From owner-freebsd-hackers Sun Mar 16 00:21:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA15819 for hackers-outgoing; Sun, 16 Mar 1997 00:21:42 -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 AAA15808 for ; Sun, 16 Mar 1997 00:21:36 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id TAA31378; Sun, 16 Mar 1997 19:18:09 +1100 Date: Sun, 16 Mar 1997 19:18:09 +1100 From: Bruce Evans Message-Id: <199703160818.TAA31378@godzilla.zeta.org.au> To: chuckr@glue.umd.edu, imp@village.org Subject: Re: Make question Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I think the problem is that /usr/src is a symlink to >/jaz/FreeBSD/current/src and when I recurse it uses the real path, >while when I don't it uses $PWD. When I cd to >/jaz/FreeBSD/current/src/usr.bin/file rather than >/usr/src/usr.bin/file, then it picks up the right thing :-(. > >Sounds like a bug to me. Yes, the existence of $PWD support in `make' and shells is probably a bug. If $PWD is set and has the same device and inode as the real path, then `make' uses it instead of the path returned by getcwd() for ${.CURDIR}. It also sets $PWD in the environment to ${.CURDIR} in an attempt to show a consistent tree to sub-makes. However, this can't work unless all shells set $PWD in the same way as `make'. They don't: First, the setting of $PWD seen by the top-level make depends on whether the shell that invoked this make sets and/or exports $PWD. E.g., /bin/sh neither sets nor exports $PWD, but if $PWD is already set and exported then it will be re-exported (with the wrong value after a cd). Fix: use only real shells (that don't export $PWD). Second, sub-makes use /bin/sh, so the behaviour is deterministic, but it is normal for $PWD to be stale after a cd. `make' notices that the device or inode for $PWD is wrong, so it doesn't use the wrong $PWD; it uses the canonical one instead of the one you want. This is a non-problem except for its interaction with the first problem. Bruce From owner-freebsd-hackers Sun Mar 16 02:56:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA19959 for hackers-outgoing; Sun, 16 Mar 1997 02:56:44 -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 CAA19953 for ; Sun, 16 Mar 1997 02:56:38 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA01407; Sun, 16 Mar 1997 11:56:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id LAA06180; Sun, 16 Mar 1997 11:32:25 +0100 (MET) Message-ID: <19970316113225.PM45611@uriah.heep.sax.de> Date: Sun, 16 Mar 1997 11:32:25 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: dgy@rtd.com (Don Yuniskis) Subject: Re: wd driver questions References: <199703160345.UAA21425@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199703160345.UAA21425@seagull.rtd.com>; from Don Yuniskis on Mar 15, 1997 20:45:07 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > Could someone with more intimate knowledge of that driver spare > a few moments for a quick set of questions? That's not me :-), but wdgetctlr() seems to be the function to look at. -- 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 Mar 16 05:27:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA25516 for hackers-outgoing; Sun, 16 Mar 1997 05:27:29 -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 FAA25511 for ; Sun, 16 Mar 1997 05:27:25 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA05393 for freebsd-hackers@freebsd.org; Sun, 16 Mar 1997 14:27:24 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id OAA07209; Sun, 16 Mar 1997 14:18:12 +0100 (MET) Message-ID: <19970316141812.XK01168@uriah.heep.sax.de> Date: Sun, 16 Mar 1997 14:18:12 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Signal 11s... VM problem? X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yeah, i know that they are usually hardware. But what about this? I've just upgraded my old notebook to 2.2. It's a sluggish old 386/sx16, with just 5 MB RAM only, the bare minimum being supported by sysinstall these days. Now i'm compiling a custom kernel on it, and get occasional sig 4's, sig 10's, and sig 11's on it. The thing is, this box has been running FreeBSD for at least two years now flawlessly. Sure, the machine is already fairly loaded with just compiling a kernel (there are ~ 6 MB in the swap partition). But again, it used to work well previously... I even used to run Emacs under X11 on it, and that was at least the same load. -- 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 Mar 16 06:32:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA28122 for hackers-outgoing; Sun, 16 Mar 1997 06:32:25 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA28114 for ; Sun, 16 Mar 1997 06:32:16 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by altos.rnd.runnet.ru (8.8.5/8.7.3) with SMTP id RAA22049 for ; Sun, 16 Mar 1997 17:31:45 +0300 (MSK) Date: Sun, 16 Mar 1997 17:31:45 +0300 (MSK) From: "Maxim A. Bolotin" To: hackers@FreeBSD.org Subject: Null files in packages 2.2 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! What's up? 2.2 Release is out, but We've null files in packages-2.2. I don't know where I have to mail about it. But, for expample file auis-6.3.1.tgz is null, size's 10Mb :-( Regards, Max. - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet max@run.net. From owner-freebsd-hackers Sun Mar 16 07:21:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA01102 for hackers-outgoing; Sun, 16 Mar 1997 07:21:07 -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 HAA01087 for ; Sun, 16 Mar 1997 07:21:04 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA08470 for hackers@FreeBSD.org; Sun, 16 Mar 1997 16:21:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id QAA07324; Sun, 16 Mar 1997 16:19:26 +0100 (MET) Message-ID: <19970316161926.HY53765@uriah.heep.sax.de> Date: Sun, 16 Mar 1997 16:19:26 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.org Subject: Re: Null files in packages 2.2 References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Maxim A. Bolotin on Mar 16, 1997 17:31:45 +0300 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Maxim A. Bolotin wrote: > What's up? 2.2 Release is out, but We've null files in packages-2.2. 2.2R hasn't been announced yet. Seems somebody forgot to set the permissions of the root to 0. -- 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 Mar 16 07:35:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA01771 for hackers-outgoing; Sun, 16 Mar 1997 07:35:13 -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 HAA01766 for ; Sun, 16 Mar 1997 07:35:09 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id IAA03972; Sun, 16 Mar 1997 08:34:27 -0700 (MST) From: Don Yuniskis Message-Id: <199703161534.IAA03972@seagull.rtd.com> Subject: Re: wd driver questions To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 16 Mar 1997 08:34:26 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <19970316113225.PM45611@uriah.heep.sax.de> from "J Wunsch" at Mar 16, 97 11:32:25 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 > > Could someone with more intimate knowledge of that driver spare > > a few moments for a quick set of questions? > > That's not me :-), but wdgetctlr() seems to be the function to look > at. Heh heh heh... your fingers must be exhausted from answering all my questions, eh Joerg? :> Actually, the problem seems to be in how the probe interprets the results of the IDENTIFY command. As such, it is possible for the drive to currently be INITed to one particular geometry yet have the probe report an entirely different geometry (as I had described in my email). Of course, I know just enough about this stuff to be considered dangerous so I will have to tread carefully before recommending a patch... As always, thanks! --don From owner-freebsd-hackers Sun Mar 16 08:12:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA04826 for hackers-outgoing; Sun, 16 Mar 1997 08:12:33 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA04821 for ; Sun, 16 Mar 1997 08:12:30 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id IAA07195; Sun, 16 Mar 1997 08:12:45 -0800 (PST) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@freebsd.org Subject: Re: Null files in packages 2.2 In-reply-to: Your message of "Sun, 16 Mar 1997 16:19:26 +0100." <19970316161926.HY53765@uriah.heep.sax.de> Date: Sun, 16 Mar 1997 08:12:45 -0800 Message-ID: <7190.858528765@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 2.2R hasn't been announced yet. Seems somebody forgot to set the > permissions of the root to 0. Actually, the permissions are correct. I haven't announced it because I want to give the mirrors a fighting chance of getting it before the hoards descend on us. Of course, now that a certain Russian has mentioned it in this mailing list, I guess that secret's already out. :-) No big deal. The mirrors seem to be happily sucking it down. Jordan From owner-freebsd-hackers Sun Mar 16 08:52:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA06440 for hackers-outgoing; Sun, 16 Mar 1997 08:52:03 -0800 (PST) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA06413 for ; Sun, 16 Mar 1997 08:51:54 -0800 (PST) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id RAA02230; Sun, 16 Mar 1997 17:51:07 +0100 (MET) From: Wolfgang Helbig Message-Id: <199703161651.RAA02230@helbig.informatik.ba-stuttgart.de> Subject: Re: wd driver questions In-Reply-To: <199703161530.IAA03754@seagull.rtd.com> from Don Yuniskis at "Mar 16, 97 08:30:41 am" To: dgy@rtd.com (Don Yuniskis) Date: Sun, 16 Mar 1997 17:51:05 +0100 (MET) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Greetings and Hallucinations! > > > It appears that boot.c uses the disk geometry obtained from the > BIOS (I think getdiskinfo() or something like that which looks > at the disk parameter table entry for each disk). Is this > correct? Think so. > However, the probe for wd appears to query the drive (with an > IDENTIFY command) to obtain these parameters. Is this also > correct? Think so. > And, how (if at all) does the geometry written to the disklabel > figure into the operation/calculations of the driver? As far as I could decipher from the driver code (wd.c) the probed geometry is used only to read the label. From there on the geometry read from the label is used exclusively by the driver. Both are the same, if you disklabel auto. But I'm not really sure about my findings. > > Thx! > --don > From owner-freebsd-hackers Sun Mar 16 09:38:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA09261 for hackers-outgoing; Sun, 16 Mar 1997 09:38:47 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09249 for ; Sun, 16 Mar 1997 09:38:42 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by altos.rnd.runnet.ru (8.8.5/8.7.3) with SMTP id UAA04547; Sun, 16 Mar 1997 20:37:51 +0300 (MSK) Date: Sun, 16 Mar 1997 20:37:51 +0300 (MSK) From: Maxim Bolotin To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: Null files in packages 2.2 In-Reply-To: <7190.858528765@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 Sun, 16 Mar 1997, Jordan K. Hubbard wrote: > Of course, now that a certain Russian has mentioned it in this > mailing list, I guess that secret's already out. :-) > > No big deal. The mirrors seem to be happily sucking it down. Oohh, I'm sorry for announce, but, the question still exists. What do you think about an empty packages ? Max. - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet max@run.net. From owner-freebsd-hackers Sun Mar 16 09:53:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA09897 for hackers-outgoing; Sun, 16 Mar 1997 09:53:24 -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 JAA09890 for ; Sun, 16 Mar 1997 09:53:21 -0800 (PST) Received: from Mars.mcs.net (ljo@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id LAA18357; Sun, 16 Mar 1997 11:53:15 -0600 (CST) Received: (from ljo@localhost) by Mars.mcs.net (8.8.5/8.8.2) id LAA03747; Sun, 16 Mar 1997 11:53:15 -0600 (CST) From: Lars Jonas Olsson Message-Id: <199703161753.LAA03747@Mars.mcs.net> Subject: fetch through ftp proxy? To: hackers@freebsd.org Date: Sun, 16 Mar 1997 11:53:14 -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'm trying to get fetch to work through a netscape proxy server. I have set FTP_PROCY environment variable and get the following scrambled error message. Any ideas? At least there seems to be some error with error messages. It seems the first 3-4 characters of every line are missing. Jonas #fetch -v ftp://freefall.cdrom.com/pub/FreeBSD/LOCAL_PORTS/MG.tar.Z Sending: USER anonymous@freefall.cdrom.com L>Proxy denies fulfilling the request Y>

Proxy denies fulfilling the request

client either is not allowed to access the requested object ugh this proxy, or the proxy denies requests from your IP address gether. Sending: QUIT fetch: proxy: connection in wrong state From owner-freebsd-hackers Sun Mar 16 09:55:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10107 for hackers-outgoing; Sun, 16 Mar 1997 09:55:25 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10099 for ; Sun, 16 Mar 1997 09:55:23 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id JAA08029; Sun, 16 Mar 1997 09:55:26 -0800 (PST) To: Maxim Bolotin cc: hackers@freebsd.org Subject: Re: Null files in packages 2.2 In-reply-to: Your message of "Sun, 16 Mar 1997 20:37:51 +0300." Date: Sun, 16 Mar 1997 09:55:26 -0800 Message-ID: <8025.858534926@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, 16 Mar 1997, Jordan K. Hubbard wrote: > > > Of course, now that a certain Russian has mentioned it in this > > mailing list, I guess that secret's already out. :-) > > > > No big deal. The mirrors seem to be happily sucking it down. > > Oohh, I'm sorry for announce, but, the question still exists. > What do you think about an empty packages ? What do you mean by "empty packages" - you mean zero length? All the files I see in packages-2.2/All look healthy to me. Jordan From owner-freebsd-hackers Sun Mar 16 10:03:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA10497 for hackers-outgoing; Sun, 16 Mar 1997 10:03:30 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA10487 for ; Sun, 16 Mar 1997 10:03:24 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by altos.rnd.runnet.ru (8.8.5/8.7.3) with SMTP id VAA06075; Sun, 16 Mar 1997 21:02:39 +0300 (MSK) Date: Sun, 16 Mar 1997 21:02:39 +0300 (MSK) From: Maxim Bolotin To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: Null files in packages 2.2 In-Reply-To: <8025.858534926@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 Sun, 16 Mar 1997, Jordan K. Hubbard wrote: > > On Sun, 16 Mar 1997, Jordan K. Hubbard wrote: > What do you mean by "empty packages" - you mean zero length? > All the files I see in packages-2.2/All look healthy to me. I not mean zero length, I mean this: altos,max % pwd /usr4/FreeBSD/packages-2.2/All altos,max % ls -l zsh-3.0.2.tgz -r--r--r-- 1 root wheel 320931 13 Mar 05:35 zsh-3.0.2.tgz altos,max % tar tzf zsh-3.0.2.tgz gzip: stdin: not in gzip format tar: child returned status 1 altos,max % od zsh-3.0.2.tgz 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 1162640 altos,max % And I can show you alot of such files. Max. > > Jordan > - Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 Russia, RUNNet max@run.net. From owner-freebsd-hackers Sun Mar 16 10:07:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA10885 for hackers-outgoing; Sun, 16 Mar 1997 10:07:50 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA10876; Sun, 16 Mar 1997 10:07:44 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id KAA08143; Sun, 16 Mar 1997 10:07:46 -0800 (PST) To: Maxim Bolotin cc: hackers@freebsd.org, asami@freebsd.org Subject: Re: Null files in packages 2.2 In-reply-to: Your message of "Sun, 16 Mar 1997 21:02:39 +0300." Date: Sun, 16 Mar 1997 10:07:45 -0800 Message-ID: <8138.858535665@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > altos,max % pwd > /usr4/FreeBSD/packages-2.2/All > altos,max % ls -l zsh-3.0.2.tgz > -r--r--r-- 1 root wheel 320931 13 Mar 05:35 zsh-3.0.2.tgz > altos,max % tar tzf zsh-3.0.2.tgz Oh. :-( Right you are, Max. These files are HOSED! Heeeeeeeeeeeeeeellllp, Satoshiiiiiiiiii!! :-) I don't even know where the packages came from, so I'm really going to have to leave the repair work to Der Herr Portsmeister. Jordan From owner-freebsd-hackers Sun Mar 16 10:16:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA11419 for hackers-outgoing; Sun, 16 Mar 1997 10:16:11 -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 KAA11414 for ; Sun, 16 Mar 1997 10:16:07 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id FAA10848; Mon, 17 Mar 1997 05:14:38 +1100 Date: Mon, 17 Mar 1997 05:14:38 +1100 From: Bruce Evans Message-Id: <199703161814.FAA10848@godzilla.zeta.org.au> To: dgy@rtd.com, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> And, how (if at all) does the geometry written to the disklabel >> figure into the operation/calculations of the driver? > >As far as I could decipher from the driver code (wd.c) the probed geometry >is used only to read the label. No, the probed geometry is used for everything in the driver. >From there on the geometry read from the >label is used exclusively by the driver. Both are the same, if you >disklabel auto. The geometry read from the label is not used by the driver (except in `#if 0' code). It is normally only used by fdisk. newfs ignores it by default. The BIOS geometry is not used either, except in some kludgy cases involving drives that don't report their geometry (old MFM drives). Old versions of the driver worked like you thought, except for complications. First the MBR was read and the BIOS geometry was guessed from it. The the drive was programmed to use the guessed BIOS geometry. Then the label and possibly the bad block table was read. Then the drive was programmed to use the geometry in the label. There were many driver bugs (all of this must be done atomically, and some of it must be redone after drive reset ...). There were many configuration errors (it was possible to put a physically impossible. or just inconsistent, geometry in the label ...). Bruce From owner-freebsd-hackers Sun Mar 16 10:58:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA13928 for hackers-outgoing; Sun, 16 Mar 1997 10:58:43 -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 KAA13921 for ; Sun, 16 Mar 1997 10:58:37 -0800 (PST) From: jeremyd@bb.cc.wa.us Received: from 208.8.136.246 (ariesd14.bb.cc.wa.us [208.8.136.246]) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id KAA05716 for ; Sun, 16 Mar 1997 10:57:26 -0800 (PST) Date: Sun, 16 Mar 1997 10:57:26 -0800 (PST) Message-Id: <199703161857.KAA05716@aries.bb.cc.wa.us> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: hackers@freebsd.org X-Mailer: SPRY Mail Version: 04.00.06.17 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Sun Mar 16 12:29:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA17717 for hackers-outgoing; Sun, 16 Mar 1997 12:29:08 -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 MAA17711 for ; Sun, 16 Mar 1997 12:29:06 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id NAA22140; Sun, 16 Mar 1997 13:27:34 -0700 (MST) From: Don Yuniskis Message-Id: <199703162027.NAA22140@seagull.rtd.com> Subject: Re: wd driver questions To: helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) Date: Sun, 16 Mar 1997 13:27:34 -0700 (MST) Cc: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) In-Reply-To: <199703161651.RAA02230@helbig.informatik.ba-stuttgart.de> from "Wolfgang Helbig" at Mar 16, 97 05:51:05 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 Wolfgang Helbig said: > > > And, how (if at all) does the geometry written to the disklabel > > figure into the operation/calculations of the driver? > > As far as I could decipher from the driver code (wd.c) the probed geometry > is used only to read the label. From there on the geometry read from the > label is used exclusively by the driver. Both are the same, if you > disklabel auto. > But I'm not really sure about my findings. >From *my* observations, it doesn't look like the disklabel geometry is used at *all*! (at least, not in the driver... I have no idea if other tools (fdisk, newfs) use the geometry from the disklabel (since it would be difficult for them to get it otherwise?)) --don From owner-freebsd-hackers Sun Mar 16 12:33:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA17985 for hackers-outgoing; Sun, 16 Mar 1997 12:33: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 ESMTP id MAA17970 for ; Sun, 16 Mar 1997 12:33:29 -0800 (PST) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.8.5/8.6.6) with ESMTP id NAA02303; Sun, 16 Mar 1997 13:33:13 -0700 (MST) Message-Id: <199703162033.NAA02303@rover.village.org> To: Bruce Evans Subject: Re: Make question Cc: chuckr@glue.umd.edu, hackers@freebsd.org In-reply-to: Your message of "Sun, 16 Mar 1997 19:18:09 +1100." <199703160818.TAA31378@godzilla.zeta.org.au> References: <199703160818.TAA31378@godzilla.zeta.org.au> Date: Sun, 16 Mar 1997 13:33:13 -0700 From: Warner Losh Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703160818.TAA31378@godzilla.zeta.org.au> Bruce Evans writes: : Fix: use only real shells (that don't export $PWD). Do you happen to know which shells do this? I suppose that using tcsh and seeing the problem doesn't put that shell on the list :-). Also, now that I know the problem, a simple ln -s /usr/obj/jaz/FreeSBD/current/src /usr/obj/usr/src seems to work around the problem for me. Thanks for the insight. Warner From owner-freebsd-hackers Sun Mar 16 12:36:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18161 for hackers-outgoing; Sun, 16 Mar 1997 12:36:18 -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 MAA18156 for ; Sun, 16 Mar 1997 12:36:17 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id NAA22639; Sun, 16 Mar 1997 13:34:34 -0700 (MST) From: Don Yuniskis Message-Id: <199703162034.NAA22639@seagull.rtd.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Sun, 16 Mar 1997 13:34:34 -0700 (MST) Cc: dgy@rtd.com, helbig@MX.BA-Stuttgart.De, hackers@FreeBSD.ORG In-Reply-To: <199703161814.FAA10848@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 05:14:38 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 Greetings! > >> And, how (if at all) does the geometry written to the disklabel > >> figure into the operation/calculations of the driver? > > > >As far as I could decipher from the driver code (wd.c) the probed geometry > >is used only to read the label. > > No, the probed geometry is used for everything in the driver. Yes, that's what it appears to be. Except that the BIOS geometry is used during boot (at least in the 2.1 stuff). > >From there on the geometry read from the > >label is used exclusively by the driver. Both are the same, if you > >disklabel auto. > > The geometry read from the label is not used by the driver (except in > `#if 0' code). It is normally only used by fdisk. newfs ignores it by > default. How does fdisk use it? Just to determine where cylinder boundaries exist? (i.e. so partitions are an integral multiple of cylinder size?) > The BIOS geometry is not used either, except in some kludgy cases > involving drives that don't report their geometry (old MFM drives). Again, the IPL stuff comes from the disk using the BIOS/"system ROM" geometry, right? > Old versions of the driver worked like you thought, except for > complications. First the MBR was read and the BIOS geometry was > guessed from it. The the drive was programmed to use the guessed BIOS > geometry. Then the label and possibly the bad block table was read. > Then the drive was programmed to use the geometry in the label. > There were many driver bugs (all of this must be done atomically, and > some of it must be redone after drive reset ...). There were many > configuration errors (it was possible to put a physically impossible. > or just inconsistent, geometry in the label ...). No one (with the exception of fdisk?) *should* need to know the real geometry, right? And, it could possibly be argues that fdisk/newfs only "need" to know it for "performance" reasons, right? --don From owner-freebsd-hackers Sun Mar 16 12:56:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18833 for hackers-outgoing; Sun, 16 Mar 1997 12:56:15 -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 MAA18828 for ; Sun, 16 Mar 1997 12:56:13 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id NAA23944; Sun, 16 Mar 1997 13:55:39 -0700 (MST) From: Don Yuniskis Message-Id: <199703162055.NAA23944@seagull.rtd.com> Subject: wd and funky geometry (understood?) To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Date: Sun, 16 Mar 1997 13:55:38 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), bde@zeta.org.au (Bruce Evans) 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 Greetings! I *think* I've located the source of the geometry foul-ups I've seen with IDE drives... [apologies that the code fragments herein are quoted from a 2.1R system -- I've just dismantled the 2.1.7R system to reprogram the system ROMs :-( The code is essentially the same. Liberal snipping employed throughout for readability...] This problem appears to have been in the system since at least Aug 94 (by my notes). The problem appears to an inconsistent use of geometry information for each drive. During IPL, the drive is INITed with parameters from the BIOS's disk parameter table. This makes sense as I can't imagine any *other* place from which to get the disk geometry (reliably). From boot() in /usr/src/sys/i386/boot/biosboot/boot.c: /////////////////////////////////////////////////////////////////// #include struct bootinfo bootinfo; /* Pick up the story from the Bios on geometry of disks */ for(ret = 0; ret < N_BIOS_GEOM; ret ++) bootinfo.bi_bios_geom[ret] = get_diskinfo(ret + 0x80); /////////////////////////////////////////////////////////////////// [get_diskinfo() system call basically does an INT 13, AH=8 (Read Drive Parameters) -- see /usr/src/sys/i386/boot/biosboot/bios.S] Since the system ROM's have already INITed the drive, the geometry reflected in bootinfo.bi_bios_geom[] will reflect the current geometries of each of these INITed drives. However, in wdattach(), wdgetctlr() is invoked to get the drive's geometry. It does this by issuing an IDENTIFY command (i.e. READP) to the drive. The data returned by the command is interpreted as a wdparams structure: /////////////////////////////////////////////////////////////////// /* * read parameters command returns this: */ struct wdparams { /* drive info */ short wdp_config; /* general configuration */ short wdp_fixedcyl; /* number of non-removable cylinders */ short wdp_removcyl; /* number of removable cylinders */ short wdp_heads; /* number of heads */ short wdp_unfbytespertrk; /* number of unformatted bytes/track */ short wdp_unfbytes; /* number of unformatted bytes/sector */ short wdp_sectors; /* number of sectors */ short wdp_minisg; /* minimum bytes in inter-sector gap*/ short wdp_minplo; /* minimum bytes in postamble */ short wdp_vendstat; /* number of words of vendor status */ /* controller info */ char wdp_cnsn[20]; /* controller serial number */ short wdp_cntype; /* controller type */ #define WDTYPE_SINGLEPORTSECTOR 1 /* single port, single sector buffer */ #define WDTYPE_DUALPORTMULTI 2 /* dual port, multiple sector buffer */ #define WDTYPE_DUALPORTMULTICACHE 3 /* above plus track cache */ short wdp_cnsbsz; /* sector buffer size, in sectors */ short wdp_necc; /* ecc bytes appended */ char wdp_rev[8]; /* firmware revision */ char wdp_model[40]; /* model name */ short wdp_nsecperint; /* sectors per interrupt */ short wdp_usedmovsd; /* can use double word read/write? */ }; /////////////////////////////////////////////////////////////////// The drive's geometry is deduced from the wdp_fixedcyl, wdp_removcyl, wdp_heads and wdp_sectors members thereof. This information is reported in the probe (actually, the attach) on the console as the device's geometry. The drive is then reINITed with these parameters by wdsetctlr() when the device is opened or an error is detected. Herein lies the problem: these parameters reflect "the default geometry of the device" (paraphrased from the ATA specification). However, the BIOS's geometry may *NOT* agree with the drives "default geometry". For example, the probe of my IDE drives yields: wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 329MB (675450 sectors), 790 cyls, 15 heads, 57 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 321MB (659232 sectors), 654 cyls, 16 heads, 63 S/T, 512 B/S However, *both* drives have a BIOS geometry of 611/16/63. (Sorry, my ancient BIOS does not support "user configurable" geometries so this was the closest geometry I could find -- hence the reason I have disassembled the 2.1.7R system to reprogram the system ROMs! The drives will automatically adapt to whatever geometry they are INITed with so it doesn't pose a problem). I haven't delved into how the geometry contained within the disklabel written to the drive factors into all this. Why is all this a problem? I don't *think* it causes any problems during IPL -- since the drive is INITed with the BIOS geometry during the boot and then switched to the "default geometry" during the attach/open. I think that the image loaded from the disk during boot is small enough that changes to the size/shape of the first track are safely ignored. (though, on second thought, I suspect this *can* screw you if your FBSD partition does not begin at the start of the disk! Comments?) However, sharing a partition might be a problem since DOS's FDISK (which you used to create the DOS partition) will talk to a disk shaped per the BIOS geometry. When FBSD takes over, the geometry of the disk is changed and track/cylinder boundaries can "move" (e.g., consider my case with a default geometry of 57 S/C vs. the BIOS's 63 S/C). And, switching to/from DOS can screw you. Consider DOS and FBSD sharing wd0. FBSD reINITs the drive to use it's default geometry. Then, you mount a DOS partition FROM THE SAME DRIVE! The layout of the DOS partition expected the BIOS geometry yet the disk is now accessed using the FBSD geometry. I suspect that LBA *could* be a redeeming grace. However, I don't know enough about the *guarantees* within the drive to determine if a particular sector address will *allways* map to the same (PHYSICALLY EQUIVALENT) sector regardless of geometry (i.e., will sector "97" in a 611/16/63 geometry correspond to the exactl same physical sector when the drive is configured for 790/15/57??) [someone who really *knows* what they are talking about could probably determine the *real* effects of all this :-( ] I was initially thinking a good hack to fix this would be to simply copy the "apparent" disk geometry from the results of the IDENTIFY command (i.e. from the shorts at parameters[54] through [56]) into the "default" disk geometry parameters (i.e., the shorts at parameters[1], [4] and [6]). That seemed easier than changing the wdparams structure to include thes other fields and then *use* those fields instead of wdp_ncylinders, wdp_heads, etc. But, I'm a bit nervous about just making that change and "hoping" it doesn't break something else :> I don't claim to know what the hell I'm talking about :> so if someone would like to enlighten me as to the errors in my analysis/assumptions, I'd be *thrilled*! :> But, right now I have to try and tweek the geometries in these system ROMs to match the geometries of my drives (and forget all these other -- more interesting -- issues! :>) Thanks! --don From owner-freebsd-hackers Sun Mar 16 13:15:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA19795 for hackers-outgoing; Sun, 16 Mar 1997 13:15:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA19790 for ; Sun, 16 Mar 1997 13:15:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA06259; Sun, 16 Mar 1997 14:05:25 -0700 From: Terry Lambert Message-Id: <199703162105.OAA06259@phaeton.artisoft.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Sun, 16 Mar 1997 14:05:25 -0700 (MST) Cc: dgy@rtd.com, helbig@MX.BA-Stuttgart.De, hackers@FreeBSD.ORG In-Reply-To: <199703161814.FAA10848@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 05:14:38 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 > >> And, how (if at all) does the geometry written to the disklabel > >> figure into the operation/calculations of the driver? > > > >As far as I could decipher from the driver code (wd.c) the probed geometry > >is used only to read the label. > > No, the probed geometry is used for everything in the driver. Why are we using a probed geometry insted of the geometry reported from the INT 0x13 call in the boot blocks? The idea that the drive could be INIT'ed to a different geometry is valid. 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 Mar 16 13:17:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA19915 for hackers-outgoing; Sun, 16 Mar 1997 13:17:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA19910 for ; Sun, 16 Mar 1997 13:17:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA06269; Sun, 16 Mar 1997 14:07:44 -0700 From: Terry Lambert Message-Id: <199703162107.OAA06269@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Sun, 16 Mar 1997 14:07:44 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <199703160612.XAA13150@rover.village.org> from "Warner Losh" at Mar 15, 97 11:12: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 > {standard input}: Assembler messages: > {standard input}:1147: Warning: GOT relocation burb: `__vt$5TNode' should be global > > OK. The problem here is trivial to reproduce. > > All of the members of TNode are virtual. Even the dtor, and it is > specifically inline (which is a major no-no for virtual dtors (and > virtual functions in general) because most compiler give multiple > copies). > > This message should really read > > "TNode::~TNode is an inline virtual function, and I don't know how to > cope, so fix the dubious construct in the code, OK" > > In the case of tvision 0.3, I see it for each of the classes that have > virtual inline functions, but it reports the wrong function name. > > Comments? Hee hee hee hee? *ALL* the members are virtual? Even the constructor, which isn't allowed to be? 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 Mar 16 13:20:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA20146 for hackers-outgoing; Sun, 16 Mar 1997 13:20:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA20139 for ; Sun, 16 Mar 1997 13:20:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA06281; Sun, 16 Mar 1997 14:10:12 -0700 From: Terry Lambert Message-Id: <199703162110.OAA06281@phaeton.artisoft.com> Subject: Re: Null files in packages 2.2 To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 16 Mar 1997 14:10:12 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <19970316161926.HY53765@uriah.heep.sax.de> from "J Wunsch" at Mar 16, 97 04:19: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 > > What's up? 2.2 Release is out, but We've null files in packages-2.2. > > 2.2R hasn't been announced yet. Seems somebody forgot to set the > permissions of the root to 0. Yes it has. It was some 700 lines of a message from Jordan to the -announce list. 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 Mar 16 13:29:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA20581 for hackers-outgoing; Sun, 16 Mar 1997 13:29:03 -0800 (PST) Received: from relay01.iafrica.com (relay01.iafrica.com [196.7.0.160]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA20576 for ; Sun, 16 Mar 1997 13:28:58 -0800 (PST) Received: from monks.iafrica.com [196.7.124.21] by relay01.iafrica.com with smtp (Exim 1.59 #1) id 0w6NTw-0004Ir-00; Sun, 16 Mar 1997 23:28:47 +0200 Comments: Authenticated sender is From: jason@relay01.iafrica.com To: hackers@freebsd.org Date: Sun, 16 Mar 1997 23:29:31 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: e-mail error Priority: normal X-mailer: Pegasus Mail for Windows (v2.52) Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To whom it may concern It seems that a small error has occurred, as I am receiving mail that has been forwarded to me from one of your pc's. It does cause me a bit of a problem as it jams up my mailbox. I would appreciate it if you could please "unsubscribe" me. Thanking you Jason From owner-freebsd-hackers Sun Mar 16 14:20:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA22651 for hackers-outgoing; Sun, 16 Mar 1997 14:20:30 -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 ESMTP id OAA22646 for ; Sun, 16 Mar 1997 14:20:23 -0800 (PST) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.8.5/8.6.6) with ESMTP id PAA03645; Sun, 16 Mar 1997 15:19:21 -0700 (MST) Message-Id: <199703162219.PAA03645@rover.village.org> To: Terry Lambert Subject: Re: Barb problem, FOUND Cc: hackers@FreeBSD.org In-reply-to: Your message of "Sun, 16 Mar 1997 14:07:44 MST." <199703162107.OAA06269@phaeton.artisoft.com> References: <199703162107.OAA06269@phaeton.artisoft.com> Date: Sun, 16 Mar 1997 15:19:20 -0700 From: Warner Losh Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199703162107.OAA06269@phaeton.artisoft.com> Terry Lambert writes: : *ALL* the members are virtual? : : Even the constructor, which isn't allowed to be? Ummm, the ctor isn't a member function, it is special :-) Warner From owner-freebsd-hackers Sun Mar 16 14:29:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA22939 for hackers-outgoing; Sun, 16 Mar 1997 14:29:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA22934 for ; Sun, 16 Mar 1997 14:29:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA06467; Sun, 16 Mar 1997 15:19:47 -0700 From: Terry Lambert Message-Id: <199703162219.PAA06467@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Sun, 16 Mar 1997 15:19:47 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.org In-Reply-To: <199703162219.PAA03645@rover.village.org> from "Warner Losh" at Mar 16, 97 03:19: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 > : *ALL* the members are virtual? > : > : Even the constructor, which isn't allowed to be? > > Ummm, the ctor isn't a member function, it is special :-) OK, then I don't know why it's bitching. It's perfectly valid to have a virtual destructor inline: the STL library book does it, so it's an OK thing to do. Yes, I *know* you would generate extra code (if you weren't running ELF or some other agregable object format, or if you were and your linker was stupid as a box of rocks. Personally, I think it's a compiler bug. 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 Mar 16 14:48:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA23639 for hackers-outgoing; Sun, 16 Mar 1997 14:48:14 -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 OAA23634 for ; Sun, 16 Mar 1997 14:48:09 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id JAA17242; Mon, 17 Mar 1997 09:44:21 +1100 Date: Mon, 17 Mar 1997 09:44:21 +1100 From: Bruce Evans Message-Id: <199703162244.JAA17242@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: wd driver questions Cc: hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> No, the probed geometry is used for everything in the driver. > >Yes, that's what it appears to be. Except that the BIOS geometry is >used during boot (at least in the 2.1 stuff). Booting is not part of the driver :-). >> The geometry read from the label is not used by the driver (except in >> `#if 0' code). It is normally only used by fdisk. newfs ignores it by >> default. > >How does fdisk use it? Just to determine where cylinder boundaries >exist? (i.e. so partitions are an integral multiple of cylinder size?) fdisk presents it as a default if the disk doesn't already have a (reasonable) partition table on it. This seems to mainly confuse users :-(. It later uses the geometry that the user set or accepted to write the CHS values. Garbage geometry -> garbage CHS values -> unbootable partitions and probably a different garbage geometry for the default next time. >> The BIOS geometry is not used either, except in some kludgy cases >> involving drives that don't report their geometry (old MFM drives). > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" >geometry, right? What's IPL? No, FreeBSD doesn't use the geometry reported by the BIOS except to print a table of BIOS geometries when it is booted with -v, and in some kludgy cases (see above). It doesn't know the correspondence between BIOS drives numbers and FreeBSD drive names, so it can't look up its table of BIOS drive geometries to get the BIOS geometry (if any) corresponding to each FreeBSD drive. >No one (with the exception of fdisk?) *should* need to know the real >geometry, right? And, it could possibly be argues that fdisk/newfs >only "need" to know it for "performance" reasons, right? Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. Bruce From owner-freebsd-hackers Sun Mar 16 17:24:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA08956 for hackers-outgoing; Sun, 16 Mar 1997 17:24:57 -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 RAA08937 for ; Sun, 16 Mar 1997 17:24:53 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id QAA23771 for ; Sun, 16 Mar 1997 16:09:49 -0800 (PST) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.8.5/8.6.6) with ESMTP id RAA03992; Sun, 16 Mar 1997 17:08:59 -0700 (MST) Message-Id: <199703170008.RAA03992@rover.village.org> To: Terry Lambert Subject: Re: Barb problem, FOUND Cc: hackers@FreeBSD.org In-reply-to: Your message of "Sun, 16 Mar 1997 15:19:47 MST." <199703162219.PAA06467@phaeton.artisoft.com> References: <199703162219.PAA06467@phaeton.artisoft.com> Date: Sun, 16 Mar 1997 17:08:58 -0700 From: Warner Losh Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <199703162219.PAA06467@phaeton.artisoft.com> Terry Lambert writes: : OK, then I don't know why it's bitching. It's perfectly valid to have : a virtual destructor inline: the STL library book does it, so it's an : OK thing to do. It is a valid C++ construct, but it is not always handled well by C++ compilers. That's why it is bitching. Generally, virtual inlines are a bad idea for the reasons that I've already gone into. : Personally, I think it's a compiler bug. It is. Quanitifying it is the hard part. Warner From owner-freebsd-hackers Sun Mar 16 17:25:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09008 for hackers-outgoing; Sun, 16 Mar 1997 17:25:05 -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 RAA08955 for ; Sun, 16 Mar 1997 17:24:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id QAA23799 for ; Sun, 16 Mar 1997 16:16:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06832; Sun, 16 Mar 1997 17:06:18 -0700 From: Terry Lambert Message-Id: <199703170006.RAA06832@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Sun, 16 Mar 1997 17:06:17 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.org In-Reply-To: <199703170008.RAA03992@rover.village.org> from "Warner Losh" at Mar 16, 97 05:08:58 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 > : OK, then I don't know why it's bitching. It's perfectly valid to have > : a virtual destructor inline: the STL library book does it, so it's an > : OK thing to do. > > It is a valid C++ construct, but it is not always handled well by C++ > compilers. That's why it is bitching. Generally, virtual inlines are > a bad idea for the reasons that I've already gone into. Those reasons are only valid for bad compiler/object-format/linker combinations. Too bad FreeBSD has one of these. 8-|. The "correct" FreeBSD "workaround" (as long as we are stuck at a.out) is to duplicate the code statically, per module using the virtual base class. > : Personally, I think it's a compiler bug. > > It is. Quanitifying it is the hard part. The compiler should "do the right thing". The "right thing" in the FreeBSD case is "emit the code and don't bitch about it being a potentially duplicated code block because of the scoping forced on it by FreeBSD's use of the antiquated a.out object format". 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 Mar 16 17:25:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA09153 for hackers-outgoing; Sun, 16 Mar 1997 17:25:43 -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 RAA09135 for ; Sun, 16 Mar 1997 17:25:36 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id QAA23782 for ; Sun, 16 Mar 1997 16:13:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06819; Sun, 16 Mar 1997 17:02:53 -0700 From: Terry Lambert Message-Id: <199703170002.RAA06819@phaeton.artisoft.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Sun, 16 Mar 1997 17:02:52 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703162244.JAA17242@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 09:44: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 > >How does fdisk use it? Just to determine where cylinder boundaries > >exist? (i.e. so partitions are an integral multiple of cylinder size?) > > fdisk presents it as a default if the disk doesn't already have a > (reasonable) partition table on it. This seems to mainly confuse > users :-(. It later uses the geometry that the user set or accepted > to write the CHS values. Garbage geometry -> garbage CHS values -> > unbootable partitions and probably a different garbage geometry for > the default next time. Q: Why are the users permitted to override geometry? A: Because FreeBSD sometimes gets it wrong. Q: Why does FreeBSD sometimes get it wrong? A: Because FreeBS gets the INT 13 values in the boot loader, but then discards them in favor of the potentially incorrect CMOS and/or non-BIOS drive query return values. Q: Why does FreeBSD do this? A: No one knows. > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" > >geometry, right? > > What's IPL? No, FreeBSD doesn't use the geometry reported by the BIOS > except to print a table of BIOS geometries when it is booted with -v, > and in some kludgy cases (see above). It doesn't know the correspondence > between BIOS drives numbers and FreeBSD drive names, so it can't look up > its table of BIOS drive geometries to get the BIOS geometry (if any) > corresponding to each FreeBSD drive. IPL = Initial Program Load. It's an IBM term. There is also the (general industry standard) RPL or "Remote Program Load". Typically, if a card has a ROM slot, there is an RPL ROM available for it. Most point of sale systems use RPL instead of IPL to remove hardware components from the cash registers, etc.. I think that the correspondance can be largely established between BIOS device and FreeBSD device using sector counts from protected mode calls vds C*H*S from the BIOS. In the case where they are equal, it doesn't matter. Where it seems to matter, you can look for the FreeBSD partition, the DOS boot block to find the boot device, or, if all else fails, ask the user (instead of asking by default). The correspondance problem is the hardest to solve, given the 7k or so second stage BIOS boot block limit. > >No one (with the exception of fdisk?) *should* need to know the real > >geometry, right? And, it could possibly be argues that fdisk/newfs > >only "need" to know it for "performance" reasons, right? > > Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. Also if it is writing C/H/S values for use by the DOS MBR to get to the BSD second stage boot, since the DOS MBR (incorrectly) looks at the C/H/S values instead of the LBA values (since the DOS MBR has the DOS geometry available, factoring an LBA to a C/H/S value is easy for it to do, but it is too badly designed to do that). In some respects, if our boot block would modify the LBA values to match the C/H/S values, while still in real mode, we would be much happier. Tony Overfield (an engineer from Dell) has gone over this all before, but since he wants a three stage boot, a lot of his good comments were thrown out with the bathwater of a three stage boot after no one came forward to "bell the cat" (write the three stage boot code). 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 Mar 16 17:28:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10011 for hackers-outgoing; Sun, 16 Mar 1997 17:28: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 RAA09976 for ; Sun, 16 Mar 1997 17:28:43 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id PAA23225 for ; Sun, 16 Mar 1997 15:09:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id KAA17924; Mon, 17 Mar 1997 10:02:17 +1100 Date: Mon, 17 Mar 1997 10:02:17 +1100 From: Bruce Evans Message-Id: <199703162302.KAA17924@godzilla.zeta.org.au> To: bde@zeta.org.au, imp@village.org Subject: Re: Make question Cc: chuckr@glue.umd.edu, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >: Fix: use only real shells (that don't export $PWD). > >Do you happen to know which shells do this? I suppose that using tcsh >and seeing the problem doesn't put that shell on the list :-). I don't know many shells. Bash sets $PWD but doesn't export it. sh doesn't set it or export it. Bruce From owner-freebsd-hackers Sun Mar 16 18:16:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA12969 for hackers-outgoing; Sun, 16 Mar 1997 18:16:10 -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 SAA12950 for ; Sun, 16 Mar 1997 18:16:02 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id TAA16102 for freebsd-hackers@freefall.cdrom.com; Sun, 16 Mar 1997 19:15:28 -0700 (MST) From: Don Yuniskis Message-Id: <199703170215.TAA16102@seagull.rtd.com> Subject: Re: wd driver questions To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Date: Sun, 16 Mar 1997 19:15:27 -0700 (MST) 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 Terry Lambert said: > > > >> And, how (if at all) does the geometry written to the disklabel > > >> figure into the operation/calculations of the driver? > > > > > >As far as I could decipher from the driver code (wd.c) the probed geometry > > >is used only to read the label. > > > > No, the probed geometry is used for everything in the driver. > > Why are we using a probed geometry insted of the geometry reported > from the INT 0x13 call in the boot blocks? The idea that the drive > could be INIT'ed to a different geometry is valid. This is the heart of the "problem" that I was discussing. My disks, for example, are INITed by the system ROMs to a particular geometry. *Then* the probe (actually, the attach()) queries the drive and reINITs the drive for the *default* drive geometry (which, in my case, is very different from the "BIOS" geometry. See my followup (long) post on this... --don From owner-freebsd-hackers Sun Mar 16 18:19:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA13135 for hackers-outgoing; Sun, 16 Mar 1997 18:19:32 -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 SAA13130 for ; Sun, 16 Mar 1997 18:19:30 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id TAA16040; Sun, 16 Mar 1997 19:14:33 -0700 (MST) From: Don Yuniskis Message-Id: <199703170214.TAA16040@seagull.rtd.com> Subject: Re: wd driver questions To: terry@lambert.org (Terry Lambert) Date: Sun, 16 Mar 1997 19:14:33 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, helbig@MX.BA-Stuttgart.De, hackers@FreeBSD.ORG In-Reply-To: <199703162105.OAA06259@phaeton.artisoft.com> from "Terry Lambert" at Mar 16, 97 02:05: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 It seems that Terry Lambert said: > > > >> And, how (if at all) does the geometry written to the disklabel > > >> figure into the operation/calculations of the driver? > > > > > >As far as I could decipher from the driver code (wd.c) the probed geometry > > >is used only to read the label. > > > > No, the probed geometry is used for everything in the driver. > > Why are we using a probed geometry insted of the geometry reported > from the INT 0x13 call in the boot blocks? The idea that the drive > could be INIT'ed to a different geometry is valid. This is the heart of the "problem" that I was discussing. My disks, for example, are INITed by the system ROMs to a particular geometry. *Then* the probe (actually, the attach()) queries the drive and reINITs the drive for the *default* drive geometry (which, in my case, is very different from the "BIOS" geometry. See my followup (long) post on this... --don From owner-freebsd-hackers Sun Mar 16 18:25:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA13626 for hackers-outgoing; Sun, 16 Mar 1997 18:25:28 -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 SAA13619 for ; Sun, 16 Mar 1997 18:25:24 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id TAA16670; Sun, 16 Mar 1997 19:23:27 -0700 (MST) From: Don Yuniskis Message-Id: <199703170223.TAA16670@seagull.rtd.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Sun, 16 Mar 1997 19:23:26 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703162244.JAA17242@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 09:44: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 > >> No, the probed geometry is used for everything in the driver. > > > >Yes, that's what it appears to be. Except that the BIOS geometry is > >used during boot (at least in the 2.1 stuff). > > Booting is not part of the driver :-). Yes, I was just trying to stress the point that the geometry used during BOOT is the geometry established by the system ROMs/BIOS and that this can be different from the geometry used by FBSD (and, in my case, it IS!) > >> The geometry read from the label is not used by the driver (except in > >> `#if 0' code). It is normally only used by fdisk. newfs ignores it by > >> default. > > > >How does fdisk use it? Just to determine where cylinder boundaries > >exist? (i.e. so partitions are an integral multiple of cylinder size?) > > fdisk presents it as a default if the disk doesn't already have a > (reasonable) partition table on it. This seems to mainly confuse > users :-(. It later uses the geometry that the user set or accepted > to write the CHS values. Garbage geometry -> garbage CHS values -> > unbootable partitions and probably a different garbage geometry for > the default next time. > > >> The BIOS geometry is not used either, except in some kludgy cases > >> involving drives that don't report their geometry (old MFM drives). > > > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" > >geometry, right? > > What's IPL? Sorry... Initial Program Load :-( Easier for me to think of that than "boot"... > No, FreeBSD doesn't use the geometry reported by the BIOS > except to print a table of BIOS geometries when it is booted with -v, > and in some kludgy cases (see above). It doesn't know the correspondence > between BIOS drives numbers and FreeBSD drive names, so it can't look up > its table of BIOS drive geometries to get the BIOS geometry (if any) > corresponding to each FreeBSD drive. The point I was making (in a followup post) was that using the IDENTIFY command, you can get the geometry that the disk is currently using (though the wdparams struct currently isn't big enough to reference that particular set of parameters -- they are about 110 bytes into the parameter block returned by the IDENTIFY command). Instead, the attach currently examines the *default* geometry for the drive and uses that! So, if the BIOS has set the drive up with one particular geometry and gone through boot(), the attach() could inquire and *preserve* that geometry instead of resetting it to the "default" geometry that the disk manufaturer happened to pick... > >No one (with the exception of fdisk?) *should* need to know the real > >geometry, right? And, it could possibly be argues that fdisk/newfs > >only "need" to know it for "performance" reasons, right? > > Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. Ah, OK. But, otherwise it should just be a performance hack, right? --don From owner-freebsd-hackers Sun Mar 16 18:40:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA14386 for hackers-outgoing; Sun, 16 Mar 1997 18:40:59 -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 SAA14381 for ; Sun, 16 Mar 1997 18:40:54 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id TAA17617; Sun, 16 Mar 1997 19:37:41 -0700 (MST) From: Don Yuniskis Message-Id: <199703170237.TAA17617@seagull.rtd.com> Subject: Re: wd driver questions To: terry@lambert.org (Terry Lambert) Date: Sun, 16 Mar 1997 19:37:40 -0700 (MST) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703170002.RAA06819@phaeton.artisoft.com> from "Terry Lambert" at Mar 16, 97 05:02:52 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 Terry Lambert said: > > > >How does fdisk use it? Just to determine where cylinder boundaries > > >exist? (i.e. so partitions are an integral multiple of cylinder size?) > > > > fdisk presents it as a default if the disk doesn't already have a > > (reasonable) partition table on it. This seems to mainly confuse > > users :-(. It later uses the geometry that the user set or accepted > > to write the CHS values. Garbage geometry -> garbage CHS values -> > > unbootable partitions and probably a different garbage geometry for > > the default next time. > > Q: Why are the users permitted to override geometry? > A: Because FreeBSD sometimes gets it wrong. > > Q: Why does FreeBSD sometimes get it wrong? > A: Because FreeBS gets the INT 13 values in the boot loader, but then > discards them in favor of the potentially incorrect CMOS and/or > non-BIOS drive query return values. Yes, I don't understand why FBSD can't just use the same geometry settings that boot.c deduces? Are the BIOS ROMs no longer accessible once boot() has completed (sorry, my ignorance is showing...)? > Q: Why does FreeBSD do this? > A: No one knows. > > > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" > > >geometry, right? > > > > What's IPL? No, FreeBSD doesn't use the geometry reported by the BIOS > > except to print a table of BIOS geometries when it is booted with -v, > > and in some kludgy cases (see above). It doesn't know the correspondence > > between BIOS drives numbers and FreeBSD drive names, so it can't look up > > its table of BIOS drive geometries to get the BIOS geometry (if any) > > corresponding to each FreeBSD drive. > > IPL = Initial Program Load. It's an IBM term. There is also the Sorry. Days long ago with punched paper tape and hollerith cards :-( > (general industry standard) RPL or "Remote Program Load". Typically, > if a card has a ROM slot, there is an RPL ROM available for it. Most > point of sale systems use RPL instead of IPL to remove hardware > components from the cash registers, etc.. > > I think that the correspondance can be largely established between > BIOS device and FreeBSD device using sector counts from protected > mode calls vds C*H*S from the BIOS. In the case where they are > equal, it doesn't matter. Where it seems to matter, you can look > for the FreeBSD partition, the DOS boot block to find the boot device, > or, if all else fails, ask the user (instead of asking by default). Why *should* there be a difference? I would assume that you would err on the side of adhering to the BIOS geometry -- wouldn't adopting some *other* geometry make it tough (impossible?) to have a DOS partition on the same drive as FBSD and be able to *access* that DOS partition from FBSD? > The correspondance problem is the hardest to solve, given the 7k or > so second stage BIOS boot block limit. [I'm lost, here... <:-( ] > > >No one (with the exception of fdisk?) *should* need to know the real > > >geometry, right? And, it could possibly be argues that fdisk/newfs > > >only "need" to know it for "performance" reasons, right? > > > > Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. > > Also if it is writing C/H/S values for use by the DOS MBR to get to > the BSD second stage boot, since the DOS MBR (incorrectly) looks at > the C/H/S values instead of the LBA values (since the DOS MBR has the > DOS geometry available, factoring an LBA to a C/H/S value is easy for > it to do, but it is too badly designed to do that). I think this is the problem I've currently been having -- DOS thinks the drive is 611/16/63 but FBSD reINITs it to 790/15/57. It's been tough trying to get DOS and FBSD to fit onto the same drive... > In some respects, if our boot block would modify the LBA values to > match the C/H/S values, while still in real mode, we would be much > happier. > > Tony Overfield (an engineer from Dell) has gone over this all before, > but since he wants a three stage boot, a lot of his good comments > were thrown out with the bathwater of a three stage boot after no > one came forward to "bell the cat" (write the three stage boot code). Ah, you must find Jerry for that task (of "Tom and Jerry" cartoon fame!) ;-) --don From owner-freebsd-hackers Sun Mar 16 19:13:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15978 for hackers-outgoing; Sun, 16 Mar 1997 19:13: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 TAA15972 for ; Sun, 16 Mar 1997 19:12:56 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA06131; Mon, 17 Mar 1997 13:41:11 +1030 (CST) From: Michael Smith Message-Id: <199703170311.NAA06131@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703170002.RAA06819@phaeton.artisoft.com> from Terry Lambert at "Mar 16, 97 05:02:52 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 17 Mar 1997 13:41:10 +1030 (CST) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De 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: > > Q: Why are the users permitted to override geometry? > A: Because FreeBSD sometimes gets it wrong. That's accurate, but incomplete and misleading. FreeBSD sometimes gets it wrong because it's not possible to always get it right. > Q: Why does FreeBSD sometimes get it wrong? > A: Because FreeBS gets the INT 13 values in the boot loader, but then > discards them in favor of the potentially incorrect CMOS and/or > non-BIOS drive query return values. This is not answering the question. > Q: Why does FreeBSD do this? > A: No one knows. Several, perhaps even many people know. Some of these have tried to explain the problem, but it would appear that you don't actually want to know the answer. One answer is that the values returned by the int13 call in the bootloader may not match the actual layout of the disk. The CMOS values allow the user to override a BIOS that might be getting it wrong. The direct drive query allows a properly-configured disk to be moved from one system to another with a reasonable chance of it still working. > I think that the correspondance can be largely established between > BIOS device and FreeBSD device using sector counts from protected > mode calls vds C*H*S from the BIOS. In the case where they are > equal, it doesn't matter. Where it seems to matter, you can look > for the FreeBSD partition, the DOS boot block to find the boot device, > or, if all else fails, ask the user (instead of asking by default). This is not true. It is not safe to call int13 from protected mode. It is not safe to call most of the BIOS at all without a real-mode 'penalty box' in which you try to look as much like CP/M as possible. See OS/2 for an example of doing this right. It is not sensible to try to match sector counts against c/h/s values from the BIOS in many cases; often the discrepancy can be more than one track multiple out. A signature approach might perhaps be better. The correspondence between FreeBSD device and BIOS device is only significantly relevant with a mixture of SCSI and IDE devices, or multiple SCSI devices on multiple controllers. > Tony Overfield (an engineer from Dell) has gone over this all before, > but since he wants a three stage boot, a lot of his good comments > were thrown out with the bathwater of a three stage boot after no > one came forward to "bell the cat" (write the three stage boot code). Several of us are playing with three-stage bootcode. If you would be so kind as to contribute an ELF loader that understands your segment-colouring stuff, preferably as an 'ld.so' for the kernel, we could move to a boot-time link approach which could take advantage of this. In reality, two versions of the linker will be required; a very stupid version that can load the main kernel object and some set of stipulated objects for inclusion in the stage-3 bootstrap, and a smarter one that should be part of the kernel to replace the current LKM mechanism. The 'stupid' one would need to fit inside the 64K small-model kernel loader module. > 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 Sun Mar 16 20:07:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA18161 for hackers-outgoing; Sun, 16 Mar 1997 20:07:05 -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 UAA18146 for ; Sun, 16 Mar 1997 20:06:38 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id OAA06742; Mon, 17 Mar 1997 14:34:27 +1030 (CST) From: Michael Smith Message-Id: <199703170404.OAA06742@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703170311.NAA06131@genesis.atrad.adelaide.edu.au> from Michael Smith at "Mar 17, 97 01:41:10 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 17 Mar 1997 14:34:27 +1030 (CST) Cc: terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De 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 Michael Smith stands accused of saying: > > > Tony Overfield (an engineer from Dell) has gone over this all before, > > but since he wants a three stage boot, a lot of his good comments > > were thrown out with the bathwater of a three stage boot after no > > one came forward to "bell the cat" (write the three stage boot code). > > Several of us are playing with three-stage bootcode. If you would be so I should perhaps have added that I haven't seen Tony's code, so I can't comment on what he has done. So far I have Bill's hack to the current bootstrap, GRUB and my tinkering with the NetBSD libsa. If anyone else is seriously working on a 3-stage bootstrap, I'd be happy to hear about it. -- ]] 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 Sun Mar 16 21:50:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA21627 for hackers-outgoing; Sun, 16 Mar 1997 21:50:39 -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 VAA21622 for ; Sun, 16 Mar 1997 21:50:35 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27607; Mon, 17 Mar 1997 00:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 17 Mar 1997 00: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 TAA12051 for ; Sun, 16 Mar 1997 19:21:25 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id TAA08627 for freebsd-hackers@freefall.cdrom.com; Sun, 16 Mar 1997 19:27:42 -0500 (EST) Date: Sun, 16 Mar 1997 19:27:42 -0500 (EST) From: Thomas David Rivers Message-Id: <199703170027.TAA08627@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Just to let everyone know I checked :-) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just to let everyone know that I checked for it; and to give my thanks to Jordan for making it happen - the checksums appear to be in the 2.2-RELEASE distribution :-) - Thanks Jordan! - - Dave R. - From owner-freebsd-hackers Sun Mar 16 22:36:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA23540 for hackers-outgoing; Sun, 16 Mar 1997 22:36:09 -0800 (PST) Received: from tarkhil.dialup.aha.ru (ppp90.cityline.ru [194.84.93.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA23495 for ; Sun, 16 Mar 1997 22:35:39 -0800 (PST) Received: from localhost (tarkhil@localhost) by tarkhil.dialup.aha.ru (8.8.5/8.6.9) with SMTP id JAA02121 for ; Mon, 17 Mar 1997 09:10:23 +0300 (MSK) Message-Id: <199703170610.JAA02121@tarkhil.dialup.aha.ru> X-Authentication-Warning: tarkhil.dialup.aha.ru: tarkhil@localhost didn't use HELO protocol X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: Re: fetch through ftp proxy? In-reply-to: Your message of "Sun, 16 Mar 1997 11:53:14 CST." <199703161753.LAA03747@Mars.mcs.net> Reply-To: tarkhil@aha.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Mar 1997 09:10:23 +0300 From: Alex Povolotsky Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703161753.LAA03747@Mars.mcs.net>, Lars Jonas Olsson writes: You seems to connect to HTTP proxy, instead of FTP. Either use FTP proxy or no proxy at all. Alex. > I'm trying to get fetch to work through a netscape proxy server. >I have set FTP_PROCY environment variable and get the following >scrambled error message. > Any ideas? At least there seems to be some error with error messages. >It seems the first 3-4 characters of every line are missing. > >Jonas > >#fetch -v ftp://freefall.cdrom.com/pub/FreeBSD/LOCAL_PORTS/MG.tar.Z >Sending: USER anonymous@freefall.cdrom.com >L>Proxy denies fulfilling the request >Y>

Proxy denies fulfilling the request

> client either is not allowed to access the requested object >ugh this proxy, or the proxy denies requests from your IP address >gether. >Sending: QUIT >fetch: proxy: connection in wrong state > > From owner-freebsd-hackers Mon Mar 17 04:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08788 for hackers-outgoing; Mon, 17 Mar 1997 04:50:38 -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 EAA08781 for ; Mon, 17 Mar 1997 04:50:34 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA18457; Mon, 17 Mar 1997 07:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 17 Mar 1997 07: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 HAA26874 for ; Mon, 17 Mar 1997 07:13:51 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA00311; Mon, 17 Mar 1997 07:19:17 -0500 (EST) Date: Mon, 17 Mar 1997 07:19:17 -0500 (EST) From: Thomas David Rivers Message-Id: <199703171219.HAA00311@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Subject: aha2940 problems in 2.1-STABLE (any by inference, possible 2.2-RELEASE) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - Hoping to circumnavigate my aha2940UW problems in 2.1.6.1 (so I could backup everything to tape for an upgrade to 2.2-RELEASE); I grabbed the /sys from the 2.1-STABLE (post 2.1.7-RELEASE) on ftp.freebsd.org and built a kernel. Much to my dismay; this kernel could not recognize the disk on which I keep the user directories, an older Micropolis 1548. It fails in the probe. The 2.1.6.1 kernel reponds with (from dmesg): ahc0 rev 0 int a irq 15 on pci0:17 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers (ahc0:1:0): "MICROP 1548-15MZ1077802 HZ2P" type 0 fixed SCSI 1 sd1(ahc0:1:0): Direct-Access 1635MB (3349512 512 byte sectors) (ahc0:2:0): "WANGTEK 5150ES SCSI FA23 08" type 1 removable SCSI 1 st0(ahc0:2:0): Sequential-Access drive offline (ahc0:3:0): "NEC CD-ROM DRIVE:400 1.0" type 5 removable SCSI 2 cd0(ahc0:3:0): CD-ROM cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present can't get the size (Note the (ahc0:1:0) lines). However, the 2.1-STABLE (post 2.1.7) kernel responds in almost exactly the same manor, with one difference: (ahc0:1:0) ABORTED COMMAND asc:49,0 Invalid message error and thus, that SCSI disk isn't added to the list of configured devices... So, I can't reference it to make a tape to do a backup.... (bummer) I imagine this occurs with 2.2-RELEASE as well (since these two now have similar aic7870 drivers - or am I mistaken.) But I haven't tried it. I will add that a 2.2-GAMMA release in January did not have this particular problem; as I verified that my SCSI tape problems were corrected with it... - Dave Rivers - From owner-freebsd-hackers Mon Mar 17 05:18:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09630 for hackers-outgoing; Mon, 17 Mar 1997 05:18: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 FAA09625 for ; Mon, 17 Mar 1997 05:18:00 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA12416; Tue, 18 Mar 1997 00:11:03 +1100 Date: Tue, 18 Mar 1997 00:11:03 +1100 From: Bruce Evans Message-Id: <199703171311.AAA12416@godzilla.zeta.org.au> To: dgy@rtd.com, terry@lambert.org Subject: Re: wd driver questions Cc: bde@zeta.org.au, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Yes, I don't understand why FBSD can't just use the same geometry >settings that boot.c deduces? Are the BIOS ROMs no longer accessible >once boot() has completed (sorry, my ignorance is showing...)? The ROMs are completely inaccessible, but that isn't the problem since the geometry of all drives known to the BIOS (actually, only the first 10) is passed from boot.c to the kernel. The problems are: 1. some drives may not be known to the BIOS 2. the kernel has no way of knowing to correspondence between BIOS drive numbers and FreeBSD drive names. It could do the same thing as boot.c, which is to guess, and if the guess doesn't work then require the user to type in the correspondence, e.g., 1:sd(0,a) ^ ^^^^ (BIOS drive number 1 = FreeBSD drive name sd0) boot.c could pass the mapping for the boot drive, but the kernel would have to do it for the other drives. This is not much simpler for users than just typing in the correct geometry. >> equal, it doesn't matter. Where it seems to matter, you can look >> for the FreeBSD partition, the DOS boot block to find the boot device, >> or, if all else fails, ask the user (instead of asking by default). > >Why *should* there be a difference? I would assume that you would >err on the side of adhering to the BIOS geometry -- wouldn't >adopting some *other* geometry make it tough (impossible?) >to have a DOS partition on the same drive as FBSD and be able to >*access* that DOS partition from FBSD? The driver just uses the geometry reported by the drive. This is simple and works in all known cases where the drive reports it geometry. There is no reason to use the same geometry as the BIOS and many reasons not to (e.g., the BIOS can't handle more than 1024 cylinders and some BIOSes can't translate so that there are <= 1024 cylineders, and some translations waste a lot of disk space, and translation is impossible for disks larger than about 8GB (except by wasting everything above 8GB)). >> Also if it is writing C/H/S values for use by the DOS MBR to get to >> the BSD second stage boot, since the DOS MBR (incorrectly) looks at >> the C/H/S values instead of the LBA values (since the DOS MBR has the >> DOS geometry available, factoring an LBA to a C/H/S value is easy for >> it to do, but it is too badly designed to do that). > >I think this is the problem I've currently been having -- DOS thinks >the drive is 611/16/63 but FBSD reINITs it to 790/15/57. It's been >tough trying to get DOS and FBSD to fit onto the same drive... I don't see any problem. The BIOS geometry is 611/16/63 for some reason (probably the BIOS is old and can't translate to > 16 heads). You must use the BIOS geometry in fdisk. The geometry used elsewhere is almost arbitrary. The driver uses 790/15/57 for simplicity. It prints 790/15/57 because that's the only one that it knows about. Don't use this in fdisk if it differs from the BIOS geometry. OTOH, you may note that the BIOS goemetry wastes about 30MB: 790*15*57 = 675450 611*16*63 = 615888 wasted = 59562 You can probably use these sectors for a non-DOS non-bootable partition by telling fdisk that the geometry is 612/16/63 and being careful not to use the nonexistent part of the last "cylinder". Your probably may actually be that the drive is jumpered to force 611/16/63 and broken so that it still reports 790/15/57. Some ESDI drives had this problem. I hope they are dead now (one I bought in 1990 cost 4 times as much as a modern IDE drive for 1/12 as much space, 1/10 as much performance, and 1/10 as much reliability). Bruce From owner-freebsd-hackers Mon Mar 17 05:52:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA11143 for hackers-outgoing; Mon, 17 Mar 1997 05:52:46 -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 FAA11138 for ; Mon, 17 Mar 1997 05:52:42 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA13488; Tue, 18 Mar 1997 00:46:39 +1100 Date: Tue, 18 Mar 1997 00:46:39 +1100 From: Bruce Evans Message-Id: <199703171346.AAA13488@godzilla.zeta.org.au> To: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Subject: Re: wd and funky geometry (understood?) Cc: bde@zeta.org.au, joerg_wunsch@uriah.heep.sax.de Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The problem appears to an inconsistent use of geometry information >for each drive. During IPL, the drive is INITed with parameters from the >BIOS's disk parameter table. This makes sense as I can't imagine any >*other* place from which to get the disk geometry (reliably). From >boot() in /usr/src/sys/i386/boot/biosboot/boot.c: >... > However, in wdattach(), wdgetctlr() is invoked to get the drive's >geometry. It does this by issuing an IDENTIFY command (i.e. READP) >to the drive. The data returned by the command is interpreted as >a wdparams structure: >... >Herein lies the problem: these parameters reflect "the default geometry of >the device" (paraphrased from the ATA specification). However, the BIOS's >geometry may *NOT* agree with the drives "default geometry". For example, >the probe of my IDE drives yields: > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 329MB (675450 sectors), 790 cyls, 15 heads, 57 S/T, 512 B/S > wdc0: unit 1 (wd1): > wd1: 321MB (659232 sectors), 654 cyls, 16 heads, 63 S/T, 512 B/S > >However, *both* drives have a BIOS geometry of 611/16/63. (Sorry, >my ancient BIOS does not support "user configurable" geometries >so this was the closest geometry I could find -- hence the reason What's the problem? The BIOS uses the fudged geometry that you told it, but the FreeBSD driver knows better - there is no reason for it to use a fudged geometry. >Why is all this a problem? I don't *think* it causes any problems >during IPL -- since the drive is INITed with the BIOS geometry >during the boot and then switched to the "default geometry" >during the attach/open. I think that the image loaded from the >disk during boot is small enough that changes to the size/shape >of the first track are safely ignored. (though, on second thought, >I suspect this *can* screw you if your FBSD partition does not >begin at the start of the disk! Comments?) > >However, sharing a partition might be a problem since DOS's >FDISK (which you used to create the DOS partition) will talk >to a disk shaped per the BIOS geometry. Of course you must use a consistently fudged geometry for everything related to the BIOS. >When FBSD takes over, >the geometry of the disk is changed and track/cylinder boundaries >can "move" (e.g., consider my case with a default geometry >of 57 S/C vs. the BIOS's 63 S/C). The FreeBSD is unrelated to the BIOS. It doesn't even notice when the boundaries move. >And, switching to/from DOS can screw you. Consider DOS and >FBSD sharing wd0. FBSD reINITs the drive to use it's default >geometry. Then, you mount a DOS partition FROM THE SAME DRIVE! >The layout of the DOS partition expected the BIOS geometry >yet the disk is now accessed using the FBSD geometry. No problem. If you mount the partition under FreeBSD, msdosfs ignores everything related to geometries. If you reboot and "mount" the partition under DOS, then the BIOS reinitializes the geometry on reboot. >I suspect that LBA *could* be a redeeming grace. However, I don't Nope. >know enough about the *guarantees* within the drive to determine >if a particular sector address will *allways* map to the same >(PHYSICALLY EQUIVALENT) sector regardless of geometry (i.e., >will sector "97" in a 611/16/63 geometry correspond to the >exactl same physical sector when the drive is configured for >790/15/57??) This is already guaranteed as follows: pick a geometry. Any physically reasonable geometry will work with a modern IDE drive (but note that BIOS geometries are usually not physically reasonable with modern BIOSes for modern (non-small) IDE drives). Then issue a WDCC_IDC command to tell the controller to translate using that geometry. Then do all translations from blkno's to C/H/S values using that geometry. The driver could use LBA mode for modern drives, but that would complicate the driver for little or negative benefit - it would still have to do the translation for old drives. >[someone who really *knows* what they are talking about could probably >determine the *real* effects of all this :-( ] Users get confused :-(. Bruce From owner-freebsd-hackers Mon Mar 17 06:31:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA12621 for hackers-outgoing; Mon, 17 Mar 1997 06:31:01 -0800 (PST) Received: from ceniai.inf.cu ([169.158.128.138]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA12616 for ; Mon, 17 Mar 1997 06:30:58 -0800 (PST) Received: from comuh.uh.cu by ceniai.inf.cu with UUCP (Smail3.1.29.1) id m0w6Ym1-0002OcC; Mon, 17 Mar 97 09:32 Received: by comuh.uh.cu (5.65/1.2-eef) id AA22219; Mon, 17 Mar 97 09:26:43 -0500 Date: Mon, 17 Mar 1997 09:26:43 -0500 (EST) From: Ignacio Machin Rdguez X-Sender: machin@comuh To: hackers@freebsd.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk who freebsd unsubscribe From owner-freebsd-hackers Mon Mar 17 07:27:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA14802 for hackers-outgoing; Mon, 17 Mar 1997 07:27:11 -0800 (PST) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA14797 for ; Mon, 17 Mar 1997 07:26:57 -0800 (PST) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id CAA03732 for hackers@freebsd.org; Tue, 18 Mar 1997 02:26:42 +1100 From: Darren Reed Message-Id: <199703171526.CAA03732@plum.cyber.com.au> Subject: dds tape drives. To: hackers@freebsd.org Date: Tue, 18 Mar 1997 02:26:41 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Looking at my dds drive under 2.1.6, I see this when it probes at boot: (ahc0:4:0): "WANGTEK 6130-HS 4G16" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x13, drive empty (the drive wasn't empty, btw...) now, if I do an "mt status", I see the following: Present Mode: Density = X3B5/88-185A Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = 0x00 Blocksize variable Mode 2: Density = 0x00 Blocksize variable Mode 3: Density = 0x00 Blocksize variable how do I use the different density codes, if at all, that are alluded to by "density code 0x13" ? also, is anyone working on making "mt status" return something like what you get on SunOS4: /dev/nrst0: no tape loaded or drive offline and Exabyte EXB-8200 8mm tape drive: sense key(0x6)= unit attention residual= 0 retries= 0 file no= 0 block no= 0 - I'm sure you can see the difference in usefulness. Darren From owner-freebsd-hackers Mon Mar 17 07:51:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA16281 for hackers-outgoing; Mon, 17 Mar 1997 07:51:35 -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 HAA16276 for ; Mon, 17 Mar 1997 07:51:31 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id IAA11675; Mon, 17 Mar 1997 08:48:28 -0700 (MST) From: Don Yuniskis Message-Id: <199703171548.IAA11675@seagull.rtd.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Mon, 17 Mar 1997 08:48:28 -0700 (MST) Cc: dgy@rtd.com, terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703171311.AAA12416@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 00:11: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 It seems that Bruce Evans said: > > >Yes, I don't understand why FBSD can't just use the same geometry > >settings that boot.c deduces? Are the BIOS ROMs no longer accessible > >once boot() has completed (sorry, my ignorance is showing...)? > > The ROMs are completely inaccessible, but that isn't the problem since > the geometry of all drives known to the BIOS (actually, only the first > 10) is passed from boot.c to the kernel. The problems are: Hmmm... I thought only the drives *configured* were passed along (i.e. two drives on each of two controllers)? > 1. some drives may not be known to the BIOS Hmmm... perhaps I'm thinking too much of DOS compatibility, etc. I guess one *could* hang a drive on a machine that DOS could NEVER access (i.e. not "*would*" but "*could*"). Lately I'm more focussed on getting DOS and FBSD to coexist so that's where my head is at... > 2. the kernel has no way of knowing to correspondence between BIOS drive > numbers and FreeBSD drive names. It could do the same thing as boot.c, Huh? I thought wd0 was the first drive (i.e. the IDE "master") on the first controller, wd1 was the "slave" on that controller, etc. Ahhhh... this isn't *guaranteed* to be the case? > which is to guess, and if the guess doesn't work then require the user > to type in the correspondence, e.g., > > 1:sd(0,a) > ^ ^^^^ (BIOS drive number 1 = FreeBSD drive name sd0) > > boot.c could pass the mapping for the boot drive, but the kernel would > have to do it for the other drives. This is not much simpler for users > than just typing in the correct geometry. > > >> equal, it doesn't matter. Where it seems to matter, you can look > >> for the FreeBSD partition, the DOS boot block to find the boot device, > >> or, if all else fails, ask the user (instead of asking by default). > > > >Why *should* there be a difference? I would assume that you would > >err on the side of adhering to the BIOS geometry -- wouldn't > >adopting some *other* geometry make it tough (impossible?) > >to have a DOS partition on the same drive as FBSD and be able to > >*access* that DOS partition from FBSD? > > The driver just uses the geometry reported by the drive. This is simple > and works in all known cases where the drive reports it geometry. There > is no reason to use the same geometry as the BIOS and many reasons not > to (e.g., the BIOS can't handle more than 1024 cylinders and some BIOSes > can't translate so that there are <= 1024 cylineders, and some translations > waste a lot of disk space, and translation is impossible for disks larger > than about 8GB (except by wasting everything above 8GB)). > > >> Also if it is writing C/H/S values for use by the DOS MBR to get to > >> the BSD second stage boot, since the DOS MBR (incorrectly) looks at > >> the C/H/S values instead of the LBA values (since the DOS MBR has the > >> DOS geometry available, factoring an LBA to a C/H/S value is easy for > >> it to do, but it is too badly designed to do that). > > > >I think this is the problem I've currently been having -- DOS thinks > >the drive is 611/16/63 but FBSD reINITs it to 790/15/57. It's been > >tough trying to get DOS and FBSD to fit onto the same drive... > > I don't see any problem. The BIOS geometry is 611/16/63 for some reason > (probably the BIOS is old and can't translate to > 16 heads). You must [if you look at the actual geometry -- 790/15/57 -- it has nothing to do with translating for > 16 heads or "EIDE" stuff. Rather, the BIOS just doesn't support a "user configurable" disk type so I'm stuck with whatever was hardcoded into the ROMs -- hence the reason I'm reburning the system ROMs! :>] > use the BIOS geometry in fdisk. The geometry used elsewhere is almost > arbitrary. The driver uses 790/15/57 for simplicity. It prints 790/15/57 > because that's the only one that it knows about. Don't use this in fdisk > if it differs from the BIOS geometry. OTOH, you may note that the BIOS > goemetry wastes about 30MB: > > 790*15*57 = 675450 > 611*16*63 = 615888 > wasted = 59562 Yes, I have been aware of that for far too long :-( Each machine has a pair of 4G SCSI drives so the 30M I lose on the IDE drives is pretty insignificant. > You can probably use these sectors for a non-DOS non-bootable partition > by telling fdisk that the geometry is 612/16/63 and being careful not > to use the nonexistent part of the last "cylinder". > > Your probably may actually be that the drive is jumpered to force > 611/16/63 and broken so that it still reports 790/15/57. Some ESDI No, the native drive geometry is 790/15/57. It is INITed by the BIOS to 611/16/63. This is the geometry that it actually *uses*. The IDENTIFY command returns the *default* geometry **AND** the *apparent* geometry. The existing code ignores the apparent geometry in favor of the default geometry (in fact, the wdparams struct doesn't even acknowledge the presence of the apparent geometry parameters). As such, the drive is doing exactly what it is supposed to do -- reporting it's *default* geometry even though it is configured with a different geometry. > drives had this problem. I hope they are dead now (one I bought in > 1990 cost 4 times as much as a modern IDE drive for 1/12 as much space, > 1/10 as much performance, and 1/10 as much reliability). Yes. I guess if you *really* want the best deal, you should *never* buy anything -- since it will always get better and cheaper! :> I think I paid the same for my 4G SCSI drives as I did for the 300M IDE drives! :-( I wasn't suggesting anything other than using the *apparent* device geometry figures to determine the drive's geometry. My thinking was that the current geometry of the drive would be reflected therein. --don From owner-freebsd-hackers Mon Mar 17 09:54:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA22845 for hackers-outgoing; Mon, 17 Mar 1997 09:54:48 -0800 (PST) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA22840 for ; Mon, 17 Mar 1997 09:54:41 -0800 (PST) Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id ma001260 for ; Sun, 16 Mar 1997 10:16:10 +0000 Message-ID: <332BC869.37B7@wgold.demon.co.uk> Date: Sun, 16 Mar 1997 10:16:09 +0000 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Barb problem, FOUND References: <199703160612.XAA13150@rover.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In no way shape or form is an inline virtual function (destructor or not) 'dunious'. Its quite legal. (Whether you might consider it to be bad style is another matter. You can't always avoid it if the class is a template, though that's clearly not the case with tvision) Bear in mind that smart C++ systems will merge duplicated static emitted inlines whether they are emitted as a result of too much complexity or through being vritual. Further, such 'outlined' virtuals need only be emitted in the module chosen to carry the vtable, and will only potentially bloat if there is no convenient method to tag the vtable to. If the compiler cannot handle code like this, then the compiler should be fixed. James Warner Losh wrote: > > {standard input}: Assembler messages: > {standard input}:1147: Warning: GOT relocation burb: `__vt$5TNode' should be global > > OK. The problem here is trivial to reproduce. > > All of the members of TNode are virtual. Even the dtor, and it is > specifically inline (which is a major no-no for virtual dtors (and > virtual functions in general) because most compiler give multiple > copies). > > This message should really read > > "TNode::~TNode is an inline virtual function, and I don't know how to > cope, so fix the dubious construct in the code, OK" > > In the case of tvision 0.3, I see it for each of the classes that have > virtual inline functions, but it reports the wrong function name. > > Comments? > > Warner From owner-freebsd-hackers Mon Mar 17 10:12:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA24374 for hackers-outgoing; Mon, 17 Mar 1997 10:12:55 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24369 for ; Mon, 17 Mar 1997 10:12:51 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.5/8.8.5) id MAA27625; Mon, 17 Mar 1997 12:12:33 -0600 (CST) Date: Mon, 17 Mar 1997 12:12:33 -0600 (CST) From: Mark Tinguely Message-Id: <199703171812.MAA27625@plains.nodak.edu> To: darrenr@cyber.com.au, hackers@freebsd.org Subject: Re: dds tape drives. Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk a long time ago, I added the files and block counts to the /sys/scsi/st.c (basically you add/subtract after every read/write/movement command -- watch out for command residuals). The scsi maintainers of the time did not choose to add the changes, and around FreeBSD 2.0.5, I got tired of manually editing them after every OS change and I quit. I don't even have one copy of the changes. --mark. From owner-freebsd-hackers Mon Mar 17 10:15:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA24488 for hackers-outgoing; Mon, 17 Mar 1997 10:15:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24483 for ; Mon, 17 Mar 1997 10:15:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08120; Mon, 17 Mar 1997 11:04:25 -0700 From: Terry Lambert Message-Id: <199703171804.LAA08120@phaeton.artisoft.com> Subject: Re: wd driver questions To: dgy@rtd.com (Don Yuniskis) Date: Mon, 17 Mar 1997 11:04:24 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703170237.TAA17617@seagull.rtd.com> from "Don Yuniskis" at Mar 16, 97 07:37:40 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 > > Q: Why does FreeBSD sometimes get it wrong? > > A: Because FreeBS gets the INT 13 values in the boot loader, but then > > discards them in favor of the potentially incorrect CMOS and/or > > non-BIOS drive query return values. > > Yes, I don't understand why FBSD can't just use the same geometry > settings that boot.c deduces? Are the BIOS ROMs no longer accessible > once boot() has completed (sorry, my ignorance is showing...)? Yes. They are no longer accessable. Or, in particular, you are not able to make INT 13 calls once you are in protected mode because there is not VM86() support for doing so. As Bruce explained, there is no way to establish a correspondance between BIOS device number (for which you have obtained a BIOS geometry, the "correct" geometry) and a FreeBSD device. What he didn't explain is that this is because the BIOS device order is a result of BIOS POST order for the controllers and the devices, which hook INT 13, and the FreeBSD device order is a result of probe order, generally a result of the config file lines with which the kernel is built. Because people plug things into the bus in whatever order they feel like, there is no way to buld a kernel that is guaranteed to probe devices in the same order that INT 13 is chained. As a matter of fact, you can't even guaranteed that a device with an INT 13 chain-in even *has* a FreeBSD driver at all, so you may be out of order no matter what you do (this is why I'm always calling for "a fallback driver using VM86()"). > > I think that the correspondance can be largely established between > > BIOS device and FreeBSD device using sector counts from protected > > mode calls vds C*H*S from the BIOS. In the case where they are > > equal, it doesn't matter. Where it seems to matter, you can look > > for the FreeBSD partition, the DOS boot block to find the boot device, > > or, if all else fails, ask the user (instead of asking by default). > > Why *should* there be a difference? I would assume that you would > err on the side of adhering to the BIOS geometry -- wouldn't > adopting some *other* geometry make it tough (impossible?) > to have a DOS partition on the same drive as FBSD and be able to > *access* that DOS partition from FBSD? Yes, that's true; coeexistance is impossible. Tony Overfield of Dell has stated in no uncertain terms that FreeBSD is incapable of installing on an increasing number of Dell systems because of this discrepancy (which arises out of big disks and their use of the "service pack 2" (OEMSR2) Win95 VFAT32 code). They *require* INT 13 LBA INIT'ing of the drive. The reason there *should* be a difference is explained above: we can't tell which INT 13 drive ID goes with which disk probed by FreeBSD. > > The correspondance problem is the hardest to solve, given the 7k or > > so second stage BIOS boot block limit. > > [I'm lost, here... <:-( ] See above. 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 Mar 17 10:41:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA26043 for hackers-outgoing; Mon, 17 Mar 1997 10:41:17 -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 KAA26031 for ; Mon, 17 Mar 1997 10:41:11 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id FAA22959; Tue, 18 Mar 1997 05:35:57 +1100 Date: Tue, 18 Mar 1997 05:35:57 +1100 From: Bruce Evans Message-Id: <199703171835.FAA22959@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: wd driver questions Cc: hackers@freebsd.org, helbig@MX.BA-Stuttgart.De, terry@lambert.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The ROMs are completely inaccessible, but that isn't the problem since >> the geometry of all drives known to the BIOS (actually, only the first >> 10) is passed from boot.c to the kernel. The problems are: > >Hmmm... I thought only the drives *configured* were passed along >(i.e. two drives on each of two controllers)? 10 always. Some might be SCSI drives. >> 1. some drives may not be known to the BIOS > >Hmmm... perhaps I'm thinking too much of DOS compatibility, etc. I >guess one *could* hang a drive on a machine that DOS could NEVER access >(i.e. not "*would*" but "*could*"). Lately I'm more focussed on getting >DOS and FBSD to coexist so that's where my head is at... It used to be normal for the BIOS to support more than 1 IDE controllers. FreeBSD has always supported any number of IDE controllers, and systems with 2 IDE controllers are now common. >> 2. the kernel has no way of knowing to correspondence between BIOS drive >> numbers and FreeBSD drive names. It could do the same thing as boot.c, > >Huh? I thought wd0 was the first drive (i.e. the IDE "master") on the first >controller, wd1 was the "slave" on that controller, etc. > >Ahhhh... this isn't *guaranteed* to be the case? Yes, but BIOS drive 0 is just the first drive found. It may be wd2 if there is nothing on the first controller. Then there are SCSI drives. >> I don't see any problem. The BIOS geometry is 611/16/63 for some reason >> (probably the BIOS is old and can't translate to > 16 heads). You must > >[if you look at the actual geometry -- 790/15/57 -- it has nothing to >do with translating for > 16 heads or "EIDE" stuff. Rather, the BIOS >just doesn't support a "user configurable" disk type so I'm stuck with >whatever was hardcoded into the ROMs -- hence the reason I'm reburning >the system ROMs! :>] OK. The BIOS's lack of translation is only a problem when the 16/63 translation gives more than 1024 (translated) cylinders. >> use the BIOS geometry in fdisk. The geometry used elsewhere is almost >> arbitrary. The driver uses 790/15/57 for simplicity. It prints 790/15/57 >> because that's the only one that it knows about. Don't use this in fdisk >> if it differs from the BIOS geometry. OTOH, you may note that the BIOS >> goemetry wastes about 30MB: >> >> 790*15*57 = 675450 >> 611*16*63 = 615888 >> wasted = 59562 > >Yes, I have been aware of that for far too long :-( Each machine has a pair >of 4G SCSI drives so the 30M I lose on the IDE drives is pretty insignificant. So is the 2*300MB on the drives :-). >> You can probably use these sectors for a non-DOS non-bootable partition >> by telling fdisk that the geometry is 612/16/63 and being careful not >> to use the nonexistent part of the last "cylinder". Oops, there is more than one "cylinder" past the last, and only a small amount of the wastage is on the partial cylinder. 790*15*57 / (16*63) = 670 so you have 670 full "cylinders" to use. You can probably use all these cylinders, perhaps even for DOS and bootable partitions by telling fdisk that the geometry is 670/16/63 and not using the partial cylinder. This depends on the softare being either stupid enough to not check cylinder numbers against the 612 limit or smart enough to know that this limit is wrong. >> Your probably may actually be that the drive is jumpered to force problem >> 611/16/63 and broken so that it still reports 790/15/57. Some ESDI > >No, the native drive geometry is 790/15/57. It is INITed by the >BIOS to 611/16/63. This is the geometry that it actually *uses*. >The IDENTIFY command returns the *default* geometry **AND** the >*apparent* geometry. The existing code ignores the apparent >geometry in favor of the default geometry (in fact, the wdparams >struct doesn't even acknowledge the presence of the apparent geometry >parameters). This is because the driver only knows about old standards where the apparent geometry parameters didn't exist. Using these parameters would either break the support for old drives or complicate the driver (it's not easy to determine drive capabilities, because old standards didn't have reliable capability bits). >As such, the drive is doing exactly what it is supposed >to do -- reporting it's *default* geometry even though it is configured >with a different geometry. And the driver is doing exactly what it is supposed to do - ignoring the current geometry. Bruce From owner-freebsd-hackers Mon Mar 17 10:47:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA26337 for hackers-outgoing; Mon, 17 Mar 1997 10:47:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26327 for ; Mon, 17 Mar 1997 10:46:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08169; Mon, 17 Mar 1997 11:35:00 -0700 From: Terry Lambert Message-Id: <199703171835.LAA08169@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 17 Mar 1997 11:35:00 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703170311.NAA06131@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 17, 97 01:41: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 > > Q: Why are the users permitted to override geometry? > > A: Because FreeBSD sometimes gets it wrong. > > That's accurate, but incomplete and misleading. FreeBSD sometimes gets it > wrong because it's not possible to always get it right. Bullshit. It is possible to get it right. You may have to rewrite a scratch area of a disk in order to do it, but it's possible. Windows95 does it just fine. It may be accurate to state that "it's hard for FreeBSD to get it right, but with slight modifications, FreeBSD could get it right in the vast majority of cases, and appeal to the user for the rest. I'm sure that this will come down to machines with identical drives that someone has duplicated with dd and which have identical defect lists for whatever reason. An unlikely case. > > Q: Why does FreeBSD sometimes get it wrong? > > A: Because FreeBS gets the INT 13 values in the boot loader, but then > > discards them in favor of the potentially incorrect CMOS and/or > > non-BIOS drive query return values. > > This is not answering the question. Yes it is. If FreeBSD did not discard the boot loader values, it would have the "correct" geometry for the device. The "correctness" of the geometry is a result of: 1) Being able to determine the absolute sector offset for a given C/H/S value in the partition table. 2) Being able to, from protected mode, write a DOS partition table C/H/S value so that when the DOS MBR goes to that C/H/S location and reads a track, it gets the FreeBSD second stage boot. 3) The FreeBSD kernel (which should use the LBA address, not the C/H/S address) being able to turn the C/H/S address back into an absolute sector offset. > > Q: Why does FreeBSD do this? > > A: No one knows. > > Several, perhaps even many people know. Some of these have tried to explain > the problem, but it would appear that you don't actually want to know the > answer. > > One answer is that the values returned by the int13 call in the bootloader > may not match the actual layout of the disk. The CMOS values allow the > user to override a BIOS that might be getting it wrong. The direct drive > query allows a properly-configured disk to be moved from one system to > another with a reasonable chance of it still working. As long as you have no other OS's on the drive which don't re-INIT the drive as well. If you have read the VFAT32 specification that came on the OEMSR2 CDROM from Microsoft, you know that the code looks at the partition data of the disk in order to determine the geometry (just like the NCR BIOS does in order to make other SCSI controller geometries OK for the NCR controller). > > I think that the correspondance can be largely established between > > BIOS device and FreeBSD device using sector counts from protected > > mode calls vds C*H*S from the BIOS. In the case where they are > > equal, it doesn't matter. Where it seems to matter, you can look > > for the FreeBSD partition, the DOS boot block to find the boot device, > > or, if all else fails, ask the user (instead of asking by default). > > This is not true. > > It is not safe to call int13 from protected mode. It is not safe to call > most of the BIOS at all without a real-mode 'penalty box' in which you > try to look as much like CP/M as possible. See OS/2 for an example of > doing this right. The INT 13 in question is called in the FreeBSD second stage boot block after switching back to real mode for the call (this is an artifact of the MACH boot blocks, which could switch back to real mode without penalty). Check the boot block code if you don't believe me. > It is not sensible to try to match sector counts against c/h/s values > from the BIOS in many cases; often the discrepancy can be more than > one track multiple out. A signature approach might perhaps be better. o Multiply the C/H/S geometry of the INT 13 ID's in question by the C/H/S limit values to get the absolute drive size. Compare the size against the IDENTIFY size. This will establish disk identity in the vast majority of cases. o Multiply the C/H/S geometry of the INT 13 ID's in question by the C/H/S value from the partition table for bootable OS types, starting with FreeBSD and MS OS's, and look for the "bootable signature" word that the DOS MBR looks for to establish disk identity. This will cover the vast majority of the remaining cases. o Modify the second stage boot to fill in the correct LBA address in the DOS partition table for a given C/H/S value at boot time; have BSD *always* use the LBA values in protected mode and *always* use the C/H/S values in the INT 13 using boot code. This should cover all other cases except where the drive is identical. o When the drive is identical, ask the user the first time the protected mode kernel is run, before root is mounted, which device is correct. Record this value in the "bootbias" in the second stage boot block *after* a successful mount of the root FS. Never ask again(*). (*) Ideally, this last would not be necessary if the root mount modifications I submitted in June of 1994 were integrated, since multiple root mounts could be attempted, and the one which was successful could be taken as the right one. In the case of identical disk devices, the "last mounted" time stamp should be examined, and the most recent one taken, and/or the drive serial number should be recorded in the boot block and retrieved using IDENTIFY or SCSI operands on the devices before they are booted, so that subsequent mounts following a duplication including timestamp would not fail. > The correspondence between FreeBSD device and BIOS device is only > significantly relevant with a mixture of SCSI and IDE devices, or > multiple SCSI devices on multiple controllers. It's relevant when there are two or more devices in the system which may be identical except for the INT 13 drive ID. > > Tony Overfield (an engineer from Dell) has gone over this all before, > > but since he wants a three stage boot, a lot of his good comments > > were thrown out with the bathwater of a three stage boot after no > > one came forward to "bell the cat" (write the three stage boot code). > > Several of us are playing with three-stage bootcode. If you would be so > kind as to contribute an ELF loader that understands your segment-colouring > stuff, preferably as an 'ld.so' for the kernel, we could move to a > boot-time link approach which could take advantage of this. What's wrong with Erich's code to do this? > In reality, two versions of the linker will be required; a very stupid > version that can load the main kernel object and some set of stipulated > objects for inclusion in the stage-3 bootstrap, and a smarter one that > should be part of the kernel to replace the current LKM mechanism. > > The 'stupid' one would need to fit inside the 64K small-model kernel > loader module. I don't see why the stupid one could not be the same as the smart one, as long as you were willing to establish PM mappings for it. As for segment loading, the most interesting method would be to put modules in seperate ELF segments in the kernel image itself, jamming them in or yanking them out at will. The segment coloring is only useful in this case if your defautl drivers for the console, etc. are colored differently than the rest of the kernel to allow them to be distinguished (and dumped at will for replacement). Given this, then a "boot" coloring (see the Microsoft Developer Network document on the Portable Executable format for ELF segment coloring) could get loaded leaving the rest for later. If you read the Schulman book on Win95, this is actually how Windows95 loads its VXD's and other pieces... only we don't have an IO.SYS that understands our file system (well, we don't have a publically available one, anyway). 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 Mar 17 10:49:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA26792 for hackers-outgoing; Mon, 17 Mar 1997 10:49:21 -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 KAA26783 for ; Mon, 17 Mar 1997 10:49:17 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.4) id NAA00797; Mon, 17 Mar 1997 13:49:12 -0500 (EST) Date: Mon, 17 Mar 1997 13:49:12 -0500 (EST) From: Charles Henrich Message-Id: <199703171849.NAA00797@crh.cl.msu.edu> To: ponds!rivers@dg-rtp.dg.com, freebsd-hackers@freebsd.org Subject: Re: aha2940 problems in 2.1-STABLE (any by inference, possible 2.2-RELE Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ASE) Newsgroups: lists.freebsd.hackers References: <5gjflq$dhj$1@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #1 (NOV) In lists.freebsd.hackers you write: >Well - > Hoping to circumnavigate my aha2940UW problems in 2.1.6.1 (so I could >backup everything to tape for an upgrade to 2.2-RELEASE); I grabbed >the /sys from the 2.1-STABLE (post 2.1.7-RELEASE) on ftp.freebsd.org >and built a kernel. > Much to my dismay; this kernel could not recognize the disk on which >I keep the user directories, an older Micropolis 1548. It fails in the >probe. > The 2.1.6.1 kernel reponds with (from dmesg): > ahc0 rev 0 int a irq 15 on pci0:17 > ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs > ahc0 waiting for scsi devices to settle > (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) > ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers The quick and dirty solution is to go into your adaptec controller setup and turn off wide negotiation on your narrow devices (I've had this same problem for some time now) -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Mon Mar 17 10:52:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27009 for hackers-outgoing; Mon, 17 Mar 1997 10:52:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26988 for ; Mon, 17 Mar 1997 10:51:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08195; Mon, 17 Mar 1997 11:41:00 -0700 From: Terry Lambert Message-Id: <199703171841.LAA08195@phaeton.artisoft.com> Subject: Re: wd driver questions To: bde@zeta.org.au (Bruce Evans) Date: Mon, 17 Mar 1997 11:41:00 -0700 (MST) Cc: dgy@rtd.com, terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703171311.AAA12416@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 00:11: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 > Your problem may actually be that the drive is jumpered to force > 611/16/63 and broken so that it still reports 790/15/57. Some ESDI > drives had this problem. I hope they are dead now (one I bought in > 1990 cost 4 times as much as a modern IDE drive for 1/12 as much space, > 1/10 as much performance, and 1/10 as much reliability). Actually, the ESDI drives did not understand translation. This was an artifact of the controller. The most notorious of these was the WD1007 ESDI controller. When jumpered for sector sparing, it reported the disk geometry without the sector sparing enabled, which caused all sorts of problems. Basically, it lied. The fix is to disable sector sparing, and use BAD144 sector sparing instead. This is a pain in the butt if the drive is shared between DOS and BSD, since you can't safely change the settings. The NetBSD install allowed you to override the probed geometry at the start; the FreeBSD did not. So both could fdisk, but FreeBSD could not mkfs. For what it's worth: they aren't all dead yet. 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 Mar 17 10:55:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27109 for hackers-outgoing; Mon, 17 Mar 1997 10:55:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27103 for ; Mon, 17 Mar 1997 10:54:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08211; Mon, 17 Mar 1997 11:43:45 -0700 From: Terry Lambert Message-Id: <199703171843.LAA08211@phaeton.artisoft.com> Subject: Re: wd and funky geometry (understood?) To: bde@zeta.org.au (Bruce Evans) Date: Mon, 17 Mar 1997 11:43:45 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org, bde@zeta.org.au, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199703171346.AAA13488@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 00:46: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 > >However, *both* drives have a BIOS geometry of 611/16/63. (Sorry, > >my ancient BIOS does not support "user configurable" geometries > >so this was the closest geometry I could find -- hence the reason > > What's the problem? The BIOS uses the fudged geometry that you told it, > but the FreeBSD driver knows better - there is no reason for it to use > a fudged geometry. The disk is shared with DOS and uses the DOS MBR. THe DOS MBR will use the fudged geometry, and the BSD DOS partition table entry must be in the fudged geometry to make the DOS MBR happy to boot it. > Of course you must use a consistently fudged geometry for everything > related to the BIOS. Like multiplying the C/H/S value by the fudged geometry in protected mode to find the BSD boot and disktab data. 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 Mar 17 10:56:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27275 for hackers-outgoing; Mon, 17 Mar 1997 10:56: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 ESMTP id KAA27269 for ; Mon, 17 Mar 1997 10:56:47 -0800 (PST) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.8.5/8.6.6) with ESMTP id LAA07505; Mon, 17 Mar 1997 11:56:39 -0700 (MST) Message-Id: <199703171856.LAA07505@rover.village.org> To: James Mansion Subject: Re: Barb problem, FOUND Cc: hackers@freebsd.org In-reply-to: Your message of "Sun, 16 Mar 1997 10:16:09 GMT." <332BC869.37B7@wgold.demon.co.uk> References: <332BC869.37B7@wgold.demon.co.uk> <199703160612.XAA13150@rover.village.org> Date: Mon, 17 Mar 1997 11:56:39 -0700 From: Warner Losh Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <332BC869.37B7@wgold.demon.co.uk> James Mansion writes: : In no way shape or form is an inline virtual function (destructor or : not) 'dunious'. Its quite legal. (Whether you might consider it to be : bad style is another matter. You can't always avoid it if the class is : a template, though that's clearly not the case with tvision) If compilers don't handle it, then the construct is dubious. :-) : If the compiler cannot handle code like this, then the compiler should : be fixed. Actually, it is a bug in the as program and it should be fixed. Warner From owner-freebsd-hackers Mon Mar 17 11:57:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01010 for hackers-outgoing; Mon, 17 Mar 1997 11:57:29 -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 LAA00998 for ; Mon, 17 Mar 1997 11:57:23 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0w6iWb-0003Og-00; Mon, 17 Mar 1997 11:56:53 -0800 Date: Mon, 17 Mar 1997 11:56:53 -0800 (PST) From: Tom Samplonius To: hackers@freebsd.org Subject: ahc problem with 2.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A "find" triggered the following on a 2.2-GAMMA system with a 3940UW: ahc1:A:8: Warning - unknown message received from target (0x12). Rejecting ahc_intr: seqint, intstat == 0xc1, scsisigi == 0xf6 The kernel locked, and kept spewing this message to the console. I presume that the driver is stuck in a tight loop. I assume the message originated from id 8, on bus A, but I don't have a device at that id! I'm using tagged commands, and scb paging. Tom From owner-freebsd-hackers Mon Mar 17 12:52:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA04009 for hackers-outgoing; Mon, 17 Mar 1997 12:52:51 -0800 (PST) Received: from odin.INS.CWRU.Edu (odin.INS.CWRU.Edu [129.22.8.102]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04000 for ; Mon, 17 Mar 1997 12:52:43 -0800 (PST) Received: (chet@localhost) by odin.INS.CWRU.Edu (8.7.6+cwru/CWRU-2.3-ins) id PAA29341; Mon, 17 Mar 1997 15:52:30 -0500 (EST) (from chet) Date: Mon, 17 Mar 1997 15:37:12 -0500 From: Chet Ramey To: freebsd-hackers@freebsd.org Subject: Problem with strcoll in FreeBSD 2.1.7 Cc: chet@odin.INS.CWRU.Edu Reply-To: chet@po.CWRU.Edu Message-ID: <9703172037.AA28815.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I'm puzzled by the following results, and I'm wondering if there's a bug in strcoll(3) or if I'm misunderstanding things. Given the following program: #include #include #include void testcoll(s1, s2) char *s1, *s2; { int r1, r2; r1 = strcoll(s1, s2); r2 = strcmp(s1, s2); printf ("strcoll(%s, %s) -> %d\n", s1, s2, r1); printf ("strcmp(%s, %s) -> %d\n", s1, s2, r2); } main(c, v) int c; char *v[]; { char *deflocale, *defcoll; char xf1[16], xf2[16]; deflocale = setlocale(LC_ALL, (char *)NULL); defcoll = setlocale(LC_COLLATE, (char *)NULL); printf ("default locale: %s\n", deflocale); printf ("default collation order: %s\n", defcoll); testcoll (v[1], v[2]); strxfrm(xf1, v[1], 16); strxfrm(xf2, v[2], 16); printf ("%s locale, after strxfrm:\n", deflocale); testcoll(xf1, xf2); setlocale (LC_ALL, "POSIX"); setlocale (LC_COLLATE, "POSIX"); printf ("POSIX locale:\n"); printf ("POSIX collation order:\n"); testcoll(v[1], v[2]); strxfrm(xf1, v[1], 16); strxfrm(xf2, v[2], 16); printf ("POSIX locale, after strxfrm:\n"); testcoll(xf1, xf2); exit (0); } I get the following output, which seems strange: bash$ ./x1 abd aXd default locale: C default collation order: C strcoll(abd, aXd) -> -22 strcmp(abd, aXd) -> 10 C locale, after strxfrm: strcoll(abd, aXd) -> -22 strcmp(abd, aXd) -> 10 POSIX locale: POSIX collation order: strcoll(abd, aXd) -> -22 strcmp(abd, aXd) -> 10 POSIX locale, after strxfrm: strcoll(abd, aXd) -> -22 strcmp(abd, aXd) -> 10 Shouldn't both strcoll(3) and strcmp(3) return values > 0? Thanks for any help. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From owner-freebsd-hackers Mon Mar 17 15:14:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11302 for hackers-outgoing; Mon, 17 Mar 1997 15:14:24 -0800 (PST) Received: from rocket.comtrol.com (rocket.comtrol.com [204.73.219.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA11291 for ; Mon, 17 Mar 1997 15:14:11 -0800 (PST) Received: from amirpc.comtrol.com (amir [204.73.219.82]) by rocket.comtrol.com (8.6.9/8.6.9) with SMTP id RAA25111 for ; Mon, 17 Mar 1997 17:13:36 -0600 Message-Id: <3.0.1.32.19970317064001.006c545c@comtrol.com> X-Sender: amir@comtrol.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Mar 1997 06:40:01 -0600 To: freebsd-hackers@FreeBSD.ORG From: Amir Farah Subject: RocketPort driver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello I have a driver for Comtrol RocketPort Serial Controller Cards. Is there any hope of making it into the next release of FreeBSD?? If not, what is a good place to make the driver accessible to people. The driver has been tested by a few people as a beta product and has performed well. Sincerely amir From owner-freebsd-hackers Mon Mar 17 15:50:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA13115 for hackers-outgoing; Mon, 17 Mar 1997 15:50:45 -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 PAA13095 for ; Mon, 17 Mar 1997 15:50:38 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19979; Mon, 17 Mar 1997 18:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 17 Mar 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 OAA05031; Mon, 17 Mar 1997 14:40:41 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id OAA00969; Mon, 17 Mar 1997 14:46:07 -0500 (EST) Date: Mon, 17 Mar 1997 14:46:07 -0500 (EST) From: Thomas David Rivers Message-Id: <199703171946.OAA00969@lakes.water.net> To: ponds!freebsd.org!freebsd-hackers, ponds!crh.cl.msu.edu!henrich Subject: Re: aha2940 problems in 2.1-STABLE (any by inference, possible 2.2-RELE Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The 2.1.6.1 kernel reponds with (from dmesg): > > > ahc0 rev 0 int a irq 15 on pci0:17 > > ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs > > ahc0 waiting for scsi devices to settle > > (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 > > sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) > > ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers > > The quick and dirty solution is to go into your adaptec controller setup and > turn off wide negotiation on your narrow devices (I've had this same problem > for some time now) Ummmm - am I mistaken; or perhaps I haven't communicated well. You see, at 2.1.6.1 the aha2940 driver works - it recognizes the drive isn't WIDE and does the right thing. At 2.1-STABLE (post 2.1.7) the aha2940 driver doesn't work. Now, if I understand you correctly, disabling WIDE negotiation for this device in the CNTRL-A setup for the aha2940 will cause 2.1.7 to become functional? I'll give it a try this evening. - Thanks - - Dave R. - From owner-freebsd-hackers Mon Mar 17 16:07:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA14149 for hackers-outgoing; Mon, 17 Mar 1997 16:07:37 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA14137 for ; Mon, 17 Mar 1997 16:07:34 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id QAA04799; Mon, 17 Mar 1997 16:07:33 -0800 (PST) Message-Id: <199703180007.QAA04799@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Amir Farah cc: freebsd-hackers@FreeBSD.ORG Subject: Re: RocketPort driver In-reply-to: Your message of "Mon, 17 Mar 1997 06:40:01 CST." <3.0.1.32.19970317064001.006c545c@comtrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Mar 1997 16:07:33 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dumb question, what is a Rocketport Serial controller and is there a version that supports PCI. Tnks, Amancio >From The Desk Of Amir Farah : > > Hello > > I have a driver for Comtrol RocketPort Serial Controller Cards. Is there > any hope of making it into the next release of FreeBSD?? If not, what is a > good place to make the driver accessible to people. The driver has been > tested by a few people as a beta product and has performed well. > > Sincerely > > amir > > From owner-freebsd-hackers Mon Mar 17 16:27:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16193 for hackers-outgoing; Mon, 17 Mar 1997 16:27:32 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA16188 for ; Mon, 17 Mar 1997 16:27:29 -0800 (PST) Received: by sovcom.kiae.su id AA15406 (5.65.kiae-1 ); Tue, 18 Mar 1997 03:09:57 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 18 Mar 97 03:09:57 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id CAA00560; Tue, 18 Mar 1997 02:58:32 +0300 (MSK) Date: Tue, 18 Mar 1997 02:58:26 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: chet@po.CWRU.Edu Cc: freebsd-hackers@freebsd.org, chet@odin.INS.CWRU.Edu Subject: Re: Problem with strcoll in FreeBSD 2.1.7 In-Reply-To: <9703172037.AA28815.SM@odin.INS.CWRU.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 Mon, 17 Mar 1997, Chet Ramey wrote: > Hi. I'm puzzled by the following results, and I'm wondering if there's a > bug in strcoll(3) or if I'm misunderstanding things. > This bug was fixed in -current and I think in 2.2 too, both functions return 10 now. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Mon Mar 17 16:33:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16623 for hackers-outgoing; Mon, 17 Mar 1997 16:33:09 -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 QAA16615 for ; Mon, 17 Mar 1997 16:33:05 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA12421; Tue, 18 Mar 1997 11:02:36 +1030 (CST) From: Michael Smith Message-Id: <199703180032.LAA12421@genesis.atrad.adelaide.edu.au> Subject: Re: RocketPort driver In-Reply-To: <3.0.1.32.19970317064001.006c545c@comtrol.com> from Amir Farah at "Mar 17, 97 06:40:01 am" To: amir@comtrol.com (Amir Farah) Date: Tue, 18 Mar 1997 11:02:36 +1030 (CST) Cc: 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 Amir Farah stands accused of saying: > > I have a driver for Comtrol RocketPort Serial Controller Cards. Is there > any hope of making it into the next release of FreeBSD?? If not, what is a > good place to make the driver accessible to people. The driver has been > tested by a few people as a beta product and has performed well. If you could bundle the driver and some instructions for installing it (perhaps ask me about the KernelDriver automated driver installation script), we could get Jordan to put it on the 2.2 CD in the 'experimental' section. I have a reasonable pile of stuff that I want to go there, and I'd suggest that anyone else that wants wider distribution for their work-in-progress project should pester jkh for inclusion. Jordan, perhaps a short announcement and a day or two of grace for us to get stuff together? > amir -- ]] 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 Mar 17 16:51:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18127 for hackers-outgoing; Mon, 17 Mar 1997 16:51:40 -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 QAA18108 for ; Mon, 17 Mar 1997 16:51:25 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA24582; Tue, 18 Mar 1997 01:50:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id BAA02040; Tue, 18 Mar 1997 01:49:40 +0100 (MET) Message-ID: <19970318014940.GY62672@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 01:49:40 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: amir@comtrol.com (Amir Farah) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: RocketPort driver References: <3.0.1.32.19970317064001.006c545c@comtrol.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.1.32.19970317064001.006c545c@comtrol.com>; from Amir Farah on Mar 17, 1997 06:40:01 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Amir Farah wrote: > I have a driver for Comtrol RocketPort Serial Controller Cards. Is there > any hope of making it into the next release of FreeBSD? If you maintain it, sure. I see you are from Comtrol (and i much appreciated their support they gave me to get my ancient 8-port card up&running, alas, the card seems to have died before i got it working under FreeBSD at all :( ), so you probably have some interest in maintaining it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Mar 17 16:56:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18753 for hackers-outgoing; Mon, 17 Mar 1997 16:56:22 -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 QAA18722 for ; Mon, 17 Mar 1997 16:56:08 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id MAA04389; Tue, 18 Mar 1997 12:03:25 +1100 (EST) Date: Tue, 18 Mar 1997 12:03:23 +1100 (EST) From: "Daniel O'Callaghan" To: Amancio Hasty cc: freebsd-hackers@freebsd.org Subject: Re: RocketPort driver In-Reply-To: <199703180007.QAA04799@rah.star-gate.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, 17 Mar 1997, Amancio Hasty wrote: > Dumb question, > what is a Rocketport Serial controller and is there a version that > supports PCI. See They make 8 and 16 port cards, including ISA and PCI. Danny From owner-freebsd-hackers Mon Mar 17 17:15:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA20372 for hackers-outgoing; Mon, 17 Mar 1997 17:15:32 -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 RAA20354 for ; Mon, 17 Mar 1997 17:15:27 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA12765; Tue, 18 Mar 1997 11:42:29 +1030 (CST) From: Michael Smith Message-Id: <199703180112.LAA12765@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703171835.LAA08169@phaeton.artisoft.com> from Terry Lambert at "Mar 17, 97 11:35:00 am" To: terry@lambert.org (Terry Lambert) Date: Tue, 18 Mar 1997 11:42:28 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De 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: > > > Q: Why are the users permitted to override geometry? > > > A: Because FreeBSD sometimes gets it wrong. > > > > That's accurate, but incomplete and misleading. FreeBSD sometimes gets it > > wrong because it's not possible to always get it right. > > Bullshit. It is possible to get it right. You may have to rewrite a > scratch area of a disk in order to do it, but it's possible. Windows95 > does it just fine. Ok, so I give you a pathalogical case. I can think of several right off the top of my head; most involve flash memory or read-only media of some sort. Of course, you have no way of knowing that the area of the disk that you've elected to use is actually "scratch", do you? Remember all those nasty comments about MS operating systems eating peoples' disks? > It may be accurate to state that "it's hard for FreeBSD to get it right, > but with slight modifications, FreeBSD could get it right in the vast > majority of cases, and appeal to the user for the rest. I'm sure that > this will come down to machines with identical drives that someone has > duplicated with dd and which have identical defect lists for whatever > reason. An unlikely case. Given unlimited resources and patience, I'm sure you could do that. With the much scantier resources actually available to the bootloader, things aren't so easy. > > > Q: Why does FreeBSD sometimes get it wrong? > > > A: Because FreeBS gets the INT 13 values in the boot loader, but then > > > discards them in favor of the potentially incorrect CMOS and/or > > > non-BIOS drive query return values. > > > > This is not answering the question. > > Yes it is. If FreeBSD did not discard the boot loader values, it would > have the "correct" geometry for the device. The "correctness" of the > geometry is a result of: You are making the (possibly incorrect) assumption that the bootloader has the 'correct' geometry in the first place. This is only valid if the bootloader obtained the correct geometry, and has not been misled or made a mistake. It could do this if it didn't come off the disk in question, or if the BIOS in the system is behaving oddly, or if it was loaded by something other than a vanilla MBR. > 1) Being able to determine the absolute sector offset for a > given C/H/S value in the partition table. This is a basic requirement for reading the second portion of the bootstrap, granted. > If you have read the VFAT32 specification that came on the OEMSR2 > CDROM from Microsoft, you know that the code looks at the partition > data of the disk in order to determine the geometry (just like the > NCR BIOS does in order to make other SCSI controller geometries OK > for the NCR controller). I have little or no time for reading Microsoft's confusing and misleading documentation; I have far too much work creating my own, thanks. Oddly enough, not everybody subscribes to, or _wants_ to subscribe to, MS' developer programs. Personally, I get by quite nicely avoiding subsdising immoral corporates wherever possible, and MS are right up there with Shell and McD's. Reading the partition data on the disk also requires that you are using an MBR in the first place; another poor assumption. > The INT 13 in question is called in the FreeBSD second stage boot block > after switching back to real mode for the call (this is an artifact of > the MACH boot blocks, which could switch back to real mode without > penalty). Check the boot block code if you don't believe me. I am fully aware that the bootblocks have access to the BIOS information. I am also keen to make this information, as well as a lot more, available to the kernel in a useful and disposable format; I just haven't received much in the way of support or time. > > It is not sensible to try to match sector counts against c/h/s values > > from the BIOS in many cases; often the discrepancy can be more than > > one track multiple out. A signature approach might perhaps be better. > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > the C/H/S limit values to get the absolute drive size. Compare > the size against the IDENTIFY size. This will establish disk > identity in the vast majority of cases. Huh? It is almost certain that, in the majority of cases, the C/H/S size will _not_ match the drive's total reported size. You would have to apply a 'nearest fit' heuristic with some intelligence about what is 'near'. Not impossible, no, but not terribly simple. > o Modify the second stage boot to fill in the correct LBA address > in the DOS partition table for a given C/H/S value at boot time; > have BSD *always* use the LBA values in protected mode and > *always* use the C/H/S values in the INT 13 using boot code. > This should cover all other cases except where the drive is > identical. This would be nice. It does, however, require that the second-stage boot be able to write to the disk, which is not always practical (and on many systems will drop the user into a large flashing red "virus alert" screen). > > The correspondence between FreeBSD device and BIOS device is only > > significantly relevant with a mixture of SCSI and IDE devices, or > > multiple SCSI devices on multiple controllers. > > It's relevant when there are two or more devices in the system which > may be identical except for the INT 13 drive ID. The only situation in which it is justifiable to be concerned about which physical drive matches which BIOS drive ID is when attempting to determine from the BIOS disk number of the root device from the bootloader which disk contains the desired root filesystem. In most cases, this is trivial and the whole argument above is moot. However, it is desirable for things to work in _nontrivial_ cases, so we are already talking about border conditions. > > Several of us are playing with three-stage bootcode. If you would be so > > kind as to contribute an ELF loader that understands your segment-colouring > > stuff, preferably as an 'ld.so' for the kernel, we could move to a > > boot-time link approach which could take advantage of this. > > What's wrong with Erich's code to do this? The fact that I have yet to obtain a version of GRUB that can be built on FreeBSD, or that comes with anything approaching the sort of basic functionality I'm looking for? GRUB is a nice idea, but too limited. I would very much like to work with it, but if I can't build it, I can't tinker. In particular, the hardcoded blocklist and "stage 1.5" concepts make me want to puke. It is also salient to note that GRUB has not been updated for over 5 months, making me fairly certain that it's a dead item. My current 'favorite' is the NetBSD libsa, which has all of the bits that I need, modulo perhaps some more network drivers, however it doesn't appear to have all of the "wonderful" ELF stuff that you keep raving about. > > In reality, two versions of the linker will be required; a very stupid > > version that can load the main kernel object and some set of stipulated > > objects for inclusion in the stage-3 bootstrap, and a smarter one that > > should be part of the kernel to replace the current LKM mechanism. > > > > The 'stupid' one would need to fit inside the 64K small-model kernel > > loader module. > > I don't see why the stupid one could not be the same as the smart one, > as long as you were willing to establish PM mappings for it. *shrug* The idea behind having two was simply that the 'stupid' one need only be able to assemble a kernel from a specified list of components, while the 'smart' one needs to run after the kernel has started to add extra components. > As for > segment loading, the most interesting method would be to put modules in > seperate ELF segments in the kernel image itself, jamming them in or > yanking them out at will. The segment coloring is only useful in this > case if your defautl drivers for the console, etc. are colored differently > than the rest of the kernel to allow them to be distinguished (and dumped > at will for replacement). Given this, then a "boot" coloring (see the > Microsoft Developer Network document on the Portable Executable format > for ELF segment coloring) could get loaded leaving the rest for later. It is pointless to make sideways references like this to documents that are effectively inaccessible. If you have a URL, cite it. If the document is not freely available, then either paraphrase enough of it to convey its details, or avoid referencing it as though I should have read it. The connotation is annoying at best, and I find it quite insulting. Look, we're talking about doing something new here. If segment colouring is useful, and I suspect that John could make it so, then there's no reason not to do it. We still need an in-kernel (or attached-to-kernel) ELF linker that can do this. All I'm suggesting is that _I_don't_know_enough_about_it_ to do it, and I am asking that you consider putting some code down that does. > If you read the Schulman book on Win95, this is actually how Windows95 > loads its VXD's and other pieces... only we don't have an IO.SYS that > understands our file system (well, we don't have a publically available > one, anyway). As above, please don't suggest that I have time to lie about in traction reading expensive books that my employer doesn't want on their shelves. On the sort of peanut salary I'm on, a $90.00 book isn't something I'm going to spring for just to read that MS use an in-kernel linker. Big yay. Bruce has already observed that the stage-2 boot can happily read UFS filesystems, so I don't know what your problem is there. > 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 Mon Mar 17 17:50:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA22897 for hackers-outgoing; Mon, 17 Mar 1997 17:50:08 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA22892 for ; Mon, 17 Mar 1997 17:50:06 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA01065; Mon, 17 Mar 1997 17:49:09 -0800 (PST) To: Michael Smith cc: amir@comtrol.com (Amir Farah), freebsd-hackers@freebsd.org Subject: Re: RocketPort driver In-reply-to: Your message of "Tue, 18 Mar 1997 11:02:36 +1030." <199703180032.LAA12421@genesis.atrad.adelaide.edu.au> Date: Mon, 17 Mar 1997 17:49:09 -0800 Message-ID: <1061.858649749@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If you could bundle the driver and some instructions for installing it > (perhaps ask me about the KernelDriver automated driver installation > script), we could get Jordan to put it on the 2.2 CD in the 'experimental' > section. Sure. > I have a reasonable pile of stuff that I want to go there, and I'd > suggest that anyone else that wants wider distribution for their > work-in-progress project should pester jkh for inclusion. Yes! > Jordan, perhaps a short announcement and a day or two of grace for us > to get stuff together? Consider this a short announcement. You all have a day or two of grace to get stuff together. :-) Seriously, we'd have been off to press with the CD already if it hadn't been for the 2.2 package spamming problem on wcarchive. While Satoshi rebuilds packages, I'm waiting. I expect that this will take another day or so. Then I will spend a day getting it ready. Let's say that if I don't have it by Wednesday mid-afternoon (PST), it might not make it. Jordan From owner-freebsd-hackers Mon Mar 17 18:37:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25175 for hackers-outgoing; Mon, 17 Mar 1997 18:37:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA25167 for ; Mon, 17 Mar 1997 18:37:44 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA08818; Mon, 17 Mar 1997 19:25:37 -0700 From: Terry Lambert Message-Id: <199703180225.TAA08818@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 17 Mar 1997 19:25:36 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703180112.LAA12765@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 18, 97 11:42:28 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 > > Bullshit. It is possible to get it right. You may have to rewrite a > > scratch area of a disk in order to do it, but it's possible. Windows95 > > does it just fine. > > Ok, so I give you a pathalogical case. I can think of several right > off the top of my head; most involve flash memory or read-only media > of some sort. > > Of course, you have no way of knowing that the area of the disk that > you've elected to use is actually "scratch", do you? Remember all > those nasty comments about MS operating systems eating peoples' disks? The "cannonically correct" way to do this is to get the protected mode driver up in parallel with a VM86()-based INT-13 using driver, and if you can't tell two media apart, write on one of them with one driver and notice the change with the other. You either: 1) Save the previous contents of the byte you write 2) Restore the byte you wrote from the absolutely identical media Either way, it is fully recoverable, especially if you choose an LBA in the partition table of one of the drives, or if you have FreeBSD recognized to partition types (A5 and one other) and switch the FreeBSD partition tag between the two possible (but otherwise equivalent) values. If they are read-only media, *it doesn't matter*. For "less cannonically correct" code that can't call VM86(), you bail: ask the user, and cache the answer. This is less horrific than asking every user during the install, defaulting to the "wrong" values for a shared disk install (the most typical install), and failing to run on all modern Dell, Gateway, etc. hardware without the user futzing around in fdisk. > Given unlimited resources and patience, I'm sure you could do that. With > the much scantier resources actually available to the bootloader, things > aren't so easy. Linux does it. Isn't FreeBSD as good as Linux? Which particular resource do they have that FreeBSD doesn't? I feel low trotting out the old "Linux" card, but you leave me little choice in this dialectic. Hopefully by "unlimited resources" you were referring to MS? > You are making the (possibly incorrect) assumption that the bootloader > has the 'correct' geometry in the first place. This is only valid if > the bootloader obtained the correct geometry, and has not been misled or > made a mistake. It could do this if it didn't come off the disk in > question, or if the BIOS in the system is behaving oddly, or if it > was loaded by something other than a vanilla MBR. If the bootloader was misled, DOS was identically mislead, and since all we really care about here is interoperability with DOS installed on the same drive (or another OS that must also care about interoperability with DOS installed on the same drive), it is *correct* to allow ourselves to be "misled". In the "mistake" case: bad code is bad code and all known bugs should be fixed instead of ignored, especially when it comes to something as critical as people not being able to install your product. > > If you have read the VFAT32 specification that came on the OEMSR2 > > CDROM from Microsoft, you know that the code looks at the partition > > data of the disk in order to determine the geometry (just like the > > NCR BIOS does in order to make other SCSI controller geometries OK > > for the NCR controller). > > I have little or no time for reading Microsoft's confusing and misleading > documentation; I have far too much work creating my own, thanks. > > Oddly enough, not everybody subscribes to, or _wants_ to subscribe to, > MS' developer programs. Personally, I get by quite nicely avoiding > subsdising immoral corporates wherever possible, and MS are right up > there with Shell and McD's. The problems with the boot are MS OS boot interoperability problems, nothing more. If you have an issue about dealing with interoperability problems by examining the software with which you are attempting to interoperate, well, all I can say is that you are unlikely to ever solve your problem. > Reading the partition data on the disk also requires that you are using > an MBR in the first place; another poor assumption. No, it's not. You should *always* have an MBR (or whatever passes for a native MBR on non-x86 computers -- on PPC's which comply with either PReP or CHRP, it's a DOS MBR. On DEC Alpha's, it's a DOS MBR). This is common sense, since it reduces the number of cases you must consider when you are trying to recognize the thing. If you are guaranteed that the first stage boot won't be a BSD second stage boot (you can do this, because we have OS-BS and a number of other programs at our disposal, something which occured *after* Bill Jolitz implemented this case for 386BSD installed on a system on which DOS had not been installed), you can make all sorts of nice simplifying assumptions. > I am fully aware that the bootblocks have access to the BIOS information. > I am also keen to make this information, as well as a lot more, available > to the kernel in a useful and disposable format; I just haven't > received much in the way of support or time. It's there already. It's in the same variables. It's utility is being declined because of the identity problems (already discussed). > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > > the C/H/S limit values to get the absolute drive size. Compare > > the size against the IDENTIFY size. This will establish disk > > identity in the vast majority of cases. > > Huh? It is almost certain that, in the majority of cases, the C/H/S > size will _not_ match the drive's total reported size. You would have > to apply a 'nearest fit' heuristic with some intelligence about > what is 'near'. Not impossible, no, but not terribly simple. Size-ordered BSD device list, bsearch for BIOS sizes. *Very* simple. > > o Modify the second stage boot to fill in the correct LBA address > > in the DOS partition table for a given C/H/S value at boot time; > > have BSD *always* use the LBA values in protected mode and > > *always* use the C/H/S values in the INT 13 using boot code. > > This should cover all other cases except where the drive is > > identical. > > This would be nice. It does, however, require that the second-stage > boot be able to write to the disk, which is not always practical (and > on many systems will drop the user into a large flashing red "virus > alert" screen). Only write it if the values are wrong. After you write it once, they aren't wrong. In the "Virus alert" case (few machines offer this at the INT 13 level anyway), instruct the user to override. We must already be instructing the user to do this to install our partition table entry anyway, right? One partition table write can not be distinguished from another. A write of that disk address range is a write of that disk address range. > > > The correspondence between FreeBSD device and BIOS device is only > > > significantly relevant with a mixture of SCSI and IDE devices, or > > > multiple SCSI devices on multiple controllers. > > > > It's relevant when there are two or more devices in the system which > > may be identical except for the INT 13 drive ID. > > The only situation in which it is justifiable to be concerned about which > physical drive matches which BIOS drive ID is when attempting to determine > from the BIOS disk number of the root device from the bootloader which > disk contains the desired root filesystem. In most cases, this is trivial > and the whole argument above is moot. However, it is desirable for things > to work in _nontrivial_ cases, so we are already talking about > border conditions. Yes. > > What's wrong with Erich's code to do this? > > The fact that I have yet to obtain a version of GRUB that can be built > on FreeBSD, or that comes with anything approaching the sort of basic > functionality I'm looking for? I'd suggest contacting Erich about this. Are you using modern tools? Erich has typically been very responsive of all emails on the subject of GRUB, at least to my reckoning. > GRUB is a nice idea, but too limited. I would very much like to work > with it, but if I can't build it, I can't tinker. In particular, the > hardcoded blocklist and "stage 1.5" concepts make me want to puke. > It is also salient to note that GRUB has not been updated for over > 5 months, making me fairly certain that it's a dead item. Or perfected. ;-). Not that I believe that, in case the wink made it unclear... > My current 'favorite' is the NetBSD libsa, which has all of the bits > that I need, modulo perhaps some more network drivers, however it doesn't > appear to have all of the "wonderful" ELF stuff that you keep raving > about. I've never raved about ELF in NetBSD... not even in their boot code. > > I don't see why the stupid one could not be the same as the smart one, > > as long as you were willing to establish PM mappings for it. > > *shrug* The idea behind having two was simply that the 'stupid' one > need only be able to assemble a kernel from a specified list of > components, while the 'smart' one needs to run after the kernel has > started to add extra components. Actually, you want to be able to load all segments with a certain set of tag bits from the kernel image file, which is a single ELF file. This should be a lot easier to do, actually. If you don't care about non-kernel files in the boot stage, then you are done. Othewise, you must provide "vnop" level correspondance between the interfaces, and in the kernel case, provide a "stupid" INT 13 "vnop" layer. The lack of a coherent kernel level vnode-as-descriptor based file I/O subsystem is one of the things that is wrong in the FreeBSD kernel. The vn_* routines are seriously incoherent compared to, for instance, the AIX kernel file I/O interface. > > As for > > segment loading, the most interesting method would be to put modules in > > seperate ELF segments in the kernel image itself, jamming them in or > > yanking them out at will. The segment coloring is only useful in this > > case if your defautl drivers for the console, etc. are colored differently > > than the rest of the kernel to allow them to be distinguished (and dumped > > at will for replacement). Given this, then a "boot" coloring (see the > > Microsoft Developer Network document on the Portable Executable format > > for ELF segment coloring) could get loaded leaving the rest for later. > > It is pointless to make sideways references like this to documents > that are effectively inaccessible. If you have a URL, cite it. If > the document is not freely available, then either paraphrase enough of > it to convey its details, or avoid referencing it as though I should > have read it. The connotation is annoying at best, and I find it > quite insulting. Sorry; I thought you would have gone to AltaVista and typed a search key of "+portable +executable +format" before stating it was inaccessable. Here is the URL. http://www.microsoft.com/win32dev/base/pefile.htm > Look, we're talking about doing something new here. If segment > colouring is useful, and I suspect that John could make it so, then > there's no reason not to do it. We still need an in-kernel (or > attached-to-kernel) ELF linker that can do this. Segment coloring refers to attribute bits for VM handling based on which ELF segment the page in question came from: 0x00000020 Code section 0x00000040 Initialized data section 0x00000080 Uninitialized data section 0x04000000 Section cannot be cached 0x08000000 Section is not pageable 0x10000000 Section is shared 0x20000000 Executable section 0x40000000 Readable section 0x80000000 Writable section (This is not comprehensive: I have additional bit definitions that I have reverse engineered from using the "MODBIN" utility to set the executable attributes, then dumped them out with my own programs; a trivial exercise; for instance "PRELOAD", which is not honored by Windows95 -- test: insert VC++ 4.2 CD, let it pop the install screen, reove the CD, and move the mouse over the install screen and watch Win95 segfault). In addition, the segment identifier, which in MS binaries is predefined in the SDK and DDK as #pragma manifests interpreted by the compiler as attribution, and the .DEF file, can be defined by the linker using the "/DEF" directive. Segments are named using a "section header", the first 8 bytes of which are a null terminated string (0-7 characters) containing the segment from the .DEF file and/or #pragma code_seg(): #pragma code_seg("_LTEXT", "LCODE") ...identifier is "_LTEXT" ...class is "LCODE", which implies... ...attribute "code section, section is not pageable, executable section" The loader would load segments of a given attribute and a given set of identifiers. > All I'm suggesting is that _I_don't_know_enough_about_it_ to do it, and > I am asking that you consider putting some code down that does. There is sample code available for download at the URL above. If you need more, I've duplicated this effort to be able to load symbol tables from Microsoft Debug format and from SoftICE files into a non-statistical profiler for VXD's, when porting the Heidemann framework to Windows95, so I suppose I could give you some similar samples, though my header file for the reverse engineer was not nearly as complete as the ones on the URL above. > > If you read the Schulman book on Win95, this is actually how Windows95 > > loads its VXD's and other pieces... only we don't have an IO.SYS that > > understands our file system (well, we don't have a publically available > > one, anyway). > > As above, please don't suggest that I have time to lie about in > traction reading expensive books that my employer doesn't want on > their shelves. On the sort of peanut salary I'm on, a $90.00 book > isn't something I'm going to spring for just to read that MS use an > in-kernel linker. Big yay. > > Bruce has already observed that the stage-2 boot can happily read UFS > filesystems, so I don't know what your problem is there. The Schulman book is a good documentation of the process of bringing up a protected mode OS from a real mode boot loader without losing access or validity of real mode data. The problem is in conversion from real-mode (INT-13/INT-21 based) disk drivers over to protected mode disk drivers. I was simply giving an example of how it had been done. Don't you have a technical library in your corner of the world? In any case, I doubt we have to go so far as to convert open file pointers from TSR's loaded by autoexec.bat... The main point is that the real mode code and the protected mode code for the VXD (PE format image) loader are the same, so there's precedent that it's possible to implement without a "smart" vs. "stupid" loader dichotomy. 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 Mar 17 18:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25674 for hackers-outgoing; Mon, 17 Mar 1997 18:50:38 -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 SAA25668 for ; Mon, 17 Mar 1997 18:50:36 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA03560; Mon, 17 Mar 1997 21:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 17 Mar 1997 21: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 UAA00887; Mon, 17 Mar 1997 20:42:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id UAA00374; Mon, 17 Mar 1997 20:48:15 -0500 (EST) Date: Mon, 17 Mar 1997 20:48:15 -0500 (EST) From: Thomas David Rivers Message-Id: <199703180148.UAA00374@lakes.water.net> To: ponds!freebsd.org!freebsd-hackers, ponds!crh.cl.msu.edu!henrich Subject: Re: aha2940 problems in 2.1-STABLE (any by inference, possible 2.2-RELE Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk See below.. > > > > The 2.1.6.1 kernel reponds with (from dmesg): > > > > > ahc0 rev 0 int a irq 15 on pci0:17 > > > ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs > > > ahc0 waiting for scsi devices to settle > > > (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 > > > sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) > > > ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers > > > > The quick and dirty solution is to go into your adaptec controller setup and > > turn off wide negotiation on your narrow devices (I've had this same problem > > for some time now) > > Ummmm - am I mistaken; or perhaps I haven't communicated well. > > You see, at 2.1.6.1 the aha2940 driver works - it recognizes > the drive isn't WIDE and does the right thing. > > At 2.1-STABLE (post 2.1.7) the aha2940 driver doesn't work. > > Now, if I understand you correctly, disabling WIDE negotiation for this > device in the CNTRL-A setup for the aha2940 will cause 2.1.7 to become > functional? > > I'll give it a try this evening. > > - Thanks - > - Dave R. - > Ok - that's it exactly... When I disable the WIDE negotiation in the BIOS setup; 2.1-STABLE is able to find my old micropolis drive and seems pretty happy with it. Thanks for the tip! The question now becomes - why was 2.1.6.1 able to handle this, but 2.1-stable unable to do so? - Dave Rivers - From owner-freebsd-hackers Mon Mar 17 18:50:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25695 for hackers-outgoing; Mon, 17 Mar 1997 18:50:44 -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 SAA25681 for ; Mon, 17 Mar 1997 18:50:39 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA03582; Mon, 17 Mar 1997 21:50:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 17 Mar 1997 21: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 VAA01497 for ; Mon, 17 Mar 1997 21:32:00 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id VAA00497 for freebsd-hackers@freefall.cdrom.com; Mon, 17 Mar 1997 21:37:20 -0500 (EST) Date: Mon, 17 Mar 1997 21:37:20 -0500 (EST) From: Thomas David Rivers Message-Id: <199703180237.VAA00497@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Another problems with aha2940 in 2.1-STABLE (post 2.1.7) - process stuck. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - thanks to Charles, I'm actually running this morning's 2.1-STABLE release (thanks again.) However, I just ran my aha2940 "killer" test; which is a tar to /dev/rst0 of some significant quantity. In 2.1.6.1; this would cause the machine to lock up - as I reported earlier - the SCSI bus would simply go wild when the last tape write had completed and the tape was in the process of rewinding. Further SCSI I/O was hosed; causing an eventual panic/reboot. This has improved somewhat, as the machine doesn't go crazy. But, the process doing the write is "stuck." The output of /bin/ps -gaxl shows the process is stuck in scsicm: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 402 397 5 -5 5 552 400 scsicm DN+ p0 0:19.90 tar cvf /dev/rst0 Cnews POP X sc shape1.4pl6 I am unable to kill the process (a reboot is likely in order.) Also, the following messages appeared on the console: sd0(ahc0:0:0): SCB 0x4 - timed out in command phase, SCSISIGI == 0x84 SEQADDR == 0x61 st0(ahc0:2:0): abort message in message buffer sd0(ahc0:0:0): SCB 0x2 timedout while recovery in progress st0(ahc0:2:0): SCB 0x3 - timed out in command phase, SCSISIGI == 0x94 SEQADDR == 0x60 st0(ahc0:2:0): no longer in timeout ahc0: Issued Channel A Bus Reset. 3 SCBs aborted Clearing bus reset sd0(ahc0:0:0): UNIT ATTENTION info?:4020040 asc:29,0 sd0(ahc0:0:0): Power on, reset, or bus device reset occurred , retries:3 sd0(ahc0:0:0): NOT READY info?:4020040 asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , retries:3 sd0(ahc0:0:0): NOT READY info?:4020040 asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , retries:2 Clearing 'in-reset' flag sd0(ahc0:0:0): NOT READY info?:4020040 asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , retries:2 sd0(ahc0:0:0): NOT READY info?:4020040 asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , retries:1 sd0(ahc0:0:0): NOT READY info?:4020040 asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , retries:1 sd0(ahc0:0:0): NOT READY asc:4,1 sd0(ahc0:0:0): Logical unit is in process of becoming ready , FAILURE For completeness; here's the devices found during the probe: ahc0 rev 0 int a irq 15 on pci0:17 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) (ahc0:1:0): "MICROP 1548-15MZ1077802 HZ2P" type 0 fixed SCSI 1 sd1(ahc0:1:0): Direct-Access 1635MB (3349512 512 byte sectors) (ahc0:2:0): "WANGTEK 5150ES SCSI FA23 08" type 1 removable SCSI 1 st0(ahc0:2:0): Sequential-Access drive offline (ahc0:3:0): "NEC CD-ROM DRIVE:400 1.0" type 5 removable SCSI 2 cd0(ahc0:3:0): CD-ROM cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present can't get the size Hope this helps debug this a little... - Dave Rivers - From owner-freebsd-hackers Mon Mar 17 19:17:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA26936 for hackers-outgoing; Mon, 17 Mar 1997 19:17:48 -0800 (PST) Received: from po2.glue.umd.edu (root@po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA26927 for ; Mon, 17 Mar 1997 19:17:43 -0800 (PST) Received: from packet.eng.umd.edu (packet.eng.umd.edu [129.2.98.184]) by po2.glue.umd.edu (8.8.5/8.8.5) with ESMTP id WAA01073 for ; Mon, 17 Mar 1997 22:17:41 -0500 (EST) Received: from localhost (chuckr@localhost) by packet.eng.umd.edu (8.8.5/8.6.4) with SMTP id WAA03589 for ; Mon, 17 Mar 1997 22:17:40 -0500 (EST) X-Authentication-Warning: packet.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 17 Mar 1997 22:17:40 -0500 (EST) From: Chuck Robey X-Sender: chuckr@packet.eng.umd.edu To: FreeBSD-Hackers Subject: Intel inteerrupts? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know (for certain) what the action is regarding the interrupt enable flag, when a software INT is invoked for the Intel architecture? Are interrupts disabled, enabled, or what? If you have an answer, and IF you know somewhere I can read to verify it, I'd really appreciate your posting it. I've had several folks give me their (conflicting) opinions, and now I'm looking for confirmation. This is in regards to something I'm doing for an operating systems class. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Mon Mar 17 19:25:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27297 for hackers-outgoing; Mon, 17 Mar 1997 19:25:10 -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 TAA27290 for ; Mon, 17 Mar 1997 19:25:05 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA14257; Tue, 18 Mar 1997 13:53:47 +1030 (CST) From: Michael Smith Message-Id: <199703180323.NAA14257@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703180225.TAA08818@phaeton.artisoft.com> from Terry Lambert at "Mar 17, 97 07:25:36 pm" To: terry@lambert.org (Terry Lambert) Date: Tue, 18 Mar 1997 13:53:47 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De 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: > > Ok, so I give you a pathalogical case. I can think of several right > > off the top of my head; most involve flash memory or read-only media > > of some sort. > > > > Of course, you have no way of knowing that the area of the disk that > > you've elected to use is actually "scratch", do you? Remember all > > those nasty comments about MS operating systems eating peoples' disks? > > The "cannonically correct" way to do this is to get the protected mode > driver up in parallel with a VM86()-based INT-13 using driver, and if you > can't tell two media apart, write on one of them with one driver and > notice the change with the other. Given that we have established that it's not feasible or desirable to write to the media, as it's not possible to determine where is a safe place on said media to write to until after we have obtained the facts that we are trying to obtain, this doesn't work. Also, the practicalities involved in the int13 driver you're discussing are horrific. > > Given unlimited resources and patience, I'm sure you could do that. With > > the much scantier resources actually available to the bootloader, things > > aren't so easy. > > Linux does it. Isn't FreeBSD as good as Linux? Which particular > resource do they have that FreeBSD doesn't? I feel low trotting out > the old "Linux" card, but you leave me little choice in this dialectic. Linux does things somewhat differently. I don't like their approach a great deal, from what little I've studied it. Perhaps their way works for them; I'm seeking a way that works for me/us. I'm not shamed by your reference; I just can't see the relevance. > Hopefully by "unlimited resources" you were referring to MS? No, I'm referring to the dearth of _space_ in the second-stage bootstrap. > If the bootloader was misled, DOS was identically mislead, and since > all we really care about here is interoperability with DOS installed > on the same drive (or another OS that must also care about interoperability > with DOS installed on the same drive), it is *correct* to allow ourselves > to be "misled". What we care about is finding sectors on the disk, given some information in c/h/s format. It is only correct that we are similarly misled to DOS if we were booted from the same source as DOS. This is not necessarily so. > The problems with the boot are MS OS boot interoperability problems, > nothing more. If you have an issue about dealing with interoperability > problems by examining the software with which you are attempting to > interoperate, well, all I can say is that you are unlikely to ever > solve your problem. I am not complaining about examining any particular OS. I am complaining about your suggestion that I should be subscribed to a developer indoctrination service for an organisation and environment that I find personally anathematical. If said organisation or said interoperability plaintiffs were to provide useful and relevant documentation on the topic of interoperability, I would be happy to study it. > > Reading the partition data on the disk also requires that you are using > > an MBR in the first place; another poor assumption. > > No, it's not. You should *always* have an MBR (or whatever passes for > a native MBR on non-x86 computers -- on PPC's which comply with either > PReP or CHRP, it's a DOS MBR. On DEC Alpha's, it's a DOS MBR). This > is common sense, since it reduces the number of cases you must consider > when you are trying to recognize the thing. Supporting an MBR is good. Mandating one is not the current Way Of Things. It is valid to suggest that we should mandate the use of an MBR and corresponding partition information, but you will encounter users that will Not Like This. > > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > > > the C/H/S limit values to get the absolute drive size. Compare > > > the size against the IDENTIFY size. This will establish disk > > > identity in the vast majority of cases. > > > > Huh? It is almost certain that, in the majority of cases, the C/H/S > > size will _not_ match the drive's total reported size. You would have > > to apply a 'nearest fit' heuristic with some intelligence about > > what is 'near'. Not impossible, no, but not terribly simple. > > Size-ordered BSD device list, bsearch for BIOS sizes. *Very* simple. Not so simple. Introduce a set of devices that are found by the BIOS but not by BSD, and vice versa. Sort amusingly. Again, remeber that we are only looking for one device to match the sizing of a single BIOS disk. > Only write it if the values are wrong. After you write it once, they > aren't wrong. In the "Virus alert" case (few machines offer this at > the INT 13 level anyway), instruct the user to override. We must > already be instructing the user to do this to install our partition > table entry anyway, right? One partition table write can not be > distinguished from another. A write of that disk address range is a > write of that disk address range. A great many machines support int13 "virus alert" services. It isn't an issue at the point where we are writing a partition table as by then we are in protected mode talking directly to the disk. It's not a major issue, but it has the potential to be a support wart. > > My current 'favorite' is the NetBSD libsa, which has all of the bits > > that I need, modulo perhaps some more network drivers, however it doesn't > > appear to have all of the "wonderful" ELF stuff that you keep raving > > about. > > I've never raved about ELF in NetBSD... not even in their boot code. No, I am referring to the "segment colouring" and other things that you appear (justifiably?) to feel are worthwhile using ELF for. I am still studying the libsa code, so I could well have missed a lot. > Actually, you want to be able to load all segments with a certain set > of tag bits from the kernel image file, which is a single ELF file. MHO is that the kernel should _not_ be a monolithic file, but rather the 'core' kernel and a collection of linkable objects (drivers, optional extras, etc.) This would allow constructing seperate kernels from a single repository of objects, etc. > The lack of a coherent kernel level vnode-as-descriptor based file > I/O subsystem is one of the things that is wrong in the FreeBSD kernel. > The vn_* routines are seriously incoherent compared to, for instance, > the AIX kernel file I/O interface. The solution to this is well known; I am hoping that you have provided your changes to Julian and/or phk so that I can then pursue them with regard to having them integrated. > http://www.microsoft.com/win32dev/base/pefile.htm Thanks for the reference. Unfortunately, this document makes no mention of "colouring" (in either spelling) boot or otherwise. It describes PE as a mutant form of COFF, which I already knew. At best, I presume you are referring to the 'section characteristics' attribute. > Segment coloring refers to attribute bits for VM handling based on > which ELF segment the page in question came from: > > 0x00000020 Code section text > 0x00000040 Initialized data section data > 0x00000080 Uninitialized data section bss > 0x04000000 Section cannot be cached I want to modify this and not care about the CPU > 0x08000000 Section is not pageable I might have an interrupt handler in here > 0x10000000 Section is shared I might use this for IPC > 0x20000000 Executable section text > 0x40000000 Readable section > 0x80000000 Writable section ?! The point, however, is that these attributes are not useful until the VM system is up and running. The initial linker pass has to run _before_ this; still, it shouldn't be hard to walk the attributes at a later stage to pass them on. You could, at least, have renumbered the bits rather than use the same (nonsensical) assignments that MS did 8) > There is sample code available for download at the URL above. If you > need more, I've duplicated this effort to be able to load symbol > tables from Microsoft Debug format and from SoftICE files into a > non-statistical profiler for VXD's, when porting the Heidemann > framework to Windows95, so I suppose I could give you some similar > samples, though my header file for the reverse engineer was not > nearly as complete as the ones on the URL above. I couldn't care less about reading PE files. My primary concern is the communication of the attribute information to the VM system, and secondarily the parsing of ELF format files. > The problem is in conversion from real-mode (INT-13/INT-21 based) disk > drivers over to protected mode disk drivers. I was simply giving an > example of how it had been done. Don't you have a technical library > in your corner of the world? The short answer is : No, we don't. The longer answer is : (technical) Books cost a small fortune in this country for some inexplicable reason. eg. Stevens UNP, a fairly stock programmer's staple, lists at AUD$90 (about US$70). Ordering non-stock books can often add 10-15% to that. Public libraries tend not to have technical books. > The main point is that the real mode code and the protected mode code > for the VXD (PE format image) loader are the same, so there's precedent > that it's possible to implement without a "smart" vs. "stupid" loader > dichotomy. TBH, I don't think this has any relevancy at all. We are talking about environments that, rose-coloured glasses or no, are really quite different. > 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 Mon Mar 17 19:27:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27443 for hackers-outgoing; Mon, 17 Mar 1997 19:27:58 -0800 (PST) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27438 for ; Mon, 17 Mar 1997 19:27:55 -0800 (PST) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id TAA15908 for hackers@freebsd.org; Mon, 17 Mar 1997 19:27:52 -0800 Date: Mon, 17 Mar 1997 19:27:52 -0800 From: Sean Eric Fagan Message-Id: <199703180327.TAA15908@kithrup.com> To: hackers@freebsd.org Subject: A really minor annoyance Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2.2-GAMMA has while ((so->so_state & SS_ISCONNECTING) && so->so_error == 0) { error = tsleep((caddr_t)&so->so_timeo, PSOCK | PCATCH, "connec", 0); in kern/uipc_syscalls.c. Thus, "connec" shows up if you do a control-T (or whatever you have status set to) while something is waiting there. "connec" is *really* annoying. Why isn't it "connect"? It used to be either "netcon" or "connect" -- "connec" is worse than "netcon" (because it looks like a typo), and "connect" is certainly better than "connec" as well. (And since it is in the system call connect, having it say "connect" makes sense as well. But even "netcon" is better.) It's not because of the number of characters -- "running" (what you get when a process is active) has just as many characters as "connect". Sean. From owner-freebsd-hackers Mon Mar 17 20:11:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA29926 for hackers-outgoing; Mon, 17 Mar 1997 20:11:50 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA29915 for ; Mon, 17 Mar 1997 20:11:46 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id UAA03104; Mon, 17 Mar 1997 20:11:33 -0800 (PST) To: Thomas David Rivers cc: hackers@freebsd.org Subject: Re: Another problems with aha2940 in 2.1-STABLE (post 2.1.7) - process stuck. In-reply-to: Your message of "Mon, 17 Mar 1997 21:37:20 EST." <199703180237.VAA00497@lakes.water.net> Date: Mon, 17 Mar 1997 20:11:32 -0800 Message-ID: <3100.858658292@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Also, the following messages appeared on the console: > sd0(ahc0:0:0): SCB 0x4 - timed out in command phase, SCSISIGI == 0x84 > SEQADDR == 0x61 > st0(ahc0:2:0): abort message in message buffer Looks familiar. Wait for David to commit Justin's SCSI driver fixes to -stable; he's currently testing them on wcarchive. Jordan From owner-freebsd-hackers Mon Mar 17 20:30:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA00988 for hackers-outgoing; Mon, 17 Mar 1997 20:30:39 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00983 for ; Mon, 17 Mar 1997 20:30:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id UAA13133; Mon, 17 Mar 1997 20:26:06 -0800 (PST) Message-Id: <199703180426.UAA13133@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert Cc: msmith@atrad.adelaide.edu.au (Michael Smith), bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: wd driver questions Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 17 Mar 1997 20:26:04 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 17 Mar 1997 19:25:36 -0700 (MST) Terry Lambert wrote: > > My current 'favorite' is the NetBSD libsa, which has all of the bits > > that I need, modulo perhaps some more network drivers, however it doesn't > > appear to have all of the "wonderful" ELF stuff that you keep raving > > about. > > I've never raved about ELF in NetBSD... not even in their boot code. ...So, for the record, NetBSD's libsa doesn't have a generic ELF loader in it yet because not all architectures use ELF. Currently, the MIPS-based, Alpha, and PowerPC ports do (although I haven't committed the PowerPC stuff yet). The trick is backwards-compatibility, i.e. retaining the ability to load both kinds of formats, and that means footprint. The NetBSD/alpha boot blocks currently support loading ECOFF and ELF formats, for example, because, until just recently, ECOFF was the standard format. I think this will be changing soon, however. Now that the FSF has a sane way of saying "This ELF binary is for this OS", I've put the following on my NetBSD/hp300 TODO list: - grok ELF symbol tables in DDB - write ELF loader for libsa - make ELF work on NetBSD m68k ...but it's not a priority right now... too many other things to do :-) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Mon Mar 17 20:40:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA01602 for hackers-outgoing; Mon, 17 Mar 1997 20:40:52 -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 UAA01588 for ; Mon, 17 Mar 1997 20:40:46 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA15114; Tue, 18 Mar 1997 15:08:28 +1030 (CST) From: Michael Smith Message-Id: <199703180438.PAA15114@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703180426.UAA13133@lestat.nas.nasa.gov> from Jason Thorpe at "Mar 17, 97 08:26:04 pm" To: thorpej@nas.nasa.gov Date: Tue, 18 Mar 1997 15:08:27 +1030 (CST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de 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 Jason Thorpe stands accused of saying: > > ...So, for the record, NetBSD's libsa doesn't have a generic ELF loader > in it yet because not all architectures use ELF. Currently, the MIPS-based, > Alpha, and PowerPC ports do (although I haven't committed the PowerPC > stuff yet). Hmm, well saves me looking for it then 8) > The trick is backwards-compatibility, i.e. retaining the ability to load > both kinds of formats, and that means footprint. The NetBSD/alpha boot > blocks currently support loading ECOFF and ELF formats, for example, > because, until just recently, ECOFF was the standard format. Aha. One of the ideas I was toying with was having a 'standalone shell' which would then load the kernel linker, which then would load the kernel proper. Then as long as the standalone shell understood the objhect format the other standalone tools were built with, you could swap kernel linkers to suit the flavour of the day. I'm not entirely sure that the benefits that would accrue from this would necessarily be worthwhile though. > I think this will be changing soon, however. Now that the FSF has a sane > way of saying "This ELF binary is for this OS", I've put the following on > my NetBSD/hp300 TODO list: They do? Do you have a reference for this method? > - make ELF work on NetBSD m68k Hmm, I have one of these things (as I guess you've noticed 8), so naturally I'm interested in that too 8) > ...but it's not a priority right now... too many other things to do :-) Dang! > Jason R. Thorpe thorpej@nas.nasa.gov -- ]] 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 Mar 17 20:57:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA02240 for hackers-outgoing; Mon, 17 Mar 1997 20:57:04 -0800 (PST) Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02228; Mon, 17 Mar 1997 20:57:00 -0800 (PST) Received: from amdint.amd.com (amdint.amd.com [139.95.250.1]) by amdext.amd.com (8.8.5/8.8.5/AMD) with ESMTP id UAA12528; Mon, 17 Mar 1997 20:56:29 -0800 (PST) Received: from sgp.amd.com (sgp.amd.com [101.0.0.64]) by amdint.amd.com (8.8.5/8.8.5/AMD) with SMTP id UAA13683; Mon, 17 Mar 1997 20:56:26 -0800 (PST) Received: from dahlia.amd.com by sgp.amd.com (4.1/AMDSH-1.20) id AA07587; Tue, 18 Mar 97 12:56:28 SST Received: by dahlia.amd.com (4.0/AMDC-1.20) id AA03152; Tue, 18 Mar 97 12:50:07 SST From: peter@sgp.amd.com (Peter) Message-Id: <9703180450.AA03152@dahlia.amd.com> Subject: unsubscribe To: owner-hackers@freebsd.org, freebsd-hackers@freefall.freebsd.org, owner-freebsd-hackers@freefall.freebsd.org, hackers@freebsd.org Date: Tue, 18 Mar 97 12:50:07 WST X-Mailer: ELM [version 2.3 PL8] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Mon Mar 17 20:57:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA02247 for hackers-outgoing; Mon, 17 Mar 1997 20:57:07 -0800 (PST) Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02230; Mon, 17 Mar 1997 20:57:01 -0800 (PST) Received: from amdint.amd.com (amdint.amd.com [139.95.250.1]) by amdext.amd.com (8.8.5/8.8.5/AMD) with ESMTP id UAA12528; Mon, 17 Mar 1997 20:56:29 -0800 (PST) Received: from sgp.amd.com (sgp.amd.com [101.0.0.64]) by amdint.amd.com (8.8.5/8.8.5/AMD) with SMTP id UAA13683; Mon, 17 Mar 1997 20:56:26 -0800 (PST) Received: from dahlia.amd.com by sgp.amd.com (4.1/AMDSH-1.20) id AA07587; Tue, 18 Mar 97 12:56:28 SST Received: by dahlia.amd.com (4.0/AMDC-1.20) id AA03152; Tue, 18 Mar 97 12:50:07 SST From: peter@sgp.amd.com (Peter) Message-Id: <9703180450.AA03152@dahlia.amd.com> Subject: unsubscribe To: owner-hackers@freebsd.org, freebsd-hackers@freefall.freebsd.org, owner-freebsd-hackers@freefall.freebsd.org, hackers@freebsd.org Date: Tue, 18 Mar 97 12:50:07 WST X-Mailer: ELM [version 2.3 PL8] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Mon Mar 17 21:14:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA02806 for hackers-outgoing; Mon, 17 Mar 1997 21:14: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 VAA02800; Mon, 17 Mar 1997 21:14:26 -0800 (PST) Received: from boa.med-info.com (boa.med-info.com [204.134.93.3]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id VAA27062 ; Mon, 17 Mar 1997 21:12:58 -0800 (PST) Received: from python.med-info.com (python.med-info.com [204.134.93.18]) by boa.med-info.com (8.8.5/8.8.4) with ESMTP id WAA05995; Mon, 17 Mar 1997 22:10:10 -0700 Received: from gazelle.med-info.com (gazelle.med-info.com [204.134.93.66]) by python.med-info.com (8.8.5/8.8.4) with ESMTP id WAA17277; Mon, 17 Mar 1997 22:10:09 -0700 Received: from localhost (kevin@localhost) by gazelle.med-info.com (8.8.5/8.8.4) with SMTP id WAA05348; Mon, 17 Mar 1997 22:10:09 -0700 X-Authentication-Warning: gazelle.med-info.com: kevin owned process doing -bs Date: Mon, 17 Mar 1997 22:10:09 -0700 (MST) From: Kevin Rosenberg To: hackers@freebsd.org cc: bugs@freebsd.org Subject: INND & 2.2-RELEASE kernel rebooting 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've recently upgraded our news server from FreeBSD v2.1.5 to v2.2. After the upgrade, the server now reboots without warning or error message while running innd. The longest uptime has been about 1 hours with innd. Without innd running, the server does not reboot. I've build a new kernel and increased MAXMEM to 128MB and also increased CHILD_MAX, OPEN_MAX, and MAXUSERS. I've also recompiled innd v1.5.1 without improvement. Swap space is 224MB spread over 3 disks. I've killed all unnecessary daemons. Could someone tell the approach to take for rebooting without warning? Thanks! -------------------------------------------------------------------- Kevin Rosenberg | CyberPort Station Chief System Administrator | The Finest Internet Service Possible! kevin@cyberport.com | http://www.cyberport.com Finger kevin@cyberport.com for PGP Public Key -------------------------------------------------------------------- From owner-freebsd-hackers Mon Mar 17 21:24:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA03332 for hackers-outgoing; Mon, 17 Mar 1997 21:24:57 -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 VAA03313 for ; Mon, 17 Mar 1997 21:24:54 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id VAA27147 for ; Mon, 17 Mar 1997 21:22:15 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA15498; Tue, 18 Mar 1997 15:51:33 +1030 (CST) From: Michael Smith Message-Id: <199703180521.PAA15498@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703180448.UAA13244@lestat.nas.nasa.gov> from Jason Thorpe at "Mar 17, 97 08:47:58 pm" To: thorpej@nas.nasa.gov Date: Tue, 18 Mar 1997 15:51:33 +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 Jason Thorpe stands accused of saying: > > ...err, "kernel linker"?? Thing wot uses simplistic file services to assemble from data on disk (kernel link instructions, object files) a kernel and runs it. > I think what you really want is a 2-stage boot program, much like > Sun's... a primary bootstrap with the block numbers of the second-level > harcoded into it, the secondary has the file system, console, elf/a.out > goop, etc. Bearing in mind that my POV is still fairly x86/FreeBSD-centric, no I do _not_ want block numbers in my bootstrap 8) The 'plan' looks something like this : 1) Media-specific bootstrap (MSB) (disk, net, tape, punchcard) is loaded by platform's boot firmware from supported OS media. 2) MSB loads media-nonspecific bootstrap (MNB) from media. 3) MNB contains multiple media drivers, provides shell-like CLI, simplistic 'OS' services etc. Can run other standalone programs, incl. kernel linker. 4) Kernel linker uses MNB services to obtain basic components for kernel. (core, media-specific drivers etc.) 5) Kernel starts, discards MSB/MNB etc., uses internal linker for load/unload of optional modules. Now, it's quite likely that to do this for, say, a sparc system the MSB may be two parts with one blocklisted in the other, however I'm not looking at changing that at all; I'm targetting a level higher. > I was forwarded a message from Ian Taylor.. I'll see if I can't dig it up. > I'm told it will be in the next release of binutils. Neat. > ...well, it's right there around "write new Fujitsu SCSI driver"... :-) Ick. (Is the old one _that_ bad? Where can documentation on the Fuji part be obtained? This is getting off-thread...) > Jason R. Thorpe thorpej@nas.nasa.gov -- ]] 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 Mar 17 21:46:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA04484 for hackers-outgoing; Mon, 17 Mar 1997 21:46:01 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04471 for ; Mon, 17 Mar 1997 21:45:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id VAA13412; Mon, 17 Mar 1997 21:43:24 -0800 (PST) Message-Id: <199703180543.VAA13412@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith Cc: hackers@freebsd.org Subject: Re: wd driver questions Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 17 Mar 1997 21:43:21 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Mar 1997 15:51:33 +1030 (CST) Michael Smith wrote: > Thing wot uses simplistic file services to assemble from data on > disk (kernel link instructions, object files) a kernel and runs it. ...oh... I rather like just having A Kernel Image and loading it :-) > Bearing in mind that my POV is still fairly x86/FreeBSD-centric, no I do > _not_ want block numbers in my bootstrap 8) ...well, it actually makes somethings a fair bit simpler... Basically, you're talking about two-stage there... but the only reason to use two-stage is space constraints (stupid limit on PCs, space until file system begins on SPARCs, etc.) If you don't hardcode the block numbers of the secondary boot program into the primary, you have to include all the file system reading code, which sort of defeats "small". installboot(8) deals with all of it anyhow, and since you currently have to run something to stash the primary bootstrap into the right sector, it's not that big of a deal :-) > Ick. (Is the old one _that_ bad? Where can documentation on the > Fuji part be obtained? This is getting off-thread...) (Yah, a little off-topic, but what the Hell :-) The current NetBSD/hp300 SCSI driver suffers from the following problems: - doesn't use NetBSD's MI SCSI code - is "simplistic" ... doesn't implement any interesting SCSI features like disconnect/reselect. Hey, when the driver was written, people were happy to have something other than HP-IB... sigh, how times change :-) I have complete documentation on the Fujitsu chip ... What I lack now is the time to work on it. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Mon Mar 17 21:55:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA05031 for hackers-outgoing; Mon, 17 Mar 1997 21:55: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 VAA05000 for ; Mon, 17 Mar 1997 21:54:57 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id VAA27012 for ; Mon, 17 Mar 1997 21:03:12 -0800 (PST) Received: from rover.village.org (localhost [127.0.0.1]) by rover.village.org (8.8.5/8.6.6) with ESMTP id WAA00531 for ; Mon, 17 Mar 1997 22:03:10 -0700 (MST) Message-Id: <199703180503.WAA00531@rover.village.org> To: hackers@freebsd.org Subject: A post 4.4 lite problem... Date: Mon, 17 Mar 1997 22:03:10 -0700 From: Warner Losh Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK. Maybe this has already been reported, but I just hit my first FreeBSD panic that actually saved to the disk (the ones before just rebooted w/o any saves, yes, cores were enabled :-). My kernel: FreeBSD rover.village.org 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Thu Mar 13 20:21:24 MST 1997 imp@rover.village.org:/jaz/FreeBSD/current/src/sys/compile/ROVER i386 (and the rest of the system is a fresh make world from the same time frame) Here's what gdb -k shows (doesn't look too useful, see the end of the dump): GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 203000 current pcb at 1e5d5c panic: page fault #0 0xf0111fb3 in ?? () (kgdb) where #0 0xf0111fb3 in ?? () #1 0xf0112272 in ?? () #2 0xf01b9956 in ?? () #3 0xf01b9444 in ?? () #4 0xf01b911f in ?? () #5 0xf010d660 in ?? () #6 0xf01a1bfd in ?? () #7 0xf0131d78 in ?? () #8 0xf0132704 in ?? () #9 0xf0111e7d in ?? () #10 0xf0112272 in ?? () #11 0xf01b9956 in ?? () #12 0xf01b9444 in ?? () #13 0xf01b911f in ?? () #14 0xf010d660 in ?? () #15 0xf01a1bfd in ?? () #16 0xf0131d78 in ?? () #17 0xf0132704 in ?? () #18 0xf012d58b in ?? () #19 0xf0107ab6 in ?? () #20 0xf0107a54 in ?? () For reasons unknown to me (and I'd like to know why, if anybody knows), none of the symbols were picked up, even though nm showed them. So, since I had a few minutes, I put together a traceback: #0 0xf0111fb3 in boot () #1 0xf0112272 in panic () #2 0xf01b9956 in trap_fatal () #3 0xf01b9444 in trap_pfault () #4 0xf01b911f in trap () #5 0xf010d660 in lockstatus () #6 0xf01a1bfd in ufs_islocked () + 0x15 #7 0xf0131d78 in vfs_msync () + 0x38 #8 0xf0132704 in sync () + 0x4c #9 0xf0111e7d in boot () + 0x75 #10 0xf0112272 in panic () #11 0xf01b9956 in trap_fatal () #12 0xf01b9444 in trap_pfault () #13 0xf01b911f in trap () #14 0xf010d660 in lockstats () #15 0xf01a1bfd in ufs_islocked () + 0x15 #16 0xf0131d78 in vfs_msync () + 0x38 #17 0xf0132704 in sync () + 0x4c #18 0xf012d58b in vfs_update () + 0x3b #19 0xf0107ab6 in kproc_start () + 0x32 #20 0xf0107a54 in main () So the reason that I sent this to -hackers rather than sendpr is that I'm not happy with the scant amount of data here. Can somebody give me a pointer on how to get more info? Right now I'm rebuilding the latest -current kernel config -g to see if that gives me a better dump or not. Thank you for your time and efforts. Warner From owner-freebsd-hackers Mon Mar 17 21:56:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA05221 for hackers-outgoing; Mon, 17 Mar 1997 21:56:39 -0800 (PST) Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05198; Mon, 17 Mar 1997 21:56:34 -0800 (PST) Received: from amdint.amd.com (amdint.amd.com [139.95.250.1]) by amdext.amd.com (8.8.5/8.8.5/AMD) with ESMTP id VAA14583; Mon, 17 Mar 1997 21:56:03 -0800 (PST) Received: from sgp.amd.com (sgp.amd.com [101.0.0.64]) by amdint.amd.com (8.8.5/8.8.5/AMD) with SMTP id VAA15933; Mon, 17 Mar 1997 21:55:58 -0800 (PST) Received: from dahlia.amd.com by sgp.amd.com (4.1/AMDSH-1.20) id AA11343; Tue, 18 Mar 97 13:55:59 SST Received: by dahlia.amd.com (4.0/AMDC-1.20) id AA03426; Tue, 18 Mar 97 13:49:38 SST From: peter@sgp.amd.com (Peter) Message-Id: <9703180549.AA03426@dahlia.amd.com> Subject: unsubscribe To: questions@freebsd.org, hackers@freebsd.org, bugs@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, current@freebsd.org, freebsd-current@freebsd.org, scsi@freebsd.org Date: Tue, 18 Mar 97 13:49:38 WST X-Mailer: ELM [version 2.3 PL8] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Mon Mar 17 22:02:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA05611 for hackers-outgoing; Mon, 17 Mar 1997 22:02:25 -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 WAA05604 for ; Mon, 17 Mar 1997 22:02:15 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id WAA08599; Mon, 17 Mar 1997 22:02:01 -0800 (PST) Message-Id: <199703180602.WAA08599@austin.polstra.com> To: jkh@time.cdrom.com Subject: Re: gcc -shared as substitute for ld -Bshareable? Newsgroups: polstra.freebsd.hackers In-Reply-To: <24425.857903930@time.cdrom.com> References: <24425.857903930@time.cdrom.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Mon, 17 Mar 1997 22:02:01 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <24425.857903930@time.cdrom.com>, Jordan K. Hubbard wrote: > Examining these build files, it really does look like Linux and SunOS > gcc supports -shared flag handling semantics rather different than > ours. Any reason we should be gratuitously different? Shall I file a > PR against this, or is it someone's idea of a feature? :-) It's a bug, and I for one would appreciate it if you'd write a PR against it. The weekly reminder messages might annoy me enough to fix it. -- 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 Mon Mar 17 22:24:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA06883 for hackers-outgoing; Mon, 17 Mar 1997 22:24:56 -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 WAA06853 for ; Mon, 17 Mar 1997 22:24:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id VAA27240 for ; Mon, 17 Mar 1997 21:55:25 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA15812; Tue, 18 Mar 1997 16:24:59 +1030 (CST) From: Michael Smith Message-Id: <199703180554.QAA15812@genesis.atrad.adelaide.edu.au> Subject: Bootstrapping (was Re: wd driver questions) In-Reply-To: <199703180543.VAA13412@lestat.nas.nasa.gov> from Jason Thorpe at "Mar 17, 97 09:43:21 pm" To: thorpej@nas.nasa.gov Date: Tue, 18 Mar 1997 16:24:58 +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 Jason Thorpe stands accused of saying: > > Thing wot uses simplistic file services to assemble from data on > > disk (kernel link instructions, object files) a kernel and runs it. > > ...oh... I rather like just having A Kernel Image and loading it :-) That's nice in it's own way, but it falls short on a few things, like being able to page bits of the kernel, replace bits of it on the fly, load and discard drivers etc. > Basically, you're talking about two-stage there... but the only reason > to use two-stage is space constraints (stupid limit on PCs, space until > file system begins on SPARCs, etc.) Yup. > If you don't hardcode the block numbers of the secondary boot program > into the primary, you have to include all the file system reading code, > which sort of defeats "small". Well, the current FreeBSD bootloader manages that in 7.5K along with a reasonably healthy amount of cruft. > installboot(8) deals with all of it anyhow, and since you currently > have to run something to stash the primary bootstrap into the right > sector, it's not that big of a deal :-) It just grates that you're putting something into the filesystem and then duplicating that information somewhere else. If I throw a new boot program in /boot, I don't necessarily want to have to hardcode its location into the stage-1 bootstrap. Or for that matter what if I want to choose between several different boot programs? -- ]] 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 Mar 17 22:35:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07429 for hackers-outgoing; Mon, 17 Mar 1997 22:35:28 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA07424 for ; Mon, 17 Mar 1997 22:35:24 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA02277 for ; Mon, 17 Mar 1997 22:35:23 -0800 (PST) To: hackers@freebsd.org Subject: Whee! jkh adds his first syscall... Date: Mon, 17 Mar 1997 22:35:23 -0800 Message-ID: <2273.858666923@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The subject alone should have the kernel hackers all running for shelter at this point - "Aigh! He's looking in /usr/src/sys!" they yell. "Somebody stop him!!" :-) Well, OK, maybe I have to confess that I've just always wanted to see what would be involved in adding a system call, and in particular *this* system call in order that I might implement a long-standing wishlist item of mine with redirection and piping (I've got the first part of this, but not the second yet). The system call: int dup3(int oldd, pid_t tpid, int newd) In dup3(), a target process ID and the value of the new descriptor newd is specified in the context of that process. If this descriptor is currently assigned to a valid file, then it will be returned as a new file descriptor in the current process context, otherwise -1 is returned. If the returned file descriptor is not needed then it should be closed. The primary purpose of dup3() is to allow "splicing" of I/O in already-running processes. Yes, I know many will look at the name and go "yuck!" - it's half in jest, OK? :) So what's the use of it? To use in things like shells, so that you can do stuff like this: # make world ^Z%1 Suspended # bg > make.out # This also works with fg, so you can foreground and redirect stdin, stdout and stderr at the same time just as easily. The patches here to sh implement this extra behavior, conditionalized on HAVE_DUP3. Now please note: This really is just proof-of-concept material here for 3 big reasons: 1. Thwapping over another processes's file descriptors is rude, and it generally confuses things like the stdio library to do this. It seems to mostly work OK in my implementation, but I'm sure some sort of "invalidate current buffered fd contents" hack would have to be added to stdio if you wanted to make it all work correctly (try redirecting stdin, for example, and see the slightly odd behavior it has now). 2. The hacks to the shell are exceedingly minimal, and don't implement the more complicated and useful cases like: fg | more or yes | fg Note that it should be perfectly possible, but you'd have to change the way the shell handles these builtins pretty substantially to make it work. Making redirection happen was easy. :-) The changes also only cover /bin/sh, which of course almost nobody uses. If we actually manage to make a useful facility out of this, someone would also have to beat on bash and tcsh. 3. I'm sure there is at least one blatant security hole opened by this mechanism, and I do *ONLY THE MOST MINIMAL* checks for security. More specifically, I compare the euids of from and to, refusing the dup3() if they don't match (or the current euid is 0). This is a very minimal test, and I don't even test for proper parent/child relationship in the non-root case. So use this stuff at your own risk! I'm mostly just releasing it for comments at this point, to find out if I'm really just smoking crack with this whole idea. Patches relative to 2.2-current, thought they should work just as well in 3.0. I also included patches to all the "derived" files from syscalls.master - while not strictly necessary, it saves everyone from having to do anything more than apply this patch from the top of /usr/src and build a new libc, new kernel and new /bin/sh. Feedback most welcome. Jordan Index: bin/sh/Makefile =================================================================== RCS file: /home/ncvs/src/bin/sh/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile --- Makefile 1996/10/25 14:49:24 1.15 +++ Makefile 1997/03/18 06:00:58 @@ -15,7 +15,7 @@ LDADD+= -ll -ledit -ltermcap LFLAGS= -8 # 8-bit lex scanner for arithmetic -CFLAGS+=-DSHELL -I. -I${.CURDIR} +CFLAGS+=-DSHELL -DHAVE_DUP3 -I. -I${.CURDIR} # for debug: # CFLAGS+= -g -DDEBUG=2 Index: bin/sh/jobs.c =================================================================== RCS file: /home/ncvs/src/bin/sh/jobs.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 jobs.c --- jobs.c 1997/01/12 21:58:49 1.8.2.1 +++ jobs.c 1997/03/18 06:00:45 @@ -213,11 +213,20 @@ struct job *jp; { struct procstat *ps; - int i; + int i, fd; if (jp->state == JOBDONE) return; INTOFF; +#ifdef HAVE_DUP3 + for (i = 0; i < 2; i++) { + if (fd_redirected_p(i)) { + fd = dup3(i, jp->ps[0].pid, i); + if (fd != -1) + close(fd); + } + } +#endif killpg(jp->ps[0].pid, SIGCONT); for (ps = jp->ps, i = jp->nprocs ; --i >= 0 ; ps++) { if ((ps->status & 0377) == 0177) { @@ -591,7 +600,7 @@ ignoresig(SIGINT); ignoresig(SIGQUIT); if ((jp == NULL || jp->nprocs == 0) && - ! fd0_redirected_p ()) { + ! fd_redirected_p (0)) { close(0); if (open("/dev/null", O_RDONLY) != 0) error("Can't open /dev/null"); @@ -602,7 +611,7 @@ ignoresig(SIGINT); ignoresig(SIGQUIT); if ((jp == NULL || jp->nprocs == 0) && - ! fd0_redirected_p ()) { + ! fd_redirected_p (0)) { close(0); if (open("/dev/null", O_RDONLY) != 0) error("Can't open /dev/null"); Index: bin/sh/redir.c =================================================================== RCS file: /home/ncvs/src/bin/sh/redir.c,v retrieving revision 1.5 diff -u -r1.5 redir.c --- redir.c 1996/09/01 10:21:36 1.5 +++ redir.c 1997/03/18 05:50:46 @@ -76,11 +76,11 @@ MKINIT struct redirtab *redirlist; /* - * We keep track of whether or not fd0 has been redirected. This is for + * We keep track of whether or not fds 0-2 have been redirected. This is for * background commands, where we want to redirect fd0 to /dev/null only - * if it hasn't already been redirected. + * if it hasn't already been redirected, and for fb/bg redirection to files. */ -int fd0_redirected = 0; +int fd_redirected[3]; STATIC void openredirect __P((union node *, char[10 ])); STATIC int openhere __P((union node *)); @@ -132,8 +132,8 @@ } else { close(fd); } - if (fd == 0) - fd0_redirected++; + if (fd >= 0 && fd <= 2) + fd_redirected[fd]++; openredirect(n, memory); } if (memory[1]) @@ -267,8 +267,8 @@ for (i = 0 ; i < 10 ; i++) { if (rp->renamed[i] != EMPTY) { - if (i == 0) - fd0_redirected--; + if (i >= 0 && i <= 2) + fd_redirected[i]--; close(i); if (rp->renamed[i] >= 0) { copyfd(rp->renamed[i], i); @@ -303,8 +303,11 @@ /* Return true if fd 0 has already been redirected at least once. */ int -fd0_redirected_p () { - return fd0_redirected != 0; +fd_redirected_p (int fd) { + if (fd >= 0 && fd <= 2) + return fd_redirected[fd] != 0; + else + return 0; } /* Index: bin/sh/redir.h =================================================================== RCS file: /home/ncvs/src/bin/sh/redir.h,v retrieving revision 1.3 diff -u -r1.3 redir.h --- redir.h 1996/09/01 10:21:37 1.3 +++ redir.h 1997/03/18 05:51:43 @@ -44,7 +44,7 @@ union node; void redirect __P((union node *, int)); void popredir __P((void)); -int fd0_redirected_p __P((void)); +int fd_redirected_p __P((int)); void clearredir __P((void)); int copyfd __P((int, int)); Index: lib/libc/sys/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/Makefile.inc,v retrieving revision 1.20 diff -u -r1.20 Makefile.inc --- Makefile.inc 1996/09/20 13:55:25 1.20 +++ Makefile.inc 1997/03/17 18:13:35 @@ -14,7 +14,7 @@ # modules with default implementations on all architectures: ASM= accept.o access.o acct.o adjtime.o bind.o chdir.o chflags.o chmod.o \ - chown.o chroot.o close.o connect.o dup.o dup2.o execve.o fchdir.o \ + chown.o chroot.o close.o connect.o dup.o dup2.o dup3.o execve.o fchdir.o \ fchflags.o fchmod.o fchown.o fcntl.o flock.o fpathconf.o fstat.o \ fstatfs.o fsync.o getdirentries.o getdtablesize.o getegid.o \ geteuid.o getfh.o getfsstat.o getgid.o getgroups.o getitimer.o \ @@ -109,6 +109,7 @@ MLINKS+=brk.2 sbrk.2 MLINKS+=dup.2 dup2.2 +MLINKS+=dup.2 dup3.2 MLINKS+=chdir.2 fchdir.2 MLINKS+=chflags.2 fchflags.2 MLINKS+=chmod.2 fchmod.2 Index: lib/libc/sys/dup.2 =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/dup.2,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 dup.2 --- dup.2 1997/03/09 22:16:51 1.3.2.3 +++ dup.2 1997/03/18 06:13:05 @@ -37,7 +37,8 @@ .Os BSD 4 .Sh NAME .Nm dup , -.Nm dup2 +.Nm dup2 , +.Nm dup3 .Nd duplicate an existing file descriptor .Sh SYNOPSIS .Fd #include @@ -45,6 +46,8 @@ .Fn dup "int oldd" .Ft int .Fn dup2 "int oldd" "int newd" +.Ft int +.Fn dup3 "int oldd" "pid_t tpid" "int newd" .Sh DESCRIPTION .Fn Dup duplicates an existing object descriptor and returns its value to @@ -113,6 +116,18 @@ is a valid descriptor, then .Fn dup2 is successful, and does nothing. +.Pp +In +.Fn dup3 , +a target process ID and the value of the new descriptor +.Fa newd +is specified in the context of that process. If this descriptor +is currently assigned to a valid file, then it will be returned +as a new file descriptor in the current process context, otherwise +-1 is returned. If the returned file descriptor is not needed then +it should be closed. The primary purpose of +.Fn dup3 +is to allow "splicing" of I/O in already-running processes. .Sh IMPLEMENTATION NOTES .Pp In the non-threaded library @@ -166,9 +181,10 @@ .Va errno indicates the cause of the error. .Sh ERRORS -.Fn Dup -and +.Fn Dup , .Fn dup2 +and +.Fn dup3 fail if: .Bl -tag -width Er .It Bq Er EBADF @@ -178,6 +194,18 @@ is not a valid active descriptor .It Bq Er EMFILE Too many descriptors are active. +.Pp +.Fn dup3 +will additionally fail if: +.Bl -tag -width Er +.It Bq Er ESRCH +The +.Fa tpid +is not found. +.It Bq Er EPERM +The effective uid of the current process does not match that of +the target process. Only the super user can modify the file descriptor +table of processes with a different euid. .El .Sh SEE ALSO .Xr accept 2 , @@ -202,3 +230,6 @@ .Fn dup2 function call appeared in .At v7 . +The +.Fn dup3 +function call appeared in FreeBSD 3.0 . Index: sys/kern/init_sysent.c =================================================================== RCS file: /home/ncvs/src/sys/kern/init_sysent.c,v retrieving revision 1.36 diff -u -r1.36 init_sysent.c --- init_sysent.c 1996/09/19 19:48:31 1.36 +++ init_sysent.c 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call switch table. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #include @@ -266,7 +266,7 @@ { 3, (sy_call_t *)shmctl }, /* 229 = shmctl */ { 1, (sy_call_t *)shmdt }, /* 230 = shmdt */ { 3, (sy_call_t *)shmget }, /* 231 = shmget */ - { 0, (sy_call_t *)nosys }, /* 232 = nosys */ + { 3, (sy_call_t *)dup3 }, /* 232 = dup3 */ { 0, (sy_call_t *)nosys }, /* 233 = nosys */ { 0, (sy_call_t *)nosys }, /* 234 = nosys */ { 0, (sy_call_t *)nosys }, /* 235 = nosys */ Index: sys/kern/kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.32.2.2 diff -u -r1.32.2.2 kern_descrip.c --- kern_descrip.c 1996/12/21 19:04:24 1.32.2.2 +++ kern_descrip.c 1997/03/18 05:17:28 @@ -149,8 +149,69 @@ } /* - * Duplicate a file descriptor. + * Duplicate a file descriptor to a particular value in another process. */ +#ifndef _SYS_SYSPROTO_H_ +struct dup3_args { + u_int from; + pid_t target; + u_int to; +}; +#endif +/* ARGSUSED */ +int +dup3(p, uap, retval) + struct proc *p; + struct dup3_args *uap; + int *retval; +{ + struct filedesc *tdp, *fdp; + struct proc *t; + struct file *fp, *nfp; + int i, error; + u_int from = uap->from, to = uap->to; + + /* Look up target process and make sure it exists, then set */ + t = pfind(uap->target); + if (!t) + return (ESRCH); + tdp = t->p_fd; + fdp = p->p_fd; + + /* Don't let non-root procs stomp other procs unless euid is the same */ + /* XXX should also put in a check for parentage here in the non-root case XXX */ + if (p->p_ucred->cr_uid && p->p_ucred->cr_uid != t->p_ucred->cr_uid) + return (EPERM); + + if (from >= fdp->fd_nfiles || fdp->fd_ofiles[from] == NULL) + return (EBADF); + if (to >= tdp->fd_nfiles) { + if ((error = fdalloc(t, to, &i))) + return (error); + if (to != i) + panic("dup3: fdalloc"); + *retval = -1; + } + else if (tdp->fd_ofiles[to]) { + if ((error = fdalloc(p, 0, &i))) + return (error); + fdp->fd_ofiles[i] = tdp->fd_ofiles[to]; + fdp->fd_ofileflags[i] = tdp->fd_ofileflags[to] &~ UF_EXCLOSE; + tdp->fd_ofiles[to]->f_count++; + if (i > fdp->fd_lastfile) + fdp->fd_lastfile = i; + *retval = i; + } + tdp->fd_ofiles[to] = fdp->fd_ofiles[from]; + tdp->fd_ofileflags[to] = fdp->fd_ofileflags[from] &~ UF_EXCLOSE; + tdp->fd_ofiles[from]->f_count++; + if (to > tdp->fd_lastfile) + tdp->fd_lastfile = to; + return (0); +} + +/* + * Duplicate a file descriptor. */ #ifndef _SYS_SYSPROTO_H_ struct dup_args { u_int fd; Index: sys/kern/syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.c,v retrieving revision 1.31 diff -u -r1.31 syscalls.c --- syscalls.c 1996/09/19 19:48:34 1.31 +++ syscalls.c 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call names. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ char *syscallnames[] = { @@ -253,7 +253,7 @@ "shmctl", /* 229 = shmctl */ "shmdt", /* 230 = shmdt */ "shmget", /* 231 = shmget */ - "#232", /* 232 = nosys */ + "dup3", /* 232 = dup3 */ "#233", /* 233 = nosys */ "#234", /* 234 = nosys */ "#235", /* 235 = nosys */ Index: sys/kern/syscalls.master =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.master,v retrieving revision 1.29 diff -u -r1.29 syscalls.master --- syscalls.master 1996/09/19 19:48:38 1.29 +++ syscalls.master 1997/03/17 18:06:01 @@ -364,7 +364,7 @@ 230 STD BSD { int shmdt(void *shmaddr); } 231 STD BSD { int shmget(key_t key, int size, int shmflg); } ; -232 UNIMPL NOHIDE nosys +232 STD BSD { int dup3(u_int from, pid_t target, u_int to); } 233 UNIMPL NOHIDE nosys 234 UNIMPL NOHIDE nosys 235 UNIMPL NOHIDE nosys Index: sys/sys/syscall-hide.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall-hide.h,v retrieving revision 1.25 diff -u -r1.25 syscall-hide.h --- syscall-hide.h 1996/09/19 19:49:10 1.25 +++ syscall-hide.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call hiders. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ HIDE_POSIX(fork) @@ -209,5 +209,6 @@ HIDE_BSD(shmctl) HIDE_BSD(shmdt) HIDE_BSD(shmget) +HIDE_BSD(dup3) HIDE_BSD(minherit) HIDE_BSD(rfork) Index: sys/sys/syscall.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall.h,v retrieving revision 1.29 diff -u -r1.29 syscall.h --- syscall.h 1996/09/19 19:49:12 1.29 +++ syscall.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call numbers. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #define SYS_syscall 0 @@ -203,6 +203,7 @@ #define SYS_shmctl 229 #define SYS_shmdt 230 #define SYS_shmget 231 +#define SYS_dup3 232 #define SYS_minherit 250 #define SYS_rfork 251 #define SYS_MAXSYSCALL 252 Index: sys/sys/sysproto.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysproto.h,v retrieving revision 1.15 diff -u -r1.15 sysproto.h --- sysproto.h 1996/09/19 19:49:13 1.15 +++ sysproto.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call prototypes. * * DO NOT EDIT-- this file is automatically generated. - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #ifndef _SYS_SYSPROTO_H_ @@ -716,6 +716,11 @@ int size; int shmflg; }; +struct dup3_args { + u_int from; + pid_t target; + u_int to; +}; struct minherit_args { caddr_t addr; size_t len; @@ -891,6 +896,7 @@ int shmctl __P((struct proc *, struct shmctl_args *, int [])); int shmdt __P((struct proc *, struct shmdt_args *, int [])); int shmget __P((struct proc *, struct shmget_args *, int [])); +int dup3 __P((struct proc *, struct dup3_args *, int [])); int minherit __P((struct proc *, struct minherit_args *, int [])); int rfork __P((struct proc *, struct rfork_args *, int [])); From owner-freebsd-hackers Mon Mar 17 23:04:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09223 for hackers-outgoing; Mon, 17 Mar 1997 23:04:05 -0800 (PST) Received: from boa.med-info.com (boa.med-info.com [204.134.93.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09188; Mon, 17 Mar 1997 23:03:54 -0800 (PST) Received: from python.med-info.com (python.med-info.com [204.134.93.18]) by boa.med-info.com (8.8.5/8.8.4) with ESMTP id AAA06424; Tue, 18 Mar 1997 00:03:21 -0700 Received: from gazelle.med-info.com (gazelle.med-info.com [204.134.93.66]) by python.med-info.com (8.8.5/8.8.4) with ESMTP id AAA17705; Tue, 18 Mar 1997 00:03:21 -0700 Received: from localhost (kevin@localhost) by gazelle.med-info.com (8.8.5/8.8.4) with SMTP id AAA05883; Tue, 18 Mar 1997 00:03:21 -0700 X-Authentication-Warning: gazelle.med-info.com: kevin owned process doing -bs Date: Tue, 18 Mar 1997 00:03:21 -0700 (MST) From: Kevin Rosenberg To: hackers@freebsd.org cc: bugs@freebsd.org Subject: Re: INND & 2.2-RELEASE kernel rebooting 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've recently upgraded our news server from FreeBSD v2.1.5 to v2.2. > After the upgrade, the server now reboots without warning or error message > while running innd. The longest uptime has been about 1 hours with innd. > Without innd running, the server does not reboot. > > I've build a new kernel and increased MAXMEM to 128MB and also increased > CHILD_MAX, OPEN_MAX, and MAXUSERS. I've also recompiled innd v1.5.1 > without improvement. Swap space is 224MB spread over 3 disks. I've killed > all unnecessary daemons. Please disregard the question. I found that increasing NMBCLUSTERS solved the problem. Apologies for the question that I was able to later answer myself. -------------------------------------------------------------------- Kevin Rosenberg | CyberPort Station Chief System Administrator | The Finest Internet Service Possible! kevin@cyberport.com | http://www.cyberport.com Finger kevin@cyberport.com for PGP Public Key -------------------------------------------------------------------- From owner-freebsd-hackers Tue Mar 18 00:09:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA12505 for hackers-outgoing; Tue, 18 Mar 1997 00:09:24 -0800 (PST) Received: from sinbin.demos.su (sinbin.demos.su [194.87.0.31]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12498 for ; Tue, 18 Mar 1997 00:09:18 -0800 (PST) Received: by sinbin.demos.su id LAA24272; (8.6.12/D) Tue, 18 Mar 1997 11:08:39 +0300 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199703180808.LAA24272@sinbin.demos.su> Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h To: davidg@freefall.freebsd.org (David Greenman) Date: Tue, 18 Mar 1997 11:08:39 +0300 (MSK) Cc: hackers@freebsd.org, mishania@demos.su In-Reply-To: <199703171108.DAA05042@freefall.freebsd.org> from "David Greenman" at Mar 17, 97 03:08:22 am X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > davidg 97/03/17 03:08:21 > > Modified: sys/pci if_fxp.c if_fxpreg.h > Log: > Fixed two deficiencies in the driver that have existed since it was > written: > > 1) Full duplex mode is now supported (and works!) > 2) The 10Mbps-only PCI Pro/10 should now work (untested, however) > > Thanks to Justin Gibbs for providing a PCI bus analyzer trace while the > Intel Windows driver was configuring the board...this made it possible > to figure out the mystery bit that I wasn't setting in the PHY for full > duplex to work. > > Revision Changes Path > 1.30 +89 -22 src/sys/pci/if_fxp.c > 1.7 +27 -1 src/sys/pci/if_fxpreg.h > > we check this driver for 2.2-R, but before compiling kernel i change line 1101 in if_fxp.c from error = ether_ioctl(ifp, command, data); to ether_ioctl(ifp, command, data); ^^^^^^^^^^^ is void in 2.2-R after this kernel compiled without any problems ... but full duplex mode not work properly ... in half duplex we have 2400 KBytes/sec via ftp in full duplex we have 20 KBytes/sec as for previous revision of driver ... we have 82557 rev 1 Alex. From owner-freebsd-hackers Tue Mar 18 00:18:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA13032 for hackers-outgoing; Tue, 18 Mar 1997 00:18:10 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA13027 for ; Tue, 18 Mar 1997 00:18:08 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id AAA08467 for ; Tue, 18 Mar 1997 00:18:12 -0800 (PST) Message-Id: <199703180818.AAA08467@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PCI and shared IRQs? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 00:18:11 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Exactly how does the pci code detects which device originated the interrupt in a shared IRQ scenario? Tnks, Amancio From owner-freebsd-hackers Tue Mar 18 00:21:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA13200 for hackers-outgoing; Tue, 18 Mar 1997 00:21:14 -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 AAA13193 for ; Tue, 18 Mar 1997 00:21:11 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA29931; Tue, 18 Mar 1997 09:21:07 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA03522; Tue, 18 Mar 1997 09:09:01 +0100 (MET) Message-ID: <19970318090901.IU02180@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 09:09:01 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: chuckr@Glue.umd.edu (Chuck Robey) Cc: FreeBSD-Hackers@FreeBSD.org (FreeBSD-Hackers) Subject: Re: Intel inteerrupts? References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Chuck Robey on Mar 17, 1997 22:17:40 -0500 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Chuck Robey wrote: > Does anyone know (for certain) what the action is regarding the interrupt > enable flag, when a software INT is invoked for the Intel architecture? > Are interrupts disabled, enabled, or what? External (hardware) interrupts on the INT pin are disabled. External interrupts on the NMI pins are still not masked, nor are any kind of traps. The INT instruction is poorly named, and should better have called TRAP in order to avoid the confusion. It does by no way `interrupt' something, it's just a special kind of a CALL instruction with a short (and rather `symbolic') target address. CPUs used to have such a mechanism all the time, see the RST (restart) instructions in the i8080/Z80. All other kinds of traps also remain enabled. You can get a SIGSEGV even if the kernel has external interrupts totally disabled. ;-) > If you have an answer, and IF you know somewhere I can read to verify it, > I'd really appreciate your posting it. I've had several folks give me > their (conflicting) opinions, and now I'm looking for confirmation. Sorry, my only written reference to this is a German programmer's ref for the 80286. You can for sure simply prove this. Just single-step through the disable_intr() part of a sio interrupt service in FreeBSD using DDB. This clearly shows that traps (breakpoint traps in this case) are still working. -- 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 Mar 18 00:21:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA13298 for hackers-outgoing; Tue, 18 Mar 1997 00:21: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 AAA13285 for ; Tue, 18 Mar 1997 00:21:49 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA29941 for hackers@freebsd.org; Tue, 18 Mar 1997 09:21:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA03572; Tue, 18 Mar 1997 09:19:03 +0100 (MET) Message-ID: <19970318091903.RF05856@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 09:19:03 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: A really minor annoyance References: <199703180327.TAA15908@kithrup.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199703180327.TAA15908@kithrup.com>; from Sean Eric Fagan on Mar 17, 1997 19:27:52 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Sean Eric Fagan wrote: > in kern/uipc_syscalls.c. Thus, "connec" shows up if you do a control-T (or > whatever you have status set to) while something is waiting there. > > "connec" is *really* annoying. Why isn't it "connect"? Probably because somebody decided that ps(1) shows only the first six characters, and forgot about ^T and DDB. -- 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 Mar 18 00:55:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA14991 for hackers-outgoing; Tue, 18 Mar 1997 00:55:00 -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 AAA14967 for ; Tue, 18 Mar 1997 00:54:56 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id AAA28191 for ; Tue, 18 Mar 1997 00:26:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id AAA08645; Tue, 18 Mar 1997 00:27:27 -0800 (PST) Message-Id: <199703180827.AAA08645@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: bag@sinbin.demos.su (Alex G. Bulushev) cc: hackers@freebsd.org, mishania@demos.su Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h In-reply-to: Your message of "Tue, 18 Mar 1997 11:08:39 +0300." <199703180808.LAA24272@sinbin.demos.su> From: David Greenman Reply-To: dg@root.com Date: Tue, 18 Mar 1997 00:27:27 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> davidg 97/03/17 03:08:21 >> >> Modified: sys/pci if_fxp.c if_fxpreg.h >> Log: >> Fixed two deficiencies in the driver that have existed since it was >> written: >> >> 1) Full duplex mode is now supported (and works!) >> 2) The 10Mbps-only PCI Pro/10 should now work (untested, however) >> >> Thanks to Justin Gibbs for providing a PCI bus analyzer trace while the >> Intel Windows driver was configuring the board...this made it possible >> to figure out the mystery bit that I wasn't setting in the PHY for full >> duplex to work. >> >> Revision Changes Path >> 1.30 +89 -22 src/sys/pci/if_fxp.c >> 1.7 +27 -1 src/sys/pci/if_fxpreg.h >> >> > >we check this driver for 2.2-R, >but before compiling kernel i change line 1101 in if_fxp.c from > error = ether_ioctl(ifp, command, data); >to > ether_ioctl(ifp, command, data); > ^^^^^^^^^^^ is void in 2.2-R > >after this kernel compiled without any problems ... Why don't you just use the version that I committed to the 2.2 branch? The above change is not sufficient for the driver to work correctly in all cases (but this has nothing to do with your performance problem). >but full duplex mode not work properly ... > >in half duplex we have 2400 KBytes/sec via ftp >in full duplex we have 20 KBytes/sec as for previous revision of driver ... > >we have 82557 rev 1 What is the card connected to? It must be connected to a fast ethernet switch in order for full duplex mode to work. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Mar 18 00:56:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA15473 for hackers-outgoing; Tue, 18 Mar 1997 00:56:43 -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 AAA15442 for ; Tue, 18 Mar 1997 00:56:38 -0800 (PST) Received: from jump.net (serv1-2.jump.net [204.238.120.19]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id XAA27859 for ; Mon, 17 Mar 1997 23:32:04 -0800 (PST) Received: from benjamin.adonai.com by jump.net (8.8.5/BERK-6.8.11) id BAA19092; Tue, 18 Mar 1997 01:31:58 -0600 (CST) Message-Id: <1.5.4.32.19970318073133.0069556c@jump.net> X-Sender: adonai@jump.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 01:31:33 -0600 To: hackers@freebsd.org From: Lee Crites Subject: still more digiboard and modem questions/problems... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have come to the conclusion that using a digiboard was not my best move. I'm *still* trying to get these things up and running, without success. It seems to me that I must be very close to the answer, but just far enough off that it isn't working. So here is my plea to all kind souls out there to please help me figure out what I'm missing... My problem(s) is (are) this: No matter what configuration I set all four of them to, they don't all act the same, and so far, none have worked properly, not even once. What is strange is that D00 and D03 seem to work the same and D01 and D02 seem to work the same. If I set all four to config 'A' then D00/D03 will act one way and D01/D02 work another. Use config 'B', D00/D03 do something and D01/D02 do something else. Yes, I tried swapping the modems and the problems follow the port, not the modem. In fact, I got two pc's so I could test, and can get them set up so that I can dial in or out to either machine from either modem. There were still some wierdness here and there, but I could put both pc's into procomm, go into 'host' mode and type away. I can set up the modems so they work between the pc's fine, then plug them into the digiboard and have problems. They connect, but nothing else happens. So, here's the scoop. I wasn't sure what anyone would want or need, so at the risk of a serious info overload, here's everything I think might have anything to do with the situation. * the server is a p133/128meg ram, 2.1gig scsi hdd, with fbsd 2.2 (via ctm) * the digiboard (PC/8e) is physically installed in the server (not coming in via the net from a terminal server box) * I only have four modems at this time, so I am using ports 0-3 on it. The modems are Practical Peripherals 33.4, and all appear to be identical. * using the dgb device driver in the kernel, using this line to configure it: device dgb0 at isa? port 0x100 iomem 0x0a0000 iosiz ? tty * the digiboard seems to be found and recognized, per these bootup messages: Mar 15 21:03:31 adam /kernel: dgb0: PC/Xe 64/8K (windowed) Mar 15 21:03:31 adam /kernel: dgb0 at 0x100-0x103 maddr 0xa0000 msize 8192 on isa Mar 15 21:03:31 adam /kernel: dgb0: 8 ports * the device(s) were built using MAKEDEV, which generated the following: crw-rw---- 1 uucp modem 58, 128 Mar 16 03:03 cuaD00 crw------- 1 root wheel 58, 129 Mar 18 00:24 cuaD01 crw------- 1 root wheel 58, 130 Mar 16 02:44 cuaD02 crw------- 1 root wheel 58, 131 Mar 17 14:10 cuaD03 crw-rw-rw- 1 uucp modem 58, 132 Mar 14 14:26 cuaD04 crw-rw-rw- 1 uucp modem 58, 133 Mar 14 14:26 cuaD05 crw-rw-rw- 1 uucp modem 58, 134 Mar 14 14:26 cuaD06 crw-rw-rw- 1 uucp modem 58, 135 Mar 14 14:26 cuaD07 crw-rw-rw- 1 uucp dialer 58, 160 Mar 5 09:16 cuaiD00 crw-rw-rw- 1 uucp dialer 58, 161 Mar 5 09:16 cuaiD01 crw-rw-rw- 1 uucp dialer 58, 162 Mar 5 09:16 cuaiD02 crw-rw-rw- 1 uucp dialer 58, 163 Mar 5 09:16 cuaiD03 crw-rw-rw- 1 uucp dialer 58, 164 Mar 5 09:16 cuaiD04 crw-rw-rw- 1 uucp dialer 58, 165 Mar 5 09:16 cuaiD05 crw-rw-rw- 1 uucp dialer 58, 166 Mar 5 09:16 cuaiD06 crw-rw-rw- 1 uucp dialer 58, 167 Mar 5 09:16 cuaiD07 crw-rw-rw- 1 uucp dialer 58, 192 Mar 5 09:16 cualD00 crw-rw-rw- 1 uucp dialer 58, 193 Mar 5 09:16 cualD01 crw-rw-rw- 1 uucp dialer 58, 194 Mar 5 09:16 cualD02 crw-rw-rw- 1 uucp dialer 58, 195 Mar 5 09:16 cualD03 crw-rw-rw- 1 uucp dialer 58, 196 Mar 5 09:16 cualD04 crw-rw-rw- 1 uucp dialer 58, 197 Mar 5 09:16 cualD05 crw-rw-rw- 1 uucp dialer 58, 198 Mar 5 09:16 cualD06 crw-rw-rw- 1 uucp dialer 58, 199 Mar 5 09:16 cualD07 crw------- 1 root wheel 58, 0 Mar 10 08:38 ttyD00 crw------- 1 root wheel 58, 1 Mar 14 13:07 ttyD01 crw------- 1 root wheel 58, 2 Mar 5 09:16 ttyD02 crw------- 1 root wheel 58, 3 Mar 5 14:09 ttyD03 crw-rw-rw- 1 uucp dialer 58, 4 Mar 5 09:16 ttyD04 crw-rw-rw- 1 uucp dialer 58, 5 Mar 5 09:16 ttyD05 crw-rw-rw- 1 uucp dialer 58, 6 Mar 5 09:16 ttyD06 crw-rw-rw- 1 uucp dialer 58, 7 Mar 5 09:16 ttyD07 crw-rw-rw- 1 uucp dialer 58, 32 Mar 5 09:16 ttyiD00 crw-rw-rw- 1 uucp dialer 58, 33 Mar 5 09:16 ttyiD01 crw-rw-rw- 1 uucp dialer 58, 34 Mar 5 09:16 ttyiD02 crw-rw-rw- 1 uucp dialer 58, 35 Mar 5 09:16 ttyiD03 crw-rw-rw- 1 uucp dialer 58, 36 Mar 5 09:16 ttyiD04 crw-rw-rw- 1 uucp dialer 58, 37 Mar 5 09:16 ttyiD05 crw-rw-rw- 1 uucp dialer 58, 38 Mar 5 09:16 ttyiD06 crw-rw-rw- 1 uucp dialer 58, 39 Mar 5 09:16 ttyiD07 crw-rw-rw- 1 uucp dialer 58, 64 Mar 5 09:16 ttylD00 crw-rw-rw- 1 uucp dialer 58, 65 Mar 5 09:16 ttylD01 crw-rw-rw- 1 uucp dialer 58, 66 Mar 5 09:16 ttylD02 crw-rw-rw- 1 uucp dialer 58, 67 Mar 5 09:16 ttylD03 crw-rw-rw- 1 uucp dialer 58, 68 Mar 5 09:16 ttylD04 crw-rw-rw- 1 uucp dialer 58, 69 Mar 5 09:16 ttylD05 crw-rw-rw- 1 uucp dialer 58, 70 Mar 5 09:16 ttylD06 crw-rw-rw- 1 uucp dialer 58, 71 Mar 5 09:16 ttylD07 ALL of them used to say uucp:dialer. What changes them is a mystery to me. I know that from time to time I have to chmod rw-rw-rw- to make them usable. But why they change in the first place is beyond me. I can say that if cu/tip don't exit properly (using ^c insteaf of using ~.), then the perms will be set to 600:root:wheel, but other than that, I'm in the dark... * I added these records to /etc/ttys: ttyD00 "/usr/libexec/getty std.57600" dialup on insecure ttyD01 "/usr/libexec/getty std.57600" dialup on insecure ttyD02 "/usr/libexec/getty std.57600" dialup on insecure ttyD03 "/usr/libexec/getty std.57600" dialup on insecure ttyD04 "/usr/libexec/getty std.57600" dialup off insecure ttyD05 "/usr/libexec/getty std.57600" dialup off insecure ttyD06 "/usr/libexec/getty std.57600" dialup off insecure ttyD07 "/usr/libexec/getty std.57600" dialup off insecure #cuaD00 "/usr/libexec/getty std.57600" dialup on insecure cuaD01 "/usr/libexec/getty std.57600" dialup on insecure cuaD02 "/usr/libexec/getty std.57600" dialup on insecure cuaD03 "/usr/libexec/getty std.57600" dialup on insecure cuaD04 "/usr/libexec/getty std.57600" dialup off insecure cuaD05 "/usr/libexec/getty std.57600" dialup off insecure cuaD06 "/usr/libexec/getty std.57600" dialup off insecure cuaD07 "/usr/libexec/getty std.57600" dialup off insecure cuaD00 "/usr/local/sbin/mgetty" dialup on insecure #cuaD01 "/usr/local/sbin/mgetty" dialup on insecure #cuaD02 "/usr/local/sbin/mgetty" dialup on insecure #cuaD03 "/usr/local/sbin/mgetty" dialup on insecure #cuaD04 "/usr/local/sbin/mgetty" dialup off insecure #cuaD05 "/usr/local/sbin/mgetty" dialup off insecure #cuaD06 "/usr/local/sbin/mgetty" dialup off insecure #cuaD07 "/usr/local/sbin/mgetty" dialup off insecure I got a suggestion to use mgetty instead of getty, so I compiled and installed it from the ports area. As you can see, I'm testing one of both (cuaD00 as mgetty and cuaD01 as getty). * using various programs (cu and tip on fbsd, procomm on a pc), I have configured the modems like this: b1 e1 l3 m1 q0 v1 w0 x4 &b1 &c1 &d3 &g0 &l0 &p0 &r0 &s0 &x0 &y0 s0:001 s1:000 s2:255 s3:013 s4:010 s5:008 s6:002 s7:050 s8:002 s9:006 s10:014 s11:095 s12:050 s18:000 s25:005 s26:001 s37:000 s72:000 * and, finally, stty -a -f /dev/cuaD00 shows (all four match): speed 57600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk -brkint -inpck -ignpar -parmrk oflags: -opost -onlcr -oxtabs cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; eol2 = ; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ; stop = ^S; susp = ^Z; time = 0; werase = ^W; [side question: Isn't there a way to export the stty settings from one port and add them to another? I remember doing something like this long ago but don't remember how it was done. I tried "stty -g -f /dev/cuaD01 < /dev/cuaD00", but it didn't seem to work the way I thought it should...] So, my kind and dear friends, bearers of good tidings, singers of songs, and general people of awesomeness... What am I missing? Should this work as is, and I have hardware problems? Am I still missing something? Am I even close? Any pointers greatly appreciated... Lee From owner-freebsd-hackers Tue Mar 18 00:59:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA16254 for hackers-outgoing; Tue, 18 Mar 1997 00:59: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 AAA16237 for ; Tue, 18 Mar 1997 00:59:02 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id UAA26947 for ; Mon, 17 Mar 1997 20:52:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id UAA13244; Mon, 17 Mar 1997 20:48:00 -0800 (PST) Message-Id: <199703180448.UAA13244@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith Cc: terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: wd driver questions Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 17 Mar 1997 20:47:58 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Mar 1997 15:08:27 +1030 (CST) Michael Smith wrote: > Aha. One of the ideas I was toying with was having a 'standalone > shell' which would then load the kernel linker, which then would load > the kernel proper. Then as long as the standalone shell understood > the objhect format the other standalone tools were built with, you > could swap kernel linkers to suit the flavour of the day. ...err, "kernel linker"?? I think what you really want is a 2-stage boot program, much like Sun's... a primary bootstrap with the block numbers of the second-level harcoded into it, the secondary has the file system, console, elf/a.out goop, etc. > > I think this will be changing soon, however. Now that the FSF has a sane > > way of saying "This ELF binary is for this OS", I've put the following on > > my NetBSD/hp300 TODO list: > > They do? Do you have a reference for this method? I was forwarded a message from Ian Taylor.. I'll see if I can't dig it up. I'm told it will be in the next release of binutils. > > - make ELF work on NetBSD m68k > > Hmm, I have one of these things (as I guess you've noticed 8), so > naturally I'm interested in that too 8) hehe :-) > > ...but it's not a priority right now... too many other things to do :-) > > Dang! ...well, it's right there around "write new Fujitsu SCSI driver"... :-) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Tue Mar 18 02:39:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA20063 for hackers-outgoing; Tue, 18 Mar 1997 02:39:53 -0800 (PST) Received: from nyx.pr.mcs.net (nyx.pr.mcs.net [204.95.55.81]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA20057 for ; Tue, 18 Mar 1997 02:39:47 -0800 (PST) Received: from nyx.pr.mcs.net (localhost [127.0.0.1]) by nyx.pr.mcs.net (8.8.5/8.8.4) with ESMTP id EAA03782 for ; Tue, 18 Mar 1997 04:39:04 -0600 (CST) Message-Id: <199703181039.EAA03782@nyx.pr.mcs.net> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: ep driver memory management question.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 04:39:03 -0600 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm not very familiar with net drivers, but I would like to rewrite the ep driver to use contiguous packet buffers. I am curious about how it allocates memory for packets, and if there are any limitations. From the code, it looks as if it just allocates an mbuf, dmas into it, and passes it off to ether_input. Is this correct? I thought that there was a 16M limit on dma for the isa bus without bouncing, but I didn't see anything that dealt with this. Is this because all the mbufs get allocated at boot, so its just the way it turns out? If so, I will need to allocate a contiguous chunk of memory for the driver upon boot. How would I do this? Thanks, Chris Csanady From owner-freebsd-hackers Tue Mar 18 03:17:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA21089 for hackers-outgoing; Tue, 18 Mar 1997 03:17:01 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA21083 for ; Tue, 18 Mar 1997 03:16:52 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.0.31] with ESMTP id OAA19100; Tue, 18 Mar 1997 14:16:01 +0300 Received: by sinbin.demos.su id OAA10806; (8.6.12/D) Tue, 18 Mar 1997 14:15:29 +0300 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199703181115.OAA10806@sinbin.demos.su> Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h To: dg@root.com Date: Tue, 18 Mar 1997 14:15:29 +0300 (MSK) Cc: hackers@freebsd.org, mishania@demos.su In-Reply-To: <199703180827.AAA08645@root.com> from "David Greenman" at Mar 18, 97 00:27:27 am X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > What is the card connected to? It must be connected to a fast ethernet > switch in order for full duplex mode to work. we use BayStack 28115 Fast Ethernet Switch and can change modes on it's ports result table via ftp test: side1 side2 speed solaris 2.5.1 100Mb/full solaris 2.5.1 100Mb/full 4700 MBytes/sec solaris 2.5.1 100Mb/full fbsd de 10Mb/half 740 MBytes/sec fbsd fxp 10Mb/half fbsd de 10Mb/half 980 MBytes/sec fbsd fxp 100Mb/half fbsd de 10Mb/half 980 MBytes/sec fbsd fxp 100Mb/half solaris 2.5.1 100Mb/full 2900 MBytes/sec fbsd fxp 100Mb/full fbsd de 10Mb/half 980 MBytes/sec fbsd fxp 100Mb/full solaris 2.5.1 100Mb/full 20 MBytes/sec Alex. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Tue Mar 18 07:59:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA00341 for hackers-outgoing; Tue, 18 Mar 1997 07:59:55 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA00310 for ; Tue, 18 Mar 1997 07:59:49 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id LAA01249; Tue, 18 Mar 1997 11:00:38 -0500 (EST) Message-Id: <3.0.32.19970318105613.00b2db60@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Mar 1997 10:56:25 -0500 To: "Jordan K. Hubbard" From: dennis Subject: 2.2 Installation "problem" 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 There doesnt seem to be any way to "unselect" a menu item....specifically in the "Choose Distributions" menu. If I cancel they are still selected. Please help.... Dennis From owner-freebsd-hackers Tue Mar 18 08:28:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA03077 for hackers-outgoing; Tue, 18 Mar 1997 08:28:35 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA03059 for ; Tue, 18 Mar 1997 08:28:32 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id IAA16505; Tue, 18 Mar 1997 08:28:15 -0800 (PST) To: dennis cc: hackers@freebsd.org Subject: Re: 2.2 Installation "problem" In-reply-to: Your message of "Tue, 18 Mar 1997 10:56:25 EST." <3.0.32.19970318105613.00b2db60@etinc.com> Date: Tue, 18 Mar 1997 08:28:15 -0800 Message-ID: <16501.858702495@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You're not looking far enough down in the menu - look at option #9! > > There doesnt seem to be any way to "unselect" a menu item....specifically > in the "Choose Distributions" menu. If I cancel they are still selected. > Please help.... > > > Dennis From owner-freebsd-hackers Tue Mar 18 08:31:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA03862 for hackers-outgoing; Tue, 18 Mar 1997 08:31:54 -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 IAA03842 for ; Tue, 18 Mar 1997 08:31:50 -0800 (PST) Received: from ceniai.inf.cu ([169.158.128.138]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id GAA29955 for ; Tue, 18 Mar 1997 06:51:02 -0800 (PST) Received: from comuh.uh.cu by ceniai.inf.cu with UUCP (Smail3.1.29.1) id m0w6vXg-00027eC; Tue, 18 Mar 97 09:50 Received: by comuh.uh.cu (5.65/1.2-eef) id AA01603; Tue, 18 Mar 97 09:13:20 -0500 Date: Tue, 18 Mar 1997 09:13:20 -0500 (EST) From: Ignacio Machin Rdguez X-Sender: machin@comuh To: hackers@FreeBSD.ORG Subject: Problemas con el correo 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 A got a problem here it seems that somethings( or somebody) is playing with the mail sistem, it seem that "something" is distributing randomly the mesg so the users get the wrong mesg and do not receive the proper mesg. Any help? Thank you From owner-freebsd-hackers Tue Mar 18 08:36:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA04903 for hackers-outgoing; Tue, 18 Mar 1997 08:36:35 -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 IAA04872 for ; Tue, 18 Mar 1997 08:36:29 -0800 (PST) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id FAA29120 for ; Tue, 18 Mar 1997 05:29:25 -0800 (PST) Received: (from joe@localhost) by florence.pavilion.net (8.8.5/8.8.5) id NAA03024; Tue, 18 Mar 1997 13:27:38 GMT Message-ID: <19970318132737.21987@pavilion.net> Date: Tue, 18 Mar 1997 13:27:37 +0000 From: Josef Karthauser To: freebsd-hackers-digest@FreeBSD.ORG Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073] From owner-freebsd-hackers Tue Mar 18 08:37:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA05144 for hackers-outgoing; Tue, 18 Mar 1997 08:37: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 IAA05123 for ; Tue, 18 Mar 1997 08:37:28 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id FAA29202 for ; Tue, 18 Mar 1997 05:43:27 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id HAA28608; Tue, 18 Mar 1997 07:30:04 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma028603; Tue Mar 18 07:29:57 1997 Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.11.142]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id HAA32761; Tue, 18 Mar 1997 07:30:00 -0600 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.3/8.6.12) with ESMTP id HAA28482; Tue, 18 Mar 1997 07:30:07 -0600 (CST) Message-Id: <199703181330.HAA28482@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Lee Crites cc: hackers@FreeBSD.ORG Subject: Re: still more digiboard and modem questions/problems... In-reply-to: Your message of "Tue, 18 Mar 1997 01:31:33 CST." <1.5.4.32.19970318073133.0069556c@jump.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 07:30:06 -0600 From: John Prince Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Lee Crites writes: > I have come to the conclusion that using a digiboard was not my best move. I Agree... > ALL of them used to say uucp:dialer. What changes them is a mystery to me. > I know that from time to time I have to chmod rw-rw-rw- to make them usable. > But why they change in the first place is beyond me. I can say that if > cu/tip don't exit properly (using ^c insteaf of using ~.), then the perms > will be set to 600:root:wheel, but other than that, I'm in the dark... Add yourself and/or all users the need to access the tty to the group dialer.. > * I added these records to /etc/ttys: > ttyD00 "/usr/libexec/getty std.57600" dialup on insecure > ttyD01 "/usr/libexec/getty std.57600" dialup on insecure > ttyD02 "/usr/libexec/getty std.57600" dialup on insecure > ttyD03 "/usr/libexec/getty std.57600" dialup on insecure > ttyD04 "/usr/libexec/getty std.57600" dialup off insecure > ttyD05 "/usr/libexec/getty std.57600" dialup off insecure > ttyD06 "/usr/libexec/getty std.57600" dialup off insecure > ttyD07 "/usr/libexec/getty std.57600" dialup off insecure > #cuaD00 "/usr/libexec/getty std.57600" dialup on insecure > cuaD01 "/usr/libexec/getty std.57600" dialup on insecure > cuaD02 "/usr/libexec/getty std.57600" dialup on insecure > cuaD03 "/usr/libexec/getty std.57600" dialup on insecure > cuaD04 "/usr/libexec/getty std.57600" dialup off insecure > cuaD05 "/usr/libexec/getty std.57600" dialup off insecure > cuaD06 "/usr/libexec/getty std.57600" dialup off insecure > cuaD07 "/usr/libexec/getty std.57600" dialup off insecure > cuaD00 "/usr/local/sbin/mgetty" dialup on insecure It not a good idea to enable both Dialout and Dialin, probably part of your problem. Set the correct device here (ttyD). > I got a suggestion to use mgetty instead of getty, so I compiled and > installed it from the ports area. As you can see, I'm testing one of both > (cuaD00 as mgetty and cuaD01 as getty). I Agree.. Try using Mgetty. > [side question: Isn't there a way to export the stty settings from one port > and add them to another? I remember doing something like this long ago but > don't remember how it was done. I tried "stty -g -f /dev/cuaD01 < > /dev/cuaD00", but it didn't seem to work the way I thought it should...] A better way is to use rc.serial.. Have you initialized your ttys?? (look at /etc/rc.serial, uncomment the line under Digiboard.. Good Luck John -- John Prince From owner-freebsd-hackers Tue Mar 18 08:38:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA05381 for hackers-outgoing; Tue, 18 Mar 1997 08:38:40 -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 IAA05324 for ; Tue, 18 Mar 1997 08:38:26 -0800 (PST) From: proff@suburbia.net Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id EAA28864 for ; Tue, 18 Mar 1997 04:57:20 -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 EAA10881 for ; Tue, 18 Mar 1997 04:58:09 -0800 (PST) Received: (qmail 9152 invoked by uid 110); 18 Mar 1997 12:55:22 -0000 Date: 18 Mar 1997 12:55:22 -0000 Message-ID: <19970318125522.9151.qmail@suburbia.net> To: hackers@FreeBSD.ORG Subject: -current mount.h Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Seems to be missing most of the per-fs structs (iso_args, msdos_args, ufs_args, nfs_args etc), that were used by mount(2). Is this an oversight? From owner-freebsd-hackers Tue Mar 18 08:38:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA05424 for hackers-outgoing; Tue, 18 Mar 1997 08:38: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 IAA05375 for ; Tue, 18 Mar 1997 08:38:39 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id FAA29037 for ; Tue, 18 Mar 1997 05:17:57 -0800 (PST) Message-Id: <199703181317.FAA29037@who.cdrom.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA073920826; Wed, 19 Mar 1997 00:13:46 +1100 From: Darren Reed Subject: further on 2.1.6 & 2940 To: hackers@FreeBSD.ORG Date: Wed, 19 Mar 1997 00:13:46 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk using the scsi command to look at the mode pages: # scsi -f /dev/rst0.ctl -m 0 69 78 00 00 00 00 00 00 00 00 00 # scsi -f /dev/rst0.ctl -m 1 AWRE (Auto Write Reallocation Enbld): 0 ARRE (Auto Read Reallocation Enbld): 0 TB (Transfer Block): 1 RC (Read Continuous): 0 EER (Enable Early Recovery): 1 PER (Post Error): 0 # scsi -f /dev/rst0.ctl -m 3 SCIOCCOMMAND ioctl: Command accepted. return status 3 (Sense Returned) host adapter status 2 Command out (6 of 6): 1a 00 03 00 ff 00 Data in (0 of 255): Error code is "current errors" Segment number is 00 Sense key is "Illegal request" The Information field is not valid but contains 00000000 (0). The Command Specific Information field is 00000000 (0). Additional sense code: 24 Additional sense code qualifier: 00 Illegal value in the command descriptor block. Bit 5 of byte 2 (value 03) is illegal. sense (32 of 48): 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 cd 00 02 38 2e 36 2e 39 2f 6b 6a d7 b5 50 10 44 70 What's this "Bit 5 of byte 2 (value 03) is illegal." mean ? I assume only mode pages 1-3 mean anything, everything after 3 is a repeast of 3. From owner-freebsd-hackers Tue Mar 18 08:38:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA05464 for hackers-outgoing; Tue, 18 Mar 1997 08:38:56 -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 IAA05423 for ; Tue, 18 Mar 1997 08:38:48 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id EAA28875 for ; Tue, 18 Mar 1997 04:59:54 -0800 (PST) Message-Id: <199703181259.EAA28875@who.cdrom.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA070189724; Tue, 18 Mar 1997 23:55:24 +1100 From: Darren Reed Subject: Re: dds tape drives. To: tinguely@plains.nodak.edu (Mark Tinguely) Date: Tue, 18 Mar 1997 23:55:24 +1100 (EDT) Cc: darrenr@cyber.com.au, hackers@FreeBSD.ORG In-Reply-To: <199703171812.MAA27625@plains.nodak.edu> from "Mark Tinguely" at Mar 17, 97 12:12:33 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 Mark Tinguely, sie said: > > a long time ago, I added the files and block counts to the /sys/scsi/st.c > (basically you add/subtract after every read/write/movement command -- > watch out for command residuals). > > The scsi maintainers of the time did not choose to add the changes, and > around FreeBSD 2.0.5, I got tired of manually editing them after every > OS change and I quit. I don't even have one copy of the changes. Does someone still have them ? btw, while people are thinking about 2940 SCSI problems (2.1.6-RELEASE): Mar 18 22:33:50 freebsd /kernel: st0(ahc0:4:0): timed out in dataout phase, SCSISIGI == 0x6 Mar 18 22:33:50 freebsd /kernel: ahc0: Issued Channel A Bus Reset #2. 1 SCBs aborted Mar 18 22:33:50 freebsd /kernel: st0(ahc0:4:0): Target Busy Mar 18 22:33:50 freebsd last message repeated 17 times Mar 18 22:34:00 freebsd /kernel: st0(ahc0:4:0): NOT READY asc:4,1 Mar 18 22:34:00 freebsd /kernel: st0(ahc0:4:0): Logical unit is in process of becoming ready Mar 18 22:40:11 freebsd /kernel: st0(ahc0:4:0): timed out in dataout phase, SCSISIGI == 0x6 Mar 18 22:40:11 freebsd /kernel: ahc0: Issued Channel A Bus Reset #2. 1 SCBs aborted Mar 18 22:40:11 freebsd /kernel: st0(ahc0:4:0): Target Busy Mar 18 22:40:11 freebsd last message repeated 17 times From owner-freebsd-hackers Tue Mar 18 08:42:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA06079 for hackers-outgoing; Tue, 18 Mar 1997 08:42:01 -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 IAA06029 for ; Tue, 18 Mar 1997 08:41:42 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id EAA28834 for ; Tue, 18 Mar 1997 04:51:52 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27514; Tue, 18 Mar 1997 07:50:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 18 Mar 1997 07: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 HAA08723; Tue, 18 Mar 1997 07:20:18 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA01010; Tue, 18 Mar 1997 07:25:38 -0500 (EST) Date: Tue, 18 Mar 1997 07:25:38 -0500 (EST) From: Thomas David Rivers Message-Id: <199703181225.HAA01010@lakes.water.net> To: ponds!time.cdrom.com!jkh@ucbvax.Berkeley.EDU Subject: Re: Another problems with aha2940 in 2.1-STABLE (post 2.1.7) - process stuck. Cc: ponds!freebsd.org!hackers@ucbvax.Berkeley.EDU Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Also, the following messages appeared on the console: > > sd0(ahc0:0:0): SCB 0x4 - timed out in command phase, SCSISIGI == 0x84 > > SEQADDR == 0x61 > > st0(ahc0:2:0): abort message in message buffer > > Looks familiar. Wait for David to commit Justin's SCSI driver > fixes to -stable; he's currently testing them on wcarchive. > > Jordan > Sure.. Did these fixes make it into 2.2-RELEASE? Or, will I need to grab 2.2-STABLE when I upgrade? - Dave Rivers - From owner-freebsd-hackers Tue Mar 18 08:57:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA07385 for hackers-outgoing; Tue, 18 Mar 1997 08:57:23 -0800 (PST) Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA07379 for ; Tue, 18 Mar 1997 08:57:20 -0800 (PST) Received: from aduxb.fnal.gov ("port 34088"@aduxb.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGN8W1PNFC000KDK@FNAL.FNAL.GOV> for hackers@freefall.freebsd.org; Tue, 18 Mar 1997 10:57:18 -0600 Received: from localhost by aduxb.fnal.gov (5.x/SMI-SVR4) id AA07455; Tue, 18 Mar 1997 10:57:14 -0600 Date: Tue, 18 Mar 1997 10:57:08 -0600 (CST) From: Richard Neswold Subject: Re: Whee! jkh adds his first syscall... In-reply-to: <199703180635.WAA07438@freefall.freebsd.org> To: hackers@freefall.freebsd.org Reply-to: neswold@FNAL.GOV Message-id: 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 Mon, 17 Mar 1997, Jordan K. Hubbard wrote: > The subject alone should have the kernel hackers all running for > shelter at this point - "Aigh! He's looking in /usr/src/sys!" > they yell. "Somebody stop him!!" :-) > > Well, OK, maybe I have to confess that I've just always wanted to see > what would be involved in adding a system call, and in particular > *this* system call in order that I might implement a long-standing > wishlist item of mine with redirection and piping (I've got the first > part of this, but not the second yet). > > Feedback most welcome. If this code is going to be added to the kernel sources, please make a kernel option to enable it (something like INCLUDE_DUP3). Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Tue Mar 18 10:21:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA15557 for hackers-outgoing; Tue, 18 Mar 1997 10:21:30 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA15547 for ; Tue, 18 Mar 1997 10:21:26 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id KAA17284; Tue, 18 Mar 1997 10:21:23 -0800 (PST) To: neswold@FNAL.GOV cc: hackers@freefall.freebsd.org Subject: Re: Whee! jkh adds his first syscall... In-reply-to: Your message of "Tue, 18 Mar 1997 10:57:08 CST." Date: Tue, 18 Mar 1997 10:21:23 -0800 Message-ID: <17280.858709283@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If this code is going to be added to the kernel sources, please make a > kernel option to enable it (something like INCLUDE_DUP3). Absolutely - heh, I'm a LONG way off from even thinking of committing this, believe me! :-) Jordan From owner-freebsd-hackers Tue Mar 18 10:46:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17090 for hackers-outgoing; Tue, 18 Mar 1997 10:46:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17080 for ; Tue, 18 Mar 1997 10:46:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA09912; Tue, 18 Mar 1997 11:34:23 -0700 From: Terry Lambert Message-Id: <199703181834.LAA09912@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 18 Mar 1997 11:34:23 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703180323.NAA14257@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 18, 97 01:53:47 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 > Given that we have established that it's not feasible or desirable to > write to the media, as it's not possible to determine where is a safe > place on said media to write to until after we have obtained the facts > that we are trying to obtain, this doesn't work. We've established no such ting. For an invalid partition, or for equivalent partition IDs which differ only in value, there are a number of things it is quite safe to twiddle with at the front of the disk. > Also, the practicalities involved in the int13 driver you're discussing > are horrific. You said impossible. Now you say impractical. How soon until we get to unavoidable? 8-). > I'm not shamed by your reference; I just can't see the relevance. The reference was intended to point out another example of a protected mode OS that can interoperate reliably with the DOS boot process, since I didn't seem to be getting anywhere with NT and Win95 examples. It was not intended to shame you, it was intended to refute the "too hard for anyone by MS" argument. > > Hopefully by "unlimited resources" you were referring to MS? > > No, I'm referring to the dearth of _space_ in the second-stage bootstrap. You have said you are already puttering with a 3 stage boot. Space is an obfuscation, not an issue. > > If the bootloader was misled, DOS was identically mislead, and since > > all we really care about here is interoperability with DOS installed > > on the same drive (or another OS that must also care about interoperability > > with DOS installed on the same drive), it is *correct* to allow ourselves > > to be "misled". > > What we care about is finding sectors on the disk, given some information > in c/h/s format. It is only correct that we are similarly misled to DOS if > we were booted from the same source as DOS. This is not necessarily so. ??? DOS can only boot off the initial drive. FreeBSD will only boot off the initial drive after install. The only issue you can be referring to is the OnTrack boot manager on the hard drive during a boot-from-floppy install, where the OnTrack code will not modify the values returned by the INT 13. This can be reconciled by using LBA based I/O, if possible, and by recognizing the OnTrack code, if not (recognition of the OnTrack code is already implemented). > I am not complaining about examining any particular OS. I am > complaining about your suggestion that I should be subscribed to a > developer indoctrination service for an organisation and environment > that I find personally anathematical. If said organisation or said > interoperability plaintiffs were to provide useful and relevant > documentation on the topic of interoperability, I would be happy to > study it. Well, I said to read the documentation, not to buy it. Am I a plaintiff by this description? Tell me what you want, and I will try to provide the information in paraphrased for other form that won't violate my license. As far as boot goes, I'd *really* suggest you download the PReP specification from the IBM, Apple, or Motorolla WWW site; chapter 5 has perhaps the most extensive discussion of the DOS partition table that I have seen in recent years. > Supporting an MBR is good. Mandating one is not the current Way Of Things. Change "the current Way Of Things"; it has no special position in the order of the universe, other than its ruts fill with mud faster when it rains. > It is valid to suggest that we should mandate the use of an MBR and > corresponding partition information, but you will encounter users that > will Not Like This. Oh well. I'll feel bad for a nanosecond, and then shrug it off, knowing that it is more important to run on as much hardware as possible than it is to assuage the MBR bigotry of a few people who don't care if we can run on everyone's hardware, so long as we already run on theirs ("I got mine; screw you if you want yours" is a bad attitude, one which I will not tacitly condone). > > Size-ordered BSD device list, bsearch for BIOS sizes. *Very* simple. > > Not so simple. Introduce a set of devices that are found by the > BIOS but not by BSD, and vice versa. Sort amusingly. Again, remeber > that we are only looking for one device to match the sizing of a > single BIOS disk. That device will have a DOS partition table with a BSD 0xA5 in it, an it will have a boot block and disklabel at the offset of the right geometry times the 0xA5 partitions C/H/S value. The more interesting case is foreign FS's mounted from drives without a BSD 0xA5 partition; there are still hueristics which you can apply thre. For instance, remove the boot device from the contention after you've found it. 8-). > A great many machines support int13 "virus alert" services. It isn't > an issue at the point where we are writing a partition table as by then > we are in protected mode talking directly to the disk. > > It's not a major issue, but it has the potential to be a support wart. Less of a support wart than "can not mount root", and "can not mount corrupt MSDOSFS, please fsck", I suspect. > > I've never raved about ELF in NetBSD... not even in their boot code. > > No, I am referring to the "segment colouring" and other things that you > appear (justifiably?) to feel are worthwhile using ELF for. I am still > studying the libsa code, so I could well have missed a lot. Well, yes, I've been raving for ELF. With John Polstra's "branding" patches, the last real techinical issue against it is gone. > > Actually, you want to be able to load all segments with a certain set > > of tag bits from the kernel image file, which is a single ELF file. > > MHO is that the kernel should _not_ be a monolithic file, but rather > the 'core' kernel and a collection of linkable objects (drivers, > optional extras, etc.) > > This would allow constructing seperate kernels from a single repository > of objects, etc. I would prefer this as well. But if you wanted to support only one file in the vn_* routines in real mode, and then support multiple files after word, then you could make the kernel contain all boot-critical devices. You should probably do this anyway. As far as it not being monolithic: it's probably desirable to be able to "config" devices into and out of the default image by adding or removing segments from the monolithic ELF binary. At the very least, it means no recompilation to support config options, as long as we get rid of the static compilation issues in shared code (#if FEATURE > 1) and so on. > > The lack of a coherent kernel level vnode-as-descriptor based file > > I/O subsystem is one of the things that is wrong in the FreeBSD kernel. > > The vn_* routines are seriously incoherent compared to, for instance, > > the AIX kernel file I/O interface. > > The solution to this is well known; I am hoping that you have provided > your changes to Julian and/or phk so that I can then pursue them with > regard to having them integrated. The initial set of changes, divorced from the rest of them, were provided to Julian before the Lite2 integration started. He still has them. Because I have to provide changes in "bite sized chunks" to allow them to be digested, we will have to incrementally work back up to where I was on my own machines in June of 1994. A coherent kernel file I/O interface is about three chunks past the currently outstanding chunk. > > http://www.microsoft.com/win32dev/base/pefile.htm > > Thanks for the reference. Unfortunately, this document makes no > mention of "colouring" (in either spelling) boot or otherwise. It > describes PE as a mutant form of COFF, which I already knew. > > At best, I presume you are referring to the 'section characteristics' > attribute. Yes. I refer to it as "coloring" because that is the proper term for atributing page ranges (a section is a page range) by VM characteristics. > > 0x40000000 Readable section > > 0x80000000 Writable section > ?! Think of "-fwriteable_strings"... > The point, however, is that these attributes are not useful until the > VM system is up and running. The initial linker pass has to run > _before_ this; still, it shouldn't be hard to walk the attributes at > a later stage to pass them on. Yes. The utility of the attributes at boot time is to decide to load a particular segment or not. Preload is the most interesting attribute in this regard; it should probably be implied on non-pageable segments. > You could, at least, have renumbered the bits rather than use the > same (nonsensical) assignments that MS did 8) I could have, but it would have been "TerryPE" instead of "PE". 8-). [ ...Technical library?... ] > The short answer is : No, we don't. The longer answer is : > (technical) Books cost a small fortune in this country for some > inexplicable reason. eg. Stevens UNP, a fairly stock programmer's > staple, lists at AUD$90 (about US$70). Ordering non-stock books can > often add 10-15% to that. > > Public libraries tend not to have technical books. Whoah. No wonder you guys are so gung-ho on the Internet... 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 Mar 18 10:57:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17797 for hackers-outgoing; Tue, 18 Mar 1997 10:57:57 -0800 (PST) Received: from mauve.csi.cam.ac.uk (exim@mauve.csi.cam.ac.uk [131.111.8.38]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17788 for ; Tue, 18 Mar 1997 10:57:54 -0800 (PST) Received: from g.pet.cam.ac.uk [131.111.209.233] by mauve.csi.cam.ac.uk with smtp (Exim 1.58 #1) id 0w7451-0001Rk-00; Tue, 18 Mar 1997 18:57:51 +0000 Received: from g.pet.cam.ac.uk [127.0.0.1] by g.pet.cam.ac.uk with esmtp (Exim 1.59 #1) id 0w745J-0005Qk-00; Tue, 18 Mar 1997 18:58:09 +0000 To: freebsd-hackers@freebsd.org Subject: CVSup tags Date: Tue, 18 Mar 1997 18:58:09 +0000 From: Gareth McCaughan Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any way of finding out a complete set of valid CVS tags for the CVS repository available via CVSup? If there isn't, I suggest that there should be; if there is, I suggest that it should be documented; if there is and it's already documented, then I suggest that I get a new brain. -- Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, gjm11@dpmms.cam.ac.uk Cambridge University, England. From owner-freebsd-hackers Tue Mar 18 11:35:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA21310 for hackers-outgoing; Tue, 18 Mar 1997 11:35:14 -0800 (PST) Received: from jump.net (serv1-2.jump.net [204.238.120.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA21305 for ; Tue, 18 Mar 1997 11:35:11 -0800 (PST) Received: by jump.net (8.8.5/BERK-6.8.11) id NAA23454; Tue, 18 Mar 1997 13:34:18 -0600 (CST) Date: Tue, 18 Mar 1997 13:34:13 -0600 (CST) From: Lee Crites To: John Prince cc: hackers@FreeBSD.ORG Subject: Re: still more digiboard and modem questions/problems... In-Reply-To: <199703181330.HAA28482@milo.lodgenet.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, 18 Mar 1997, John Prince wrote: Thanks for the response. I have a few replies to it... > Lee Crites writes: > > I have come to the conclusion that using a digiboard was not my best move. > > I Agree... Any suggestions on a multi-port board? I need a 'one box' solution for many of my clients. The ideal situation would be a pentium box with an isdn card to connect to the internet, an ethernet card for connecting to the lan (is there such a thing as a router card?), a multiport serial card (so they can dial in), and 28.8/33.4 modems. I'd *like* things to be scsi, but that's another story. Any clues on what multiport card would be best? What isdn card is best? > Add yourself and/or all users the need to access the tty to the > group dialer.. I can add these to /etc/groups. What happens when I reach that magic one-hundred-something limit in the group record? > It not a good idea to enable both Dialout and Dialin, probably part of your > problem. I started out with just the ttyDxx, then added cuaDxx, at which point I had both, I added mgetty, at which point I commented out all of the others, ttyDxx included. When I decided to try one mgetty and one getty is when I uncommented out the ttyDxx items. > Set the correct device here (ttyD). I'm looking for dialin access, not dialout access. So do I use ttyDxx or cuaDxx? This might be my problem. I thought I used the cuaDxx for dialin. > A better way is to use rc.serial.. > Have you initialized your ttys?? (look at /etc/rc.serial, uncomment the > line under Digiboard.. I saw this a while ago. I believe the only time I tried it was when I was using getty. I just tried it while using mgetty with little difference. I did, however, actually get one of my pc's to get some garbage back after the modem connected. So I guess that is progress. Until then All I ever got was modem connect and nothing else. Lee From owner-freebsd-hackers Tue Mar 18 11:42:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA22247 for hackers-outgoing; Tue, 18 Mar 1997 11:42:22 -0800 (PST) Received: from bellind.com ([206.101.34.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22238 for ; Tue, 18 Mar 1997 11:42:18 -0800 (PST) From: RGireyev@BELLIND.COM Received: from cdcexchange.bellind.com ([170.1.130.2]) by firewall.bellind.com with SMTP id <3660-1>; Tue, 18 Mar 1997 11:39:45 -0800 Received: by cdcexchange.bellind.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC3391.F9F097A0@cdcexchange.bellind.com>; Tue, 18 Mar 1997 11:46:11 -0800 Message-ID: To: Subject: Donation please ... Date: Tue, 18 Mar 1997 11:46:09 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy! Could ya'll help a fellow American who is down on his luck. All I need is the source distribution for top. Stuff like top.h, top.c (maybe even a makefile). I'm having trouble getting into the FTP site where sources supposedly are, and they don't seem to exist anywhere on ftp.freebsd.org. Thank you. -------------------------------------------------- Beavis and Butt-head Software Co Inc | Fone 1-800-555-CHICKs "Just press any key, dude!!!!" | Phaks 1-800-555-BUTT -------------------------------------------------- From owner-freebsd-hackers Tue Mar 18 11:55:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA23104 for hackers-outgoing; Tue, 18 Mar 1997 11:55:05 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA23096 for ; Tue, 18 Mar 1997 11:55:01 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id LAA17703 for ; Tue, 18 Mar 1997 11:55:00 -0800 (PST) To: hackers@freebsd.org Subject: REPOST: dup3() - interesting feature-in-training or silly hack? Date: Tue, 18 Mar 1997 11:55:00 -0800 Message-ID: <17699.858714900@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [I posted this last night to -hackers, but several people reported back that they never saw it, and freefall sort of crashed about 3 hours later so perhaps it just got eaten.] From: "Jordan K. Hubbard" Date: Mon, 17 Mar 1997 22:35:23 -0800 Subject: Whee! jkh adds his first syscall... The subject alone should have the kernel hackers all running for shelter at this point - "Aigh! He's looking in /usr/src/sys!" they yell. "Somebody stop him!!" :-) Well, OK, maybe I have to confess that I've just always wanted to see what would be involved in adding a system call, and in particular *this* system call in order that I might implement a long-standing wishlist item of mine with redirection and piping (I've got the first part of this, but not the second yet). The system call: int dup3(int oldd, pid_t tpid, int newd) In dup3(), a target process ID and the value of the new descriptor newd is specified in the context of that process. If this descriptor is currently assigned to a valid file, then it will be returned as a new file descriptor in the current process context, otherwise -1 is returned. If the returned file descriptor is not needed then it should be closed. The primary purpose of dup3() is to allow "splicing" of I/O in already-running processes. Yes, I know many will look at the name and go "yuck!" - it's half in jest, OK? :) So what's the use of it? To use in things like shells, so that you can do stuff like this: # make world ^Z%1 Suspended # bg > make.out # This also works with fg, so you can foreground and redirect stdin, stdout and stderr at the same time just as easily. The patches here to sh implement this extra behavior, conditionalized on HAVE_DUP3. Now please note: This really is just proof-of-concept material here for 3 big reasons: 1. Thwapping over another processes's file descriptors is rude, and it generally confuses things like the stdio library to do this. It seems to mostly work OK in my implementation, but I'm sure some sort of "invalidate current buffered fd contents" hack would have to be added to stdio if you wanted to make it all work correctly (try redirecting stdin, for example, and see the slightly odd behavior it has now). 2. The hacks to the shell are exceedingly minimal, and don't implement the more complicated and useful cases like: fg | more or yes | fg Note that it should be perfectly possible, but you'd have to change the way the shell handles these builtins pretty substantially to make it work. Making redirection happen was easy. :-) The changes also only cover /bin/sh, which of course almost nobody uses. If we actually manage to make a useful facility out of this, someone would also have to beat on bash and tcsh. 3. I'm sure there is at least one blatant security hole opened by this mechanism, and I do *ONLY THE MOST MINIMAL* checks for security. More specifically, I compare the euids of from and to, refusing the dup3() if they don't match (or the current euid is 0). This is a very minimal test, and I don't even test for proper parent/child relationship in the non-root case. So use this stuff at your own risk! I'm mostly just releasing it for comments at this point, to find out if I'm really just smoking crack with this whole idea. Patches relative to 2.2-current, thought they should work just as well in 3.0. I also included patches to all the "derived" files from syscalls.master - while not strictly necessary, it saves everyone from having to do anything more than apply this patch from the top of /usr/src and build a new libc, new kernel and new /bin/sh. Feedback most welcome. Jordan Index: bin/sh/Makefile =================================================================== RCS file: /home/ncvs/src/bin/sh/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile - --- Makefile 1996/10/25 14:49:24 1.15 +++ Makefile 1997/03/18 06:00:58 @@ -15,7 +15,7 @@ LDADD+= -ll -ledit -ltermcap LFLAGS= -8 # 8-bit lex scanner for arithmetic - -CFLAGS+=-DSHELL -I. -I${.CURDIR} +CFLAGS+=-DSHELL -DHAVE_DUP3 -I. -I${.CURDIR} # for debug: # CFLAGS+= -g -DDEBUG=2 Index: bin/sh/jobs.c =================================================================== RCS file: /home/ncvs/src/bin/sh/jobs.c,v retrieving revision 1.8.2.1 diff -u -r1.8.2.1 jobs.c - --- jobs.c 1997/01/12 21:58:49 1.8.2.1 +++ jobs.c 1997/03/18 06:00:45 @@ -213,11 +213,20 @@ struct job *jp; { struct procstat *ps; - - int i; + int i, fd; if (jp->state == JOBDONE) return; INTOFF; +#ifdef HAVE_DUP3 + for (i = 0; i < 2; i++) { + if (fd_redirected_p(i)) { + fd = dup3(i, jp->ps[0].pid, i); + if (fd != -1) + close(fd); + } + } +#endif killpg(jp->ps[0].pid, SIGCONT); for (ps = jp->ps, i = jp->nprocs ; --i >= 0 ; ps++) { if ((ps->status & 0377) == 0177) { @@ -591,7 +600,7 @@ ignoresig(SIGINT); ignoresig(SIGQUIT); if ((jp == NULL || jp->nprocs == 0) && - - ! fd0_redirected_p ()) { + ! fd_redirected_p (0)) { close(0); if (open("/dev/null", O_RDONLY) != 0) error("Can't open /dev/null"); @@ -602,7 +611,7 @@ ignoresig(SIGINT); ignoresig(SIGQUIT); if ((jp == NULL || jp->nprocs == 0) && - - ! fd0_redirected_p ()) { + ! fd_redirected_p (0)) { close(0); if (open("/dev/null", O_RDONLY) != 0) error("Can't open /dev/null"); Index: bin/sh/redir.c =================================================================== RCS file: /home/ncvs/src/bin/sh/redir.c,v retrieving revision 1.5 diff -u -r1.5 redir.c - --- redir.c 1996/09/01 10:21:36 1.5 +++ redir.c 1997/03/18 05:50:46 @@ -76,11 +76,11 @@ MKINIT struct redirtab *redirlist; /* - - * We keep track of whether or not fd0 has been redirected. This is for + * We keep track of whether or not fds 0-2 have been redirected. This is for * background commands, where we want to redirect fd0 to /dev/null only - - * if it hasn't already been redirected. + * if it hasn't already been redirected, and for fb/bg redirection to files. */ - -int fd0_redirected = 0; +int fd_redirected[3]; STATIC void openredirect __P((union node *, char[10 ])); STATIC int openhere __P((union node *)); @@ -132,8 +132,8 @@ } else { close(fd); } - - if (fd == 0) - - fd0_redirected++; + if (fd >= 0 && fd <= 2) + fd_redirected[fd]++; openredirect(n, memory); } if (memory[1]) @@ -267,8 +267,8 @@ for (i = 0 ; i < 10 ; i++) { if (rp->renamed[i] != EMPTY) { - - if (i == 0) - - fd0_redirected--; + if (i >= 0 && i <= 2) + fd_redirected[i]--; close(i); if (rp->renamed[i] >= 0) { copyfd(rp->renamed[i], i); @@ -303,8 +303,11 @@ /* Return true if fd 0 has already been redirected at least once. */ int - -fd0_redirected_p () { - - return fd0_redirected != 0; +fd_redirected_p (int fd) { + if (fd >= 0 && fd <= 2) + return fd_redirected[fd] != 0; + else + return 0; } /* Index: bin/sh/redir.h =================================================================== RCS file: /home/ncvs/src/bin/sh/redir.h,v retrieving revision 1.3 diff -u -r1.3 redir.h - --- redir.h 1996/09/01 10:21:37 1.3 +++ redir.h 1997/03/18 05:51:43 @@ -44,7 +44,7 @@ union node; void redirect __P((union node *, int)); void popredir __P((void)); - -int fd0_redirected_p __P((void)); +int fd_redirected_p __P((int)); void clearredir __P((void)); int copyfd __P((int, int)); Index: lib/libc/sys/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/Makefile.inc,v retrieving revision 1.20 diff -u -r1.20 Makefile.inc - --- Makefile.inc 1996/09/20 13:55:25 1.20 +++ Makefile.inc 1997/03/17 18:13:35 @@ -14,7 +14,7 @@ # modules with default implementations on all architectures: ASM= accept.o access.o acct.o adjtime.o bind.o chdir.o chflags.o chmod.o \ - - chown.o chroot.o close.o connect.o dup.o dup2.o execve.o fchdir.o \ + chown.o chroot.o close.o connect.o dup.o dup2.o dup3.o execve.o fchdir.o \ fchflags.o fchmod.o fchown.o fcntl.o flock.o fpathconf.o fstat.o \ fstatfs.o fsync.o getdirentries.o getdtablesize.o getegid.o \ geteuid.o getfh.o getfsstat.o getgid.o getgroups.o getitimer.o \ @@ -109,6 +109,7 @@ MLINKS+=brk.2 sbrk.2 MLINKS+=dup.2 dup2.2 +MLINKS+=dup.2 dup3.2 MLINKS+=chdir.2 fchdir.2 MLINKS+=chflags.2 fchflags.2 MLINKS+=chmod.2 fchmod.2 Index: lib/libc/sys/dup.2 =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/dup.2,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 dup.2 - --- dup.2 1997/03/09 22:16:51 1.3.2.3 +++ dup.2 1997/03/18 06:13:05 @@ -37,7 +37,8 @@ .Os BSD 4 .Sh NAME .Nm dup , - -.Nm dup2 +.Nm dup2 , +.Nm dup3 .Nd duplicate an existing file descriptor .Sh SYNOPSIS .Fd #include @@ -45,6 +46,8 @@ .Fn dup "int oldd" .Ft int .Fn dup2 "int oldd" "int newd" +.Ft int +.Fn dup3 "int oldd" "pid_t tpid" "int newd" .Sh DESCRIPTION .Fn Dup duplicates an existing object descriptor and returns its value to @@ -113,6 +116,18 @@ is a valid descriptor, then .Fn dup2 is successful, and does nothing. +.Pp +In +.Fn dup3 , +a target process ID and the value of the new descriptor +.Fa newd +is specified in the context of that process. If this descriptor +is currently assigned to a valid file, then it will be returned +as a new file descriptor in the current process context, otherwise +-1 is returned. If the returned file descriptor is not needed then +it should be closed. The primary purpose of +.Fn dup3 +is to allow "splicing" of I/O in already-running processes. .Sh IMPLEMENTATION NOTES .Pp In the non-threaded library @@ -166,9 +181,10 @@ .Va errno indicates the cause of the error. .Sh ERRORS - -.Fn Dup - -and +.Fn Dup , .Fn dup2 +and +.Fn dup3 fail if: .Bl -tag -width Er .It Bq Er EBADF @@ -178,6 +194,18 @@ is not a valid active descriptor .It Bq Er EMFILE Too many descriptors are active. +.Pp +.Fn dup3 +will additionally fail if: +.Bl -tag -width Er +.It Bq Er ESRCH +The +.Fa tpid +is not found. +.It Bq Er EPERM +The effective uid of the current process does not match that of +the target process. Only the super user can modify the file descriptor +table of processes with a different euid. .El .Sh SEE ALSO .Xr accept 2 , @@ -202,3 +230,6 @@ .Fn dup2 function call appeared in .At v7 . +The +.Fn dup3 +function call appeared in FreeBSD 3.0 . Index: sys/kern/init_sysent.c =================================================================== RCS file: /home/ncvs/src/sys/kern/init_sysent.c,v retrieving revision 1.36 diff -u -r1.36 init_sysent.c - --- init_sysent.c 1996/09/19 19:48:31 1.36 +++ init_sysent.c 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call switch table. * * DO NOT EDIT-- this file is automatically generated. - - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #include @@ -266,7 +266,7 @@ { 3, (sy_call_t *)shmctl }, /* 229 = shmctl */ { 1, (sy_call_t *)shmdt }, /* 230 = shmdt */ { 3, (sy_call_t *)shmget }, /* 231 = shmget */ - - { 0, (sy_call_t *)nosys }, /* 232 = nosys */ + { 3, (sy_call_t *)dup3 }, /* 232 = dup3 */ { 0, (sy_call_t *)nosys }, /* 233 = nosys */ { 0, (sy_call_t *)nosys }, /* 234 = nosys */ { 0, (sy_call_t *)nosys }, /* 235 = nosys */ Index: sys/kern/kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.32.2.2 diff -u -r1.32.2.2 kern_descrip.c - --- kern_descrip.c 1996/12/21 19:04:24 1.32.2.2 +++ kern_descrip.c 1997/03/18 05:17:28 @@ -149,8 +149,69 @@ } /* - - * Duplicate a file descriptor. + * Duplicate a file descriptor to a particular value in another process. */ +#ifndef _SYS_SYSPROTO_H_ +struct dup3_args { + u_int from; + pid_t target; + u_int to; +}; +#endif +/* ARGSUSED */ +int +dup3(p, uap, retval) + struct proc *p; + struct dup3_args *uap; + int *retval; +{ + struct filedesc *tdp, *fdp; + struct proc *t; + struct file *fp, *nfp; + int i, error; + u_int from = uap->from, to = uap->to; + + /* Look up target process and make sure it exists, then set */ + t = pfind(uap->target); + if (!t) + return (ESRCH); + tdp = t->p_fd; + fdp = p->p_fd; + + /* Don't let non-root procs stomp other procs unless euid is the same */ + /* XXX should also put in a check for parentage here in the non-root case XXX */ + if (p->p_ucred->cr_uid && p->p_ucred->cr_uid != t->p_ucred->cr_uid) + return (EPERM); + + if (from >= fdp->fd_nfiles || fdp->fd_ofiles[from] == NULL) + return (EBADF); + if (to >= tdp->fd_nfiles) { + if ((error = fdalloc(t, to, &i))) + return (error); + if (to != i) + panic("dup3: fdalloc"); + *retval = -1; + } + else if (tdp->fd_ofiles[to]) { + if ((error = fdalloc(p, 0, &i))) + return (error); + fdp->fd_ofiles[i] = tdp->fd_ofiles[to]; + fdp->fd_ofileflags[i] = tdp->fd_ofileflags[to] &~ UF_EXCLOSE; + tdp->fd_ofiles[to]->f_count++; + if (i > fdp->fd_lastfile) + fdp->fd_lastfile = i; + *retval = i; + } + tdp->fd_ofiles[to] = fdp->fd_ofiles[from]; + tdp->fd_ofileflags[to] = fdp->fd_ofileflags[from] &~ UF_EXCLOSE; + tdp->fd_ofiles[from]->f_count++; + if (to > tdp->fd_lastfile) + tdp->fd_lastfile = to; + return (0); +} + +/* + * Duplicate a file descriptor. */ #ifndef _SYS_SYSPROTO_H_ struct dup_args { u_int fd; Index: sys/kern/syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.c,v retrieving revision 1.31 diff -u -r1.31 syscalls.c - --- syscalls.c 1996/09/19 19:48:34 1.31 +++ syscalls.c 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call names. * * DO NOT EDIT-- this file is automatically generated. - - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ char *syscallnames[] = { @@ -253,7 +253,7 @@ "shmctl", /* 229 = shmctl */ "shmdt", /* 230 = shmdt */ "shmget", /* 231 = shmget */ - - "#232", /* 232 = nosys */ + "dup3", /* 232 = dup3 */ "#233", /* 233 = nosys */ "#234", /* 234 = nosys */ "#235", /* 235 = nosys */ Index: sys/kern/syscalls.master =================================================================== RCS file: /home/ncvs/src/sys/kern/syscalls.master,v retrieving revision 1.29 diff -u -r1.29 syscalls.master - --- syscalls.master 1996/09/19 19:48:38 1.29 +++ syscalls.master 1997/03/17 18:06:01 @@ -364,7 +364,7 @@ 230 STD BSD { int shmdt(void *shmaddr); } 231 STD BSD { int shmget(key_t key, int size, int shmflg); } ; - -232 UNIMPL NOHIDE nosys +232 STD BSD { int dup3(u_int from, pid_t target, u_int to); } 233 UNIMPL NOHIDE nosys 234 UNIMPL NOHIDE nosys 235 UNIMPL NOHIDE nosys Index: sys/sys/syscall-hide.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall-hide.h,v retrieving revision 1.25 diff -u -r1.25 syscall-hide.h - --- syscall-hide.h 1996/09/19 19:49:10 1.25 +++ syscall-hide.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call hiders. * * DO NOT EDIT-- this file is automatically generated. - - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ HIDE_POSIX(fork) @@ -209,5 +209,6 @@ HIDE_BSD(shmctl) HIDE_BSD(shmdt) HIDE_BSD(shmget) +HIDE_BSD(dup3) HIDE_BSD(minherit) HIDE_BSD(rfork) Index: sys/sys/syscall.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syscall.h,v retrieving revision 1.29 diff -u -r1.29 syscall.h - --- syscall.h 1996/09/19 19:49:12 1.29 +++ syscall.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call numbers. * * DO NOT EDIT-- this file is automatically generated. - - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #define SYS_syscall 0 @@ -203,6 +203,7 @@ #define SYS_shmctl 229 #define SYS_shmdt 230 #define SYS_shmget 231 +#define SYS_dup3 232 #define SYS_minherit 250 #define SYS_rfork 251 #define SYS_MAXSYSCALL 252 Index: sys/sys/sysproto.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysproto.h,v retrieving revision 1.15 diff -u -r1.15 sysproto.h - --- sysproto.h 1996/09/19 19:49:13 1.15 +++ sysproto.h 1997/03/17 18:15:11 @@ -2,7 +2,7 @@ * System call prototypes. * * DO NOT EDIT-- this file is automatically generated. - - * created from Id: syscalls.master,v 1.28 1996/08/20 07:17:49 smpatel Exp + * created from Id: syscalls.master,v 1.29 1996/09/19 19:48:38 phk Exp */ #ifndef _SYS_SYSPROTO_H_ @@ -716,6 +716,11 @@ int size; int shmflg; }; +struct dup3_args { + u_int from; + pid_t target; + u_int to; +}; struct minherit_args { caddr_t addr; size_t len; @@ -891,6 +896,7 @@ int shmctl __P((struct proc *, struct shmctl_args *, int [])); int shmdt __P((struct proc *, struct shmdt_args *, int [])); int shmget __P((struct proc *, struct shmget_args *, int [])); +int dup3 __P((struct proc *, struct dup3_args *, int [])); int minherit __P((struct proc *, struct minherit_args *, int [])); int rfork __P((struct proc *, struct rfork_args *, int [])); ------------------------------ End of hackers-digest V3 #109 ***************************** From owner-freebsd-hackers Tue Mar 18 12:11:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA24463 for hackers-outgoing; Tue, 18 Mar 1997 12:11:20 -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 MAA24444 for ; Tue, 18 Mar 1997 12:11:08 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0w75C6-0002xD-00; Tue, 18 Mar 1997 12:09:14 -0800 Date: Tue, 18 Mar 1997 12:09:14 -0800 (PST) From: Tom Samplonius To: "Alex G. Bulushev" cc: dg@root.com, hackers@freebsd.org, mishania@demos.su Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h In-Reply-To: <199703181115.OAA10806@sinbin.demos.su> 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, 18 Mar 1997, Alex G. Bulushev wrote: > > What is the card connected to? It must be connected to a fast ethernet > > switch in order for full duplex mode to work. > > we use BayStack 28115 Fast Ethernet Switch > and can change modes on it's ports > > result table via ftp test: > > side1 side2 speed > > solaris 2.5.1 100Mb/full solaris 2.5.1 100Mb/full 4700 MBytes/sec > solaris 2.5.1 100Mb/full fbsd de 10Mb/half 740 MBytes/sec > fbsd fxp 10Mb/half fbsd de 10Mb/half 980 MBytes/sec > fbsd fxp 100Mb/half fbsd de 10Mb/half 980 MBytes/sec > fbsd fxp 100Mb/half solaris 2.5.1 100Mb/full 2900 MBytes/sec > fbsd fxp 100Mb/full fbsd de 10Mb/half 980 MBytes/sec > fbsd fxp 100Mb/full solaris 2.5.1 100Mb/full 20 MBytes/sec > > Alex. I don't know where you measureed those speeds from, but it wasn't from fast ethernet. Tom From owner-freebsd-hackers Tue Mar 18 12:13:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA24650 for hackers-outgoing; Tue, 18 Mar 1997 12:13:06 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24636 for ; Tue, 18 Mar 1997 12:13:02 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.5/8.8.5) id OAA16584; Tue, 18 Mar 1997 14:12:37 -0600 (CST) Date: Tue, 18 Mar 1997 14:12:37 -0600 (CST) From: Mark Tinguely Message-Id: <199703182012.OAA16584@plains.nodak.edu> To: avalon@coombs.anu.edu.au Subject: Re: dds tape drives. Cc: darrenr@cyber.com.au, hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In some mail from Mark Tinguely, sie said: > > > > a long time ago, I added the files and block counts to the /sys/scsi/st.c > > (basically you add/subtract after every read/write/movement command -- > > watch out for command residuals). > > > Does someone still have them ? It is true that I do not have them on any of my disks, but now that I think of it I must have these on an old tape backup. I will restore them when I can make some time. This change will not be any newer than for FreeBSD 2.0.x (or even FreeBSD 1.x) so it would only be a guide to make changes to newer st.c. I still have the sources for mt (the predecessor to st) and the minor changes that are needed to report the result of the kernel file/record counts. --mark. From owner-freebsd-hackers Tue Mar 18 12:19:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA25337 for hackers-outgoing; Tue, 18 Mar 1997 12:19:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA25332 for ; Tue, 18 Mar 1997 12:19:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10036; Tue, 18 Mar 1997 13:08:37 -0700 From: Terry Lambert Message-Id: <199703182008.NAA10036@phaeton.artisoft.com> Subject: Re: Donation please ... To: RGireyev@BELLIND.COM Date: Tue, 18 Mar 1997 13:08:36 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "RGireyev@BELLIND.COM" at Mar 18, 97 11:46: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 > Could ya'll help a fellow American who is down on his luck. Here, have a penguin. > All I need is the source distribution for top. Stuff like > top.h, top.c (maybe even a makefile). I'm having trouble > getting into the FTP site where sources supposedly are, and > they don't seem to exist anywhere on ftp.freebsd.org. Look at the "port" for top. The Makefile pulls down the source code from the official distribution site during the build. 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 Mar 18 12:24:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA25736 for hackers-outgoing; Tue, 18 Mar 1997 12:24:07 -0800 (PST) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA25677 for ; Tue, 18 Mar 1997 12:24:00 -0800 (PST) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.0.31] with ESMTP id XAA28360; Tue, 18 Mar 1997 23:23:04 +0300 Received: by sinbin.demos.su id XAA12133; (8.6.12/D) Tue, 18 Mar 1997 23:22:54 +0300 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199703182022.XAA12133@sinbin.demos.su> Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h To: tom@sdf.com (Tom Samplonius) Date: Tue, 18 Mar 1997 23:22:54 +0300 (MSK) Cc: dg@root.com, hackers@freebsd.org, mishania@demos.su In-Reply-To: from "Tom Samplonius" at Mar 18, 97 12:09:14 pm X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > fbsd fxp 100Mb/half solaris 2.5.1 100Mb/full 2900 MBytes/sec > > fbsd fxp 100Mb/full fbsd de 10Mb/half 980 MBytes/sec > > fbsd fxp 100Mb/full solaris 2.5.1 100Mb/full 20 MBytes/sec > > > > Alex. > > I don't know where you measureed those speeds from, but it wasn't from > fast ethernet. replace MBytes by KBytes, sorry ... Alex. > > Tom > > From owner-freebsd-hackers Tue Mar 18 12:29:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA26004 for hackers-outgoing; Tue, 18 Mar 1997 12:29:44 -0800 (PST) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25984; Tue, 18 Mar 1997 12:29:26 -0800 (PST) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id PAA00353; Tue, 18 Mar 1997 15:28:28 -0500 (EST) Message-Id: <199703182028.PAA00353@bmcgover-pc.cisco.com> To: questions@freebsd.org, hackers@freebsd.org Subject: Question on mapping PCI memory (Repeat) Date: Tue, 18 Mar 1997 15:28:28 -0500 From: Brian McGovern Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I apologize for re-asking this question, but ES here recently reparitioned my harddrive, and I lost all of my mail, including the answer to this question. Assume: I have a PCI card. It has 3 configuration registers at various offsets that are defined by the constants CZ_PCI_PLX9060_MEM, CZ_PCI_MEMORY_WINDOW, CZ_PCI_IRQ. I wish to be able to map the first two, which are memory addresses of dual ported ram on the card (I assume physical addresses), to virtual address space, so I can access it from the kernel. Major premise: I think I know how to do it. Minor premise: I probably have no clue, and I'm screwing it up. Therefore: I am assuming that I can use the pci_map_mem routine, and do something like: vm_offset_t vaddr, paddr; if (pci_map_mem(config_id, CZ_PCI_PLX9060_MEM, &vaddr, &paddr) == 0) die(); and then have (unsigned char *)vaddr be a pointer to my virtual memory space, which I can then memcpy to, or do things like (unsigned char *)vaddr[index] = 0; and such. Also, as an alternative, I can do it the long way, similar to: paddr = pci_conf_read(config_id, CZ_PCI_PLX9060_MEM); vaddr = (vm_offset_t)pmap_mapdev(paddr, 72); Then use vaddr as above as the virtual addresses. The questions I have are: 1.) Is this correct? If so, yea me. If not, which invokation is incorrect? 2.) Do I have to do anything extra fancy, such as take extra steps to align on page boundaries and such, and, if so, how would I go about doing that? 3.) Do I have to worry about locking the virtual memory space down? I assume they'd become kernel pages (as this is for a device driver), so they should never be "swapped". Any other comments are also welcome. Thanks. -Brian From owner-freebsd-hackers Tue Mar 18 12:49:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA27103 for hackers-outgoing; Tue, 18 Mar 1997 12:49:15 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.37.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA27098 for ; Tue, 18 Mar 1997 12:49:08 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id PAA11126; Tue, 18 Mar 1997 15:48:05 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id PAA27027; Tue, 18 Mar 1997 15:47:55 -0500 Date: Tue, 18 Mar 1997 15:47:55 -0500 Message-Id: <199703182047.PAA27027@jenolan.caipgeneral> From: "David S. Miller" To: tom@sdf.com CC: bag@sinbin.demos.su, dg@root.com, hackers@freebsd.org, mishania@demos.su In-reply-to: (message from Tom Samplonius on Tue, 18 Mar 1997 12:09:14 -0800 (PST)) Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Date: Tue, 18 Mar 1997 12:09:14 -0800 (PST) From: Tom Samplonius > solaris 2.5.1 100Mb/full solaris 2.5.1 100Mb/full 4700 MBytes/sec Thats incredible, Sun doesn't even claim such good numbers, and also neither do I! Congrats.. ;-) ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< From owner-freebsd-hackers Tue Mar 18 12:50:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA27180 for hackers-outgoing; Tue, 18 Mar 1997 12:50:40 -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 MAA27174 for ; Tue, 18 Mar 1997 12:50:34 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA18536; Tue, 18 Mar 1997 21:50:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id VAA03132; Tue, 18 Mar 1997 21:21:44 +0100 (MET) Message-ID: <19970318212144.WS51057@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 21:21:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Cc: avalon@coombs.anu.edu.au (Darren Reed) Subject: Re: further on 2.1.6 & 2940 References: <199703181317.FAA29037@who.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199703181317.FAA29037@who.cdrom.com>; from Darren Reed on Mar 19, 1997 00:13:46 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Darren Reed wrote: > # scsi -f /dev/rst0.ctl -m 3 > SCIOCCOMMAND ioctl: Command accepted. > return status 3 (Sense Returned) host adapter status 2 > Command out (6 of 6): > 1a 00 03 00 ff 00 > > Data in (0 of 255): > > Error code is "current errors" > Segment number is 00 > Sense key is "Illegal request" > The Information field is not valid but contains 00000000 (0). > The Command Specific Information field is 00000000 (0). > Additional sense code: 24 > Additional sense code qualifier: 00 > Illegal value in the command descriptor block. > Bit 5 of byte 2 (value 03) is illegal. > sense (32 of 48): > 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 cd > 00 02 38 2e 36 2e 39 2f 6b 6a d7 b5 50 10 44 70 > > What's this "Bit 5 of byte 2 (value 03) is illegal." mean ? ASC/ASCQ 24 00 is ``Invalid field in CDB''. Byte 2 value 3 is the number of the mode page in the CDB. Your drive doesn't support mode page #3, the rigid disk geometry page. Let me guess: it's a Jaz drive, ain't it? IOmega didn't bother to tell you how many cylinders and heads they are using. -- 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 Mar 18 12:51:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA27216 for hackers-outgoing; Tue, 18 Mar 1997 12: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 MAA27209 for ; Tue, 18 Mar 1997 12:51:07 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA18552; Tue, 18 Mar 1997 21:50:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id VAA03142; Tue, 18 Mar 1997 21:23:33 +0100 (MET) Message-ID: <19970318212333.IS33029@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 21:23:33 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: comuh.uh.cu!machin@ceniai.inf.cu (Ignacio Machin Rdguez) Subject: Re: Problemas con el correo References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Ignacio Machin Rdguez on Mar 18, 1997 09:13:20 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Ignacio Machin Rdguez wrote: ¡saludos! > A got a problem here it seems that somethings( or somebody) is > playing with the mail sistem, it seem that "something" is > distributing randomly the mesg so the users get the wrong mesg and > do not receive the proper mesg. Can you give us some more details, please? -- 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 Mar 18 12:57:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA27700 for hackers-outgoing; Tue, 18 Mar 1997 12:57:46 -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 MAA27689 for ; Tue, 18 Mar 1997 12:57:40 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id OAA28474; Tue, 18 Mar 1997 14:57:25 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma028464; Tue Mar 18 14:57:19 1997 Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.11.142]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id OAA09830; Tue, 18 Mar 1997 14:57:23 -0600 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.3/8.6.12) with ESMTP id OAA03514; Tue, 18 Mar 1997 14:57:30 -0600 (CST) Message-Id: <199703182057.OAA03514@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Lee Crites cc: John Prince , hackers@freebsd.org Subject: Re: still more digiboard and modem questions/problems... In-reply-to: Your message of "Tue, 18 Mar 1997 13:34:13 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 14:57:29 -0600 From: John Prince Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Any suggestions on a multi-port board? I need a 'one box' solution for >many of my clients. >The ideal situation would be a pentium box with an isdn card to connect to >the internet, an ethernet card for connecting to the lan (is there such a >thing as a router card?), a multiport serial card (so they can dial in), and >28.8/33.4 modems. The Digiboard is a fine board, it should support what you want to do.. I just do not like them.. I am not sure about ISDN.. I seem to be missing your first thread, however if all is configured properly all will work.. >I can add these to /etc/groups. What happens when I reach that magic >one-hundred-something limit in the group record? That number is 200.. Be creative, ie..... group1:*:1200:user1,user2,user3,user4,user5,etc..... group2:*:1201:user200,user201,user203,etc....... dialer:*:68:group1,group2, <>>> maybe even reinstall the OS. << Create device nodes (MAKEDEV) Edit /etc/rc.serial to support digiboard Edit /etc/ttys , enable dialin devices (ttyD is your dialin) Do a factory refresh on each modem (Check your operators manual, should be 'at&f0') Add user support for devices, Verify permission and finaly <<< REBOOT >>> If it still fails, have you tested your phone connection?? Are your going through a pbx or ksu?? Good luck... --john John Prince johnp@lodgenet.com jprince@iw.net From owner-freebsd-hackers Tue Mar 18 13:19:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA29092 for hackers-outgoing; Tue, 18 Mar 1997 13:19:37 -0800 (PST) Received: from bellind.com ([206.101.34.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29085 for ; Tue, 18 Mar 1997 13:19:31 -0800 (PST) From: RGireyev@bellind.com Received: from cdcexchange.bellind.com ([170.1.130.2]) by firewall.bellind.com with SMTP id <3662-2>; Tue, 18 Mar 1997 13:17:09 -0800 Received: by cdcexchange.bellind.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC339F.97D88F60@cdcexchange.bellind.com>; Tue, 18 Mar 1997 13:23:39 -0800 Message-ID: To: Cc: Subject: RE: Donation please ... Date: Tue, 18 Mar 1997 13:23:38 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thank you for replying Terry. I think you may have missed a sentence in my original posting. I am having trouble getting into the FTP site that has the sources. I'm sorry to trouble the list with something so stupid. Thanks. P.S. Is tha penguin small and qute? What's her name? Oh wait...,,, oops sorry! Improper topic. >---------- >From: Terry Lambert[SMTP:terry@lambert.org] >Sent: Tuesday, March 18, 1997 12:08 PM >To: Rudy Gireyev >Cc: freebsd-hackers@freebsd.org >Subject: Re: Donation please ... > >> Could ya'll help a fellow American who is down on his luck. > >Here, have a penguin. > > >> All I need is the source distribution for top. Stuff like >> top.h, top.c (maybe even a makefile). I'm having trouble >> getting into the FTP site where sources supposedly are, and >> they don't seem to exist anywhere on ftp.freebsd.org. > >Look at the "port" for top. The Makefile pulls down the source >code from the official distribution site during the build. > > > 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 Mar 18 13:49:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02429 for hackers-outgoing; Tue, 18 Mar 1997 13:49:00 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02418 for ; Tue, 18 Mar 1997 13:48:54 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA00033 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Tue, 18 Mar 1997 22:48:51 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id VAA01659 for FreeBSD-hackers@freebsd.org; Tue, 18 Mar 1997 21:04:12 +0100 (MET) From: Wilko Bulte Message-Id: <199703182004.VAA01659@yedi.iaf.nl> Subject: using ISDN-FreeBSD in the Netherlands To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Tue, 18 Mar 1997 21:04:12 +0100 (MET) 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 I'd like to come into contact with people who use FreeBSD in combination with ISDN in the Netherlands. Need some more info what works here (hardware wise etc). Please reply to me directly and not to the list. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Mar 18 13:58:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04565 for hackers-outgoing; Tue, 18 Mar 1997 13:58:17 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04559 for ; Tue, 18 Mar 1997 13:58:14 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id WAA03493; Tue, 18 Mar 1997 22:46:50 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.5/8.8.2) id VAA28007; Tue, 18 Mar 1997 21:25:28 +0100 (MET) Message-ID: <19970318212528.28756@klemm.gtn.com> Date: Tue, 18 Mar 1997 21:25:28 +0100 From: Andreas Klemm To: paulzn@olivetti.nl Cc: hackers@FreeBSD.org Subject: Re: current-digest V3 #39 References: <199703131421.GAA28883@freefall.freebsd.org> <19970318081322.59650@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.66 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I noticed that if I used shutdown I got a message that some process > refused to die. The only process which might cause it was mount_mfs. > I just disabled mounting an mfs on /tmp and now I can halt cleanly. > Are you using mfs ??? If so try disabling it. Well, yes, I use mfs ... but ... who or what broke it in 2.2.0 and 3.0 ? I'm using mfs for months and had no trouble. -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Tue Mar 18 14:34:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06588 for hackers-outgoing; Tue, 18 Mar 1997 14:34:35 -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 OAA06583 for ; Tue, 18 Mar 1997 14:34:32 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id OAA04469; Tue, 18 Mar 1997 14:34:18 -0800 (PST) Date: Tue, 18 Mar 1997 14:34:18 -0800 (PST) From: Chris Coleman Reply-To: Chris Coleman To: Lee Crites cc: John Prince , hackers@FreeBSD.ORG Subject: Re: still more digiboard and modem questions/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 I have a BOCA 16 port modem board running on my FreeBSD 2.1-STABLE system. I have had it running for about 6 months. I had a few problems when I had different brands of modems running on the same box, but I removed them and I have had no problems since. I can give you the specifics of how I set it up if you want. But it should be almost the same as the digiboard. (I think i remember patterning the stuff after the digiboard setup.) I don't believe I had to put anyone in any special groups. I just had to modify /etc/ttys and /etc/rc.serial Both files Follow: Here is my /etc/ttys: # name getty type status comments console none unknown off secure # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 off secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/X11R6/bin/xdm -nodaemon" cons25 on secure # BocaBoard ttyd1 "/usr/libexec/getty std.115200" dialup on insecure ttyd2 "/usr/libexec/getty std.115200" dialup on insecure ttyd3 "/usr/libexec/getty std.115200" dialup on insecure ttyd4 "/usr/libexec/getty std.115200" dialup on insecure ttyd5 "/usr/libexec/getty std.115200" dialup on insecure #.... ttydf "/usr/libexec/getty std.115200" dialup on insecure ttydg "/usr/libexec/getty std.115200" dialup on insecure # Pseudo terminals ttyp0 none network {SNIP} Here is /etc/rc.serial: majorly snipped: #!/bin/sh # $Id: rc.serial,v 1.4.4.3 1996/07/02 14:39:34 bde Exp $ default() { # Reset everything changed by the other functions to initial defaults. ci=$1; shift # call in device identifier co=$1; shift # call out device identifier for i in $* do comcontrol /dev/tty$ci$i dtrwait 300 drainwait 0 stty Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07481 for hackers-outgoing; Tue, 18 Mar 1997 14:49:37 -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 OAA07470 for ; Tue, 18 Mar 1997 14:49:19 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA22129; Tue, 18 Mar 1997 23:49:03 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id VAA06438; Tue, 18 Mar 1997 21:57:13 +0100 (MET) Message-ID: <19970318215713.RB16737@uriah.heep.sax.de> Date: Tue, 18 Mar 1997 21:57:13 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: RGireyev@BELLIND.COM Cc: freebsd-hackers@freebsd.org Subject: Re: Donation please ... References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from RGireyev@BELLIND.COM on Mar 18, 1997 11:46:09 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As RGireyev@BELLIND.COM wrote: > Could ya'll help a fellow American who is down on his luck. > All I need is the source distribution for top. Stuff like > top.h, top.c (maybe even a makefile). I'm having trouble > getting into the FTP site where sources supposedly are, and > they don't seem to exist anywhere on ftp.freebsd.org. Try any of the FreeBSD mirrors, like ftp://ftp.de.freebsd.org/pub/FreeBSD/distfiles/top-3.4.tar.gz -- 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 Mar 18 14:50:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07553 for hackers-outgoing; Tue, 18 Mar 1997 14:50:02 -0800 (PST) Received: from newland.com ([205.233.79.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA07512 for ; Tue, 18 Mar 1997 14:49:55 -0800 (PST) Received: from mnewton.newland.com ([205.233.79.111]) by newland.com (8.6.12/8.6.12) with SMTP id RAA23307 for ; Tue, 18 Mar 1997 17:50:14 -0500 Message-ID: <332F1BFE.4DD7@newland.com> Date: Tue, 18 Mar 1997 17:49:34 -0500 From: mnewton Organization: The Newland Group X-Mailer: Mozilla 2.01Gold (Win95; I) MIME-Version: 1.0 To: hackers Subject: root passwd got fried Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Help!!!!!! Some how the root passwd got fried on one pc. I can login to any other user but root. I can't su either , gives bad string error. anyway of fixing the root passwd i.e thru a boot maintenace mode or something From owner-freebsd-hackers Tue Mar 18 14:54:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA08132 for hackers-outgoing; Tue, 18 Mar 1997 14:54:11 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08127 for ; Tue, 18 Mar 1997 14:54:08 -0800 (PST) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.8.3/8.6.9) with SMTP id RAA03800 for ; Tue, 18 Mar 1997 17:57:17 -0500 (EST) Message-Id: <3.0.32.19970318175056.00adbf78@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Mar 1997 17:50:59 -0500 To: hackers@freebsd.org From: dennis Subject: 2.2 build problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When compiling our driver, the file sys/conf.h includes a file ioconf.h (that is a #include of /usr/include/machine/conf.h) is missing. Does anyone know where its SUPPOSED to be, and why I don't seem to have it? Thanks, Dennis From owner-freebsd-hackers Tue Mar 18 14:55:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA08175 for hackers-outgoing; Tue, 18 Mar 1997 14:55:25 -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 OAA08165 for ; Tue, 18 Mar 1997 14:55:21 -0800 (PST) Received: from misery.sdf.com [204.244.213.33] by misery.sdf.com with smtp (Exim 1.59 #1) id 0w77lA-0003XV-00; Tue, 18 Mar 1997 14:53:36 -0800 Date: Tue, 18 Mar 1997 14:53:36 -0800 (PST) From: Tom Samplonius To: RGireyev@bellind.com cc: freebsd-hackers@freebsd.org Subject: RE: Donation please ... 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, 18 Mar 1997 RGireyev@bellind.com wrote: > Thank you for replying Terry. I think you may have missed > a sentence in my original posting. I am having trouble > getting into the FTP site that has the sources. I'm sorry > to trouble the list with something so stupid. Then perhaps you need to fix your net connectivity, because eecs.nwu.edu is working fine. Tom From owner-freebsd-hackers Tue Mar 18 15:07:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08873 for hackers-outgoing; Tue, 18 Mar 1997 15:07:05 -0800 (PST) Received: from bellind.com ([206.101.34.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA08864 for ; Tue, 18 Mar 1997 15:07:02 -0800 (PST) From: RGireyev@BELLIND.COM Received: from cdcexchange.bellind.com ([170.1.130.2]) by firewall.bellind.com with SMTP id <3661-1>; Tue, 18 Mar 1997 15:04:36 -0800 Received: by cdcexchange.bellind.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC33AE.9AFCB4F0@cdcexchange.bellind.com>; Tue, 18 Mar 1997 15:11:07 -0800 Message-ID: To: Cc: Subject: RE: Donation please ... Date: Tue, 18 Mar 1997 15:11:06 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Huge thanks to all for replying. I now have the source code I was looking for. Rudy. P.S. Just for the record there is nothing wrong with the ftp://eecs.nwu.edu the problem is on my end. My uncompromising network administrator is unable to configure our DNS correctly. The reverse name resolution does not work. Neither he nor his boss are willing to listen to suggestions from someone as lowly and insignificant as me. If you need further proof look at the header of my email and you'll see MS-Exchange. Ohh well, as long as I have FreeBSD to hack on when I go home I really don't care what they pay me to do here. >---------- >From: Tom Samplonius[SMTP:tom@sdf.com] >Sent: Tuesday, March 18, 1997 2:53 PM >To: Rudy Gireyev >Cc: freebsd-hackers@FreeBSD.ORG >Subject: RE: Donation please ... > > >On Tue, 18 Mar 1997 RGireyev@bellind.com wrote: > >> Thank you for replying Terry. I think you may have missed >> a sentence in my original posting. I am having trouble >> getting into the FTP site that has the sources. I'm sorry >> to trouble the list with something so stupid. > > Then perhaps you need to fix your net connectivity, because >eecs.nwu.edu >is working fine. > >Tom > > From owner-freebsd-hackers Tue Mar 18 15:09:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09047 for hackers-outgoing; Tue, 18 Mar 1997 15:09:19 -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 PAA09033 for ; Tue, 18 Mar 1997 15:09:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id PAA11166; Tue, 18 Mar 1997 15:10:20 -0800 (PST) Message-Id: <199703182310.PAA11166@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: "David S. Miller" cc: tom@sdf.com, bag@sinbin.demos.su, hackers@freebsd.org, mishania@demos.su Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpreg.h In-reply-to: Your message of "Tue, 18 Mar 1997 15:47:55 EST." <199703182047.PAA27027@jenolan.caipgeneral> From: David Greenman Reply-To: dg@root.com Date: Tue, 18 Mar 1997 15:10:20 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Date: Tue, 18 Mar 1997 12:09:14 -0800 (PST) > From: Tom Samplonius > > > solaris 2.5.1 100Mb/full solaris 2.5.1 100Mb/full 4700 MBytes/sec > >Thats incredible, Sun doesn't even claim such good numbers, and also >neither do I! Congrats.. ;-) Yes, these are some of the first results out of our TeraBit project. I admit that 4.7GB/sec is a little low for something intended to be scaled to a TeraBit, but it's a start. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project :-) From owner-freebsd-hackers Tue Mar 18 15:09:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09059 for hackers-outgoing; Tue, 18 Mar 1997 15:09:21 -0800 (PST) Received: from bellind.com ([206.101.34.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA09038 for ; Tue, 18 Mar 1997 15:09:17 -0800 (PST) From: RGireyev@BELLIND.COM Received: from cdcexchange.bellind.com ([170.1.130.2]) by firewall.bellind.com with SMTP id <3660-1>; Tue, 18 Mar 1997 15:06:51 -0800 Received: by cdcexchange.bellind.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC33AE.EBA29C80@cdcexchange.bellind.com>; Tue, 18 Mar 1997 15:13:23 -0800 Message-ID: To: Subject: RE: Donation please ... Date: Tue, 18 Mar 1997 15:13:21 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Huge thanks to all for replying. I now have the source code I was looking for. Rudy. P.S. Just for the record there is nothing wrong with the ftp://eecs.nwu.edu the problem is on my end. My uncompromising network administrator is unable to configure our DNS correctly. The reverse name resolution does not work. Neither he nor his boss are willing to listen to suggestions from someone as lowly and insignificant as me. If you need further proof look at the header of my email and you'll see MS-Exchange. Ohh well, as long as I have FreeBSD to hack on when I go home I really don't care what they pay me to do here. -------------------------------------------------- Beavis and Butt-head Software Co Inc | Fone 1-800-555-CHICKs "Just press any key, dude!!!!" | Phaks 1-800-555-BUTT -------------------------------------------------- From owner-freebsd-hackers Tue Mar 18 15:20:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09667 for hackers-outgoing; Tue, 18 Mar 1997 15:20:09 -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 PAA09627 for ; Tue, 18 Mar 1997 15:20:00 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id JAA19519; Wed, 19 Mar 1997 09:49:46 +1030 (CST) From: Michael Smith Message-Id: <199703182319.JAA19519@genesis.atrad.adelaide.edu.au> Subject: Re: further on 2.1.6 & 2940 In-Reply-To: <19970318212144.WS51057@uriah.heep.sax.de> from J Wunsch at "Mar 18, 97 09:21:44 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 19 Mar 1997 09:49:46 +1030 (CST) Cc: hackers@freebsd.org, avalon@coombs.anu.edu.au 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: > As Darren Reed wrote: > > > # scsi -f /dev/rst0.ctl -m 3 ^^^ ... > ASC/ASCQ 24 00 is ``Invalid field in CDB''. Byte 2 value 3 is the > number of the mode page in the CDB. Your drive doesn't support mode > page #3, the rigid disk geometry page. Let me guess: it's a Jaz > drive, ain't it? IOmega didn't bother to tell you how many cylinders > and heads they are using. No, it's not a Jaz drive. Tape drive's don't have "rigid disk geometry" pages either 8) For reference, here's what a Jaz says if you try that : lovely# scsi -f /dev/rsd6.ctl -m 3 SCIOCCOMMAND ioctl: Command accepted. return status 3 (Sense Returned)Command out (6 of 6): 1a 00 03 00 ff 00 Data in (0 of 255): Error code is "current errors" Segment number is 00 Sense key is "Illegal request" The Information field is not valid but contains 00000000 (0). The Command Specific Information field is 00000000 (0). Additional sense code: 24 Additional sense code qualifier: 00 sense (32 of 48): 70 00 05 00 00 00 00 11 00 00 00 00 24 00 00 00 00 00 04 c6 01 33 d9 00 00 00 00 00 00 00 00 00 > -- > 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. ;-) > -- ]] 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 Mar 18 15:28:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10201 for hackers-outgoing; Tue, 18 Mar 1997 15:28:58 -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 PAA10191 for ; Tue, 18 Mar 1997 15:28:53 -0800 (PST) Message-Id: <199703182328.PAA10191@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA190457549; Wed, 19 Mar 1997 10:25:49 +1100 From: Darren Reed Subject: Re: dds tape drives. To: hackers@FreeBSD.ORG Date: Wed, 19 Mar 1997 10:25:49 +1100 (EDT) In-Reply-To: <199703181259.EAA28875@who.cdrom.com> from "Darren Reed" at Mar 18, 97 11:55:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk further to this cause, I can do a remote dump to st0 with a blocking factor of 56, but locally, doing "dump 0bf 56 /dev/nrst0 /" will generate lots of SCSI error messages. I take this to mean it doesn't like data coming at it fast, but why doesn't the SCSI stuff handle this rather than proucing all those error messsages ? From owner-freebsd-hackers Tue Mar 18 15:44:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11342 for hackers-outgoing; Tue, 18 Mar 1997 15:44:37 -0800 (PST) Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11331; Tue, 18 Mar 1997 15:44:33 -0800 (PST) Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.5/(97/03/03 3.23)) id SAA21714; Tue, 18 Mar 1997 18:44:21 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from crc3.concentric.net (61033d0022ny.concentric.net [206.173.18.82]) by newman.concentric.net (8.8.5) id SAA25036; Tue, 18 Mar 1997 18:44:19 -0500 (EST) Message-ID: <332F2938.76EB@concentric.net> Date: Tue, 18 Mar 1997 18:46:00 -0500 From: "Richard J. Linane" Reply-To: Typh0on@concentric.net Organization: Richard J. Linane X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-announce@freebsd.org Subject: Ports Collection through DOS Partitian 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 way to install a ports collcetion from a DOS partitian to a second drive with 2.1.7 bsd on it. From owner-freebsd-hackers Tue Mar 18 15:52:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11975 for hackers-outgoing; Tue, 18 Mar 1997 15:52:44 -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 PAA11968; Tue, 18 Mar 1997 15:52:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id PAA11329; Tue, 18 Mar 1997 15:52:32 -0800 (PST) Message-Id: <199703182352.PAA11329@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Brian McGovern cc: questions@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Question on mapping PCI memory (Repeat) In-reply-to: Your message of "Tue, 18 Mar 1997 15:28:28 EST." <199703182028.PAA00353@bmcgover-pc.cisco.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 18 Mar 1997 15:52:32 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Therefore: > > I am assuming that I can use the pci_map_mem routine, and do >something like: > > vm_offset_t vaddr, paddr; > > if (pci_map_mem(config_id, CZ_PCI_PLX9060_MEM, &vaddr, &paddr) == 0) > die(); > >and then have (unsigned char *)vaddr be a pointer to my virtual memory space, >which I can then memcpy to, or do things like >(unsigned char *)vaddr[index] = 0; and such. > >Also, as an alternative, I can do it the long way, similar to: > > paddr = pci_conf_read(config_id, CZ_PCI_PLX9060_MEM); > vaddr = (vm_offset_t)pmap_mapdev(paddr, 72); > >Then use vaddr as above as the virtual addresses. > >The questions I have are: > >1.) Is this correct? If so, yea me. If not, which invokation is incorrect? Yes, either way will work. >2.) Do I have to do anything extra fancy, such as take extra steps to >align on page boundaries and such, and, if so, how would I go about >doing that? The virtual and physical addresses returned will be on page boundries; you don't need to do anything special. >3.) Do I have to worry about locking the virtual memory space down? I assume >they'd become kernel pages (as this is for a device driver), so they should >never be "swapped". No, the kernel isn't pageable, and even if it were, pages associated with device memory would never be reclaimed. So in other words, the device memory will be mapped and stay mapped until you explicitly unmap it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Mar 18 16:32:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16368 for hackers-outgoing; Tue, 18 Mar 1997 16:32:55 -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 QAA16357 for ; Tue, 18 Mar 1997 16:32:51 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA20049; Wed, 19 Mar 1997 11:02:29 +1030 (CST) From: Michael Smith Message-Id: <199703190032.LAA20049@genesis.atrad.adelaide.edu.au> Subject: Re: 2.2 build problem In-Reply-To: <3.0.32.19970318175056.00adbf78@etinc.com> from dennis at "Mar 18, 97 05:50:59 pm" To: dennis@etinc.com (dennis) Date: Wed, 19 Mar 1997 11:02:28 +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 dennis stands accused of saying: > > When compiling our driver, the file sys/conf.h includes a file ioconf.h > (that is a #include of /usr/include/machine/conf.h) is missing. > > Does anyone know where its SUPPOSED to be, and why I don't seem > to have it? It's generated by 'config' when you configure your kernel. Either there is something wrong with your kernel configuration and config is not generating it, or you have something else mucked up. If you are building an LKM, bsd.kmod.mk defines ACTUALLY_LKM_NOT_KERNEL and ioconf.h isn't picked up. If that's not helpful enough, throw us some more details and we'll see what we can do to help. > Dennis -- ]] 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 Mar 18 16:51:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18107 for hackers-outgoing; Tue, 18 Mar 1997 16:51:58 -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 QAA18074 for ; Tue, 18 Mar 1997 16:51:27 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA20233; Wed, 19 Mar 1997 11:19:47 +1030 (CST) From: Michael Smith Message-Id: <199703190049.LAA20233@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703181834.LAA09912@phaeton.artisoft.com> from Terry Lambert at "Mar 18, 97 11:34:23 am" To: terry@lambert.org (Terry Lambert) Date: Wed, 19 Mar 1997 11:19:47 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De 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: > > Given that we have established that it's not feasible or desirable to > > write to the media, as it's not possible to determine where is a safe > > place on said media to write to until after we have obtained the facts > > that we are trying to obtain, this doesn't work. > > We've established no such ting. For an invalid partition, or for > equivalent partition IDs which differ only in value, there are a > number of things it is quite safe to twiddle with at the front of > the disk. There are? We haven't yet established where "the front of the disk" is yet. It's not safe (or reliable) to try to rewrite the MBR (virus protection), or the slack space following (some other systems put bootstraps there). Then the next cylinder might be a partition. > > Also, the practicalities involved in the int13 driver you're discussing > > are horrific. > > You said impossible. Now you say impractical. How soon until we get > to unavoidable? 8-). No, I said the practicalities are horrific. I don't see an int13 driver giving us anything that we don't have already. > > What we care about is finding sectors on the disk, given some information > > in c/h/s format. It is only correct that we are similarly misled to DOS if > > we were booted from the same source as DOS. This is not necessarily so. > > ??? > > DOS can only boot off the initial drive. FreeBSD will only boot off > the initial drive after install. DOS can be booted from lots of places; think "network boot", or "floppy disk". So can FreeBSD; there is no guarantee there at all. > The only issue you can be referring to is the OnTrack boot manager on > the hard drive during a boot-from-floppy install, where the OnTrack > code will not modify the values returned by the INT 13. That's one case. > This can be reconciled by using LBA based I/O, if possible, and by > recognizing the OnTrack code, if not (recognition of the OnTrack code > is already implemented). Yes. Fortunately, the need for DiskMangler is fading fast. > Well, I said to read the documentation, not to buy it. Am I a > plaintiff by this description? Tell me what you want, and I will > try to provide the information in paraphrased for other form that > won't violate my license. Reading the documentation implies access to it. My point is that access to the documentation you are suggesting comes at a price that I cannot stomach. So far, I've done remarkably well with a copy of the old Pink Shirt Book. > Well, yes, I've been raving for ELF. With John Polstra's "branding" > patches, the last real techinical issue against it is gone. Apparently ILT has made changes to the FSF tools for some sort of ABI branding; I am hopeful that this will be adequate and, preferably, compatible 8) > I would prefer this as well. But if you wanted to support only one > file in the vn_* routines in real mode, and then support multiple files > after word, then you could make the kernel contain all boot-critical > devices. You should probably do this anyway. The initial loader pass should include the kernel core and whatever boot-critical devices are required. This obviates the need for any devices at all in the kernel core. I realise that this is going to take some serious work; I'd love to have the time to do this properly 8( > it means no recompilation to support config options, as long as we > get rid of the static compilation issues in shared code (#if FEATURE > 1) > and so on. This is actually a huge issue; the assumption that devices are numbered from 0->(NFOO-1) is another wart that I would like to rip. > Because I have to provide changes in "bite sized chunks" to allow them > to be digested, we will have to incrementally work back up to where I > was on my own machines in June of 1994. > > A coherent kernel file I/O interface is about three chunks past the > currently outstanding chunk. Ok; still, I'm happy to hear that _something_ is being done about it. > > > 0x40000000 Readable section > > > 0x80000000 Writable section > > ?! > > Think of "-fwriteable_strings"... There are 4 possible combinations of those values : 0) not readable, not writable 1) readable, not writable 2) not readable, writable 3) readable, writable Of those, remembering that this is a program's text file, I can only see 1) and 3) being any use, ie. the 'readable' bit is pointless. > Yes. The utility of the attributes at boot time is to decide to > load a particular segment or not. Preload is the most interesting > attribute in this regard; it should probably be implied on non-pageable > segments. Hmm. The nature of the boot-time linking process would probably imply that all of the objects in question would have to be loaded, as there would be no paging mechanism by which unloaded sections could be loaded until after the system was up, and possibly not even then (eg. boot from network server, no kernel core locally). > > Public libraries tend not to have technical books. > > Whoah. No wonder you guys are so gung-ho on the Internet... Yeah. And don't get me started on getting technical literature out of hardware vendors. You have any details on the "Apollo Utility chip" in the HP9000/4xx machines? 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 Tue Mar 18 18:12:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25648 for hackers-outgoing; Tue, 18 Mar 1997 18:12:44 -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 SAA25643 for ; Tue, 18 Mar 1997 18:12:42 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id SAA01485 for ; Tue, 18 Mar 1997 18:12:41 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id SAA16117; Tue, 18 Mar 1997 18:10:08 -0800 (PST) Message-Id: <199703190210.SAA16117@austin.polstra.com> To: gjm11@dpmms.cam.ac.uk Subject: Re: CVSup tags Newsgroups: polstra.freebsd.hackers In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Tue, 18 Mar 1997 18:10:08 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Gareth McCaughan wrote: > Is there any way of finding out a complete set of valid CVS tags > for the CVS repository available via CVSup? All the useful ones are documented in section 17.2.3 of the FreeBSD Handbook. -- 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 Tue Mar 18 18:18:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25904 for hackers-outgoing; Tue, 18 Mar 1997 18:18: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 SAA25889 for ; Tue, 18 Mar 1997 18:18:15 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA12544; Wed, 19 Mar 1997 02:17:59 GMT Message-Id: <199703190217.CAA12544@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: mnewton cc: hackers Subject: Re: root passwd got fried In-reply-to: Your message of "Tue, 18 Mar 1997 17:49:34 EST." <332F1BFE.4DD7@newland.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Mar 1997 02:17:58 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Help!!!!!! > Some how the root passwd got fried on one pc. I can login to any other > user but root. I can't su either , gives bad string error. > anyway of fixing the root passwd i.e thru a boot maintenace mode > or something Reboot (CTL-ALT-DEL) and boot with -s, mount -u / and mount /usr then vipw. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Mar 18 18:56:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA28011 for hackers-outgoing; Tue, 18 Mar 1997 18:56:02 -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 SAA27994 for ; Tue, 18 Mar 1997 18:55:58 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA21222; Wed, 19 Mar 1997 13:25:16 +1030 (CST) From: Michael Smith Message-Id: <199703190255.NAA21222@genesis.atrad.adelaide.edu.au> Subject: Re: still more digiboard and modem questions/problems... In-Reply-To: <1.5.4.32.19970318073133.0069556c@jump.net> from Lee Crites at "Mar 18, 97 01:31:33 am" To: adonai@jump.net (Lee Crites) Date: Wed, 19 Mar 1997 13:25:16 +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 Lee Crites stands accused of saying: > ALL of them used to say uucp:dialer. What changes them is a mystery to me. Various things. Don't worry about it too much, although you might want to mark the ports you settle on as modem ports in /etc/rc.serial. > * I added these records to /etc/ttys: > ttyD00 "/usr/libexec/getty std.57600" dialup on insecure > ttyD01 "/usr/libexec/getty std.57600" dialup on insecure > ttyD02 "/usr/libexec/getty std.57600" dialup on insecure > ttyD03 "/usr/libexec/getty std.57600" dialup on insecure > ttyD04 "/usr/libexec/getty std.57600" dialup off insecure > ttyD05 "/usr/libexec/getty std.57600" dialup off insecure > ttyD06 "/usr/libexec/getty std.57600" dialup off insecure > ttyD07 "/usr/libexec/getty std.57600" dialup off insecure > #cuaD00 "/usr/libexec/getty std.57600" dialup on insecure > cuaD01 "/usr/libexec/getty std.57600" dialup on insecure > cuaD02 "/usr/libexec/getty std.57600" dialup on insecure > cuaD03 "/usr/libexec/getty std.57600" dialup on insecure > cuaD04 "/usr/libexec/getty std.57600" dialup off insecure > cuaD05 "/usr/libexec/getty std.57600" dialup off insecure > cuaD06 "/usr/libexec/getty std.57600" dialup off insecure > cuaD07 "/usr/libexec/getty std.57600" dialup off insecure > cuaD00 "/usr/local/sbin/mgetty" dialup on insecure That's stupid 8). Why do you have gettys on both the dialin and dialout ports? > I got a suggestion to use mgetty instead of getty, so I compiled and > installed it from the ports area. As you can see, I'm testing one of both > (cuaD00 as mgetty and cuaD01 as getty). mgetty sucks (IMHO). Avoid it unless you're doing something special. You want to run a normal getty on the dialin (ttyD) port _only_. You will also want to make sure your modems are configured correctly. In particular, you want DCD-follows-carrier, no echo, no result codes. Something like at&c0e0q1&w will work for most Rockwell-based modems (note that c0/c1 varies, check your modem manual for the right sense for yours.) -- ]] 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 Mar 18 19:05:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA29341 for hackers-outgoing; Tue, 18 Mar 1997 19:05:10 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA29325 for ; Tue, 18 Mar 1997 19:05:00 -0800 (PST) From: tenser@spitfire.ecsel.psu.edu Received: (qmail 29295 invoked by uid 1000); 19 Mar 1997 03:04:37 -0000 Date: 19 Mar 1997 03:04:37 -0000 Message-ID: <19970319030437.29294.qmail@spitfire.ecsel.psu.edu> To: hackers@freebsd.org Subject: X11 under 2.2-RELEASE? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm, is it just me, or are the versions of xterm and xdm shipped with 2.2-RELEASE still slightly skewed with respect to utmp? : krusty 6; w 10:04PM up 2:48, 3 users, load averages: 0.00, 0.08, 0.33 USER TTY FROM LOGIN@ IDLE WHAT tad v0 - 7:16PM 2:47 xinit -- tenser p1 spitfire.ecsel.p 10:02PM - w ttyp0 tad 13Aug95 2:47 - : krusty 7; I don't think that ttyp0 is a valid user. :-) Then again, this could be a different bug just now rearing it's ugly head, or krusty might be slightly messed up. If I'm missing something obvious here, please throw a slap upside the grape my way. :-) - Dan C. From owner-freebsd-hackers Tue Mar 18 19:45:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA02535 for hackers-outgoing; Tue, 18 Mar 1997 19:45:44 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02530 for ; Tue, 18 Mar 1997 19:45:41 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id TAA19448; Tue, 18 Mar 1997 19:45:25 -0800 (PST) To: tenser@spitfire.ecsel.psu.edu cc: hackers@FreeBSD.ORG Subject: Re: X11 under 2.2-RELEASE? In-reply-to: Your message of "19 Mar 1997 03:04:37 GMT." <19970319030437.29294.qmail@spitfire.ecsel.psu.edu> Date: Tue, 18 Mar 1997 19:45:25 -0800 Message-ID: <19445.858743125@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hmm, is it just me, or are the versions of xterm and xdm shipped with > 2.2-RELEASE still slightly skewed with respect to utmp? When did you last check? Rich *just* updated them yesterday. Jordan From owner-freebsd-hackers Tue Mar 18 21:28:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA07067 for hackers-outgoing; Tue, 18 Mar 1997 21:28:46 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA07062 for ; Tue, 18 Mar 1997 21:28:35 -0800 (PST) Received: (qmail 29934 invoked by uid 1000); 19 Mar 1997 05:28:15 -0000 Message-ID: <19970319052815.29933.qmail@spitfire.ecsel.psu.edu> To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: X11 under 2.2-RELEASE? In-reply-to: Your message of "Tue, 18 Mar 1997 19:45:25 PST." <19445.858743125@time.cdrom.com> Date: Wed, 19 Mar 1997 00:28:15 -0500 From: Dan Cross Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hmm, is it just me, or are the versions of xterm and xdm shipped with > > 2.2-RELEASE still slightly skewed with respect to utmp? > > When did you last check? Rich *just* updated them yesterday. Ahhh... Okay, it looks like we missed it by one day. :-) I'm re- downloading now. Thanks. The machine in question isn't under my control, but I'll let the right people know. :-) - Dan C. From owner-freebsd-hackers Tue Mar 18 22:48:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA15965 for hackers-outgoing; Tue, 18 Mar 1997 22:48:42 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA15881 for ; Tue, 18 Mar 1997 22:48:40 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA20167 for ; Tue, 18 Mar 1997 22:48:40 -0800 (PST) To: hackers@freebsd.org Subject: dup3() - I've thought it over and decided... Date: Tue, 18 Mar 1997 22:48:39 -0800 Message-ID: <20163.858754119@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's a hack. Forget about it. :-) That said, I think that there's a need for a more generalized I/O model which allows this kind of in-flight disconnection and reconnection of I/O handles a process might have open, but it needs to be a lot more involved than just thwapping over somebody's file handles. :-) There needs to be some mechanism for flushing or discarding pending I/O on reconnect, for one thing, and it needs to play friendly with stdio. I'll think about the problem some more.. :) Jordan From owner-freebsd-hackers Tue Mar 18 22:53:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA20658 for hackers-outgoing; Tue, 18 Mar 1997 22:53:16 -0800 (PST) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA20646 for ; Tue, 18 Mar 1997 22:53:06 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id QAA23547; Wed, 19 Mar 1997 16:50:20 +1000 Received: by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) id QAA16421; Wed, 19 Mar 1997 16:40:30 +1000 (EST) Date: Wed, 19 Mar 1997 16:40:30 +1000 (EST) From: Stephen McKay Message-Id: <199703190640.QAA16421@ogre.dtir.qld.gov.au> To: "Jordan K. Hubbard" cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: REPOST: dup3() - interesting feature-in-training or silly hack? X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: >The subject alone should have the kernel hackers all running for >shelter at this point - "Aigh! He's looking in /usr/src/sys!" >they yell. "Somebody stop him!!" :-) Jordan, Jordan, Jordan! I'm speechless! I think you should have a bit of a rest. Reality should return in a few hours. Unless you took a lot of it, then you might be OK in a few days. To be serious for a moment, this extra utility does not justify the cost. The cost is in degrading our process model. Before this change, a process had certain guarantees and had to ask explicitly for things to happen to it except for 2 things: external signals, and debugging (ptrace). Debugging has to be external to the process. External signals (unlike internally requested signals like timed alarms and child status changes) are usually fatal, and so cause a relatively simple cleanup and exit. The proposed "dup3" adds a new class of invasive system calls. Where does it stop? remote_chdir()? remote_putenv()? The guaranteed boundaries between processes that allow the programmer to be certain of what will work are eroded by the proposed dup3, and by all similar "pull the rug out from under it" mechanisms. (I forgot revoke() back there a bit. It, like external signals, is for fatal conditions only.) >So what's the use of it? To use in things like shells, so that you >can do stuff like this: > ># make world > >^Z%1 Suspended ># bg > make.out ># > >This also works with fg, so you can foreground and redirect stdin, >stdout and stderr at the same time just as easily. There are at least two solutions to this problem, one simple, one complex. I have an alias that always stores the output of make into a file. I can then use tail -f to look at it in real time, or simply wait for later. The more complex version is to change your shell to allocate a virtual terminal to every command and manage the output. Thus, your shell could simply copy the output from make's virtual terminal to your main terminal (virtual or real), or when commanded, it could copy it to a file, or feed it to another pipeline. Similarly for input. This would not violate the sanctity of the processes involved. Then, if you wanted to optimise slightly, you could hack your kernel to plug the output of one virtual terminal directly into the output of another one, avoiding the overhead of the usual case of background processes writing to your terminal. That would be a nicer kernel project. :-) >Feedback most welcome. I think you've had an interesting learning experience doing this (tragic) thing to your kernel, but now you should put it all back. Stephen. From owner-freebsd-hackers Tue Mar 18 23:02:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA07261 for hackers-outgoing; Tue, 18 Mar 1997 23:02:20 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA07234 for ; Tue, 18 Mar 1997 23:02:17 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id XAA20256; Tue, 18 Mar 1997 23:01:42 -0800 (PST) To: Stephen McKay cc: freebsd-hackers@freebsd.org Subject: Re: REPOST: dup3() - interesting feature-in-training or silly hack? In-reply-to: Your message of "Wed, 19 Mar 1997 16:40:30 +1000." <199703190640.QAA16421@ogre.dtir.qld.gov.au> Date: Tue, 18 Mar 1997 23:01:42 -0800 Message-ID: <20252.858754902@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think you've had an interesting learning experience doing this (tragic) > thing to your kernel, but now you should put it all back. :-) :-) Yes, I'd already decided that well before now. Of course, having to allocate virtual terminals all over the place just to get a flexible I/O model is rude and disgusting too, and only shows that somebody wasn't thinking hard enough when they decided that having stdin, stdout and stderr constituted "sufficient interaction" for a UNIX process. Now if just files and sockets and pipes went away and became generalized CORBA objects, we could... *Wurgh* Sorry... Still some lingering side-effects. :-) Jordan From owner-freebsd-hackers Tue Mar 18 23:36:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09469 for hackers-outgoing; Tue, 18 Mar 1997 23:36:17 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09452; Tue, 18 Mar 1997 23:36:13 -0800 (PST) From: Mike Pritchard Message-Id: <199703190736.XAA09452@freefall.freebsd.org> Subject: Re: dup3() - I've thought it over and decided... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 18 Mar 1997 23:36:12 -0800 (PST) Cc: hackers@freebsd.org In-Reply-To: <20163.858754119@time.cdrom.com> from "Jordan K. Hubbard" at Mar 18, 97 10:48:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > It's a hack. Forget about it. :-) > > That said, I think that there's a need for a more generalized I/O > model which allows this kind of in-flight disconnection and > reconnection of I/O handles a process might have open, but it needs to > be a lot more involved than just thwapping over somebody's file > handles. :-) There needs to be some mechanism for flushing or > discarding pending I/O on reconnect, for one thing, and it needs to > play friendly with stdio. > > I'll think about the problem some more.. :) How about going more along the checkpoint/restart route? Suspend the process, checkpoint it, and on restart you can reconnect stdin/out/err to either the current tty, or to another file. Reconnecting to a pipeline should also be possible. I can dig up the USENIX paper the Cray guys wrote on this if you like :-). Like you, I often do something like: % some long running command that generates output [oh, I have to go, geez, I wish I had redirected the output, darn...] ^C % nohup same_command >& out -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-hackers Wed Mar 19 00:51:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA12503 for hackers-outgoing; Wed, 19 Mar 1997 00:51:06 -0800 (PST) Received: from infoce-2-ll.ll4.relcom.ru (infoce-2-ll.ll4.relcom.ru [193.124.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12494 for ; Wed, 19 Mar 1997 00:50:50 -0800 (PST) Received: from matrix.infoce-2-ll.ll4.relcom.ru by infoce-2-ll.ll4.relcom.ru with ESMTP id LAA07126; (8.6.11/vak/1.9) Wed, 19 Mar 1997 11:44:30 +0300 Message-Id: <199703190844.LAA07126@infoce-2-ll.ll4.relcom.ru> From: "Artem Koutchine" To: Cc: Subject: ATAPI and INSTALL.. 2b|!2B Date: Wed, 19 Mar 1997 15:42:52 +0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello! Maybe I am a little bit out of date, but the fact is that i got 2CD installations of FreeBSD 2.1.0 and i Have a Pentium PC with tomato motherboard (HX chipset) and 8x ATAPI CD-ROM (LG exGoldStar). I tried everything that have been written in the readme files and install.txt and others, but nothing worked. I still cannot install FreeBSD because it just does not find my CD-ROM. As was said in one of the readme files, the ATAPI driver is in the ALPHA state. Was it updated since then ? And, of course, how can I install FreeBSD ? (ftp install will not work, because it will take about 2 months to complete, LAN install will not work eather, because there is no LAN here) I was think about doing install from a DOS partition by installing a new HDD, copying file there and then installing it from there to another hdd. But i don't have an empty hdd..:(( Help me, please! Artem Koutchine matrix@infoce-2-ll.ll4.relcom.ru From owner-freebsd-hackers Wed Mar 19 01:06:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA12973 for hackers-outgoing; Wed, 19 Mar 1997 01:06:08 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA12967 for ; Wed, 19 Mar 1997 01:06:04 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id BAA20686; Wed, 19 Mar 1997 01:06:03 -0800 (PST) To: Mike Pritchard cc: hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... In-reply-to: Your message of "Tue, 18 Mar 1997 23:36:12 PST." <199703190736.XAA09452@freefall.freebsd.org> Date: Wed, 19 Mar 1997 01:06:03 -0800 Message-ID: <20682.858762363@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > How about going more along the checkpoint/restart route? Suspend > the process, checkpoint it, and on restart you can reconnect stdin/out/err > to either the current tty, or to another file. Reconnecting to > a pipeline should also be possible. I can dig up the USENIX paper > the Cray guys wrote on this if you like :-). Does the checkpoint feature allow you to complete snapshot process state? That's another item on my wishlist. :-) I wouldn't mind reading that paper, if you can dig it up. Anyone remember a timesharing system called ITS (from MIT)? If you got disconnected from the modem (not uncommon in those days of Pennywhistle, 300 baud acoustically-coupled modems :-) you wouldn't lose your session, like you do under UNIX, rather the next time you logged in it would ask you: [Attach your detached tree?] And if you said 'y' you'd get your old process tree back, everything right where you left it. Now I'm not sure if ITS accomplished this by leaving your processes suspended and under the ownership of some foster parent for a certain period of time, or if it genuinely saved them to disk and then resurrected them on demand, but it sure was a bloody convenient feature which I've always missed! :-) Jordan From owner-freebsd-hackers Wed Mar 19 01:35:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA13776 for hackers-outgoing; Wed, 19 Mar 1997 01:35:08 -0800 (PST) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA13766 for ; Wed, 19 Mar 1997 01:35:04 -0800 (PST) Received: (from joe@localhost) by florence.pavilion.net (8.8.5/8.8.5) id JAA24055; Wed, 19 Mar 1997 09:33:58 GMT Message-ID: <19970319093358.36887@pavilion.net> Date: Wed, 19 Mar 1997 09:33:58 +0000 From: Josef Karthauser To: "Jordan K. Hubbard" Cc: Mike Pritchard , hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... References: <199703190736.XAA09452@freefall.freebsd.org> <20682.858762363@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <20682.858762363@time.cdrom.com>; from Jordan K. Hubbard on Wed, Mar 19, 1997 at 01:06:03AM -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Mar 19, 1997 at 01:06:03AM -0800, Jordan K. Hubbard wrote: > > [Attach your detached tree?] > > And if you said 'y' you'd get your old process tree back, everything > right where you left it. > > Now I'm not sure if ITS accomplished this by leaving your processes > suspended and under the ownership of some foster parent for a certain > period of time, or if it genuinely saved them to disk and then > resurrected them on demand, but it sure was a bloody convenient > feature which I've always missed! :-) The package 'screen' allows a similar thing. It manages virtual shells on a terminal and allows you to detach the whole lot in one go, and then reattach from anywhere. I used to use it at University when terminals were hard to hold on to all day (due to student demand). Useful for that FTP that's going to take all day. :) Joe -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073] From owner-freebsd-hackers Wed Mar 19 01:38:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA13888 for hackers-outgoing; Wed, 19 Mar 1997 01:38:47 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA13880 for ; Wed, 19 Mar 1997 01:38:42 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id RAA01909; Wed, 19 Mar 1997 17:36:02 +0800 (WST) Date: Wed, 19 Mar 1997 17:36:02 +0800 (WST) From: Adrian Chadd To: "Jordan K. Hubbard" cc: Mike Pritchard , hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... In-Reply-To: <20682.858762363@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 > Anyone remember a timesharing system called ITS (from MIT)? If you > got disconnected from the modem (not uncommon in those days of > Pennywhistle, 300 baud acoustically-coupled modems :-) you wouldn't > lose your session, like you do under UNIX, rather the next time you > logged in it would ask you: > > [Attach your detached tree?] > > And if you said 'y' you'd get your old process tree back, everything > right where you left it. > Not that I was old enough at the time, but screen does this *grin* .. I'm sure with enough mucking bout you could get it to "time" out as such, I actually run it every time I dialup my ISP and have it do something very similar to what you described. :) Have fun, Adrian Chadd From owner-freebsd-hackers Wed Mar 19 02:01:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA14585 for hackers-outgoing; Wed, 19 Mar 1997 02:01:47 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA14576 for ; Wed, 19 Mar 1997 02:01:40 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id RAA01949; Wed, 19 Mar 1997 17:58:43 +0800 (WST) Date: Wed, 19 Mar 1997 17:58:42 +0800 (WST) From: Adrian Chadd To: Josef Karthauser cc: "Jordan K. Hubbard" , Mike Pritchard , hackers@freebsd.org Subject: Re : "screen " (was Re: dup3() - I've thought it over and decided...) In-Reply-To: <19970319093358.36887@pavilion.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 > The package 'screen' allows a similar thing. It manages virtual > shells on a terminal and allows you to detach the whole lot in one > go, and then reattach from anywhere. I used to use it at University > when terminals were hard to hold on to all day (due to student demand). > Useful for that FTP that's going to take all day. :) > Thats the exact reason why I hate giving screen access to our users :) Remember how much net traffic COSTS in Australia (I'm not going to scare you US people..) but now when people logout it kills all their processes, my excuse is that it doesn't leave the occasional ncftp or irc in a loop chewing up CPU time :) (I also like it cause it lets me "lock" my screens when I walk away from terminals for a few minutes). Adrian. From owner-freebsd-hackers Wed Mar 19 02:59:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA16192 for hackers-outgoing; Wed, 19 Mar 1997 02:59:30 -0800 (PST) Received: from lilac.csi.cam.ac.uk (exim@lilac.csi.cam.ac.uk [131.111.8.44]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA16187 for ; Wed, 19 Mar 1997 02:59:25 -0800 (PST) Received: from g.pet.cam.ac.uk [131.111.209.233] by lilac.csi.cam.ac.uk with smtp (Exim 1.58 #1) id 0w7J5A-0003cN-00; Wed, 19 Mar 1997 10:59:00 +0000 Received: from g.pet.cam.ac.uk [127.0.0.1] by g.pet.cam.ac.uk with esmtp (Exim 1.59 #1) id 0w7J5S-0006TT-00; Wed, 19 Mar 1997 10:59:18 +0000 To: John Polstra Cc: freebsd-hackers@freebsd.org Subject: Re: CVSup tags In-reply-to: Your message of "Tue, 18 Mar 1997 18:10:08 PST." <199703190210.SAA16117@austin.polstra.com> Date: Wed, 19 Mar 1997 10:59:18 +0000 From: Gareth McCaughan Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I asked: > > Is there any way of finding out a complete set of valid CVS tags > > for the CVS repository available via CVSup? John Polstra replied: > All the useful ones are documented in section 17.2.3 of the FreeBSD > Handbook. Well, yes, but there is no guarantee that the Handbook is always up to date, surely? (It still claims to document 2.1.7, for instance.) It would be good if there were some way of interrogating the server so as to find out what CVS tags make sense to it. On nasty way would be to have a collection in the main branch, containing exactly one file: a list of all "approved" tags. Then it's just necessary to remember to keep this up to date any time a new tag is added. -- Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, gjm11@dpmms.cam.ac.uk Cambridge University, England. From owner-freebsd-hackers Wed Mar 19 03:00:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA16268 for hackers-outgoing; Wed, 19 Mar 1997 03:00:45 -0800 (PST) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA16261 for ; Wed, 19 Mar 1997 03:00:42 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id VAA12308; Wed, 19 Mar 1997 21:00:30 +1000 Received: by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) id UAA22114; Wed, 19 Mar 1997 20:04:41 +1000 (EST) Date: Wed, 19 Mar 1997 20:04:41 +1000 (EST) From: Stephen McKay Message-Id: <199703191004.UAA22114@ogre.dtir.qld.gov.au> To: "Jordan K. Hubbard" cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: dup3() - I've thought it over and decided... X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: >Anyone remember a timesharing system called ITS (from MIT)? If you >got disconnected from the modem (not uncommon in those days of >Pennywhistle, 300 baud acoustically-coupled modems :-) you wouldn't >lose your session, like you do under UNIX, rather the next time you >logged in it would ask you: > >[Attach your detached tree?] > >And if you said 'y' you'd get your old process tree back, everything >right where you left it. > >Now I'm not sure if ITS accomplished this by leaving your processes >suspended and under the ownership of some foster parent for a certain >period of time, or if it genuinely saved them to disk and then >resurrected them on demand, but it sure was a bloody convenient >feature which I've always missed! :-) Look at the "screen" port. It can do this detach/reattach stuff even if you only use one screen. It uses pseudo terminals, of course. Wonderful stuff. No need for checkpointing processes. Then again, maybe we could get a good TOPS-10 emulation going. Had lots of fun in the Good Old Days(tm) of University detaching and reattaching other people. As usual, they had not the slightest comprehension of how an OS worked, so it was all Black Magic to them. :-) Stephen. From owner-freebsd-hackers Wed Mar 19 03:35:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17332 for hackers-outgoing; Wed, 19 Mar 1997 03:35:57 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17327 for ; Wed, 19 Mar 1997 03:35:55 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id DAA05572; Wed, 19 Mar 1997 03:35:39 -0800 (PST) To: Stephen McKay cc: freebsd-hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... In-reply-to: Your message of "Wed, 19 Mar 1997 20:04:41 +1000." <199703191004.UAA22114@ogre.dtir.qld.gov.au> Date: Wed, 19 Mar 1997 03:35:39 -0800 Message-ID: <5569.858771339@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Look at the "screen" port. It can do this detach/reattach stuff even if > you only use one screen. It uses pseudo terminals, of course. Wonderful > stuff. No need for checkpointing processes. Erm. I do beg to differ. Several people have pointed out various PTY-using schemes as The Answer when it's painfully clear that PTYs are a scarce and inefficient resource that don't stand a chance of scaling to the task at hand - more generalized process management. Perhaps if we had a light-weight, cloning PTY driver and the business of acquiring a new one was very fast then that would be a very different thing, but for now we have a lot of gross code in libutil which runs around trying to open everything in sight until it succeeds. :-) Besides, there are other reasons for implementing checkpointing than just this. Common scenario: You're 5 hours into a 7 hour build when the printer device wedges hard and it become clear that only a reboot will fix it. Your wife is clamoring for the printer. She needs it now? What to do? Well, if this were a more elegant system, you'd simply say "no problem, dear, let me just save my build." and you'd suspend the make, checkpoint your login shell (taking your sleeping make world with it as a child) and reboot the system. Once you're back, you invoke a new shell from the saved image and forground your make, all as it was. Of course there are certainly problems with this rosy picture. "What happens to all of the processes' external dependencies?" I hear you ask. "All the sockets it may have had open, the files half-read, the shared memory segments referenced..." Naturally, resurrection isn't going to be a pretty process. It'd be a bit like resucitating a half-drowned corpse, really - you might get the person back, but they'll never be entirely the same. If you can get it to work well in 90% of the cases it's used, however, I think it'll be useful nonetheless. This would, strangely enough, be another area where a more flexible I/O connection model would really help. If the reanimator function had a way of easily walking the list of open I/O objects the process had and invalidating the ones which were no longer viable (timed-out network objects, for example, or pointers to inode objects which have been freed/reclaimed) by simply closing them or substituting in a reference to /dev/null, that would greatly simplify things. Because you'd already have provisions for a process's I/O being abruptly redirected elsewhere (like the bit-bucket), resurrection wouldn't be such a rude shock to the process. > Then again, maybe we could get a good TOPS-10 emulation going. Had lots > of fun in the Good Old Days(tm) of University detaching and reattaching Who needs TOPS-10 emulation? Just run the genuine OS under the PDP-10 machine emulator. :-) The author was threatening to port it to something non-sparc last time I talked to him. ;) Jordan From owner-freebsd-hackers Wed Mar 19 03:59:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA18046 for hackers-outgoing; Wed, 19 Mar 1997 03:59:27 -0800 (PST) Received: from hda.hda.com (ip76-max1-fitch.ziplink.net [199.232.245.76]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA18040 for ; Wed, 19 Mar 1997 03:59:24 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id FAA23788; Wed, 19 Mar 1997 05:16:11 -0500 From: Peter Dufault Message-Id: <199703191016.FAA23788@hda.hda.com> Subject: Re: dup3() - I've thought it over and decided... In-Reply-To: <20682.858762363@time.cdrom.com> from "Jordan K. Hubbard" at "Mar 19, 97 01:06:03 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Mar 1997 05:16:10 -0500 (EST) Cc: mpp@freefall.freebsd.org, 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 > > How about going more along the checkpoint/restart route? Suspend > > the process, checkpoint it, and on restart you can reconnect stdin/out/err > > to either the current tty, or to another file. Reconnecting to > > a pipeline should also be possible. I can dig up the USENIX paper > > the Cray guys wrote on this if you like :-). > > Does the checkpoint feature allow you to complete snapshot process > state? That's another item on my wishlist. :-) > > I wouldn't mind reading that paper, if you can dig it up. If you do some searches on checkpointing you should find some on line articles about issues involved in checkpointing processes on Unix. I stumbled on them once when looking for something else and perused them a little since I had once been involved in evaluating doing that for a minisuper (didn't do any more than that though). Obviously, long running computational environments want a fairly transparent checkpoint/restart. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-hackers Wed Mar 19 05:58:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22307 for hackers-outgoing; Wed, 19 Mar 1997 05:58:01 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22301; Wed, 19 Mar 1997 05:57:58 -0800 (PST) From: Mike Pritchard Message-Id: <199703191357.FAA22301@freefall.freebsd.org> Subject: Re: dup3() - I've thought it over and decided... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Mar 1997 05:57:58 -0800 (PST) Cc: hackers@freebsd.org In-Reply-To: <20682.858762363@time.cdrom.com> from "Jordan K. Hubbard" at Mar 19, 97 01:06:03 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > How about going more along the checkpoint/restart route? Suspend > > the process, checkpoint it, and on restart you can reconnect stdin/out/err > > to either the current tty, or to another file. Reconnecting to > > a pipeline should also be possible. I can dig up the USENIX paper > > the Cray guys wrote on this if you like :-). > > Does the checkpoint feature allow you to complete snapshot process > state? That's another item on my wishlist. :-) > > I wouldn't mind reading that paper, if you can dig it up. The best I could do for now was come up with was the information available from www.usenix.org: Authors: Brent A. Kingsbury, John T. Kline, Cray Research Title: Job and process recovery in a UNIX-based operating system Winter 1989 USENIX However, while searching around, it looks like there is a POSIX draft floating around that has something to say on the matter of checkpoint/restart. As for Cray's implementation, yes, it allows you to create a complete snapshot of the process, process group, or session. At this point you could either kill the the proc/pgrp/session for later restart, or allow it to keep running and only use the snapshot in case of a system crash. I was involved in some work on this that allowed you to checkpoint the process on one machine and then restart it on another for load leveling purposes. It was used mainly for checkpoint/restart of long running batch jobs submitted via NQS, but it was usable with interactive jobs to a degree. There was on-going work for better interactive support when I left Cray (see below). > Anyone remember a timesharing system called ITS (from MIT)? If you > got disconnected from the modem (not uncommon in those days of > Pennywhistle, 300 baud acoustically-coupled modems :-) you wouldn't > lose your session, like you do under UNIX, rather the next time you > logged in it would ask you: > > [Attach your detached tree?] > > And if you said 'y' you'd get your old process tree back, everything > right where you left it. I used to use CDC's NOS that had this feature. Very useful. I think that Cray's current implementation also has this feature. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-hackers Wed Mar 19 06:48:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA23950 for hackers-outgoing; Wed, 19 Mar 1997 06:48:18 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA23942 for ; Wed, 19 Mar 1997 06:48:13 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id JAA08879 for ; Wed, 19 Mar 1997 09:51:54 -0500 (EST) Message-Id: <3.0.32.19970319094707.00b27180@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 09:47:11 -0500 To: hackers@freebsd.org From: dennis Subject: Kernel Object Dependencies Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2 years, 4 releases and kernel object dependencies still dont work! Drat. db From owner-freebsd-hackers Wed Mar 19 07:18:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA25351 for hackers-outgoing; Wed, 19 Mar 1997 07:18:20 -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 HAA25343 for ; Wed, 19 Mar 1997 07:18:17 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id BAA26085; Thu, 20 Mar 1997 01:48:10 +1030 (CST) From: Michael Smith Message-Id: <199703191518.BAA26085@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel Object Dependencies In-Reply-To: <3.0.32.19970319094707.00b27180@etinc.com> from dennis at "Mar 19, 97 09:47:11 am" To: dennis@etinc.com (dennis) Date: Thu, 20 Mar 1997 01:48:09 +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 dennis stands accused of saying: > > 2 years, 4 releases and kernel object dependencies still dont work! > Drat. Er, Dennis. While I understand your pique, this isn't very helpful. Would you prhaps care to share with us an example that would help in _fixing_ this? > db > -- ]] 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 Mar 19 07:33:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA25936 for hackers-outgoing; Wed, 19 Mar 1997 07:33:18 -0800 (PST) Received: from chess.inetspace.com (chess.inetspace.com [206.50.163.14]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA25921 for ; Wed, 19 Mar 1997 07:33:12 -0800 (PST) Received: (from kgor@localhost) by chess.inetspace.com (8.8.5/8.7.3) id JAA00323; Wed, 19 Mar 1997 09:31:49 -0600 (CST) Date: Wed, 19 Mar 1997 09:31:49 -0600 (CST) Message-Id: <199703191531.JAA00323@chess.inetspace.com> From: "Kent S. Gordon" To: jkh@time.cdrom.com CC: mpp@freefall.freebsd.org, hackers@freebsd.org In-reply-to: <20682.858762363@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: dup3() - I've thought it over and decided... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "jkh" == Jordan K Hubbard writes: > Anyone remember a timesharing system called ITS (from MIT)? If > you got disconnected from the modem (not uncommon in those days > of Pennywhistle, 300 baud acoustically-coupled modems :-) you > wouldn't lose your session, like you do under UNIX, rather the > next time you logged in it would ask you: Try using screen and you can attach back to your old session. > [Attach your detached tree?] > And if you said 'y' you'd get your old process tree back, > everything right where you left it. > Jordan -- Kent S. Gordon Senior Software Engineer INetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com From owner-freebsd-hackers Wed Mar 19 07:37:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26224 for hackers-outgoing; Wed, 19 Mar 1997 07:37:02 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26209 for ; Wed, 19 Mar 1997 07:36:49 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id KAA09139; Wed, 19 Mar 1997 10:40:31 -0500 (EST) Message-Id: <3.0.32.19970319103544.00b208b0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 10:35:48 -0500 To: Michael Smith From: dennis Subject: Re: Kernel Object Dependencies 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 01:48 AM 3/20/97 +1030, Michael Smith wrote: >dennis stands accused of saying: >> >> 2 years, 4 releases and kernel object dependencies still dont work! >> Drat. > >Er, Dennis. While I understand your pique, this isn't very helpful. >Would you prhaps care to share with us an example that would help in >_fixing_ this? Certainly. I brought this up in v1.0 and was scolded badly and told to "fix it myself".... A quick sample: in files.i386: i386/isa/filename.o optional dn device-driver in configuration file: device dn0 at isa? port 0x240 net irq 11 vector dnintr generates the following dependency in the Makefile in the build directory.... filename.o: -cp $S/i386/isa/filename.o . which should clearly be..... filename.o: $S/i386/isa/filename.o -cp $S/i386/isa/filename.o . I'd be happy to verify/test any fix, except that I dont run current and can only test on 2.2.... Dennis which of course means that updated From owner-freebsd-hackers Wed Mar 19 07:40:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26501 for hackers-outgoing; Wed, 19 Mar 1997 07:40:52 -0800 (PST) Received: from usr04.primenet.com (root@usr04.primenet.com [206.165.5.104]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26496 for ; Wed, 19 Mar 1997 07:40:47 -0800 (PST) Received: from primenet.com (root@mailhost02.primenet.com [206.165.5.53]) by usr04.primenet.com (8.8.5/8.8.5) with ESMTP id IAA08929; Wed, 19 Mar 1997 08:40:35 -0700 (MST) Received: from conceptual.com (consys.com [207.218.17.187]) by primenet.com (8.8.5/8.8.5) with ESMTP id IAA25413; Wed, 19 Mar 1997 08:40:25 -0700 (MST) Received: from conceptual.com (localhost [127.0.0.1]) by conceptual.com (8.8.5/8.6.9) with ESMTP id IAA26553; Wed, 19 Mar 1997 08:40:17 -0700 (MST) Message-Id: <199703191540.IAA26553@conceptual.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Mike Pritchard cc: jkh@time.cdrom.com (Jordan K. Hubbard), hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... In-reply-to: Your message of "Wed, 19 Mar 1997 05:57:58 PST." <199703191357.FAA22301@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Mar 1997 08:40:17 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > As for Cray's implementation, yes, it allows you to create a complete > snapshot of the process, process group, or session. At this point you > could either kill the the proc/pgrp/session for later restart, or allow > it to keep running and only use the snapshot in case of a system crash. > I was involved in some work on this that allowed you to checkpoint the > process on one machine and then restart it on another for load leveling > purposes. > > It was used mainly for checkpoint/restart of long running batch > jobs submitted via NQS, but it was usable with interactive jobs > to a degree. There was on-going work for better interactive > support when I left Cray (see below). There are some other interesting things you can do with this if you have it. Fault tolerant ORBs, for instance. If you've got a mission critical long running app with enough simplicity you can periodically checkpoint to reliable storage and restart on another compatible system with a minimum of fuss should you happen to have any of a myriad number of problems with your first platform. Deep Pockets that have things that sustain damage are funding stuff like this right now :-) I've spent part of the last month looking somewhat superficially into the issues, for SGIs there's something called Hibernator that sorta works. Cray does appear to be the current state-of-the-art. Couple checkpointing/process migration with a queuing system like Codine that understands distributed environments like ORBs, PVM, MPI, etc., and you have the potential for a pretty fault tolerant, distributed computing resource based mainly on off-the-shelf hardware. For long running apps that is, ISPs are a different problem. -- Russell L. Carter Voice:(520) 636-2600 FAX:(520) 636-2888 rcarter@consys.com Conceptual Systems & Software, P.O. Box 1129 Chino Valley AZ 86323 "Before sitting down, always look for ferrets." From owner-freebsd-hackers Wed Mar 19 07:48:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26929 for hackers-outgoing; Wed, 19 Mar 1997 07:48:05 -0800 (PST) Received: from nyx.pr.mcs.net (nyx.pr.mcs.net [204.95.55.81]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26882 for ; Wed, 19 Mar 1997 07:47:57 -0800 (PST) Received: from nyx.pr.mcs.net (localhost [127.0.0.1]) by nyx.pr.mcs.net (8.8.5/8.8.4) with ESMTP id JAA01236; Wed, 19 Mar 1997 09:47:32 -0600 (CST) Message-Id: <199703191547.JAA01236@nyx.pr.mcs.net> X-Mailer: exmh version 1.6.9 8/22/96 To: "Jordan K. Hubbard" cc: Stephen McKay , freebsd-hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... In-reply-to: Your message of Wed, 19 Mar 1997 03:35:39 -0800. <5569.858771339@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Mar 1997 09:47:31 -0600 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [snip] > >Besides, there are other reasons for implementing checkpointing than >just this. Common scenario: You're 5 hours into a 7 hour build when >the printer device wedges hard and it become clear that only a reboot >will fix it. Your wife is clamoring for the printer. She needs it >now? What to do? Well, if this were a more elegant system, you'd >simply say "no problem, dear, let me just save my build." and you'd >suspend the make, checkpoint your login shell (taking your sleeping >make world with it as a child) and reboot the system. Checkpointing would be a real plus for FreeBSD imho. With respect to cost/performance, you cant really beat PPros now, and they seem to be showing up more in scientific computing uses. Last time I checked, we were going to buy Hibernator for our Onyx, (yes, just a 1 machine license..) and it was something like $10k. This is utterly rediculous. Anyways, I think if FreeBSD had something similar, it would give us a nice edge in this type of market. --Chris Csanady > >Once you're back, you invoke a new shell from the saved image and >forground your make, all as it was. > >Of course there are certainly problems with this rosy picture. "What >happens to all of the processes' external dependencies?" I hear you >ask. "All the sockets it may have had open, the files half-read, the >shared memory segments referenced..." > >Naturally, resurrection isn't going to be a pretty process. It'd be a >bit like resucitating a half-drowned corpse, really - you might get >the person back, but they'll never be entirely the same. If you can >get it to work well in 90% of the cases it's used, however, I think >it'll be useful nonetheless. This would, strangely enough, be another >area where a more flexible I/O connection model would really help. If >the reanimator function had a way of easily walking the list of open >I/O objects the process had and invalidating the ones which were no >longer viable (timed-out network objects, for example, or pointers to >inode objects which have been freed/reclaimed) by simply closing them >or substituting in a reference to /dev/null, that would greatly >simplify things. Because you'd already have provisions for a >process's I/O being abruptly redirected elsewhere (like the >bit-bucket), resurrection wouldn't be such a rude shock to the >process. > >> Then again, maybe we could get a good TOPS-10 emulation going. Had lots >> of fun in the Good Old Days(tm) of University detaching and reattaching > >Who needs TOPS-10 emulation? Just run the genuine OS under the PDP-10 >machine emulator. :-) The author was threatening to port it to >something non-sparc last time I talked to him. ;) > > Jordan From owner-freebsd-hackers Wed Mar 19 07:56:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA27526 for hackers-outgoing; Wed, 19 Mar 1997 07:56:41 -0800 (PST) Received: from infoce-2-ll.ll4.relcom.ru (infoce-2-ll.ll4.relcom.ru [193.124.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA27347 for ; Wed, 19 Mar 1997 07:52:41 -0800 (PST) Received: from matrix.infoce-2-ll.ll4.relcom.ru by infoce-2-ll.ll4.relcom.ru with ESMTP id SAA01963; (8.6.11/vak/1.9) Wed, 19 Mar 1997 18:47:55 +0300 Message-Id: <199703191547.SAA01963@infoce-2-ll.ll4.relcom.ru> From: "Artem Koutchine" To: Subject: Cannot install.. help, please ! Date: Wed, 19 Mar 1997 22:44:51 +0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I have been trying to install FreeBSD for 2 days now and I am almost gone crazy. For now i have progressed to the moment when the installer says CANNOT LOAD THE ROOT DISTRIBUTION. PLEASE CORRECT THE PROBLEM AND TRY AGAIN. I am installing 2.1.0-R I have P5-133mhz, 16MB, TOMATO 5DHX (HX chipset) Motherboard and i have 2 hdds Western Digital 21600 (as Primary Master, DOS partition for WIndows95) Western Digital 21200 (as Secondary Master, fully for FreeBSD) Since my type of CD-ROM is not supprted i copied the first CD into the DOS partition and started install.bat from there. Since the first try i tried the following: 1. Choosing a compatible freebsd partition 2. chooing a dedicated freebsd partition 3. Changing geometry to the LBA params (as in BIOS) 4. CHanging geometry to the physical params (the real ones) 5. Coping the DIST dir into /FREEBSD/DIST 6. Coping the DIST dir from cd into /FREEBSD (withoou DIST, as the install.txt says) in any case i always chose to install BootManager (cannot work without it!) still, nothing works, it says: CANNOT LOAD THE ROOT DISTRIBUTION Please, help me! Thanx Artem Koutchine From owner-freebsd-hackers Wed Mar 19 08:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA29215 for hackers-outgoing; Wed, 19 Mar 1997 08:32:49 -0800 (PST) Received: from thelonious.spidome.net (thelonious.spidome.net [205.153.247.99]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA29208 for ; Wed, 19 Mar 1997 08:32:45 -0800 (PST) Received: (from daniel@localhost) by thelonious.spidome.net (8.8.3/8.8.3) id KAA12937 for hackers@freebsd.org; Wed, 19 Mar 1997 10:16:23 -0600 (CST) From: Dan Odom Message-Id: <199703191616.KAA12937@thelonious.spidome.net> Subject: ATAPI CD fix To: hackers@freebsd.org Date: Wed, 19 Mar 1997 10:16:22 -0600 (CST) 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 I've seen two posts in two days on this topic (to 'hackers', even), so I'll throw in my $2.00 (inflation sucks): FreeBSD 2.1.6 (and 2.1.7?) needs the IDE cd-rom to be a slave on the primary controller. It will not work if the cd-rom drive is the master on the secondary controller. Most PCs are shipped with the CD-ROM on the secondary controller, so you need to go in and switch the cables around. I learned this the hard way. Six months ago or so I was working help desk (don't groan) and one of the "known issues" that floated accross my desk was "BSD derived operating systems will not recognize the ATAPI CD-ROM in some models." I forgot about it until I tried to install BSDI 2.1 on a new server and (surprise) it didn't find the CD. I went through my filing cabinets to find the solution: "The ATAPI CD-ROM device driver that ships with many BSD distributions requires the drive to be a slave on the master controller. Switch the CD-ROM cable from the controller on the system board to the connector on the primary hard drive." This, of course, was _after_ four hours of fiddling with it. :-) This holds true for BSDI 2.1 and FreeBSD 2.1.6. FreeBSD 2.2-SNAP will work properly. Why isn't this in an FAQ somewhere? -- Daniel Odom System administrator (sometimes) and web guy (the rest of the time) daniel@thelonious.spidome.net http://www.spidome.net/daniel/ finger me for a PGP key From owner-freebsd-hackers Wed Mar 19 09:00:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA08008 for hackers-outgoing; Wed, 19 Mar 1997 09:00:21 -0800 (PST) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA07976 for ; Wed, 19 Mar 1997 09:00:17 -0800 (PST) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.6.13/8.6.9) with ESMTP id JAA10218; Wed, 19 Mar 1997 09:00:15 -0800 Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.5/8.8.5) with SMTP id JAA15707; Wed, 19 Mar 1997 09:00:13 -0800 (PST) Date: Wed, 19 Mar 1997 09:00:12 -0800 (PST) From: Chris Timmons To: Gareth McCaughan cc: freebsd-hackers@freebsd.org Subject: Re: CVSup tags 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 Bill Fenner has put together a nice WWW browsing mechanism for the CVS repository itself, if you aren't keeping one up-to-date on your local machine (CVSup is quite effective for doing that, too! Then you could have all the tags at once :) http://www.freebsd.org/cgi/cvsweb.cgi is the url. You can browse and get a sense of what tags are available by looking at one of the files in the core distribution (eg src/bin/ls/ls.c) Generally the only tags you will be interested in are the ones documented in the handbook and their logical successors. Developers from time to time will tag files belonging to a particular subsystem in order to make their work easier; you'd probably want to steer clear of these unless you know from following -current what they are for. -Chris On Wed, 19 Mar 1997, Gareth McCaughan wrote: > I asked: > > > > Is there any way of finding out a complete set of valid CVS tags > > > for the CVS repository available via CVSup? > > John Polstra replied: > > > All the useful ones are documented in section 17.2.3 of the FreeBSD > > Handbook. > > Well, yes, but there is no guarantee that the Handbook is always > up to date, surely? (It still claims to document 2.1.7, for instance.) > > It would be good if there were some way of interrogating the server > so as to find out what CVS tags make sense to it. On nasty way would > be to have a collection in the main branch, containing exactly one file: > a list of all "approved" tags. Then it's just necessary to remember > to keep this up to date any time a new tag is added. > > -- > Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, > gjm11@dpmms.cam.ac.uk Cambridge University, England. > From owner-freebsd-hackers Wed Mar 19 09:08:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA08676 for hackers-outgoing; Wed, 19 Mar 1997 09:08:52 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08668 for ; Wed, 19 Mar 1997 09:08:48 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id JAA06414; Wed, 19 Mar 1997 09:07:33 -0800 (PST) To: "Artem Koutchine" cc: hackers@freebsd.org Subject: Re: Cannot install.. help, please ! In-reply-to: Your message of "Wed, 19 Mar 1997 22:44:51 +0700." <199703191547.SAA01963@infoce-2-ll.ll4.relcom.ru> Date: Wed, 19 Mar 1997 09:07:33 -0800 Message-ID: <6410.858791253@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have been trying to install FreeBSD for 2 days now and I am almost > gone crazy. For now i have progressed to the moment when the installer says 1. Please don't send these mails to freebsd-hackers; it's the wrong list. You want to send these mails to freebsd-questions. Thanks. 2. You'll have to try a later distribution - 2.1.0 didn't support loading from DOS very well. I recommend 2.1.7. Jordan From owner-freebsd-hackers Wed Mar 19 10:09:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA11719 for hackers-outgoing; Wed, 19 Mar 1997 10:09:29 -0800 (PST) Received: from bagpuss.visint.co.uk (bagpuss.visint.co.uk [194.207.134.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA11712 for ; Wed, 19 Mar 1997 10:09:25 -0800 (PST) Received: from bagpuss.visint.co.uk (bagpuss.visint.co.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id SAA17929; Wed, 19 Mar 1997 18:09:27 GMT Date: Wed, 19 Mar 1997 18:09:27 +0000 (GMT) From: Stephen Roome To: Dan Odom cc: hackers@freebsd.org Subject: Re: ATAPI CD fix In-Reply-To: <199703191616.KAA12937@thelonious.spidome.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 Wed, 19 Mar 1997, Dan Odom wrote: > I've seen two posts in two days on this topic (to 'hackers', even), so > I'll throw in my $2.00 (inflation sucks): > > FreeBSD 2.1.6 (and 2.1.7?) needs the IDE cd-rom to be a slave on the > primary controller. It will not work if the cd-rom drive is the > master on the secondary controller. Most PCs are shipped with the > CD-ROM on the secondary controller, so you need to go in and switch > the cables around. Well, mine worked fine as the master drive on the secondary controller, and that's with a Creative Labs Hex speed drive and a Creative Labs Infra 1800 drive.. both worked fine. Steve. From owner-freebsd-hackers Wed Mar 19 11:15:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15697 for hackers-outgoing; Wed, 19 Mar 1997 11:15:02 -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 LAA15679 for ; Wed, 19 Mar 1997 11:14:57 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id MAA18297 for freebsd-hackers@freebsd.org; Wed, 19 Mar 1997 12:15:22 -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: Wed, 19 Mar 1997 11:33:34 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: 2.2 RELEASE Compile Fails on 2.2 Gamma Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Compiling 2.2-RELEASE on a 2.2 GAMA machine I am getting: ===> libc cc -O -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/2.2/src/lib/libc/locale -DYP -c /usr/src/2.2/src/lib/libc/net/ether_addr.c -o ether_addr.o In file included from /usr/src/2.2/src/lib/libc/net/ether_addr.c:49: /usr/include/net/if.h:69: field `ifi_lastchange' has incomplete type In file included from /usr/src/2.2/src/lib/libc/net/ether_addr.c:51: /usr/include/netinet/if_ether.h:90: field `ac_if' has incomplete type *** Error code 1 Stop. I am cvsup'ed as of two minutes ago. I checked out RELENG_2_2_0_RELEASE. What gives? Simon From owner-freebsd-hackers Wed Mar 19 11:15:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA15698 for hackers-outgoing; Wed, 19 Mar 1997 11:15: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 LAA15680 for ; Wed, 19 Mar 1997 11:14:57 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id MAA18294 for freebsd-hackers@freebsd.org; Wed, 19 Mar 1997 12:15:22 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD X-PRIORITY: 2 (High) Priority: urgent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Tue, 18 Mar 1997 16:07:57 -0800 (PST) Resent-Message-Id: Resent-From: Steve Tarkalson Resent-To: Simon Shapiro Date: Wed, 19 Mar 1997 12:04:14 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: FW: threads... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Y'all, As many of you knw, we are working on a large/complex project using FreeBSD. Critical part of this effort is porting a complex, high-speed database server from Slowlaris and Linux. It is a multi-threaded application. Following are comments by Steve, our lead developer of the server. He is highly qualified but FreeBSD is new to him. The server works flawlessly on Solaris, using posix Threads and works properly on Linux (againm using Posix threads). Any help will be appreciated. We will even pay for consulting work if necessary. Simon ----- Forwarded Message ----: ----- From: Steve Tarkalson To: Simon Shapiro Subject: threads... Simon, here is a summary of the current problems I am having with threads on FreeBSD: - there is name space collisions between libc and libc_r. supposedly libc_r is a full blown replacement for libc (?). if you link with libc_r, libc gets linked as well. since ld assumes startup files (crt0.o and std lib c). order is important to solve some name space problems but this causes other non-fatal problems - like an empty stub for _thread_init() - threads initialization doesn't occurr (_thread_init). there doesn't seem to be an entry on the Construct list for this guy in libc_r. even though I have explicitly called this routine in the application things still don't seem to be setup correctly. Some other missing component ???? - threads seem to get created but their start proc never gets executed - scheduling... - signals aren't reliable Of course the later two problems could hinge on the first. -Steve ---------------------------------- E-Mail: Steve Tarkalson Date: 03/18/97 Time: 16:07:57 This message was sent by XF-Mail ---------------------------------- -------------End of forwarding message------------------------- From owner-freebsd-hackers Wed Mar 19 11:46:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA17282 for hackers-outgoing; Wed, 19 Mar 1997 11:46:17 -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 LAA17269 for ; Wed, 19 Mar 1997 11:46:14 -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 LAA15265 for ; Wed, 19 Mar 1997 11:48:06 -0800 (PST) Received: (qmail 6456 invoked by uid 110); 19 Mar 1997 10:08:35 -0000 Message-ID: <19970319100834.6455.qmail@suburbia.net> Subject: screen (was dup3() - ...) In-Reply-To: from Adrian Chadd at "Mar 19, 97 05:36:02 pm" To: adrian@obiwan.aceonline.com.au (Adrian Chadd) Date: Wed, 19 Mar 1997 21:08:34 +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 > > And if you said 'y' you'd get your old process tree back, everything > > right where you left it. > > > > Not that I was old enough at the time, but screen does this *grin* .. I'm > sure with enough mucking bout you could get it to "time" out as such, I > actually run it every time I dialup my ISP and have it do something very > similar to what you described. :) > > Have fun, > > Adrian Chadd screen -h2000, a 21" grey-scale monitor and a 170x60 (8x16 font) text console, is a fantastic programing enviroment. Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows. More recent versions of screen support file-style access permisions per-screen for multiple-user attaches. --> /usr/ports/misc/screen -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |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 Wed Mar 19 12:00:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18466 for hackers-outgoing; Wed, 19 Mar 1997 12:00:25 -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 MAA18444 for ; Wed, 19 Mar 1997 12:00:19 -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 MAA16745 for ; Wed, 19 Mar 1997 12:02:06 -0800 (PST) Received: (qmail 21057 invoked by uid 110); 19 Mar 1997 09:41:31 -0000 Message-ID: <19970319094131.21053.qmail@suburbia.net> Subject: Re: dup3() - I've thought it over and decided... In-Reply-To: <20682.858762363@time.cdrom.com> from "Jordan K. Hubbard" at "Mar 19, 97 01:06:03 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Mar 1997 20:41:31 +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 > Now I'm not sure if ITS accomplished this by leaving your processes > suspended and under the ownership of some foster parent for a certain > period of time, or if it genuinely saved them to disk and then > resurrected them on demand, but it sure was a bloody convenient > feature which I've always missed! :-) > > Jordan Ever heard of screen(1)? -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |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 Wed Mar 19 12:35:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20280 for hackers-outgoing; Wed, 19 Mar 1997 12:35:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20272 for ; Wed, 19 Mar 1997 12:35:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA12337; Wed, 19 Mar 1997 13:23:59 -0700 From: Terry Lambert Message-Id: <199703192023.NAA12337@phaeton.artisoft.com> Subject: Re: Donation please ... To: RGireyev@bellind.com Date: Wed, 19 Mar 1997 13:23:59 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: from "RGireyev@bellind.com" at Mar 18, 97 01:23:38 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 > Thank you for replying Terry. I think you may have missed > a sentence in my original posting. I am having trouble > getting into the FTP site that has the sources. I'm sorry > to trouble the list with something so stupid. Well, if it's a port, it's probably not on the CDROM. If it is, it will be on the Walnut Creek Site. If not, you will have to wait until you *can* get through, since if the site is down, it's down for us too. [ ... BEGIN TRIVIA ... ] > P.S. Is tha penguin small and qute? > What's her name? > Oh wait...,,, oops sorry! Improper topic. The "Penguin" response is a satire on a Bugs Bunny cartoon which was a satire on a Humphrey Bogart movie. Throughout the cartoon (in which Bugs Bunny is trying to get a Penguin "home"), Bogart is interrupting with a line from one of his movies (which one is left as an exercise for the student): Humphrey Bogart: "Pardon me, but could you help a fellow American who's down on his luck" Bugs Bunny is always giving him coins, even on the ice pack, where he can't possibly have coins left. Finally, after an arduous journey to the South Pole, the Penguin reveals that "Home" is an ice show in Hoboken, New Jersey. Bugs is distraught: Bugs: "Hoboken!!! I'm *dyyyyyin'!!!" Bogart appears, and asks the question, and Bugs repeats it to him and hands him the Penguin, running off into the distance. [ ... END TRIVIA ... ] 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 Mar 19 12:41:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20709 for hackers-outgoing; Wed, 19 Mar 1997 12:41:17 -0800 (PST) Received: from cedb.dpcsys.com (cedb.DPCSYS.com [209.25.4.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20699 for ; Wed, 19 Mar 1997 12:41:12 -0800 (PST) Received: from localhost (dan@localhost) by cedb.dpcsys.com (8.8.5/8.8.2) with SMTP id UAA24369 for ; Wed, 19 Mar 1997 20:41:00 GMT Date: Wed, 19 Mar 1997 12:41:00 -0800 (PST) From: Dan Busarow To: hackers@freebsd.org Subject: minor bug in 2.2 sysinstall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hope this isn't too late. I just finished an UPDATE install from 2.1-R to 2.2-R In the selection for distribution type when I selected Kernel Developer I ended up with both Kernel Developer and Average User selected. Couldn't deselect Average User. I decided to let it go figuring the worst that would happen would be two installs but it seemed to work fine so it's not a big problem. Dan -- Dan Busarow 714 443 4172 DPC Systems / Beach.Net dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 From owner-freebsd-hackers Wed Mar 19 12:47:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21115 for hackers-outgoing; Wed, 19 Mar 1997 12:47:53 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21101 for ; Wed, 19 Mar 1997 12:47:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA12366; Wed, 19 Mar 1997 13:35:43 -0700 From: Terry Lambert Message-Id: <199703192035.NAA12366@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 19 Mar 1997 13:35:42 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703190049.LAA20233@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 19, 97 11:19:47 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 > There are? We haven't yet established where "the front of the disk" > is yet. It's not safe (or reliable) to try to rewrite the MBR (virus > protection), or the slack space following (some other systems put > bootstraps there). Then the next cylinder might be a partition. Override the virus protection. > DOS can be booted from lots of places; think "network boot", or "floppy disk". > So can FreeBSD; there is no guarantee there at all. In any case, the boot device is known. > > it means no recompilation to support config options, as long as we > > get rid of the static compilation issues in shared code (#if FEATURE > 1) > > and so on. > > This is actually a huge issue; the assumption that devices are > numbered from 0->(NFOO-1) is another wart that I would like to rip. Yes. This should go. So should all configuration options that cause conditional compilation of code rather than conditional inclusion of objects in the link which extend a global linker set. If you get rid of conditional compilation, and leave only conditional inclusion, then you remove the need for recompile on conditional changes, and it becomes a binary/linker issue *only*. This is a *good* thing. > Of those, remembering that this is a program's text file, I can only > see 1) and 3) being any use, ie. the 'readable' bit is pointless. That's the bit. I won't argue utility of microsoft definitions, since I'm not willing to play Devil's advocate for their engineering process, such as it is. > > Yes. The utility of the attributes at boot time is to decide to > > load a particular segment or not. Preload is the most interesting > > attribute in this regard; it should probably be implied on non-pageable > > segments. > > Hmm. The nature of the boot-time linking process would probably imply > that all of the objects in question would have to be loaded, as there > would be no paging mechanism by which unloaded sections could be > loaded until after the system was up, and possibly not even then > (eg. boot from network server, no kernel core locally). They *could* be sparsely loaded. You do not need paged memory management to support partial loading (look at Win3.1 DLL's). > Yeah. And don't get me started on getting technical literature out of > hardware vendors. You have any details on the "Apollo Utility chip" in > the HP9000/4xx machines? 8) No, and I own one of the suckers (yeah, I've seen you on the NetBSD list for the HP300 code). 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 Mar 19 13:00:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21738 for hackers-outgoing; Wed, 19 Mar 1997 13:00:14 -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 NAA21728 for ; Wed, 19 Mar 1997 13:00:04 -0800 (PST) Received: (qmail 13234 invoked by uid 5); 19 Mar 1997 20:59:58 -0000 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id HAA07624; Thu, 20 Mar 1997 07:44:52 +1100 (EST) From: John Birrell Message-Id: <199703192044.HAA07624@freebsd1.cimlogic.com.au> Subject: Re: FW: threads... To: Shimon@i-Connect.Net (Simon Shapiro) Date: Thu, 20 Mar 1997 07:44:51 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from Simon Shapiro at "Mar 19, 97 12:04:14 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 Simon Shapiro wrote: > - there is name space collisions between libc and libc_r. > supposedly libc_r is a full blown replacement for libc (?). > if you link with libc_r, libc gets linked as well. since > ld assumes startup files (crt0.o and std lib c). order is > important to solve some name space problems but this causes > other non-fatal problems - like an empty stub for > _thread_init() Use libc_r _instead_ of libc. libc_r is a super-set of libc, so the name space collisions are not surprising -- they're intended! You can avoid gcc telling ld to link lib by using -nostdlib. > > - threads initialization doesn't occurr (_thread_init). there > doesn't seem to be an entry on the Construct list for this > guy in libc_r. even though I have explicitly called this > routine in the application things still don't seem to be > setup correctly. Some other missing component ???? If you link correctly, this should not be a problem. > > - threads seem to get created but their start proc never > gets executed - scheduling... > > - signals aren't reliable > > Of course the later two problems could hinge on the first. Probably. If the correct linking doesn't solve your problems, ask your developer to email me. Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Wed Mar 19 13:31:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA23820 for hackers-outgoing; Wed, 19 Mar 1997 13:31:50 -0800 (PST) Received: from squirrel.tgsoft.com (squirrel.tgsoft.com [207.167.64.183]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23815 for ; Wed, 19 Mar 1997 13:31:46 -0800 (PST) Received: (from thompson@localhost) by squirrel.tgsoft.com (8.8.5/8.6.12) id NAA10994; Wed, 19 Mar 1997 13:31:12 -0800 (PST) Date: Wed, 19 Mar 1997 13:31:12 -0800 (PST) Message-Id: <199703192131.NAA10994@squirrel.tgsoft.com> From: mark thompson To: hackers@freebsd.com Subject: 2.2 release (has anyone seen?) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk i built 2.2 release from a recent cvsup. The kernel runs ok, but when i halt it it gets a kernel page trap, after syncing the disks, but before marking them clean. If nobody else has seen this, i will mess with it long enuf to get a traceback. -mark From owner-freebsd-hackers Wed Mar 19 13:35:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04549 for hackers-outgoing; Wed, 19 Mar 1997 13:35:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04447 for ; Wed, 19 Mar 1997 13:35:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA12436; Wed, 19 Mar 1997 14:21:58 -0700 From: Terry Lambert Message-Id: <199703192121.OAA12436@phaeton.artisoft.com> Subject: Re: dup3() - I've thought it over and decided... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Mar 1997 14:21:58 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <20163.858754119@time.cdrom.com> from "Jordan K. Hubbard" at Mar 18, 97 10:48:39 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's a hack. Forget about it. :-) > > That said, I think that there's a need for a more generalized I/O > model which allows this kind of in-flight disconnection and > reconnection of I/O handles a process might have open, but it needs to > be a lot more involved than just thwapping over somebody's file > handles. :-) There needs to be some mechanism for flushing or > discarding pending I/O on reconnect, for one thing, and it needs to > play friendly with stdio. > > I'll think about the problem some more.. :) Gee, too bad descriptors aren't implemented using process logical names that you can modify from other processes... 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 Mar 19 14:01:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA18624 for hackers-outgoing; Wed, 19 Mar 1997 14:01:58 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA18610 for ; Wed, 19 Mar 1997 14:01:55 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA08169; Wed, 19 Mar 1997 14:01:50 -0800 (PST) To: Dan Busarow cc: hackers@freebsd.org Subject: Re: minor bug in 2.2 sysinstall In-reply-to: Your message of "Wed, 19 Mar 1997 12:41:00 PST." Date: Wed, 19 Mar 1997 14:01:50 -0800 Message-ID: <8164.858808910@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In the selection for distribution type when I selected Kernel Developer > I ended up with both Kernel Developer and Average User selected. > Couldn't deselect Average User. Actually, I just changed the way the display works - not to worry! :) Jordan From owner-freebsd-hackers Wed Mar 19 14:07:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA25685 for hackers-outgoing; Wed, 19 Mar 1997 14:07:43 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA25678 for ; Wed, 19 Mar 1997 14:07:39 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA08209 for ; Wed, 19 Mar 1997 14:07:40 -0800 (PST) To: hackers@freebsd.org Subject: MSWord docs... Date: Wed, 19 Mar 1997 14:07:40 -0800 Message-ID: <8205.858809260@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What's the latest technology on previewing MSword stuff under FreeBSD? I haven't been keeping up, I'm afraid... I know we can currently handle postscript, pdf and acrobat, but word? Thanks. Jordan P.S. And no, I don't have a copy of Word for 3.1, so please don't even suggest WINE. :-) From owner-freebsd-hackers Wed Mar 19 14:26:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA26692 for hackers-outgoing; Wed, 19 Mar 1997 14:26:49 -0800 (PST) Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA26675 for ; Wed, 19 Mar 1997 14:26:40 -0800 (PST) From: sthaug@nethelp.no Received: (qmail 19132 invoked by uid 1001); 19 Mar 1997 22:26:08 +0000 (GMT) To: hackers@freebsd.org Subject: Anybody using Tyan S1672 (Tacoma) motherboard with parity RAM? X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 19 Mar 1997 23:26:08 +0100 Message-ID: <19130.858810368@verdi.nethelp.no> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anybody using the Tyan S1672 (Tacoma) motherboard with parity RAM with FreeBSD? We have a couple of these here, and they work fine as long as we only configure normal parity checking in the BIOS. As soon as we turn on ECC, we start getting mysterious crashes etc. We'd like to hear about other experiences with this board. Thanks in advance! Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Wed Mar 19 15:09:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA29472 for hackers-outgoing; Wed, 19 Mar 1997 15:09:51 -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 PAA29466 for ; Wed, 19 Mar 1997 15:09:48 -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 RAA26548; Wed, 19 Mar 1997 17:15:34 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id XAA00243; Wed, 19 Mar 1997 23:10:30 GMT Message-ID: <19970319171029.18226@right.PCS> Date: Wed, 19 Mar 1997 17:10:29 -0600 From: Jonathan Lemon To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <8205.858809260@time.cdrom.com>; from Jordan K. Hubbard on Mar 03, 1997 at 02:07:40PM -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mar 03, 1997 at 02:07:40PM -0800, Jordan K. Hubbard wrote: > What's the latest technology on previewing MSword stuff under FreeBSD? > I haven't been keeping up, I'm afraid... I know we can currently handle > postscript, pdf and acrobat, but word? Thanks. > > Jordan > > P.S. And no, I don't have a copy of Word for 3.1, so please don't > even suggest WINE. :-) Actually, I think that MS gives out a free MS-Word viewer that runs under WINE. -- Jonathan From owner-freebsd-hackers Wed Mar 19 15:27:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00818 for hackers-outgoing; Wed, 19 Mar 1997 15:27:36 -0800 (PST) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00812 for ; Wed, 19 Mar 1997 15:27:33 -0800 (PST) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA20937; Wed, 19 Mar 1997 15:26:29 -0800 (PST) Date: Wed, 19 Mar 1997 15:26:27 -0800 (PST) From: John Utz To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: MSWord docs... In-Reply-To: <8205.858809260@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 Hah! if u find one, let *all* of us know! I seem to recall a post in one of the groups i read about the fact that some guy in germany hacked the file format, and then removed it from his website "by request of microsoft". if somebody could do a viewer, then somebody could do a word clone! On Wed, 19 Mar 1997, Jordan K. Hubbard wrote: > What's the latest technology on previewing MSword stuff under FreeBSD? > I haven't been keeping up, I'm afraid... I know we can currently handle > postscript, pdf and acrobat, but word? Thanks. > > Jordan > > P.S. And no, I don't have a copy of Word for 3.1, so please don't > even suggest WINE. :-) > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-hackers Wed Mar 19 15:32:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01319 for hackers-outgoing; Wed, 19 Mar 1997 15:32:47 -0800 (PST) Received: from uucp.DK.net (uucp.DK.net [193.88.44.47]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA01312 for ; Wed, 19 Mar 1997 15:32:24 -0800 (PST) Received: from pingnet (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id AAA02215; Thu, 20 Mar 1997 00:30:18 +0100 Received: from kyklopen by ic1.ic.dk with UUCP id AA20297 (5.65c8/IDA-1.4.4j); Thu, 20 Mar 1997 00:16:49 +0100 Received: (from staff@localhost) by kyklopen.ping.dk (8.8.5/8.8.4) id XAA02244; Wed, 19 Mar 1997 23:42:57 +0100 (MET) Date: Wed, 19 Mar 1997 23:42:57 +0100 (MET) From: Thomas Sparrevohn To: John Birrell Cc: Simon Shapiro , freebsd-hackers@freebsd.org Subject: Re: FW: threads... In-Reply-To: <199703192044.HAA07624@freebsd1.cimlogic.com.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 20 Mar 1997, John Birrell wrote: > Simon Shapiro wrote: > > - there is name space collisions between libc and libc_r. > > supposedly libc_r is a full blown replacement for libc (?). > > if you link with libc_r, libc gets linked as well. since > > ld assumes startup files (crt0.o and std lib c). order is > > important to solve some name space problems but this causes > > other non-fatal problems - like an empty stub for > > _thread_init() > > Use libc_r _instead_ of libc. libc_r is a super-set of libc, so the > name space collisions are not surprising -- they're intended! > Sorry but could'nt we just append a flag to gcc, say -pthread and let gcc handle the library shift etc. Its actually quite easy. -- Thomas From owner-freebsd-hackers Wed Mar 19 15:44:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01983 for hackers-outgoing; Wed, 19 Mar 1997 15:44:21 -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 PAA01976 for ; Wed, 19 Mar 1997 15:44:16 -0800 (PST) Received: (qmail 1896 invoked by uid 5); 19 Mar 1997 23:44:07 -0000 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id KAA08218; Thu, 20 Mar 1997 10:43:46 +1100 (EST) From: John Birrell Message-Id: <199703192343.KAA08218@freebsd1.cimlogic.com.au> Subject: Re: FW: threads... To: staff@kyklopen.ping.dk (Thomas Sparrevohn) Date: Thu, 20 Mar 1997 10:43:45 +1100 (EST) Cc: jb@cimlogic.com.au, Shimon@i-Connect.Net, freebsd-hackers@freebsd.org In-Reply-To: from Thomas Sparrevohn at "Mar 19, 97 11:42:57 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 Thomas Sparrevohn wrote: > Sorry but could'nt we just append a flag to gcc, say -pthread and let > gcc handle the library shift etc. Its actually quite easy. I have asked if that would be OK and I think I got the go-ahead -- nobody objected. This patch to src/contrib/gcc/config/i386/freebsd.h should do the trick: 90c90 < #define LIB_SPEC "%{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}" --- > #define LIB_SPEC "%{!p:%{!pg:%{!pthread:-lc}%{pthread:-lc_r}}}%{p:%{!pthread:-lc_p}%{pthread:-lc_r_p}}%{pg:%{!pthread:-lc_p}%{pthread:-lc_r_p}}" I've been holding this until I got a few other patches before it would be worth bothering someone to commit it (since I can't 8-(). > > -- Thomas Regards -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Wed Mar 19 15:55:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02512 for hackers-outgoing; Wed, 19 Mar 1997 15:55:44 -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 PAA02498 for ; Wed, 19 Mar 1997 15:55:25 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA28993; Thu, 20 Mar 1997 10:24:27 +1030 (CST) From: Michael Smith Message-Id: <199703192354.KAA28993@genesis.atrad.adelaide.edu.au> Subject: Re: Anybody using Tyan S1672 (Tacoma) motherboard with parity RAM? In-Reply-To: <19130.858810368@verdi.nethelp.no> from "sthaug@nethelp.no" at "Mar 19, 97 11:26:08 pm" To: sthaug@nethelp.no Date: Thu, 20 Mar 1997 10:24:26 +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 sthaug@nethelp.no stands accused of saying: > Is anybody using the Tyan S1672 (Tacoma) motherboard with parity RAM > with FreeBSD? No, but I've seen some oddities with another HX board. > We have a couple of these here, and they work fine as long as we only > configure normal parity checking in the BIOS. As soon as we turn on > ECC, we start getting mysterious crashes etc. We'd like to hear about > other experiences with this board. Thanks in advance! With the Tekram P5H30 board, using an Award BIOS, there are several different parity/ECC settings. At least one of these results in the board bombing out with an ECC error long before anything resembling an OS is loaded. > Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- ]] 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 Mar 19 15:57:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA02681 for hackers-outgoing; Wed, 19 Mar 1997 15:57:46 -0800 (PST) Received: from ceniai.inf.cu ([169.158.128.138]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA02674 for ; Wed, 19 Mar 1997 15:57:38 -0800 (PST) Received: from cujae.UUCP by ceniai.inf.cu with UUCP (Smail3.1.29.1) id m0w7QZb-0002BkC; Wed, 19 Mar 97 18:58 Received: from crepiai.ispjae.edu.cu by cujae.ispjae.edu.cu with SMTP (5.65/25) id AA00296; Wed, 19 Mar 97 17:49:55 -0500 Received: from ceis.ispjae.edu.cu ([169.158.141.40]) by crepiai.ispjae.edu.cu with SMTP id AA00895 (5.67b/IDA-1.5 for ); Wed, 19 Mar 1997 18:22:36 -0500 Received: from CEIS/SpoolDir by ceis.ispjae.edu.cu (Mercury 1.21); 19 Mar 97 18:25:17 UTC-5 Received: from SpoolDir by CEIS (Mercury 1.30); 19 Mar 97 12:18:41 UTC-5 From: "Dr.C Miguel Garay Garcell / Profesor Titular" Organization: CEIS / ISPJAE To: hackers@freebsd.org Date: Wed, 19 Mar 1997 12:17:38 GMT-0500 Subject: (Fwd) X11 under 2.2-RELEASE? Priority: normal X-Mailer: Pegasus Mail for Windows (v2.21) Message-Id: <319C4D43A1@ceis.ispjae.edu.cu> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- Forwarded Message Follows ------- From: tenser@spitfire.ecsel.psu.edu Date: 19 Mar 1997 03:04:37 -0000 To: hackers@freebsd.org Subject: X11 under 2.2-RELEASE? Hmm, is it just me, or are the versions of xterm and xdm shipped with 2.2-RELEASE still slightly skewed with respect to utmp? : krusty 6; w 10:04PM up 2:48, 3 users, load averages: 0.00, 0.08, 0.33 USER TTY FROM LOGIN@ IDLE WHAT tad v0 - 7:16PM 2:47 xinit -- tenser p1 spitfire.ecsel.p 10:02PM - w ttyp0 tad 13Aug95 2:47 - : krusty 7; I don't think that ttyp0 is a valid user. :-) Then again, this could be a different bug just now rearing it's ugly head, or krusty might be slightly messed up. If I'm missing something obvious here, please throw a slap upside the grape my way. :-) - Dan C. From owner-freebsd-hackers Wed Mar 19 16:04:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA03231 for hackers-outgoing; Wed, 19 Mar 1997 16:04:25 -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 QAA03222 for ; Wed, 19 Mar 1997 16:04:13 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA29076; Thu, 20 Mar 1997 10:33:34 +1030 (CST) From: Michael Smith Message-Id: <199703200003.KAA29076@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel Object Dependencies In-Reply-To: <3.0.32.19970319103544.00b208b0@etinc.com> from dennis at "Mar 19, 97 10:35:48 am" To: dennis@etinc.com (dennis) Date: Thu, 20 Mar 1997 10:33: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 dennis stands accused of saying: > > > >Er, Dennis. While I understand your pique, this isn't very helpful. > >Would you prhaps care to share with us an example that would help in > >_fixing_ this? ... > in files.i386: > > i386/isa/filename.o optional dn device-driver > > in configuration file: > > device dn0 at isa? port 0x240 net irq 11 vector dnintr > > generates the following dependency in the Makefile in the build directory.... > > filename.o: > -cp $S/i386/isa/filename.o . > > which should clearly be..... > > filename.o: $S/i386/isa/filename.o > -cp $S/i386/isa/filename.o . Er, no it doesn't. To wit : files.i386: i386/isa/mdsio.c optional mdsio device-driver kernel config: device mdsio0 at isa? port "IO_COM3" tty irq 10 vector mdsiointr Makefile: mdsio.o: $S/i386/isa/mdsio.c ${DRIVER_C} This is on a 2.2 system. I have been taking advantage of the fact that these dependancies _do_ work (and the opt_foo.h stuff too) to simplify maintaining a number of kernels in parallel. Are you doing 'make depend' after you config your kernel? It _is_ necessary in order to generate the dependancies. Sorry about not replying last night; I ran out of typing juice 8( > Dennis -- ]] 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 Mar 19 16:05:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA03323 for hackers-outgoing; Wed, 19 Mar 1997 16:05:53 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA03316 for ; Wed, 19 Mar 1997 16:05:48 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA11834 for ; Wed, 19 Mar 1997 19:09:42 -0500 (EST) Message-Id: <3.0.32.19970319190454.00b222d0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 19:04:57 -0500 To: hackers@freebsd.org From: dennis Subject: insight on malloc crash... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can anyone give some insight on why the following code might panic v2.2 (while it has been working happily since 1.x) p=malloc(size,M_DEVBUF,M_WAITOK); if (p) bzero(p,size) bzero is panicing....did something change? this stuff isnt very well document :/ Dennis From owner-freebsd-hackers Wed Mar 19 16:09:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA03544 for hackers-outgoing; Wed, 19 Mar 1997 16:09:38 -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 QAA03529 for ; Wed, 19 Mar 1997 16:09:08 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA29110; Thu, 20 Mar 1997 10:36:44 +1030 (CST) From: Michael Smith Message-Id: <199703200006.KAA29110@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703192035.NAA12366@phaeton.artisoft.com> from Terry Lambert at "Mar 19, 97 01:35:42 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 20 Mar 1997 10:36:43 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De 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: > > Yes. This should go. So should all configuration options that > cause conditional compilation of code rather than conditional > inclusion of objects in the link which extend a global linker set. That's a lot harder. I would say "some" rather than "all". > If you get rid of conditional compilation, and leave only conditional > inclusion, then you remove the need for recompile on conditional > changes, and it becomes a binary/linker issue *only*. This is a *good* > thing. Be wary of increasing the linkage overhead too much 8) > > Hmm. The nature of the boot-time linking process would probably imply > > that all of the objects in question would have to be loaded, as there > > would be no paging mechanism by which unloaded sections could be > > loaded until after the system was up, and possibly not even then > > (eg. boot from network server, no kernel core locally). > > They *could* be sparsely loaded. You do not need paged memory > management to support partial loading (look at Win3.1 DLL's). Understood; the point merely being that much of the kernel may be required _before_ there is any method available again to load the bits that were left out. A standalone boot-time linker and associated media drivers are going to be long gone before the kernel is in a position to talk to the media again. > 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 Mar 19 16:11:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA03723 for hackers-outgoing; Wed, 19 Mar 1997 16:11:49 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA03713 for ; Wed, 19 Mar 1997 16:11:44 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id TAA11869; Wed, 19 Mar 1997 19:15:24 -0500 (EST) Message-Id: <3.0.32.19970319191037.00b2d900@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Mar 1997 19:10:39 -0500 To: Michael Smith From: dennis Subject: Re: Kernel Object Dependencies Cc: msmith@atrad.adelaide.edu.au, 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 10:33 AM 3/20/97 +1030, Michael Smith wrote: >dennis stands accused of saying: >> > >> >Er, Dennis. While I understand your pique, this isn't very helpful. >> >Would you prhaps care to share with us an example that would help in >> >_fixing_ this? >... >> in files.i386: >> >> i386/isa/filename.o optional dn device-driver >> >> in configuration file: >> >> device dn0 at isa? port 0x240 net irq 11 vector dnintr >> >> generates the following dependency in the Makefile in the build directory.... >> >> filename.o: >> -cp $S/i386/isa/filename.o . >> >> which should clearly be..... >> >> filename.o: $S/i386/isa/filename.o >> -cp $S/i386/isa/filename.o . > > >Er, no it doesn't. To wit : > > files.i386: > >i386/isa/mdsio.c optional mdsio device-driver > > kernel config: > >device mdsio0 at isa? port "IO_COM3" tty irq 10 vector mdsiointr > > Makefile: > >mdsio.o: $S/i386/isa/mdsio.c > ${DRIVER_C} > >This is on a 2.2 system. I have been taking advantage of the fact that >these dependancies _do_ work (and the opt_foo.h stuff too) to simplify >maintaining a number of kernels in parallel. > >Are you doing 'make depend' after you config your kernel? It _is_ >necessary in order to generate the dependancies. Sorry about not >replying last night; I ran out of typing juice 8( the example you gave is a source/object dependecy, which works. I believe that config somehow generates the dependency in the Makefile, and that has to come from the files.i386 declaration.What I'm saying is that it doesn't generate the correct Makefile entry when the file is an object module. Dennis From owner-freebsd-hackers Wed Mar 19 16:14:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA03894 for hackers-outgoing; Wed, 19 Mar 1997 16:14:20 -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 QAA03878 for ; Wed, 19 Mar 1997 16:13:53 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA29036; Thu, 20 Mar 1997 10:27:29 +1030 (CST) From: Michael Smith Message-Id: <199703192357.KAA29036@genesis.atrad.adelaide.edu.au> Subject: Re: MSWord docs... In-Reply-To: <8205.858809260@time.cdrom.com> from "Jordan K. Hubbard" at "Mar 19, 97 02:07:40 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 20 Mar 1997 10:27:28 +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: > What's the latest technology on previewing MSword stuff under FreeBSD? > I haven't been keeping up, I'm afraid... I know we can currently handle > postscript, pdf and acrobat, but word? Thanks. If it wasn't for the fact that it expires in 11 days, I would be suggesting you grab the StarOffice suite (for Linux). I have the second-generation installer just about ready to go (I need net access to a Linux machine with it installed to finalise some stuff thought), but as the current beta expires so soon, I'm waiting to see whether there's another beta coming or a 'full release'. The wordprocess from StarOffice is an excellent Word clone, and reads and writes Word documents quite well, modulo the odd font translation problem. > P.S. And no, I don't have a copy of Word for 3.1, so please don't > even suggest WINE. :-) If previewing is all you need, get the MS Word Reader and run it under Wine. It's a freebie from MS. -- ]] 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 Mar 19 16:59:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07396 for hackers-outgoing; Wed, 19 Mar 1997 16:59:32 -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 QAA07388 for ; Wed, 19 Mar 1997 16:59:24 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA29544; Thu, 20 Mar 1997 11:29:02 +1030 (CST) From: Michael Smith Message-Id: <199703200059.LAA29544@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel Object Dependencies In-Reply-To: <3.0.32.19970319191037.00b2d900@etinc.com> from dennis at "Mar 19, 97 07:10:39 pm" To: dennis@etinc.com (dennis) Date: Thu, 20 Mar 1997 11:29:01 +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 dennis stands accused of saying: > >> in files.i386: > >> > >> i386/isa/filename.o optional dn device-driver ^^ I missed that, sorry. > >> which should clearly be..... > >> > >> filename.o: $S/i386/isa/filename.o > >> -cp $S/i386/isa/filename.o . Gotcha. Should it be 'cp' or 'ln -sf' do you think? A symlink will give you the dependancy behaviour automatically as the kernel dependancy rule will include the driver, and you save space too. > the example you gave is a source/object dependecy, which works. > I believe that config somehow generates the dependency in the > Makefile, and that has to come from the files.i386 declaration.What > I'm saying is that it doesn't generate the correct Makefile entry > when the file is an object module. Here's a patch for /usr/src/usr.sbin/config/mkmakefile.c that will emit the dependancy as you've described; please let me know if it works for you (beware snarf-n-barf damage) : --- /local1/playpen/2.2/src/usr.sbin/config/mkmakefile.c Tue Dec 17 16:17:47 1996 +++ mkmakefile.c Thu Mar 20 11:26:11 1997 @@ -675,7 +675,7 @@ else { *cp = '\0'; if (och == 'o') { - fprintf(f, "%so:\n\t-cp $S/%so .\n\n", + fprintf(f, "%so: $S/%so\n\t-cp $S/%so .\n\n", tail(np), np); continue; } > Dennis -- ]] 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 Mar 19 17:03:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA07652 for hackers-outgoing; Wed, 19 Mar 1997 17:03:12 -0800 (PST) Received: from jedi.asc-net.com ([204.254.69.20]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA07642 for ; Wed, 19 Mar 1997 17:03:07 -0800 (PST) Received: from localhost (marty@localhost) by jedi.asc-net.com (8.8.5/8.8.5) with SMTP id RAA00533; Wed, 19 Mar 1997 17:06:57 -0800 (PST) Date: Wed, 19 Mar 1997 17:06:56 -0800 (PST) From: Marty Bower To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: MSWord docs... In-Reply-To: <8205.858809260@time.cdrom.com> Message-ID: X-mailer: Pine 3.95q (FreeBSD 2.2) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Save as HTML" in Word? MjB On Wed, 19 Mar 1997, Jordan K. Hubbard wrote: > What's the latest technology on previewing MSword stuff under FreeBSD? > I haven't been keeping up, I'm afraid... I know we can currently handle > postscript, pdf and acrobat, but word? Thanks. > > Jordan > > P.S. And no, I don't have a copy of Word for 3.1, so please don't > even suggest WINE. :-) > From owner-freebsd-hackers Wed Mar 19 17:49:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA12291 for hackers-outgoing; Wed, 19 Mar 1997 17:49:35 -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 RAA12283 for ; Wed, 19 Mar 1997 17:49:32 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id SAA00999; Wed, 19 Mar 1997 18:46:35 -0700 (MST) Date: Wed, 19 Mar 1997 18:46:35 -0700 (MST) Message-Id: <199703200146.SAA00999@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: msmith@atrad.adelaide.edu.au (Michael Smith), hackers@freebsd.org Subject: Re: wd driver questions In-Reply-To: <199703192035.NAA12366@phaeton.artisoft.com> References: <199703190049.LAA20233@genesis.atrad.adelaide.edu.au> <199703192035.NAA12366@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > There are? We haven't yet established where "the front of the disk" > > is yet. It's not safe (or reliable) to try to rewrite the MBR (virus > > protection), or the slack space following (some other systems put > > bootstraps there). Then the next cylinder might be a partition. > > Override the virus protection. It's not possible to do inside the install program. Nate From owner-freebsd-hackers Wed Mar 19 17:51:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA12527 for hackers-outgoing; Wed, 19 Mar 1997 17:51: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 RAA12517 for ; Wed, 19 Mar 1997 17:51:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id RAA18256; Wed, 19 Mar 1997 17:52:29 -0800 (PST) Message-Id: <199703200152.RAA18256@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: dennis cc: hackers@FreeBSD.ORG Subject: Re: insight on malloc crash... In-reply-to: Your message of "Wed, 19 Mar 1997 19:04:57 EST." <3.0.32.19970319190454.00b222d0@etinc.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Mar 1997 17:52:29 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Can anyone give some insight on why the following code might >panic v2.2 (while it has been working happily since 1.x) > >p=malloc(size,M_DEVBUF,M_WAITOK); >if (p) > bzero(p,size) > > >bzero is panicing....did something change? this stuff isnt very >well document :/ The only thing that comes to mind off-hand is that "size" might be bogus (either 0 or way too large). Is the panic on the first byte zeroed, or is it some amount into the malloced area? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Mar 19 18:47:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA18361 for hackers-outgoing; Wed, 19 Mar 1997 18:47:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA18355 for ; Wed, 19 Mar 1997 18:47:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA12885; Wed, 19 Mar 1997 19:34:02 -0700 From: Terry Lambert Message-Id: <199703200234.TAA12885@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 19 Mar 1997 19:34:02 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703200006.KAA29110@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 20, 97 10:36: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 > > Yes. This should go. So should all configuration options that > > cause conditional compilation of code rather than conditional > > inclusion of objects in the link which extend a global linker set. > > That's a lot harder. I would say "some" rather than "all". Can you, off the top of your head, think of any code that can be conditionally compiled, but should not be made modular? About the only code I can think of is the "#if DEBUG" type code. If you localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a depedency for the subsystem (by linking it to a single object before linking it to the kernel) than that should go away as well, or at least become sufficiently comparmentalized that you don't have the structures changing out from under you when some modules are compiled with the conditional and some are compiled without. > > If you get rid of conditional compilation, and leave only conditional > > inclusion, then you remove the need for recompile on conditional > > changes, and it becomes a binary/linker issue *only*. This is a *good* > > thing. > > Be wary of increasing the linkage overhead too much 8) I think linkage overhead is where module boundries belong. This lets me have commercial or quasi-commercial (like an Adaptec driver using HIM under non-disclosure by *only* the driver author) module that I don't have to worry about compilation dependencies when I set my comparmentailized flags. Specifically, I'd like to see options for kernel resource management handled via linker-set agregated data structures, highed bidder in the set wins (or better, agregate wins). This would let me provide minimal per-module resource requirements on a per-module basis, and still let me override by commiting an addition 'n' resources. Big win; for instance mbuf counts for big server sites, max subprocess counts for big user sites, etc.. > > They *could* be sparsely loaded. You do not need paged memory > > management to support partial loading (look at Win3.1 DLL's). > > Understood; the point merely being that much of the kernel may be > required _before_ there is any method available again to load the bits > that were left out. A standalone boot-time linker and associated > media drivers are going to be long gone before the kernel is in a > position to talk to the media again. If you can read the blocks, and the load was sparse, you can fill in the sparse pieces. The trick would be knowing that you need to do it; you could handle that by unmapping the allocated-but-unpopulated regions. Not much sense in doing this; all it saves is load time if most of your code in the load path is not in the run path... this is only useful if your modules do not each end up in their own virtual address space like they should, since you wouldn't have to reclaim areas where you loaded (for instance) device code for a device that didn't probe true. Marking the probe code discardable means you can recover the whole area, sperate KVA or not, for things that didn't probe as present. For a PnP OS, the BIOS has the option of not PnP enabling non-boot-ctritical devices (many people believe this is an error in the PnP specification). 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 Mar 19 18:48:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA18518 for hackers-outgoing; Wed, 19 Mar 1997 18:48:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA18508 for ; Wed, 19 Mar 1997 18:48:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA12900; Wed, 19 Mar 1997 19:35:44 -0700 From: Terry Lambert Message-Id: <199703200235.TAA12900@phaeton.artisoft.com> Subject: Re: wd driver questions To: nate@mt.sri.com (Nate Williams) Date: Wed, 19 Mar 1997 19:35:44 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: <199703200146.SAA00999@rocky.mt.sri.com> from "Nate Williams" at Mar 19, 97 06:46:35 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 > > > There are? We haven't yet established where "the front of the disk" > > > is yet. It's not safe (or reliable) to try to rewrite the MBR (virus > > > protection), or the slack space following (some other systems put > > > bootstraps there). Then the next cylinder might be a partition. > > > > Override the virus protection. > > It's not possible to do inside the install program. You misunderstand: "Tell human to override the virus protection", NOT "code software to override the virus protection" 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 Mar 19 19:01:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA19406 for hackers-outgoing; Wed, 19 Mar 1997 19:01:52 -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 TAA19391 for ; Wed, 19 Mar 1997 19:01:42 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA00691; Thu, 20 Mar 1997 13:28:20 +1030 (CST) From: Michael Smith Message-Id: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703200234.TAA12885@phaeton.artisoft.com> from Terry Lambert at "Mar 19, 97 07:34:02 pm" To: terry@lambert.org (Terry Lambert) Date: Thu, 20 Mar 1997 13:28:20 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De 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: > > > Yes. This should go. So should all configuration options that > > > cause conditional compilation of code rather than conditional > > > inclusion of objects in the link which extend a global linker set. > > > > That's a lot harder. I would say "some" rather than "all". > > Can you, off the top of your head, think of any code that can be > conditionally compiled, but should not be made modular? About the > only code I can think of is the "#if DEBUG" type code. That's the one. There's also quite a lot of code whose behaviour depends on various other options, but it would be practical in the short term to just compile several times with the sensible combinations of the various options and produce different modules. (I am thinking here fe. of NFS_NOSERVER) > If you > localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a > depedency for the subsystem (by linking it to a single object before > linking it to the kernel) than that should go away as well, or at > least become sufficiently comparmentalized that you don't have the > structures changing out from under you when some modules are compiled > with the conditional and some are compiled without. Debugging should always have been on a per-module basis; having a single kernelwide "DEBUG" define is clumsy. However 'debug subsystem' implies always-present debug hooks, which can be expensive. I don't like that much. > Specifically, I'd like to see options for kernel resource management > handled via linker-set agregated data structures, highed bidder in the > set wins (or better, agregate wins). This would let me provide minimal > per-module resource requirements on a per-module basis, and still let me > override by commiting an addition 'n' resources. Big win; for instance > mbuf counts for big server sites, max subprocess counts for big user > sites, etc.. Most of that would be better handled (as implied by Doug R.) by a persistent attribute store (that R word) and dynamic allocation. I can't see myself loading a module with nothing but 1024 mbufs in its BSS 8) > > Understood; the point merely being that much of the kernel may be > > required _before_ there is any method available again to load the bits > > that were left out. A standalone boot-time linker and associated > > media drivers are going to be long gone before the kernel is in a > > position to talk to the media again. > > If you can read the blocks, and the load was sparse, you can fill in > the sparse pieces. You are still not listening 8); I have just said "when you discover you need the blocks, you can no longer read them because your load source has gone." This is an issue for the period from when control is transferred to the loaded kernel from the linker until a filesystem is mounted, and thus all the code that could possibly be required over that interval must be present. > 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 Mar 19 19:02:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA19449 for hackers-outgoing; Wed, 19 Mar 1997 19:02:06 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA19428 for ; Wed, 19 Mar 1997 19:01:58 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id TAA09402; Wed, 19 Mar 1997 19:01:25 -0800 (PST) To: "Dr.C Miguel Garay Garcell / Profesor Titular" cc: hackers@freebsd.org Subject: Re: (Fwd) X11 under 2.2-RELEASE? In-reply-to: Your message of "Wed, 19 Mar 1997 12:17:38 EST." <319C4D43A1@ceis.ispjae.edu.cu> Date: Wed, 19 Mar 1997 19:01:25 -0800 Message-ID: <9399.858826885@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hmm, is it just me, or are the versions of xterm and xdm shipped with > 2.2-RELEASE still slightly skewed with respect to utmp? You probably just need to pick up more current versions of the XFree86 distribution for 2.2 on ftp.freebsd.org. They were recently updated. Jordan From owner-freebsd-hackers Wed Mar 19 20:53:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA25255 for hackers-outgoing; Wed, 19 Mar 1997 20:53:51 -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 UAA25250 for ; Wed, 19 Mar 1997 20:53:47 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w7Zqq-0001Ye-00; Wed, 19 Mar 1997 21:53:20 -0700 To: "Jordan K. Hubbard" Subject: Re: dup3() - I've thought it over and decided... Cc: Mike Pritchard , hackers@freebsd.org In-reply-to: Your message of "Wed, 19 Mar 1997 01:06:03 PST." <20682.858762363@time.cdrom.com> References: <20682.858762363@time.cdrom.com> Date: Wed, 19 Mar 1997 21:53:19 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <20682.858762363@time.cdrom.com> "Jordan K. Hubbard" writes: : Anyone remember a timesharing system called ITS (from MIT)? If you : got disconnected from the modem (not uncommon in those days of : Pennywhistle, 300 baud acoustically-coupled modems :-) you wouldn't : lose your session, like you do under UNIX, rather the next time you : logged in it would ask you: : : [Attach your detached tree?] : : And if you said 'y' you'd get your old process tree back, everything : right where you left it. VMS kinda did this too. Its terminal driver was "detachable" and you could then "attach" a new tty. Basically, you had an upper level interface (the virtual TTY) and a lower interface (the physical hardware). An instance of a tty could talk to any physical device[*]. Maybe something like that would be a useful abstraction. I actually think that you can likely do the terminal redirection in a souped up pty driver. I think that doing one per command is insanely expensive, but some abstraction like VMS might help, since the detach did the right thing wrt buffered I/O and the like. Warner [*] well, to the bottom half of the driver, so things like DECnet terminals and TCP/IP Telnet session stuck around when the net flaked out. Very handy back when I was at the slow end of the net (a 9600 baud link to sri-nic on the arapa net). From owner-freebsd-hackers Wed Mar 19 20:57:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA25397 for hackers-outgoing; Wed, 19 Mar 1997 20:57:01 -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 UAA25392 for ; Wed, 19 Mar 1997 20:56:58 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w7Zsz-0001Yq-00; Wed, 19 Mar 1997 21:55:33 -0700 To: "Jordan K. Hubbard" Subject: Re: dup3() - I've thought it over and decided... Cc: Stephen McKay , freebsd-hackers@freebsd.org In-reply-to: Your message of "Wed, 19 Mar 1997 03:35:39 PST." <5569.858771339@time.cdrom.com> References: <5569.858771339@time.cdrom.com> Date: Wed, 19 Mar 1997 21:55:30 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <5569.858771339@time.cdrom.com> "Jordan K. Hubbard" writes: : > Then again, maybe we could get a good TOPS-10 emulation going. Had lots : > of fun in the Good Old Days(tm) of University detaching and reattaching : : Who needs TOPS-10 emulation? Just run the genuine OS under the PDP-10 : machine emulator. :-) The author was threatening to port it to : something non-sparc last time I talked to him. ;) There are at least three desystem 10 or DECsystem 20 emulators that run on alphas... Kinda handy to have those 64 bits to simulate the 36 bit words :-). Warner From owner-freebsd-hackers Thu Mar 20 00:00:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01536 for hackers-outgoing; Thu, 20 Mar 1997 00:00:57 -0800 (PST) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA01531 for ; Thu, 20 Mar 1997 00:00:53 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id SAA28528; Thu, 20 Mar 1997 18:00:31 +1000 Received: by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) id RAA00482; Thu, 20 Mar 1997 17:48:26 +1000 (EST) Date: Thu, 20 Mar 1997 17:48:26 +1000 (EST) From: Stephen McKay Message-Id: <199703200748.RAA00482@ogre.dtir.qld.gov.au> To: Michael Smith cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: Anybody using Tyan S1672 (Tacoma) motherboard with parity RAM? X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: >sthaug@nethelp.no stands accused of saying: >> Is anybody using the Tyan S1672 (Tacoma) motherboard with parity RAM >> with FreeBSD? > >No, but I've seen some oddities with another HX board. > >> We have a couple of these here, and they work fine as long as we only >> configure normal parity checking in the BIOS. As soon as we turn on >> ECC, we start getting mysterious crashes etc. We'd like to hear about >> other experiences with this board. Thanks in advance! > >With the Tekram P5H30 board, using an Award BIOS, there are several >different parity/ECC settings. At least one of these results in the >board bombing out with an ECC error long before anything resembling >an OS is loaded. I've been meaning to bring this up in -hardware, but now that the topic is open... I have an Octek Rhino 9 rev 1.4 motherboard, which, according to the PCI stuff at boot has rev 1 of both the TXC and PIIX3 chips. If rev 1 equates to A1 then ECC is supposed to not work (according to a chap here who watches the PC chipset groups). However, all the advertising, and the packaging, and the BIOS claim that it works. Plus, if I boot in parity mode, then use pciconf to flip it into ECC mode, then I get an instant NMI like I expect. So, maybe ECC is working. However, ECC only works when I run at 120Mhz (60Mhz bus speed). At 133Mhz (66Mhz bus speed) I can run parity mode at the most aggressive settings. At 120Mhz, I can run either parity or ECC mode at the most aggressive settings. At 133Mhz with the LEAST aggressive settings I can find, ECC will cause a lockup (not an NMI) about one minute into a kernel compilation. Sometimes it doesn't make it through booting. By the way, I'm using Micron 60ns FPM 16Mb (x2) ram. I have ordered Intel's errata on these chips through their web site, but that was weeks ago. If they ever turn up, it should shed some light on this. If anyone else has this info (maybe Rodney?), I'd appreciate some enlightenment! Stephen. From owner-freebsd-hackers Thu Mar 20 00:16:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA01979 for hackers-outgoing; Thu, 20 Mar 1997 00:16:42 -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 AAA01974 for ; Thu, 20 Mar 1997 00:16:39 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id AAA10605 for ; Thu, 20 Mar 1997 00:16:38 -0800 (PST) Date: Thu, 20 Mar 1997 00:16:37 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: CRC errors with SMC 100MBit? And vx0 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 Using a SMC card in a 2.2-nearly-released-but-cannot-remember-exactly-which-march-revision, My 3com linkswitch 3k (And the NFS server receiving the data) is reporting that about 1% or so of the packets coming out of my SMC card to the server have CRC errors. Interestingly enough, it appears to only be via NFS traffic, since FTP's of 1 GB will go fine with no errors at a few MB/sec, but NFS traffic instantly causes them to appear. So I was thinking maybe it was UDP traffic, *but* as near as I can tell, I'm using TCP mounts. So heck if I know. It's annoying though. Any ideas? Actually, on a whim, I just swapped the SMC card for a 3COM 3c905 100MBit card, and it does similar type things. I've tested the cabling with my trusty Fluke LanMeter, and even a null cable with the cards back-to-back shows the problem, so I don't think it's my Switch. From owner-freebsd-hackers Thu Mar 20 01:27:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA04431 for hackers-outgoing; Thu, 20 Mar 1997 01:27:51 -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 BAA04422 for ; Thu, 20 Mar 1997 01:27:28 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA29191; Thu, 20 Mar 1997 10:27:25 +0100 Received: from mozart.eurocontrol.fr by eurocontrol.fr with ESMTP (1.37.109.16/16.2) id AA021859927; Thu, 20 Mar 1997 10:25:28 +0100 Message-Id: <199703200925.AA021859927@euro.eurocontrol.fr> Received: by mozart.eurocontrol.fr (1.37.109.16/16.2) id AA257769926; Thu, 20 Mar 1997 10:25:27 +0100 From: "yann a. oudghiri" Subject: DE disks drivers... To: freebsd-hackers@freebsd.org Date: Thu, 20 Mar 1997 10:25:26 MET X-Mailer: Elm [revision: 109.14] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hello, does anybody knows if the release 2.1.7 has a driver -- a /dev/XXX, for 1.8Mo formatted disks -- by 2M.exe for ex., and mac disks ? don't tell me about mdisk, what i want is to be abble to mount such disks ? -- yann a. oudghiri http://www.mygale.org/07/oudghiri mail-to: oudghiri@mygale.org From owner-freebsd-hackers Thu Mar 20 01:43:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA05079 for hackers-outgoing; Thu, 20 Mar 1997 01:43:56 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA05071 for ; Thu, 20 Mar 1997 01:43:52 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id KAA17941 for ; Thu, 20 Mar 1997 10:43:50 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.5/8.6.9) id KAA03193 for freebsd-hackers@freefall.cdrom.com; Thu, 20 Mar 1997 10:52:41 +0100 (MET) Date: Thu, 20 Mar 1997 10:52:41 +0100 (MET) From: Christoph Kukulies Message-Id: <199703200952.KAA03193@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: background pixmap at boot time Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I may be wrong but wasn't there a facility to allow for a background picture to show at boot time or setup time (a la MS dark blue screen at Win95 setup or Win95 coudy sky)? The motif will be another question, though. -- Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Mar 20 02:05:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA06019 for hackers-outgoing; Thu, 20 Mar 1997 02:05:10 -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 CAA06006 for ; Thu, 20 Mar 1997 02:05:02 -0800 (PST) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id CAA03160; Thu, 20 Mar 1997 02:00:47 -0800 (PST) Message-ID: <19970320020046.37549@hydrogen.nike.efn.org> Date: Thu, 20 Mar 1997 02:00:46 -0800 From: John-Mark Gurney To: "yann a. oudghiri" Cc: freebsd-hackers@freebsd.org Subject: Re: DE disks drivers... References: <199703200925.AA021859927@euro.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64_p3-9,11-13,16-17,20-23,25-27 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk yann a. oudghiri scribbled this message on Mar 20: > hello, > does anybody knows if the release 2.1.7 has a driver -- a /dev/XXX, > for 1.8Mo formatted disks -- by 2M.exe for ex., and mac disks ? if your talking about 1.72meg disk... FreeBSD has support them since at least 1.1.5.1... (I know, I installed it off 1.72meg dos formated floppies :) )... > don't tell me about mdisk, what i want is to be abble to mount > such disks ? you can mount floppies with the msdosfs... using the appropriate /dev/fdX.size device... I don't do much with mac disks... but there is a port of hfs in ports/emulators that is suppose to be able to read mac disks (hard disks, floppies, and cdroms)... but I've never used it was I don't work with macs... hope this helps.. 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 Thu Mar 20 02:18:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA06384 for hackers-outgoing; Thu, 20 Mar 1997 02:18:47 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA06376 for ; Thu, 20 Mar 1997 02:18:42 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id LAA13853; Thu, 20 Mar 1997 11:15:04 +0100 (MET) Date: Thu, 20 Mar 1997 11:15:04 +0100 (MET) From: Andrzej Bialecki To: Marty Bower cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: MSWord docs... 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, 19 Mar 1997, Marty Bower wrote: > "Save as HTML" in Word? > Hmmm... not quite but close. Did anybody try to use Netscape with MSWord plug-in? I don't have it installed (being myself happy Lynx user :-), but you could try... Andy, +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-hackers Thu Mar 20 02:32:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA06775 for hackers-outgoing; Thu, 20 Mar 1997 02:32:56 -0800 (PST) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA06770 for ; Thu, 20 Mar 1997 02:32:51 -0800 (PST) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id LAA13957; Thu, 20 Mar 1997 11:22:39 +0100 (MET) Date: Thu, 20 Mar 1997 11:22:39 +0100 (MET) From: Andrzej Bialecki To: Christoph Kukulies cc: freebsd-hackers@freefall.freebsd.org Subject: Re: background pixmap at boot time In-Reply-To: <199703200952.KAA03193@gilberto.physik.rwth-aachen.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, 20 Mar 1997, Christoph Kukulies wrote: > > I may be wrong but wasn't there a facility to allow for a background > picture to show at boot time or setup time (a la MS dark blue screen > at Win95 setup or Win95 coudy sky)? The motif will be another question, > though. > > -- > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > Michael Smith prepared patch for -current to do this. It works and it's nice :-) He put it at his ftp site, but the URL escaped me. BTW, I think there should be an ioctl call to this to turn it off at the end of booting (just before the login prompt comes up), to avoid confusion amongst unaware ones ;-) It took me some time to guess what key is used to go back to normal screen... (u know, sometimes I'm a risky guy: I apply patches and don't read the docs to the very end). Andy +-------------------------------------------------------------------------+ Andrzej Bialecki _) _) _)_) _)_)_) _) _) --------------------------------------- _)_) _) _) _) _)_) _)_) Research and Academic Network in Poland _) _)_) _)_)_)_) _) _) _) Bartycka 18, 00-716 Warsaw, Poland _) _) _) _) _)_)_) _) _) +-------------------------------------------------------------------------+ From owner-freebsd-hackers Thu Mar 20 03:21:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA08163 for hackers-outgoing; Thu, 20 Mar 1997 03:21: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 DAA08158 for ; Thu, 20 Mar 1997 03:21:09 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id VAA05519; Thu, 20 Mar 1997 21:50:58 +1030 (CST) From: Michael Smith Message-Id: <199703201120.VAA05519@genesis.atrad.adelaide.edu.au> Subject: Re: background pixmap at boot time In-Reply-To: <199703200952.KAA03193@gilberto.physik.rwth-aachen.de> from Christoph Kukulies at "Mar 20, 97 10:52:41 am" To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Thu, 20 Mar 1997 21:50:58 +1030 (CST) Cc: freebsd-hackers@freefall.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 Christoph Kukulies stands accused of saying: > > I may be wrong but wasn't there a facility to allow for a background > picture to show at boot time or setup time (a la MS dark blue screen > at Win95 setup or Win95 coudy sky)? The motif will be another question, > though. ftp://gsoft.com.au/pub/2.2_splashkit.tar.gz But I only got one piece of feedback on it, so it's not on the 2.2 CDrom. > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de -- ]] 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 Mar 20 03:33:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA08476 for hackers-outgoing; Thu, 20 Mar 1997 03:33: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 DAA08469 for ; Thu, 20 Mar 1997 03:33:06 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id MAA25608; Thu, 20 Mar 1997 12:33:01 +0100 (MET) From: Søren Schmidt Message-Id: <199703201133.MAA25608@ravenock.cybercity.dk> Subject: Re: background pixmap at boot time In-Reply-To: from Andrzej Bialecki at "Mar 20, 97 11:22:39 am" To: abial@korin.warman.org.pl (Andrzej Bialecki) Date: Thu, 20 Mar 1997 12:33:00 +0100 (MET) Cc: kuku@gilberto.physik.rwth-aachen.de, 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 Andrzej Bialecki who wrote: > On Thu, 20 Mar 1997, Christoph Kukulies wrote: > > > > > I may be wrong but wasn't there a facility to allow for a background > > picture to show at boot time or setup time (a la MS dark blue screen > > at Win95 setup or Win95 coudy sky)? The motif will be another question, > > though. > > > > -- > > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > > > Michael Smith prepared patch for -current to do this. It works and it's > nice :-) He put it at his ftp site, but the URL escaped me. ftp.gsoft.com.au IIRC > BTW, I think there should be an ioctl call to this to turn it off at the > end of booting (just before the login prompt comes up), to avoid confusion > amongst unaware ones ;-) It took me some time to guess what key is used to > go back to normal screen... (u know, sometimes I'm a risky guy: I apply > patches and don't read the docs to the very end). Hmm, this is still a hack, its supposed to be a key definable via the keymap... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu Mar 20 03:38:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA08781 for hackers-outgoing; Thu, 20 Mar 1997 03:38:50 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA08773 for ; Thu, 20 Mar 1997 03:38:45 -0800 (PST) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id LAA15862; Thu, 20 Mar 1997 11:22:48 GMT To: Michael Smith Cc: terry@lambert.org (Terry Lambert), bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Kernel configuration futures (Was Re: wd driver questions) References: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au> From: Doug Rabson Date: 20 Mar 1997 11:22:45 +0000 In-Reply-To: Michael Smith's message of Thu, 20 Mar 1997 13:28:20 +1030 (CST) Message-ID: Lines: 104 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: > > Terry Lambert stands accused of saying: > > > > Yes. This should go. So should all configuration options that > > > > cause conditional compilation of code rather than conditional > > > > inclusion of objects in the link which extend a global linker set. > > > > > > That's a lot harder. I would say "some" rather than "all". > > > > Can you, off the top of your head, think of any code that can be > > conditionally compiled, but should not be made modular? About the > > only code I can think of is the "#if DEBUG" type code. > > That's the one. There's also quite a lot of code whose behaviour depends > on various other options, but it would be practical in the short term > to just compile several times with the sensible combinations of the > various options and produce different modules. (I am thinking here > fe. of NFS_NOSERVER) One thing I will be doing with the NFS code is to separate the server and client code into two clean pieces. Instead of building a single module with both client and server, there will be two independant modules. I don't think they should have been together in the first place. > > > If you > > localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a > > depedency for the subsystem (by linking it to a single object before > > linking it to the kernel) than that should go away as well, or at > > least become sufficiently comparmentalized that you don't have the > > structures changing out from under you when some modules are compiled > > with the conditional and some are compiled without. > > Debugging should always have been on a per-module basis; having a single > kernelwide "DEBUG" define is clumsy. However 'debug subsystem' implies > always-present debug hooks, which can be expensive. I don't like that > much. > > > Specifically, I'd like to see options for kernel resource management > > handled via linker-set agregated data structures, highed bidder in the > > set wins (or better, agregate wins). This would let me provide minimal > > per-module resource requirements on a per-module basis, and still let me > > override by commiting an addition 'n' resources. Big win; for instance > > mbuf counts for big server sites, max subprocess counts for big user > > sites, etc.. > > Most of that would be better handled (as implied by Doug R.) by a > persistent attribute store (that R word) and dynamic allocation. I can't > see myself loading a module with nothing but 1024 mbufs in its BSS 8) Exactly. If kernel variables like #mbufs were controlled by a persistent sysctl database then performance tuning becomes trivial and certainly doesn't require re-linking the kernel with the 'server buffering module'. One could even write a flashy GUI thing for editing the variables. I don't think I have the strength for that though :-). > > > > Understood; the point merely being that much of the kernel may be > > > required _before_ there is any method available again to load the bits > > > that were left out. A standalone boot-time linker and associated > > > media drivers are going to be long gone before the kernel is in a > > > position to talk to the media again. > > > > If you can read the blocks, and the load was sparse, you can fill in > > the sparse pieces. > > You are still not listening 8); I have just said "when you discover you > need the blocks, you can no longer read them because your load source > has gone." This is an issue for the period from when control is > transferred to the loaded kernel from the linker until a filesystem is > mounted, and thus all the code that could possibly be required over > that interval must be present. The kernel file ought to be a minimal system (no filesystems, no drivers) aggregated with some number of kernel modules. Filesystems and drivers and everything else would plug themselves into the kernel using sysinits. I think that the right way to do this is to have all drivers and filesystems which must be present at boot time (e.g. everything needed to find the root filesystem whether it is local or NFS mounted) statically aggregated with the kernel file (still modules, but essentially pre-loaded). Other modules which the administrator knows will be needed *could* also be pre-loaded but this is not necessary. After the root filesystem is present, the persistent configuration database is available. This will contain all that is needed to load modules for all pci, pnp, pccard devices that are detected. Legacy isa devices can be handled by having a list of drivers to load unconditionally and device parameters (irq, mem, etc) to use with those drivers. Once all the modules have been loaded from the root filesystem (and passed their probes), boot continues more or less as it does today. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426 From owner-freebsd-hackers Thu Mar 20 03:54:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA09318 for hackers-outgoing; Thu, 20 Mar 1997 03:54:03 -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 DAA09313 for ; Thu, 20 Mar 1997 03:54:00 -0800 (PST) Message-Id: <199703201154.DAA09313@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA183358642; Thu, 20 Mar 1997 22:50:42 +1100 From: Darren Reed Subject: dump for msdos filesystems To: hackers@freebsd.org Date: Thu, 20 Mar 1997 22:50:41 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk whilst looking at the overall backup picture for my pc, I realised it would be nice to backup dos from unix. is there already a dump converted to msdos ? if not, I'm going to hack on dump a bit. From owner-freebsd-hackers Thu Mar 20 04:35:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA11463 for hackers-outgoing; Thu, 20 Mar 1997 04:35:46 -0800 (PST) Received: from tarpon.exis.net (stefan@tarpon.exis.net [205.252.72.108]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA11447 for ; Thu, 20 Mar 1997 04:35:44 -0800 (PST) Received: (from stefan@localhost) by tarpon.exis.net (8.7.4/8.7.3) id HAA29332; Thu, 20 Mar 1997 07:39:37 -0500 Date: Thu, 20 Mar 1997 07:39:36 -0500 (EST) From: Stefan Molnar To: "Jordan K. Hubbard" cc: "Dr.C Miguel Garay Garcell / Profesor Titular" , hackers@FreeBSD.ORG Subject: Re: (Fwd) X11 under 2.2-RELEASE? In-Reply-To: <9399.858826885@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 > You probably just need to pick up more current versions of the XFree86 > distribution for 2.2 on ftp.freebsd.org. They were recently updated. > > > Jordan May I ask when that ws done? I pulled it down 03/19 in the afternoon from ftp.freebsd.org. And I am reviveing the same problem. Thanks, Stefan -------------------------------------------- Stefan Molnar Team Exis.Net stefan@exis.net Member EFF Team OS/2 east-coast-ambassador@soda.CSUA.Berkeley.EDU -------------------------------------------- From owner-freebsd-hackers Thu Mar 20 04:54:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA12339 for hackers-outgoing; Thu, 20 Mar 1997 04:54:11 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA12331; Thu, 20 Mar 1997 04:54:05 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id EAA00410; Thu, 20 Mar 1997 04:53:48 -0800 (PST) To: Stefan Molnar cc: "Dr.C Miguel Garay Garcell / Profesor Titular" , hackers@FreeBSD.ORG, rich@FreeBSD.ORG Subject: Re: (Fwd) X11 under 2.2-RELEASE? In-reply-to: Your message of "Thu, 20 Mar 1997 07:39:36 EST." Date: Thu, 20 Mar 1997 04:53:48 -0800 Message-ID: <406.858862428@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > May I ask when that ws done? I pulled it down 03/19 in the afternoon from > ftp.freebsd.org. And I am reviveing the same problem. Hmmm, I'm sorry to say that I just discovered that the files didn't make it over somehow (and I'm mystified, since I just did again what I remember doing yesterday morning, and now when I look again it's all undone). I'm copying the files over again now (Rich - sorry for the false alarm). By the time you read this, what's in ftp://ftp.freebsd.org/pub/FreeBSD/2.2-RELEASE/XF8632 should be entirely different. Jordan From owner-freebsd-hackers Thu Mar 20 06:25:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA16189 for hackers-outgoing; Thu, 20 Mar 1997 06:25:33 -0800 (PST) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA16183 for ; Thu, 20 Mar 1997 06:25:30 -0800 (PST) Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id qa001264 for ; Thu, 20 Mar 1997 19:57:21 +0000 Message-ID: <333196A1.51F3@wgold.demon.co.uk> Date: Thu, 20 Mar 1997 19:57:21 +0000 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Warner Losh CC: hackers@freebsd.org Subject: Re: Barb problem, FOUND References: <332BC869.37B7@wgold.demon.co.uk> <199703160612.XAA13150@rover.village.org> <199703171856.LAA07505@rover.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Oh come on! Just because a particular compiler is full of bugs doesn't mean that a construct allowed by the language spec is dubious. No way. Maybe the compiler is dubious ... Get a better compiler. If necessary use a platform which has a choice of compilers that are less dubious. James Warner Losh wrote: > > In message <332BC869.37B7@wgold.demon.co.uk> James Mansion writes: > : In no way shape or form is an inline virtual function (destructor or > : not) 'dunious'. Its quite legal. (Whether you might consider it to be > : bad style is another matter. You can't always avoid it if the class is > : a template, though that's clearly not the case with tvision) > > If compilers don't handle it, then the construct is dubious. :-) > > : If the compiler cannot handle code like this, then the compiler should > : be fixed. > > Actually, it is a bug in the as program and it should be fixed. > > Warner From owner-freebsd-hackers Thu Mar 20 06:53:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17252 for hackers-outgoing; Thu, 20 Mar 1997 06:53:52 -0800 (PST) Received: from heaven.gigo.com (root@ppp.gigo.com [207.173.132.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17247 for ; Thu, 20 Mar 1997 06:53:49 -0800 (PST) Received: from heaven.gigo.com (jfesler@heaven.gigo.com [207.173.133.57]) by heaven.gigo.com (8.8.5/8.8.5) with SMTP id GAA00227 for ; Thu, 20 Mar 1997 06:53:44 -0800 (PST) Date: Thu, 20 Mar 1997 06:53:43 -0800 (PST) From: Jason Fesler To: hackers@freebsd.org Subject: tun0/user ppp lockups? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here's a strange one: After 1-3 days of being up, all traffic across tun0 dies. I can still use the ethernet; I can not however reset the PPP connection, nor can I telnet to the PPP port at 3000, or talk to the outside world. Anyone know of any problems with user ppp or with tun0? User PPP worked too easily other than this lockup problem, to want to try kernel PPP ;-) From owner-freebsd-hackers Thu Mar 20 07:17:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18392 for hackers-outgoing; Thu, 20 Mar 1997 07:17:50 -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 HAA18387 for ; Thu, 20 Mar 1997 07:17:48 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w7jaw-0002sI-00; Thu, 20 Mar 1997 08:17:34 -0700 To: James Mansion Subject: Re: Barb problem, FOUND Cc: hackers@freebsd.org In-reply-to: Your message of "Thu, 20 Mar 1997 19:57:21 GMT." <333196A1.51F3@wgold.demon.co.uk> References: <333196A1.51F3@wgold.demon.co.uk> <332BC869.37B7@wgold.demon.co.uk> <199703160612.XAA13150@rover.village.org> <199703171856.LAA07505@rover.village.org> Date: Thu, 20 Mar 1997 08:17:28 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <333196A1.51F3@wgold.demon.co.uk> James Mansion writes: : Just because a particular compiler is full of bugs doesn't mean that a : construct allowed by the language spec is dubious. No way. I misspoke myself. There are several compilers that don't handle this construct correctly. They generally don't whine about it, but they generally do generate horrible code for this case. We saw a few years ago that by removing the inline virtuals we had binaries that were 500k! smaller. We also found with OI that lots of compilers had subtle bugs with inline virtuals. Given all the problems that multiple compilers have implementing it effectively, I think that it is as least unwise to use the construct. In my book, that makes it dubious, but others will have a different opinion. Warner From owner-freebsd-hackers Thu Mar 20 07:24:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18734 for hackers-outgoing; Thu, 20 Mar 1997 07:24:54 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18726 for ; Thu, 20 Mar 1997 07:24:47 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id KAA16782; Thu, 20 Mar 1997 10:27:25 -0500 (EST) Message-Id: <3.0.32.19970320102225.00b1e8c0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 10:22:28 -0500 To: Michael Smith From: dennis Subject: Re: Kernel Object Dependencies Cc: msmith@atrad.adelaide.edu.au, 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:29 AM 3/20/97 +1030, Michael Smith wrote: >dennis stands accused of saying: >> >> in files.i386: >> >> >> >> i386/isa/filename.o optional dn device-driver > ^^ >I missed that, sorry. > >> >> which should clearly be..... >> >> >> >> filename.o: $S/i386/isa/filename.o >> >> -cp $S/i386/isa/filename.o . > >Gotcha. Should it be 'cp' or 'ln -sf' do you think? A symlink will give >you the dependancy behaviour automatically as the kernel dependancy rule >will include the driver, and you save space too. > Yes, thats how BSDI does it...although links dont let you test patched modules as easily without having to overwrite the other one..... >Here's a patch for /usr/src/usr.sbin/config/mkmakefile.c that will >emit the dependancy as you've described; please let me know if it >works for you (beware snarf-n-barf damage) : > >--- /local1/playpen/2.2/src/usr.sbin/config/mkmakefile.c Tue Dec 17 16:17:47 1996 >+++ mkmakefile.c Thu Mar 20 11:26:11 1997 >@@ -675,7 +675,7 @@ > else { > *cp = '\0'; > if (och == 'o') { >- fprintf(f, "%so:\n\t-cp $S/%so .\n\n", >+ fprintf(f, "%so: $S/%so\n\t-cp $S/%so .\n\n", > tail(np), np); > continue; > } > Thanks, I'll give it a try... Dennis From owner-freebsd-hackers Thu Mar 20 07:27:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18845 for hackers-outgoing; Thu, 20 Mar 1997 07:27:13 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18840 for ; Thu, 20 Mar 1997 07:27:10 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id KAA16805; Thu, 20 Mar 1997 10:31:05 -0500 (EST) Message-Id: <3.0.32.19970320102606.00b2adb0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 10:26:09 -0500 To: dg@root.com From: dennis Subject: Re: insight on malloc crash... 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 05:52 PM 3/19/97 -0800, David Greenman wrote: >>Can anyone give some insight on why the following code might >>panic v2.2 (while it has been working happily since 1.x) >> >>p=malloc(size,M_DEVBUF,M_WAITOK); >>if (p) >> bzero(p,size) >> >> >>bzero is panicing....did something change? this stuff isnt very >>well document :/ > > The only thing that comes to mind off-hand is that "size" might be >bogus (either 0 or way too large). Is the panic on the first byte zeroed, >or is it some amount into the malloced area? FYI: The answer, if anyone is interested, is that in 2.2 the userland prototype (in string.h) is not compatible with the kernel version in sys/systm.h, even though the 'c' call is the same. Dennis From owner-freebsd-hackers Thu Mar 20 08:05:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA21035 for hackers-outgoing; Thu, 20 Mar 1997 08:05:21 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21030; Thu, 20 Mar 1997 08:05:16 -0800 (PST) Received: from castle (root@ip190.konnections.com [192.41.71.190]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id JAA26669; Thu, 20 Mar 1997 09:04:46 -0700 (MST) Message-ID: <3332B065.A859E43@konnections.com> Date: Fri, 21 Mar 1997 08:59:33 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: FreeBSD-chat@FreeBSD.org CC: FreeBSD-hackers@FreeBSD.org Subject: Free Systems Journal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hey All: Burning Eagle Book Company would like to announce our forthcoming publication: "The Free Systems Journal" We will feature coverage of all (well almost) Free/Open unix(like) systems and FreeDOS. This includes FreeBSD, NetBSD, Linux, Minix, ELKS, UZI(possibly) and whatever else we can find interest in. We will be a raw publication focusing on content, not style or looks. I plan on limiting it to black and white, forever. Coverage will include: X Window Installation adn configuration Troubleshooting Real world applications Letters Readers' Opinions Hardware issues like: Minimal systems Top end systems Hardware testing & review Laptops Software issues like: Distributions FreeWare CommercialWare Humor How to live without Microsoft User Artwork (B&W) Hacking/Programming System specific issues.... ? Our motiviation centers around Linux Journal's desire to stay strictly Linux focused. This is not a bad decision on their part, but it leaves a void for the other systems. We need contributors to offer articles, tips, opinion, artwork, in the following areas: #1. Real world applications. Descriptions, problems, solutions and the TRUTH about what these systems CAN and CAN'T do in the real world. (1000 to 4000 words) #2. Software reviews. What applications work, and what don't, especially which ones are very strong or very weak. (500 to 2000 words) [Bigger apps and CommercialWare apps may run longer where necessary] #3. Configuration Details. Especially for useful supporting apps that may be harder to do like Sendmail, fax, any big packages. (500 to 3000 words). #4. Hardware configuration issues. Especially for the lesser used systems, i.e. minix, ELKS, Hurd, NetBSD on parted architectures (like NeXT [sorry, that was just what I'm waiting to see]) (1500 to 4000 words) #5. Humor...? 1 to 4000 words....pictures? #6. Tips, usually less than 500 words. #7. Experimental stuff....? 1 to ? words, I'm willing to go serial on these if they're REALLY GOOD. #8. Newbie stuff, if you're just getting started but you have something GOOD to say. #9. Book reviews -- Starting with non-linux systems, then Linux, then Unix in general, then anything else. #10. Anything else well written. I'm very serious about new writers and unique stuff. I'm not a traditional guy, nor are most of you, that's why we're here. I just want to see good stuff. We will pay for most contributions, although not for the smaller stuff. You will get the satisfaction of being published and the exposure. You won't get rich, and I'm starting to think that we won't either. But I want to break even and get word out on the street. ALSO: If you're a company and you'd like advertising space, we have up to 10 pages of advertising available from full page to 1/16th page. We have a set rate, but I'm willing to exchange goods and services as partial payment, especially for small/struggling companies. I'm willing to do about anything to help out. Big firms are stuck with the rates, but I will still negotiate hardware/software as partial payment. Send your inquiries to: mallison@konnections.com or Burning Eagle Books 1175 East Canyon Rd #17 Ogden, UTAH 84404-5972 ATTN: FSJ/Advert REVIEWS: You may submit hardware, software and books for testing and review to: Burning Eagle Books 1175 East Canyon Rd #17 Ogden, UTAH 84404-5972 ATTN: FSJ/Reviews Any questions or input are welcome. Write directly to me at: Mike Allison mallison@konnections.com Thanks, -Mike From owner-freebsd-hackers Thu Mar 20 08:16:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22042 for hackers-outgoing; Thu, 20 Mar 1997 08:16:32 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22029 for ; Thu, 20 Mar 1997 08:16:27 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.5/8.8.5) id KAA11021; Thu, 20 Mar 1997 10:15:58 -0600 (CST) Date: Thu, 20 Mar 1997 10:15:58 -0600 (CST) From: Mark Tinguely Message-Id: <199703201615.KAA11021@plains.nodak.edu> To: avalon@coombs.anu.edu.au Subject: Re: dds tape drives. Cc: darrenr@cyber.com.au, hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I whipped together the sys/scsi/st.c block and record counting code I had for both FreeBSD 2.2-RELEASE and FreeBSD 1.7-RELEASE. This is tested only on FreeBSD 1.7. I surrounded the sys/scsi/st.c changes inside NDSU_ST_EXT defines for quicker disabling if you so desire. A person may also remove the NDSU_ST_EXT #ifdef statements if you also wish. I also added the check to see if the tape is mounted read-write or read-only (I used this is a tape mounting program where an operator mounts a tape in one of those mode, and the tape mounting program can spit the tape out if the operator has the wrong write setting). The Write status is accomplished by adding a new "flag" field in the mtget structure located in the file sys/sys/mtio.h for anyone that is interested you in these changes, you may get them from either: ftp://joy.cs.ndsu.nodak.edu/pub/freebsd-st-count/1.7-st-patch ftp://joy.cs.ndsu.nodak.edu/pub/freebsd-st-count/2.2-st-patch or ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd-st-count/1.7-st-patch ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd-st-count/2.2-st-patch --mark. From owner-freebsd-hackers Thu Mar 20 08:24:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22702 for hackers-outgoing; Thu, 20 Mar 1997 08:24:05 -0800 (PST) Received: from kuoi.asui.uidaho.edu (qmailr@kuoi.asui.uidaho.edu [129.101.191.123]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA22676 for ; Thu, 20 Mar 1997 08:23:59 -0800 (PST) Received: (qmail 25659 invoked by uid 1003); 20 Mar 1997 16:23:55 -0000 Message-ID: <19970320082355.57030@kuoi.asui.uidaho.edu> Date: Thu, 20 Mar 1997 08:23:55 -0800 From: faried nawaz To: Jason Fesler Cc: hackers@freebsd.org Subject: Re: tun0/user ppp lockups? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64e Organization: dis. Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jason Fesler says in : > Here's a strange one: After 1-3 days of being up, all traffic across > tun0 dies. I can still use the ethernet; I can not however reset the > PPP connection, nor can I telnet to the PPP port at 3000, or talk to the > outside world. > > Anyone know of any problems with user ppp or with tun0? User PPP worked > too easily other than this lockup problem, to want to try kernel PPP ;-) on 2.2-gamma dated ~ feb 27, i see this problem every day, perhaps 1-2 times. it's very annoying. ppp stops responding and starts chewing cpu. i end up killing ppp (w/ -9), doing ifconfig tun0 delete, route delete default, and dialing in again. my main reason for using ppp is the packet aliasing -- i need that. blah, faried. -- faried nawaz WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE box 3582, moscow, id 83843-1914, usa linux, the ms-dos of the nineties PIGLET loves you if at first you don't succeed, skydiving is not for you not a system janitor. People's Front Against WWW From owner-freebsd-hackers Thu Mar 20 09:00:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24804 for hackers-outgoing; Thu, 20 Mar 1997 09:00:22 -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 JAA24794 for ; Thu, 20 Mar 1997 09:00:15 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA15376 (5.67b/IDA-1.5 for ); Thu, 20 Mar 1997 17:58:18 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id RAA06358; Thu, 20 Mar 1997 17:57:25 +0100 (CET) Message-Id: <19970320175605.58709@x14.> Date: Thu, 20 Mar 1997 17:56:05 +0100 From: Stefan Esser To: John Utz Cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.65_p2,4-7,10-11,15,18,21-22 In-Reply-To: ; from John Utz on Wed, Mar 19, 1997 at 03:26:27PM -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mar 19, John Utz wrote: > Hah! > > if u find one, let *all* of us know! I seem to recall a post in > one of the groups i read about the fact that some guy in germany hacked > the file format, and then removed it from his website "by request of > microsoft". Sure, a Word viewer DOES exist ... It is even published by Microsoft, and available from their FTP server. I've tested it under Wine, and it does nicely display the USB/HCI spec (which is more than 100 pages long). The program is available as a compressed archive (self-installing) under the name "wrd6view.exe". There is a Win95 version, too, but it does not (yet) run under Wine. Regards, STefan From owner-freebsd-hackers Thu Mar 20 09:35:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26288 for hackers-outgoing; Thu, 20 Mar 1997 09:35:39 -0800 (PST) Received: from mail.calweb.com (mail.calweb.com [208.131.56.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26281 for ; Thu, 20 Mar 1997 09:35:35 -0800 (PST) Received: from devnull (devnull.calweb.com [208.131.56.69]) by mail.calweb.com (8.8.5/8.8.5) with SMTP id JAA00238; Thu, 20 Mar 1997 09:32:08 -0800 (PST) Message-Id: <3.0.1.32.19970320093130.00a74ad0@gigo.com> Warning: Unsolicited Commercial Email (UCE) will be returned to send in bulk X-Sender: jfesler@gigo.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 20 Mar 1997 09:31:30 -0800 To: faried nawaz From: Jason Fesler Subject: Re: tun0/user ppp lockups? Cc: hackers@freebsd.org In-Reply-To: <19970320082355.57030@kuoi.asui.uidaho.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:23 AM 3/20/97 -0800, you wrote: >on 2.2-gamma dated ~ feb 27, i see this problem every day, perhaps 1-2 >times. it's very annoying. ppp stops responding and starts chewing cpu. >i end up killing ppp (w/ -9), doing ifconfig tun0 delete, route delete >default, and dialing in again. Blah... At least you found a way around it. I'll have to code something up that will look for the situation, and do all that. I was killing PPP, but not ifconfig'ing it. Thanks for the pointer. >my main reason for using ppp is the packet aliasing -- i need that. :-) I just need it for a connection :-). I may try kernel PPP (blah, user PPP worked _too_ easily), as long as I can still use ipfw on it. -- Jason Fesler From owner-freebsd-hackers Thu Mar 20 09:53:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA27047 for hackers-outgoing; Thu, 20 Mar 1997 09:53:11 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27041; Thu, 20 Mar 1997 09:53:08 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id JAA01586; Thu, 20 Mar 1997 09:53:02 -0800 (PST) To: mike allison cc: FreeBSD-chat@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Subject: Re: Free Systems Journal In-reply-to: Your message of "Fri, 21 Mar 1997 08:59:33 MST." <3332B065.A859E43@konnections.com> Date: Thu, 20 Mar 1997 09:53:02 -0800 Message-ID: <1582.858880382@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hey All: > > Burning Eagle Book Company would like to announce our forthcoming > publication: > > "The Free Systems Journal" This sounds like a great offering, though I do feel compelled to note that before people jump on board too quickly with this, the FreeBSD Project, in cooperation with Walnut Creek CDROM, is also just now launching "The FreeBSD Newsletter" and will be sending it out free of charge to all interested FreeBSD customers (2.2's recently introduced registration form has a subscription option for it). I mention this now because I am, in fact, currently seeking articles for the first issue, something I was going to announce tomorrow but your announcement sort of galvanized me into action a bit sooner. :) My worry is that two startup publications devoted to this segment of free software market will quickly deplete the available articles, already in rather short supply, and I wonder how we might work this out. It's also going to be possible for me to collect name & address info directly from the installed base, as well as give away free advertising space to FreeBSD related vendors, so it strikes me as a definite possibility that one publication could sort of hamper the growth of the other from a surplus of advantage if we don't work out some more cooperative arrangement. I'd welcome suggestions as to how we might handle this. It's also the objective of the FreeBSD Newsletter to be available in a wide variety of media, including postscript paper copies, ascii (for email) and HTML for the WWW site(s). Back issues will also be kept on www.freebsd.org and distributed with future CDROM distributions. Given that this will probably be nothing like the slick, glossy, full-color periodicals you get from folks like the Linux Journal (and possibly this Free Software Journal), I having had something more like USENIX's ";login" newsletter in mind, perhaps there is ample room in the market for both publications if we play this reasonably cooperatively. If nothing else, the Free Software Journal will be paying its contributors and may therefore attract a different caliber of writer. :) Comments? Jordan From owner-freebsd-hackers Thu Mar 20 10:01:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27618 for hackers-outgoing; Thu, 20 Mar 1997 10:01:59 -0800 (PST) Received: from keystone.westminster.edu (fullermd@keystone.westminster.edu [204.171.15.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27611 for ; Thu, 20 Mar 1997 10:01:54 -0800 (PST) Received: (from fullermd@localhost) by keystone.westminster.edu (8.8.4/8.6.12) id NAA15523; Thu, 20 Mar 1997 13:01:26 -0500 (EST) Date: Thu, 20 Mar 1997 13:01:25 -0500 (EST) From: "Matthew D. Fuller" To: Christoph Kukulies cc: freebsd-hackers@freefall.freebsd.org Subject: Re: background pixmap at boot time In-Reply-To: <199703200952.KAA03193@gilberto.physik.rwth-aachen.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, 20 Mar 1997, Christoph Kukulies wrote: > > I may be wrong but wasn't there a facility to allow for a background > picture to show at boot time or setup time (a la MS dark blue screen > at Win95 setup or Win95 coudy sky)? The motif will be another question, > though. > > -- > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > What, in XWindows? :-} MAtt From owner-freebsd-hackers Thu Mar 20 10:04:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27760 for hackers-outgoing; Thu, 20 Mar 1997 10:04:42 -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 KAA27753; Thu, 20 Mar 1997 10:04:28 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id MAA00723; Thu, 20 Mar 1997 12:04:09 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma000701; Thu Mar 20 12:03:49 1997 Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.11.142]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id MAA13753; Thu, 20 Mar 1997 12:03:56 -0600 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.3/8.6.12) with ESMTP id MAA27214; Thu, 20 Mar 1997 12:04:05 -0600 (CST) Message-Id: <199703201804.MAA27214@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Stefan Esser cc: John Utz , "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: MSWord docs... In-reply-to: Your message of "Thu, 20 Mar 1997 17:56:05 +0100." <19970320175605.58709@x14.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 12:04:04 -0600 From: John Prince Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How does that help with word95 and the office 97 stuff.. Most windows machines shipped today do not ship with word6.x. Stefan Esser writes: > On Mar 19, John Utz wrote: > > Hah! > > > > if u find one, let *all* of us know! I seem to recall a post in > > one of the groups i read about the fact that some guy in germany hacked > > the file format, and then removed it from his website "by request of > > microsoft". > > Sure, a Word viewer DOES exist ... > It is even published by Microsoft, and > available from their FTP server. > > I've tested it under Wine, and it does > nicely display the USB/HCI spec (which > is more than 100 pages long). > > The program is available as a compressed > archive (self-installing) under the name > "wrd6view.exe". There is a Win95 version, > too, but it does not (yet) run under Wine. > > Regards, STefan From owner-freebsd-hackers Thu Mar 20 10:11:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28023 for hackers-outgoing; Thu, 20 Mar 1997 10:11:16 -0800 (PST) Received: from keystone.westminster.edu (keystone.westminster.edu [204.171.15.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28015 for ; Thu, 20 Mar 1997 10:10:53 -0800 (PST) Received: (from fullermd@localhost) by keystone.westminster.edu (8.8.4/8.6.12) id NAA15539; Thu, 20 Mar 1997 13:10:11 -0500 (EST) Date: Thu, 20 Mar 1997 13:10:10 -0500 (EST) From: "Matthew D. Fuller" To: Darren Reed cc: hackers@freebsd.org Subject: Re: dump for msdos filesystems In-Reply-To: <199703201154.DAA09313@freefall.freebsd.org> 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, 20 Mar 1997, Darren Reed wrote: > > whilst looking at the overall backup picture for my pc, I realised it > would be nice to backup dos from unix. > > is there already a dump converted to msdos ? > > if not, I'm going to hack on dump a bit. I might just be being stupid here, but can't you mount your DOS partition, and just backup whatever directory you mounted it on? I guess it might create some problems come restore time, but that could easily be fixed in a version w/ better MSDOS filesystem skills. You can use either mount_msdos directly or mount -t msdos. Unless I'm missing something simple, which is quite possible. :-} MAtt From owner-freebsd-hackers Thu Mar 20 10:26:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA28639 for hackers-outgoing; Thu, 20 Mar 1997 10:26:46 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28620 for ; Thu, 20 Mar 1997 10:26:41 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13973; Thu, 20 Mar 1997 11:14:04 -0700 From: Terry Lambert Message-Id: <199703201814.LAA13973@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 20 Mar 1997 11:14:04 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 20, 97 01:28: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 > That's the one. There's also quite a lot of code whose behaviour depends > on various other options, but it would be practical in the short term > to just compile several times with the sensible combinations of the > various options and produce different modules. (I am thinking here > fe. of NFS_NOSERVER) The NFS_NOSERVER code changes the way the lease VOP's operate, not because the code should be condition, but because the code is badly integrated. The registration of lease management mechanisms should take place for all VFS consumers, not just NFS. This is a generic issue with not being able to register a set of event callback entry points for a module. The *real* problem here is that the NFS server wants to register event handlers, but the server and the client code are in the same module space. This is really a source organization issue. I could see a number of useful events that a VFS consumer at the system call level would want to register. For instance, directory modification events would probably be useful for a file browser application to monitor. In any case, no matter how you slice it, the NFS_NOSERVER is an exception because of implementation, not because it should be, so it isn't a good example. The DEBUG case is a better example, but even you say it should be per module. 8-). > > If you > > localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a > > depedency for the subsystem (by linking it to a single object before > > linking it to the kernel) than that should go away as well, or at > > least become sufficiently comparmentalized that you don't have the > > structures changing out from under you when some modules are compiled > > with the conditional and some are compiled without. > > Debugging should always have been on a per-module basis; having a single > kernelwide "DEBUG" define is clumsy. However 'debug subsystem' implies > always-present debug hooks, which can be expensive. I don't like that > much. Not a "subsystem for debugging", but "debugging for subsystem SUBSYSTEM". For instance, a VM object's relationship to other VM objects, and a process structure object's relationship to other process structure objects, should be encapsulated in the subsystem containing it. This means that I can, for example, change the size of the process structure without changing the ability of another subsystem to deal with the exported contents interface. In other words, the data in a proc structure not used by the proc structure code itself is invariant over debug. If you were a C++ geek, you would call the per subsystem debug data "private" (or "protected"). > > Specifically, I'd like to see options for kernel resource management > > handled via linker-set agregated data structures, highed bidder in the > > set wins (or better, agregate wins). This would let me provide minimal > > per-module resource requirements on a per-module basis, and still let me > > override by commiting an addition 'n' resources. Big win; for instance > > mbuf counts for big server sites, max subprocess counts for big user > > sites, etc.. > > Most of that would be better handled (as implied by Doug R.) by a > persistent attribute store (that R word) and dynamic allocation. I can't > see myself loading a module with nothing but 1024 mbufs in its BSS 8) Can you see linking one into a kernel? 8-). The problem with a registry is that it is not module local; to agregate two or more sets of objects into one larger single set requires that you imply counting methods, etc.. > > If you can read the blocks, and the load was sparse, you can fill in > > the sparse pieces. > > You are still not listening 8); I have just said "when you discover you > need the blocks, you can no longer read them because your load source > has gone." This is an issue for the period from when control is > transferred to the loaded kernel from the linker until a filesystem is > mounted, and thus all the code that could possibly be required over > that interval must be present. Heh. You aren't listening to me... you don't get rid of the boot-loader code. If you don't get rid of it, you can still use it. It's like the BIOS based boot being able to use the INT 13 redirector supplied by OnTrack, when you boot from an OnTrack drive. As long as you don't override it, it's still there. 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 Mar 20 10:50:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA29684 for hackers-outgoing; Thu, 20 Mar 1997 10:50:08 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA29677 for ; Thu, 20 Mar 1997 10:50:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14045; Thu, 20 Mar 1997 11:36:52 -0700 From: Terry Lambert Message-Id: <199703201836.LAA14045@phaeton.artisoft.com> Subject: Re: Kernel configuration futures (Was Re: wd driver questions) To: dfr@render.com (Doug Rabson) Date: Thu, 20 Mar 1997 11:36:52 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: from "Doug Rabson" at Mar 20, 97 11:22:45 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 am thinking here fe. of NFS_NOSERVER) > > One thing I will be doing with the NFS code is to separate the server > and client code into two clean pieces. Instead of building a single > module with both client and server, there will be two independant > modules. I don't think they should have been together in the first > place. Heh. We both pointed at the same fix. 8-). > > Most of that would be better handled (as implied by Doug R.) by a > > persistent attribute store (that R word) and dynamic allocation. I can't > > see myself loading a module with nothing but 1024 mbufs in its BSS 8) > > Exactly. If kernel variables like #mbufs were controlled by a > persistent sysctl database then performance tuning becomes trivial and > certainly doesn't require re-linking the kernel with the 'server > buffering module'. One could even write a flashy GUI thing for > editing the variables. I don't think I have the strength for that > though :-). Personally, I don't like having tunables at all. I would prefer it attempt to allocate and fail on a resource shortage. It's very annoying to hit a hard limit with no good reason. There is only one reason for a hard limit: to prevent accidental "denial of service". The only reson for a soft limit is to prevent intentional "denial of service"... malicious attacks. If I need another mbuf (or other kernel resource), or I will error out some action, why, if I have the memory available, should I allow an error-out to ever occur? Why do I want what are (effectively) gratuitous errors? The whole concept of tunables needs to be revamped. > The kernel file ought to be a minimal system (no filesystems, no > drivers) aggregated with some number of kernel modules. Filesystems > and drivers and everything else would plug themselves into the kernel > using sysinits. > > I think that the right way to do this is to have all drivers and > filesystems which must be present at boot time (e.g. everything needed > to find the root filesystem whether it is local or NFS mounted) > statically aggregated with the kernel file (still modules, but > essentially pre-loaded). Other modules which the administrator knows > will be needed *could* also be pre-loaded but this is not necessary. YES, EXACTLY! There would be *no such thing* as a seperable module which did not self-register via sysinit(). The point of going to ELF, where you can have multiple segments in a given image is to remove the real need for linker sets altogether, and therefore the need for linking, rather than simple agregation of onjects with an object librarian that operates on an ELF "library". Give an loader that can load or force the unload of a self registering and unregistering ELF segment in an ELF image, loadable modules become ELF "libraries" on their own. This also lets me do things like "module TCP requires module IP" (for one example). It also lets me, after I get rid of the vfs_init code's dependence on the !@#%!@! FFS file system being statically linked for it to be able to get the struct vops size, replace the boot FS with any FS I want, including (for example) NTFS or VFAT32 or HPFS or EXT2FS, etc.. If the loader itself is similarly self-agregated (but statically), then I can use the same FS modules for the loader that I use for the kernel; in point of fact, if I leave the loaer code around, the kernel doesn't *need* an FS module other than that provided in the loader image. > After the root filesystem is present, the persistent configuration > database is available. This will contain all that is needed to load > modules for all pci, pnp, pccard devices that are detected. Legacy > isa devices can be handled by having a list of drivers to load > unconditionally and device parameters (irq, mem, etc) to use with > those drivers. I still would prefer that everything "just work" without a registry. For PnP, EISA, MCA, or pure-PCI systems, this will work. For ISA systems, we've covered most of the danger cases (LANCE and NE200 probe, etc.) already. I still need a registry so that I can look up my component ID's for COM and/or CORBA and/or MS software installed on the system (in case we ever support WIN32), but little else. > Once all the modules have been loaded from the root filesystem (and > passed their probes), boot continues more or less as it does today. Yes, exactly. The boot critical devices go in, then the rest of the device go in once boot is done AND the device is present. The probe code is in ELF segments marked "discardable" and will load in the rest of the driver if the probe is true, but either way, the probe code itself is in pages which are reclaimed. The benefits are enormous... besides which, we fit in 4M again (who knows, maybe even 2M!). 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 Mar 20 11:01:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA00344 for hackers-outgoing; Thu, 20 Mar 1997 11:01:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA00338 for ; Thu, 20 Mar 1997 11:01:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14080; Thu, 20 Mar 1997 11:49:59 -0700 From: Terry Lambert Message-Id: <199703201849.LAA14080@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Thu, 20 Mar 1997 11:49:59 -0700 (MST) Cc: james@wgold.demon.co.uk, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Mar 20, 97 08:17:28 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 > : Just because a particular compiler is full of bugs doesn't mean that a > : construct allowed by the language spec is dubious. No way. > > I misspoke myself. There are several compilers that don't handle this > construct correctly. They generally don't whine about it, but they > generally do generate horrible code for this case. We saw a few years > ago that by removing the inline virtuals we had binaries that were > 500k! smaller. We also found with OI that lots of compilers had > subtle bugs with inline virtuals. > > Given all the problems that multiple compilers have implementing it > effectively, I think that it is as least unwise to use the construct. > In my book, that makes it dubious, but others will have a different > opinion. I remember when people were applying the same logic to dynamic scoping of stack variables: if( foo) { int my_dynamic_i; ... } Use of the register keyword on Lattice (later SASC) compilers: fum() { register int a, b, c, d, e, f; /* all the registers...*/ register int q; /* XXX reuses register 'a'!!!*/ } And use of bit fields, unsigned values. and enumerated types (which didn't work in so many odd ways that it's not worth going into). Oh yeah: don't use sbrk() because you can't brk() back to the OS... 8-P. The argument is without merit: if a compiler is buggy, it should be fixed, or the vendor should be forced out of business by word of mouth. 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 Mar 20 11:41:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02589 for hackers-outgoing; Thu, 20 Mar 1997 11:41:37 -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 LAA02584 for ; Thu, 20 Mar 1997 11:41:33 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w7nhP-0003Bt-00; Thu, 20 Mar 1997 12:40:32 -0700 To: Terry Lambert Subject: Re: Barb problem, FOUND Cc: james@wgold.demon.co.uk, hackers@freebsd.org In-reply-to: Your message of "Thu, 20 Mar 1997 11:49:59 MST." <199703201849.LAA14080@phaeton.artisoft.com> References: <199703201849.LAA14080@phaeton.artisoft.com> Date: Thu, 20 Mar 1997 12:40:31 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703201849.LAA14080@phaeton.artisoft.com> Terry Lambert writes: : The argument is without merit: if a compiler is buggy, it should be : fixed, or the vendor should be forced out of business by word of mouth. That's a very high and noble attitude, but sadly products have to be shipped and often times you are't in the position to be able to fix a vendor's product *NOW*. Warner From owner-freebsd-hackers Thu Mar 20 11:49:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02905 for hackers-outgoing; Thu, 20 Mar 1997 11:49:04 -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 LAA02900; Thu, 20 Mar 1997 11:48:57 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA06576; Thu, 20 Mar 1997 19:54:54 +0100 From: Luigi Rizzo Message-Id: <199703201854.TAA06576@labinfo.iet.unipi.it> Subject: Re: Free Systems Journal To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 20 Mar 1997 19:54:54 +0100 (MET) Cc: mallison@konnections.com, FreeBSD-chat@FreeBSD.org, FreeBSD-hackers@FreeBSD.org In-Reply-To: <1582.858880382@time.cdrom.com> from "Jordan K. Hubbard" at Mar 20, 97 09:52:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > launching "The FreeBSD Newsletter" and will be sending it out free of > charge to all interested FreeBSD customers (2.2's recently introduced > registration form has a subscription option for it). > > I mention this now because I am, in fact, currently seeking articles > for the first issue, something I was going to announce tomorrow but > your announcement sort of galvanized me into action a bit sooner. :) what would be the intended (prevalent) audience of "The FreeBSD Newsletter", hobbyists, industrial/commercial users, research oriented people ? I guess that something along the lines of chapters of "The Complete FreeBSD" on various system configuration issues would be of interest to many people, but perhaps not that rewarding to write (because of the need of filling up the details). Conversely, some nice articles on the internals of FreeBSD would be much more interesting to write, but perhaps have a much more limited audience (not to mention that those able to write them might simply not have the time to). 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 Thu Mar 20 11:54:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03253 for hackers-outgoing; Thu, 20 Mar 1997 11:54:15 -0800 (PST) Received: from odin.visigenic.com (odin.visigenic.com [204.179.98.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03248 for ; Thu, 20 Mar 1997 11:54:13 -0800 (PST) Received: from VSI48 (vsi48.visigenic.com [206.64.15.185]) by odin.visigenic.com (Netscape Mail Server v2.02) with SMTP id AAA24409; Thu, 20 Mar 1997 11:50:56 -0800 Message-Id: <3.0.32.19970320115413.009d6510@visigenic.com> X-Sender: toneil@visigenic.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 20 Mar 1997 11:54:14 -0800 To: "Jordan K. Hubbard" From: "Tim Oneil" Subject: Re: Free Systems Journal 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 09:53 AM 3/20/97 -0800, you wrote: >Given that this will probably be nothing like the slick, glossy, >full-color periodicals you get from folks like the Linux Journal (and >possibly this Free Software Journal), I having had something more like >USENIX's ";login" newsletter in mind, perhaps there is ample room in >the market for both publications if we play this reasonably >cooperatively. If nothing else, the Free Software Journal will be >paying its contributors and may therefore attract a different caliber >of writer. :) >Comments? Jordan; I think this is a great idea. I would (since you ask), find someone willing to coordinate the effort, a first editor-in-cheif as it were, wanting to do it becuase he/she loves freeBSD, and then that person can put together a reuest for editors/authors. If two or more people can be found who want to do it, they should bounce around ideas for format and content. I was going to add "then they could submit the ideas to the news letter for approval", but, too many cooks. Maybe it would be better for them to just do it. -Tim From owner-freebsd-hackers Thu Mar 20 12:42:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA05743 for hackers-outgoing; Thu, 20 Mar 1997 12:42:19 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05500 for ; Thu, 20 Mar 1997 12:37:06 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA02680; Thu, 20 Mar 1997 12:22:24 -0800 (PST) To: "Matthew D. Fuller" cc: Darren Reed , hackers@FreeBSD.org Subject: Re: dump for msdos filesystems In-reply-to: Your message of "Thu, 20 Mar 1997 13:10:10 EST." Date: Thu, 20 Mar 1997 12:22:24 -0800 Message-ID: <2676.858889344@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > if not, I'm going to hack on dump a bit. > > I might just be being stupid here, but can't you mount your DOS > partition, and just backup whatever directory you mounted it on? > I guess it might create some problems come restore time, but that could Not at all - I do this all the time with cpio. It's the only way my DOS files ever get backed up at all. :) [And yes, I've restored my DOS filesystem to full working order more than once with the amazing combo FreeBSD/DOS fixit floppy :-) ] Jordan From owner-freebsd-hackers Thu Mar 20 12:43:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA05819 for hackers-outgoing; Thu, 20 Mar 1997 12:43:16 -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 MAA05781 for ; Thu, 20 Mar 1997 12:43:06 -0800 (PST) Message-Id: <199703202043.MAA05781@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA057750382; Fri, 21 Mar 1997 07:39:42 +1100 From: Darren Reed Subject: Re: dump for msdos filesystems To: fullermd@keystone.westminster.edu (Matthew D. Fuller) Date: Fri, 21 Mar 1997 07:39:42 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Matthew D. Fuller" at Mar 20, 97 01:10:10 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 Matthew D. Fuller, sie said: > > On Thu, 20 Mar 1997, Darren Reed wrote: > > > > whilst looking at the overall backup picture for my pc, I realised it > > would be nice to backup dos from unix. > > > > is there already a dump converted to msdos ? > > > > if not, I'm going to hack on dump a bit. > > I might just be being stupid here, but can't you mount your DOS > partition, and just backup whatever directory you mounted it on? > I guess it might create some problems come restore time, but that could > easily be fixed in a version w/ better MSDOS filesystem skills. > You can use either mount_msdos directly or mount -t msdos. > Unless I'm missing something simple, which is quite possible. At work, we recently realised the performance benefit of dump only writing one file to tape (as opposed to how tar/cpio work). For example, filesystems with many small files have the backup time reduced from several hours to less than half an hour. Where there are larger files, the boost isn't so much. darren From owner-freebsd-hackers Thu Mar 20 12:45:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06057 for hackers-outgoing; Thu, 20 Mar 1997 12:45:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06033 for ; Thu, 20 Mar 1997 12:45:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA29840; Thu, 20 Mar 1997 13:33:54 -0700 From: Terry Lambert Message-Id: <199703202033.NAA29840@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Thu, 20 Mar 1997 13:33:53 -0700 (MST) Cc: terry@lambert.org, james@wgold.demon.co.uk, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Mar 20, 97 12:40: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 > : The argument is without merit: if a compiler is buggy, it should be > : fixed, or the vendor should be forced out of business by word of mouth. > > That's a very high and noble attitude, but sadly products have to be > shipped and often times you are't in the position to be able to fix a > vendor's product *NOW*. Ditch your vendor. Eventually he will fix it for loss of business over the problem, or he will disappear for loss of business over the problem. Either way, the vendor is not a long term issue for this kind of problem. 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 Mar 20 12:51:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06411 for hackers-outgoing; Thu, 20 Mar 1997 12:51:56 -0800 (PST) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06404 for ; Thu, 20 Mar 1997 12:51:46 -0800 (PST) Received: by iafnl.es.iaf.nl with UUCP id AA06858 (5.67b/IDA-1.5 for freebsd-hackers@freebsd.org); Thu, 20 Mar 1997 21:51:42 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id TAA01044; Thu, 20 Mar 1997 19:41:55 +0100 (MET) From: Wilko Bulte Message-Id: <199703201841.TAA01044@yedi.iaf.nl> Subject: Re: DE disks drivers... To: gurney_j@resnet.uoregon.edu Date: Thu, 20 Mar 1997 19:41:55 +0100 (MET) Cc: yann.oudighir@eurocontrol.fr, freebsd-hackers@freebsd.org In-Reply-To: <19970320020046.37549@hydrogen.nike.efn.org> from "John-Mark Gurney" at Mar 20, 97 02:00:46 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 As John-Mark Gurney wrote... > yann a. oudghiri scribbled this message on Mar 20: > > don't tell me about mdisk, what i want is to be abble to mount > > such disks ? > > you can mount floppies with the msdosfs... using the appropriate > /dev/fdX.size device... I don't do much with mac disks... but there is a > port of hfs in ports/emulators that is suppose to be able to read mac > disks (hard disks, floppies, and cdroms)... but I've never used it was I > don't work with macs... I've used hfs to read 650Mb removable MO Mac disks. Seems to work ok. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Thu Mar 20 12:52:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06492 for hackers-outgoing; Thu, 20 Mar 1997 12:52:36 -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 MAA06477 for ; Thu, 20 Mar 1997 12:52:32 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w7oof-0003K9-00; Thu, 20 Mar 1997 13:52:05 -0700 To: Terry Lambert Subject: Re: Barb problem, FOUND Cc: james@wgold.demon.co.uk, hackers@freebsd.org In-reply-to: Your message of "Thu, 20 Mar 1997 13:33:53 MST." <199703202033.NAA29840@phaeton.artisoft.com> References: <199703202033.NAA29840@phaeton.artisoft.com> Date: Thu, 20 Mar 1997 13:52:04 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703202033.NAA29840@phaeton.artisoft.com> Terry Lambert writes: : > : The argument is without merit: if a compiler is buggy, it should be : > : fixed, or the vendor should be forced out of business by word of mouth. : > : > That's a very high and noble attitude, but sadly products have to be : > shipped and often times you are't in the position to be able to fix a : > vendor's product *NOW*. : : Ditch your vendor. Eventually he will fix it for loss of business : over the problem, or he will disappear for loss of business over : the problem. Either way, the vendor is not a long term issue for : this kind of problem. At the time we were doing OI, nearly *ALL* of the compilers were so afflicated. Sun's, Centerline's, Lucid's, cfront, Microsoft's, Dec's, HP's and IBM's. They all sucked at doing inline virtuals, creating multiple copies for them. There were *NO* compilers that we could have used that were compainle with the Sun compiler on SunOS (our primary market for this library). Oh, and g++ wouldn't even compile OI. When all or nearly all of the compilers you have to deal with don't grok a construct, it is a bad construct. Sometimes it isn't as simple as you paint thing Terry. Warner From owner-freebsd-hackers Thu Mar 20 13:13:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA07513 for hackers-outgoing; Thu, 20 Mar 1997 13:13:38 -0800 (PST) Received: from turing.ukonline.co.uk (turing.ukonline.co.uk [194.6.116.21]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07502 for ; Thu, 20 Mar 1997 13:13:34 -0800 (PST) Received: from lizard (lon1-36.ukonline.co.uk [194.6.117.164]) by turing.ukonline.co.uk (8.6.12/8.6.10) with SMTP id VAA10708 for ; Thu, 20 Mar 1997 21:11:58 GMT Message-ID: <33321948.5997@ukonline.co.uk> Date: Thu, 20 Mar 1997 21:14:48 -0800 From: Benn Horton X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Modem driver needed. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I'm planning to use the ppp command in FreeBSD to handle an ISP connection, but first I need to get my modem up and running. Do you have a generic driver that I could use for my MRI 33.6kbps modem? From owner-freebsd-hackers Thu Mar 20 13:38:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA08903 for hackers-outgoing; Thu, 20 Mar 1997 13:38:27 -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 NAA08898 for ; Thu, 20 Mar 1997 13:38:23 -0800 (PST) Received: from localhost (danny@localhost) by skylark.hilink.com.au (8.8.5/8.6.10) with SMTP id IAA18765 for ; Fri, 21 Mar 1997 08:37:42 +1100 (EST) Date: Fri, 21 Mar 1997 08:37:42 +1100 (EST) From: "Daniel O'Callaghan" To: freebsd-hackers@freebsd.org Subject: Strange output from ps 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, I've seen this twice now, on 2.2-ALPHA (I'm about to upgrade to 2.2R) Cron Daemon said: > ps: kvm_getprocs: Cannot allocate memory It is turning up in a cron job which does 'ps -ax'. Machine is 32 MB RAM, 70MB available swap, 1.3MB free, 4 MB disk cache. intel 486dx4-100. There are about 60 processes running. Does anyone have any ideas? Thanks, Danny From owner-freebsd-hackers Thu Mar 20 13:40:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA09066 for hackers-outgoing; Thu, 20 Mar 1997 13:40:11 -0800 (PST) Received: from python.shoal.net.au (andrew@python.shoal.net.au [203.26.44.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09055; Thu, 20 Mar 1997 13:40:05 -0800 (PST) Received: from localhost (andrew@localhost) by python.shoal.net.au (8.8.5/8.7.3) with SMTP id HAA08281; Fri, 21 Mar 1997 07:39:14 +1000 (EST) Date: Fri, 21 Mar 1997 07:39:14 +1000 (EST) From: Andrew Perry To: "Jordan K. Hubbard" cc: mike allison , FreeBSD-chat@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Subject: Re: Free Systems Journal In-Reply-To: <1582.858880382@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 > > > Hey All: > > > > Burning Eagle Book Company would like to announce our forthcoming > > publication: > > > > "The Free Systems Journal" > > I'd welcome suggestions as to how we might handle this. > > > Comments? > > Jordan > just my 2 cents maybe we should send articles to both, FreeBSD people will certainly support the new newsletter (which I think is a great idea, will you be sending them to australia? otherwise i can live with e-mail) but if we have articles in the Free Systems Journal as well that may generate interest in FreeBSD from non FreeBSD users. Andrew Perry andrew@shoal.net.au From owner-freebsd-hackers Thu Mar 20 13:52:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10064 for hackers-outgoing; Thu, 20 Mar 1997 13:52:51 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10059; Thu, 20 Mar 1997 13:52:49 -0800 (PST) Received: from castle (root@ip190.konnections.com [192.41.71.190]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id OAA29986; Thu, 20 Mar 1997 14:52:11 -0700 (MST) Message-ID: <333301D2.5F697155@konnections.com> Date: Fri, 21 Mar 1997 14:46:58 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: Andrew Perry CC: "Jordan K. Hubbard" , FreeBSD-chat@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Subject: Re: Free Systems Journal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew: I don't think my other response was posted to the whole net, (I'll see what I can do). Basically, I told Jordan that my desire was to allow for reasonable copies of articles in the journal and that we'd post back copies, after a proscribed period, onto the net in various formats. Along with this I would be willing to allow reprints in the newsletter, or more realistically, the rights would revert back to the author who could then offer them up to the newsletter. At the same time, I wouldn't keep from publishing a good article, just because it appeared someplace else (keeping with copyright restrictions, of course). I said I like to look at this as a way to "expand" exposure not compete for it. Anything I haven't thoght of? -Mike Andrew Perry wrote: > > > > > > Hey All: > > > > > > Burning Eagle Book Company would like to announce our forthcoming > > > publication: > > > > > > "The Free Systems Journal" > > > > I'd welcome suggestions as to how we might handle this. > > > > > > Comments? > > > > Jordan > > > just my 2 cents > maybe we should send articles to both, FreeBSD people will certainly > support the new newsletter (which I think is a great idea, will you be > sending them to australia? otherwise i can live with e-mail) but if we > have articles in the Free Systems Journal as well that may generate > interest in FreeBSD from non FreeBSD users. > > Andrew Perry > andrew@shoal.net.au From owner-freebsd-hackers Thu Mar 20 13:53:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10157 for hackers-outgoing; Thu, 20 Mar 1997 13:53: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 NAA10148 for ; Thu, 20 Mar 1997 13:53:35 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA23490; Thu, 20 Mar 1997 21:52:03 GMT Message-Id: <199703202152.VAA23490@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Benn Horton cc: hackers@freebsd.org Subject: Re: Modem driver needed. In-reply-to: Your message of "Thu, 20 Mar 1997 21:14:48 PST." <33321948.5997@ukonline.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 21:52:02 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi > > I'm planning to use the ppp command in FreeBSD to handle an ISP > connection, but first I need to get my modem up and running. Do you > have a generic driver that I could use for my MRI 33.6kbps modem? You don't need a modem driver - the serial driver will suffice. You can use ppp to do the whole lot, including AT commands. Refer to /etc/ppp/ppp.*.sample for details. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Mar 20 13:56:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10407 for hackers-outgoing; Thu, 20 Mar 1997 13:56:07 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10402; Thu, 20 Mar 1997 13:56:05 -0800 (PST) Received: from castle (root@ip207.konnections.com [192.41.71.207]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id OAA00120; Thu, 20 Mar 1997 14:55:35 -0700 (MST) Message-ID: <3333026C.4D412594@konnections.com> Date: Fri, 21 Mar 1997 14:50:22 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: FreeBSD-Chat@FreeBSD.org CC: FreeBSD-Hackers@FreeBSD.org Subject: [Fwd: Re: Free Systems Journal] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk mike allison wrote: > > Jordon: > > This is very interesting. We've been working on this project for a > couple of weeks now and it was at the behest of Greg Lehey whom I've > recruited, to write to FreeBSD and let everyone know. A couple of > things I didn't put out, which I should have, is that I want to be able > to allow for readers to make reasonable copies and that we will place > back issues on the net (like you in multi formats, pdf, ps, etc). I > have no objections to writers doing FreeBSD and FreeBSD related stories > to publishing them in your newletter, and vice versa. I'd also be > willing to list a link to you newsletter and support it in any way > feasible. > > I would certainly hope that we can all complement each other rather than > compete and that readers will want to get as much "news" as possible. > It's hard to say that a free newsletter threatens our market, but I see > a very real concern regarding article availability. > > Rather than deplete that pool however, I want to offer it greater > exposure. Again, although we may pay, the amount isn't going to be a > GREAT attraction (although somehting is better than nothing in that > regard). > > Really, though, our desire is not to compete, but to expand. I think, > in the long run, readers will have Free access to our magazine, they may > need to pay for timely access, but ultimate access through the net, > should be free as well. How free, price-wise, depends on our ability to > find other funding through advertising, or ?. > > Please respond with you comments and thank you for your letter > > Thanks, > > -Mike > > Jordan K. Hubbard wrote: > > > > > Hey All: > > > > > > Burning Eagle Book Company would like to announce our forthcoming > > > publication: > > > > > > "The Free Systems Journal" > > > > This sounds like a great offering, though I do feel compelled to note > > that before people jump on board too quickly with this, the FreeBSD > > Project, in cooperation with Walnut Creek CDROM, is also just now > > launching "The FreeBSD Newsletter" and will be sending it out free of > > charge to all interested FreeBSD customers (2.2's recently introduced > > registration form has a subscription option for it). > > > > I mention this now because I am, in fact, currently seeking articles > > for the first issue, something I was going to announce tomorrow but > > your announcement sort of galvanized me into action a bit sooner. :) > > > > My worry is that two startup publications devoted to this segment of > > free software market will quickly deplete the available articles, > > already in rather short supply, and I wonder how we might work this > > out. It's also going to be possible for me to collect name & address > > info directly from the installed base, as well as give away free > > advertising space to FreeBSD related vendors, so it strikes me as a > > definite possibility that one publication could sort of hamper the > > growth of the other from a surplus of advantage if we don't work out > > some more cooperative arrangement. > > > > I'd welcome suggestions as to how we might handle this. > > > > It's also the objective of the FreeBSD Newsletter to be available in a > > wide variety of media, including postscript paper copies, ascii (for > > email) and HTML for the WWW site(s). Back issues will also be kept on > > www.freebsd.org and distributed with future CDROM distributions. > > > > Given that this will probably be nothing like the slick, glossy, > > full-color periodicals you get from folks like the Linux Journal (and > > possibly this Free Software Journal), I having had something more like > > USENIX's ";login" newsletter in mind, perhaps there is ample room in > > the market for both publications if we play this reasonably > > cooperatively. If nothing else, the Free Software Journal will be > > paying its contributors and may therefore attract a different caliber > > of writer. :) > > > > Comments? > > > > Jordan From owner-freebsd-hackers Thu Mar 20 14:05:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA10857 for hackers-outgoing; Thu, 20 Mar 1997 14:05:15 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10840 for ; Thu, 20 Mar 1997 14:05:03 -0800 (PST) Received: from campa.panke.de (anonymous222.ppp.cs.tu-berlin.de [130.149.17.222]) by mail.cs.tu-berlin.de (8.8.5/8.8.5) with SMTP id WAA21812; Thu, 20 Mar 1997 22:41:48 +0100 (MET) Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id WAA00646; Thu, 20 Mar 1997 22:22:04 +0100 Date: Thu, 20 Mar 1997 22:22:04 +0100 Message-Id: <199703202122.WAA00646@campa.panke.de> From: Wolfram Schneider To: Mike Pritchard Cc: hackers@freebsd.org Reply-to: hackers@freebsd.org Subject: old BSD manpages (Re: cvs commit: www/data docs.sgml) In-Reply-To: <199703171718.JAA21012@freefall.freebsd.org> References: <199703170004.QAA01889@freefall.freebsd.org> <199703171718.JAA21012@freefall.freebsd.org> 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 Mike Pritchard writes: >Wolfram Schneider wrote: >> >> wosch 97/03/16 16:04:54 >> >> Modified: data docs.sgml >> Log: >> Add link to a new man page script. > >What an understatement! Wolfram's new script has man pages >for EVERY FreeBSD release past and present. Good job! Not all releases. I'm still seeking the manual pages for NET/1, 386BSD 0.0, FreeBSD 1.0, and FreeBSD 1.1. Wolfram From owner-freebsd-hackers Thu Mar 20 14:07:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA11002 for hackers-outgoing; Thu, 20 Mar 1997 14:07: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 OAA10977 for ; Thu, 20 Mar 1997 14:07:28 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id WAA24926; Thu, 20 Mar 1997 22:06:51 GMT Message-Id: <199703202206.WAA24926@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Daniel O'Callaghan" cc: freebsd-hackers@freebsd.org Subject: Re: Strange output from ps In-reply-to: Your message of "Fri, 21 Mar 1997 08:37:42 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 22:06:50 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Hi, > > I've seen this twice now, on 2.2-ALPHA (I'm about to upgrade to 2.2R) > > Cron Daemon said: > > > ps: kvm_getprocs: Cannot allocate memory > > It is turning up in a cron job which does 'ps -ax'. > Machine is 32 MB RAM, 70MB available swap, 1.3MB free, 4 MB disk cache. > intel 486dx4-100. There are about 60 processes running. > > Does anyone have any ideas? Sounds like your ps is out of sync with your kernel. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Mar 20 14:14:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA11414 for hackers-outgoing; Thu, 20 Mar 1997 14:14:56 -0800 (PST) Received: from ss1000.ms.mff.cuni.cz (root@ss1000-eth.ms.mff.cuni.cz [194.50.18.221]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11400 for ; Thu, 20 Mar 1997 14:14:48 -0800 (PST) Received: from ulab-13.ms.mff.cuni.cz (vmen3237@ulab-13.ms.mff.cuni.cz [194.50.19.113]) by ss1000.ms.mff.cuni.cz (8.8.3/8.8.3) with ESMTP id XAA05176; Thu, 20 Mar 1997 23:14:22 +0100 (MET) Received: from localhost (vmen3237@localhost) by ulab-13.ms.mff.cuni.cz (8.8.3/8.8.3) with SMTP id XAA13610; Thu, 20 Mar 1997 23:14:20 +0100 (MET) X-Authentication-Warning: ulab-13.ms.mff.cuni.cz: vmen3237 owned process doing -bs Date: Thu, 20 Mar 1997 23:14:20 +0100 (MET) From: "Vladimir Mencl, MK, susSED" X-Sender: vmen3237@ulab-13 Reply-To: "Vladimir Mencl, MK, susSED" To: "Daniel O'Callaghan" cc: freebsd-hackers@freebsd.org Subject: Re: Strange output from ps 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, 21 Mar 1997, Daniel O'Callaghan wrote: > > Cron Daemon said: > > > ps: kvm_getprocs: Cannot allocate memory > Could be because of too many processes running (either of one user or total)? I've experienced problems with ps, the message was "Too many open files in system". It was a global limit problem, and I had to recompile the kernel with increased MAXUSERS value (which increases NPROCS which increases maxfiles). A local limit problem can be solved with ulimit - try to increase the # of processes - ulimit -u # Vlada Mencl From owner-freebsd-hackers Thu Mar 20 14:19:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA11664 for hackers-outgoing; Thu, 20 Mar 1997 14:19:08 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11657; Thu, 20 Mar 1997 14:19:05 -0800 (PST) Received: from castle (root@ip207.konnections.com [192.41.71.207]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id PAA00388; Thu, 20 Mar 1997 15:18:35 -0700 (MST) Message-ID: <33330802.3D353BFD@konnections.com> Date: Fri, 21 Mar 1997 15:13:22 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: FreeBSD-Chat@FreeBSD.org CC: FreeBSD-Hackers@FreeBSD.org, jtc@NetBSD.org Subject: Free Systems Journal -- Philosophy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello again: While we're a bit busy with this conversation about newsletters and jounals, I just wanted to stand up and lay out my philosophy in regards to what Free Systems Journal should be. First of all it has to be an organ (sorry bevis) for the issues that the Free systems community faces. That is the ENTIRE community. Let no one think that this community belongs any more to the Linux users than it does to the FreeDOS or Minix users. We're all in this together. We don't need to agree but we can't deal anyone out. I said my original desire for this sprang from Linux Journal's continued open disregard of other systems. That is not a negative stance for LJ, on the contrary, it never claimed to be anything but. On the other hand, there has always been a need for coverage of other systems in a responsive manner, not as an aside to some greater issue. I assure you if LJ paid attention to other systems, they wouldn't do it justice. I myself wonder how it can be done, but we'll find a pole to revolve around and then expand or contract based on community needs. I don't think any one person, or group, is more qualified to contribute than another. A newbie might have just as pertinent a concern as anyone else, and just as elegant a solution. There are many more newbies out there than gurus. Unlike many of the people out there, a lot of us don't have a guru to defer to. (Except the newsgroups, and we don't always know who's answering the mail there.) I want this endeavor to become something useful to all of us, that we can all have a stake in and be proud of. If the NetBSD folks do something cool, or pull off a major installation, like say, to the Justice Department, we should all be proud and pull a little closer. Our similarities are our strength our differences merely distractions. Our goal should be to become smarter as individuals and to make computing a transparent part of our lives (both from a control sense, and a cost sense). I don't mind having to pay for good software, but I do mind not being able to chose and bad software eventually becoming the ONLY software. UNIX (Sorry to whomever owns the trademark this week) was always open in this sense. It was the great equalizer. It has again become that great equalizer. It has motivated people to create Free systems and that includes free versions of some of the most popular, most expensive and most controlled personal computing software. If you flood my office with contributions, I'll publish what I can. What's really good I'll pass on to others to publish. There's no way that we'll sit on a valuable article just to pump some imagined value out of it. I'm open to any suggestions about how to provide this service. I'm a book guy and magazines are new to us. But I'm become zealous about this and I'm determined to see it through. Your thoughts are appreciated. I'm not a real member of these lists, so please let me know what the right procedure is for joining. Thanks, -Mike Allison Publisher, Burning Eagle Books mallison@konnections.com From owner-freebsd-hackers Thu Mar 20 14:44:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA03171 for hackers-outgoing; Thu, 20 Mar 1997 14:44:35 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA03166 for ; Thu, 20 Mar 1997 14:44:15 -0800 (PST) Received: from awfulhak.demon.co.uk ([158.152.17.1]) by relay-5.mail.demon.net id aa0502280; 20 Mar 97 21:22 GMT Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA20824; Thu, 20 Mar 1997 21:03:15 GMT Message-Id: <199703202103.VAA20824@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: faried nawaz cc: Jason Fesler , hackers@freebsd.org Subject: Re: tun0/user ppp lockups? In-reply-to: Your message of "Thu, 20 Mar 1997 08:23:55 PST." <19970320082355.57030@kuoi.asui.uidaho.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 21:03:15 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does a manual SIGSEGV kill it ? If so, can you tell me what the stack trace looks like ? Also, is this on a direct connection (null-modem) or through a modem ? > Jason Fesler says in : > > > Here's a strange one: After 1-3 days of being up, all traffic across > > tun0 dies. I can still use the ethernet; I can not however reset the > > PPP connection, nor can I telnet to the PPP port at 3000, or talk to the > > outside world. > > > > Anyone know of any problems with user ppp or with tun0? User PPP worked > > too easily other than this lockup problem, to want to try kernel PPP ;-) > > on 2.2-gamma dated ~ feb 27, i see this problem every day, perhaps 1-2 > times. it's very annoying. ppp stops responding and starts chewing cpu. > i end up killing ppp (w/ -9), doing ifconfig tun0 delete, route delete > default, and dialing in again. > > my main reason for using ppp is the packet aliasing -- i need that. > > blah, > > faried. > -- > faried nawaz WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE > box 3582, moscow, id 83843-1914, usa linux, the ms-dos of the nineties > PIGLET loves you if at first you don't succeed, skydiving is not for you > not a system janitor. People's Front Against WWW -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Mar 20 14:48:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA03362 for hackers-outgoing; Thu, 20 Mar 1997 14:48:32 -0800 (PST) Received: from caliban.dihelix.com (caliban.mrtc.org [199.4.33.251]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA03355; Thu, 20 Mar 1997 14:48:28 -0800 (PST) Received: (from langfod@localhost) by caliban.dihelix.com (8.8.4/8.8.3) id MAA00219; Thu, 20 Mar 1997 12:48:10 -1000 (HST) Message-Id: <199703202248.MAA00219@caliban.dihelix.com> Subject: Re: Free Systems Journal -- Philosophy In-Reply-To: <33330802.3D353BFD@konnections.com> from mike allison at "Mar 21, 97 03:13:22 pm" To: mallison@konnections.com (mike allison) Date: Thu, 20 Mar 1997 12:48:10 -1000 (HST) Cc: FreeBSD-Chat@freebsd.org, FreeBSD-Hackers@freebsd.org, jtc@NetBSD.org From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just a thought: Jordan: could FreeBSD Inc./Walnut Creek contract out to do the Newsletter you are thinking of? For one thing it would allow you folks to concentrate on content as opposed to layout. -David Langford langfod@dihelix.com From owner-freebsd-hackers Thu Mar 20 15:12:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA05265 for hackers-outgoing; Thu, 20 Mar 1997 15:12:33 -0800 (PST) Received: from cyber2.servtech.com (root@imap.servtech.com [199.1.22.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA05258 for ; Thu, 20 Mar 1997 15:12:31 -0800 (PST) Received: from pr-comm.com (root@prcomm.roc.servtech.com [204.181.3.14]) by cyber2.servtech.com (8.8.5/8.8.5) with ESMTP id SAA22393 for ; Thu, 20 Mar 1997 18:12:25 -0500 (EST) Received: (from housley@localhost) by pr-comm.com (8.7.5/8.7.3) id SAA06982 for freebsd-hackers@freebsd.org; Thu, 20 Mar 1997 18:11:20 -0500 (EST) From: "James E. Housley" Posted-Date: Thu, 20 Mar 1997 18:11:20 -0500 (EST) Message-Id: <199703202311.SAA06982@pr-comm.com> Subject: RE: tun0/user ppp lockups? To: freebsd-hackers@freebsd.org Date: Thu, 20 Mar 1997 18:11:20 -0500 (EST) 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 I have been having similar problems. I changed to lines yesterday in ppp.conf and things seem better. Haven't run long enough to be sure. In 2.1.x it was recomended to disable and deny lqr (Line Quality). I noticed that 2.2.x enables that by default. enable lqr accept lqr could be changed to disable lqr deny lqr Try it and see if it helps. Jim. From owner-freebsd-hackers Thu Mar 20 15:37:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA06799 for hackers-outgoing; Thu, 20 Mar 1997 15:37:29 -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 PAA06791; Thu, 20 Mar 1997 15:37:04 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA09871; Fri, 21 Mar 1997 10:06:16 +1030 (CST) From: Michael Smith Message-Id: <199703202336.KAA09871@genesis.atrad.adelaide.edu.au> Subject: Re: MSWord docs... In-Reply-To: <199703201804.MAA27214@milo.lodgenet.com> from John Prince at "Mar 20, 97 12:04:04 pm" To: johnp@lodgenet.com (John Prince) Date: Fri, 21 Mar 1997 10:06:16 +1030 (CST) Cc: se@freebsd.org, spaz@u.washington.edu, jkh@time.cdrom.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 John Prince stands accused of saying: > How does that help with word95 and the office 97 stuff.. > Most windows machines shipped today do not ship with word6.x. Word 7 is Word 6 with different icons, basically. The file format and structure are the same. -- ]] 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 Mar 20 15:51:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA07491 for hackers-outgoing; Thu, 20 Mar 1997 15:51:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA07475 for ; Thu, 20 Mar 1997 15:51:01 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA14590; Thu, 20 Mar 1997 16:39:03 -0700 From: Terry Lambert Message-Id: <199703202339.QAA14590@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Thu, 20 Mar 1997 16:39:03 -0700 (MST) Cc: terry@lambert.org, james@wgold.demon.co.uk, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Mar 20, 97 01:52: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 > At the time we were doing OI, nearly *ALL* of the compilers were so > afflicated. Sun's, Centerline's, Lucid's, cfront, Microsoft's, Dec's, > HP's and IBM's. They all sucked at doing inline virtuals, creating > multiple copies for them. There were *NO* compilers that we could > have used that were compainle with the Sun compiler on SunOS (our > primary market for this library). Oh, and g++ wouldn't even compile > OI. Oregon Software's C++ as well? > When all or nearly all of the compilers you have to deal with don't > grok a construct, it is a bad construct. Sometimes it isn't as simple > as you paint thing Terry. The compilers weren't emitting them into seperate segments? You could post-process the object files (a "prelink") if it was. Otherwise, what can I say... you live with the overhead of the emitted static inlines and complain to the vendor. It seems very similar to the issues of statically linked Motif binaries and other large space wasters... ie: NetScape, et. al.. 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 Mar 20 15:58:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA09363 for hackers-outgoing; Thu, 20 Mar 1997 15:58:57 -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 PAA09305; Thu, 20 Mar 1997 15:58:50 -0800 (PST) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id PAA05785 ; Thu, 20 Mar 1997 15:14:41 -0800 (PST) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA05637; Thu, 20 Mar 1997 15:14:36 -0800 Date: Thu, 20 Mar 1997 15:14:36 -0800 (PST) From: "Brian N. Handy" Reply-To: "Brian N. Handy" To: mike allison Cc: "Jordan K. Hubbard" , FreeBSD-chat@freebsd.org, FreeBSD-hackers@freebsd.org Subject: Re: Free Systems Journal In-Reply-To: <333301D2.5F697155@konnections.com> Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Anything I haven't thoght of? Any chance of combining this operation into one mighty empire that could succeed, rather than two competing empires with the same goals? Also, is the Free Systems Journal destined to be a real, oh-my-gosh Publication, with a cover and postage and I can subscribe to it, or something else? (That didn't come across completely clear to me, but I may have missed something.) Jordan has been caught vaguely off-guard, so I'm not sure he's completely fleshed out his version of what he wants to do. At any rate, I'd be more excited about supporting something that was going to get some exposure outside of our little community here. I'm almost afraid a newsletter of sorts would not see a lot of exposure outside of the people already subscribed to freebsd-*, whereas something that gets published and advertised and talked about and whoa here it is on the MAGAZINE RACK and what's this {Free, Net, Open}BSD stuff about anyway? I guess what I'm saying is I strongly support the idea of a publication, if that's what Mike is talking about. Jordan is a real capable salesman, though, who I'm sure could make a newsletter focussed specifically on FreeBSD succeed too. I'd rather see forces that mesh well together rather than smaller competing services. Brian From owner-freebsd-hackers Thu Mar 20 16:17:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA10642 for hackers-outgoing; Thu, 20 Mar 1997 16:17:17 -0800 (PST) Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA10637 for ; Thu, 20 Mar 1997 16:17:13 -0800 (PST) Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.5/(97/03/20 3.25)) id TAA18176; Thu, 20 Mar 1997 19:17:11 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from crc3.concentric.net (61033d0023ny.concentric.net [206.173.18.83]) by newman.concentric.net (8.8.5) id TAA14396; Thu, 20 Mar 1997 19:17:09 -0500 (EST) Message-ID: <3331D3E6.3D12@concentric.net> Date: Thu, 20 Mar 1997 19:18:46 -0500 From: "Richard J. Linane" Reply-To: Typh0on@concentric.net Organization: Richard J. Linane X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Coping Files From MS-DOS to a BSD Partitian? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am wondering if anyone could help me with this as I am quite new BSD and UNIX....but learning. I have an unsupported CD-ROM Drive. I would like to install some of the programs in the Packages Distribution. The only choice I have to install from as a source is a DOS Partitian or from alot of floppies. I think it might intail the mounting of the MS-DOS partitian on the same drive. Do I need to mount the partitian to do this and if so how? Any help would be greatly appriciated and passed on to those who ask. Sincerly, Rich Linane Typh0on@concentric.net From owner-freebsd-hackers Thu Mar 20 16:41:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA12931 for hackers-outgoing; Thu, 20 Mar 1997 16:41:01 -0800 (PST) Received: from grendel.IAEhv.nl (grendel.IAEhv.nl [194.151.72.15]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA12752 for ; Thu, 20 Mar 1997 16:37:55 -0800 (PST) Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id CAA00934; Fri, 21 Mar 1997 02:36:39 +0100 (CET) Message-ID: <19970321023634.25431@grendel.IAEhv.nl> Date: Fri, 21 Mar 1997 02:36:34 +0100 From: Peter Korsten To: John Utz Cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.65e_p2,4-5,7,11,15,18,21-22 In-Reply-To: ; from John Utz on Wed, Mar 19, 1997 at 03:26:27PM -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Utz shared with us: > > On Wed, 19 Mar 1997, Jordan K. Hubbard wrote: > > > What's the latest technology on previewing MSword stuff under FreeBSD? > > I haven't been keeping up, I'm afraid... I know we can currently handle > > postscript, pdf and acrobat, but word? Thanks. > > if u find one, let *all* of us know! I seem to recall a post in > one of the groups i read about the fact that some guy in germany hacked > the file format, and then removed it from his website "by request of > microsoft". > > if somebody could do a viewer, then somebody could do a word clone! Hmm. I think that I wrote about the guy in Germany. I don't have the URL at home, mail me at 'peterk@IAEhv.nl' if you want it. I don't know whether the link has been removed. The guy does state that he figured out a file format himself, which happens to look remarkably similar to the MS OLE 2.0 file format in general and the Word format in particular. (But only the raw text can be extracted, forget about things as tables and formatting.) I do know that the MS Word format was removed, by request of MS, from the "Wotsit File Format Collection" (http://www.wotsit.demon.co.uk). As a matter of fact, we do have the Word binairy file format at our office. It's pretty easy to come by, just send a mail to 'wordbff@microsoft.com', state your company, your position, the usual address stuff and why you want the format (better check http://www.microsoft.com/ first). After some time, an envelope with a contract arrives. You sign it, send it back, and again after some time the docs arrive per UPS next day delivery express service arrives (and you can put your signature on one of those cool Hitchhiker's Guide to the Galaxy lookalike gadgets). Great service, I must say. There are a few quirks: 1. You have to keep the information to your own company and you aren't allowed to publish it. So a source distribution probably is out of the question. A solution might be, that only a binary of a word-to-whatever converter would be available. 2. You're not allowed to make a word processor. 3. The docs suppose that you use the OLE 2.0 API to read the word files. We don't have docs on that, but a lot can be learnt from the documentation of the German guy. Moreover, it wouldn't be a bad idea to be able to read Access and Excel files as well, if there were an OLE 2.0 API in FreeBSD. - Peter -- Peter Korsten | peter@grendel.IAEhv.nl (UUCP) | peterk@IAEhv.nl C/C++/Perl/Java hacker From owner-freebsd-hackers Thu Mar 20 16:41:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA12983 for hackers-outgoing; Thu, 20 Mar 1997 16:41:35 -0800 (PST) Received: from grendel.IAEhv.nl (grendel.IAEhv.nl [194.151.72.15]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA12963 for ; Thu, 20 Mar 1997 16:41:17 -0800 (PST) Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id CAA00942; Fri, 21 Mar 1997 02:39:12 +0100 (CET) Message-ID: <19970321023908.47537@grendel.IAEhv.nl> Date: Fri, 21 Mar 1997 02:39:08 +0100 From: Peter Korsten To: Michael Smith Cc: Christoph Kukulies , freebsd-hackers@freefall.freebsd.org Subject: Re: background pixmap at boot time References: <199703200952.KAA03193@gilberto.physik.rwth-aachen.de> <199703201120.VAA05519@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.65e_p2,4-5,7,11,15,18,21-22 In-Reply-To: <199703201120.VAA05519@genesis.atrad.adelaide.edu.au>; from Michael Smith on Thu, Mar 20, 1997 at 09:50:58PM +1030 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael Smith shared with us: > Christoph Kukulies stands accused of saying: > > > > I may be wrong but wasn't there a facility to allow for a background > > picture to show at boot time or setup time (a la MS dark blue screen > > at Win95 setup or Win95 coudy sky)? The motif will be another question, > > though. > > ftp://gsoft.com.au/pub/2.2_splashkit.tar.gz > > But I only got one piece of feedback on it, so it's not on the 2.2 > CDrom. Well, it worked fine for me, as long as I didn't combine it with xdm. That messed up my vtty's pretty well. - Peter -- Peter Korsten | peter@grendel.IAEhv.nl (UUCP) | peterk@IAEhv.nl C/C++/Perl/Java hacker From owner-freebsd-hackers Thu Mar 20 17:05:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14049 for hackers-outgoing; Thu, 20 Mar 1997 17:05:56 -0800 (PST) Received: from jedi.asc-net.com ([204.254.69.20]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA14036; Thu, 20 Mar 1997 17:05:38 -0800 (PST) Received: from jedi.asc-net.com ([204.254.69.20]) by jedi.asc-net.com (8.8.5/8.8.5) with SMTP id RAA02740; Thu, 20 Mar 1997 17:10:55 -0800 (PST) Date: Thu, 20 Mar 1997 17:10:54 -0800 (PST) From: Marty Bower To: Michael Smith cc: John Prince , se@FreeBSD.ORG, spaz@u.washington.edu, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: MSWord docs... In-Reply-To: <199703202336.KAA09871@genesis.atrad.adelaide.edu.au> Message-ID: X-mailer: Pine 3.95q (FreeBSD 2.2) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From its help file: "Microsoft Word 97 has a different file format from earlier versions of Word." Alledgedly there is some form of converter for 6.0/95, enabling it to read 97 docs. 97 also has the option of saving in 6.0/95 format. MjB On Fri, 21 Mar 1997, Michael Smith wrote: > Word 7 is Word 6 with different icons, basically. The file format > and structure are the same. From owner-freebsd-hackers Thu Mar 20 17:08:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14225 for hackers-outgoing; Thu, 20 Mar 1997 17:08:37 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA14214; Thu, 20 Mar 1997 17:08:34 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA03680; Thu, 20 Mar 1997 17:08:22 -0800 (PST) To: "David Langford" cc: mallison@konnections.com (mike allison), FreeBSD-Chat@FreeBSD.ORG, FreeBSD-Hackers@FreeBSD.ORG, jtc@NetBSD.org Subject: Re: Free Systems Journal -- Philosophy In-reply-to: Your message of "Thu, 20 Mar 1997 12:48:10 -1000." <199703202248.MAA00219@caliban.dihelix.com> Date: Thu, 20 Mar 1997 17:08:22 -0800 Message-ID: <3677.858906502@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Jordan: could FreeBSD Inc./Walnut Creek contract out to > do the Newsletter you are thinking of? > For one thing it would allow you folks to concentrate on content as opposed > to layout. I'm not sure I follow you - I won't be doing layout; Walnut Creek CDROM has an art department for that. :-) We're just doing content. Jordan From owner-freebsd-hackers Thu Mar 20 17:14:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA14612 for hackers-outgoing; Thu, 20 Mar 1997 17:14:55 -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 RAA14606; Thu, 20 Mar 1997 17:14:43 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA10718; Fri, 21 Mar 1997 11:43:38 +1030 (CST) From: Michael Smith Message-Id: <199703210113.LAA10718@genesis.atrad.adelaide.edu.au> Subject: Re: MSWord docs... In-Reply-To: from Marty Bower at "Mar 20, 97 05:10:54 pm" To: marty@asc-net.com (Marty Bower) Date: Fri, 21 Mar 1997 11:43:38 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, johnp@lodgenet.com, se@FreeBSD.ORG, spaz@u.washington.edu, jkh@time.cdrom.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 Marty Bower stands accused of saying: > >From its help file: > > "Microsoft Word 97 has a different file format from earlier versions of > Word." > > Alledgedly there is some form of converter for 6.0/95, enabling it to read > 97 docs. 97 also has the option of saving in 6.0/95 format. That's Office 97, which wasn't what I was talking about. I was specifically referring to Word 7, which uses the same format as 6. Regardless, this is off topic. -- ]] 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 Mar 20 18:13:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA17654 for hackers-outgoing; Thu, 20 Mar 1997 18:13: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 SAA17645 for ; Thu, 20 Mar 1997 18:13:18 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA11202; Fri, 21 Mar 1997 12:42:29 +1030 (CST) From: Michael Smith Message-Id: <199703210212.MAA11202@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel Object Dependencies In-Reply-To: <3.0.32.19970320102225.00b1e8c0@etinc.com> from dennis at "Mar 20, 97 10:22:28 am" To: dennis@etinc.com (dennis) Date: Fri, 21 Mar 1997 12:42:29 +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 dennis stands accused of saying: > >> >> > >> >> filename.o: $S/i386/isa/filename.o > >> >> -cp $S/i386/isa/filename.o . > > > >Gotcha. Should it be 'cp' or 'ln -sf' do you think? A symlink will give > >you the dependancy behaviour automatically as the kernel dependancy rule > >will include the driver, and you save space too. > > Yes, thats how BSDI does it...although links dont let you test patched > modules as easily without having to overwrite the other one..... So you're saying you prefer 'cp'? So far you're the only consumer of this that I'm aware of, so your opinion gets to call the shots 8) > Thanks, I'll give it a try... Any luck? > Dennis -- ]] 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 Mar 20 18:37:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA18967 for hackers-outgoing; Thu, 20 Mar 1997 18:37:19 -0800 (PST) Received: from keystone.westminster.edu (fullermd@keystone.westminster.edu [204.171.15.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA18950; Thu, 20 Mar 1997 18:37:08 -0800 (PST) Received: (from fullermd@localhost) by keystone.westminster.edu (8.8.4/8.6.12) id VAA17722; Thu, 20 Mar 1997 21:36:59 -0500 (EST) Date: Thu, 20 Mar 1997 21:36:59 -0500 (EST) From: "Matthew D. Fuller" To: Andrew Perry cc: "Jordan K. Hubbard" , FreeBSD-chat@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Subject: Re: Free Systems Journal 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, 21 Mar 1997, Andrew Perry wrote: > just my 2 cents > maybe we should send articles to both, FreeBSD people will certainly > support the new newsletter (which I think is a great idea, will you be > sending them to australia? otherwise i can live with e-mail) but if we > have articles in the Free Systems Journal as well that may generate > interest in FreeBSD from non FreeBSD users. > > Andrew Perry > andrew@shoal.net.au For what it's worth, I have to heartily agree with this. FreeBSD articles can go nicely in a newsletter-type thing, and any new interest generated amoung x86 UNIX users is good. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |FreeBSD is good. FreeBSD is our friend. UNIX is our god.| *Micro$oft is bad. Micro$oft causes problems.* |MicroBSD??? I DON'T THINK SO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!| |"I hate quotes in signature files" :-} MAtthew Fuller| *fullermd@keystone.westminster.edu FreeBSD junkie* |http://keystone.westminster.edu/~fullermd Westminster College| *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Thu Mar 20 18:39:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19111 for hackers-outgoing; Thu, 20 Mar 1997 18:39:37 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19105; Thu, 20 Mar 1997 18:39:34 -0800 (PST) Received: from castle (root@ip207.konnections.com [192.41.71.207]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id TAA03266; Thu, 20 Mar 1997 19:39:00 -0700 (MST) Message-ID: <3333450A.93B36BA@konnections.com> Date: Fri, 21 Mar 1997 19:33:46 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: "Brian N. Handy" CC: "Jordan K. Hubbard" , FreeBSD-chat@freebsd.org, FreeBSD-hackers@freebsd.org Subject: Re: Free Systems Journal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian: Yes, the Free Systems Journal will be a REAL cover & postage magazine that the whole world can subscribe to. BUT, and this is important... - it won't JUST be BSD - it won't be evangelical, officially below the Free /Open systems line. - it CAN'T cater to all of the specific needs of the BSD community, I don't think. Although, again I'll let the community dictate that. What Jordan wants to do goes to the FreeBSD community. If Jordan can support that, then I think it is a good thing. Again, I don't think competition is a bad thing, but I also don't see it as competition. Also, I promised to give some kind of face time to the newsletter, even if it is just a "For More In Depth...see.." sorta thing. The risk doesn't lie within the community. It lies with those of us businesses who take these risks. If there is a market for the mag, and it's well written, there is, ergo, a market for the readership and, logically, market potential for advertisers. That's where it will succeed. A free newsletter is not competition in those senses. We do not compete for resources outside of input and some of that we can share. My cause isn't to win support for Jordan, I'm not quitting becuase he's in the fray, the market will support us all. But, I'm not going to try to kill or swap the newsletter, either, it's a healthy addition. In my humble opinion. -Mike Brian N. Handy wrote: > > >Anything I haven't thoght of? > > Any chance of combining this operation into one mighty empire that could > succeed, rather than two competing empires with the same goals? > > Also, is the Free Systems Journal destined to be a real, oh-my-gosh > Publication, with a cover and postage and I can subscribe to it, or > something else? (That didn't come across completely clear to me, but I > may have missed something.) Jordan has been caught vaguely off-guard, so > I'm not sure he's completely fleshed out his version of what he wants to > do. At any rate, I'd be more excited about supporting something that was > going to get some exposure outside of our little community here. I'm > almost afraid a newsletter of sorts would not see a lot of exposure > outside of the people already subscribed to freebsd-*, whereas something > that gets published and advertised and talked about and whoa here it is on > the MAGAZINE RACK and what's this {Free, Net, Open}BSD stuff about anyway? > > I guess what I'm saying is I strongly support the idea of a publication, > if that's what Mike is talking about. Jordan is a real capable salesman, > though, who I'm sure could make a newsletter focussed specifically on > FreeBSD succeed too. I'd rather see forces that mesh well together rather > than smaller competing services. > > Brian From owner-freebsd-hackers Thu Mar 20 18:46:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19445 for hackers-outgoing; Thu, 20 Mar 1997 18:46:39 -0800 (PST) Received: from keystone.westminster.edu (fullermd@keystone.westminster.edu [204.171.15.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19439 for ; Thu, 20 Mar 1997 18:46:33 -0800 (PST) Received: (from fullermd@localhost) by keystone.westminster.edu (8.8.4/8.6.12) id VAA17785; Thu, 20 Mar 1997 21:46:27 -0500 (EST) Date: Thu, 20 Mar 1997 21:46:25 -0500 (EST) From: "Matthew D. Fuller" cc: Benn Horton , hackers@freebsd.org Subject: Re: Modem driver needed. In-Reply-To: <199703202152.VAA23490@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 Thu, 20 Mar 1997, Brian Somers wrote: > > Hi > > > > I'm planning to use the ppp command in FreeBSD to handle an ISP > > connection, but first I need to get my modem up and running. Do you > > have a generic driver that I could use for my MRI 33.6kbps modem? > > You don't need a modem driver - the serial driver will suffice. > You can use ppp to do the whole lot, including AT commands. Refer > to /etc/ppp/ppp.*.sample for details. Yeah; there's no reason for a modem driver. You modem should just support the AT command set. There's an entry in the FAQ on the web site, I think it's http://www.freebsd.org/FAQ/FAQ151.html#151 that deals with setting up a dialin. There's a link off it the tells you how to set things up to send AT command directly to the modem. It contains the codes to set autoanswer, and you can just run ppp as the getty on that port in /etc/getty. I think. One problem I had is that my modem's non-standard, so I don't know the command to write the current config to the firmware, so I have to re-send the AT commands every time I bootup. The normal line is at&c1&d3&k3&q6 s0=1 &w the &w normall writes the config to the modem firmware, but mine doesn't so I have to take off those last 2 characters, and redo it every bootup. That's about the only problem I can see that you might have. If anyonw has an idea what my AT sequence to save to firmware is, I'd be grateful. I have a Compaq Presario 9000 series, with a 28.8 modem. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |FreeBSD is good. FreeBSD is our friend. UNIX is our god.| *Micro$oft is bad. Micro$oft causes problems.* |MicroBSD??? I DON'T THINK SO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!| |"I hate quotes in signature files" :-} MAtthew Fuller| *fullermd@keystone.westminster.edu FreeBSD junkie* |http://keystone.westminster.edu/~fullermd Westminster College| *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Thu Mar 20 18:50:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19615 for hackers-outgoing; Thu, 20 Mar 1997 18: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 SAA19606 for ; Thu, 20 Mar 1997 18:50:48 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04779; Thu, 20 Mar 1997 21:50:12 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 20 Mar 1997 21: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 TAA01386; Thu, 20 Mar 1997 19:49:47 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id TAA00572; Thu, 20 Mar 1997 19:55:11 -0500 (EST) Date: Thu, 20 Mar 1997 19:55:11 -0500 (EST) From: Thomas David Rivers Message-Id: <199703210055.TAA00572@lakes.water.net> To: ponds!village.org!imp, ponds!lambert.org!terry Subject: Re: Barb problem, FOUND Cc: ponds!freebsd.org!hackers, ponds!wgold.demon.co.uk!james Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > : Just because a particular compiler is full of bugs doesn't mean that a > > : construct allowed by the language spec is dubious. No way. > > > > I misspoke myself. There are several compilers that don't handle this > > construct correctly. They generally don't whine about it, but they > > generally do generate horrible code for this case. We saw a few years > > ago that by removing the inline virtuals we had binaries that were > > 500k! smaller. We also found with OI that lots of compilers had > > subtle bugs with inline virtuals. > > > > Given all the problems that multiple compilers have implementing it > > effectively, I think that it is as least unwise to use the construct. > > In my book, that makes it dubious, but others will have a different > > opinion. > > I remember when people were applying the same logic to dynamic scoping > of stack variables: > > if( foo) { > int my_dynamic_i; > > ... > } > > Use of the register keyword on Lattice (later SASC) compilers: > > fum() > { > register int a, b, c, d, e, f; /* all the registers...*/ > register int q; /* XXX reuses register 'a'!!!*/ > } Hey! As manager of the SAS/C compilers I object to that :-) :-) [We like to keep our skeletons in the closet, thank you.] Of course; you likely mean the ooolllddd ones - not the spiffy new ones we have now :-) :-) We still use and actively maintain those compilers - we just don't sell them to the public. The SAS system on PC, mainframe (370 - MVS and VMS), MAC (68K and PowerPC) is built with compilers that owe their existence to that offering. [We still 'maintain' the amiga compiler via updates on-the-net. But, you can't buy that one any more either.] > > And use of bit fields, unsigned values. and enumerated types (which > didn't work in so many odd ways that it's not worth going into). > > Oh yeah: don't use sbrk() because you can't brk() back to the OS... > > 8-P. > > The argument is without merit: if a compiler is buggy, it should be > fixed, or the vendor should be forced out of business by word of mouth. My point here is that compiler vendors often do fix things. Sometimes, even before they are forced out of business :-) :-) So, you'd due well to report problems and #ifdef around them until they are repaired. - Dave Rivers - From owner-freebsd-hackers Thu Mar 20 18:50:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19622 for hackers-outgoing; Thu, 20 Mar 1997 18:50:53 -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 SAA19605 for ; Thu, 20 Mar 1997 18:50:48 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04810; Thu, 20 Mar 1997 21:50:15 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 20 Mar 1997 21: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 VAA02839 for ; Thu, 20 Mar 1997 21:26:32 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id VAA00238 for freebsd-hackers@freebsd.org; Thu, 20 Mar 1997 21:31:56 -0500 (EST) Date: Thu, 20 Mar 1997 21:31:56 -0500 (EST) From: Thomas David Rivers Message-Id: <199703210231.VAA00238@lakes.water.net> To: ponds!freebsd.org!freebsd-hackers Subject: Some not-too-good news about aha2940 and 2.1.7.1-RELEASE Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I anxiously got a 2.1.7.1-RELEASE kernel built (by grabbing the sys sources and doing a config/make) to test out the aha2940 improvements. Unfortunately; on my two particular problems, things actually got worse. My "write to the SCSI tape" (recall, this is a wangtek 5150ES - and when I get to the end of the write and the tape is rewinding, I run into trouble) - actually locked up the entire SCSI bus. 2.1.7 only locked up the one process. My only recourse was to reboot. The machine would answer PINGs, but you couldn't telnet or rlogin because there was no disk access. I imagine the first swap would have panic'd. Here's the messages from the console window (which I happened to have up at the time): sd0(ahc0:0:0): SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 SEQADDR == 0x42 st0(ahc0:2:0): abort message in message buffer sd0(ahc0:0:0): SCB 0x1 timedout while recovery in progress Now; as to the second problem. Recall that I did not set up a narrow negotiation for my second SCSI drive (an older micropolis drive.) This worked fine for 2.1.6.1. However, with 2.1.7, I have to disable (in the Adaptec BIOS utilities) WIDE negotiation on this drive or FreeBSD doesn't see it (an aborted command is all the probe prints.) Again; this is new with 2.1.7.xxx For info - I've appended the front part of the probe (as taken from dmesg). So - it looks like things got worse for my particular situation in 2.1.7.1.... - Dave Rivers - FreeBSD 2.1.7.1-RELEASE #0: Thu Mar 20 20:22:54 EST 1997 rivers@lakes.water.net:/usr/src/sys-2.1.7.1/compile/LAKES CPU: 133-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30457856 (29744K bytes) Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 ahc0 rev 0 int a irq 15 on pci0:17 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "HP C3323-300 4242" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1003MB (2056008 512 byte sectors) (ahc0:1:0): "MICROP 1548-15MZ1077802 HZ2P" type 0 fixed SCSI 1 sd1(ahc0:1:0): Direct-Access 1635MB (3349512 512 byte sectors) (ahc0:2:0): "WANGTEK 5150ES SCSI FA23 08" type 1 removable SCSI 1 st0(ahc0:2:0): Sequential-Access drive offline (ahc0:3:0): "NEC CD-ROM DRIVE:400 1.0" type 5 removable SCSI 2 cd0(ahc0:3:0): CD-ROM cd present.[217422 x 2048 byte records] vga0 rev 211 int a irq 11 on pci0:20 Probing for devices on the ISA bus: From owner-freebsd-hackers Thu Mar 20 18:56:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA19886 for hackers-outgoing; Thu, 20 Mar 1997 18:56:01 -0800 (PST) Received: from keystone.westminster.edu (fullermd@keystone.westminster.edu [204.171.15.203]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19852; Thu, 20 Mar 1997 18:55:56 -0800 (PST) Received: (from fullermd@localhost) by keystone.westminster.edu (8.8.4/8.6.12) id VAA17802; Thu, 20 Mar 1997 21:55:34 -0500 (EST) Date: Thu, 20 Mar 1997 21:55:34 -0500 (EST) From: "Matthew D. Fuller" To: mike allison cc: FreeBSD-Chat@freebsd.org, FreeBSD-Hackers@freebsd.org, jtc@NetBSD.org Subject: Re: Free Systems Journal -- Philosophy In-Reply-To: <33330802.3D353BFD@konnections.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, 21 Mar 1997, mike allison wrote: > Hello again: > > While we're a bit busy with this conversation about newsletters and > jounals, I just wanted to stand up and lay out my philosophy in regards > to what Free Systems Journal should be. > > First of all it has to be an organ (sorry bevis) for the issues that the > Free systems community faces. That is the ENTIRE community. Let no one > think that this community belongs any more to the Linux users than it > does to the FreeDOS or Minix users. We're all in this together. We > don't need to agree but we can't deal anyone out. I said my original > desire for this sprang from Linux Journal's continued open disregard of > other systems. That is not a negative stance for LJ, on the contrary, > it never claimed to be anything but. On the other hand, there has > always been a need for coverage of other systems in a responsive manner, > not as an aside to some greater issue. I assure you if LJ paid > attention to other systems, they wouldn't do it justice. I myself > wonder how it can be done, but we'll find a pole to revolve around and > then expand or contract based on community needs. > > I don't think any one person, or group, is more qualified to contribute > than another. A newbie might have just as pertinent a concern as anyone > else, and just as elegant a solution. There are many more newbies out > there than gurus. Unlike many of the people out there, a lot of us > don't have a guru to defer to. (Except the newsgroups, and we don't > always know who's answering the mail there.) > > I want this endeavor to become something useful to all of us, that we > can all have a stake in and be proud of. If the NetBSD folks do > something cool, or pull off a major installation, like say, to the > Justice Department, we should all be proud and pull a little closer. > > Our similarities are our strength our differences merely distractions. > Our goal should be to become smarter as individuals and to make > computing a transparent part of our lives (both from a control sense, > and a cost sense). I don't mind having to pay for good software, but I > do mind not being able to chose and bad software eventually becoming the > ONLY software. > > UNIX (Sorry to whomever owns the trademark this week) was always open in > this sense. It was the great equalizer. It has again become that great > equalizer. It has motivated people to create Free systems and that > includes free versions of some of the most popular, most expensive and > most controlled personal computing software. > > If you flood my office with contributions, I'll publish what I can. > What's really good I'll pass on to others to publish. There's no way > that we'll sit on a valuable article just to pump some imagined value > out of it. > > I'm open to any suggestions about how to provide this service. I'm a > book guy and magazines are new to us. But I'm become zealous about this > and I'm determined to see it through. > > Your thoughts are appreciated. I'm not a real member of these lists, so > please let me know what the right procedure is for joining. > > Thanks, > > -Mike Allison BRAVO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |FreeBSD is good. FreeBSD is our friend. UNIX is our god.| *Micro$oft is bad. Micro$oft causes problems.* |MicroBSD??? I DON'T THINK SO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!| |"I hate quotes in signature files" :-} MAtthew Fuller| *fullermd@keystone.westminster.edu FreeBSD junkie* |http://keystone.westminster.edu/~fullermd Westminster College| *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From owner-freebsd-hackers Thu Mar 20 19:02:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA20121 for hackers-outgoing; Thu, 20 Mar 1997 19:02:26 -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 TAA20098 for ; Thu, 20 Mar 1997 19:02:04 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA13198; Fri, 21 Mar 1997 02:24:14 GMT Message-Id: <199703210224.CAA13198@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org cc: Mike Pritchard Subject: Re: old BSD manpages (Re: cvs commit: www/data docs.sgml) In-reply-to: Your message of "Thu, 20 Mar 1997 22:22:04 +0100." <199703202122.WAA00646@campa.panke.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 02:24:14 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mike Pritchard writes: > >Wolfram Schneider wrote: > >> > >> wosch 97/03/16 16:04:54 > >> > >> Modified: data docs.sgml > >> Log: > >> Add link to a new man page script. > > > >What an understatement! Wolfram's new script has man pages > >for EVERY FreeBSD release past and present. Good job! > > Not all releases. I'm still seeking the manual pages for NET/1, > 386BSD 0.0, FreeBSD 1.0, and FreeBSD 1.1. > > Wolfram How about the release of FreeBSD-1.1-GAMMA (not too big) ? From: jkh@smspde.ilo.dec.com (Jordan Hubbard) Newsgroups: comp.os.386bsd.announce Subject: FreeBSD 1.1 GAMMA is released Followup-To: poster Date: 20 Apr 1994 10:32:23 -0700 Organization: Digital Equipment Corporation, Galway Ireland Distribution: world NNTP-Posting-Host: agate.berkeley.edu After some delay, the FreeBSD group is very pleased to announce the release of FreeBSD 1.1 GAMMA! Q. WHAT IS 1.1 GAMMA? A. FreeBSD 1.1 GAMMA represents the BETA release with a small (but important) number of bug fixes and enhanced documentation. We have taken great pains to focus only on bug fixing so as not to destabilize what people have been running from the 1.1 BETA release. GAMMA is also the `Release Candidate', meaning that these are the bits which we'll be sending out as FreeBSD 1.1 RELEASE, modulo any final problems that are found and fixed. Q. WHY SHOULD I RUN GAMMA AND NOT SIMPLY WAIT FOR 1.1 RELEASE? A. Because you're a kind and thoughtful person and you're keen to help us do one last little bit of release testing! :-) Seriously speaking, it is very important that people help us shake these bits out ASAP since we're only going to take a week between GAMMA and RELEASE, our emphasis being on getting the RELEASE bits out as soon as possible. In order to avoid unduly penalizing folks who install GAMMA, we will also be providing BOTH BINARY AND SOURCE UPGRADES for 1.1 RELEASE! Sorry to shout, but this is the first time we've done this and I just thought I'd make sure it was known. So, if you install GAMMA now then you can look forward to two small tar files (binary and source), an update script and a README file that will make going from GAMMA to RELEASE quick and easy. Go for it! :) Q. HOW DO I UPGRADE FROM 1.0.2? A. Given that 1.1 represents a MAJOR upgrade over 1.0, we cannot provide a binary upgrade strategy (it would be larger than the entire release!) and must regrettably make the same stipulation that the "big boys" do, namely, `please back up your user files and reinstall.' That said, if you've got space for the _source distribution_ then you can skip grabbing the 1.1 binary distribution altogether and simply use the upgrade script provided to fully upgrade to 1.1 from source. This is the easiest way of going about it if you've got the disk space to spare. Q. WHAT ABOUT THE LEGAL PROBLEMS I HEARD ABOUT? A. Thanks to an exceptional willingness on USL's part to negotiate on this (when they could have simply said "No" and left it at that), we are now able to do this 1.1 Release. NOTE: ** FreeBSD 1.1 will be the LAST Net/2 based release of FreeBSD **. Subsequent releases of FreeBSD will based on the BSD 4.4 LITE code and all future releases of FreeBSD will be completely `unencumbered'. The terms of this are mandated by the recent UCB/USL settlement and are non-negotiable. This is not to say that FreeBSD users will be due for an enormous shock as their favorite OS mutates beyond all recognition, far from it. We will be approaching the port with great conservatism, taking care to finely balance the needs of legality (4.4 lite) and stability (unencumbered portions of the old code base), and we are very optimistic about FreeBSD's future as a stable, high performance operating system with all the features (and Internet support) that people have come to expect from us. Folks who are interested in knowing more about (or, even better, participating in) this process are encouraged to write to us at: freebsd-hackers@freefall.cdrom.com Q. SOUNDS GREAT, WHERE DO I GET IT? A. As always, you may grab the release from: freebsd.cdrom.com:~ftp/pub/FreeBSD/FreeBSD-1.1-GAMMA However, I'd like to STRONGLY urge you to look on one of the mirror sites first! Poor little freebsd.cdrom.com is sitting at the end of a T1 line and tends to SWAMP when too many folks beat up on it at once! The FreeBSD release is being mirrored at the following locations, and if you don't see the GAMMA bits there yet, please allow some time to elapse for the mirror to properly grab it and try again. FREEBSD MIRROR SITES -------------------- Austria ftp.tu-graz.ac.at:/pub/FreeBSD Finland ftp.funet.fi:/pub/unix/FreeBSD France ftp.ibp.fr:/pub/FreeBSD Germany ftp.informatik.tu-muenchen.de:/pub/comp/os/bsd/FreeBSD ftp.uni-duisburg.de:/pub/unix/FreeBSD gil.physik.rwth-aachen.de:/pub/FreeBSD Hong Kong ftp.cs.cuhk.hk:/pub/FreeBSD Netherlands ftp.nl.net:/pub/os/FreeBSD Russia ftp.kiae.su:/FreeBSD UK src.doc.ic.ac.uk:/packages/FreeBSD USA ftp.dsu.edu:/pub/FreeBSD You will also want to grab a copy of the new FAQ, the most up-to-date copy of which is always in: freebsd.cdrom.com:~ftp/pub/FreeBSD/FAQ This contains very useful information about our mailing lists, hardware supported and a host of other things. As always, we hope you enjoy FreeBSD as much as we have enjoyed producing it! The FreeBSD Team From owner-freebsd-hackers Thu Mar 20 19:03:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA20167 for hackers-outgoing; Thu, 20 Mar 1997 19:03:00 -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 TAA20162 for ; Thu, 20 Mar 1997 19:02:58 -0800 (PST) Received: from awfulhak.demon.co.uk by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0w7uai-0008t4C; Thu, 20 Mar 97 19:02 PST Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA12995; Fri, 21 Mar 1997 02:16:55 GMT Message-Id: <199703210216.CAA12995@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "James E. Housley" cc: freebsd-hackers@freebsd.org Subject: Re: tun0/user ppp lockups? In-reply-to: Your message of "Thu, 20 Mar 1997 18:11:20 EST." <199703202311.SAA06982@pr-comm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 02:16:55 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have been having similar problems. I changed to lines yesterday in > ppp.conf and things seem better. Haven't run long enough to be sure. > In 2.1.x it was recomended to disable and deny lqr (Line Quality). > I noticed that 2.2.x enables that by default. > > enable lqr > accept lqr Hmm. $ cd /usr/src/etc/ppp $ uname -a FreeBSD shift.lan.awfulhak.org 2.2-RELEASE FreeBSD 2.2-RELEASE #0: Mon Mar 17 20:40:56 GMT 1997 brian@shift.lan.awfulhak.org:/usr/src/sys/compile/SHIFT i386 $ fgrep lqr ppp.conf* ppp.conf.sample: disable lqr ppp.conf.sample: deny lqr ppp.conf.server.sample: disable lqr You should disable this if you're playing ppp client. The ppp.conf.sample in -current has an example of a client-server setup that uses lqr so that the server can tell when the other side has died. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Mar 20 19:10:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA20584 for hackers-outgoing; Thu, 20 Mar 1997 19:10:41 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA20579; Thu, 20 Mar 1997 19:10:38 -0800 (PST) Received: from castle (root@ip207.konnections.com [192.41.71.207]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id UAA03666; Thu, 20 Mar 1997 20:08:54 -0700 (MST) Message-ID: <33334C0C.2B73BEFB@konnections.com> Date: Fri, 21 Mar 1997 20:03:40 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: Tom Torrance at home CC: FreeBSD-Chat@FreeBSD.org, FreeBSD-Hackers@FreeBSD.org Subject: Re: new freeunix publication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Tom: Initially, our rates are: - Continental US -- $25 (USD) - Alaska, Hawaii, Canada -- $27 (USD) (Canada may be less if I can swing it, or at least in Canadian funds... give me a few weeks.) - Rest of the Americas -- $35 (USD) - Worldwide -- $37 (USD) All must be drawn on US funds, unless I fix Canada. These rates are fixed until we go to press in May with issue 1. After that they may change. If they change, they'll go up probably. If they go down, I'll reinburse the diff. It is all affected by advertising and I'm going to give it a while before I arrive at "FINAL" figures. Anyone who subscribes before 1 May will lock into these rates for at least 1 year. I'm loyal enough to think about that come next year too. If you want to subscribe now, when we receive payment, we'll enter the subscriptions, but keep the check or money order on file until the 1st issue ships. That way, you're not paying for the product until it ships. You make payment (Check or Money Order [I'm probably the last person who prefers a personal check, at least initially]) to: Burning Eagle Books And mail to: Free Systems Journal C/O Burning Eagle Books 1175 East Canyon Rd #17 Ogden, UT 84404-5972 ATTN: FSJ/Subs Bottom line: If the rates go up, it'll be 2 or 3 dollars a year. So, it's not the end of the world. But you'll get an issue when it comes out, not when you remember to ask, after you see it on your neighbor's desk. Thanks, -Mike Tom Torrance at home wrote: > > Sounds interesting. What are the subscription rates set at? > > Regards, > Tom From owner-freebsd-hackers Thu Mar 20 21:14:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA26566 for hackers-outgoing; Thu, 20 Mar 1997 21:14:59 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26560; Thu, 20 Mar 1997 21:14:56 -0800 (PST) Received: from castle (root@ip207.konnections.com [192.41.71.207]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id WAA05611; Thu, 20 Mar 1997 22:14:16 -0700 (MST) Message-ID: <3333696D.58323B7B@konnections.com> Date: Fri, 21 Mar 1997 22:09:02 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: "Daniel O'Callaghan" CC: FreeBSD-Chat@FreeBSD.org, FreeBSD-Hackers@FreeBSD.org Subject: Re: new freeunix publication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Danny: We have a retail book sales site and I discussed this very issue tonight in theory. I don't think it's a problem, but let me talk nuts and bolts... probably change the subscription agent....you'd still have to mail the # to us, so there's not a security problem, not like we're pressed for time, yet. I'll get an answer tommorrow, post it to you and any sites... Thanks, Danny. -Mike Daniel O'Callaghan wrote: > > On Fri, 21 Mar 1997, mike allison wrote: > > > All must be drawn on US funds, unless I fix Canada. > > Any chance of credit card? Organising a foreign currency draft > is a real pain. I'd be happy to pay the extra 4%. > > Danny From owner-freebsd-hackers Thu Mar 20 21:49:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA28022 for hackers-outgoing; Thu, 20 Mar 1997 21:49:20 -0800 (PST) Received: from jazz.snu.ac.kr (jazz.snu.ac.kr [147.46.102.36]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA28013 for ; Thu, 20 Mar 1997 21:49:15 -0800 (PST) Received: (from junker@localhost) by jazz.snu.ac.kr (8.8.5/8.8.4-procmail) id OAA01259 for freebsd-hackers@freebsd.org; Fri, 21 Mar 1997 14:43:42 +0900 (KST) From: Choi Jun Ho Message-Id: <199703210543.OAA01259@jazz.snu.ac.kr> Subject: Re: (Fwd) X11 under 2.2-RELEASE? To: freebsd-hackers@freebsd.org Date: Fri, 21 Mar 1997 14:43:42 +0900 (KST) In-Reply-To: <406.858862428@time.cdrom.com> from "Jordan K. Hubbard" at Mar 20, 97 04:53:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk $)C Jordan K. Hubbard4T@G @L@| FmAv?!<-(wrote): :: :: I'm copying the files over again now (Rich - sorry for the false :: alarm). By the time you read this, what's in :: ftp://ftp.freebsd.org/pub/FreeBSD/2.2-RELEASE/XF8632 should be :: entirely different. :: :: Jordan :: Oh, there is no directory of XFree86 3.2... moderato:~% ftp ftp.freebsd.org Connected to wcarchive.cdrom.com. 220 wcarchive.cdrom.com FTP server (Version DG-1.0.101 Mon Feb 3 23:58:27 PST 1997) ready. Name (ftp.freebsd.org:junker): ftp 331 Guest login ok, send your complete e-mail address as password. Password: 230-Welcome to wcarchive - home ftp site for Walnut Creek CDROM. ... Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /pub/FreeBSD/2.2-RELEASE/XF8632 550 /pub/FreeBSD/2.2-RELEASE/XF8632: No such file or directory. ftp> What happens to that?(now Thu Mar 20 14:46:05 KST 1997) (KST= KR +3733+12658 Asia/Seoul) -- --------------------------------------------------------------^^--- Judgement Uninfected Naked Kind & Executive Ranger - J U N K E R from KONAMI 1990 "SD-Snatcher" in MSX2 Choi Jun Ho http://jazz.snu.ac.kr/~junker Distributed Computing System Lab, CS Dept., Seoul National Univ. From owner-freebsd-hackers Thu Mar 20 22:29:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA29366 for hackers-outgoing; Thu, 20 Mar 1997 22:29:54 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA29324; Thu, 20 Mar 1997 22:28:36 -0800 (PST) From: Mike Pritchard Message-Id: <199703210628.WAA29324@freefall.freebsd.org> Subject: Re: old BSD manpages (Re: cvs commit: www/data docs.sgml) To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Thu, 20 Mar 1997 22:28:35 -0800 (PST) Cc: hackers@FreeBSD.org In-Reply-To: <199703210224.CAA13198@awfulhak.demon.co.uk> from "Brian Somers" at Mar 21, 97 02:24:14 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brian Somers wrote: > > GAMMA is also the `Release Candidate', meaning that these are the bits > which we'll be sending out as FreeBSD 1.1 RELEASE, modulo any final > problems that are found and fixed. Can someone tell me what all of the pre-FreeBSD 2.0 releases were? There are a few man pages that reference them, but I've never been quite sure of the versions, so I haven't added them to the .Fx macro. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-hackers Thu Mar 20 23:14:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA01345 for hackers-outgoing; Thu, 20 Mar 1997 23:14:31 -0800 (PST) Received: from hamby1 (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA01335 for ; Thu, 20 Mar 1997 23:14:27 -0800 (PST) Received: (from jehamby@localhost) by hamby1 (SMI-8.6/SMI-SVR4) id XAA00804; Thu, 20 Mar 1997 23:10:59 -0800 Date: Thu, 20 Mar 1997 23:10:59 -0800 From: jehamby@lightside.com (Jake Hamby) Message-Id: <199703210710.XAA00804@hamby1> To: ponds!rivers@dg-rtp.dg.com, terry@lambert.org Subject: Re: Barb problem, FOUND Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: mW5W8RPrC5CX67PmhoXMlw== Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From ponds!rivers@dg-rtp.dg.com Thu Mar 20 21:51:25 1997 > Date: Thu, 20 Mar 1997 19:55:11 -0500 (EST) > From: Thomas David Rivers > To: ponds!village.org!imp@ucbvax.Berkeley.EDU, ponds!lambert.org!terry@ucbvax.Berkeley.EDU > Subject: Re: Barb problem, FOUND > Cc: ponds!freebsd.org!hackers@ucbvax.Berkeley.EDU, ponds!wgold.demon.co.uk!james@ucbvax.Berkeley.EDU > X-Loop: FreeBSD.org > X-UIDL: e5e3cfd6091cbeac8d85ac00f2302abc Wow, your mailer did SOMETHING funky to the return addresses (UUCP gremlins?)! :) > Hey! As manager of the SAS/C compilers I object to that :-) :-) > [We like to keep our skeletons in the closet, thank you.] > > > Of course; you likely mean the ooolllddd ones - not the spiffy new > ones we have now :-) :-) We still use and actively maintain > those compilers - we just don't sell them to the public. The SAS > system on PC, mainframe (370 - MVS and VMS), MAC (68K and PowerPC) > is built with compilers that owe their existence to that offering. > [We still 'maintain' the amiga compiler via updates on-the-net. But, > you can't buy that one any more either.] Funny, I bought SAS/C 6.5 for Amiga a few years back, through the SAS book department. Are you sure they've stopped selling it? Don't know what I'm gonna do with it now, but it's nice to have around (the manuals are a great reference for libc stuff, at any rate). > My point here is that compiler vendors often do fix things. Sometimes, > even before they are forced out of business :-) :-) So, you'd due > well to report problems and #ifdef around them until they are repaired. Agreed. -- Jake From owner-freebsd-hackers Thu Mar 20 23:47:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA02642 for hackers-outgoing; Thu, 20 Mar 1997 23:47:37 -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 XAA02637 for ; Thu, 20 Mar 1997 23:47:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id XAA07473; Thu, 20 Mar 1997 23:48:56 -0800 (PST) Message-Id: <199703210748.XAA07473@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Mike Pritchard cc: brian@awfulhak.demon.co.uk (Brian Somers), hackers@FreeBSD.org Subject: Re: old BSD manpages (Re: cvs commit: www/data docs.sgml) In-reply-to: Your message of "Thu, 20 Mar 1997 22:28:35 PST." <199703210628.WAA29324@freefall.freebsd.org> From: David Greenman Reply-To: dg@root.com Date: Thu, 20 Mar 1997 23:48:56 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Brian Somers wrote: >> >> GAMMA is also the `Release Candidate', meaning that these are the bits >> which we'll be sending out as FreeBSD 1.1 RELEASE, modulo any final >> problems that are found and fixed. > >Can someone tell me what all of the pre-FreeBSD 2.0 releases were? >There are a few man pages that reference them, but I've never been >quite sure of the versions, so I haven't added them to the .Fx macro. 1.0, 1.1, 1.1.5, and 1.1.5.1. Only 1.0 and 1.1 were put on CDROM; 1.1.5.x was released only via the Internet due to legal reasons. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Mar 21 01:47:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA06989 for hackers-outgoing; Fri, 21 Mar 1997 01:47:01 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA06981 for ; Fri, 21 Mar 1997 01:46:58 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id BAA00758 for ; Fri, 21 Mar 1997 01:46:57 -0800 (PST) Message-Id: <199703210946.BAA00758@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: loadable modules and allocating a big memory segment? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 01:46:57 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am thinking about loadable sound drivers and video drivers which require continuous physical memory. In the case of the video drivers we may want to allocate as much as 2 megabytes of physical memory. Does current support such a memory allocation scheme? Tnks, Amancio From owner-freebsd-hackers Fri Mar 21 02:13:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA07960 for hackers-outgoing; Fri, 21 Mar 1997 02:13:56 -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 CAA07953 for ; Fri, 21 Mar 1997 02:13:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id CAA07938; Fri, 21 Mar 1997 02:15:17 -0800 (PST) Message-Id: <199703211015.CAA07938@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Amancio Hasty cc: hackers@FreeBSD.ORG Subject: Re: loadable modules and allocating a big memory segment? In-reply-to: Your message of "Fri, 21 Mar 1997 01:46:57 PST." <199703210946.BAA00758@rah.star-gate.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 21 Mar 1997 02:15:16 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I am thinking about loadable sound drivers and video drivers which require >continuous physical memory. > >In the case of the video drivers we may want to allocate as much as >2 megabytes of physical memory. Does current support such a memory >allocation scheme? Memory fragmentation is always a potential problem after the system has been up and running awhile, but John has made some changes recently that increase the likelihood that a chunk can be found. ...so it should work most of the time. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Mar 21 02:20:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA08222 for hackers-outgoing; Fri, 21 Mar 1997 02:20:17 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA08215 for ; Fri, 21 Mar 1997 02:20:11 -0800 (PST) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id KAA20207; Fri, 21 Mar 1997 10:12:29 GMT To: Brian Somers Cc: faried nawaz , Jason Fesler , hackers@freebsd.org Subject: Re: tun0/user ppp lockups? References: <199703202103.VAA20824@awfulhak.demon.co.uk> From: Doug Rabson Date: 21 Mar 1997 10:12:21 +0000 In-Reply-To: Brian Somers's message of Thu, 20 Mar 1997 21:03:15 +0000 Message-ID: Lines: 22 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Somers writes: > > Does a manual SIGSEGV kill it ? If so, can you tell me what the > stack trace looks like ? Also, is this on a direct connection > (null-modem) or through a modem ? When I had problems with ppp in the past, I compiled it debug and ran it as normal, then connected a gdb to it using attach and left it. If it freaked out, I could debug it properly with symbols. I have been using mpd recently with some success. I had a couple of problems with it which I will try to feed back to the author this weekend but it seems basically sound. The code quality seems much better than ppp but it does miss out on a couple of features (term, packet filtering, aliasing). If you need them, you can always use ipfw, I guess. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Mar 21 02:28:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA08500 for hackers-outgoing; Fri, 21 Mar 1997 02:28:21 -0800 (PST) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA08475; Fri, 21 Mar 1997 02:28:10 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA15309; Fri, 21 Mar 1997 10:25:56 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 21 Mar 1997 10:28:43 +0000 Received: from tees.elsevier.co.uk (tees.elsevier.co.uk [193.131.197.60]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA14999; Fri, 21 Mar 1997 10:28:39 GMT Received: (from dpr@localhost) by tees.elsevier.co.uk (8.8.3/8.8.3) id KAA01520; Fri, 21 Mar 1997 10:28:38 GMT To: mike allison Cc: Tom Torrance at home , FreeBSD-Chat@FreeBSD.org, FreeBSD-Hackers@FreeBSD.org Subject: Re: new freeunix publication References: <33334C0C.2B73BEFB@konnections.com> From: Paul Richards Date: 21 Mar 1997 10:28:36 +0000 In-Reply-To: mike allison's message of Fri, 21 Mar 1997 20:03:40 -0700 Message-ID: <57afnxwncb.fsf@tees.elsevier.co.uk> Lines: 18 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk mike allison writes: > Initially, our rates are: > > - Worldwide -- $37 (USD) > > All must be drawn on US funds, unless I fix Canada. > You make payment (Check or Money Order [I'm probably the last person who > prefers a personal check, at least initially]) to: Is there any other way to pay, like VISA? It'd cost me almost as much to raise a money order as it would to pay for the subscription ! -- Dr Paul Richards. [p.richards@elsevier.co.uk] Originative Solutions Ltd. [paul@originat.demon.co.uk] Phone: 0370 462071 (Mobile), +44 (0)1865 843155 (Elsevier) From owner-freebsd-hackers Fri Mar 21 03:14:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA09916 for hackers-outgoing; Fri, 21 Mar 1997 03:14:32 -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 DAA09905 for ; Fri, 21 Mar 1997 03:14:07 -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 DAA24312 for ; Fri, 21 Mar 1997 03:14:00 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA094094658; Fri, 21 Mar 1997 16:44:18 +0500 Message-Id: <199703211144.AA094094658@fakir.india.hp.com> To: freebsd-hackers@freebsd.org Subject: SDDISKSORT Date: Fri, 21 Mar 1997 16:44:18 +0500 From: "A JOSEPH KOSHY" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I noticed that by default we never turn on disk sorting for SCSI drives. What would be the reason for doing so. I understand that if a drive supports command queueing then presorting the request list may not be effective. However not all hardware support command queueing. Is not sorting the disk I/Os beneficial for all SCSI drives? Koshy My Personal Opinions Only From owner-freebsd-hackers Fri Mar 21 03:23:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA10266 for hackers-outgoing; Fri, 21 Mar 1997 03:23:10 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA10259 for ; Fri, 21 Mar 1997 03:23:06 -0800 (PST) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id LAA20347; Fri, 21 Mar 1997 11:13:53 GMT To: Terry Lambert Cc: msmith@atrad.adelaide.edu.au (Michael Smith), bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions References: <199703201814.LAA13973@phaeton.artisoft.com> From: Doug Rabson Date: 21 Mar 1997 11:13:49 +0000 In-Reply-To: Terry Lambert's message of Thu, 20 Mar 1997 11:14:04 -0700 (MST) Message-ID: Lines: 74 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > > That's the one. There's also quite a lot of code whose behaviour depends > > on various other options, but it would be practical in the short term > > to just compile several times with the sensible combinations of the > > various options and produce different modules. (I am thinking here > > fe. of NFS_NOSERVER) > > The NFS_NOSERVER code changes the way the lease VOP's operate, not > because the code should be condition, but because the code is badly > integrated. > > The registration of lease management mechanisms should take place > for all VFS consumers, not just NFS. This is a generic issue with > not being able to register a set of event callback entry points for > a module. The *real* problem here is that the NFS server wants to > register event handlers, but the server and the client code are in > the same module space. This is really a source organization issue. Interesting idea. Any chance of a design for such a system? > > I could see a number of useful events that a VFS consumer at the > system call level would want to register. For instance, directory > modification events would probably be useful for a file browser > application to monitor. Directory modification events would be pretty useful for the NFS server as well to extend the useful lifetime of NFS client cookies. The event would need to supply more information than just 'changed' since the seek values are still valid unless the directory was compacted. > [snip] > > > > You are still not listening 8); I have just said "when you discover you > > need the blocks, you can no longer read them because your load source > > has gone." This is an issue for the period from when control is > > transferred to the loaded kernel from the linker until a filesystem is > > mounted, and thus all the code that could possibly be required over > > that interval must be present. > > Heh. You aren't listening to me... you don't get rid of the boot-loader > code. If you don't get rid of it, you can still use it. > > It's like the BIOS based boot being able to use the INT 13 redirector > supplied by OnTrack, when you boot from an OnTrack drive. As long as > you don't override it, it's still there. Actually, I expect the boot loader will have to be quite simple. To be practical, even with a 3 stage bootstrap the third stage will have to fit into 64k since it will need to use INT 13 for its disk access and our tools can't (and shouldn't) generate anything except tiny model programs. As a result, it will have severely truncated read-only file system support (see libsa from NetBSD). This is sufficient to load up the kernel. The boot will be discarded as soon as the kernel is entered. I was reading through libsa and our boot code yesterday and I believe that a 3 stage bootstrap for biosboot would be pretty easy. If the third stage was written using libsa then life would be much easier when writing an ELF loader. The filesystem and file descriptor support in libsa mimic normal syscalls making it possible to write and test the loader in userland before changing the bootstrap. I for one find fiddling with the bootstrap a hair raising experience. I have some bad memories from the 386bsd days with bootstraps and disklabels. Shudder. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Mar 21 03:39:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA10838 for hackers-outgoing; Fri, 21 Mar 1997 03:39:04 -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 DAA10833 for ; Fri, 21 Mar 1997 03:39:00 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id WAA24882; Fri, 21 Mar 1997 22:50:10 +1100 (EST) Date: Fri, 21 Mar 1997 22:50:09 +1100 (EST) From: "Daniel O'Callaghan" To: Doug Rabson cc: hackers@freebsd.org Subject: Re: tun0/user ppp lockups? 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 21 Mar 1997, Doug Rabson wrote: > I have been using mpd recently with some success. I had a couple of > problems with it which I will try to feed back to the author this > weekend but it seems basically sound. The code quality seems much > better than ppp but it does miss out on a couple of features (term, > packet filtering, aliasing). If you need them, you can always use > ipfw, I guess. Considering the same author wrote the divert(4) code for ipfw, which has led to Charles Mott's aliasing code being turned into a divert(4)-using natd, I think this was Archie's intention. Whistle wrote a natd themselves for the Interjet, but only released divert(4) and mpd of the Interjet, not the natd. (I'm sure Julian or Archie will correct me if I'm wrong). Danny From owner-freebsd-hackers Fri Mar 21 04:01:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA11757 for hackers-outgoing; Fri, 21 Mar 1997 04:01:38 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA11737 for ; Fri, 21 Mar 1997 04:01:31 -0800 (PST) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id LAA20389; Fri, 21 Mar 1997 11:51:48 GMT To: Terry Lambert Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: Kernel configuration futures (Was Re: wd driver questions) References: <199703201836.LAA14045@phaeton.artisoft.com> From: Doug Rabson Date: 21 Mar 1997 11:51:44 +0000 In-Reply-To: Terry Lambert's message of Thu, 20 Mar 1997 11:36:52 -0700 (MST) Message-ID: Lines: 140 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > ... > > The whole concept of tunables needs to be revamped. Some tunables are necessary. It should, however, be possible to tune things by say: # sysctl -w kern.i386.physmem=128M # or something # sync # reboot This seems a damn sight easier than editing a config file, rebuilding the kernel, installing it and then rebooting. > > > > The kernel file ought to be a minimal system (no filesystems, no > > drivers) aggregated with some number of kernel modules. Filesystems > > and drivers and everything else would plug themselves into the kernel > > using sysinits. > > > > I think that the right way to do this is to have all drivers and > > filesystems which must be present at boot time (e.g. everything needed > > to find the root filesystem whether it is local or NFS mounted) > > statically aggregated with the kernel file (still modules, but > > essentially pre-loaded). Other modules which the administrator knows > > will be needed *could* also be pre-loaded but this is not necessary. > > YES, EXACTLY! There would be *no such thing* as a seperable module > which did not self-register via sysinit(). > > The point of going to ELF, where you can have multiple segments in > a given image is to remove the real need for linker sets altogether, > and therefore the need for linking, rather than simple agregation > of onjects with an object librarian that operates on an ELF "library". You don't really need ELF for this, actually. If a driver module registers itself with sysinit, then it can be just added to the kernel link if you want it statically loaded. When loading the module dynamically, the kernel should run any sysinits contained in the module at load time. The module doesn't need to act differently in the two cases. > > Give an loader that can load or force the unload of a self registering > and unregistering ELF segment in an ELF image, loadable modules become > ELF "libraries" on their own. > > This also lets me do things like "module TCP requires module IP" (for > one example). Hmm. Somehow I doubt that many people would load IP without TCP :-). Dependancies in general would be useful for modules. That is probably where ELF has the edge. For instance, to get back the NFS example, both the client and the server share some utility code for doing RPC. If there were three modules, this works nicely: nfs_rpc_mod.o # RPC support code for client and server nfs_mod.o # NFS client, depends on nfs_rpc_mod.o nfs_serv_mod.o # NFS server, depends on nfs_rpc_mod.o When loading nfs_mod.o or nfs_serv_mod.o, nfs_rpc_mod.o would load automatically if not already present. > > It also lets me, after I get rid of the vfs_init code's dependence on > the !@#%!@! FFS file system being statically linked for it to be able > to get the struct vops size, replace the boot FS with any FS I want, > including (for example) NTFS or VFAT32 or HPFS or EXT2FS, etc.. > > If the loader itself is similarly self-agregated (but statically), then > I can use the same FS modules for the loader that I use for the kernel; > in point of fact, if I leave the loaer code around, the kernel doesn't > *need* an FS module other than that provided in the loader image. See my other reply. I think the restrictions of running in the loader (size and non-interrupt-driven i/o) make the use of a full-blown filesystem impractical. > > > > After the root filesystem is present, the persistent configuration > > database is available. This will contain all that is needed to load > > modules for all pci, pnp, pccard devices that are detected. Legacy > > isa devices can be handled by having a list of drivers to load > > unconditionally and device parameters (irq, mem, etc) to use with > > those drivers. > > I still would prefer that everything "just work" without a registry. > For PnP, EISA, MCA, or pure-PCI systems, this will work. For ISA > systems, we've covered most of the danger cases (LANCE and NE200 probe, > etc.) already. I still need a registry so that I can look up my > component ID's for COM and/or CORBA and/or MS software installed on > the system (in case we ever support WIN32), but little else. For PCI, PnP etc, I still think there needs to be a registry. The registry would have a mapping from pci device id to driver module name. The alternatives are to embed the device id in the module name, giving something like dev_8086_1229_mod.o for the fxp driver or to load all known drivers and let the probes sort out which ids they match. Neither approach works very well. Some drivers support many device ids and the idea of loading all drivers and only keeping the ones which probe just doesn't scale very well. > > > > Once all the modules have been loaded from the root filesystem (and > > passed their probes), boot continues more or less as it does today. > > Yes, exactly. The boot critical devices go in, then the rest of the > device go in once boot is done AND the device is present. The probe > code is in ELF segments marked "discardable" and will load in the > rest of the driver if the probe is true, but either way, the probe > code itself is in pages which are reclaimed. Not convinced. I don't want to have to probe possibly hundreds of drivers when there are only a couple of devices in the system. It should work in the other direction. The PCI device scan gives a list of ids. These ids are looked up in the registry to find possible drivers and those drivers are loaded. The only code which is loaded is code which is likely to be needed. When a new driver is installed (possibly in binary form from a vendor) it would hook itself into the registry for all the pci ids which it can support. > > The benefits are enormous... besides which, we fit in 4M again (who knows, > maybe even 2M!). Lets not get too optimistic. For the install disk, a lot of drivers still need to be present, either statically in the kernel or on the compiled-in MFS and that still takes up space. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Mar 21 04:20:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA12434 for hackers-outgoing; Fri, 21 Mar 1997 04:20:33 -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 EAA12429 for ; Fri, 21 Mar 1997 04:20:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id EAA08284; Fri, 21 Mar 1997 04:19:24 -0800 (PST) Message-Id: <199703211219.EAA08284@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: "A JOSEPH KOSHY" cc: freebsd-hackers@freebsd.org Subject: Re: SDDISKSORT In-reply-to: Your message of "Fri, 21 Mar 1997 16:44:18 +0500." <199703211144.AA094094658@fakir.india.hp.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 21 Mar 1997 04:19:24 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I noticed that by default we never turn on disk sorting for SCSI drives. Yes, that is correct. >What would be the reason for doing so. I understand that if a drive supports >command queueing then presorting the request list may not be effective. >However not all hardware support command queueing. > >Is not sorting the disk I/Os beneficial for all SCSI drives? The block sort algorithm in FreeBSD is highly inferior to the algorithms used in modern SCSI drives. Enabling the FreeBSD algorithm in this situation substantially reduces disk performance for drives/controllers that support tagged command queueing, which is why 'disksort' is disabled by default in FreeBSD. For people who have controllers that don't support tagged queueing, they can enable the disksort algorithm with the SDDISKSORT kernel option. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Mar 21 06:46:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA17930 for hackers-outgoing; Fri, 21 Mar 1997 06:46:40 -0800 (PST) Received: from mail.konnections.com (mail.konnections.com [192.41.71.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17924; Fri, 21 Mar 1997 06:46:38 -0800 (PST) Received: from castle (root@ip219.konnections.com [192.41.71.219]) by mail.konnections.com (8.8.3/8.8.3) with SMTP id HAA09872; Fri, 21 Mar 1997 07:43:36 -0700 (MST) Message-ID: <3333EEE1.5242080A@konnections.com> Date: Sat, 22 Mar 1997 07:38:25 -0700 From: mike allison Organization: Publisher -- Burning Eagle Book Company X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.0 i486) MIME-Version: 1.0 To: Paul Richards CC: Tom Torrance at home , FreeBSD-Chat@FreeBSD.org, FreeBSD-Hackers@FreeBSD.org Subject: Re: new freeunix publication References: <33334C0C.2B73BEFB@konnections.com> <57afnxwncb.fsf@tees.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Paul: As I stated yesterday, I'm working on a VISA agreement with our retail affiliate. It's a bit different since they aren't really sending/handling the product, but I'm sure we can work it out. Otherwise, there are some cases where I will accept foreign funds. Most countires currencies are stable enough that I don't need to worry, also I have a UK address you might be able to send UK funds through. Give me a day or so before we have to get creative. I think the VISA/MC and American Express capability will be on line soon. Thanks, -Mike Paul Richards wrote: > > mike allison writes: > > > Initially, our rates are: > > > > - Worldwide -- $37 (USD) > > > > All must be drawn on US funds, unless I fix Canada. > > > You make payment (Check or Money Order [I'm probably the last person who > > prefers a personal check, at least initially]) to: > > Is there any other way to pay, like VISA? It'd cost me almost as much > to raise a money order as it would to pay for the subscription ! > > -- > Dr Paul Richards. [p.richards@elsevier.co.uk] > Originative Solutions Ltd. [paul@originat.demon.co.uk] > Phone: 0370 462071 (Mobile), +44 (0)1865 843155 (Elsevier) From owner-freebsd-hackers Fri Mar 21 08:20:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA24148 for hackers-outgoing; Fri, 21 Mar 1997 08: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 IAA24141 for ; Fri, 21 Mar 1997 08:20:43 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09802; Fri, 21 Mar 1997 11:20:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 21 Mar 1997 11: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 GAA10662; Fri, 21 Mar 1997 06:28:11 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id GAA01221; Fri, 21 Mar 1997 06:33:36 -0500 (EST) Date: Fri, 21 Mar 1997 06:33:36 -0500 (EST) From: Thomas David Rivers Message-Id: <199703211133.GAA01221@lakes.water.net> To: ponds!lightside.com!jehamby, ponds!lambert.org!terry Subject: Re: Barb problem, FOUND Cc: ponds!freebsd.org!hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > From ponds!rivers@dg-rtp.dg.com Thu Mar 20 21:51:25 1997 > > Date: Thu, 20 Mar 1997 19:55:11 -0500 (EST) > > From: Thomas David Rivers > > To: ponds!village.org!imp@ucbvax.Berkeley.EDU, > ponds!lambert.org!terry@ucbvax.Berkeley.EDU > > Subject: Re: Barb problem, FOUND > > Cc: ponds!freebsd.org!hackers@ucbvax.Berkeley.EDU, > ponds!wgold.demon.co.uk!james@ucbvax.Berkeley.EDU > > X-Loop: FreeBSD.org > > X-UIDL: e5e3cfd6091cbeac8d85ac00f2302abc > > Wow, your mailer did SOMETHING funky to the return addresses (UUCP gremlins?)! > :) Yes - the "funny" part is the @ucbvx.Berkeley.EDU - that machine doesn't even exist anymore. However; the example sendmail.cf scripts for UUCP support reference it. I'm guessing some intermediate hop incorrectly did that rewrite. I'd love to figure out just exactly which one... > > > Hey! As manager of the SAS/C compilers I object to that :-) :-) > > [We like to keep our skeletons in the closet, thank you.] > > > > > > Of course; you likely mean the ooolllddd ones - not the spiffy new > > ones we have now :-) :-) We still use and actively maintain > > those compilers - we just don't sell them to the public. The SAS > > system on PC, mainframe (370 - MVS and VMS), MAC (68K and PowerPC) > > is built with compilers that owe their existence to that offering. > > [We still 'maintain' the amiga compiler via updates on-the-net. But, > > you can't buy that one any more either.] > > Funny, I bought SAS/C 6.5 for Amiga a few years back, through the SAS book > department. Are you sure they've stopped selling it? Don't know what I'm gonna > do with it now, but it's nice to have around (the manuals are a great reference > for libc stuff, at any rate). Yes - quite sure. We continued to sell it from the book department until we ran out of stock. We ran out a few months ago. We continue to "support" it, albeit unofficially, via updates to that product. [e.g. Some recent updates were done to add a builtin rotate function for speeding up encryption/decryption.] We're considering a new C++ update to add templates - would that be worthwhile? If so, would you need automatic instantiation or would explicit instantiation be adequate? - Dave Rivers - From owner-freebsd-hackers Fri Mar 21 08:25:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA24332 for hackers-outgoing; Fri, 21 Mar 1997 08:25:29 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA24314 for ; Fri, 21 Mar 1997 08:25:14 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA15782; Fri, 21 Mar 1997 09:12:19 -0700 From: Terry Lambert Message-Id: <199703211612.JAA15782@phaeton.artisoft.com> Subject: Re: MSWord docs... To: peter@grendel.IAEhv.nl (Peter Korsten) Date: Fri, 21 Mar 1997 09:12:19 -0700 (MST) Cc: spaz@u.washington.edu, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <19970321023634.25431@grendel.IAEhv.nl> from "Peter Korsten" at Mar 21, 97 02:36: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 > I don't know whether the link has been removed. The guy does state > that he figured out a file format himself, which happens to look > remarkably similar to the MS OLE 2.0 file format in general and > the Word format in particular. (But only the raw text can be > extracted, forget about things as tables and formatting.) The "File Formats Handbook" by _Born_ makes a similar claim. > I do know that the MS Word format was removed, by request of MS, from > the "Wotsit File Format Collection" (http://www.wotsit.demon.co.uk). I saw this too... > 3. The docs suppose that you use the OLE 2.0 API to read the word > files. We don't have docs on that, but a lot can be learnt from > the documentation of the German guy. Moreover, it wouldn't be > a bad idea to be able to read Access and Excel files as well, > if there were an OLE 2.0 API in FreeBSD. This is the "OLESS" stuff, right? Do you have a URL for this doc? 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 Mar 21 08:35:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA25097 for hackers-outgoing; Fri, 21 Mar 1997 08:35:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA25085 for ; Fri, 21 Mar 1997 08:35:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA15806; Fri, 21 Mar 1997 09:22:17 -0700 From: Terry Lambert Message-Id: <199703211622.JAA15806@phaeton.artisoft.com> Subject: Re: loadable modules and allocating a big memory segment? To: dg@root.com Date: Fri, 21 Mar 1997 09:22:17 -0700 (MST) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG In-Reply-To: <199703211015.CAA07938@root.com> from "David Greenman" at Mar 21, 97 02:15: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 am thinking about loadable sound drivers and video drivers which require > >continuous physical memory. > > > >In the case of the video drivers we may want to allocate as much as > >2 megabytes of physical memory. Does current support such a memory > >allocation scheme? > > Memory fragmentation is always a potential problem after the system has > been up and running awhile, but John has made some changes recently that > increase the likelihood that a chunk can be found. ...so it should work > most of the time. Plus there is no serious technical obstacle to doing a defrag on the memory as part of the contiguous allocation mechanism (though no one has implemented one). Effectively, there is no reson why all physical page space can not be reclaimed, short of the GDT and the currently active LDT, by simply moving around page data and page table entries. If you want to get a bit more complicated (using the dword count for the LGDT caller to callee stack copying), you should be able to move *everything* around as much as you want. ...actually, I've always wondered why the kernel stack is preloaded instead of using the dword to "call" the kernel from real mode... it would let it TSS back to real mode at any time, if it were done. You'd put the reset code there, and RETI from the kernel to cause a reset, instead of futzing around like we curently do... 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 Mar 21 09:21:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA27404 for hackers-outgoing; Fri, 21 Mar 1997 09:21:22 -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 JAA27395 for ; Fri, 21 Mar 1997 09:21:09 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA15127; Fri, 21 Mar 1997 12:20:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 21 Mar 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 MAA16226; Fri, 21 Mar 1997 12:01:42 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id MAA03608; Fri, 21 Mar 1997 12:07:09 -0500 (EST) Date: Fri, 21 Mar 1997 12:07:09 -0500 (EST) From: Thomas David Rivers Message-Id: <199703211707.MAA03608@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Subject: More ideas on "dup alloc" problem (I'm back.) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - You haven't heard from me regarding this problem in a while; I've been investigating, however. What I've determined is that the bytes are getting all the way down into the SCSI routines (my test system is SCSI based, but this occurs on IDE as well) - any they are uncorrupted. In fact, using the nice debugging routines in scsi_base.c (I'm on 2.1.7.1 now) I was able to print the bytes for the block number in question. During the newfs of /dev/rsd0a, scsi_done is convinced that a buffer full of 0x00 bytes was written at the block associated with inode #7680. [The data associated with the xs buffer when the physical block number is the one associated with inode #7680 contains 0x00.] However, the subsequent fsck find's the 0xff's previosly written to the block... (again, dutifully reported by the scsi_done() debugging printf's.) So - what I'm thinking is that scsi_done() was called when, in fact, the operation wasn't complete. That is; an interrupt came through for something else and got handed off to the scsi interrupt routine instead of whatever it was for.... In fact, this would have to be "done" before it ever got started; or else a spurious SCSI interrupt would come through. That is: queue up SCSI I/O catch an interrupt - pass it to scsi interrupt handler scsi_done removes queued I/O from xs chain, calls biodone(), etc... nothing actually gets written. Another explanation is that at queing time for the I/O, we should be at splbio() up until the point that the SCSI start is issued... Now - that kinda is a plausible explanation of what's happening; I have been able to prove it yet... but hope to soon. Also, I'm not sure how this would relate to the IDE situation, or even the MFS situation. - Thoughts? - - Dave Rivers - From owner-freebsd-hackers Fri Mar 21 09:26:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA27597 for hackers-outgoing; Fri, 21 Mar 1997 09:26:41 -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 JAA27372 for ; Fri, 21 Mar 1997 09:20:13 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA08751; Fri, 21 Mar 1997 17:20:08 +0100 From: Luigi Rizzo Message-Id: <199703211620.RAA08751@labinfo.iet.unipi.it> Subject: Re: MSWord docs... To: terry@lambert.org (Terry Lambert) Date: Fri, 21 Mar 1997 17:20:07 +0100 (MET) Cc: peter@grendel.IAEhv.nl, spaz@u.washington.edu, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199703211612.JAA15782@phaeton.artisoft.com> from "Terry Lambert" at Mar 21, 97 09:12:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 3. The docs suppose that you use the OLE 2.0 API to read the word > > files. We don't have docs on that, but a lot can be learnt from > > the documentation of the German guy. Moreover, it wouldn't be > > a bad idea to be able to read Access and Excel files as well, > > if there were an OLE 2.0 API in FreeBSD. > > This is the "OLESS" stuff, right? Do you have a URL for this doc? I don't know about OLESS but a similar thing called LAOLA, consisting in PERL files which parse OLE files, is at http://wwwwbs.cs.tu-berlin.de/~schwartz/pmh/ although it can extract pieces from the "OLE" filesystem structure, it does not seem to have detailed info on the internal format of each file type. 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 Fri Mar 21 09:52:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA29096 for hackers-outgoing; Fri, 21 Mar 1997 09:52:24 -0800 (PST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29090 for ; Fri, 21 Mar 1997 09:52:22 -0800 (PST) Received: from roo.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 21 Mar 1997 09:52:20 -0800 Message-Id: <199703211752.AA01751@zephyr.isi.edu> X-Mailer: exmh version 1.6.4 10/10/95 To: hackers@freebsd.org Subject: new Adaptec ATM driver available Reply-To: hutton@ISI.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 97 09:51:32 PST From: Anne Hutton Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, the rather formal blurb below is to let you know that there is a new BSD (including FreeBSD) Adaptec ATM driver available... Anne Hutton ......................................... The Applied Research Lab (ARL) of Washington University and the ATOMIC-2 Project at USC/ISI are pleased to announce the availability of a BSD device driver for the Adaptec 590x series of PCI ATM host adaptors (eg ANA-5940) Written by Chuck Cranor of Washington University's ARL (chuck@ccrc.wustl.edu), the "MIDWAY" ATM device driver originally supported Efficient Network's PCI ATM 155Mbps cards under FreeBSD, NetBSD, and OpenBSD. Working with Anne Hutton of USC/ISI, Chuck has recently added support for the Adaptec series of 155Mbps PCI ATM cards to the driver. The driver is currently in use at Washington University for several projects include the MARS video server project, the IP/ATM integration project, and the "QoS Guarantees Within Endsystems" project (see http://www.arl.wustl.edu/arl for details on these projects). USC/ISI is currently using the driver as part of their ATOMIC-2 project (http://www.isi.edu/atomic2/) for a PC-based ATM-ATOMIC gateway. The driver is also being used by researchers at Nokia, Sony, and Georgia Tech among other places. The driver is fully integrated into the NetBSD and OpenBSD source trees and can be obtained from those project's ftp servers. The FreeBSD version of the driver [partly contributed by Kenjiro Cho ] can be obtained from ftp://dworkin.wustl.edu/dist/bsd/bsdatm1.4.tar.gz From owner-freebsd-hackers Fri Mar 21 09:54:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA29259 for hackers-outgoing; Fri, 21 Mar 1997 09:54:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29253 for ; Fri, 21 Mar 1997 09:54:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15929; Fri, 21 Mar 1997 10:40:15 -0700 From: Terry Lambert Message-Id: <199703211740.KAA15929@phaeton.artisoft.com> Subject: Re: wd driver questions To: dfr@render.com (Doug Rabson) Date: Fri, 21 Mar 1997 10:40:15 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.ORG, helbig@MX.BA-Stuttgart.De In-Reply-To: from "Doug Rabson" at Mar 21, 97 11:13:49 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 NFS_NOSERVER code changes the way the lease VOP's operate, not > > because the code should be condition, but because the code is badly > > integrated. > > > > The registration of lease management mechanisms should take place > > for all VFS consumers, not just NFS. This is a generic issue with > > not being able to register a set of event callback entry points for > > a module. The *real* problem here is that the NFS server wants to > > register event handlers, but the server and the client code are in > > the same module space. This is really a source organization issue. > > Interesting idea. Any chance of a design for such a system? It should take place in the vfs_init() (which doesn't have a macro op) or the VFS_START() (which does). One problem here is that there is no corresponding "deinit"; it would have to be defined. You would generate two classes of even initially: 1) VFSEVENT( type, fs) A VFS event of 'type' has occurred on the file system 'fs' 2) VOPEVENT( type, fs, vn) A vnode operation event of type 'type' has occurred on the file system 'fs' affecting the file system vnode 'vn' This really goes back to defining the FS in terms of events and handling of events... this needs to be done for generic support of soft updates in all FS's, in any case. The "event management" would be a very generic subsystem in the kernel, so an FS specific implementation is probably an error. The lease code would be changed over to use "lease events" instead, and the NFS would register to receive the events. If there were no NFS server registration for lease events, then the events would be ignored (all events for which there is not a handler are simply ignored). For events with multiple handlers, all handlers are called (two browser windows open on the same directory, and so on). I supposed we could add an arbitrary "priority" field, and provide the ability for a handler to "swallow" an event to make sure that it does not propagate, but I'd rather not deal with inheritance issues juset yet. One could consider "soft" interrupts and "top end drivers" as event subsystem clients. > > I could see a number of useful events that a VFS consumer at the > > system call level would want to register. For instance, directory > > modification events would probably be useful for a file browser > > application to monitor. > > Directory modification events would be pretty useful for the NFS > server as well to extend the useful lifetime of NFS client cookies. > The event would need to supply more information than just 'changed' > since the seek values are still valid unless the directory was > compacted. Yes; this is more like a "lock range decoelesce" for the modified block. The client cookies in the "lock range" at the time of the event would be invalidated. This would resolve the Sun NFSv3 interoperability issue for the most part (there is still a potential boundry condition, where BSD4.4 does directory truncation, and the previous versions of UNIX and clone systems did not; but that's pretty easy to deal with: if the cookie is past EOF, it's invalid). If you are planning on doing any of this, I'm going to have to look to see how much of my mount code changes made it in via Jeffrey Hsu; the opportunity to modify the VFSOP operation is something that merits *serious* design consideration... much of the original CSRG work in the VFS integration was haphazard, IMO, and since we are no longer under the legal pressures that caused them to have to cut corners in the first place, we sould step back before diving in. I would like to have input here, if you'll let me. Clearly, the code needs to have reflexive op's (to allow us to deregister event syncs), but there are other issues as well; the following, in addition to the deinit, will affect the contents of the vfsops as well: o The original CSRG vfs_init depended on a statically linked FS to get the number of element in a 'struct vnodeop_desc' array from the first FS, which was hard-coded to be FFS. If it still does this, then kern/vnode_if.sh should be changed to emit code for vnode_if.c to calculate this from the template using 'sizeof( vfs_op_descs)/sizeof(struct vnodeop_desc)' instead. This removes the init dependency on FFS, or on a statically linked FS at all (patches submitted 06/06/94). o The difference between a 'vfs_mount' and a 'vfs_root' should be destroyed. This can be accomplished by causing all mounts to occur into the mounted FS list as if they were root mounts, and then handling the "mount point covering" in common code shared by all FS's, instead of duplicating parts of it in each FS's "mount" routine. This gets rid of 'vfs_root', and changes 'vfs_mount' significantly (partial patches for root mount merge into mount submitted 06/14/94). o When a 'mount' occurs (the mounted FS list is updated), the second stage is to map the FS into the FS hierarchy (root FS inferior name space). Since this is in common code, a 'mapping event' can be genreated, and 'handled' by the handlers. One handler would be registered by the NFS server... and thus all of the export processing moves out of the per FS code and up into the NFS server code, where it belongs, so that FS's do not have to have specific knowledge of exports (cv: the current code). o The previous change provides, as a side effect, the ability to handle FS media arrival events cleanly. A mount is just an event handler in the aformentioned event subsystem, and a volume arival (or departure) is "just another event". o The VFS_QUOTACTL should go away; quotas should be implemented as a stacking layer so they can apply to all file systems, not just UFS/FFS derived FS's. More common code == less potential for failures resulting from partially propagated changes with global effect == narrower change scoping == an overall more robust system. > > Heh. You aren't listening to me... you don't get rid of the boot-loader > > code. If you don't get rid of it, you can still use it. > > > > It's like the BIOS based boot being able to use the INT 13 redirector > > supplied by OnTrack, when you boot from an OnTrack drive. As long as > > you don't override it, it's still there. > > Actually, I expect the boot loader will have to be quite simple. To > be practical, even with a 3 stage bootstrap the third stage will have > to fit into 64k since it will need to use INT 13 for its disk access > and our tools can't (and shouldn't) generate anything except tiny > model programs. As a result, it will have severely truncated > read-only file system support (see libsa from NetBSD). This is > sufficient to load up the kernel. The boot will be discarded as soon > as the kernel is entered. It's tempting to implement a protected mode VMM in the third stage boot; have you seen: Protected Mode Software Architecture _Tom Shandly_, MindShare, Inc. Addison-Wesley Developers Press ISBN 0-201-5447-X Yet? > I was reading through libsa and our boot code yesterday and I believe > that a 3 stage bootstrap for biosboot would be pretty easy. If the > third stage was written using libsa then life would be much easier > when writing an ELF loader. The filesystem and file descriptor > support in libsa mimic normal syscalls making it possible to write and > test the loader in userland before changing the bootstrap. Yes; I would like to see the objects move between the systems, actually, which is why I was talking about a vnode-as-fd based kernel file I/O subsystem with Mike the other day. > I for one find fiddling with the bootstrap a hair raising experience. > I have some bad memories from the 386bsd days with bootstraps and > disklabels. Shudder. Well, this is an issue for "device arrival" events (implied on a "probe true" for a physical device) which are handled by a device mapping layer handler. Used in conjunction with a devfs, this would "magically" solve all the partition and diskslice and ... problems. I've discussed this before, but in case it wasn't obvious how the algorithm could work, here's a 50,000 foo view of the idea: probe() { if( found) event_send( RAW_DEVICE_ARRIVE, some_real_dev); return; } RAW_DEVICE_ARRIVE( ... dev) { /* * Raw device: look for a mapping layer that * recognizes the format of the data on this * device... ie: * o DOS partition table * o DOS extended partition table * o BSD diskslice * o SVR4 vtoc * o BAD144 * o etc. ... */ for( i = 0; i < num_log_to_phys_layers; i++) { if( map_layer[ i].recognize( dev)) return; } else event_send( END_DEVICE_ARRIVE, ... dev); return; } END_DEVICE_ARRIVE( ... dev) { /* * End device: distinguished because it does not * have a logical-to-physical mapping layer. It * must be an FS or it's just a device... */ lastmp = NULL; for( i = 0; i < num_fs_types; i++) if( ( mp = fstype[ i].mount( lastmp, dev)) != NULL) { lastmp = mp; /* * Mounted into mount tab... need * to mount into FS hierarchy, if * mount point defined... */ mount_into_fs( mp) /* * fall through for other FS's so we * can support quotas, umsdosfs, and * so on... */ } } if( !lastmp) { /* * device not mounted... diagnostic to console * if debugging, etc. */ } return; } /* map_layer[ DOS_PARTITIONING] ... */ int dos_partition_recognize( dev) { /* * recognition sequence... */ if( !recognize) return( 0); /* not ours!*/ /* * Each valid partition is a new raw device... */ for( i = 0; i < 4; i++) { if( !valid( i)) continue; event_send( RAW_DEVICE_ARRIVE, dos_p_mkdev(i)); } return( 1); } And so on... the details of the mapping layer device implementation, and the collapse of a logical-to-physical on top of a logical to physical, etc., are implementation issues (we can discuss them seperately, or off line). 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 Mar 21 10:04:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA29693 for hackers-outgoing; Fri, 21 Mar 1997 10:04:33 -0800 (PST) Received: from mailsrv2.zib.de (mailsrv2.zib.de [130.73.121.11]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA29675 for ; Fri, 21 Mar 1997 10:04:12 -0800 (PST) Received: from softs11.zib.de by mailsrv2.zib.de (SMI-8.6/SMI-SVR4) id TAA01178; Fri, 21 Mar 1997 19:03:37 +0100 Received: by softs11.zib.de (SMI-8.6/SMI-SVR4) id TAA13416; Fri, 21 Mar 1997 19:03:36 +0100 Date: Fri, 21 Mar 1997 19:03:36 +0100 From: schneider@zib.de (Wolfram Schneider) Message-Id: <199703211803.TAA13416@softs11.zib.de> To: Mike Pritchard Cc: brian@awfulhak.demon.co.uk (Brian Somers), hackers@FreeBSD.org Subject: Re: old BSD manpages (Re: cvs commit: www/data docs.sgml) In-Reply-To: <199703210628.WAA29324@freefall.freebsd.org> References: <199703210224.CAA13198@awfulhak.demon.co.uk> <199703210628.WAA29324@freefall.freebsd.org> 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 Mike Pritchard writes: >Can someone tell me what all of the pre-FreeBSD 2.0 releases were? >There are a few man pages that reference them, but I've never been >quite sure of the versions, so I haven't added them to the .Fx macro. ASCII Art http://www.de.freebsd.org/de/ftp/unix-stammbaum Wolfram From owner-freebsd-hackers Fri Mar 21 10:13:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA00199 for hackers-outgoing; Fri, 21 Mar 1997 10:13:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00191 for ; Fri, 21 Mar 1997 10:12:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15960; Fri, 21 Mar 1997 10:59:12 -0700 From: Terry Lambert Message-Id: <199703211759.KAA15960@phaeton.artisoft.com> Subject: Re: Kernel configuration futures (Was Re: wd driver questions) To: dfr@render.com (Doug Rabson) Date: Fri, 21 Mar 1997 10:59:12 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De In-Reply-To: from "Doug Rabson" at Mar 21, 97 11:51: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 > > The whole concept of tunables needs to be revamped. > > Some tunables are necessary. It should, however, be possible to tune > things by say: > > # sysctl -w kern.i386.physmem=128M # or something > # sync > # reboot > > This seems a damn sight easier than editing a config file, rebuilding > the kernel, installing it and then rebooting. Why reboot at all? 8-) 8-). Oh, god, now we need a "safe mode" for recovery from someone saying they have 256M of memory when they only have 16M (maybe they saw an "add more memory" error message? 8-)). > > YES, EXACTLY! There would be *no such thing* as a seperable module > > which did not self-register via sysinit(). > > > > The point of going to ELF, where you can have multiple segments in > > a given image is to remove the real need for linker sets altogether, > > and therefore the need for linking, rather than simple agregation > > of onjects with an object librarian that operates on an ELF "library". > > You don't really need ELF for this, actually. If a driver module > registers itself with sysinit, then it can be just added to the kernel > link if you want it statically loaded. When loading the module > dynamically, the kernel should run any sysinits contained in the > module at load time. The module doesn't need to act differently in > the two cases. Yes... the difference is, I want to be able to pull a module from an already linked kernel, and to do that, I have to deagregate the linker set data agregated from that module. 8-(. > > This also lets me do things like "module TCP requires module IP" (for > > one example). > > Hmm. Somehow I doubt that many people would load IP without TCP :-). Novell? TCP/IPX... 8-) 8-). > Dependancies in general would be useful for modules. That is probably > where ELF has the edge. For instance, to get back the NFS example, > both the client and the server share some utility code for doing RPC. > If there were three modules, this works nicely: > > nfs_rpc_mod.o # RPC support code for client and server > nfs_mod.o # NFS client, depends on nfs_rpc_mod.o > nfs_serv_mod.o # NFS server, depends on nfs_rpc_mod.o > > When loading nfs_mod.o or nfs_serv_mod.o, nfs_rpc_mod.o would load > automatically if not already present. This could be done by moving the link/load phase into the kernel, actually, without needing ELF. The ELF issues come into play when you want to reclaim space after an unload, or otherwise defrag your VM. I'm loathe to put each driver in its own unique VM for obvious overhead reasons (cv: "MACH vs. CHORUS" ad infinitum). > See my other reply. I think the restrictions of running in the loader > (size and non-interrupt-driven i/o) make the use of a full-blown > filesystem impractical. Depends on how well defined the VFS bottom end becomes. I think the current state of affairs in this regard is abysmal... there are some 120 or so kernel interfaces required to support the full Heidemann framework. This is an unacceptable bottom end. > For PCI, PnP etc, I still think there needs to be a registry. The > registry would have a mapping from pci device id to driver module > name. The alternatives are to embed the device id in the module name, > giving something like dev_8086_1229_mod.o for the fxp driver or to > load all known drivers and let the probes sort out which ids they > match. Neither approach works very well. Some drivers support many > device ids and the idea of loading all drivers and only keeping the > ones which probe just doesn't scale very well. Or to load a "metaprobe" module that knows which modules to load based on ID. 8-). That's how PnP services in Win95 operate, to some extent; it's just that the module references a registry. But there's no reason the module has to be implemented taht way. If you abstract at that level, the implementation can be opaque. It *should* be opaque so you don't have to have all your code working at once time to test part of it. > > Yes, exactly. The boot critical devices go in, then the rest of the > > device go in once boot is done AND the device is present. The probe > > code is in ELF segments marked "discardable" and will load in the > > rest of the driver if the probe is true, but either way, the probe > > code itself is in pages which are reclaimed. > > Not convinced. I don't want to have to probe possibly hundreds of > drivers when there are only a couple of devices in the system. It > should work in the other direction. The PCI device scan gives a list > of ids. These ids are looked up in the registry to find possible > drivers and those drivers are loaded. The only code which is loaded > is code which is likely to be needed. You don't need a registry for this (as above). If you don't like the "metaprobe" idea, rather than scanning the registry, it could look for an ELF segment "device data" in the files before it loaded them; either way, a real registry is not really necessary. I like the idea of the registr not being boot critical because I like the idea of putting the registry data into an LDAP server and doing central administration on all my machines by operating against the directory. If you require the registry, then you have to go full branching (that's not an LDAP capability, you'd need the whole X.500, which is a bear). It's the chicken-and-egg problem for network authentication instances for UNIX systems. How do I authenticate a kerberos ticket before I'm running processes which have credentials without the ticket associated with them? This is the same problem that UnixWare and NDS integration faced. > When a new driver is installed (possibly in binary form from a vendor) > it would hook itself into the registry for all the pci ids which it > can support. Or just have a segment with those ID's in it, or have a discradable code segment that a metaprobe knows how to load... > > The benefits are enormous... besides which, we fit in 4M again (who knows, > > maybe even 2M!). > > Lets not get too optimistic. For the install disk, a lot of drivers > still need to be present, either statically in the kernel or on the > compiled-in MFS and that still takes up space. But they do not take up space in RAM, unless they are used (assuming you have kernel paging support on at least a segment color boundry). 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 Mar 21 10:16:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA00656 for hackers-outgoing; Fri, 21 Mar 1997 10:16:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00651 for ; Fri, 21 Mar 1997 10:16:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15981; Fri, 21 Mar 1997 11:01:05 -0700 From: Terry Lambert Message-Id: <199703211801.LAA15981@phaeton.artisoft.com> Subject: Re: MSWord docs... To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Fri, 21 Mar 1997 11:01:05 -0700 (MST) Cc: terry@lambert.org, peter@grendel.IAEhv.nl, spaz@u.washington.edu, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199703211620.RAA08751@labinfo.iet.unipi.it> from "Luigi Rizzo" at Mar 21, 97 05:20: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 > I don't know about OLESS but a similar thing called LAOLA, consisting > in PERL files which parse OLE files, is at > > http://wwwwbs.cs.tu-berlin.de/~schwartz/pmh/ > > although it can extract pieces from the "OLE" filesystem structure, it > does not seem to have detailed info on the internal format of each file > type. Oh well, it's a start... thanks! PS: OLES == OLE Structured Storage; that's the official name for these compound files... 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 Mar 21 11:18:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05113 for hackers-outgoing; Fri, 21 Mar 1997 11:18:25 -0800 (PST) Received: from newland.com ([205.233.79.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA05024 for ; Fri, 21 Mar 1997 11:17:11 -0800 (PST) Received: from mnewton.newland.com ([205.233.79.111]) by newland.com (8.6.12/8.6.12) with SMTP id OAA23219 for ; Fri, 21 Mar 1997 14:16:44 -0500 Message-ID: <3332DE75.379F@newland.com> Date: Fri, 21 Mar 1997 14:16:05 -0500 From: mnewton Organization: The Newland Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: hackers Subject: FreeBSD as proxy server for mail client 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 BSD box connected as a proxy server (Squid) with a static IP .I have 25 pc's attached on a local IP net browsing and popping mail from the BSD pc. I have some users that have other mail servers on the "outside" that I need to proxy thru' the BSD box. Do I use IPFW or SOCKS to do this ??. Will it conflict with SQUID ??? etc etc. thx mn From owner-freebsd-hackers Fri Mar 21 11:51:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA08532 for hackers-outgoing; Fri, 21 Mar 1997 11:51:13 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA08525 for ; Fri, 21 Mar 1997 11:51:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA16139; Fri, 21 Mar 1997 12:38:16 -0700 From: Terry Lambert Message-Id: <199703211938.MAA16139@phaeton.artisoft.com> Subject: Re: FreeBSD as proxy server for mail client To: mnewton@newland.com (mnewton) Date: Fri, 21 Mar 1997 12:38:16 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <3332DE75.379F@newland.com> from "mnewton" at Mar 21, 97 02:16:05 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 have a BSD box connected as a proxy server (Squid) with a static IP .I > have 25 pc's attached on a local IP net browsing and popping mail from > the BSD pc. I have some users that have other mail servers on the > "outside" that I need to proxy thru' the BSD box. Do I use IPFW or SOCKS > to do this ??. > Will it conflict with SQUID ??? etc etc. Do you care if the connection is made to the FreeBSD box or to the outside box? If you don't care, I'd suggest using popper to retrieve the mail from the user's outside account to the user's FreeBSD account, and then the user can read their mail by connecting to the FreeBSD box. 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 Mar 21 13:02:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA13044 for hackers-outgoing; Fri, 21 Mar 1997 13:02:48 -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 NAA13030 for ; Fri, 21 Mar 1997 13:02:45 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w8BS4-0002RV-00; Fri, 21 Mar 1997 14:02:16 -0700 To: schneider@zib.de (Wolfram Schneider) Subject: Re: old BSD manpages (Re: cvs commit: www/data docs.sgml) Cc: Mike Pritchard , brian@awfulhak.demon.co.uk (Brian Somers), hackers@freebsd.org In-reply-to: Your message of "Fri, 21 Mar 1997 19:03:36 +0100." <199703211803.TAA13416@softs11.zib.de> References: <199703211803.TAA13416@softs11.zib.de> <199703210224.CAA13198@awfulhak.demon.co.uk> <199703210628.WAA29324@freefall.freebsd.org> Date: Fri, 21 Mar 1997 14:02:16 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199703211803.TAA13416@softs11.zib.de> Wolfram Schneider writes: : ASCII Art http://www.de.freebsd.org/de/ftp/unix-stammbaum Hmmm, I'd suspect there is a lot more cross polination between the various *BSDs and BSDi now than is listed on the chart. Warner From owner-freebsd-hackers Fri Mar 21 14:11:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16505 for hackers-outgoing; Fri, 21 Mar 1997 14:11:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA16496 for ; Fri, 21 Mar 1997 14:11:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA16418 for hackers@freebsd.org; Fri, 21 Mar 1997 15:00:05 -0700 From: Terry Lambert Message-Id: <199703212200.PAA16418@phaeton.artisoft.com> Subject: A self-referential message To: hackers@freebsd.org Date: Fri, 21 Mar 1997 15:00:04 -0700 (MST) 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 list is slogged; apparently the SMTP server is taking a long time to answer. How recent is the snapshot being run by freefall? 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 Mar 21 14:40:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA18241 for hackers-outgoing; Fri, 21 Mar 1997 14:40:02 -0800 (PST) Received: from main.gbdata.com (USR1-1.detnet.com [207.113.12.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA18186 for ; Fri, 21 Mar 1997 14:39:55 -0800 (PST) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.5/8.8.5) id PAA25614; Fri, 21 Mar 1997 15:46:26 -0600 (CST) From: Gary Clark II Message-Id: <199703212146.PAA25614@main.gbdata.com> Subject: Re: FreeBSD as proxy server for mail client To: mnewton@newland.com (mnewton) Date: Fri, 21 Mar 1997 15:46:26 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <3332DE75.379F@newland.com> from mnewton at "Mar 21, 97 02:16:05 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 mnewton wrote: > I have a BSD box connected as a proxy server (Squid) with a static IP .I > have 25 pc's attached on a local IP net browsing and popping mail from > the BSD pc. I have some users that have other mail servers on the > "outside" that I need to proxy thru' the BSD box. Do I use IPFW or SOCKS > to do this ??. > Will it conflict with SQUID ??? etc etc. I don't know of a proxy that will work for this in the RIGHT way. I would just load up a cron job to run popclient every so often and put the mail in the machines mail box. > > thx mn > Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-hackers Fri Mar 21 14:40:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA18322 for hackers-outgoing; Fri, 21 Mar 1997 14:40:17 -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 OAA18290 for ; Fri, 21 Mar 1997 14:40:12 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id JAA29116; Sat, 22 Mar 1997 09:50:59 +1100 (EST) Date: Sat, 22 Mar 1997 09:50:59 +1100 (EST) From: "Daniel O'Callaghan" To: mnewton cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD as proxy server for mail client In-Reply-To: <199703211938.MAA16139@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, 21 Mar 1997, Terry Lambert wrote: > > I have a BSD box connected as a proxy server (Squid) with a static IP .I > > have 25 pc's attached on a local IP net browsing and popping mail from > > the BSD pc. I have some users that have other mail servers on the > > "outside" that I need to proxy thru' the BSD box. Do I use IPFW or SOCKS > > to do this ??. > > Will it conflict with SQUID ??? etc etc. > > Do you care if the connection is made to the FreeBSD box or to the > outside box? > > If you don't care, I'd suggest using popper to retrieve the mail > from the user's outside account to the user's FreeBSD account, and > then the user can read their mail by connecting to the FreeBSD box. I guess you mean 'popclient' here, rather than 'popper'. For Mark's benefit: popclient is a unix program which will fetch mail from a remote pop server and put the mail in your local Unix mailbox. Danny From owner-freebsd-hackers Fri Mar 21 15:18:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA21495 for hackers-outgoing; Fri, 21 Mar 1997 15:18:54 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21475; Fri, 21 Mar 1997 15:18:50 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id PAA02970; Fri, 21 Mar 1997 15:18:46 -0800 (PST) Message-Id: <199703212318.PAA02970@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Louis A. Mamakos" cc: Steve Passe , hackers@freebsd.org, Michael Petry , multimedia@freebsd.org Subject: Re: Continquous Memory vs Virtual Memory In-reply-to: Your message of "Fri, 21 Mar 1997 17:59:21 EST." <199703212259.RAA09791@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 15:18:45 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of "Louis A. Mamakos" : > > Hi, > > > > > Nope, because the risc program is build in a allocated area in > > > the kernel which the user can't override. If someone wanted > > ^^^^^^^^^^^^^^^^^ > > > to over-write a particular region of memory with the output > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > of the bt848 , they can . > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > this is the possibility that I was refering to. thus they could do the > > same thing that people do with strcpy(), write a short segment of > > code that creates a "worm hole" into the kernel, then install it > > with the above technique. this says to me that allowing a user > > to create and load a RISC program is a BAD idea. But having the > > kernel level RISC compiler is a good idea. It could enforce that the > > destination address MUST be within the range of the video card's > > linear buffer. Now we still need to worry about source addresses, > > a clever programmer could write a "snoop" program that > > could look into kernel core for other hacking info... > > You need to do something a bit different than this. I'm also presuming > that you'd want to capture into a memory buffer that the user's got access > to, rather than just into a frame buffer. I think that you'd still > want to support clipping regions, as all the effort had already been done > to accomodate the frame buffer. > > The cool part here is that the (real) memory need not be continguous, meaning > that any old buffer that the user malloc()'ed could be used, provided that > it's actually in a resident page frame. > > I fear that more knowledge of the VM system is going to be necessary.. Oh > boy. > > louie Hey Louie, don't be shy to post to the hackers list. They are there for this sort of questions 8) To hackers, Is there an easy way for me to determine the actual physical pages that a kernel malloc returns or should I just go ahead and do it manually. Thats is translate the virtual memory address to a physical address across the memory region a kernel malloc returns to a driver. The background of all this is that the Bt848 video capture chip does not really require a contiguous memory region since individual captured lines can be directed to any region by way of a "risc program" To give you an idea of what we do, here are fragments from the Bt848 driver. inst = OP_WRITE | OP_SOL | bt_enable_cnt << 12 | (b); inst2 = OP_WRITE | bt_enable_cnt << 12 | (cols * pixel_width/2); And in a for loop: --- *dma_prog++ = inst; *dma_prog++ = target_buffer; target_buffer += interlace*pitch; ---- Target_buffer can be any memory location in the host or in a video adapter's frame buffer. Tnks, Amancio From owner-freebsd-hackers Fri Mar 21 15:20:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA21613 for hackers-outgoing; Fri, 21 Mar 1997 15:20:12 -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 PAA21608 for ; Fri, 21 Mar 1997 15:20:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id PAA10490; Fri, 21 Mar 1997 15:20:08 -0800 (PST) Message-Id: <199703212320.PAA10490@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG Subject: Re: loadable modules and allocating a big memory segment? In-reply-to: Your message of "Fri, 21 Mar 1997 09:22:17 MST." <199703211622.JAA15806@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 21 Mar 1997 15:20:08 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >I am thinking about loadable sound drivers and video drivers which require >> >continuous physical memory. >> > >> >In the case of the video drivers we may want to allocate as much as >> >2 megabytes of physical memory. Does current support such a memory >> >allocation scheme? >> >> Memory fragmentation is always a potential problem after the system has >> been up and running awhile, but John has made some changes recently that >> increase the likelihood that a chunk can be found. ...so it should work >> most of the time. > >Plus there is no serious technical obstacle to doing a defrag on >the memory as part of the contiguous allocation mechanism (though >no one has implemented one). > >Effectively, there is no reson why all physical page space can not >be reclaimed, short of the GDT and the currently active LDT, by >simply moving around page data and page table entries. If you want >to get a bit more complicated (using the dword count for the LGDT >caller to callee stack copying), you should be able to move *everything* >around as much as you want. Actually, Terry, you are quite wrong about that. The kernel has many instances where it must temprarily store the physical address of a page - in order to set up DMA descriptors, for example (indeed, in the DMA descriptors themselves), not to mention data structures at the pmap level (PV entries, for example). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Mar 21 15:22:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA21720 for hackers-outgoing; Fri, 21 Mar 1997 15:22:08 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21709 for ; Fri, 21 Mar 1997 15:22:03 -0800 (PST) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA18622; Fri, 21 Mar 1997 18:13:12 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA01754; Fri, 21 Mar 1997 18:13:09 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id SAA01355 for ; Fri, 21 Mar 1997 18:23:34 GMT Message-Id: <199703211823.SAA01355@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: hackers@freebsd.org Subject: New de driver released ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 18:23:34 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [I've sent it to dg and will be uploading it to freefall later tonight. Read this message completely. For those people who have cards that just don't work, I'd really like you to try this driver and send me the results.] This is a new, very different, de driver. It's the one in NetBSD and most of the bugs seem to have been shaken out. I've tested with 21040, 21041, SMC9332DST, DE500-AA, DE500-XA, DE500-BA (21143!). This driver requires the if_media support recently added to NetBSD. It is not optional. It took me less that 15 minutes to get a FreeBSD 2.1.0 system with ifmedia running. You need: sys/net/if_media.[ch] (small tweak needed to if_media.h NetBSD uses _KERNEL instead of KERNEL). Add SIOC[GS]IFMEDIA to sys/sys/sockio.h Add struct ifmediareq and ifr_media to ifres in sys/net/if.h Add entry for net/if_media.c to sys/conf/files % uname -a FreeBSD whydos.lkg.dec.com 2.1.0-RELEASE FreeBSD 2.1.0-RELEASE #2: Fri Mar 21 17:14:15 1997 root@:/usr/src/sys/compile/DECFDDI i386 % ifconfig de0 de0: flags=8863 media: autoselect (100baseTX) status: active inet 10.0.0.3 netmask 0xff000000 broadcast 10.255.255.255 This was done by using the ifconfig from NetBSD. No changes where made, just compiled it. Cheers, -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Fri Mar 21 16:25:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA25767 for hackers-outgoing; Fri, 21 Mar 1997 16:25:32 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA25757 for ; Fri, 21 Mar 1997 16:25:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA16659; Fri, 21 Mar 1997 17:12:40 -0700 From: Terry Lambert Message-Id: <199703220012.RAA16659@phaeton.artisoft.com> Subject: Re: loadable modules and allocating a big memory segment? To: dg@root.com Date: Fri, 21 Mar 1997 17:12:40 -0700 (MST) Cc: terry@lambert.org, hasty@rah.star-gate.com, hackers@FreeBSD.ORG In-Reply-To: <199703212320.PAA10490@root.com> from "David Greenman" at Mar 21, 97 03:20: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 > >Effectively, there is no reson why all physical page space can not > >be reclaimed, short of the GDT and the currently active LDT, by > >simply moving around page data and page table entries. If you want > >to get a bit more complicated (using the dword count for the LGDT > >caller to callee stack copying), you should be able to move *everything* > >around as much as you want. > > Actually, Terry, you are quite wrong about that. The kernel has many > instances where it must temprarily store the physical address of a page - > in order to set up DMA descriptors, for example (indeed, in the DMA > descriptors themselves), not to mention data structures at the pmap level > (PV entries, for example). Well, there's nothing that says the reclaim would occur instantaneously... only that it would occur. For devices which can't relocate in physical memory, it's likely that you would want to attribute the device allocation request so that it can be allocated as "high persistance". This would let you pre-defrag the memory and allocate those next to each other (probably in high memory under 16M?). For outstanding operations that aren't high persistance, then you can be assured that they will complete in a resonable period of time (at which time the *can* be relocated, like SCSI buffers in the non-bounce case). 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 Mar 21 16:27:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA25854 for hackers-outgoing; Fri, 21 Mar 1997 16:27:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA25848 for ; Fri, 21 Mar 1997 16:27:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA16679; Fri, 21 Mar 1997 17:14:13 -0700 From: Terry Lambert Message-Id: <199703220014.RAA16679@phaeton.artisoft.com> Subject: Re: FreeBSD as proxy server for mail client To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Fri, 21 Mar 1997 17:14:13 -0700 (MST) Cc: mnewton@newland.com, hackers@FreeBSD.ORG In-Reply-To: from "Daniel O'Callaghan" at Mar 22, 97 09:50:59 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 > > If you don't care, I'd suggest using popper to retrieve the mail > > from the user's outside account to the user's FreeBSD account, and > > then the user can read their mail by connecting to the FreeBSD box. > > I guess you mean 'popclient' here, rather than 'popper'. For Mark's > benefit: popclient is a unix program which will fetch mail from a remote > pop server and put the mail in your local Unix mailbox. Yes, sorry. I've spent too much time in the Qualacomm FTP site lately... 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 Mar 21 19:31:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA06214 for hackers-outgoing; Fri, 21 Mar 1997 19:31:37 -0800 (PST) Received: from grunt.sands.com (dal91.metronet.com [192.245.137.91]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA06199; Fri, 21 Mar 1997 19:31:23 -0800 (PST) Received: from grunt.sands.com (localhost.sands.com [127.0.0.1]) by grunt.sands.com (8.7.6/8.7.3) with ESMTP id VAA03550; Fri, 21 Mar 1997 21:37:49 -0600 (CST) Message-Id: <199703220337.VAA03550@grunt.sands.com> X-Mailer: exmh version 1.6.9 8/22/96 To: questions@freebsd.org, hackers@freebsd.org Subject: ISDN TA drivers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 21:37:48 -0600 From: Ted Spradley Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anybody working on a device driver for any of the cheap new ISDN terminal adapters, e.g., Diamond Supra NetCommander, Diva, Cardinal Technology. Sure would hate to have to buy an external router, when FreeBSD could the job so much better. Of course, I *could* write the driver myself, if no one's in a hurry (including me). Ted Spradley tsprad@metronet.com +1-972-484-5356 Brisco: "...the more I learn the less I know." Bowler: "At the rate we're learning things we won't know nothing in no time." Ted Spradley tsprad@metronet.com +1-972-484-5356 Brisco: "...the more I learn the less I know." Bowler: "At the rate we're learning things we won't know nothing in no time." From owner-freebsd-hackers Fri Mar 21 21:01:18 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA09599 for hackers-outgoing; Fri, 21 Mar 1997 21:01:18 -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 VAA09587 for ; Fri, 21 Mar 1997 21:01:16 -0800 (PST) Received: (from jmacd@localhost) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) id VAA12058 for freebsd-hackers@freebsd.org; Fri, 21 Mar 1997 21:01:15 -0800 (PST) Date: Fri, 21 Mar 1997 21:01:15 -0800 (PST) From: Josh MacDonald Message-Id: <199703220501.VAA12058@paris.CS.Berkeley.EDU> To: freebsd-hackers@freebsd.org Subject: libc_r Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I read the pthread(3) man page and it says I need to build libc_r myself in order to use threads. I could do this, but its inconvenient. How come it isn't being distributed in the binary distributions? -josh From owner-freebsd-hackers Fri Mar 21 22:33:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA12378 for hackers-outgoing; Fri, 21 Mar 1997 22:33:55 -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 WAA12373 for ; Fri, 21 Mar 1997 22:33:51 -0800 (PST) Received: (qmail 8428 invoked by uid 5); 22 Mar 1997 06:33:42 -0000 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id RAA15734; Sat, 22 Mar 1997 17:33:44 +1100 (EST) From: John Birrell Message-Id: <199703220633.RAA15734@freebsd1.cimlogic.com.au> Subject: Re: libc_r To: jmacd@CS.Berkeley.EDU (Josh MacDonald) Date: Sat, 22 Mar 1997 17:33:43 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199703220501.VAA12058@paris.CS.Berkeley.EDU> from Josh MacDonald at "Mar 21, 97 09:01:15 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 Josh MacDonald wrote: > Hi, I read the pthread(3) man page and it says I need to build > libc_r myself in order to use threads. I could do this, but > its inconvenient. How come it isn't being distributed in the > binary distributions? In current, libc_r was left as optional to avoid (a) lengthening the build time when most people probably didn't want it; and (b) breaking a `make world' in the event that there were problems in the libc_r build. The binary distributions (I guess you mean SNAPs) contain what normally gets built. Of course Jordan could read the pthread man page too, and add WANT_LIBC_R to his environment before building a SNAP. ;-) I think there are enough people using libc_r now to enable it permanently in sys/lib/Makefile, leaving an environment variable to turn it off. There are no quirks to the libc_r build -- from time to time edits are made to libc Makefiles without corresponding edits in libc_r Makefiles. I'd like to merge all the Makefiles to avoid this problem, but this adds complexity to the libc Makefiles that people might not want. > > -josh > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137 From owner-freebsd-hackers Fri Mar 21 23:16:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA13791 for hackers-outgoing; Fri, 21 Mar 1997 23:16:27 -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 XAA13786 for ; Fri, 21 Mar 1997 23:16:24 -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 XAA12560; Fri, 21 Mar 1997 23:16:20 -0800 (PST) From: Josh MacDonald Message-Id: <199703220716.XAA12560@paris.CS.Berkeley.EDU> To: John Birrell cc: freebsd-hackers@freebsd.org Subject: Re: libc_r In-reply-to: Your message of "Sat, 22 Mar 1997 17:33:43 +1100." <199703220633.RAA15734@freebsd1.cimlogic.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12553.859014977.1@paris.CS.Berkeley.EDU> Date: Fri, 21 Mar 1997 23:16:19 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In current, libc_r was left as optional to avoid (a) lengthening the > build time when most people probably didn't want it; and (b) breaking > a `make world' in the event that there were problems in the libc_r > build. The binary distributions (I guess you mean SNAPs) contain what > normally gets built. Of course Jordan could read the pthread man page > too, and add WANT_LIBC_R to his environment before building a SNAP. ;-) > > I think there are enough people using libc_r now to enable it > permanently in sys/lib/Makefile, leaving an environment variable > to turn it off. There are no quirks to the libc_r build -- from > time to time edits are made to libc Makefiles without corresponding > edits in libc_r Makefiles. I'd like to merge all the Makefiles to avoid > this problem, but this adds complexity to the libc Makefiles that > people might not want. This is sort of what I suspected. Consider this (hi Jordan) a request for the above change. -josh From owner-freebsd-hackers Sat Mar 22 01:13:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA16509 for hackers-outgoing; Sat, 22 Mar 1997 01:13:40 -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 BAA16504 for ; Sat, 22 Mar 1997 01:13: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 BAA16870 for ; Sat, 22 Mar 1997 01:15:43 -0800 (PST) Received: (qmail 22992 invoked by uid 110); 22 Mar 1997 09:12:53 -0000 Message-ID: <19970322091253.22991.qmail@suburbia.net> Subject: Re: mount: ufs filesystem is not available - urgent help needed In-Reply-To: <199703220749.IAA14778@gilberto.physik.rwth-aachen.de> from Christoph Kukulies at "Mar 22, 97 08:49:05 am" To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Sat, 22 Mar 1997 20:12:53 +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 > > Since yesterday night cvsup.de.freebsd.org (and in consequence > of this due to nfs mounts) ftp.de.freebsd.org are defunct. > > ftp.de.freebsd.org crashed and stopped at reboot due to > fsck failures in single user mode. I sitting here at the machine > now , fsck'ed , rebooted and now I'm getting > > mount: ufs filesystem is not available > mount: ufs filesystem is not available > mount: ufs filesystem is not available > mount: ufs filesystem is not available > mount: ufs filesystem is not available > > on every ufs mount (/, /var, /usr, /home, /a) > > I need urgent help to get the machine going again. > > Thanks. > > > -- > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > The problem is that part of your system is current and part is not. Try /stand/mount -a Cheers, Julian From owner-freebsd-hackers Sat Mar 22 01:45:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA17328 for hackers-outgoing; Sat, 22 Mar 1997 01:45:28 -0800 (PST) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA17276 for ; Sat, 22 Mar 1997 01:42:02 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.8.3/8.6.5) id OAA01530; Sat, 22 Mar 1997 14:43:53 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199703220943.OAA01530@hq.icb.chel.su> Subject: Re: ep driver memory management question.. To: ccsanady@nyx.pr.mcs.net (Chris Csanady) Date: Sat, 22 Mar 1997 14:43:52 +0500 (ESK) Cc: hackers@FreeBSD.ORG In-Reply-To: <199703181039.EAA03782@nyx.pr.mcs.net> from "Chris Csanady" at Mar 18, 97 04:39:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm not very familiar with net drivers, but I would like to rewrite the ep > driver to use contiguous packet buffers. I am curious about how it allocates > memory for packets, and if there are any limitations. From the code, it looks > as if it just allocates an mbuf, dmas into it, and passes it off to It allocates mbufs in bucnhes them uses them as needed. > ether_input. Is this correct? I thought that there was a 16M limit on dma I don't know about newer cards supported by it but the original 3c5[07]9 does not have any DMA! It uses ins/outs port access instructions. > for the isa bus without bouncing, but I didn't see anything that dealt with > this. Is this because all the mbufs get allocated at boot, so its just the > way it turns out? If so, I will need to allocate a contiguous chunk of memory > for the driver upon boot. How would I do this? Again, it does not use DMA. I think the best idea will be to use mbuf clusters like David Greenman does in his drivers. Look at /sys/pci/if_fxp.c for example. -SB From owner-freebsd-hackers Sat Mar 22 04:14:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20391 for hackers-outgoing; Sat, 22 Mar 1997 04:14:31 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20383 for ; Sat, 22 Mar 1997 04:14:21 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id NAA22953; Sat, 22 Mar 1997 13:14:22 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.5/8.6.9) id NAA15713; Sat, 22 Mar 1997 13:24:02 +0100 (MET) Message-ID: Date: Sat, 22 Mar 1997 13:24:01 +0100 From: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) To: proff@suburbia.net Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies), hackers@freebsd.org Subject: Re: mount: ufs filesystem is not available - urgent help needed References: <19970322091253.22991.qmail@suburbia.net> <199703220749.IAA14778@gilberto.physik.rwth-aachen.de> X-Mailer: Mutt 0.58e Mime-Version: 1.0 In-Reply-To: <19970322091253.22991.qmail@suburbia.net>; from proff@suburbia.net on Mar 22, 1997 20:12:53 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk proff@suburbia.net writes: > > > > Since yesterday night cvsup.de.freebsd.org (and in consequence > > of this due to nfs mounts) ftp.de.freebsd.org are defunct. > > > > ftp.de.freebsd.org crashed and stopped at reboot due to > > fsck failures in single user mode. I sitting here at the machine > > now , fsck'ed , rebooted and now I'm getting > > > > mount: ufs filesystem is not available > > mount: ufs filesystem is not available > > mount: ufs filesystem is not available > > mount: ufs filesystem is not available > > mount: ufs filesystem is not available > > > > on every ufs mount (/, /var, /usr, /home, /a) > > > > I need urgent help to get the machine going again. > > > > Thanks. > > > > > > -- > > Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > > > The problem is that part of your system is current and part is not. > > Try /stand/mount -a No, this can't be. I booted with this configuration several times before. I used fixit.flp and grabbed a new mount binary to no avail. > > Cheers, > Julian -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Sat Mar 22 04:43:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA21600 for hackers-outgoing; Sat, 22 Mar 1997 04:43:07 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21594 for ; Sat, 22 Mar 1997 04:43:04 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id NAA23044; Sat, 22 Mar 1997 13:43:06 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.5/8.6.9) id NAA17808; Sat, 22 Mar 1997 13:52:46 +0100 (MET) From: Christoph Kukulies Message-Id: <199703221252.NAA17808@gilberto.physik.rwth-aachen.de> Subject: Re: mount: ufs filesystem is not available - urgent help needed In-Reply-To: from Christoph Kukulies at "Mar 22, 97 01:24:01 pm" To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Sat, 22 Mar 1997 13:52:44 +0100 (MET) Cc: proff@suburbia.net, kuku@gilberto.physik.rwth-aachen.de, hackers@freebsd.org Reply-To: Christoph Kukulies 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 problem is that part of your system is current and part is not. > > > > Try /stand/mount -a > > No, this can't be. I booted with this configuration several times > before. > I used fixit.flp and grabbed a new mount binary to no avail. > > > > > > Cheers, > > Julian > > -- > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > I got it working again with a new kernel. I must have done something behind my back which I don't know of. Thanks to all for helping. -- Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Sat Mar 22 04:50:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA21872 for hackers-outgoing; Sat, 22 Mar 1997 04:50:42 -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 EAA21867 for ; Sat, 22 Mar 1997 04:50:37 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA01766; Sat, 22 Mar 1997 07:50:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 22 Mar 1997 07: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 HAA09931 for ; Sat, 22 Mar 1997 07:39:10 -0500 (EST) Received: (from root@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA09437; Sat, 22 Mar 1997 07:44:40 -0500 (EST) Date: Sat, 22 Mar 1997 07:44:40 -0500 (EST) From: Thomas David Rivers Message-Id: <199703221244.HAA09437@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Subject: More "dup alloc" info. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just F.Y.I. - I'm still stumbling around with this dup alloc problem. I'm using 2.1.7.1 sources now... Anyway, I've discovered that if I had a printf() to aha_done [my reproduction is with an aha1542b; and an IDE machine - but I'm working on the 1542b] to print the current processor level (cpl) that problem is masked. That is, I don't reproduce the bug. This would tend to indicate that some timing is involved; and that, somewhere the cpl must be at least splbio(). However, using: if(cpl & bio_imask != bio_imask) checks in some suspect places (i.e. scsi_done(), biodone()) I haven't been able to verify this. (That is, none of them were tripped.) Again - it seems that a SCSI command is being constructed which contains a data buffer just chock full of the requisite 0x00s, but that data certainly isn't making it to the disk... scsi_done() is convinced the operation completed successfully. (I.e. sdstart() queued it, and an interrupt came back for it.. scsi_done() dump'd the xs buffer to print all 0x00s.) BUT - those 0x00s aren't making it to the disk... argh... Help, I'm running out of ideas ... - Dave Rivers - From owner-freebsd-hackers Sat Mar 22 06:16:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA25815 for hackers-outgoing; Sat, 22 Mar 1997 06:16:46 -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 GAA25806 for ; Sat, 22 Mar 1997 06:16:34 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA10666 for hackers@freebsd.org; Sat, 22 Mar 1997 14:23:53 +0100 From: Luigi Rizzo Message-Id: <199703221323.OAA10666@labinfo.iet.unipi.it> Subject: DATA_SET and SYSINIT manpages missing To: hackers@freebsd.org Date: Sat, 22 Mar 1997 14:23:53 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, could someone write manpages (9) for the DATA_SET and SYSINIT macros (possibly with an example of use) ? They seem to be missing from section 9 of the manual in 2.2-R , but they are used in almost all device drivers and it is quite hard to figure out how they should be used (other than by imitating an existing driver -- a Bad Thing IMHO because one ends out writing code that he doesn't understand and might be used by others as a model ... ) 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 Sat Mar 22 09:22:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA10689 for hackers-outgoing; Sat, 22 Mar 1997 09:22:34 -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 JAA10672 for ; Sat, 22 Mar 1997 09:22:29 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA08239; Sat, 22 Mar 1997 18:21:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id RAA27072; Sat, 22 Mar 1997 17:58:55 +0100 (MET) Message-ID: <19970322175854.TD55532@uriah.heep.sax.de> Date: Sat, 22 Mar 1997 17:58:54 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: matrix@infoce-2-ll.ll4.relcom.ru (Artem Koutchine) Cc: hackers@freebsd.org Subject: Re: ATAPI and INSTALL.. 2b|!2B References: <199703190844.LAA07126@infoce-2-ll.ll4.relcom.ru> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199703190844.LAA07126@infoce-2-ll.ll4.relcom.ru>; from Artem Koutchine on Mar 19, 1997 15:42:52 +0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Btw., freebsd.org is the correct domain.) As Artem Koutchine wrote: > Maybe I am a little bit out of date, but the fact is that i got 2CD > installations of FreeBSD 2.1.0 and i Have a Pentium PC with > tomato motherboard (HX chipset) and 8x ATAPI CD-ROM (LG exGoldStar). Yes, you are -- out of date. Use FreeBSD 2.2R if you wanna use an ATAPI CD-ROM device (soon to appear on CDs). -- 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 Mar 22 09:52:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA16556 for hackers-outgoing; Sat, 22 Mar 1997 09:52: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 JAA16541 for ; Sat, 22 Mar 1997 09:52:35 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA08745 for hackers@freebsd.org; Sat, 22 Mar 1997 18:52:33 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id SAA27615; Sat, 22 Mar 1997 18:33:24 +0100 (MET) Message-ID: <19970322183324.GD15929@uriah.heep.sax.de> Date: Sat, 22 Mar 1997 18:33:24 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <8205.858809260@time.cdrom.com>; from Jordan K. Hubbard on Mar 19, 1997 14:07:40 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > What's the latest technology on previewing MSword stuff under FreeBSD? I've seen a utility named `catdoc' or such, that does a pretty good job extracting the meat from a Word document. It's been written by some Russian guy, i might have laying it around somewhere. It's for sure a bunch better than the old `strings docfile' previewer, but it currently hardcodes the Cyrillic or Latin-1 character tables (as a compile-time option). If you wanna pay money, Applixware for Linux (distributed by RedHat) runs fairly well on FreeBSD 2.2, and can read Word and other stuff. People keep telling me that it runs *way* faster than StarOffice. I've even heard someone claiming it runs faster on FreeBSD than on Linux *grin*. -- 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 Mar 22 10:00:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA18104 for hackers-outgoing; Sat, 22 Mar 1997 10:00:01 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA18089 for ; Sat, 22 Mar 1997 09:59:56 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33]) by relay-5.mail.demon.net id aa0511179; 22 Mar 97 17:58 GMT Received: from localhost (dfr@localhost) by kipper.nlsystems.com (8.8.5/8.8.5) with SMTP id RAA15610; Sat, 22 Mar 1997 17:56:49 GMT Date: Sat, 22 Mar 1997 17:56:49 +0000 (GMT) From: Doug Rabson X-Sender: dfr@kipper.nlsystems.com Reply-To: Doug Rabson To: Terry Lambert cc: Doug Rabson , msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: Kernel configuration futures (Was Re: wd driver questions) In-Reply-To: <199703211759.KAA15960@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, 21 Mar 1997, Terry Lambert wrote: > > > > You don't really need ELF for this, actually. If a driver module > > registers itself with sysinit, then it can be just added to the kernel > > link if you want it statically loaded. When loading the module > > dynamically, the kernel should run any sysinits contained in the > > module at load time. The module doesn't need to act differently in > > the two cases. > > Yes... the difference is, I want to be able to pull a module from > an already linked kernel, and to do that, I have to deagregate the > linker set data agregated from that module. 8-(. I think that in the long run, this might be useful but only marginally. The only modules which should be included in the static kernel are ones which will be used. Including dozens of drivers in the kernel only to ditch them later is just wasteful. It also seems to me that to be able to discard a module from the static kernel, you would need to pad all its sections to VM pages so that you can re-use the pages. This also sounds wasteful. > > > > > This also lets me do things like "module TCP requires module IP" (for > > > one example). > > > > Hmm. Somehow I doubt that many people would load IP without TCP :-). > > Novell? TCP/IPX... 8-) 8-). That is the other way around, TCP without IP. Is that possible? I thought the normal streaming protocol for IPX was SPX or something. I know very little about Novell.. > > > > Dependancies in general would be useful for modules. That is probably > > where ELF has the edge. For instance, to get back the NFS example, > > both the client and the server share some utility code for doing RPC. > > If there were three modules, this works nicely: > > > > nfs_rpc_mod.o # RPC support code for client and server > > nfs_mod.o # NFS client, depends on nfs_rpc_mod.o > > nfs_serv_mod.o # NFS server, depends on nfs_rpc_mod.o > > > > When loading nfs_mod.o or nfs_serv_mod.o, nfs_rpc_mod.o would load > > automatically if not already present. > > This could be done by moving the link/load phase into the kernel, > actually, without needing ELF. The ELF issues come into play when > you want to reclaim space after an unload, or otherwise defrag your > VM. I'm loathe to put each driver in its own unique VM for obvious > overhead reasons (cv: "MACH vs. CHORUS" ad infinitum). The link/load should definately be in the kernel. I firmly believe that the cost of the runtime symbol tables is well worth the gain of allowing inter-module dependancies, and kernel-initiated module loads. > > > > See my other reply. I think the restrictions of running in the loader > > (size and non-interrupt-driven i/o) make the use of a full-blown > > filesystem impractical. > > Depends on how well defined the VFS bottom end becomes. I think the > current state of affairs in this regard is abysmal... there are some > 120 or so kernel interfaces required to support the full Heidemann > framework. This is an unacceptable bottom end. Any changes to this area are going to take far too long. I want to get something practical and small working fairly quickly. Bells and whistles can come later. > > > > For PCI, PnP etc, I still think there needs to be a registry. The > > registry would have a mapping from pci device id to driver module > > name. The alternatives are to embed the device id in the module name, > > giving something like dev_8086_1229_mod.o for the fxp driver or to > > load all known drivers and let the probes sort out which ids they > > match. Neither approach works very well. Some drivers support many > > device ids and the idea of loading all drivers and only keeping the > > ones which probe just doesn't scale very well. > > Or to load a "metaprobe" module that knows which modules to load based > on ID. 8-). That's how PnP services in Win95 operate, to some > extent; it's just that the module references a registry. But there's > no reason the module has to be implemented taht way. If you abstract > at that level, the implementation can be opaque. It *should* be > opaque so you don't have to have all your code working at once time to > test part of it. The reason I want the probe to be data-driven rather than code-driven (the way it is today) is to make installing a new driver trivial. > > Not convinced. I don't want to have to probe possibly hundreds of > > drivers when there are only a couple of devices in the system. It > > should work in the other direction. The PCI device scan gives a list > > of ids. These ids are looked up in the registry to find possible > > drivers and those drivers are loaded. The only code which is loaded > > is code which is likely to be needed. > > You don't need a registry for this (as above). If you don't like the > "metaprobe" idea, rather than scanning the registry, it could look > for an ELF segment "device data" in the files before it loaded them; > either way, a real registry is not really necessary. This would work I guess. It still means scanning all the drivers, opening the files etc. How does it get a complete list of drivers? One way might be to force all pci driver modules to be installed in a single directory (e.g. /lkm/pci/*.o or whatever). Even if the device id information is embedded in a section of the ELF file, I still think it is better to compile a single index file by scanning the drivers at install time. > > I like the idea of the registr not being boot critical because I like > the idea of putting the registry data into an LDAP server and doing > central administration on all my machines by operating against the > directory. If you require the registry, then you have to go full > branching (that's not an LDAP capability, you'd need the whole X.500, > which is a bear). It's the chicken-and-egg problem for network > authentication instances for UNIX systems. How do I authenticate > a kerberos ticket before I'm running processes which have credentials > without the ticket associated with them? This is the same problem > that UnixWare and NDS integration faced. Again, this is way in the future. Lets try and do something that is possible today, otherwise it will never get done. > > > The benefits are enormous... besides which, we fit in 4M again (who knows, > > > maybe even 2M!). > > > > Lets not get too optimistic. For the install disk, a lot of drivers > > still need to be present, either statically in the kernel or on the > > compiled-in MFS and that still takes up space. > > But they do not take up space in RAM, unless they are used (assuming > you have kernel paging support on at least a segment color boundry). The install floppy's MFS does take up space in RAM. For the install disk, it still makes sense to statically include as many drivers as possible. The GENERIC kernel that gets installed can be *much* simpler. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891 From owner-freebsd-hackers Sat Mar 22 10:54:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA24288 for hackers-outgoing; Sat, 22 Mar 1997 10:54:58 -0800 (PST) Received: from main.cyberzone-inc.com (root@main.cyberzone-inc.com [206.152.226.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24265 for ; Sat, 22 Mar 1997 10:54:51 -0800 (PST) Received: from win95 (pm1-18.cyberzone-inc.com [206.152.226.48]) by main.cyberzone-inc.com (8.7.3/8.7.3) with SMTP id NAA25212 for ; Sat, 22 Mar 1997 13:53:50 GMT Date: Sat, 22 Mar 1997 13:53:50 GMT Message-Id: <199703221353.NAA25212@main.cyberzone-inc.com> X-Sender: dean@206.152.226.1 X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hackers@FreeBSD.ORG From: "Dean Z. Douthat" Subject: AdvanSys SCSI boards Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi: Has anybody tested the driver for the AdvanSys ISA SCSI board? Has anybody converted the driver for PCI. The models are: ISA: AdvanSCSI ABP5140 PCI: AcvanSCSI ABP940 These boards seem to offer a lot of functionality at very good prices. TIA Dean Z. Douthat Osiris Business Systems PO Box 7571 Ann Arbor MI 48107-7571 VOX: +1(313)747-9170 FAX: +1(313)747-8478 dean@cyberzone-inc.com From owner-freebsd-hackers Sat Mar 22 10:55:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA24399 for hackers-outgoing; Sat, 22 Mar 1997 10:55:35 -0800 (PST) Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24366 for ; Sat, 22 Mar 1997 10:55:18 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33]) by relay-11.mail.demon.net id aa1115468; 22 Mar 97 18:22 GMT Received: from localhost (dfr@localhost) by kipper.nlsystems.com (8.8.5/8.8.5) with SMTP id SAA17008; Sat, 22 Mar 1997 18:21:35 GMT Date: Sat, 22 Mar 1997 18:21:35 +0000 (GMT) From: Doug Rabson X-Sender: dfr@kipper.nlsystems.com To: Terry Lambert cc: Doug Rabson , msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: wd driver questions In-Reply-To: <199703211740.KAA15929@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, 21 Mar 1997, Terry Lambert wrote: > > Interesting idea. Any chance of a design for such a system? > > It should take place in the vfs_init() (which doesn't have a macro op) > or the VFS_START() (which does). > > One problem here is that there is no corresponding "deinit"; it would > have to be defined. > > You would generate two classes of even initially: > > 1) VFSEVENT( type, fs) > > A VFS event of 'type' has occurred on the file system 'fs' > > 2) VOPEVENT( type, fs, vn) > > A vnode operation event of type 'type' has occurred on the > file system 'fs' affecting the file system vnode 'vn' > > This really goes back to defining the FS in terms of events and handling > of events... this needs to be done for generic support of soft updates > in all FS's, in any case. > > The "event management" would be a very generic subsystem in the > kernel, so an FS specific implementation is probably an error. The > lease code would be changed over to use "lease events" instead, and > the NFS would register to receive the events. If there were no NFS > server registration for lease events, then the events would be > ignored (all events for which there is not a handler are simply > ignored). For events with multiple handlers, all handlers are > called (two browser windows open on the same directory, and so on). > I supposed we could add an arbitrary "priority" field, and provide > the ability for a handler to "swallow" an event to make sure that it > does not propagate, but I'd rather not deal with inheritance issues > juset yet. Leasing is a bit different. The VOP_LEASE is used by the filesystem consumers to get read or write leases to the files before calling the other vops. I am not sure how this would fit into an event mechanism. > > Directory modification events would be pretty useful for the NFS > > server as well to extend the useful lifetime of NFS client cookies. > > The event would need to supply more information than just 'changed' > > since the seek values are still valid unless the directory was > > compacted. > > Yes; this is more like a "lock range decoelesce" for the modified > block. The client cookies in the "lock range" at the time of the > event would be invalidated. This would resolve the Sun NFSv3 > interoperability issue for the most part (there is still a potential > boundry condition, where BSD4.4 does directory truncation, and the > previous versions of UNIX and clone systems did not; but that's pretty > easy to deal with: if the cookie is past EOF, it's invalid). Life is slightly trickier for the NFS server since it doesn't keep track of the cookies which it has handed out. The client keeps track. It is hard for the server to distinguish between a cookie which is valid and one which was not affected by any recent directory modifications. Keeping track would involve too much complexity for very little gain, IMHO. It is still much easier to invalidate all the cookies on a compaction. What we can do is not invalidate the cookies when the directory is extended. That would help some clients. > > > If you are planning on doing any of this, I'm going to have to look > to see how much of my mount code changes made it in via Jeffrey Hsu; > the opportunity to modify the VFSOP operation is something that > merits *serious* design consideration... much of the original CSRG > work in the VFS integration was haphazard, IMO, and since we are no > longer under the legal pressures that caused them to have to cut > corners in the first place, we sould step back before diving in. I > would like to have input here, if you'll let me. > > [csrg deficiencies snipped] I will be doing at least some of this. I plan to spend the next several months working more or less full time on FreeBSD. It will make a nice change after the last two years hacking 3D graphics for Microsoft ;-). > > Actually, I expect the boot loader will have to be quite simple. To > > be practical, even with a 3 stage bootstrap the third stage will have > > to fit into 64k since it will need to use INT 13 for its disk access > > and our tools can't (and shouldn't) generate anything except tiny > > model programs. As a result, it will have severely truncated > > read-only file system support (see libsa from NetBSD). This is > > sufficient to load up the kernel. The boot will be discarded as soon > > as the kernel is entered. > > It's tempting to implement a protected mode VMM in the third stage boot; > have you seen: > > Protected Mode Software Architecture > _Tom Shandly_, MindShare, Inc. > Addison-Wesley Developers Press > ISBN 0-201-5447-X > > Yet? I haven't seen it; it sounds interesting. I will wander down to Foyles and see if I can find a copy. It may well be tempting to implement a VMM in the boot but I still think that it is overkill. The purpose of the boot code is to load the kernel and nothing else. If that can be done with a simple non-VMM bit of code then that is how it should be done. Boot code is hard to debug at the best of times so it should be kept small and simple IMHO. > > > > I was reading through libsa and our boot code yesterday and I believe > > that a 3 stage bootstrap for biosboot would be pretty easy. If the > > third stage was written using libsa then life would be much easier > > when writing an ELF loader. The filesystem and file descriptor > > support in libsa mimic normal syscalls making it possible to write and > > test the loader in userland before changing the bootstrap. > > Yes; I would like to see the objects move between the systems, actually, > which is why I was talking about a vnode-as-fd based kernel file I/O > subsystem with Mike the other day. Do you mean replacing the struct file with struct vnode? That seems worthwhile but is really best treated as a totally different piece of work. > > > > I for one find fiddling with the bootstrap a hair raising experience. > > I have some bad memories from the 386bsd days with bootstraps and > > disklabels. Shudder. > > Well, this is an issue for "device arrival" events (implied on a > "probe true" for a physical device) which are handled by a device > mapping layer handler. Used in conjunction with a devfs, this would > "magically" solve all the partition and diskslice and ... problems. > > I've discussed this before, but in case it wasn't obvious how the > algorithm could work, here's a 50,000 foo view of the idea: > > [more interesting stuff snipped] Again, I don't want to go too fast with this. Revamping disk partitioning and proper support for removable devices can come later. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891 From owner-freebsd-hackers Sat Mar 22 11:27:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA26286 for hackers-outgoing; Sat, 22 Mar 1997 11:27:49 -0800 (PST) Received: from aviion.ts.kiev.ua (aviion.ts.kiev.ua [193.124.229.12]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA26275 for ; Sat, 22 Mar 1997 11:27:37 -0800 (PST) Received: from nbki.ipri.kiev.ua by aviion.ts.kiev.ua with ESMTP id TAA17467; (8.6.11/zah/2.1) Sat, 22 Mar 1997 19:26:15 GMT Received: from cki.ipri.kiev.ua by nbki.ipri.kiev.ua with ESMTP id VAA22732; (8.6.9/zah/1.1) Sat, 22 Mar 1997 21:16:30 GMT Received: from 194.44.146.14 (mac.ipri.kiev.ua [194.44.146.14]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with SMTP id VAA19244; Sat, 22 Mar 1997 21:22:19 +0200 (EET) Message-ID: <333423C1.7BAF@cki.ipri.kiev.ua> Date: Sat, 22 Mar 1997 21:24:01 +0300 From: Ruslan Shevchenko Reply-To: rssh@cki.ipri.kiev.ua Organization: IPRI X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K) MIME-Version: 1.0 To: Joerg Wunsch CC: hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> <19970322183324.GD15929@uriah.heep.sax.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > As Jordan K. Hubbard wrote: > > > What's the latest technology on previewing MSword stuff under FreeBSD? > > I've seen a utility named `catdoc' or such, that does a pretty good > job extracting the meat from a Word document. It's been written by > some Russian guy, i might have laying it around somewhere. It's for > sure a bunch better than the old `strings docfile' previewer, but it > currently hardcodes the Cyrillic or Latin-1 character tables (as a > compile-time option). Can anybody give a links to catdoc & `string docfile' ? (about text processing : anybody know, is Linux SciTeXt work with Lesstif ? ) From owner-freebsd-hackers Sat Mar 22 12:31:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA28762 for hackers-outgoing; Sat, 22 Mar 1997 12:31:37 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA28756 for ; Sat, 22 Mar 1997 12:31:32 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id VAA00571 for FreeBSD-hackers@freebsd.org; Sat, 22 Mar 1997 21:31:20 +0100 (MET) From: Guido van Rooij Message-Id: <199703222031.VAA00571@gvr.win.tue.nl> Subject: random in kernel To: FreeBSD-hackers@freebsd.org (FreeBSD-hackers) Date: Sat, 22 Mar 1997 21:31:20 +0100 (MET) 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 see a random() in libkern. I'm wondering why we cannot use get_random_bytes() in stead. This gives a much better randomness.. -Guido From owner-freebsd-hackers Sat Mar 22 12:55:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA29663 for hackers-outgoing; Sat, 22 Mar 1997 12:55:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA29657 for ; Sat, 22 Mar 1997 12:55:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19437; Sat, 22 Mar 1997 13:42:24 -0700 From: Terry Lambert Message-Id: <199703222042.NAA19437@phaeton.artisoft.com> Subject: Re: Kernel configuration futures (Was Re: wd driver questions) To: dfr@render.com Date: Sat, 22 Mar 1997 13:42:24 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de In-Reply-To: from "Doug Rabson" at Mar 22, 97 05:56: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 > > Yes... the difference is, I want to be able to pull a module from > > an already linked kernel, and to do that, I have to deagregate the > > linker set data agregated from that module. 8-(. > > I think that in the long run, this might be useful but only marginally. > The only modules which should be included in the static kernel are ones > which will be used. Including dozens of drivers in the kernel only to > ditch them later is just wasteful. Say we include a VM86()-based INT 13 disk driver that will, by definition, work with all disk controllers that DOS, Windows, and NT can use. Because it is INT 13 based, it is single-threaded, and can not do overlapped I/O. Now say we have an Adaptec 2940 controller. We want to replace the universal, but inferior performing, driver with an Adaptec 2940 specific driver. How can we do this? Well, if we can't deagregate the INT 13 driver because of the way it is hooked in, then we can't do it. We have to rebuild the kernel. > It also seems to me that to be able to discard a module from the static > kernel, you would need to pad all its sections to VM pages so that you can > re-use the pages. This also sounds wasteful. You need to pad it's sections *in memory* to VM pages. If you physically pad them, then it will be wasteful of 0-511 bytes (assuming a frag size of 512 bytes and a sparse image file) and be a little faster. But you don't have to do it. That's why Sun supports VOP_GETPAGE and VOP_PUTPAGE. > > Novell? TCP/IPX... 8-) 8-). > > That is the other way around, TCP without IP. Is that possible? I > thought the normal streaming protocol for IPX was SPX or something. I > know very little about Novell.. The normal one is SPX. Their internet proxy server runs over TCP/IPX and gates to TCP/IP. > The link/load should definately be in the kernel. I firmly believe that > the cost of the runtime symbol tables is well worth the gain of allowing > inter-module dependancies, and kernel-initiated module loads. Well, that's two of us. 8-). > > > See my other reply. I think the restrictions of running in the loader > > > (size and non-interrupt-driven i/o) make the use of a full-blown > > > filesystem impractical. > > > > Depends on how well defined the VFS bottom end becomes. I think the > > current state of affairs in this regard is abysmal... there are some > > 120 or so kernel interfaces required to support the full Heidemann > > framework. This is an unacceptable bottom end. > > Any changes to this area are going to take far too long. I want to get > something practical and small working fairly quickly. Bells and whistles > can come later. That still lets us have a set of non-VFS-based vn_* file I/O routines. The only difference is whether the vnode from one of these is allowed to persist over the changeover to the other vn_* routines. vn_* is a small enough spanning set of functions for an agegate interface that can operate in both real and protected mode with little overhead. If the real mode code keeps the path on vn_open's, they can be reopened in protected mode without losing. Actually sharing the code can come later, but sharing the interface ought to be considered up front. > > You don't need a registry for this (as above). If you don't like the > > "metaprobe" idea, rather than scanning the registry, it could look > > for an ELF segment "device data" in the files before it loaded them; > > either way, a real registry is not really necessary. > > This would work I guess. It still means scanning all the drivers, opening > the files etc. How does it get a complete list of drivers? One way might > be to force all pci driver modules to be installed in a single directory > (e.g. /lkm/pci/*.o or whatever). Even if the device id information is > embedded in a section of the ELF file, I still think it is better to > compile a single index file by scanning the drivers at install time. Or delete non-essential drivers at install time (move them to another directory, etc., instead of really deleting them). Do you really want to have to build a registry before you build the rest of the code? 8-). > The install floppy's MFS does take up space in RAM. For the install disk, > it still makes sense to statically include as many drivers as possible. > The GENERIC kernel that gets installed can be *much* simpler. Well, I'd say "driver disk now, fallback drivers later" to handle this one... that way you include "support for as many drivers as possible" without actually including "as many drivers as possible". THe additional disk would be a nice annoyance to promote fallback driver developement. 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 Sat Mar 22 13:09:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA00312 for hackers-outgoing; Sat, 22 Mar 1997 13:09:26 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA00304 for ; Sat, 22 Mar 1997 13:09:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19471; Sat, 22 Mar 1997 13:56:00 -0700 From: Terry Lambert Message-Id: <199703222056.NAA19471@phaeton.artisoft.com> Subject: Re: wd driver questions To: dfr@nlsys.demon.co.uk (Doug Rabson) Date: Sat, 22 Mar 1997 13:55:59 -0700 (MST) Cc: terry@lambert.org, dfr@render.com, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de In-Reply-To: from "Doug Rabson" at Mar 22, 97 06:21:35 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 > Leasing is a bit different. The VOP_LEASE is used by the filesystem > consumers to get read or write leases to the files before calling the > other vops. I am not sure how this would fit into an event mechanism. event_send( LEASE_REQUEST) -> <- event_reply( LEASE_GRANT) A reply is an event to a handler specified in the send (the event source instance, in C++ terms, with 'this' being passed as one of the event arguments...). > Life is slightly trickier for the NFS server since it doesn't keep track > of the cookies which it has handed out. The client keeps track. It is > hard for the server to distinguish between a cookie which is valid and one > which was not affected by any recent directory modifications. Keeping > track would involve too much complexity for very little gain, IMHO. This was not my meaning on lock range decoelesce. I was thinking in terms of a generation count in each directory block, maybe, as an implementation detail. > It is still much easier to invalidate all the cookies on a compaction. > What we can do is not invalidate the cookies when the directory is > extended. That would help some clients. This really depends on what FS events the SunOS NFS client is really implicitly modelling by it's behavior. We know that a directory modification that reorders or removes the referenced entry in a block containing a given cookie is one. We *don't* know under what circumstances it will *correctly* back off and reread. Really, we need a contact at Sun for this one... 8-(. > > Yes; I would like to see the objects move between the systems, actually, > > which is why I was talking about a vnode-as-fd based kernel file I/O > > subsystem with Mike the other day. > > Do you mean replacing the struct file with struct vnode? That seems > worthwhile but is really best treated as a totally different piece of > work. Well, if the interface is the same in the protected mode kernel and the boot support library, then the consumer code can be shared, even if we don't go so far as to share actual implementation beyond that. One problem here is that vnode's are seperate from in core inodes, and the probably shouldn't be (vclean re-rear's it's ugly head). Fixing this means adding a VOP_VRELE() for per FS vnode release, for when the inode and vnode pool are per FS, and the same entity. It implies a lot of things, like reference counting all vnodes that come out of the VFS barrier, including directory name cache references, as if they were "open" instances. > Again, I don't want to go too fast with this. Revamping disk partitioning > and proper support for removable devices can come later. Heh. Sorry... got carried away from finding a sympathetic ear. 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 Sat Mar 22 13:24:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01170 for hackers-outgoing; Sat, 22 Mar 1997 13:24:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA01165 for ; Sat, 22 Mar 1997 13:24:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19505; Sat, 22 Mar 1997 14:12:16 -0700 From: Terry Lambert Message-Id: <199703222112.OAA19505@phaeton.artisoft.com> Subject: Re: DATA_SET and SYSINIT manpages missing To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sat, 22 Mar 1997 14:12:16 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199703221323.OAA10666@labinfo.iet.unipi.it> from "Luigi Rizzo" at Mar 22, 97 02:23: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 > could someone write manpages (9) for the DATA_SET and SYSINIT macros > (possibly with an example of use) ? They seem to be missing from > section 9 of the manual in 2.2-R , but they are used in almost all > device drivers and it is quite hard to figure out how they should be > used (other than by imitating an existing driver -- a Bad Thing IMHO > because one ends out writing code that he doesn't understand and might > be used by others as a model ... ) The DATA_SET stuff is probably best written by Garrett, who I believe implemented it in the first place. All it is is a set of macros to get at the GNU "linker set" abstraction without forcing the user to code in assembly language. Since linker sets were introduced for C++ constructors for virtual base classes, and similar things, it's likely that they are described in the G++/GLD documentation. I don't remember who integrated the SYSINIT stuff; I'm the one who originally wrote it. Probably the integrator would be the person to do the job (I originally wrote the LKM stuff, too, and it's mutated out of all proportion). One of the problems with it is that my initial presentation was alpha level code, but it was quickly integrated anyway. There were a lot of things in it that I would not have done in "real" code (it was more a proof of concept thing). Because it was integrated instead of commented on, I never had a chance to rev. the stuff, so whoever did the integration did a rev. (that I probably should have been tasked with) in the process. 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 Mar 22 13:51:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02258 for hackers-outgoing; Sat, 22 Mar 1997 13:51:09 -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 NAA02251 for ; Sat, 22 Mar 1997 13:51:01 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA11403 for hackers@freebsd.org; Sat, 22 Mar 1997 22:51:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA29490; Sat, 22 Mar 1997 22:38:51 +0100 (MET) Message-ID: <19970322223851.RA46875@uriah.heep.sax.de> Date: Sat, 22 Mar 1997 22:38:51 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@freebsd.org Subject: Re: MSWord docs... References: <8205.858809260@time.cdrom.com> <19970322183324.GD15929@uriah.heep.sax.de> <333423C1.7BAF@cki.ipri.kiev.ua> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <333423C1.7BAF@cki.ipri.kiev.ua>; from Ruslan Shevchenko on Mar 22, 1997 21:24:01 +0300 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Ruslan Shevchenko wrote: > Can anybody give a links to catdoc & `string docfile' ? As for catdoc, i've got the source somewhere on my machine at work, saved from a Usenet article. I have to remember to dig it up there, then i can post it here (it's fairly tiny). Well, `strings docfile' is just this: `strings docfile'. Simply run strings(1) on the .doc file. :-) -- 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 Mar 22 14:02:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA02740 for hackers-outgoing; Sat, 22 Mar 1997 14:02:38 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA02732 for ; Sat, 22 Mar 1997 14:02:29 -0800 (PST) Received: from awfulhak.demon.co.uk ([158.152.17.1]) by relay-6.mail.demon.net id aa0600031; 22 Mar 97 21:57 GMT Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id LAA25922; Sat, 22 Mar 1997 11:07:48 GMT Message-Id: <199703221107.LAA25922@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Matthew D. Fuller" cc: Benn Horton , hackers@freebsd.org Subject: Re: Modem driver needed. In-reply-to: Your message of "Thu, 20 Mar 1997 21:46:25 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Mar 1997 11:07:48 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > One problem I had is that my modem's non-standard, so I don't know the > command to write the current config to the firmware, so I have to re-send > the AT commands every time I bootup. > The normal line is at&c1&d3&k3&q6 s0=1 &w Normal for you maybe :) > the &w normall writes the config to the modem firmware, but mine doesn't > so I have to take off those last 2 characters, and redo it every bootup. > That's about the only problem I can see that you might have. > If anyonw has an idea what my AT sequence to save to firmware is, I'd be > grateful. I have a Compaq Presario 9000 series, with a 28.8 modem. You could try &w1 instead.... doesn't the modem support AT&? or AT&$ ? Otherwise, you'll need a manual. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Mar 22 14:04:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA02865 for hackers-outgoing; Sat, 22 Mar 1997 14:04:50 -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 NAA02637 for ; Sat, 22 Mar 1997 13:59:43 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id WAA18632; Fri, 21 Mar 1997 22:19:24 GMT Message-Id: <199703212219.WAA18632@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Daniel O'Callaghan" cc: Doug Rabson , hackers@freebsd.org Subject: Re: tun0/user ppp lockups? In-reply-to: Your message of "Fri, 21 Mar 1997 22:50:09 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 22:19:24 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > On 21 Mar 1997, Doug Rabson wrote: > > > I have been using mpd recently with some success. I had a couple of > > problems with it which I will try to feed back to the author this > > weekend but it seems basically sound. The code quality seems much > > better than ppp but it does miss out on a couple of features (term, > > packet filtering, aliasing). If you need them, you can always use > > ipfw, I guess. > > Considering the same author wrote the divert(4) code for ipfw, which has > led to Charles Mott's aliasing code being turned into a divert(4)-using > natd, I think this was Archie's intention. Whistle wrote a natd > themselves for the Interjet, but only released divert(4) and mpd of the > Interjet, not the natd. (I'm sure Julian or Archie will correct me if I'm > wrong). > > Danny Yeeeesss, I never did understand Whistle's reasons for leaving the divert(4) stuff in "limbo" and *hinting* at it being useful. I suspect there were reasons that ought'nt to be discussed. I *am* interested in getting ppp into a solid state. I lack a bit of experience (and time) in this environment (*frown*), but I'm getting the hang of things. mpd capabilities would be nice :) -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Mar 22 19:00:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA16692 for hackers-outgoing; Sat, 22 Mar 1997 19:00:30 -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 TAA16687 for ; Sat, 22 Mar 1997 19:00:28 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA20927; Sat, 22 Mar 1997 18:59:47 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma020925; Sat Mar 22 18:59:24 1997 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id SAA25573; Sat, 22 Mar 1997 18:59:24 -0800 (PST) From: Archie Cobbs Message-Id: <199703230259.SAA25573@bubba.whistle.com> Subject: Re: tun0/user ppp lockups? In-Reply-To: <199703212219.WAA18632@awfulhak.demon.co.uk> from Brian Somers at "Mar 21, 97 10:19:24 pm" To: brian@awfulhak.demon.co.uk (Brian Somers) Date: Sat, 22 Mar 1997 18:59:24 -0800 (PST) Cc: danny@panda.hilink.com.au, dfr@render.com, 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 > Yeeeesss, I never did understand Whistle's reasons for leaving the divert(4) > stuff in "limbo" and *hinting* at it being useful. I suspect there were > reasons that ought'nt to be discussed. Well.. there's no conspiracy or anything. I wrote the divert code simply because it made it possible to completely separate the PPP stuff from the address translation stuff, which made development alltogether easier. It was only in "limbo" in the sense that for a while we seemed to be the only people using it :-) I wanted to release the address translation code as well but that was put on hold in order to protect our "competitive advantage" or some silliness like that... :-) Also, divert sockets are more generally useful for things like encryption, packet snooping, or whatever. The hope is that people find them useful for doing creative experiments, prototyping, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Sat Mar 22 20:30:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA21433 for hackers-outgoing; Sat, 22 Mar 1997 20:30:51 -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 UAA21427 for ; Sat, 22 Mar 1997 20:30:47 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id UAA04266; Sat, 22 Mar 1997 20:30:37 -0800 (PST) Message-Id: <199703230430.UAA04266@austin.polstra.com> To: jb@cimlogic.com.au Subject: Re: libc_r Newsgroups: polstra.freebsd.hackers In-Reply-To: <199703220633.RAA15734@freebsd1.cimlogic.com.au> References: <199703220633.RAA15734@freebsd1.cimlogic.com.au> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Sat, 22 Mar 1997 20:30:37 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199703220633.RAA15734@freebsd1.cimlogic.com.au>, John Birrell wrote: > I think there are enough people using libc_r now to enable it > permanently in sys/lib/Makefile, leaving an environment variable > to turn it off. I agree. In fact, I don't think there's even a need for an evironment variable to disable it. -- 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 Sat Mar 22 21:56:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA24778 for hackers-outgoing; Sat, 22 Mar 1997 21:56: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 VAA24772 for ; Sat, 22 Mar 1997 21:56:32 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id FAA18935; Sun, 23 Mar 1997 05:54:12 GMT Message-Id: <199703230554.FAA18935@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: danny@panda.hilink.com.au, dfr@render.com, hackers@freebsd.org Subject: Re: tun0/user ppp lockups? In-reply-to: Your message of "Sat, 22 Mar 1997 18:59:24 PST." <199703230259.SAA25573@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Mar 1997 05:54:11 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Yeeeesss, I never did understand Whistle's reasons for leaving the divert(4) > > stuff in "limbo" and *hinting* at it being useful. I suspect there were > > reasons that ought'nt to be discussed. > > Well.. there's no conspiracy or anything. I wrote the divert code > simply because it made it possible to completely separate the PPP > stuff from the address translation stuff, which made development > alltogether easier. It was only in "limbo" in the sense that for > a while we seemed to be the only people using it :-) I wanted to > release the address translation code as well but that was put on > hold in order to protect our "competitive advantage" or some > silliness like that... :-) The only problem is with dynamic IPs. What we really need is the capability to trigger events that will tell natd (or whatever) when an interface has been "changed"..... Then, natd could sit on an interface and do really smart things rather than getting confused/restarted with every ifconfig. Currently, natd could figure things out for incoming packets by looking at the "from" address given by recvfrom(), but it has no chance with outgoing packets ("from" is 0.0.0.0). Maybe "from" should be changed to be #define DIVERT_MAGIC ((u_char)123) #define DIR_IN 1 #define DIR_OUT 2 struct sockaddr_divert { u_char sa_len; u_char sa_family; u_short sin_port; struct in_addr sin_addr; u_char direction; u_char divert_magic; char sin_zero[6]; } Nice & compatible with sockaddr_in, and with the address of the interface in question available in sin_addr, natd can "notice" that it's been changed. I would think the divert_magic bit is necessary so that the application can tell if it's dealing with an old or new kernel (sockaddr_in/sockaddr_divert). Are there any major problems here that I'm missing ? -- Brian , Don't _EVER_ lose your sense of humour....