From owner-freebsd-hackers Sun Oct 22 00:15:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA27701 for hackers-outgoing; Sun, 22 Oct 1995 00:15:06 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA27685 for ; Sun, 22 Oct 1995 00:15:00 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA23370; Sun, 22 Oct 1995 16:41:03 +1000 Date: Sun, 22 Oct 1995 16:41:03 +1000 From: Bruce Evans Message-Id: <199510220641.QAA23370@godzilla.zeta.org.au> To: jkh@time.cdrom.com, pst@shockwave.com Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >Just FYI, it's never been mine. I routinely use structure >initializers that only gcc grocks, and have even been known to do the >occasional: > { > char foo[n]; > .. > } >To do the job of alloca.. Not that I use the latter construct very >often - I generally just use alloca directly, but the point is that if /usr/src/usr.sbin/config/main.c:120: warning: ANSI C forbids variable-size array `tmp' It's a nice feature, but it probably shouldn't be used without ifdefs in a bootstrapping utility, and using ifdefs negates the advantage of having it (you have to write ugly portable code _and_ ugly ifdefs _and_ code using the feature instead of just ugly portable code). Bruce From owner-freebsd-hackers Sun Oct 22 00:25:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA28025 for hackers-outgoing; Sun, 22 Oct 1995 00:25:46 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA28020 for ; Sun, 22 Oct 1995 00:25:44 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id AAA00557; Sun, 22 Oct 1995 00:24:13 -0700 Message-Id: <199510220724.AAA00557@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Heikki Suonsivu cc: Joe Greco , freebsd-hackers@freefall.FreeBSD.org Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. In-reply-to: Your message of "Sun, 22 Oct 1995 08:32:05 +0200." <199510220632.IAA12224@shadows.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Oct 1995 00:24:11 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> Heikki Suonsivu said: > Or one with routing technology which can prioritize customer's traffic > according to the price they pay. The technology isn't there yet, though I > have got a flakey proto written at HUT and I think someone else is also > working on similar modifications. I have also heard cisco planning to do > something like this. Well, the technology is here is called OSI TP4 which allows you to prioritize at least the interface level. Amancio From owner-freebsd-hackers Sun Oct 22 02:44:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01483 for hackers-outgoing; Sun, 22 Oct 1995 02:44:21 -0700 Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA01478 for ; Sun, 22 Oct 1995 02:44:19 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id CAA16433 for hackers@freebsd.org; Sun, 22 Oct 1995 02:45:03 -0700 From: Brian Litzinger Message-Id: <199510220945.CAA16433@MediaCity.com> Subject: linux emulations how to? To: hackers@freebsd.org Date: Sun, 22 Oct 1995 02:45:03 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 542 Sender: owner-hackers@freebsd.org Precedence: bulk I compiled a -current kernel with COMPAT_LINUX and booted it. I got ld.so and shlibs from linux/slackware-2.3 and put it in /compat/linux/lib I modload -e linux_init /lkm/linux_mod.o Then I # ./linuxxdoom zsh: segmentation fault (core dumped) ./linuxxdoom Where did I go wrong? Thanks, -- Brian Litzinger | | brian@mediacity.com | This space intentionally left blank | http://www.mpress.com | | From owner-freebsd-hackers Sun Oct 22 03:09:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA02120 for hackers-outgoing; Sun, 22 Oct 1995 03:09:41 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA02115 for ; Sun, 22 Oct 1995 03:09:31 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id LAA02092 ; Sun, 22 Oct 1995 11:09:22 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id LAA15941 ; Sun, 22 Oct 1995 11:09:21 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id LAA04443; Sun, 22 Oct 1995 11:08:18 +0100 (MET) From: Ollivier Robert Message-Id: <199510221008.LAA04443@keltia.freenix.fr> Subject: Re: linux emulations how to? To: brian@MediaCity.com (Brian Litzinger) Date: Sun, 22 Oct 1995 11:08:18 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199510220945.CAA16433@MediaCity.com> from "Brian Litzinger" at Oct 22, 95 02:45:03 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1224 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Brian Litzinger said: > I got ld.so and shlibs from linux/slackware-2.3 and put it in > /compat/linux/lib My libraries are these : total 2242 -rwxr-xr-x 1 root wheel 17412 Mar 6 1995 ld.so* -rwxr-xr-x 1 root wheel 320516 May 28 23:30 libX11.so.3* -r-xr-xr-x 1 root wheel 529412 Oct 14 19:57 libX11.so.6* -rwxr-xr-x 1 root wheel 291844 May 28 23:30 libXt.so.3* -r-xr-xr-x 1 root wheel 320516 Oct 14 19:57 libXt.so.6* -rwxr-xr-x 1 root wheel 623620 Mar 6 1995 libc.so.4* -rwxr-xr-x 1 root wheel 107524 Mar 6 1995 libm.so.4* The .6 are for Abuse. > I modload -e linux_init /lkm/linux_mod.o > Then I > > # ./linuxxdoom > zsh: segmentation fault (core dumped) ./linuxxdoom Do you have SYSVSHM in your kernel ? 812 [11:04] root@keltia:xdomm/doom-1.8# modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 2 f0b06000 0018 f0b0b000 1 linux_emulator VFS 1 14 f0cff000 0019 f0d041e0 1 cd9660 814 [11:04] root@keltia:xdomm/doom-1.8# ./xdoom DOOM System Startup v1.8 V_Init: allocate screens. M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. W_Init: Init WADfiles. adding ./doom1.wad shareware version. M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [...................] P_Init: Init Playloop state. I_Init: Setting up machine state. Could not start sound server [sndserver] D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. HU_Init: Setting up heads up display. ST_Init: Init status bar. Using MITSHM extension shared memory id=655360, addr=0x802c000 -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #0: Sat Oct 14 19:05:10 MET 1995 From owner-freebsd-hackers Sun Oct 22 04:14:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA03776 for hackers-outgoing; Sun, 22 Oct 1995 04:14:57 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA03770 for ; Sun, 22 Oct 1995 04:14:49 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) id MAA22506 for hackers@freebsd.org; Sun, 22 Oct 1995 12:13:26 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id NAA00300 for ; Sat, 21 Oct 1995 13:10:01 +0100 Date: Sat, 21 Oct 1995 13:10:00 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: FreeBSD stable dies when mounting /tmp as MFS twice (light weight prosa :-) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! Today I had magic fingers... :-) Perhaps one could / should (?) add some sanity checks into the "mount MFS" code that prevent attempts to mount a MFS twice ?! The situation: I had /tmp configured to be MFS mounted. Added /var/tmp to fstab, to be MFS mounted, too. Then I entered the command mount -at mfs and the system crashed within 5 seconds showing the following messages: Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:4 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:3 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:3 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:2 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:2 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:tries:3 Oct 21 12:00:48 knobel /kernel: etries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): verlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , retries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 OverlaD asc:4e,0 Overlapped commands a Oct 21 12:00:48 knobel /kernel: , FAILURE Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , FAILURE Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , retries:4 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , re0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:1 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , FAILURE Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped comme,0 Overlapped commands attemptes:4 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:4 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:8nds attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , FAILUREBORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:2 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , FAILURE Oct 21 12:00:50 knobel /kernel: sd0(ah Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: ries:3 Oct 21 12:00:51 knobel /kernel: sd0( $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Sun Oct 22 05:00:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04526 for hackers-outgoing; Sun, 22 Oct 1995 05:00:41 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA04521 ; Sun, 22 Oct 1995 05:00:38 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.12/8.6.9) id FAA22012; Sun, 22 Oct 1995 05:00:22 -0700 Date: Sun, 22 Oct 1995 05:00:22 -0700 From: "Jordan K. Hubbard" Message-Id: <199510221200.FAA22012@time.cdrom.com> To: announce@freebsd.org Subject: package installer menu in new sysinstall Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk Reply-To: hackers@freebsd.org Please stay away from it for now.. It's got some problems that I'm working on and probably will NOT work in the FTP installation scenarios that most of you are using, sorry about that! I should have it fixed tonite, it's just that other problems (which are now also fixed) sort of kept me away from the package extraction menu until now.. Jordan From owner-freebsd-hackers Sun Oct 22 05:22:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA05256 for hackers-outgoing; Sun, 22 Oct 1995 05:22:57 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA05251 for ; Sun, 22 Oct 1995 05:22:55 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id VAA00244; Sun, 22 Oct 1995 21:46:10 +0930 From: Michael Smith Message-Id: <199510221216.VAA00244@genesis.atrad.adelaide.edu.au> Subject: Re: Bragging rights.. To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Sun, 22 Oct 1995 21:46:09 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, davidg@root.com, root@spiffy.cybernet.com, hackers@freebsd.org In-Reply-To: <199510201024.FAA29169@brasil.moneng.mei.com> from "Joe Greco" at Oct 20, 95 05:24:46 am Content-Type: text Content-Length: 1682 Sender: owner-hackers@freebsd.org Precedence: bulk Joe Greco stands accused of saying: > > The PC16550D (The "reference" part for 16550's) is specified to a 24MHz input > > clock. > > And here I always thought it was the National Semiconductor part that was > the "reference" part, because the 16550 was originally their fault. I still The PC16550D _is_ the NatSemi part. It supersedes the PC16550C, and thus the NC16550* range. The NS16550's haven't been available for some years now, AFAIK. If you have some you bought recently, check the fab date on them. > > The standard clock reference for this part in a PC is 1.8MHz. > > Decent serial card vendors (eg. Quatech) offer jumper-selectable clock > > dividers to allow you to pick your desired clock rate. > > I have yet to see this on any reasonably-priced card :-( Fortunately, > it's a cheap upgrade to do if you're handy with a soldering iron.. Likewise, which is why we fork out >$100 for these ones. (They're absolutely everything you could ever want in a serial card; jumperable IRQ overy every imaginable value, switch-selectable base addresses in increments of 8 from 0x0 to 0x400, optional open-collector interrupt outputs, jumperable DTE/DCE pinouts, 18MHz bit clock dividable by 1, 2 5 or 10... rah rah rah 8) > Joe Greco - Systems Administrator jgreco@ns.sol.net -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Sun Oct 22 05:40:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA05978 for hackers-outgoing; Sun, 22 Oct 1995 05:40:06 -0700 Received: from knobel.gun.de (knobel-ip.gun.de [192.109.159.141]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA05959 for ; Sun, 22 Oct 1995 05:39:58 -0700 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id NAA00971 for ; Sun, 22 Oct 1995 13:36:17 +0100 Date: Sun, 22 Oct 1995 13:36:17 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: FreeBSD stable dies when mounting /tmp as MFS twice (light weight prosa :-) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! I'm remailing this, because I didn't see it in hackers mailing list after 24 hours ... $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< ---------- Forwarded message ---------- Date: Sat, 21 Oct 1995 13:10:00 +0100 (MET) From: Andreas Klemm To: hackers@freebsd.org Subject: FreeBSD stable dies when mounting /tmp as MFS twice (light weight prosa :-) Hi ! Today I had magic fingers... :-) Perhaps one could / should (?) add some sanity checks into the "mount MFS" code that prevent attempts to mount a MFS twice ?! The situation: I had /tmp configured to be MFS mounted. Added /var/tmp to fstab, to be MFS mounted, too. Then I entered the command mount -at mfs and the system crashed within 5 seconds showing the following messages: Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:4 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:3 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:3 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:2 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:2 Oct 21 12:00:47 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:47 knobel /kernel: , retries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:tries:3 Oct 21 12:00:48 knobel /kernel: etries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): verlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , retries:1 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 OverlaD asc:4e,0 Overlapped commands a Oct 21 12:00:48 knobel /kernel: , FAILURE Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , FAILURE Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:48 knobel /kernel: , retries:4 Oct 21 12:00:48 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , re0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:1 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , FAILURE Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped comme,0 Overlapped commands attemptes:4 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:4 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:49 knobel /kernel: , retries:3 Oct 21 12:00:49 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:8nds attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , FAILUREBORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:2 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: sd0(ahc0:0:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted sks:80,0 Oct 21 12:00:50 knobel /kernel: , FAILURE Oct 21 12:00:50 knobel /kernel: sd0(ah Oct 21 12:00:50 knobel /kernel: , retries:1 Oct 21 12:00:50 knobel /kernel: ries:3 Oct 21 12:00:51 knobel /kernel: sd0( $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Sun Oct 22 06:59:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA07162 for hackers-outgoing; Sun, 22 Oct 1995 06:59:47 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA07157 for ; Sun, 22 Oct 1995 06:59:44 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA22346 for ; Sun, 22 Oct 1995 06:59:28 -0700 To: hackers@freebsd.org Subject: User groups update? Date: Sun, 22 Oct 1995 06:59:28 -0700 Message-ID: <22344.814370368@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Hi all.. About 6 months ago, there was a lot of hoopla about forming FreeBSD user groups and such, and a few of this list's more intrepid members even went so far as to establish a few in different parts of the U.S. A successful "international conference" was also held in Aachen, and great congradulations are due Christoph Kukulies for pulling off what was apparently a very entertaining and successful event - sorry I couldn't make it!. Anyway, I just want to make sure that we're not losing steam in what is a very worth-while endevour: The formation of user groups for discussing and supporting FreeBSD. Look at it this way: We don't have a book, and as much as we'd like to we're just not going to have one for awhile. This therefore leaves email, word of mouth and user groups as the only ways of disseminating information. User groups have the added benefit of giving us hacker types something social to do occasionally, and you often learn far more from an evening of discussion with other hackers than you could in a week of reading email. For the more commercially inclined, user groups are also a great way of making potentially valuable contacts and are very worth-while indeed! Putting my money where my mouth is, I've long felt pretty bad that there's not even a FreeBSD user group here in the San Francisco bay area, where I live. I don't get the excuse to go to S.F. as often as I'd like as it is! :-) So I'd like to propose here and now that we start the San Francisco branch of the FreeBSD User Group (FUG), to meet sometime before October 30th - send me mail if you're interested in attending, and any preferred days and times. I'll set up the venue and take care of the other details. And no, I don't think we should call it the FreeBSD Users & Collected Kindred group.. :-) Jordan From owner-freebsd-hackers Sun Oct 22 08:34:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11199 for hackers-outgoing; Sun, 22 Oct 1995 08:34:37 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11192 for ; Sun, 22 Oct 1995 08:34:31 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA00961; Sun, 22 Oct 1995 10:33:27 -0500 From: Joe Greco Message-Id: <199510221533.KAA00961@brasil.moneng.mei.com> Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. To: dennis@etinc.com (dennis) Date: Sun, 22 Oct 1995 10:33:26 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510212251.SAA05887@etinc.com> from "dennis" at Oct 21, 95 06:51:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > >Cheating them? > > Yes. Because they think their getting 128k (or 115k) and they're only > getting 90K. Where is this 90K figure coming from? 115200 / 10 = 11520 bytes/second (or 11.25K) 115200 / 8 = 14400 bytes/second (or 14.06K) > Now if you TELL them that they're only getting 90K and thats what they're > paying for, > then thats OK...the way it should be. But if they think they're getting 115 > or 128k for > what their paying, then its being misrepresented. If I were to sell a customer an async ISDN line, they are getting precisely what they pay for. It is not being misrepresented. They are paying for, and receiving, 115k of async bandwidth. What is it about this that you have difficulty comprehending? > If I were your competitor my > Newspaper adds would read (get full 128k with ET (Joe only gives you 90K)) > I'd have so many more customers that I could eat the cost of the sync cards > and laugh my > way to the bank. And then to court (but hey, that's just me). Of course if you really think you would have so many more customers that you could afford to write off the cost of the sync cards, maybe it would be easier to just wait until you go under and take your customer base at that point. > >Buddy, in this business, people PAY for bandwidth. An ISP could really care > >less about the technology used to connect a customer's site - it only > >affects recurring monthly costs and startup costs, which are passed off to > >the customer anyways. What you're REALLY paying the ISP for is bandwidth! > >And if you drop in a technology that squeezes more data over the line, the > >ISP needs to take this into account in their overall strategy. A T1 can be > >split into over 30 64K async channels before reaching bandwidth overcommit, > >whereas it can only be split into 24 sync channels! That is a respectable > >impact on operations. > > Precisely. Charge for the bandwidth. You can charge MORE for sync, because > you get more. > I thought that the idea of being in business was to make money, one by having > value-added services, each of which I make a small margin, and the other to get > more customers by having something to offer that my competitor doesn't have. But who says the competitor doesn't offer it? It's just disproportionately expensive, which is why most people don't care to look into it. > I'm getting the > feeling that all of your customers must be residential, in which case you > may not have an opportunity. No, actually all of my customers are businesses, and are connected at rates that are at least Ethernet. This is purely an academic exercise :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Sun Oct 22 09:07:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA14465 for hackers-outgoing; Sun, 22 Oct 1995 09:07:25 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA14460 for ; Sun, 22 Oct 1995 09:07:20 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA07272; Sun, 22 Oct 1995 12:24:03 -0400 Date: Sun, 22 Oct 1995 12:24:03 -0400 Message-Id: <199510221624.MAA07272@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Heikki Suonsivu From: dennis@etinc.com (dennis) Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >BTW, I have a $1000 (minus possible taxes) reward available for the author >of a free driver for a commonly available synchronous serial card like SDL, >ET or Arnet. Ie. sources available and non-restrictive license (preferably >both GPL and Berkey to allow it to be included both in Linux and *BSD*). >Need to talk to ciscos (that is what usually is in the other end). Needs Add two 0's to this number and we can talk. We'll have it as part of our product very shortly, but....for the reasons that you just stated, no "right to steal" licenses available. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 09:23:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA21114 for hackers-outgoing; Sun, 22 Oct 1995 09:23:10 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA21083 for ; Sun, 22 Oct 1995 09:23:08 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id JAA25240 for ; Sun, 22 Oct 1995 09:21:59 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id MAA07304 for ; Sun, 22 Oct 1995 12:38:33 -0400 Date: Sun, 22 Oct 1995 12:38:33 -0400 Message-Id: <199510221638.MAA07304@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Sender: owner-hackers@freebsd.org Precedence: bulk Michael Smith brags... >> > The PC16550D (The "reference" part for 16550's) is specified to a 24MHz input >> > clock. >> >> And here I always thought it was the National Semiconductor part that was >> the "reference" part, because the 16550 was originally their fault. I still > >The PC16550D _is_ the NatSemi part. It supersedes the PC16550C, and >thus the NC16550* range. The NS16550's haven't been available for >some years now, AFAIK. If you have some you bought recently, check the >fab date on them. >Likewise, which is why we fork out >$100 for these ones. (They're >absolutely everything you could ever want in a serial card; jumperable >IRQ overy every imaginable value, switch-selectable base addresses in >increments of 8 from 0x0 to 0x400, optional open-collector interrupt >outputs, jumperable DTE/DCE pinouts, 18MHz bit clock dividable by 1, 2 5 or >10... rah rah rah 8) I really can't believe you guys are bragging about the widespread utilization of souped-up async. You still don't get the fact that you're losing several hundred dollars worth of machine (which brings the cost in-line with sync) to save a few hundred on cards for a less-efficient solution. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 09:45:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA27728 for hackers-outgoing; Sun, 22 Oct 1995 09:45:50 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA27719 for ; Sun, 22 Oct 1995 09:45:40 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA23476; Sun, 22 Oct 1995 09:45:12 -0700 Message-ID: <308A7517.3CB52305@FreeBSD.org> Date: Sun, 22 Oct 1995 09:45:11 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: dennis CC: Heikki Suonsivu , hackers@FreeBSD.org Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. References: <199510221624.MAA07272@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis wrote: > We'll have it as part of our product very shortly, but....for the reasons > that you just stated, no "right to steal" licenses available. That's OK. There are a number of other sync serial cards for which support is forthcoming (I've already directed Heikki at John Hay and the ARNET driver in progress) and for which all driver sources should be available. Given that we're supposed to be a full-source, free OS (and always interested in seeing sharing work with other OSs) I think that this is a good direction and I applaud Heikki for being willing enough to pony up a non-trivial amount of money. No, $1000 is not enough to even remotely tempt a company into doing support, but it may be just enough to push someone who was contemplating it anyway into writing a driver.. -- Jordan From owner-freebsd-hackers Sun Oct 22 10:06:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28101 for hackers-outgoing; Sun, 22 Oct 1995 10:06:06 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA28096 for ; Sun, 22 Oct 1995 10:06:03 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA23516; Sun, 22 Oct 1995 10:05:41 -0700 Message-ID: <308A79E5.64A99F5A@FreeBSD.org> Date: Sun, 22 Oct 1995 10:05:41 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: dennis CC: hackers@FreeBSD.org Subject: Re: Bragging rights.. References: <199510221638.MAA07304@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis wrote: > I really can't believe you guys are bragging about the widespread > utilization of souped-up async. You still don't get the fact that you're losing several > hundred dollars worth of machine (which brings the cost in-line with sync) to save a few > hundred on cards for a less-efficient solution. I think your view in these matters may be a little too narrow (which is probably fine, given the market you have your eye on - one man's narrow vision is another man's intense product focus :-). What we're talking about is *incremental* cost, which is very important to the low-budget folks. We're not talking about what we'd build if we had all the money up front to implement whatever solution would be most optimum - we're talking about how to get one's feet wet without going all the way in up to the neck on the first step. In my case, I had a pair of TAs readily available (did I mention that I haven't actually *purchased* these TAs yet? These two are loaners, pending me somehow getting the P.O. pushed through WC for the real ones) and 2 PCs just sitting there. I already had a PC dedicated to being a gateway anyway, so sparing the performance hit on that little 486 wasn't a consideration. If I'd had a 386 sitting in the corner, that would have done the job instead. So my only incremental cost were the TAs which, as I mention, haven't even technically become a cost yet. The rest was accomplished with a couple of standard serial cards and some cables. That's it. I didn't have to load any special drivers and I didn't have to buy any other hardware. Now that's just me, but I don't think that my situation is that unique. Let's assume I'm Joe Sixpack and even more budget constrained (all those cases of Miller High Life in the garage aren't cheap!). In that case I can go for a pair of the cheaper TAs out there (I think that even the async capable Bitsurfers are going down to around $450) in a month or two (about how long it will take PacBell to install my line) and try to scrounge a couple of PCs that nobody wants anymore anymore over at corporate (read: anything less woofy than a 486DX). That's called low incremental cost, and for many many home users that pretty much makes the difference between the "right" solution and the "right now" solution. Sure, I know I'm not getting my full pipe and that the async overhead is high, but do I care? Heck no! I'm still over the moon at being able to go substantially faster than V.34, and I suspect that Joe Sixpack would be too. That's why I asked about the cheapo version of a sync serial card. Let's talk 3 more months down the line and Joe has managed to raise a few more pennies by recycling all the aluminum beer cans from the back seat of his car.. All that money is burning a hole in his pocket and he's thinking "Hmmmm. If I could find a pair of cards for $200 or so that would let me get my last little 38.9%, I could definitely drink "lite" for another couple of weeks to make up for it." Again, incremental cost. You, as a marketing person, must surely appreciate that! "Suck 'em in cheap and keep 'em paying" must be one of the first lessons they teach at the P.T. Barnum Memorial University and I think it applies pretty squarely to this whole Internet fracas. The regional bells are pushing ISDN in a big way, and I think that's the next "upgrade" that all those legions of Internet addicts will next be contemplating. When they do, you may rest assured that they won't flock to the most expensive solutions available. I know, you've said that a cheap sync serial card is the least of your plans and you wouldn't touch ISDN with a stick. I'm not suggesting that YOU do this, merely that someone do. When they do, be it a cheap ISDN card or sync serial upgrade, Joe and I will probably be there with our checkbooks. -- Jordan From owner-freebsd-hackers Sun Oct 22 10:25:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28695 for hackers-outgoing; Sun, 22 Oct 1995 10:25:32 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA28689 ; Sun, 22 Oct 1995 10:25:29 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA07437; Sun, 22 Oct 1995 13:42:17 -0400 Date: Sun, 22 Oct 1995 13:42:17 -0400 Message-Id: <199510221742.NAA07437@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: RE: Freeware reward????? Cc: Heikki Suonsivu , hackers@FreeBSD.org, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan writes..... >dennis wrote: >> We'll have it as part of our product very shortly, but....for the reasons >> that you just stated, no "right to steal" licenses available. > >That's OK. There are a number of other sync serial cards for which support is >forthcoming (I've already directed Heikki at John Hay and the ARNET driver in progress) >and for which all driver sources should be available. "Freeware" drivers are not competition. They just eliminate the pikers. Given that most commercial companies have trouble doing commercially acceptable products in this area , whats the chance that some guy with way too much free time can do better? > Given that we're supposed to be a >full-source, free OS (and always interested in seeing sharing work with other OSs) I >think that this is a good direction and I applaud Heikki for being willing enough to pony >up a non-trivial amount of money. No, $1000 is not enough to even remotely tempt a >company into doing support, but it may be just enough to push someone who was >contemplating it anyway into writing a driver.. >-- Is this for the "best" resulting product, or the first? Or don't you care? Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 10:31:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28848 for hackers-outgoing; Sun, 22 Oct 1995 10:31:18 -0700 Received: from icicle (root@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA28843 for ; Sun, 22 Oct 1995 10:31:16 -0700 Received: from hal.winternet.com (ppp-66-43.dialup.winternet.com [204.246.66.43]) by icicle (8.6.12/8.6.12) with SMTP id MAA06536 for ; Sun, 22 Oct 1995 12:31:13 -0500 Posted-Date: Sun, 22 Oct 1995 12:31:13 -0500 Received: by hal.winternet.com (4.1/SMI-4.1+GPO.winter1) id AA11410; Sun, 22 Oct 95 12:27:14 CDT Date: Sun, 22 Oct 95 12:27:14 CDT Message-Id: <9510221727.AA11410@hal.winternet.com> To: hackers@freebsd.org Subject: Re: New record for installation floppy update! :-) From: glen@winternet.com Sender: owner-hackers@freebsd.org Precedence: bulk Is anybody with a 4M i386sx able to get the boot disks to work? This is what I get: rootfs is 1000 Kbyte compile in MFS (long pause) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf018c45d code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enableeed, resume, IPL = 0 current process = 1 (swapper) interrupt mask = net tty bio panic: page fault I retrieved the latest boot floppy from ftp.freebsd.org at noon Sunday: -rw-r--r-- 1 glen 1228800 Oct 22 10:04 boot.flp the past TWO boot disks have given an identical panic (the PC was the same) glen From owner-freebsd-hackers Sun Oct 22 10:39:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29119 for hackers-outgoing; Sun, 22 Oct 1995 10:39:19 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA29087 ; Sun, 22 Oct 1995 10:39:12 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id NAA07481; Sun, 22 Oct 1995 13:56:02 -0400 Date: Sun, 22 Oct 1995 13:56:02 -0400 Message-Id: <199510221756.NAA07481@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >dennis wrote: >> I really can't believe you guys are bragging about the widespread >> utilization of souped-up async. You still don't get the fact that you're losing several >> hundred dollars worth of machine (which brings the cost in-line with sync) to save a few >> hundred on cards for a less-efficient solution. > >I think your view in these matters may be a little too narrow (which is probably fine, >given the market you have your eye on - one man's narrow vision is another man's intense >product focus :-). > >What we're talking about is *incremental* cost, which is very important to the low-budget >folks. We're not talking about what we'd build if we had all the money up front to >implement whatever solution would be most optimum - we're talking about how to get one's >feet wet without going all the way in up to the neck on the first step. > I'm talking about incremental profit, a capitalist concept. Have something better in your bag of goddies that costs a few dollars more an month and people will buy it every time. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 10:45:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29462 for hackers-outgoing; Sun, 22 Oct 1995 10:45:56 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA29457 for ; Sun, 22 Oct 1995 10:45:55 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id KAA23167; Sun, 22 Oct 1995 10:45:42 -0700 From: Julian Elischer Message-Id: <199510221745.KAA23167@ref.tfs.com> Subject: Re: Freeware reward????? To: dennis@etinc.com (dennis) Date: Sun, 22 Oct 1995 10:45:41 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199510221742.NAA07437@etinc.com> from "dennis" at Oct 22, 95 01:42:17 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1148 Sender: owner-hackers@freebsd.org Precedence: bulk > "Freeware" drivers are not competition. They just eliminate the pikers. > Given that most > commercial companies have trouble doing commercially acceptable products in > this area > , whats the chance that some guy with way too much free time can do better? well, it depends on the guy :) > > > Is this for the "best" resulting product, or the first? Or don't you care? One interesting side effect of being a source-OS is that once the first version is written, other people improve on it till it becomes acceptable.. there are lots of people who don't feel competant to start a driver from scratch, but who would happily leap in and extend/modify an existing one.. so in fact the answer might actually be the "first resulting product", and "no we don't care", but only on the understanding that the product will be worked on by multitudes.. :) > > > Dennis > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com > > Synchronous Communications Cards and Routers For > Discriminating Tastes. 56k to T1 and beyond. Frame > Relay, PPP, HDLC, and X.25 > > > From owner-freebsd-hackers Sun Oct 22 10:48:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29547 for hackers-outgoing; Sun, 22 Oct 1995 10:48:11 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA29542 ; Sun, 22 Oct 1995 10:48:09 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id KAA00828; Sun, 22 Oct 1995 10:47:48 -0700 To: dennis@etinc.com (dennis) cc: "Jordan K. Hubbard" , hackers@FreeBSD.org Subject: Re: Bragging rights.. In-reply-to: Your message of "Sun, 22 Oct 1995 13:56:02 EDT." <199510221756.NAA07481@etinc.com> Date: Sun, 22 Oct 1995 10:47:47 -0700 Message-ID: <826.814384067@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > I'm talking about incremental profit, a capitalist concept. Have something > better in your bag of > goddies that costs a few dollars more an month and people will buy it every > time. I wasn't aware that ET offered a pay-by-the-month plan for their serial cards, and for as little as $3 a month too! You're right, I think you'll get a lot of requests with a deal like that.. :-) Jordan From owner-freebsd-hackers Sun Oct 22 10:50:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29638 for hackers-outgoing; Sun, 22 Oct 1995 10:50:53 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA29631 ; Sun, 22 Oct 1995 10:50:50 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id OAA07514; Sun, 22 Oct 1995 14:07:41 -0400 Date: Sun, 22 Oct 1995 14:07:41 -0400 Message-Id: <199510221807.OAA07514@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan writes.... >That's why I asked about the cheapo version of a sync serial card. Let's talk 3 more >months down the line and Joe has managed to raise a few more pennies by recycling all the >aluminum beer cans from the back seat of his car.. All that money is burning a hole in >his pocket and he's thinking "Hmmmm. If I could find a pair of cards for $200 or so that >would let me get my last little 38.9%, I could definitely drink "lite" for another couple >of weeks to make up for it." Again, incremental cost. You, as a marketing person, must >surely appreciate that! "Suck 'em in cheap and keep 'em paying" must be one of the first >lessons they teach at the P.T. Barnum Memorial University and I think it applies pretty >squarely to this whole Internet fracas. The regional bells are pushing ISDN in a big way, >and I think that's the next "upgrade" that all those legions of Internet addicts will next >be contemplating. When they do, you may rest assured that they won't flock to the most >expensive solutions available. The regional Bells are pushing ISDN because they've invested billions in the technology and they're in danger of losing their dial-tone customers to competition due to de-regulation. They're going to lose much of their revenue base and they need to have a use for the ports on their switches. If you think its the next "great upgrade" you're badly mistaken. >I know, you've said that a cheap sync serial card is the least of your plans and you >wouldn't touch ISDN with a stick. I'm not suggesting that YOU do this, merely that >someone do. When they do, be it a cheap ISDN card or sync serial upgrade, Joe and I will >probably be there with our checkbooks. Of course you value you're time much less than I do. Little checks...they're a pain just to cash. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 11:20:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA00875 for hackers-outgoing; Sun, 22 Oct 1995 11:20:23 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA00870 for ; Sun, 22 Oct 1995 11:20:20 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA01020; Sun, 22 Oct 1995 11:19:58 -0700 Message-ID: <308A8B4E.6F9AB114@FreeBSD.org> Date: Sun, 22 Oct 1995 11:19:58 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: dennis CC: hackers@FreeBSD.org Subject: Re: Bragging rights.. References: <199510221807.OAA07514@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis wrote: > on their switches. If you > think its the next "great upgrade" you're badly mistaken. Why? I don't see where the regional bell's *motivation* is at all the issue. I understand that you're pretty biased against ISDN in favor of your own Frame Relay solutions, but let's not go trying to adjust reality to fit the picture you'd like it to be! If people buy ISDN, it will be a success. So far, people are buying ISDN and all the technical criticism in the world you may have won't change that fact one iota. I think we're arguing at cross purposes. I'm talking about what the end-user wants and you're telling me what they SHOULD want and, in Dennis's ideal world, would want. Sorry, but you clearly haven't been a user in nearly long enough to have informed opinions about that anymore - you have a high speed sync serial "hammer" and now you insist that everything looks like a nail. > Of course you value you're time much less than I do. Little checks...they're > a pain just to cash. Yeah, you're right Dennis - I clearly value my time less. I must be, since we're having this pointless debate! :-) Also, WRT the little checks, I guess you'd have told Dave Thomas to take a hike if he'd come to you for startup funding too, wouldn't you? Dave: "I need just a $10,000 and you can have 10% of the whole business. I want to call it "Wendy's" and the idea is that we'll sell a good burger for under $2.00" Dennis: "What? You want to sell burgers for 2 bucks?! You're nuts! People want to pay $20 for a clearly superior burger, not $2! You'll lose your shirt! Take a hike, you idiot!" Yeah, I can picture that.. :-) -- Jordan From owner-freebsd-hackers Sun Oct 22 11:20:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA00913 for hackers-outgoing; Sun, 22 Oct 1995 11:20:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA00903 for ; Sun, 22 Oct 1995 11:20:28 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA27451 for ; Sun, 22 Oct 1995 19:19:56 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA28409 for freebsd-hackers@freebsd.org; Sun, 22 Oct 1995 19:19:55 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id TAA03456 for freebsd-hackers@freebsd.org; Sun, 22 Oct 1995 19:18:56 +0100 From: J Wunsch Message-Id: <199510221818.TAA03456@uriah.heep.sax.de> Subject: What is the best way... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 22 Oct 1995 19:18:55 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 789 Sender: owner-hackers@freebsd.org Precedence: bulk ...to implement something similar to the xxx_poll() driver entry points in SysV? For those whod don't know, these entries are supposed to be called on each clock tick (at spl6, i think this is `soft clock'), and they are useful for devices that lose interrupts, or that don't even have an interrupt of its own. The closest thing one could do (besides from the approach e.g. pcaudio is using, which i consider being overkill as a poll() replacement) were to continuously re-issue yet another timeout on each clock tick. However, since that would cause timeout() to walk the entire timer queue, it's rather expensive. Bruce? -- 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 Oct 22 11:29:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA01314 for hackers-outgoing; Sun, 22 Oct 1995 11:29:27 -0700 Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA01309 for ; Sun, 22 Oct 1995 11:29:25 -0700 Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id OAA05294 for ; Sun, 22 Oct 1995 14:29:19 -0400 Date: Sun, 22 Oct 1995 14:29:18 -0400 (EDT) From: Matthew Bailey X-Sender: mbailey@cps201 To: hackers@freebsd.org Subject: SNAP 951020 Kernel compile problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Below is the final protions of building a kernel for my machine. and yet below that is the config that I used to try to build this kernel. If someone would be so kind to take a look and see if there is something obvious that I missed. I would be greatful. Thanks again Matthew S. Bailey >From root@taz.emmons.cmich.eduSun Oct 22 14:26:58 1995 Date: Sun, 22 Oct 1995 10:10:11 -0400 From: Charlie Root To: mbailey@cps.cmich.edu Script started on Sun Oct 22 10:09:37 1995 taz# make loading kernel conf.o: Undefined symbol `_wcdopen' referenced from data segment conf.o: Undefined symbol `_wcdclose' referenced from data segment conf.o: Undefined symbol `_wcdstrategy' referenced from data segment conf.o: Undefined symbol `_wcdioctl' referenced from data segment conf.o: Undefined symbol `_wcdopen' referenced from data segment conf.o: Undefined symbol `_wcdclose' referenced from data segment conf.o: Undefined symbol `_wcdioctl' referenced from data segment conf.o: Undefined symbol `_wcdstrategy' referenced from data segment *** Error code 1 Stop. taz# exit taz# exit Script done on Sun Oct 22 10:09:45 1995 ---------- Forwarded message ---------- Date: Sun, 22 Oct 1995 10:10:37 -0400 From: Charlie Root To: mbailey@cps.cmich.edu # # ATAPI -- GENERIC kernel with ATAPI (IDE) CDROM support added. # # $Id: ATAPI,v 1.2 1995/10/05 04:34:30 jkh Exp $ # machine "i386" cpu "I586_CPU" ident DEVIL maxusers 256 options "CHILD_MAX=256" options "OPEN_MAX=256" options USER_LDT options NQNFS options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE #Allow users to grab the console options SYSVSHM options SYSVSEM options SYSVMSG config kernel root on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 options ATAPI #Enable ATAPI support for IDE bus device wcd0 #IDE CD-ROM controller ahc0 controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.1 #options XSERVER # include code for XFree86 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 64 pseudo-device gzip # Exec gzipped a.out's From owner-freebsd-hackers Sun Oct 22 11:35:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA01638 for hackers-outgoing; Sun, 22 Oct 1995 11:35:53 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA01633 for ; Sun, 22 Oct 1995 11:35:51 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA25727 for ; Sun, 22 Oct 1995 11:34:33 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA01089; Sun, 22 Oct 1995 19:30:32 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA28486; Sun, 22 Oct 1995 19:30:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id TAA03572; Sun, 22 Oct 1995 19:23:40 +0100 From: J Wunsch Message-Id: <199510221823.TAA03572@uriah.heep.sax.de> Subject: Re: New record for installation floppy update! :-) To: glen@winternet.com Date: Sun, 22 Oct 1995 19:23:39 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9510221727.AA11410@hal.winternet.com> from "glen@winternet.com" at Oct 22, 95 12:27:14 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 297 Sender: owner-hackers@freebsd.org Precedence: bulk As glen@winternet.com wrote: > > Is anybody with a 4M i386sx able to get the boot disks to work? I don't think it's supposed to. :-( -- 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 Oct 22 12:26:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03835 for hackers-outgoing; Sun, 22 Oct 1995 12:26:07 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA03829 ; Sun, 22 Oct 1995 12:26:03 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA23857 (5.65c8/HUTCS-S 1.4); Sun, 22 Oct 1995 21:25:48 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id VAA12777; Sun, 22 Oct 1995 21:25:58 +0200 Date: Sun, 22 Oct 1995 21:25:58 +0200 Message-Id: <199510221925.VAA12777@shadows.cs.hut.fi> From: Heikki Suonsivu To: dennis@etinc.com (dennis) Cc: "Jordan K. Hubbard" , Heikki Suonsivu , hackers@FreeBSD.org Subject: RE: Freeware reward????? In-Reply-To: <199510221742.NAA07437@etinc.com> References: <199510221742.NAA07437@etinc.com> Sender: owner-hackers@FreeBSD.org Precedence: bulk dennis writes: > Given that most > commercial companies have trouble doing commercially acceptable products in > this area > , whats the chance that some guy with way too much free time can do better? They can't do it better, usually, unless some kind of system can be built to make free software a profitable business. Cygnus is an example of this; I think there other alternatives like funds into which people can donate money for a specific piece of free software to be built, like this specific case, although in lack of suitable fund we need just to make promises. If the drivers are completed, within a year we will see which method turns out to be the best. If cards supported by freely available drivers sell more then than those with no freely available drivers, in FreeBSD environment, we can make conclusions. Until that, we can only speculate. Maybe we should drop -hackers off the receivers? > Is this for the "best" resulting product, or the first? Or don't you care? We are not searching for the best product we can get. We are searching for a product which happens to do what we need: make either two FreeBSD machines or a Cisco and a FreeBSD machine to talk to each other over a synchronous link. ET cards would probably do the job, but I do find free drivers an additional bonus which I give high value for. -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-hackers Sun Oct 22 12:34:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03927 for hackers-outgoing; Sun, 22 Oct 1995 12:34:51 -0700 Received: from w8hd.w8hd.org (w8hd.w8hd.org [198.252.159.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA03922 ; Sun, 22 Oct 1995 12:34:49 -0700 Received: (from kimc@localhost) by w8hd.w8hd.org (8.6.12/8.6.9) id PAA25737; Sun, 22 Oct 1995 15:34:40 -0400 Date: Sun, 22 Oct 1995 15:34:40 -0400 (EDT) From: Kim Culhan To: "Jordan K. Hubbard" cc: dennis , hackers@FreeBSD.ORG Subject: Re: Bragging rights.. In-Reply-To: <308A8B4E.6F9AB114@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I've been using a pair of Adtran ISU128's for some time, they do both sync and async; I'm not tellin' which I'm using :) I do have one complaint though. The async interfaces have TTL voltage levels though they supply these little 'adapters' labeled to suggest they convert the RS530 async. connections to RS232. In fact all they do is transpose some of the signal leads.. anyone know of a source for some boxes to convert RS530 to real RS232 ? I heard the newer ISU Express units have real RS232 levels, is this what you have Jordan ? kim -- kimc@w8hd.org From owner-freebsd-hackers Sun Oct 22 12:53:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04644 for hackers-outgoing; Sun, 22 Oct 1995 12:53:54 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04638 for ; Sun, 22 Oct 1995 12:53:52 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id MAA19659 for ; Sun, 22 Oct 1995 12:53:45 -0700 Message-Id: <199510221953.MAA19659@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@FreeBSD.ORG Subject: Re: Bragging rights.. In-reply-to: Your message of "Sun, 22 Oct 1995 15:34:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Oct 1995 12:53:41 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Anyone knows if the Ascend's Pipeline 50 uses asynch or sync ? Tnks, Amancio From owner-freebsd-hackers Sun Oct 22 12:59:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA04827 for hackers-outgoing; Sun, 22 Oct 1995 12:59:49 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA04822 for ; Sun, 22 Oct 1995 12:59:47 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA05348; Sun, 22 Oct 1995 12:59:17 -0700 Message-ID: <308AA295.794BDF32@FreeBSD.org> Date: Sun, 22 Oct 1995 12:59:17 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: Kim Culhan CC: dennis , hackers@FreeBSD.org Subject: Re: Bragging rights.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Kim Culhan wrote: > I heard the newer ISU Express units have real RS232 levels, is this > what you have Jordan ? Yep! I have the L1 model - the cheapest member of the Express family. -- Jordan From owner-freebsd-hackers Sun Oct 22 14:58:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA09321 for hackers-outgoing; Sun, 22 Oct 1995 14:58:50 -0700 Received: from io.org (root@io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA09291 ; Sun, 22 Oct 1995 14:58:39 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id RAA20606; Sun, 22 Oct 1995 17:58:13 -0400 Date: Sun, 22 Oct 1995 17:58:22 -0400 (EDT) From: Brian Tao To: FREEBSD-HACKERS-L , FREEBSD-QUESTIONS-L Subject: Re: 2.1.0-951020-SNAP available on ftp.io.org In-Reply-To: <17663.814287185@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 21 Oct 1995, Jordan K. Hubbard wrote: > > This snapshot is available on: > > ftp://ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/ > > We also regret that a space crunch currently precludes our putting it > on freefall.freebsd.org, as we usually do. Some of you may wish to > wait until it hits your local mirror (ftp.cdrom.com is always pretty > heavily loaded!). As a side note, I just pulled the 2.1.0-951020-SNAP directory over to ftp://ftp.io.org/pub/systems/freebsd/2.1.0-951020-SNAP, including the boot, root and fixit floppies dated October 21. ftp.io.org is a 486DX2/66 that was recently downgraded to 32 megs, so I've lowered the limit on remote anonymous FTP logins to 30 at a time (it also handles IRC server duty). There's normally 12 to 15 in that user class. So if ftp.cdrom.com is full and you have a fast link through UUNET Canada, then try ftp.io.org. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Oct 22 16:28:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA12035 for hackers-outgoing; Sun, 22 Oct 1995 16:28:27 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA12030 for ; Sun, 22 Oct 1995 16:28:24 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id QAA02181; Sun, 22 Oct 1995 16:28:22 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id QAA00837; Sun, 22 Oct 1995 16:26:50 -0700 Message-Id: <199510222326.QAA00837@corbin.Root.COM> To: Matthew Bailey cc: hackers@freebsd.org Subject: Re: SNAP 951020 Kernel compile problems. In-reply-to: Your message of "Sun, 22 Oct 95 14:29:18 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 22 Oct 1995 16:26:45 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >Below is the final protions of building a kernel for my machine. and yet >below that is the config that I used to try to build this kernel. > >If someone would be so kind to take a look and see if there is something >obvious that I missed. I would be greatful. You need to have IDE controller support - the "wdc0/wd0" entries were apparantly removed. -DG From owner-freebsd-hackers Sun Oct 22 16:35:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA12197 for hackers-outgoing; Sun, 22 Oct 1995 16:35:33 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA12189 ; Sun, 22 Oct 1995 16:35:29 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA07915; Sun, 22 Oct 1995 16:35:26 -0700 To: announce@freebsd.org cc: hackers@freebsd.org Subject: Latest 2.1.0-951020-SNAP floppies now available. Reply-To: hackers@freebsd.org Date: Sun, 22 Oct 1995 16:35:26 -0700 Message-ID: <7913.814404926@time.cdrom.com> From: Charlie & Sender: owner-hackers@freebsd.org Precedence: bulk On ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/floppies These fix many reported problems.. Thanks for the feedback, folks, and please keep it coming! Every bug fixed now is one less we'll have for 2.1. Jordan From owner-freebsd-hackers Sun Oct 22 16:52:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA12485 for hackers-outgoing; Sun, 22 Oct 1995 16:52:10 -0700 Received: from ofw.jri.co.jp (ofw.jri.co.jp [202.32.75.227]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA12478 for ; Sun, 22 Oct 1995 16:52:06 -0700 From: shibuya@$inet1.tyo.open.jri.co.jp Received: by ofw.jri.co.jp; id IAA00991; Mon, 23 Oct 1995 08:52:03 +0900 Received: from unknown(10.127.7.6) by ofw.jri.co.jp via smap (V1.3) id sma000986; Mon Oct 23 08:52:00 1995 Received: from r6.jri.co.jp by jriuu.sci.jri.co.jp (16.6/IIJ-U1.1-JRI1.3-950113) id AA03188; Mon, 23 Oct 95 08:51:57 +0900 Received: from [10.31.10.198] by r6.ichi.jri.co.jp (AIX 3.2/UCB 5.64/3.3W4-jri-relay-1.1) id AA39421; Mon, 23 Oct 1995 08:51:25 +0900 Received: from cc:Mail SMTPLINK 2.1 by $inet1.tyo.open.jri.co.jp id 9510238144.AA814463554; Mon, 23 Oct 95 08:52:34 JST Date: Mon, 23 Oct 95 08:52:34 JST Message-Id: <9510238144.AA814463554@$inet1.tyo.open.jri.co.jp> To: hackers@freebsd.org Subject: cc:Mail SMTPLINK Undeliverable Message Sender: owner-hackers@freebsd.org Precedence: bulk Message undeliverable at this time Original text follows ---------------------------------------------- Received: from r6.ichi.jri.co.jp by ccMail SMTPLINK 2.1 >From owner-freebsd-announce@freefall.freebsd.org X-Envelope-From: owner-freebsd-announce@freefall.freebsd.org Received: from jriuu.sci.jri.co.jp by r6.ichi.jri.co.jp (AIX 3.2/UCB 5.64/3.3W4-jri-relay-1.1) id AA36596; Mon, 23 Oct 1995 08:50:07 +0900 Received: from ofw.jri.co.jp by jriuu.sci.jri.co.jp (16.6/IIJ-U1.1-JRI1.3-950113) id AA03182; Mon, 23 Oct 95 08:50:35 +0900 Received: by ofw.jri.co.jp; id IAA00958; Mon, 23 Oct 1995 08:50:33 +0900 Received: from freefall.freebsd.org(192.216.222.4) by ofw.jri.co.jp via smap (V1.3) id sma000954; Mon Oct 23 08:50:11 1995 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA12395 ; Sun, 22 Oct 1995 16:49:09 -0700 Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA12212 for announce-outgoing; Sun, 22 Oct 1995 16:35:36 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA12189 ; Sun, 22 Oct 1995 16:35:29 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA07915; Sun, 22 Oct 1995 16:35:26 -0700 To: announce@freebsd.org Cc: hackers@freebsd.org Subject: Latest 2.1.0-951020-SNAP floppies now available. Reply-To: hackers@freebsd.org Date: Sun, 22 Oct 1995 16:35:26 -0700 Message-Id: <7913.814404926@time.cdrom.com> From: Charlie & Sender: owner-announce@freebsd.org Precedence: bulk On ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/floppies These fix many reported problems.. Thanks for the feedback, folks, and please keep it coming! Every bug fixed now is one less we'll have for 2.1. Jordan From owner-freebsd-hackers Sun Oct 22 16:56:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA12565 for hackers-outgoing; Sun, 22 Oct 1995 16:56:05 -0700 Received: from proxy.siemens.at (proxy.siemens.at [192.138.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA12560 for ; Sun, 22 Oct 1995 16:56:02 -0700 Received: from PC0087.gud.siemens.co.at (pc0087.gud.siemens-austria) by proxy.siemens.at with SMTP id AA00202 (5.67a/IDA-1.5 for ); Mon, 23 Oct 1995 00:55:27 +0100 Received: by PC0087.gud.siemens.co.at; Mon, 23 Oct 95 0:57:44 +0100 Date: Mon, 23 Oct 95 0:59:00 GUD Message-Id: X-Priority: 3 (Normal) To: From: Subject: Undeliverable Message X-Incognito-Sn: 366 X-Incognito-Format: VERSION=2.01 ENCRYPTED=NO Sender: owner-hackers@freebsd.org Precedence: bulk To: Cc: Subject: Latest 2.1.0-951020-SNAP floppies now available. Message not delivered to recipients below. Press F1 for help with VNM error codes. VNM3043: Karl-Heinz Lemp@ISA5@PSE OE VNM3043 -- MAILBOX IS FULL The message cannot be delivered because the recipient's mailbox contains the maximum number of messages, as set by the system administrator. The recipient must delete some messages before any other messages can be delivered. The maximum message limit for a user's mailbox is 10,000. The default message limit is 1000 messages. Administrators can set message limits using the Mailbox Settings function available in the Manage User menu (MUSER). When a user's mailbox reaches the limit, the user must delete some of the messages before the mailbox can accept any more incoming messages. ---------------------- Original Message Follows ----------------------On ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/floppies These fix many reported problems.. Thanks for the feedback, folks, and please keep it coming! Every bug fixed now is one less we'll have for 2.1. Jordan From owner-freebsd-hackers Sun Oct 22 17:12:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12821 for hackers-outgoing; Sun, 22 Oct 1995 17:12:30 -0700 Received: from cps201.cps.cmich.edu (cps201.cps.cmich.edu [141.209.20.201]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12816 for ; Sun, 22 Oct 1995 17:12:27 -0700 Received: from cps201 (cps201.cps.cmich.edu [141.209.20.201]) by cps201.cps.cmich.edu (8.6.12/8.6.12) with SMTP id UAA11211; Sun, 22 Oct 1995 20:11:06 -0400 Date: Sun, 22 Oct 1995 20:11:05 -0400 (EDT) From: Matthew Bailey X-Sender: mbailey@cps201 To: David Greenman cc: hackers@freebsd.org Subject: Re: SNAP 951020 Kernel compile problems. In-Reply-To: <199510222326.QAA00837@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 22 Oct 1995, David Greenman wrote: > > You need to have IDE controller support - the "wdc0/wd0" entries were > apparantly removed. The LINT file says the two lines are required. There is nothing stating you need to have a controller. Some of use SCSI hard Drives this is not all that obvious. I think a little note in the LINT makefile would be advisable. Matt From owner-freebsd-hackers Sun Oct 22 19:16:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA16608 for hackers-outgoing; Sun, 22 Oct 1995 19:16:19 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA16603 for ; Sun, 22 Oct 1995 19:16:14 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id WAA08448; Sun, 22 Oct 1995 22:33:16 -0400 Date: Sun, 22 Oct 1995 22:33:16 -0400 Message-Id: <199510230233.WAA08448@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Julian Elischer From: dennis@etinc.com (dennis) Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> >> >> >BTW, I have a $1000 (minus possible taxes) reward available for the author >> >of a free driver for a commonly available synchronous serial card like SDL, >> >ET or Arnet. Ie. sources available and non-restrictive license (preferably >> >both GPL and Berkey to allow it to be included both in Linux and *BSD*). >> >Need to talk to ciscos (that is what usually is in the other end). Needs >> >> Add two 0's to this number and we can talk. >> >> We'll have it as part of our product very shortly, but....for the reasons >> that you just stated, no "right to steal" licenses available. >I do understand the fact that you've put so much work into your >product's software.. >but do you really think that if it were released in source, that it >would negatively impact your sales? >This is a serious question.. >what do you think would happen? >My expectation is that it would immediatly be ported to Lynx , OS9, >and other OS's and become an industry standard.. not >a bad place to be really. The technologies that we have (Frame Relay, X.25 sync PPP, etc) would immediately be ported to less expensive boards, creating a price war over hardware since none of you care about anything but cost. If it became very popular then others would build similar boards.It wouldn't create any markets, since no-one uses a T1 board if they don't need it. No serious commercial venture would use it anyway, because these types of products aren't like modems. You need support, and no-one is going to bet their business on a driver maintained by some weeny part-time programmer in lower Mongolia. You also need a program, and FreeBSD doesn't have one. >. Have you considered releaseinf drivers for >some small part of your product line as an experiment and watching >what happens? I've considered releasing a "freeware" source version of our board drivers.... No Frame Relay, No X.25, No Sync PPP, No Utilities).....but what is there to gain? We're already selling boards faster than we can build them. Who wants to sell 1,000 boards at (Jordan's price of) $150.? I believe that it would result in the cannabilization of the business I already have. People willing to pay will get it cheaper, and the really cheap and stupid will still go out and buy $700. junk routers (or soup up their async boards to do higher speeds!) In 1991, Western Digital was selling 20,000 Ethernet boards a month, which was unbelievable at the time. Whats more unbelivable is that they were losing money. Communism failed for a reason, you know. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 19:34:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17246 for hackers-outgoing; Sun, 22 Oct 1995 19:34:02 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA17241 ; Sun, 22 Oct 1995 19:33:57 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id WAA08494; Sun, 22 Oct 1995 22:51:01 -0400 Date: Sun, 22 Oct 1995 22:51:01 -0400 Message-Id: <199510230251.WAA08494@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >dennis wrote: >> on their switches. If you >> think its the next "great upgrade" you're badly mistaken. > >Why? I don't see where the regional bell's *motivation* is at all the issue. You brought it up. The fact that some RBOCs are pushing ISDN is not what it seems. It costs big bucks to tool-up for ISDN, and once you do you have to sell LOTS of it to recover your costs. The world will change when de-reg hits. The world will also change when switched FR hits. >I understand that you're pretty biased against ISDN in favor of your own Frame Relay >solutions, but let's not go trying to adjust reality to fit the picture you'd like it to >be! If people buy ISDN, it will be a success. So far, people are buying ISDN and all >the technical criticism in the world you may have won't change that fact one iota. They're different markets, Jordan. ISDN will never be private line replacement, its a replacement for dial-up. I have nothing against ISDN, in fact we intend to support the sync solution that I've been discussing. (There's a neat new 512K ISDN concentrator out....crank up your xtals boys!) I said I wouldn't use it myself because I'd rather have a private line. I see no benefit whatsoever in using something thats "included" in the O/S, since there's no one out there that will do it as well as we can...and if we do it it will be portable and immediately available for NetBSD, BSD/OS and Linux and whatever else I decide to sell (which is a LOT bigger market than the FreeBSD market alone). db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 19:38:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17381 for hackers-outgoing; Sun, 22 Oct 1995 19:38:13 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA17375 for ; Sun, 22 Oct 1995 19:38:09 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id WAA08501; Sun, 22 Oct 1995 22:55:12 -0400 Date: Sun, 22 Oct 1995 22:55:12 -0400 Message-Id: <199510230255.WAA08501@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Heikki Suonsivu From: dennis@etinc.com (dennis) Subject: RE: Freeware reward????? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > >dennis writes: > > Given that most > > commercial companies have trouble doing commercially acceptable products in > > this area > > , whats the chance that some guy with way too much free time can do better? > >They can't do it better, usually, unless some kind of system can be built >to make free software a profitable business. Cygnus is an example of this; >I think there other alternatives like funds into which people can donate >money for a specific piece of free software to be built, like this specific >case, although in lack of suitable fund we need just to make promises. > >If the drivers are completed, within a year we will see which method turns >out to be the best. If cards supported by freely available drivers sell >more then than those with no freely available drivers, in FreeBSD >environment, we can make conclusions. Until that, we can only speculate. >Maybe we should drop -hackers off the receivers? Its not how much you sell, its how much you make on what you sell. Selling more is easy....just drop your prices. Economics 101. Overseas, freely-available has more value because there's a support problem for US-made products. I understand that. We usually give better deals to overseas dealers because of it. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 19:44:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17622 for hackers-outgoing; Sun, 22 Oct 1995 19:44:04 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA17617 for ; Sun, 22 Oct 1995 19:43:59 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id XAA08508; Sun, 22 Oct 1995 23:00:57 -0400 Date: Sun, 22 Oct 1995 23:00:57 -0400 Message-Id: <199510230300.XAA08508@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Kim Culhan From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > >I've been using a pair of Adtran ISU128's for some time, they do both >sync and async; I'm not tellin' which I'm using :) > >I do have one complaint though. The async interfaces have TTL voltage >levels though they supply these little 'adapters' labeled to >suggest they convert the RS530 async. connections to RS232. > They can't exactly do this, because EIA-530 is synchronous RS-422 (balanced) and RS-232 is unbalanced, so they have to do signal conversion. They probably default to RS-232 for async and run EIA-530 for sync. I doubt if RS-232 would work at RS-422 levels at higher speeds as RS-232 is only spec'ed for 20k anyway. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 19:50:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17902 for hackers-outgoing; Sun, 22 Oct 1995 19:50:08 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA17895 for ; Sun, 22 Oct 1995 19:50:02 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id TAA07543; Sun, 22 Oct 1995 19:49:55 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id TAA04734; Sun, 22 Oct 1995 19:47:25 -0700 Message-Id: <199510230247.TAA04734@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: dennis@etinc.com (dennis) cc: hackers@freebsd.org Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. In-reply-to: Your message of "Sun, 22 Oct 1995 22:33:16 EDT." <199510230233.WAA08448@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Oct 1995 19:47:24 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org Precedence: bulk There is a weird irony in this argument, given the fact that the OS is "FreeBSD", and consider what that "Free" in the name was supposed to mean, though it is lost on many. And, I guess I'll point out that it doesn't take a lot of time spent surfing http://www.bsdi.com to realize that sometimes "free" drivers work a lot better, and get to the users a *lot* faster... These are not very new differences of ah opinion, maybe it's up to each entity to decide what they want to do, but I don't know why it's important to thrash them here. Best regards, Russell > >> > >> > >> >BTW, I have a $1000 (minus possible taxes) reward available for the author > >> >of a free driver for a commonly available synchronous serial card like SDL, > >> >ET or Arnet. Ie. sources available and non-restrictive license (preferably > >> >both GPL and Berkey to allow it to be included both in Linux and *BSD*). > >> >Need to talk to ciscos (that is what usually is in the other end). Needs > >> > >> Add two 0's to this number and we can talk. > >> > >> We'll have it as part of our product very shortly, but....for the reasons > >> that you just stated, no "right to steal" licenses available. > >I do understand the fact that you've put so much work into your > >product's software.. > >but do you really think that if it were released in source, that it > >would negatively impact your sales? > >This is a serious question.. > >what do you think would happen? > >My expectation is that it would immediatly be ported to Lynx , OS9, > >and other OS's and become an industry standard.. not > >a bad place to be really. > > The technologies that we have (Frame Relay, X.25 sync PPP, etc) would > immediately be ported to less expensive boards, creating a price war > over hardware since none of you care about anything but cost. If it became > very popular then others would build similar boards.It wouldn't create any > markets, > since no-one uses a T1 board if they don't need it. No serious commercial > venture would use it anyway, because these types of products aren't like modems. > You need support, and no-one is going to bet their business on a driver > maintained by > some weeny part-time programmer in lower Mongolia. You also need a program, > and FreeBSD > doesn't have one. > > >. Have you considered releaseinf drivers for > >some small part of your product line as an experiment and watching > >what happens? > > I've considered releasing a "freeware" source version of our board drivers.... > No Frame Relay, No X.25, No Sync PPP, No Utilities).....but what is there to > gain? We're already > selling boards faster than we can build them. Who wants to sell 1,000 boards > at (Jordan's price > of) $150.? I believe that it would result in the cannabilization of the > business I already have. People > willing to pay will get it cheaper, and the really cheap and stupid will > still go out and buy $700. junk > routers (or soup up their async boards to do higher speeds!) > > In 1991, Western Digital was selling 20,000 Ethernet boards a month, which > was unbelievable at the time. Whats more unbelivable is that they were losing > money. > > Communism failed for a reason, you know. > > db > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com > > Synchronous Communications Cards and Routers For > Discriminating Tastes. 56k to T1 and beyond. Frame > Relay, PPP, HDLC, and X.25 > > From owner-freebsd-hackers Sun Oct 22 20:11:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA18524 for hackers-outgoing; Sun, 22 Oct 1995 20:11:50 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA18518 ; Sun, 22 Oct 1995 20:11:46 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id XAA08599; Sun, 22 Oct 1995 23:28:54 -0400 Date: Sun, 22 Oct 1995 23:28:54 -0400 Message-Id: <199510230328.XAA08599@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan spouts... >I think we're arguing at cross purposes. I'm talking about what the end-user wants and >you're telling me what they SHOULD want and, in Dennis's ideal world, would want. Sorry, >but you clearly haven't been a user in nearly long enough to have informed opinions about >that anymore - you have a high speed sync serial "hammer" and now you insist that >everything looks like a nail. You're just wrong about everything. I think that its pretty funny that you think that you have more perspective than I do. The only perspective that you have thats better than mine is that you seem to be poor....and yes, I don't remember that very well. I am a user, and I've been a user more than anyone, and I've also been in the market and seen what my customers are doing. I dial-up from home, and I maintain the router at ET. People buy what is presented to them....if they understood the choices they would buy sync 128k. But they don't understand the choices so they buy whats cheap. They don't understand the choices and neither do the ISPs. Datacomm in this country is a freaking mess........Anyone wants to be an ISP on LI give me a call.... Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 20:15:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA18672 for hackers-outgoing; Sun, 22 Oct 1995 20:15:45 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA18667 for ; Sun, 22 Oct 1995 20:15:41 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id XAA08606; Sun, 22 Oct 1995 23:32:38 -0400 Date: Sun, 22 Oct 1995 23:32:38 -0400 Message-Id: <199510230332.XAA08606@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Russell L. Carter" From: dennis@etinc.com (dennis) Subject: Re: ISDN: Sync vs Async. Was: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > >There is a weird irony in this argument, given the fact that >the OS is "FreeBSD", and consider what that "Free" in the name was >supposed to mean, though it is lost on many. > >And, I guess I'll point out that it doesn't take a lot of time >spent surfing http://www.bsdi.com to realize that sometimes >"free" drivers work a lot better, and get to the users a *lot* >faster... > Of course BSDI wrote, maintains and supports their sync drivers and recommends ours as an alternative. They don't support or specifically recommend freeware.....and BSD/OS is NOT freeware. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sun Oct 22 20:38:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA19202 for hackers-outgoing; Sun, 22 Oct 1995 20:38:45 -0700 Received: from w8hd.w8hd.org (w8hd.w8hd.org [198.252.159.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA19191 for ; Sun, 22 Oct 1995 20:38:38 -0700 Received: (from kimc@localhost) by w8hd.w8hd.org (8.6.12/8.6.9) id XAA26908; Sun, 22 Oct 1995 23:38:33 -0400 Date: Sun, 22 Oct 1995 23:38:33 -0400 (EDT) From: Kim Culhan To: dennis cc: hackers@FreeBSD.ORG Subject: Re: Bragging rights.. In-Reply-To: <199510230300.XAA08508@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Sun, 22 Oct 1995, dennis wrote: > > > >I've been using a pair of Adtran ISU128's for some time, they do both > >sync and async; I'm not tellin' which I'm using :) > > > >I do have one complaint though. The async interfaces have TTL voltage > >levels though they supply these little 'adapters' labeled to > >suggest they convert the RS530 async. connections to RS232. > > > > They can't exactly do this, because EIA-530 is synchronous RS-422 (balanced) > and RS-232 is unbalanced, so they have to do signal conversion. They > probably default to RS-232 for async and run EIA-530 for sync. I doubt if > RS-232 would work at RS-422 levels at higher speeds as RS-232 is only > spec'ed for 20k anyway. Its async with TTL voltage levels. > > Dennis > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com Right. Thats my point, they may not work at _all_ connected just to any 'RS232' device. They will work with some 'typical' RS232 interfaces. They're very good units, what with their v.35 interfaces, very flexible. When we took these out of service from the v.35 interfaces, we wanted to put 'em back in service using more common async. ports in another application but..lets just say I was sold these units by a certain Florida reseller who didn't return my call[s] about this issue; caveat emptor. I still like 'em alot, the designers didn't get to choose the sales organization. regards kim -- kimc@w8hd.org From owner-freebsd-hackers Sun Oct 22 21:12:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA20467 for hackers-outgoing; Sun, 22 Oct 1995 21:12:04 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA20457 for ; Sun, 22 Oct 1995 21:11:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA11146; Mon, 23 Oct 1995 14:08:11 +1000 Date: Mon, 23 Oct 1995 14:08:11 +1000 From: Bruce Evans Message-Id: <199510230408.OAA11146@godzilla.zeta.org.au> To: davidg@Root.COM, mbailey@cps.cmich.edu Subject: Re: SNAP 951020 Kernel compile problems. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> You need to have IDE controller support - the "wdc0/wd0" entries were >> apparantly removed. >The LINT file says the two lines are required. There is nothing stating >you need to have a controller. Some of use SCSI hard Drives this is not >all that obvious. I think a little note in the LINT makefile would be >advisable. It's the same as for SCSI. Specifying sd0 without specifying a SCSI controller won't work. Bruce From owner-freebsd-hackers Sun Oct 22 22:22:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA22169 for hackers-outgoing; Sun, 22 Oct 1995 22:22:09 -0700 Received: from subnet.sub.net (root@subnet.sub.net [192.101.75.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA22164 for ; Sun, 22 Oct 1995 22:22:05 -0700 Received: from ud.dinoex.sub.org (root@localhost) by subnet.sub.net (8.6.12/8.6.12) with UUCP id GAA07949 for freebsd.org!freebsd-hackers; Mon, 23 Oct 1995 06:21:26 +0100 Received: from phase23.dinoex.sub.org by ud.dinoex.sub.org with uucp (Linux Smail3.1.28.1 #14) id m0t74rA-000JiRC; Sun, 22 Oct 95 19:10 MET Received: from citylink.dinoex.sub.org by phase23.dinoex.sub.org with uucp (CY Smail3.1.28.1 #6) id m0t723c-0005KkC; Sun, 22 Oct 95 16:11 MET From: peter@citylink.dinoex.sub.org (Peter Much) Date: Fri, 20 Oct 1995 01:03:39 +0100 Message-Id: <199510200003.BAA14324@citylink.dinoex.sub.org> Received: by citylink.dinoex.sub.org (8.6.12 FreeBSD-1/PMuch) id BAA14324; Fri, 20 Oct 1995 01:03:39 +0100 To: freebsd-hackers@freebsd.org Newsgroups: comp.unix.bsd.freebsd.misc Subject: modf.S (in libc.a): stack access fault Summary: ingres cannot handle float values Reply-To: admin@citylink.dinoex.sub.org Organization: Buero fuer Sektenforschung und Qualitaetspruefung in der Esoterik Keywords: ingres float exception modf() libc Sender: owner-hackers@freebsd.org Precedence: bulk The funktion modf() (in libc.a, from lib/libc/i386/gen/modf.S) seems to dismangle the program stack. This is the reason why ingres cannot handle float values with FreeBSD (and other OS's - i reported that here, somewhen about May). If linked with lib/msun/src/s_modf.c instead, it does work. A friend of mine had already reported this bug to Borland/Heimsoeth years ago - so it was obviously not the latest version of the Borland compiler library that made it into FreeBSD.:-(( To reproduce the error, try the following code: ---------------------------------------------------------------------- #include main() { double arg = 0.0, fj; int i; char *p, buf[21]; p = buf; for(i=0; i < 20; i++) { arg *= 10; (void)modf(arg, &fj); arg -= fj; *p++ = (int)fj + '0'; } *p = '\0'; printf("%s\n", buf); } ---------------------------------------------------------------------- It crashes with i=7. I don't know math-copro-assembler, so i cannot debug this. Peter P.S: Anybody wanting the ingres patches to build a port? -- Write to: Peter Much * Koelnische Str. 22 * D-34117 Kassel * +49-561-774961 peter@citylink.dinoex.sub.org * much@hrz.uni-kassel.de From owner-freebsd-hackers Sun Oct 22 23:26:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA23856 for hackers-outgoing; Sun, 22 Oct 1995 23:26:48 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA23851 for ; Sun, 22 Oct 1995 23:26:44 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA15714; Mon, 23 Oct 1995 16:25:25 +1000 Date: Mon, 23 Oct 1995 16:25:25 +1000 From: Bruce Evans Message-Id: <199510230625.QAA15714@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, peter@citylink.dinoex.sub.org Subject: Re: modf.S (in libc.a): stack access fault Sender: owner-hackers@freebsd.org Precedence: bulk >The funktion modf() (in libc.a, from lib/libc/i386/gen/modf.S) seems to >dismangle the program stack. This is the reason why ingres cannot handle >float values with FreeBSD (and other OS's - i reported that here, somewhen >about May). If linked with lib/msun/src/s_modf.c instead, it does work. >To reproduce the error, try the following code: >---------------------------------------------------------------------- >#include >main() >{ > double arg = 0.0, fj; > int i; > char *p, buf[21]; > p = buf; > for(i=0; i < 20; i++) { > arg *= 10; > (void)modf(arg, &fj); > arg -= fj; > *p++ = (int)fj + '0'; > } > *p = '\0'; > printf("%s\n", buf); >} >---------------------------------------------------------------------- $ cc -Wall prog.c prog.c:4: warning: return-type defaults to `int' prog.c: In function `main': prog.c:12: warning: implicit declaration of function `modf' prog.c:18: warning: control reaches end of non-void function `modf' is not declared and so the compiler has to assume that it returns `int'. Since it actually returns double, the behaviour is undefined. `modf' is declared in include to fix the problem. The actual behaviour when the modf() in libc.a is called under FreeBSD is that each call leaves a double on the floating point stack. On the 8th call, the stack has 7 registers full of junk so there is no space for the 2 registers used by modf() and a stack exception occurs. Under FreeBSD, stack exceptions are trapped, so a SIGFPE is generated on the next floating point instruction after the one for which the stack exception was recorded. The behaviour when the modf() in libm.a is called should be similar. It is the same here. The math routines in lib/libc/i386/gen (fabs, frexp, ldexp and modf) are of lower quality than the ones in lib/msun/src and probably shouldn't exist. Bruce From owner-freebsd-hackers Mon Oct 23 00:51:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA25556 for hackers-outgoing; Mon, 23 Oct 1995 00:51:37 -0700 Received: from ccslinux.dlsu.edu.ph (linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA25546 for ; Mon, 23 Oct 1995 00:50:45 -0700 Received: by ccslinux.dlsu.edu.ph (Linux Smail3.1.28.1 #13) Sender: owner-hackers@FreeBSD.org Precedence: bulk id m0t7HT6-000A5cC; Mon, 23 Oct 95 15:38 GMT+0800 Date: Mon, 23 Oct 1995 15:38:47 +48000 From: Gavin Lim Subject: /proc file system To: hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We have FreeBSD 2.0.5. We're designing a process migration facility and it seems that the /proc file system would be very useful to us. What documentation is there to program /proc? What are the file formats? Thanks! Hope to hear from you guys as soon as possible. ============================================================================== Gavin Lim Gavin@linux1.dlsu.edu.ph ============================================================================== From owner-freebsd-hackers Mon Oct 23 01:51:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA27627 for hackers-outgoing; Mon, 23 Oct 1995 01:51:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA27614 for ; Mon, 23 Oct 1995 01:51:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA20756; Mon, 23 Oct 1995 18:50:30 +1000 Date: Mon, 23 Oct 1995 18:50:30 +1000 From: Bruce Evans Message-Id: <199510230850.SAA20756@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de Subject: Re: What is the best way... Sender: owner-hackers@freebsd.org Precedence: bulk >...to implement something similar to the xxx_poll() driver entry >points in SysV? >For those whod don't know, these entries are supposed to be called on >each clock tick (at spl6, i think this is `soft clock'), and they are >useful for devices that lose interrupts, or that don't even have an >interrupt of its own. I prefer periodic timeouts (standard timeouts that get repeated automatically). >The closest thing one could do (besides from the approach e.g. >pcaudio is using, which i consider being overkill as a poll() >replacement) were to continuously re-issue yet another timeout on each >clock tick. However, since that would cause timeout() to walk the >entire timer queue, it's rather expensive. timeout() seems to be fairly inexpensive at least when the queue is short. I've thought of having separate queues for periodic timeouts at frequencies hz, hz/10, hz/100, ... but timeouts can be dispatched more efficiently from a single delta queue than from multiple queues. If timeout() is too slow then I think effort would be better spent speeding it up, perhaps by using binary search. It's surprising how many improvement possibilities there are for something as basic as timeouts. Other possibilities: 1) high resolution timeouts (vary the clock's maximum count so that clock interrupts occur when you want them, not periodically). Heavy use of periodic timeouts would defeat optimization possibilities here (reprogramming the clock isn't free but you could hope to gain by taking less interrupts. Periodic interrupts would have to be simulated and ones at frequency `hz' would cost more than now). 2) timeouts that act at higher ipls. Currently, timeouts can only occur at splsoftclock(). "Unimportant" hardware activity such as IDE disk transfers can delay timeouts by several clock ticks. Bruce From owner-freebsd-hackers Mon Oct 23 01:52:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA27691 for hackers-outgoing; Mon, 23 Oct 1995 01:52:23 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA27674 for ; Mon, 23 Oct 1995 01:52:10 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id SAA02381 for hackers@freebsd.org; Mon, 23 Oct 1995 18:17:44 +0930 From: Michael Smith Message-Id: <199510230847.SAA02381@genesis.atrad.adelaide.edu.au> Subject: New userconfig To: hackers@freebsd.org Date: Mon, 23 Oct 1995 18:17:44 +0930 (CST) Content-Type: text Content-Length: 1895 Sender: owner-hackers@freebsd.org Precedence: bulk Ok, time to ruffle the feathers again 8) In my quest to make the 'visual' userconfig as snuggly and friendly as possible, I'd like to request a boon of the directional philosophers. The background : In order to meaninfully interpret the values assigned the basic ISA device parameters, I currently make the following assumptions : If a parameter is -1, the driver does not use the parameter. It is never relevant, and is never consulted. If a parameter is -2, the driver has a compiled-in default for this parameter, but the default can be overridden by setting the value to another value. Currently, of course, this doesn't happen. It could be argued that it should never happen, either, but until a device registration scheme is in place that provides a better technique, this is it. Joerg has kindly provided details for modifying config(8) to recognise 'auto' and 'none' as alternatives to '?'. I'd like to ask further for comments (and advice) on setting the _default_ for nonspecified parameters to 'none' (-1), rather than the currently ambiguous state (some -1, some 0). Arguments about whether -1 and -2 map to "legit" parameter values should be accompanied by examples of _ISA_ hardware that live at such addresses, or have such aperture sizes, and are at all likely to be supported by FreeBSD. ++++ Julian, specifically to you, and generally to anyone else working on device driver registration issues - is there a "better way", that takes advantage of the devfs concept/support/etc? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 23 02:07:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA28594 for hackers-outgoing; Mon, 23 Oct 1995 02:07:24 -0700 Received: from annax.tky.hut.fi (annax.tky.hut.fi [130.233.32.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA28582 for ; Mon, 23 Oct 1995 02:07:19 -0700 Received: from pooh.tky.hut.fi (root@pooh.tky.hut.fi [130.233.33.233]) by annax.tky.hut.fi (8.6.12/8.6.5) with ESMTP id LAA10192 for ; Mon, 23 Oct 1995 11:04:46 +0200 Received: by pooh.tky.hut.fi (LAA02663); Mon, 23 Oct 1995 11:07:15 +0200 Date: Mon, 23 Oct 1995 11:07:15 +0200 Message-Id: <199510230907.LAA02663@pooh.tky.hut.fi> From: "Timo J. Rinne" To: freebsd-hackers@freebsd.org In-reply-to: Julian Elischer's message of 21 Oct 1995 06:23:57 +0200 Subject: A quick vote on pthreads PLZ Reply-to: tri@iki.fi Organization: Helsinki University of Technology, Otakaari 1, 02150 ESPOO, Finland Mime-version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk Julian wrote: > A/port/package > B/new base part of the system? I vote for B, but I'd really like to see real kernel threads. Regards, //Rinne From owner-freebsd-hackers Mon Oct 23 03:07:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA01349 for hackers-outgoing; Mon, 23 Oct 1995 03:07:17 -0700 Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA01340 for ; Mon, 23 Oct 1995 03:07:12 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <15335-0@bunyip.cc.uq.oz.au>; Mon, 23 Oct 1995 20:05:37 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id TAA13996; Mon, 23 Oct 1995 19:57:08 +1000 Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.3) id TAA22795; Mon, 23 Oct 1995 19:53:21 +1000 Date: Mon, 23 Oct 1995 19:53:21 +1000 From: Stephen McKay Message-Id: <199510230953.TAA22795@orion.devetir.qld.gov.au> To: Steven Wallace cc: freebsd-hackers@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Sender: owner-hackers@freebsd.org Precedence: bulk Steven Wallace wrote: >> semsys() and shmsys() syscall interfaces are BAD because they >> multiplex several syscalls that have different types of args. >> There was no reason to duplicate this sysv braindamage but now >> we're stuck with it. NetBSD has reimplemented the syscalls properly >> as separate syscalls #220-231. >> >I agree. This is yucky! > >We need a better way to handle these syscall subcodes (as SYSV calls 'em). Is it not true that this System V stuff can be written as library routines that use BSD facilities such as mmap() and sockets? I would be happy to see the effort expended this way so that I can keep my kernel free of such cruft. Stephen McKay. From owner-freebsd-hackers Mon Oct 23 03:07:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA01418 for hackers-outgoing; Mon, 23 Oct 1995 03:07:57 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA01409 ; Mon, 23 Oct 1995 03:07:54 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA12962; Mon, 23 Oct 1995 03:07:48 -0700 To: hackers@freebsd.org cc: ache@freebsd.org Subject: Grrr! Startslip ate my brain! Date: Mon, 23 Oct 1995 03:07:48 -0700 Message-ID: <12960.814442868@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Well, OK, maybe it just nibbled a bit at the corners.. OK, OK, it didn't eat my brain at all! I just said that to get your attention. What it *DID* do, however, was totally fail to negotiate header compression! I was talking to David tonite about the slattach -c flag as opposed to -a, and it occured to me to check which form of VJ header compression I was using. Imagine my horror to find out that I haven't been using *any* form of compression up to now (no wonder my interactive performance didn't feel quite as fast as I thought it should!) and switching back to good old kermit + slattach had me working just peachy again. So my question is this: How do you select VJ compression options with startslip? Can we add this? I really like the simplicity that startslip affords me, but I can't really afford to have header compression not work - I do too much interactive work on freefall. Thanks! Jordan From owner-freebsd-hackers Mon Oct 23 03:52:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA02825 for hackers-outgoing; Mon, 23 Oct 1995 03:52:41 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA02819 for ; Mon, 23 Oct 1995 03:52:35 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA24992; Mon, 23 Oct 1995 20:37:17 +1000 Date: Mon, 23 Oct 1995 20:37:17 +1000 From: Bruce Evans Message-Id: <199510231037.UAA24992@godzilla.zeta.org.au> To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: New userconfig Sender: owner-hackers@freebsd.org Precedence: bulk >In order to meaninfully interpret the values assigned the basic ISA >device parameters, I currently make the following assumptions : >If a parameter is -1, the driver does not use the parameter. It is never >relevant, and is never consulted. >If a parameter is -2, the driver has a compiled-in default for this parameter, >but the default can be overridden by setting the value to another value. Note that userconfig can't use special values to decide which values can be changed, since it needs to be able to change to and from all values. Currently unadvertised driver capablities determine which values actually make sense. The -1 and -2 above are back to front. -1 has always meant `?' (autoconfig). There is a special rule for this in config/lang.l. Drivers should never use compiled in defaults for this, but they may use values read from firmware. >Joerg has kindly provided details for modifying config(8) to recognise >'auto' and 'none' as alternatives to '?'. I'd like to ask further for >comments (and advice) on setting the _default_ for nonspecified parameters >to 'none' (-1), rather than the currently ambiguous state (some -1, some 0). `none' is a verbose alternative to `'. I think nonspecified parameters always have a value of -1 except in cases where 0 is more natural (for pointers and bitmaps). >Julian, specifically to you, and generally to anyone else working on device >driver registration issues - is there a "better way", that takes advantage >of the devfs concept/support/etc? I think you'll eventually have to modify device tables in 1001 drivers. Bruce From owner-freebsd-hackers Mon Oct 23 04:19:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA04063 for hackers-outgoing; Mon, 23 Oct 1995 04:19:45 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA04058 for ; Mon, 23 Oct 1995 04:19:33 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id UAA02636; Mon, 23 Oct 1995 20:44:26 +0930 From: Michael Smith Message-Id: <199510231114.UAA02636@genesis.atrad.adelaide.edu.au> Subject: Re: New userconfig To: bde@zeta.org.au (Bruce Evans) Date: Mon, 23 Oct 1995 20:44:25 +0930 (CST) Cc: hackers@freebsd.org, msmith@atrad.adelaide.edu.au In-Reply-To: <199510231037.UAA24992@godzilla.zeta.org.au> from "Bruce Evans" at Oct 23, 95 08:37:17 pm Content-Type: text Content-Length: 1975 Sender: owner-hackers@freebsd.org Precedence: bulk Bruce Evans stands accused of saying: > Note that userconfig can't use special values to decide which values can be > changed, since it needs to be able to change to and from all values. > Currently unadvertised driver capablities determine which values actually > make sense. Given that the driver parameters are unadvertised, special values have to be used, unless you care to suggest an alternative form of telepathy. > The -1 and -2 above are back to front. -1 has always meant `?' > (autoconfig). There is a special rule for this in config/lang.l. No problem; I'll use -1 for auto, and -2 for none. The distinction needs to be made either way. > Drivers should never use compiled in defaults for this, but they may use > values read from firmware. Some drivers, as has already been established, need to use compiled-in defaults in order to function usefully in this imperfect world 8( > `none' is a verbose alternative to `'. I think nonspecified parameters > always have a value of -1 except in cases where 0 is more natural (for > pointers and bitmaps). Is anything specific going to break if nonspecified parameters become -2, rather than -1? > I think you'll eventually have to modify device tables in 1001 drivers. Indeed; however before I commit bloody murder on the statically defined device attributes, I'd like some input from those with a little more experience 8) (I'd also like some reassurance that I can 'make world' -current from -stable and have a reasonable chance of getting somewhere, so that I can get in step with the current state of the art) > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 23 05:19:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAB04837 for hackers-outgoing; Mon, 23 Oct 1995 05:19:07 -0700 Received: from mtc.relinfo.mari.su (relay.relinfo.mari.su [193.124.110.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA04829 for ; Mon, 23 Oct 1995 05:18:16 -0700 Received: by mtc.relinfo.mari.su id AA29349 (5.65/IDA-simtel for hackers@freebsd.org); Mon, 23 Oct 1995 15:22:28 +0300 Message-Id: <199510231222.AA29349@mtc.relinfo.mari.su> From: news-service@mtc.relinfo.mari.su (News Mailing Service) To: hackers@freebsd.org Subject: reply from USENET server Date: Mon, 23 Oct 95 15:22:28 GMT Sender: owner-hackers@freebsd.org Precedence: bulk Relcom News Server, version 2.8.0.18 Copyright (C) 1991-1994 Serge Vakulenko Modifications 1993 Aleksei Rudnev Mon Oct 23 15:22:28 1995 --On ftp.freebsd.org/pub/FreeBSD/2.1.0-951020-SNAP/floppies --These fix many reported problems.. Thanks for the feedback, folks, --and please keep it coming! Every bug fixed now is one less we'll have --for 2.1. You are not registered on this server -- Jordan From owner-freebsd-hackers Mon Oct 23 07:17:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07882 for hackers-outgoing; Mon, 23 Oct 1995 07:17:36 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA07877 for ; Mon, 23 Oct 1995 07:17:25 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) id PAA10461 for freebsd.org!hackers; Mon, 23 Oct 1995 15:12:55 +0100 Received: from wup.de by wup-gate with smtp (Smail3.1.28.1 #2) id m0t7Nfn-0007rLC; Mon, 23 Oct 95 15:16 MET Received: from sunny.wup.de by wup.de (4.1/SMI-4.1) id AA10048; Mon, 23 Oct 95 15:04:57 +0100 Received: by sunny.wup.de (5.x/SMI-SVR4) id AA00655; Mon, 23 Oct 1995 15:08:40 +0100 Date: Mon, 23 Oct 1995 15:08:40 +0100 From: Andreas Klemm Message-Id: <9510231408.AA00655@sunny.wup.de> To: hackers@freebsd.org Subject: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) Newsgroups: comp.security.announce Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! Do you know this CERET Advisory already ?! Strange for me, that a Linux version with a certain libc release is 1. proofed by CERT and 2. mentioned to be secure and FreeBSD isn't mentioned ..... what does it mean ... a) CERT doesn't test FreeBSD ? b) FreeBSD still has the mentioned security hole ? Regards Andreas /// Newsgroups: comp.security.announce Path: wup-gate.wup.de!news.gun.de!genesis.westend.com!news.rwth-aachen.de!news.dfn.de!scsing.switch.ch!swidir.switch.ch!in2p3.fr!oleane!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!chi-news.cic.net!uwm.edu!math.ohio-state.edu!cis.ohio-state.edu!nntp.sei.cmu.edu!news.sei.cmu.edu!cert-advisory From: CERT Advisory Subject: CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) Message-ID: <1995Oct19.140427.10159@sei.cmu.edu> Originator: cert-advisory@why.cert.org Keywords: security CERT Sender: netnews@sei.cmu.edu (Netnews) Reply-To: cert-advisory-request@cert.org Organization: CERT Coordination Center - 412-268-7090 Date: Thu, 19 Oct 1995 14:04:27 EDT Approved: cert-advisory@cert.org Lines: 363 ============================================================================= CA-95:13 CERT Advisory October 19, 1995 Syslog Vulnerability - A Workaround for Sendmail ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of problems with the syslog(3) subroutine. To the best of our current knowledge, the problem is present in virtually all versions of the UNIX Operating System except the following: Sony's NEWS-OS 6.X SunOS 5.5 (Solaris 2.5) Linux with libc version 4.7.2, released May 1995 We have received reports indicating that the vulnerability is being exploited with a script that has been written to be used with sendmail. This advisory includes a workaround that you can use with sendmail. It *does not* include workarounds for any other programs that use the syslog(3) subroutine--telnetd, ftpd, httpd, etc. The CERT Coordination Center recommends installing all appropriate syslog-related patches as soon as they are available from vendors. But, in the meantime, we suggest addressing at least the syslog problem in sendmail by installing sendmail version 8.7.1. We are aware that several workarounds concerning the syslog vulnerability have been published on the Internet, but the CERT staff has not formally evaluated them. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:13.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The syslog(3) subroutine uses an internal buffer for building messages that are sent to the syslogd(8) daemon. This subroutine does no range checking on data stored in this buffer. It is possible to overflow the internal buffer and rewrite the subroutine call stack. It is then possible to execute arbitrary programs. This problem is present in virtually all versions of the UNIX Operating System except the following: Sony's NEWS-OS 6.X SunOS 5.5 (Solaris 2.5) Linux with libc version 4.7.2 released in May, 1995 The sendmail(8) program uses the syslog(3) subroutine, and a script has been written and is being used to exploit the vulnerability. II. Impact Local and remote users can execute commands. Prior access to the system is not needed. Exploitation can lead to root access. III. Solution We recommend that you do all of A, B, and C. A. Install syslog patches from your vendor when they become available. Information we received from vendors as of the date of this advisory is attached as Appendix A and reproduced in CA-95:13.README. We will update the README file as vendors send updated information. When you install patches, you will need to recompile/relink any programs built on your system that have been compiled without shared libraries, that is, compiled statically. Be especially careful of programs that contain their own versions of the syslog(3) subroutine. You may need to do significant extra work to compile those programs to use the vendor-supplied patches. B. Install sendmail version 8.7.1. NOTE: This workaround addresses the syslog(3) vulnerability in sendmail only. The vulnerability still exists in all other programs that use syslog(3). When your vendor(s) provides a patch, we recommend that you rebuild sendmail version 8.7.1 with the patched syslog(3) and place that newly compiled version into service. Sendmail is available by anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksum: MD5 (sendmail.8.7.1.tar.Z) = 4a66d07a059d1d5af5e9ea53ff1b396a Depending upon your currently installed sendmail program, switching to a different sendmail may require significant effort (such as rewriting the sendmail.cf file). See Section VI for additional notes on installation. In addition, Sections IV and V below contain scripts for building sendmail 8.7.1 for SunOS 4.1.X and Solaris 2.X, respectively. C. Install smrsh. To restrict the sendmail program mailer facility, install and use the sendmail restricted shell program (smrsh). We recommend that you do this regardless of whether you use the vendor's supplied sendmail or you install sendmail version 8.7.1. Smrsh is now included in the sendmail 8.7.1 distribution in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. IV. Building this package for SunOS 4.1.X Here is a script that is given as an illustration of how to build sendmail 8.7.1 for SunOS 4.1.X. Please refer to READ_ME in the src subdirectory for a more complete explanation of other options available during the compilation process. % uname -sr SunOS 4.1.2 % ls sendmail.8.7.1.tar.Z % zcat sendmail.8.7.1.tar.Z | tar xf - % cd sendmail-8.7.1/src % ./makesendmail LIBS='-lresolv' DBMDEF='-DNDBM -DNIS' \ INCDIRS= LIBDIRS= sendmail Configuration: os=SunOS, rel=4.1.2, rbase=4, arch=sun4, sfx= Creating obj.SunOS.4.1.2.sun4 using Makefile.SunOS Making dependencies in obj.SunOS.4.1.2.sun4 Making in obj.SunOS.4.1.2.sun4 ... See Section VI for final installation steps. V. Building this package for Solaris 2.X Here is a typescript that is given as an illustration for how to build sendmail 8.7.1 for Solaris 2.X. Note that this procedure assumes that you have the GNU gcc system. The examples below used gcc version 2.6.3. Again, please refer to READ_ME in the src sub-directory for a more complete explanation of other options available during the compilation process. % uname -sr SunOS 5.4 % ls sendmail.8.7.1.tar.Z % zcat sendmail.8.7.1.tar.Z | tar xf - % cd sendmail-8.7.1/src % ./makesendmail LIBS='-lresolv -lsocket -lnsl -lelf' \ INCDIRS= LIBDIRS= sendmail Configuration: os=SunOS, rel=5.4, rbase=5, arch=sun4, sfx= Creating obj.SunOS.5.4.sun4 using Makefile.SunOS.5.4 Making dependencies in obj.SunOS.5.4.sun4 ... Note: If you wish sendmail version 8.7.1 to use the aliases and configuration file directory conventions from SunOS 5.4, use the following command: ./makesendmail LIBS='-lresolv -lsocket -lnsl -lelf' \ ENVDEF='-DSOLARIS=204 -DUSE_VENDOR_CF_PATH' INCDIRS= \ LIBDIRS= sendmail VI. Final Installation Notes Sendmail can then be installed and configured with new configuration files as needed. We strongly recommend that if you change to sendmail 8.7.1, you also change to the configuration files that are provided with that version. Significant work has been done to make this task easier. It is now possible to build a sendmail configuration file (sendmail.cf) using the configuration files provided with this release. Consult the cf/READ_ME file for a more complete explanation. We recommended that you create your configuration files using this method because it provides a technique for incorporating any future changes to sendmail into your configuration files. In addition, we recommend that you recreate your configuration file (sendmail.cf) using the configuration files provided with 8.7.1. Finally, for Sun users, a paper is available to help you convert your sendmail configuration files from the Sun version of sendmail to one that works with version 8.7.1. The paper is entitled "Converting Standard Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of Texas Instruments Inc. It is included in the distribution and is located in contrib/converting.sun.configs. --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Eric Allman and Wolfgang Ley for their involvement in the development of this advisory, and thanks Karl Strickland and Neil Woods for reporting the vulnerability. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org), or PEM (contact CERT staff for details). Internet email: cert@cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request@cert.org. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. .............................................................................. Appendix A: Vendor Information Current as of October 19, 1995 See CA-95.13.README for updated information. Below is information we have received from vendors concerning the vulnerability described in this advisory. If you do not see your vendor's name, please contact the vendor directly for information. In addition to vendor information, note that the freely available Linux with libc version 4.7.2, released May 1995, is not vulnerable. -------------------- Eric Allman Sendmail version 8.7.1 is not vulnerable. This version is available by anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksum: MD5 (sendmail.8.7.1.tar.Z) = 4a66d07a059d1d5af5e9ea53ff1b396a -------------------- Berkeley Software Design, Inc. Users of BSD/OS V2.0 and V2.0.1 by Berkeley Software Design, Inc. should install patch U201-001 which works for both versions. The patch is available to all BSDI customers in: ftp://ftp.bsdi.com/bsdi/patches/ md5 checksum: 88b3fd8c83a5926589d7b87b55bc4e14 -------------------- Cray Research Information about fixes for the syslog problem can be found in FN #2011, dated October 10, 1995. Customers should receive this information from their Cray Research service representative. For all source installations, your Cray Research service representative can obtain the fix via the getfix tool. Due to the number of executables which use this library routine, it is not possible to provide getfix packages for all binary installations. UNICOS binary update packages 8.0.4.2 and 9.0.1.2 include this mod. FIX AVAILABILITY ---------------- Release Level Fix Package Affected Product Containing Fix Availability ================ ============== =========== UNICOS 8.0 UNICOS 8.0.4.2 * source only UNICOS 8.3 ** source only UNICOS 9.0 UNICOS 9.0.1.2 * source only * This update is not yet available. ** No more updates planned -------------------- Digital Equipment Corporation At the time of writing this document, patches(binary kits) for Digital's ULTRIX platforms are in final testing and packaging. V4.3 (both VAX and RISC) thru V4.5. Similar patches(binary kits) for OSF/1 versions are in progress and testing is expected to begin the week of October 23, 1995 and then packaged for Customer distribution estimated to available in November. Digital will provide notice of the completion of the kits through AES services (DIA, DSNlink FLASH) and be available from your normal Digital Support channel. Digital's Software Security Response Team 10/18/95 -------------------- Open Software Foundation OSF cannot reproduce the security hole in OSF/1. However we have reproduced the problem with syslog(3). We have a fix for the syslog(3) problem. Support customers should contact OSF for the fix. The fix will be included in the OSF/1 R1.3.2 update release. -------------------- Silicon Graphics Inc. SGI has been in coordination with CERT regarding this issue. Specific SGI information was not complete before CERTs submission deadline for this advisory. SGI does have pending information and this information will be available via anonymous ftp (sgigate.sgi.com) and/or your SGI service provider and potential future CERT advisory addendums. -------------------- Solbourne (Grumman) Solbourne 2.5 is not vulnerable. -------------------- Sony Corporation NEWS-OS 6.0.3 and 6.1 are not vulnerable. -------------------- Sun Microsystems, Inc. SunOS 5.5 is not vulnerable. -- andreas@wup.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - From owner-freebsd-hackers Mon Oct 23 07:53:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08932 for hackers-outgoing; Mon, 23 Oct 1995 07:53:22 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA08924 for ; Mon, 23 Oct 1995 07:53:16 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA04819; Tue, 24 Oct 1995 00:51:31 +1000 Date: Tue, 24 Oct 1995 00:51:31 +1000 From: Bruce Evans Message-Id: <199510231451.AAA04819@godzilla.zeta.org.au> To: bde@zeta.org.au, msmith@atrad.adelaide.edu.au Subject: Re: New userconfig Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> Note that userconfig can't use special values to decide which values can be >> changed, since it needs to be able to change to and from all values. >> Currently unadvertised driver capablities determine which values actually >> make sense. >Given that the driver parameters are unadvertised, special values have to be >used, unless you care to suggest an alternative form of telepathy. Given that there are no special values, sysconfig can't refuse to change any value. It must be possible to change from the "can't change" value to any value without dropping back to the command line userconfig (BTW, visuserconfig() always clears the screen and returns 1 so that it is impossible to drop back to the command line or see what you were doing if you could). >> Drivers should never use compiled in defaults for this, but they may use >> values read from firmware. >Some drivers, as has already been established, need to use compiled-in >defaults in order to function usefully in this imperfect world 8( They should be fixed. >Is anything specific going to break if nonspecified parameters become -2, >rather than -1? Probably not. grep 'iobase == ' in isa/*.c shows only a test against IOBASEUNK in NetBSD (?) code in aic6360.c. grep 'iobase <' shows some bogus insensitive tests in asc.c, gsc.c and lpt.c. These tests once broken when id_iobase was changed to an unsigned type like it should be. Bruce From owner-freebsd-hackers Mon Oct 23 08:11:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09500 for hackers-outgoing; Mon, 23 Oct 1995 08:11:04 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09432 for ; Mon, 23 Oct 1995 08:09:29 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id KAA11912; Mon, 23 Oct 1995 10:09:24 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id KAA15592; Mon, 23 Oct 1995 10:31:33 -0500 Message-Id: <199510231531.KAA15592@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Brian Litzinger cc: hackers@freebsd.org Subject: Re: linux emulations how to? In-reply-to: Your message of "Sun, 22 Oct 1995 02:45:03 PDT." <199510220945.CAA16433@MediaCity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Oct 1995 10:31:32 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk > I compiled a -current kernel with COMPAT_LINUX and booted it. > On Friday I spent a few minutes trying to make a linux_lib port which would ftp/install the proper linux libraries for linux-compat I couldn't get the slackware 2.3 libs to work. Then I found three different sets of libs on local machines here. I found this combination to work: ld.so libXaw.so.3 libXt.so.3.1.0 libgr.so.1 libm.so.4.5.26 libX11.so.3 libXaw.so.3.1.0 libc.so.4 libgr.so.1.3 libX11.so.3.1.0 libXt.so.3 libc.so.4.5.26 libm.so.4 But I'm thinking now it's more of an issue with ld.so than the libraries themselves. I'm still looking for a public ftp that has older linux libs, when I find something I'll finish out the linux library port. BTW, I've got linux ports of mapleV and Wingz (commercial demos), and I'll get a doom port when these library issues are fixed. > > -- > Brian Litzinger | | > brian@mediacity.com | This space intentionally left blank | > http://www.mpress.com | | > eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Mon Oct 23 08:50:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11250 for hackers-outgoing; Mon, 23 Oct 1995 08:50:47 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11235 for ; Mon, 23 Oct 1995 08:50:42 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id HAA26347; Mon, 23 Oct 1995 07:54:24 -0400 From: Peter Dufault Message-Id: <199510231154.HAA26347@hda.com> Subject: Re: What is the best way... To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 23 Oct 1995 07:54:24 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510221818.TAA03456@uriah.heep.sax.de> from "J Wunsch" at Oct 22, 95 07:18:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1178 Sender: owner-hackers@freebsd.org Precedence: bulk > > ...to implement something similar to the xxx_poll() driver entry > points in SysV? > > For those whod don't know, these entries are supposed to be called on > each clock tick (at spl6, i think this is `soft clock'), and they are > useful for devices that lose interrupts, or that don't even have an > interrupt of its own. > > The closest thing one could do (besides from the approach e.g. > pcaudio is using, which i consider being overkill as a poll() > replacement) were to continuously re-issue yet another timeout on each > clock tick. However, since that would cause timeout() to walk the > entire timer queue, it's rather expensive. The special case of calling the function at every tick that you specify will be nice and fast, since timeout() only must adjust the tick delta based on those functions that will be called before the one you are installing is to be called. Fortunately, the faster the ticks are the less time is spent hunting through the queue for the insertion point. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Mon Oct 23 08:56:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11558 for hackers-outgoing; Mon, 23 Oct 1995 08:56:19 -0700 Received: from fgate.flevel.co.uk (fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11553 for ; Mon, 23 Oct 1995 08:56:11 -0700 Received: (from freebsd@localhost) by fgate.flevel.co.uk (8.6.11/8.6.9) id QAA05512; Mon, 23 Oct 1995 16:59:45 +0100 Date: Mon, 23 Oct 1995 16:59:43 +0100 (BST) From: freebsd To: hackers@freebsd.org cc: freebsd@fgate.flevel.co.uk Subject: Lists and quotas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi all, I have two questions: 1) Where can I find a decent mailing list server for FreeBSD? 2) What is the format of the quota.user and quota.group files (I can't find it anywhere :) ) ? Thanks in advance. Graham Breach From owner-freebsd-hackers Mon Oct 23 09:36:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12907 for hackers-outgoing; Mon, 23 Oct 1995 09:36:24 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA12902 for ; Mon, 23 Oct 1995 09:36:22 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t7PrJ-0003x8C; Mon, 23 Oct 95 09:36 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id RAA00411 for ; Mon, 23 Oct 1995 17:36:20 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org Reply-to: phk@freebsd.org Subject: Help with japanese needed. Date: Mon, 23 Oct 1995 17:36:20 +0100 Message-ID: <409.814466180@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk Check out this URL, and if you understand japanese, please: 1) translate it all... 2) find out if FreeBSD will run on it... 2) find out when & where I can buy one... http://www.ibm.co.jp/jpccinfo/thinkpad/palm_110 I gather as much as we are talking about a 715g palmtop with 260 Mb disk... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Just that: dried leaves in boiling water ? From owner-freebsd-hackers Mon Oct 23 09:48:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13396 for hackers-outgoing; Mon, 23 Oct 1995 09:48:00 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA13391 for ; Mon, 23 Oct 1995 09:47:46 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id MAA26590; Mon, 23 Oct 1995 12:39:00 -0400 Date: Mon, 23 Oct 1995 12:38:58 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: Lists and quotas To: freebsd cc: hackers@freebsd.org, freebsd@fgate.flevel.co.uk In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Mon, 23 Oct 1995, freebsd wrote: > 1) Where can I find a decent mailing list server for FreeBSD? use majordomo-1.92, the FreeBSD mailing lists do! change: /usr/local/bin/perl -> /usr/bin/perl /usr/lib/sendmail -> /usr/sbin/sendmail and in the unlink() calls in resend, bracket the arg with < and > in place of " and ". (a bug in majordomo-1.92 that causes files to accumlate in /tmp) Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Mon Oct 23 09:54:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13530 for hackers-outgoing; Mon, 23 Oct 1995 09:54:18 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA13517 ; Mon, 23 Oct 1995 09:54:13 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA21856; Mon, 23 Oct 1995 10:56:02 -0600 Date: Mon, 23 Oct 1995 10:56:02 -0600 From: Nate Williams Message-Id: <199510231656.KAA21856@rocky.sri.MT.net> To: "Eric L. Hernes" Cc: hackers@freebsd.org, sos@freebsd.org Subject: Re: linux emulations how to? In-Reply-To: <199510231531.KAA15592@jake.lodgenet.com> References: <199510220945.CAA16433@MediaCity.com> <199510231531.KAA15592@jake.lodgenet.com> Sender: owner-hackers@freebsd.org Precedence: bulk > On Friday I spent a few minutes trying to make a linux_lib port > which would ftp/install the proper linux libraries for linux-compat > I couldn't get the slackware 2.3 libs to work. Then I found > three different sets of libs on local machines here. I found > this combination to work: > > ld.so > libXaw.so.3 > libXt.so.3.1.0 > libgr.so.1 > libm.so.4.5.26 > libX11.so.3 > libXaw.so.3.1.0 > libc.so.4 > libgr.so.1.3 > libX11.so.3.1.0 > libXt.so.3 > libc.so.4.5.26 > libm.so.4 > > But I'm thinking now it's more of an issue with ld.so than > the libraries themselves. My experience has been that the linux emulator doesn't work unless the libraries AND the ld.so program are ZMAGIC executables. The emulator seems to work fine running QMAGIC executables, but not when the libraries or run-time linker is that format. Nate From owner-freebsd-hackers Mon Oct 23 09:59:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13742 for hackers-outgoing; Mon, 23 Oct 1995 09:59:13 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA13737 for ; Mon, 23 Oct 1995 09:59:08 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7QDC-000078C; Mon, 23 Oct 95 09:58 PDT Message-Id: Date: Mon, 23 Oct 95 09:58 PDT From: jdp@polstra.com (John Polstra) To: imp@village.org Cc: freebsd-hackers@freebsd.org Subject: Re: Problem with ptk-b8 .. ld problems already fixed? Sender: owner-hackers@freebsd.org Precedence: bulk > I'm trying to get pTk-p8 up and running on my FreeBSD 2.0 and got the > following error. Look familiar to anybody? > > ld.so: Undefined symbol "__XInitImageFuncPtrs" in perl:./blib/auto/Tk/Tk.so > > Tk.so looks to be referencing X11, but can't seem to find this in libX11, > even though it is in my copy (per nm output). I think the problem you're seeing is caused by a combination of an old version of ld.so, and an improperly-built tk library. First I should confess that while I know a lot about ld.so, I don't know anything about pTk-p8. So I'm flying half blind here. But it looks like "./blib/auto/Tk/Tk.so" is a shared object which perl is trying to load at runtime via dlopen(), and that's the assumption I'll use. Please correct me if I'm wrong about that. First, the problem in ld.so. The version in 2.0.5 did not do so-called "cascade loading" properly. As an example, if Tk.so needs -ltk, and -ltk needs -lX11, ld.so should load -ltk and -lX11 automatically when it is called upon by dlopen() to load Tk.so. But it did not quite do that right in 2.0.5. The situation is improved in the version of ld.so that is in -current at the present time. It's still not 100% right, but it's usable anyway. It's definitely worth getting the latest version. (Actually, I think you must already have a more recent version. I'm pretty sure that the version of ld.so that came with 2.0.5 would have simply said "ld.so failed" rather than telling you about the undefined symbol.) Second, the problem in the "tk" library. How could ld.so possibly know that when it loads Tk.so that it will also need to load the other libraries such as -ltk and -lX11? The answer is that such "shared object dependencies" are recorded in the shared objects themselves. For example, when you build the "tk" library, you should do it something like this: ld -Bshareable ... -ltcl -lX11 The dependencies on the "tcl" and "X11" libraries are then recorded in the "tk" library itself, so that ld.so will know it has to load those other libraries too. The current "tk" library that is distributed with the FreeBSD packages wasn't built that way, and that's a problem. (I apologize for failing to bring this up with Satoshi Asami, our friendly ports czar. It's not his fault!) Actually, there's a third problem as well. The static linker "ld" has a bug, in that it doesn't detect some undefined symbols when building a shared library. Really, it should not be possible to even build the "tk" shared library without specifying the libraries it depends on in the "ld" command line. "ld" should complain about undefined symbols in that case. But it doesn't. I'm working on all these things, so please be patient. Meanwhile, I think you can work around your present problem by: * Installing an up-to-date version of "ld.so", and * Specifying "-ltk -ltcl -lX11" on the "ld" command line that you use to build "Tk.so". Please let me know if that doesn't work. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon Oct 23 10:11:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA14104 for hackers-outgoing; Mon, 23 Oct 1995 10:11:29 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA14074 ; Mon, 23 Oct 1995 10:09:33 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id MAA12884; Mon, 23 Oct 1995 12:09:32 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id MAA19172; Mon, 23 Oct 1995 12:29:15 -0500 Message-Id: <199510231729.MAA19172@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Nate Williams cc: "Eric L. Hernes" , hackers@freebsd.org, sos@freebsd.org Subject: Re: linux emulations how to? In-reply-to: Your message of "Mon, 23 Oct 1995 10:56:02 MDT." <199510231656.KAA21856@rocky.sri.MT.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Oct 1995 12:29:15 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk > > > > But I'm thinking now it's more of an issue with ld.so than > > the libraries themselves. > > My experience has been that the linux emulator doesn't work unless the > libraries AND the ld.so program are ZMAGIC executables. The emulator > seems to work fine running QMAGIC executables, but not when the > libraries or run-time linker is that format. > Yup, the set that works are all ZMAGIC. The ones that don't are mixtures of [QZ]MAGIC. I'll look for ZMAGIC's on the net (or maybe make a local-port) > > > Nate eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Mon Oct 23 11:03:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15252 for hackers-outgoing; Mon, 23 Oct 1995 11:03:55 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15247 for ; Mon, 23 Oct 1995 11:03:45 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA01856; Mon, 23 Oct 1995 13:02:10 -0500 From: Joe Greco Message-Id: <199510231802.NAA01856@brasil.moneng.mei.com> Subject: Re: NCR810/Barracuda Question To: smace@metal.ops.neosoft.com (Scott Mace) Date: Mon, 23 Oct 1995 13:02:09 -0500 (CDT) Cc: se@zpr.uni-koeln.de, hackers@freebsd.org In-Reply-To: <199510191527.KAA03934@metal.ops.neosoft.com> from "Scott Mace" at Oct 19, 95 10:27:37 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > > } ncr1: targ 2? ERROR(80:100) (e-ab-2) (8/13)@(10d4:e000000) > > ^^^ > > handshake timeout > > > > } reg: da 10 0 13 47 8 2 1f 0 e 82 ab 80 0 3 0 > > > > Are you sure that there are excactly two terminators (i.e. is there > > possibly one on the Barracuda) ? > > I've seen similar problems if the terminiation power is coming from the > drive and is also coming from the card. I always set it up so the drive > gets term power from the bus, and have never had a problem. Nope, that's not it. The termination is religious, except that it's not a slick terminator. It works fine under DOS. It also works under the 102095 SNAP floppy (or at least it was able to newfs filesystems and the like). I would very much like to be able to install a new set of drivers without upgrading the OS. The machine in question is a production news server and taking it down is bad enough... doing an upgrade at the same time would be rather painful. Is there any way I could just upgrade the driver? (which files do I need?) Thanks for any suggestions, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Mon Oct 23 11:15:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15404 for hackers-outgoing; Mon, 23 Oct 1995 11:15:45 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15399 for ; Mon, 23 Oct 1995 11:15:40 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id CAA19128 for freebsd-hackers@freebsd.org; Tue, 24 Oct 1995 02:15:23 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-hackers@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-hackers@freebsd.org Date: 24 Oct 1995 02:14:48 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <46gm2o$ikl$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <9510231408.AA00655@sunny.wup.de> Subject: Re: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) Sender: owner-hackers@freebsd.org Precedence: bulk andreas@sunny.wup.de (Andreas Klemm) writes: >Hi ! >Do you know this CERET Advisory already ?! >Strange for me, that a Linux version with a certain libc release >is 1. proofed by CERT and 2. mentioned to be secure and >FreeBSD isn't mentioned ..... what does it mean ... > a) CERT doesn't test FreeBSD ? > b) FreeBSD still has the mentioned security hole ? >Regards > Andreas /// FreeBSD has fixed the hole, IMHO better than the others, but it used one of the advanced 4.4BSD stdio features to do it more securely (fwopen()/vfprintf() instead of umpteen strlen()/snprintf()). They covered FreeBSD/NetBSD (not by name) by saying: there are different patches available for other operating systems, but these have not been evaluated by cert, blah, blah. Both Free/NetBSD did it their own way. -Peter >-- >andreas@wup.de /\/\___ Wiechers & Partner Datentechnik GmbH >Andreas Klemm ___/\/\/ - Support Unix - From owner-freebsd-hackers Mon Oct 23 11:24:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15643 for hackers-outgoing; Mon, 23 Oct 1995 11:24:59 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA15637 for ; Mon, 23 Oct 1995 11:24:55 -0700 Received: by sequent.kiae.su id AA03698 (5.65.kiae-2 ); Mon, 23 Oct 1995 22:19:19 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 23 Oct 95 22:19:18 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id VAA00591; Mon, 23 Oct 1995 21:10:28 +0300 To: hackers@freebsd.org, "Jordan K. Hubbard" References: <12960.814442868@time.cdrom.com> In-Reply-To: <12960.814442868@time.cdrom.com>; from "Jordan K. Hubbard" at Mon, 23 Oct 1995 03:07:48 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 23 Oct 1995 21:10:28 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Grrr! Startslip ate my brain! Lines: 16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 749 Sender: owner-hackers@freebsd.org Precedence: bulk In message <12960.814442868@time.cdrom.com> Jordan K. Hubbard writes: >So my question is this: How do you select VJ compression options with >startslip? Can we add this? I really like the simplicity that >startslip affords me, but I can't really afford to have header >compression not work - I do too much interactive work on freefall. It is easy, all headers compression was selected via startup scripts, see examples/startslip/slup.sh for example. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 11:38:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17156 for hackers-outgoing; Mon, 23 Oct 1995 11:38:27 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA17142 for ; Mon, 23 Oct 1995 11:38:14 -0700 Received: by Sysiphos id AA12365 (5.67b/IDA-1.5 for hackers@freebsd.org); Mon, 23 Oct 1995 19:33:44 +0100 Message-Id: <199510231833.AA12365@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 23 Oct 1995 19:33:44 +0100 In-Reply-To: Joe Greco "Re: NCR810/Barracuda Question" (Oct 23, 13:02) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Joe Greco Subject: Re: NCR810/Barracuda Question Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 23, 13:02, Joe Greco wrote: } Subject: Re: NCR810/Barracuda Question } > > } ncr1: targ 2? ERROR(80:100) (e-ab-2) (8/13)@(10d4:e000000) } > > ^^^ } > > handshake timeout } > > } > > } reg: da 10 0 13 47 8 2 1f 0 e 82 ab 80 0 3 0 } > > } > > Are you sure that there are excactly two terminators (i.e. is there } > > possibly one on the Barracuda) ? } > } > I've seen similar problems if the terminiation power is coming from the } > drive and is also coming from the card. I always set it up so the drive } > gets term power from the bus, and have never had a problem. } } Nope, that's not it. The termination is religious, except that it's not a } slick terminator. } } It works fine under DOS. It also works under the 102095 SNAP floppy (or at } least it was able to newfs filesystems and the like). } } I would very much like to be able to install a new set of drivers without } upgrading the OS. The machine in question is a production news server and } taking it down is bad enough... doing an upgrade at the same time would be } rather painful. Is there any way I could just upgrade the driver? (which } files do I need?) The driver is completely cointained in "/sys/pci/ncr.c". (There is a "ncrreg.h" file in the same directory, but that has not changed since March '95 ...) Just get a new "ncr.c" and rebuild your kernel. Let me know, if you encounter any problems. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Mon Oct 23 11:39:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17240 for hackers-outgoing; Mon, 23 Oct 1995 11:39:31 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17234 for ; Mon, 23 Oct 1995 11:39:25 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA22178; Mon, 23 Oct 1995 12:41:13 -0600 Date: Mon, 23 Oct 1995 12:41:13 -0600 From: Nate Williams Message-Id: <199510231841.MAA22178@rocky.sri.MT.net> To: Terry Lambert Cc: nate@rocky.sri.MT.net (Nate Williams), kaleb@x.org, hackers@freefall.freebsd.org Subject: Re: Netscape puzzle In-Reply-To: <199510231828.LAA11375@phaeton.artisoft.com> References: <199510202122.PAA15970@rocky.sri.MT.net> <199510231828.LAA11375@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.org Precedence: bulk Terry Lambert writes: [ Netscape not working ] > Another potential datapoint: > > We are all aware of the bind/sendmail static data initialization shared > library changes, right? Refreh my memory. > The ones that Matt Day reported and provided patches for in both Linux > and BSD and to the package authors? I don't remember seeing it. Was in on the ports mailing list? Nate From owner-freebsd-hackers Mon Oct 23 11:52:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17783 for hackers-outgoing; Mon, 23 Oct 1995 11:52:10 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17538 for ; Mon, 23 Oct 1995 11:46:38 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11356; Mon, 23 Oct 1995 11:25:04 -0700 From: Terry Lambert Message-Id: <199510231825.LAA11356@phaeton.artisoft.com> Subject: Re: Netscape puzzle To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 23 Oct 1995 11:25:03 -0700 (MST) Cc: nate@rocky.sri.MT.net, hackers@freefall.freebsd.org In-Reply-To: <199510202133.RAA05549@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 20, 95 05:33:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 668 Sender: owner-hackers@FreeBSD.org Precedence: bulk > I had tried that and it didn't make any difference with the BSD 2.0b1, > I still got an "unable to open display" error. :-( I suggest compiling a program that does a: main() { printf( "DISPLAY is '%s'\n", getenv("DISPLAY")); } On a BSDI 2.0 system and running it on a FreeBSD box and seeing what you get. We already know there are differences in the way the environment code works, and you are highly dependeint on that code. Have you tried it with an explicit "-display" argument instead of relying on the environment? 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 Oct 23 12:01:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18231 for hackers-outgoing; Mon, 23 Oct 1995 12:01:47 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18225 for ; Mon, 23 Oct 1995 12:01:43 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA01971; Mon, 23 Oct 1995 14:01:00 -0500 From: Joe Greco Message-Id: <199510231901.OAA01971@brasil.moneng.mei.com> Subject: Re: NCR810/Barracuda Question To: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 23 Oct 1995 14:00:58 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510231833.AA12365@Sysiphos> from "Stefan Esser" at Oct 23, 95 07:33:44 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > } I would very much like to be able to install a new set of drivers without > } upgrading the OS. The machine in question is a production news server and > } taking it down is bad enough... doing an upgrade at the same time would be > } rather painful. Is there any way I could just upgrade the driver? (which > } files do I need?) > > The driver is completely cointained in "/sys/pci/ncr.c". > (There is a "ncrreg.h" file in the same directory, but > that has not changed since March '95 ...) > > Just get a new "ncr.c" and rebuild your kernel. Let me > know, if you encounter any problems. That doesn't quite work: daily-planet# make cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I/usr/include -DDAILY_PLANET -DI586_CPU -DOPEN_MAX=256 -DCHILD_MAX=256 -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15 -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DMATH_EMULATE -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../pci/ncr.c ../../pci/ncr.c: In function `ncr_attach': ../../pci/ncr.c:3447: warning: implicit declaration of function `scsi_alloc_bus' ../../pci/ncr.c:3447: warning: assignment makes pointer from integer without a cast ../../pci/ncr.c:3453: structure has no member named `maxtarg' ../../pci/ncr.c:3457: structure has no member named `maxtarg' ../../pci/ncr.c:3471: warning: passing arg 1 of `scsi_attachdevs' from incompatible pointer type *** Error code 1 Stop. Ah well. :-/ I suppose we can wait for 2.1 to come out :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Mon Oct 23 12:04:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18406 for hackers-outgoing; Mon, 23 Oct 1995 12:04:29 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18398 for ; Mon, 23 Oct 1995 12:04:26 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11444; Mon, 23 Oct 1995 11:51:33 -0700 From: Terry Lambert Message-Id: <199510231851.LAA11444@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 23 Oct 1995 11:51:33 -0700 (MST) Cc: pst@shockwave.com, swallace@ece.uci.edu, bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: <26924.814325836@time.cdrom.com> from "Jordan K. Hubbard" at Oct 21, 95 06:37:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I can't imagine porting to (or being interested in) any > platform that did not support gcc, and if it did not then porting gcc > would be my first task anyway! I'm happy you feel this way. I'm using a Motorolla Ultra 603/604 PPC box, PReP compliant, running AIX as a cross-environment. When should I expect your GCC port that supports AIX imports/exports qualifiers that I'm currently using to try out BSD kernel code in the AIX kernel? Thanks, 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 Oct 23 12:07:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18733 for hackers-outgoing; Mon, 23 Oct 1995 12:07:12 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18676 for ; Mon, 23 Oct 1995 12:06:58 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11462; Mon, 23 Oct 1995 11:58:51 -0700 From: Terry Lambert Message-Id: <199510231858.LAA11462@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: swallace@ece.uci.edu (Steven Wallace) Date: Mon, 23 Oct 1995 11:58:50 -0700 (MST) Cc: bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: <199510212304.QAA06180@newport.ece.uci.edu> from "Steven Wallace" at Oct 21, 95 04:04:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2702 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > to get it right. First we need to catch up with 4.4lite2, which uses > > macros to handle struct padding. Then we need to catch up with NetBSD, > I hate that SCARG macro. It makes looking at the code harder to > understand. Perhaps if we did something like: > > read(struct proc *p, void *v, int retval[]) > { > struct read_args /* { > int fd; > char *buf; > u_int nbyte; > } */ *uap = v; > int fd = SCARG(uap, fd); > char *buf = SCARG(uap, buf); > u_int nbyte = SCARG(uap, nbyte); > > ... > } > > That way we don't have SCARG all over the place, and this would > prepare us for your static function idea. Seeing this on -hackers, I'd like to have someone back up and explain "the static function idea", since it seems likely that an alternate approact to the idea might be more fruitful than rewriting the system call interface such that we have to hack tables all over hell for no real gain. > > which passes the args correctly (as void *). Then we need to handle > > varargs functions and struct padding better. I think all the details > > can be hidden in machine-generated functions so that the args structs > > and verbose macros to reference them don't have to appear in the core > > sources. I have macros that divorce K&R and ANSI vararg behaviour from the code itself (I use them for various things myself). Is this what we are trying to accomplish? > > semsys() and shmsys() syscall interfaces are BAD because they > > multiplex several syscalls that have different types of args. > > There was no reason to duplicate this sysv braindamage but now > > we're stuck with it. NetBSD has reimplemented the syscalls properly > > as separate syscalls #220-231. > > I agree. This is yucky! No, this is good -- system calls are a scarce resource and should be consumed conservatively. What's the problem you have with anonymous argument vectors using subfunction codes? > We need a better way to handle these syscall subcodes (as SYSV calls 'em). I guess I don't really understand why these are a problem, unless you are trying to do something silly, like prototype them. > One idea I have is to use special case for the number of parms. > If it is < 0 then special handling should be taken. > case -1: Get code from next parameter. > case -2: Get code from next parameter (quad_t). > case -3: code = (code >> 8) & 0xff; (for ibcs2 xenix emulation) > Then use the function pointer as a pointer to a new sysent, > and do it all over again (making sure no recursion). 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 Oct 23 12:09:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAB18927 for hackers-outgoing; Mon, 23 Oct 1995 12:09:58 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA18912 for ; Mon, 23 Oct 1995 12:09:49 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7SFB-000078C; Mon, 23 Oct 95 12:09 PDT Message-Id: Date: Mon, 23 Oct 95 12:09 PDT From: jdp@polstra.com (John Polstra) To: ache@freefall.freebsd.org Cc: freebsd-hackers@freebsd.org Subject: ld.so, LD_NOSTD_PATH, and suid/sgid programs Sender: owner-hackers@freebsd.org Precedence: bulk [Andrey - I am cc'ing this to the freebsd-hackers list, because I would like to get some additional opinions about this topic.] Nate Williams and I have been doing a lot of work on ld.so lately, so I noticed with interest the recently committed change to rtld.c: > ache 95/10/21 07:52:49 > > Modified: gnu/usr.bin/ld/rtld rtld.c > Log: > if uid != euid or gid != egid unsetenv("LD_NOSTD_PATH") too I don't think that this change was such a good idea. On one hand, it adds yet another little bit of strangeness to the behavior of ld.so for suid/sgid programs. On the other hand, I do not believe that it solves a security problem, or improves the security of ld.so in any way. The dynamic linker already had code to ignore a different environment variable, LD_LIBRARY_PATH, for suid and sgid programs. That was and is important, because it does solve a serious security problem. If the dynamic linker honored LD_LIBRARY_PATH for a suid or sgid program, then a user could cause any suid or sgid program to execute his own arbitrary code with elevated permissions. He could do that simply by setting LD_LIBRARY_PATH so that his own version of libc got used instead of the standard system library. That is why the dynamic linker ignores LD_LIBRARY_PATH when uid != euid or gid != egid. But LD_NOSTD_PATH is not the same. It does not constitute any security threat, as far as I can see. All LD_NOSTD_PATH does is to cause ld.so _not_ to look in the standard places (/usr/lib) for shared libraries. It does not and cannot allow a user to substitute his own code, and have it executed with elevated permissions. At worst, a user can cause ld.so to _fail_ by setting LD_NOSTD_PATH. But that, in itself, is no security threat. It doesn't give a user the ability to do anything that he couldn't already do some other way. Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid programs? If not, I think that the recent change should be removed from rtld.c. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon Oct 23 12:11:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19036 for hackers-outgoing; Mon, 23 Oct 1995 12:11:35 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19029 for ; Mon, 23 Oct 1995 12:11:28 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11420; Mon, 23 Oct 1995 11:43:20 -0700 From: Terry Lambert Message-Id: <199510231843.LAA11420@phaeton.artisoft.com> Subject: Re: A quick vote on pthreads PLZ To: cimaxp1!jb@werple.net.au (John Birrell) Date: Mon, 23 Oct 1995 11:43:19 -0700 (MST) Cc: bde@zeta.org.au, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <199510212130.HAA06203@werple.net.au> from "John Birrell" at Oct 22, 95 07:05:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 797 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > would it do with all the places that return a pointer to static storage? > > These fall into three categories: > > (1) Functions which have a *_r() reentrant equivalent like readdir_r which > have extra arguments so that static storage is avoided. > (2) Functions which malloc memory and return that instead. The MIT code does > this in places. Return the static storage, as normal, unless create_thread() has been called, in which case, malloc the storage instead. > (3) Dunno what the solution is. No matter what it's supposed to be, what it *will* be is a static storage compatability hack. Static storage returns need to be deprecated. 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 Oct 23 12:13:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19163 for hackers-outgoing; Mon, 23 Oct 1995 12:13:31 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19156 for ; Mon, 23 Oct 1995 12:13:27 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00464; Mon, 23 Oct 1995 12:12:41 -0700 To: Terry Lambert cc: pst@shockwave.com, swallace@ece.uci.edu, bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Mon, 23 Oct 1995 11:51:33 PDT." <199510231851.LAA11444@phaeton.artisoft.com> Date: Mon, 23 Oct 1995 12:12:41 -0700 Message-ID: <462.814475561@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I'm using a Motorolla Ultra 603/604 PPC box, PReP compliant, running > AIX as a cross-environment. > > When should I expect your GCC port that supports AIX imports/exports > qualifiers that I'm currently using to try out BSD kernel code in the > AIX kernel? Never, but so what? People who use AIX under any circumstances are already so screwed that the compiler is the least of their worries.. :-) I did my time with AIX, and you'll get no sympathy from me. None whatsoever. I'd sooner cross-develop under XENIX! Jordan From owner-freebsd-hackers Mon Oct 23 12:15:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19288 for hackers-outgoing; Mon, 23 Oct 1995 12:15:04 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19282 for ; Mon, 23 Oct 1995 12:15:02 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11337; Mon, 23 Oct 1995 11:17:36 -0700 From: Terry Lambert Message-Id: <199510231817.LAA11337@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: cimaxp1!jb@werple.net.au (John Birrell) Date: Mon, 23 Oct 1995 11:17:36 -0700 (MST) Cc: leisner@sdsp.mc.xerox.com, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <199510202241.IAA26825@werple.net.au> from "John Birrell" at Oct 21, 95 08:44:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1392 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 3) Anyone have good hard numbers about the differences between user/kernel > > level threads on performance? > > No. We don't have a user-space implementation that works on a system with > kernel threads. We would have just used the kernel threads (like we do under > OSF/1^H^H^H^HDigital UNIX). 8-). I reimplemented Sun's LWP library, first on SunOS, then on BSD, and then later on Solaris and SVR4.2 (UnixWare). It's unfortunately one of the things that Novell felt "competed" with them (incorrectly: Novell didn't own USL at the time: USL felt they assumed all ownership, post-facto); I'd have to rewrite it to release it. The only performance comparisons I could make were on Solaris and SVR4.2. On the Solaris, there was a slightly higher system time and a lower user space time for kernel threads. On a Uniprocessor system, there was no significant difference. On SVR4.2 there was about a 12% advantage to user space threads on a UP system (probably attributable to their abominable page management practices compared to Sun). On MP systems, Solaris and SVR4 kernel threads both kicked user space threads butt's (but my test did not rely on a great deal of inter thread synchronization, so take it with a grain of salt). 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 Oct 23 12:19:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19591 for hackers-outgoing; Mon, 23 Oct 1995 12:19:32 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19581 ; Mon, 23 Oct 1995 12:19:28 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00523; Mon, 23 Oct 1995 12:19:19 -0700 To: hackers@freebsd.org cc: ache@freebsd.org Subject: startslip isn't just broken - it's EVIL! Date: Mon, 23 Oct 1995 12:19:18 -0700 Message-ID: <521.814475958@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk I've seen some bogus software in my day, but this one really tears it.. Not only does it have absolutely no concept of setting the VJ compression flags, but it has no provisions for multiple setup strings! Freefall doesn't deal with my TA correctly and whenever I connect I don't get a login banner - I have to hit return first (this is an oft-reported bit of FreeBSD braindamage - any plans to fix it someday?). Unfortunately, startslip is too stupid to cope with the idea of actually sending a return, much less a user defined string, if it doesn't get the prompt it's expecting. It just waits around forever. Bleah! Then there's the little cuteness of having changed the flags completely and utterly between 2.1 and current - any explanation for that decision? I've added VJ compression support to sliplogin, but these other problems I've been having with it in the wake of making those changes (I can't even *test* them because the friggin' thing won't log in!!) make me think that startslip doesn't need to be improved, it needs to be re-written from scratch and I may just do that right now.. Jordan From owner-freebsd-hackers Mon Oct 23 12:22:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19751 for hackers-outgoing; Mon, 23 Oct 1995 12:22:48 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19741 for ; Mon, 23 Oct 1995 12:22:43 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11316; Mon, 23 Oct 1995 11:07:39 -0700 From: Terry Lambert Message-Id: <199510231807.LAA11316@phaeton.artisoft.com> Subject: Re: NetBSD/FreeBSD (pthreads) To: leisner@sdsp.mc.xerox.com (Marty Leisner) Date: Mon, 23 Oct 1995 11:07:38 -0700 (MST) Cc: terry@lambert.org, cimaxp1!jb@werple.net.au, hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: <9510202115.AA19961@gnu.mc.xerox.com> from "Marty Leisner" at Oct 20, 95 02:15:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 386 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I personally would prefer good ways of solving problems without > threads...to throw threads at problems make debugging and > understanding much, much harder... I agree, but I don't think you could make a PC-Compatible dataflow machine. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 23 12:25:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19862 for hackers-outgoing; Mon, 23 Oct 1995 12:25:12 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19856 for ; Mon, 23 Oct 1995 12:25:08 -0700 Received: from exalt.x.org by expo.x.org id AA22523; Mon, 23 Oct 95 15:24:34 -0400 Received: from localhost by exalt.x.org id PAA01221; Mon, 23 Oct 1995 15:24:31 -0400 Message-Id: <199510231924.PAA01221@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: Netscape puzzle In-Reply-To: Your message of Mon, 23 Oct 1995 11:25:03 EST. <199510231825.LAA11356@phaeton.artisoft.com> Organization: X Consortium Date: Mon, 23 Oct 1995 15:24:30 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I had tried that and it didn't make any difference with the BSD 2.0b1, > > I still got an "unable to open display" error. :-( > > I suggest compiling a program that does a: > > main() > { > printf( "DISPLAY is '%s'\n", getenv("DISPLAY")); > } > > On a BSDI 2.0 system and running it on a FreeBSD box and seeing what > you get. Would that I had a BSD/OS 2.0 system to do that on. All I've got is a 1.1 CD-ROM. :-( > We already know there are differences in the way the environment > code works, and you are highly dependeint on that code. > > Have you tried it with an explicit "-display" argument instead of > relying on the environment? I've tried everything. Nothing works. -- Kaleb From owner-freebsd-hackers Mon Oct 23 12:33:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA20112 for hackers-outgoing; Mon, 23 Oct 1995 12:33:03 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA20107 ; Mon, 23 Oct 1995 12:33:00 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA02068; Mon, 23 Oct 1995 14:31:48 -0500 From: Joe Greco Message-Id: <199510231931.OAA02068@brasil.moneng.mei.com> Subject: Re: startslip isn't just broken - it's EVIL! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 23 Oct 1995 14:31:47 -0500 (CDT) Cc: hackers@freebsd.org, ache@freebsd.org In-Reply-To: <521.814475958@time.cdrom.com> from "Jordan K. Hubbard" at Oct 23, 95 12:19:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > I've seen some bogus software in my day, but this one really tears > it.. > > Not only does it have absolutely no concept of setting the VJ > compression flags, but it has no provisions for multiple setup > strings! Freefall doesn't deal with my TA correctly and whenever I > connect I don't get a login banner - I have to hit return first (this > is an oft-reported bit of FreeBSD braindamage - any plans to fix it > someday?). Unfortunately, startslip is too stupid to cope with the > idea of actually sending a return, much less a user defined string, if > it doesn't get the prompt it's expecting. It just waits around > forever. Bleah! Hmmm, never seen that. Are you using full hardware handshaking? > Then there's the little cuteness of having changed the flags > completely and utterly between 2.1 and current - any explanation for > that decision? > > I've added VJ compression support to sliplogin, but these other > problems I've been having with it in the wake of making those changes > (I can't even *test* them because the friggin' thing won't log in!!) > make me think that startslip doesn't need to be improved, it needs to > be re-written from scratch and I may just do that right now.. Yes, I never built up the ambition to fix it right. I kept patching it but my recent sets of patches never seemed to show up after the ones I submitted for 2.0R... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Mon Oct 23 12:40:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA20541 for hackers-outgoing; Mon, 23 Oct 1995 12:40:31 -0700 Received: from iaehv.IAEhv.nl (root@iaehv.IAEhv.nl [192.87.208.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA20522 for ; Mon, 23 Oct 1995 12:40:09 -0700 Received: by iaehv.IAEhv.nl (8.6.12/1.63) id UAA00149; Mon, 23 Oct 1995 20:38:47 +0100 From: guido@IAEhv.nl (Guido van Rooij) Message-Id: <199510231938.UAA00149@iaehv.IAEhv.nl> X-Disclaimer: iaehv.nl is a public access UNIX system and cannot be held responsible for the opinions of its individual users. Subject: fork: resource not available... To: freebsd-hackers@freebsd.org Date: Mon, 23 Oct 1995 20:38:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 639 Sender: owner-hackers@freebsd.org Precedence: bulk Can someone shed a light on this one?: Cron Daemon writes: >From daemon Mon Oct 23 18:00:37 1995 >Date: Mon, 23 Oct 1995 19:00:03 +0100 >Message-Id: <199510231800.TAA17944@iaehv.IAEhv.nl> >From: root@IAEhv.nl (Cron Daemon) >To: news >Subject: Cron nice /usr/lib/news/send-nntp news.tue.nl:news.tue.nl >X-Cron-Env: >X-Cron-Env: >X-Cron-Env: >X-Cron-Env: >X-Cron-Env: > >/usr/lib/news/send-nntp: fork: Resource temporarily unavailable >/usr/lib/news/send-nntp: fork: Resource temporarily unavailable From owner-freebsd-hackers Mon Oct 23 12:48:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA21480 for hackers-outgoing; Mon, 23 Oct 1995 12:48:17 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA21464 for ; Mon, 23 Oct 1995 12:48:10 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA19777; Mon, 23 Oct 1995 15:46:50 -0400 Date: Mon, 23 Oct 1995 15:46:50 -0400 (EDT) From: "Ron G. Minnich" To: freebsd-hackers@freebsd.org Subject: upgrade 2.05 to 2.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk just wondering: i have 16 boxes in a rack running 2.05R, which don't have keyboards, which will need to go to 2.1 soon i suppose (and hopefully 2.1 has fixed msync ...). Anyone have a reasonable upgrade hack to make this sort of thing easy. I did one script for 2.0 -> 2.05, basically via rdist, but there has to be a better way, right? maybe? thanks in advance. Ron Minnich |Like a knife through Daddy's heart: rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Mon Oct 23 12:49:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA21739 for hackers-outgoing; Mon, 23 Oct 1995 12:49:12 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA21716 for ; Mon, 23 Oct 1995 12:49:09 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00811; Mon, 23 Oct 1995 12:48:49 -0700 To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: hackers@freebsd.org Subject: Re: Grrr! Startslip ate my brain! In-reply-to: Your message of "Mon, 23 Oct 1995 21:10:28 +0300." Date: Mon, 23 Oct 1995 12:48:49 -0700 Message-ID: <809.814477729@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > It is easy, all headers compression was selected via startup scripts, > see examples/startslip/slup.sh for example. I was using the 2.1 version (I'm running a 2.1 tree, for obvious reasons :-) for which this wasn't present. I'll bring the 2.2 changes in for this and other reasons, but I'm still wondering how I'm going to get around the problem with the lack of a "chat" equivalent given freefall's propensity not to issue a login prompt at connection time.. As I mentioned to you in talk, I'm just going to finish my from-scratch re-write of this thing and try to add the features I feel are missing (most of them :-).. Jordan From owner-freebsd-hackers Mon Oct 23 12:51:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA22051 for hackers-outgoing; Mon, 23 Oct 1995 12:51:19 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA22043 for ; Mon, 23 Oct 1995 12:51:15 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA02168; Mon, 23 Oct 1995 14:49:54 -0500 From: Joe Greco Message-Id: <199510231949.OAA02168@brasil.moneng.mei.com> Subject: Re: fork: resource not available... To: guido@IAEhv.nl (Guido van Rooij) Date: Mon, 23 Oct 1995 14:49:53 -0500 (CDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510231938.UAA00149@iaehv.IAEhv.nl> from "Guido van Rooij" at Oct 23, 95 08:38:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Can someone shed a light on this one?: > > Cron Daemon writes: > > >From daemon Mon Oct 23 18:00:37 1995 > >Date: Mon, 23 Oct 1995 19:00:03 +0100 > >Message-Id: <199510231800.TAA17944@iaehv.IAEhv.nl> > >From: root@IAEhv.nl (Cron Daemon) > >To: news > >Subject: Cron nice /usr/lib/news/send-nntp news.tue.nl:news.tue.nl > >X-Cron-Env: > >X-Cron-Env: > >X-Cron-Env: > >X-Cron-Env: > >X-Cron-Env: > > > >/usr/lib/news/send-nntp: fork: Resource temporarily unavailable > >/usr/lib/news/send-nntp: fork: Resource temporarily unavailable You're at your process limit. Type "limit" at a csh prompt to find your default limit. Probably 40. Entirely too small for a busy news server. I generally build news kernels sorta big: maxusers 128 options "CHILD_MAX=256" options "OPEN_MAX=256" #options "NMBCLUSTERS=512" etc. but sometimes you gotta up those numbers. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Mon Oct 23 13:09:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA22900 for hackers-outgoing; Mon, 23 Oct 1995 13:09:51 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA22893 for ; Mon, 23 Oct 1995 13:09:48 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11375; Mon, 23 Oct 1995 11:28:40 -0700 From: Terry Lambert Message-Id: <199510231828.LAA11375@phaeton.artisoft.com> Subject: Re: Netscape puzzle To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 23 Oct 1995 11:28:39 -0700 (MST) Cc: kaleb@x.org, hackers@freefall.freebsd.org In-Reply-To: <199510202122.PAA15970@rocky.sri.MT.net> from "Nate Williams" at Oct 20, 95 03:22:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1076 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > >From work, if I rsh to my box and run netscape 2.0b1 with the display set > > to a machine here at work, I get an "unable to open display" error. With > > netscape 1.1 it runs for several seconds and then takes the PPP connection > > down. This has occured each and every time I've tried it. > > Why it's taking your connection out, I don't know but I've found that > the Netscape versions >= 1.1 I've run on both SunOS and FreeBSD require > me using the IP address instead of the hostname if I want to use remote > hosts. The Slowlaris versions doesn't for some reason, but I found it > interesting none the less. Another potential datapoint: We are all aware of the bind/sendmail static data initialization shared library changes, right? The ones that Matt Day reported and provided patches for in both Linux and BSD and to the package authors? Perhaps this is the same bug, where the resolver is incorrectly initialized. 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 Oct 23 13:23:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA23652 for hackers-outgoing; Mon, 23 Oct 1995 13:23:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA23647 for ; Mon, 23 Oct 1995 13:23:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11604; Mon, 23 Oct 1995 13:15:17 -0700 From: Terry Lambert Message-Id: <199510232015.NAA11604@phaeton.artisoft.com> Subject: Re: Bragging rights.. To: dennis@etinc.com (dennis) Date: Mon, 23 Oct 1995 13:15:16 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510221638.MAA07304@etinc.com> from "dennis" at Oct 22, 95 12:38:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 516 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I really can't believe you guys are bragging about the widespread > utilization of > souped-up async. You still don't get the fact that you're losing several > hundred dollars > worth of machine (which brings the cost in-line with sync) to save a few > hundred on > cards for a less-efficient solution. I don't own any IDE drives -- do you? It's an interesting parallel. 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 Oct 23 13:24:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA23759 for hackers-outgoing; Mon, 23 Oct 1995 13:24:41 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA23750 ; Mon, 23 Oct 1995 13:24:35 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11615; Mon, 23 Oct 1995 13:17:05 -0700 From: Terry Lambert Message-Id: <199510232017.NAA11615@phaeton.artisoft.com> Subject: Re: Bragging rights.. To: jkh@FreeBSD.ORG (Jordan K. Hubbard) Date: Mon, 23 Oct 1995 13:17:05 -0700 (MST) Cc: dennis@etinc.com, hackers@FreeBSD.ORG In-Reply-To: <308A79E5.64A99F5A@FreeBSD.org> from "Jordan K. Hubbard" at Oct 22, 95 10:05:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 328 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk [ ... ] Jordan, you're average line length is ~94 characters. Did you load a proportional font into your xterm or something? It makes it nearly impossible to read without reformatting. 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 Oct 23 13:32:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA24456 for hackers-outgoing; Mon, 23 Oct 1995 13:32:44 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA24448 for ; Mon, 23 Oct 1995 13:32:35 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id QAA10935; Mon, 23 Oct 1995 16:49:08 -0400 Date: Mon, 23 Oct 1995 16:49:08 -0400 Message-Id: <199510232049.QAA10935@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> I really can't believe you guys are bragging about the widespread >> utilization of >> souped-up async. You still don't get the fact that you're losing several >> hundred dollars >> worth of machine (which brings the cost in-line with sync) to save a few >> hundred on >> cards for a less-efficient solution. > >I don't own any IDE drives -- do you? It's an interesting parallel. > Routers don't use disks during operation, so why spend money on SCSI? Its hardly a parallel, since theres no gain in spending the money. On the other hand, you pay extra for speed because you think its worth it...which is exactly what I said about sync. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Mon Oct 23 13:34:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA24742 for hackers-outgoing; Mon, 23 Oct 1995 13:34:40 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA24734 for ; Mon, 23 Oct 1995 13:34:36 -0700 From: mikebo@tellabs.com Received: from sunc26.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7TMq-000jCKC; Mon, 23 Oct 95 15:21 CDT Received: by sunc26.tellabs.com (4.1/1.9) id AA03529; Mon, 23 Oct 95 15:21:06 CDT Message-Id: <9510232021.AA03529@sunc26.tellabs.com> Subject: FBSD 2.0.5 951020 SNAP Install comments To: jkh@time.cdrom.com Date: Mon, 23 Oct 1995 15:21:06 -0500 (CDT) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 807 Sender: owner-hackers@freebsd.org Precedence: bulk My only problems with the install so far: 64-character limit to specify NFS mount point - too short for my shop! 138.111.84.254:/export/home/tellabk-4/mikebo/FreeBSD/2.1.0-951020-SNAP ^ truncated This is undoubtedly not a problem for most people, but it bit me. I got around it my moving my stuff up one level, but 64-char seems kinda arbitrary to me. (?) - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Mon Oct 23 13:49:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26269 for hackers-outgoing; Mon, 23 Oct 1995 13:49:23 -0700 Received: from uswat.advtech.uswest.com (firewall-user@uswat.advtech.uswest.com [130.13.16.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA26258 for ; Mon, 23 Oct 1995 13:49:15 -0700 Received: from mailhub.advtech.uswest.com (mh16.advtech.uswest.com [130.13.16.7]) by uswat.advtech.uswest.com (8.7/8.6.12) with ESMTP id OAA29050 for ; Mon, 23 Oct 1995 14:49:12 -0600 (MDT) Received: from advtech.uswest.com (durian@angeleys.advtech.uswest.com [130.13.8.92]) by mailhub.advtech.uswest.com (8.7/8.7) with ESMTP id OAA12447 for ; Mon, 23 Oct 1995 14:49:11 -0600 (MDT) Message-Id: <199510232049.OAA12447@mailhub.advtech.uswest.com> From: "Mike Durian" To: hackers@freebsd.org Subject: Device major number request Date: Mon, 23 Oct 1995 14:49:09 -0600 Sender: owner-hackers@freebsd.org Precedence: bulk Could you please assign me a character device major number? I'm porting the tclmidi driver to FreeBSD and would like to avoid conflicts. mike From owner-freebsd-hackers Mon Oct 23 13:54:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA26787 for hackers-outgoing; Mon, 23 Oct 1995 13:54:28 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA26776 ; Mon, 23 Oct 1995 13:54:21 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11677; Mon, 23 Oct 1995 13:46:49 -0700 From: Terry Lambert Message-Id: <199510232046.NAA11677@phaeton.artisoft.com> Subject: Re: Bragging rights.. To: jkh@FreeBSD.ORG (Jordan K. Hubbard) Date: Mon, 23 Oct 1995 13:46:49 -0700 (MST) Cc: dennis@etinc.com, hackers@FreeBSD.ORG In-Reply-To: <308A8B4E.6F9AB114@FreeBSD.org> from "Jordan K. Hubbard" at Oct 22, 95 11:19:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4232 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > dennis wrote: > > on their switches. If you > > think its the next "great upgrade" you're badly mistaken. > > Why? I don't see where the regional bell's *motivation* is at all > the issue. You're right that their motivation isn't an issue in deployment. But it is in their tarrif structure. I think the investment in 5ESS or better switching technology isn't as pronounced as Dennis would have use believe, or I'd have ISDN and Centrex/Centron services available at my home (I don't; there is a single 5ESS in Tucson, AZ, and much more than that worth of phone lines -- I'm on one of the "alternate" exchanges). > I understand that you're pretty biased against ISDN in favor of your > own Frame Relay solutions, but let's not go trying to adjust reality > to fit the picture you'd like it to be! If people buy ISDN, it will > be a success. So far, people are buying ISDN and all the technical > criticism in the world you may have won't change that fact one iota. The RBOC motivation *is* a factor in this argument. Specifically, the RBOC's are pushing ISDN because they can meter it, even though new equipment costs are much higher (the biggest chunk of what you pay for ISDN is the fact that you are tying up a switch for more than the expected average amount of time, and you are only doing that because of circuit switching). A packet switched network can't be metered based on content destination. The major cost in ISDN, BTW, is the software the RBOC's buy from AT&T. Note that if you live in a US West service area and happen to luck out and live near a 5ESS or better switch and US West happens to license AT&T's software for the thing, you still don't get real ISDN: You get 64/16/16 instead of 64/64/16... unsuitable for most videoconferencing or for 128k bonded rates. US West calls the real ISDN "National ISDN". Check their web page for when it will (not) be available in your area. The problem with Frame Relay is the same problem with ISDN: Inter-LATA routing. Note that for an ISP, the costs of a T1 to a FR cloud are a hell of a lot cheaper than 64 ISDN lines, so your overall cost is going to be reduced by half of the circuit. > I think we're arguing at cross purposes. I'm talking about what > the end-user wants and you're telling me what they SHOULD want and, > in Dennis's ideal world, would want. Sorry, but you clearly > haven't been a user in nearly long enough to have informed > opinions about that anymore - you have a high speed sync serial > "hammer" and now you insist that everything looks like a nail. Well, I'm an end user, and I *don't* want ISDN. I want flat rate Frame Relay, and I'm willing to pay up to 1/4 of what I pay a month to keep a roof over my head. Only no one will sell it to me. I think *you're* talking about what the end user can reasonably expect to be able to purchase from the local RBOC, not what they want. Like Henery Ford, who'd sell you any color of car, as long as it was black. I know 20 other engineers who want it too (they happen to work for the same company)... and that's just my immediate acquantances. And we are hardly the only computer/technology company in the area. We are going to have 1200-2000 Microsoft support people in the area in the next 4 years (200+ this year, then more each year). At Novell, there are at least 60 people I know who wanted it even before I left there. The reason I'm in Arizona instead of Utah is the lack of decent video conference capabilities made a move a job requirement. Now Dennis does have a problem with his market: No one (RBOC) wants to sell wires to go between his cards. But what an end user wants and what all of the parties involved agree to sell are two very different things. When the time comes, I'm going TCI (or Jones InterCable or whatever); basically whoever offers the service first is getting my business, and if it isn't US West (or your favorite RBOC), fine, then screw them. If there's a configuration where I can use one of Dennis' cards, then fine, I'll use it. Otherwise I use whatever I have to. Can you two cut it out? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Oct 23 13:58:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA27131 for hackers-outgoing; Mon, 23 Oct 1995 13:58:45 -0700 Received: from fgate.flevel.co.uk (fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA27101 for ; Mon, 23 Oct 1995 13:58:25 -0700 Received: (from freebsd@localhost) by fgate.flevel.co.uk (8.6.11/8.6.9) id WAA00236; Mon, 23 Oct 1995 22:00:53 +0100 Date: Mon, 23 Oct 1995 22:00:51 +0100 (BST) From: freebsd To: hackers@freebsd.org cc: david@flevel.co.uk Subject: HELP URGENT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi Please Cc: david@flevel.co.uk We have a freebsd bootable hard disk that now refuses to boot. It hangs immediately after attaching bpf Are there any testing tools we can use? Config DX100 16M Adaptec 2940 Any ideas gratefully received david S. From owner-freebsd-hackers Mon Oct 23 14:00:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA27300 for hackers-outgoing; Mon, 23 Oct 1995 14:00:22 -0700 Received: from metal.ops.neosoft.com (root@metal-pluto.ops.NeoSoft.COM [198.65.163.227]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27271 ; Mon, 23 Oct 1995 14:00:05 -0700 Received: (from smace@localhost) by metal.ops.neosoft.com (8.7.1/8.7.1) id PAA05188; Mon, 23 Oct 1995 15:59:39 -0500 (CDT) From: Scott Mace Message-Id: <199510232059.PAA05188@metal.ops.neosoft.com> Subject: SHOW STOPPER for 2.1 To: hackers@freebsd.org, stable@freebsd.org Date: Mon, 23 Oct 1995 15:59:39 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk There's a big problem with the "DES" package on 1020 SNAP the libtelnet.so.2.0 library has dependencies for libdes.so.2.0 and libkrb.so.2.0 (the 2 kerberos IV libraries). Its something weird in the release generation, because I used a libtelnet created from my 2.1-stable source tree and it fixed the problem. Scott From owner-freebsd-hackers Mon Oct 23 14:03:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA27618 for hackers-outgoing; Mon, 23 Oct 1995 14:03:53 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27608 for ; Mon, 23 Oct 1995 14:03:47 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11710; Mon, 23 Oct 1995 13:55:47 -0700 From: Terry Lambert Message-Id: <199510232055.NAA11710@phaeton.artisoft.com> Subject: Re: What is the best way... To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 23 Oct 1995 13:55:47 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510221818.TAA03456@uriah.heep.sax.de> from "J Wunsch" at Oct 22, 95 07:18:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 675 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > The closest thing one could do (besides from the approach e.g. > pcaudio is using, which i consider being overkill as a poll() > replacement) were to continuously re-issue yet another timeout on each > clock tick. However, since that would cause timeout() to walk the > entire timer queue, it's rather expensive. So use a hash and do ordered inserts into the timer queue using one-behind delta's and timer markers for canceled timeouts so they don't throw off the timeouts that follow them. Then the walk list is very abbreviated. 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 Oct 23 14:13:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28420 for hackers-outgoing; Mon, 23 Oct 1995 14:13:43 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28405 for ; Mon, 23 Oct 1995 14:13:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11752; Mon, 23 Oct 1995 14:05:20 -0700 From: Terry Lambert Message-Id: <199510232105.OAA11752@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c To: syssgm@devetir.qld.gov.au (Stephen McKay) Date: Mon, 23 Oct 1995 14:05:20 -0700 (MST) Cc: swallace@ece.uci.edu, freebsd-hackers@FreeBSD.ORG, syssgm@devetir.qld.gov.au In-Reply-To: <199510230953.TAA22795@orion.devetir.qld.gov.au> from "Stephen McKay" at Oct 23, 95 07:53:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 784 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >We need a better way to handle these syscall subcodes (as SYSV calls 'em). > > Is it not true that this System V stuff can be written as library routines > that use BSD facilities such as mmap() and sockets? I would be happy to see > the effort expended this way so that I can keep my kernel free of such cruft. This assumes: 1) The SYSV code uses shared libraries 2) Someone (you?) has written library replacements so that real SYSV shared libraries need not be used 3) No one is interested in running statically linked IBCS2 binaries, only dynamically linked ones. At present, I believe all of these are, in part or in whole, wrong. 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 Oct 23 14:21:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29001 for hackers-outgoing; Mon, 23 Oct 1995 14:21:23 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28995 for ; Mon, 23 Oct 1995 14:21:18 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11769; Mon, 23 Oct 1995 14:13:19 -0700 From: Terry Lambert Message-Id: <199510232113.OAA11769@phaeton.artisoft.com> Subject: Re: Netscape puzzle To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 23 Oct 1995 14:13:19 -0700 (MST) Cc: terry@lambert.org, nate@rocky.sri.MT.net, kaleb@x.org, hackers@freefall.freebsd.org In-Reply-To: <199510231841.MAA22178@rocky.sri.MT.net> from "Nate Williams" at Oct 23, 95 12:41:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1090 Sender: owner-hackers@FreeBSD.org Precedence: bulk > Terry Lambert writes: > [ Netscape not working ] > > Another potential datapoint: > > > > We are all aware of the bind/sendmail static data initialization shared > > library changes, right? > > Refreh my memory. They changed the initializations to something that would allow copy on write shared library data to be used as well. Basically, it's getting rid of local data for crappy shared library implementations. If you mixed old and new implementations (check the bind release notes), then the behaviour became undefined, even if you recompiled everything. One (hack) fix is to call the initialization before it's strictly allowed. > > The ones that Matt Day reported and provided patches for in both Linux > > and BSD and to the package authors? > > I don't remember seeing it. Was in on the ports mailing list? No. It was on hackers and it was sent to one or more NetBSD and Linux lists, as well as being mailed to Allman & company. 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 Oct 23 14:27:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29444 for hackers-outgoing; Mon, 23 Oct 1995 14:27:27 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29438 for ; Mon, 23 Oct 1995 14:27:23 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11802; Mon, 23 Oct 1995 14:19:32 -0700 From: Terry Lambert Message-Id: <199510232119.OAA11802@phaeton.artisoft.com> Subject: Re: Netscape puzzle To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Mon, 23 Oct 1995 14:19:32 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.FreeBSD.org In-Reply-To: <199510231924.PAA01221@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 23, 95 03:24:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 763 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > We already know there are differences in the way the environment > > code works, and you are highly dependeint on that code. > > > > Have you tried it with an explicit "-display" argument instead of > > relying on the environment? > > I've tried everything. Nothing works. Try the old bind code. It's possible the BSDI didn't update. Or try the new code. It's possible they did. Note that your sendmail and bind versions *must* be matched by release date, opr sendmail will dump stuff in the spool and you'll get a big delay until the next time it runs and flushes the stuff out. First tries will always fail... 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 Oct 23 15:00:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA00820 for hackers-outgoing; Mon, 23 Oct 1995 15:00:18 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA00794 for ; Mon, 23 Oct 1995 14:59:57 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id WAA08413; Mon, 23 Oct 1995 22:59:42 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199510232159.WAA08413@gvr.win.tue.nl> Subject: clk interrupts > 150/sec??? To: freebsd-hackers@freebsd.org Date: Mon, 23 Oct 1995 22:59:41 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 335 Sender: owner-hackers@freebsd.org Precedence: bulk How can this be explained: [~] guido@iaehv> vmstat -i interrupt total rate clk0 irq0 3884051 156 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rtc0 irq8 3173264 128 fdc0 irq6 1 0 sc0 irq1 2462 0 ed0 irq5 3667585 147 I always thought clk0 should have a rate of 100/sec. -Guido From owner-freebsd-hackers Mon Oct 23 15:04:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01241 for hackers-outgoing; Mon, 23 Oct 1995 15:04:11 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA00958 for ; Mon, 23 Oct 1995 15:02:07 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id SAA11231; Mon, 23 Oct 1995 18:19:20 -0400 Date: Mon, 23 Oct 1995 18:19:20 -0400 Message-Id: <199510232219.SAA11231@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: dennis@etinc.com (dennis) Subject: Re: Bragging rights.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> dennis wrote: >> > on their switches. If you >> > think its the next "great upgrade" you're badly mistaken. >> >> Why? I don't see where the regional bell's *motivation* is at all >> the issue. > >You're right that their motivation isn't an issue in deployment. >But it is in their tarrif structure. > >I think the investment in 5ESS or better switching technology >isn't as pronounced as Dennis would have use believe, or I'd have >ISDN and Centrex/Centron services available at my home (I don't; >there is a single 5ESS in Tucson, AZ, and much more than that >worth of phone lines -- I'm on one of the "alternate" exchanges). The 5ESS's themselves aren't a sufficient condition for ISDN. They have to re-tool them (software, line cards, etc) and they have to have a network management scheme in place. We don't have it in NY either (you can get it....but its a nightmare) and we've been digital forever here. Its basically a multi-million dollar decision to go ahead with it, and when they do they're in it big. They can't just dabble in it without losing big bucks. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Mon Oct 23 15:08:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01685 for hackers-outgoing; Mon, 23 Oct 1995 15:08:22 -0700 Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01675 for ; Mon, 23 Oct 1995 15:08:13 -0700 Received: (from vince@localhost) by apollo.COSC.GOV (8.6.12/8.6.9) id PAA07427; Mon, 23 Oct 1995 15:06:07 -0700 Date: Mon, 23 Oct 1995 15:06:07 -0700 (PDT) From: -Vince- To: Stefan Esser cc: hackers@freebsd.org Subject: Re: machine reboot & kernel maxusers option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 7 Oct 1995, Stefan Esser wrote: > On Oct 7, 4:45, -Vince- wrote: > } Subject: machine reboot & kernel maxusers option > } > } I am experiencing the following problem and the machine just > } reboots under FreeBSD-current, anyone have any ideas? > > There have been no functional changes to the driver > for nearly a month now ... > > Did you rebuild your kernel within that time ? yes I did... > } MAND FAILED (4 28) @f0b4aa00. > } assertion "cp" failed: file "../../pci/ncr.c", line 5560 > } sd0(ncr0:0:0): COMMAND FAILED (4 28) @f0b4aa00. > > Hmm, the 28 in the message above means "Queue Full", i.e. > there were too many commands issued by the generic SCSI > driver. But the maximum number of commands to issue is a > parameter known to the generic SCSI code, so this should > never happen ... Hmmm, is there anyway around this? > In fact, there was a change one month ago, which did change > the size of the command queue. But in fact, the queue size > was increased ... Hmm, okay... > You may want to try changing back the line (ncr.c:132): > > #define MAX_START (MAX_TARGET + 7 * SCSI_NCR_MAX_TAGS) > > into its previous form: > > #define MAX_START (7 * SCSI_NCR_MAX_TAGS) Okay, I'll give that a try... > I'll look into this, but I need more information: Thanks in advance! > 1) Complete verbose boot message log, if possible > (I.e. Boot with "-v" option, send "/sbin/dmesg" output). Here you go: FreeBSD 2.2-CURRENT #0: Fri Sep 29 01:43:02 PDT 1995 vince@apollo.COSC.GOV:/usr/src/sys/compile/GALAXY CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 25165824 (24576K bytes) avail memory = 20131840 (19660K bytes) BIOS Geometries: 0:03f7793f 0..1015=1016 cyl, 0..121=122 heads, 1..63=63 sects 0 accounted for Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x260-0x27f irq 5 on isa ed0: address 00:40:05:16:77:85, type NE2000 (16 bit) ed1 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 not found at 0x3e8 sio3 not found at 0x2e8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 not found at 0xffffffff lpt2 not found at 0xffffffff pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc1 not found at 0x170 bt0 not found at 0x330 uha0 not found at 0x330 ahc1 not found ahb0 not found aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found wt0 not found at 0x300 mcd0: timeout getting status mcd0 not found at 0x300 mcd1: timeout getting status mcd1 not found at 0x340 matcdc0 not found at 0xffffffff scd0 not found at 0x230 ie0 not found at 0x360 ep0 not found at 0x300 ix0 not found at 0x300 le0: no board found at 0x300 le0 not found at 0x300 lnc0 not found at 0x280 lnc1 not found at 0x300 ze0 not found at 0x300 zp0 not found at 0x300 npx0 on motherboard npx0: INT 16 interface gus0 at 0x220 irq 11 drq 1 on isa gus0: pcibus_setup(1): mode1res=0x80000000 (0x80000000), mode2res=0xff (0x0e) pcibus_setup(2): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there Probing for devices on the PCI bus: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 2 on pci0:7 ncr0 rev 2 int a irq 10 on pci0:11 mapreg[10] type=1 addr=0000e400 size=0100. mapreg[14] type=0 addr=fbfef000 size=0100. reg20: virtual=0xf3ca2000 physical=0xfbfef000 size=0x100 ncr0: restart (scsi reset). ncr0 scanning for targets 0..6 (V2 pl23 95/09/07) ncr0 waiting for scsi devices to settle (ncr0:0:0): "DEC DSP5400S 427L" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 3814MB (7812870 512 byte sectors) sd0(ncr0:0:0): with 3055 cyls, 26 heads, and an average 98 sectors/track vga0 rev 0 on pci0:12 mapreg[10] type=0 addr=fb000000 size=800000. pci0: uses 8388864 bytes of memory from fb000000 upto fbfef0ff. pci0: uses 256 bytes of I/O space from e400 upto e4ff. changing root device to sd0a sd0s1: type 0x6, start 63, end = 1106783, size 1106721 : OK sd0s2: type 0xa5, start 1106784, end = 7808975, size 6702192 : OK > 2) When does this happen ? > At boot time, or when the system had been heavily loaded ? Only when the system has lots of sendmail processes... > Which devices are connected ? active ? Just the 4.0 GIG Sequel Hard Drive... > There is a timeout function in the driver, which should > reset the NCR chip after some 10 seconds of no progress > on any outstanding command. > > This ought to clear the error condition ... Hmmm, how do I do that exactly? > } Also, can someone tell me what the maxusers option in the kernel > } config file does exactly? > > Look for uses of MAXUSERS in "/sys/conf/param.c". I did but didn't know what it's used for exactly... Cheers, -Vince- vince@apollo.COSC.GOV - GUS Mailing Lists Admin UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center - Board of Advisors Running FreeBSD - Real UN*X for Free! Linda Wong/Vivian Chow/Hacken Lee/Danny Chan Fan Club Mailiing Lists Admin From owner-freebsd-hackers Mon Oct 23 15:09:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA01783 for hackers-outgoing; Mon, 23 Oct 1995 15:09:16 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA01761 for ; Mon, 23 Oct 1995 15:09:04 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA23005; Mon, 23 Oct 1995 16:10:56 -0600 Date: Mon, 23 Oct 1995 16:10:56 -0600 From: Nate Williams Message-Id: <199510232210.QAA23005@rocky.sri.MT.net> To: Terry Lambert Cc: syssgm@devetir.qld.gov.au (Stephen McKay), swallace@ece.uci.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c In-Reply-To: <199510232105.OAA11752@phaeton.artisoft.com> References: <199510230953.TAA22795@orion.devetir.qld.gov.au> <199510232105.OAA11752@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > We need a better way to handle these syscall subcodes (as SYSV > > > calls 'em). > > > > Is it not true that this System V stuff can be written as library > > routines that use BSD facilities such as mmap() and sockets? I > > would be happy to see the effort expended this way so that I can > > keep my kernel free of such cruft. > > This assumes: > > 1) The SYSV code uses shared libraries > 2) Someone (you?) has written library replacements so that > real SYSV shared libraries need not be used > 3) No one is interested in running statically linked IBCS2 > binaries, only dynamically linked ones. I think Stephen is implying that instead of adding the code to do the syscalls inside the kernel, you could somehow 'call' a library routine which is external to the kernel. If you could do such a thing, then none of the above are applicable. But, I believe the current 'macro-kernel' system used in BSD precludes us doing such things. Nate From owner-freebsd-hackers Mon Oct 23 15:14:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02067 for hackers-outgoing; Mon, 23 Oct 1995 15:14:38 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA02057 for ; Mon, 23 Oct 1995 15:14:26 -0700 Received: by sequent.kiae.su id AA12364 (5.65.kiae-2 ); Tue, 24 Oct 1995 02:10:30 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 02:10:30 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id AAA04813; Tue, 24 Oct 1995 00:52:32 +0300 To: "Jordan K. Hubbard" Cc: hackers@freebsd.org References: <809.814477729@time.cdrom.com> In-Reply-To: <809.814477729@time.cdrom.com>; from "Jordan K. Hubbard" at Mon, 23 Oct 1995 12:48:49 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 00:52:32 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Grrr! Startslip ate my brain! Lines: 15 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 688 Sender: owner-hackers@freebsd.org Precedence: bulk In message <809.814477729@time.cdrom.com> Jordan K. Hubbard writes: >As I mentioned to you in talk, I'm just going to finish my >from-scratch re-write of this thing and try to add the features I feel >are missing (most of them :-).. Please, mail me your planned changes first, modifiying startslip I know it from memory, it will help us to deal with possible side effects and similar things. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 15:18:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02291 for hackers-outgoing; Mon, 23 Oct 1995 15:18:18 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA02274 for ; Mon, 23 Oct 1995 15:17:41 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA23085; Mon, 23 Oct 1995 16:19:32 -0600 Date: Mon, 23 Oct 1995 16:19:32 -0600 From: Nate Williams Message-Id: <199510232219.QAA23085@rocky.sri.MT.net> To: hackers@FreeBSD.org Subject: LPPng: New BSD LPR SW (forwarded message from Patrick Powell) Sender: owner-hackers@FreeBSD.org Precedence: bulk ------- start of forwarded message (RFC 934 encapsulation) ------- Received: from sneezy.sri.com (sneezy.sri.com [128.18.40.6]) by rocky.sri.MT.net (8.6.12/8.6.12) with SMTP id OAA22727 for ; Mon, 23 Oct 1995 14:51:52 -0600 Received: from enterprise.interpath.net by sneezy.sri.com (4.1/SMI-4.1) id AA17744; Mon, 23 Oct 95 13:35:16 PDT Received: (from majordom@localhost) by enterprise.interpath.net (8.6.12/8.6.9) id OAA04340 for bsdi-users-outgoing; Mon, 23 Oct 1995 14:50:46 -0400 Message-Id: <199510231850.LAA06159@dickory.sdsu.edu> Precedence: bulk From: Patrick Powell Sender: owner-bsdi-users@BSDI.COM To: bsdi-users@Interpath.net Subject: LPRng - Enhanced Printer Spooling Software Date: Mon, 23 Oct 1995 11:50:21 -0700 In response to several requests, here is the (long delayed) LPRng announcement. LPRng - An Enhanced Printer Spooler (Beta Release) Patrick Powell ABSTRACT The LPRng software is an enhanced, extended, and portable version of the Berkeley LPR software. While providing the same general functionality, the imple- mentation is completely new and provides support for the following features: lightweight (no databases needed) lpr, lpc, and lprm programs; dynamic redirec- tion of print queues; automatic job holding; highly verbose diagnostics; multiple printers serving a sin- gle queue; client programs do not need to run SUID root; greatly enhanced security checks; and a greatly improved permission and authorization mechanism. The source software compiles and runs on a wide variety of UNIX systems, and is compatible with most PC and MAC based print spoolers that use the LPR network interface. The package comes with filters for PostScript and HP printers, as well as the usual 'dumb' printers. Note that the filters supplied for the HP printers do accounting, and were developed to be used in an Educational Environment, where avoiding accounting procedures is quite prevalent. The software may be obtained from ftp://dickory.sdsu.edu/pub/LPRng/ (US) ftp://iona.ie/pub/plp/LPRng (Europe) To join the LPRng/PLP mailing list, please send mail to plp-request@iona.ie with the word 'subscribe' in the BODY Patrick Powell ------- end ------- From owner-freebsd-hackers Mon Oct 23 15:42:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03216 for hackers-outgoing; Mon, 23 Oct 1995 15:42:34 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA03211 for ; Mon, 23 Oct 1995 15:42:26 -0700 Received: by sequent.kiae.su id AA17295 (5.65.kiae-2 ); Tue, 24 Oct 1995 02:40:13 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 02:40:13 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id BAA05102; Tue, 24 Oct 1995 01:39:38 +0300 To: ache@freefall.freebsd.org, John Polstra Cc: freebsd-hackers@freebsd.org References: In-Reply-To: ; from John Polstra at Mon, 23 Oct 95 12:09 PDT Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 01:39:38 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 921 Sender: owner-hackers@freebsd.org Precedence: bulk In message John Polstra writes: >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid >programs? If not, I think that the recent change should be removed from >rtld.c. In this case I keep in mind some shell script execution which calls setuid programs. By setiing LD_NOSTD_PATH user allows such programs easily fails, it is clear. Here can be very unpleasant side effect that usually shell scripts not expects setuid programs failing for such reasons and have lack of error traping at this point. It can leads to unpredictable things in shell script execution flow. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 16:04:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA04387 for hackers-outgoing; Mon, 23 Oct 1995 16:04:56 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA04377 for ; Mon, 23 Oct 1995 16:04:50 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id RAA19317; Mon, 23 Oct 1995 17:03:11 -0600 Message-Id: <199510232303.RAA19317@rover.village.org> To: Terry Lambert Subject: Re: Netscape puzzle Cc: kaleb@x.org (Kaleb S. KEITHLEY), hackers@freefall.freebsd.org In-reply-to: Your message of Mon, 23 Oct 1995 14:19:32 PDT Date: Mon, 23 Oct 1995 17:03:10 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.org Precedence: bulk : Try the old bind code. It's possible the BSDI didn't update. : : Or try the new code. It's possible they did. I know that the Linux people just produced a patch for this. However, somehow I got unsubscribed from their mailing lists and didn't realize it until just now. Basically the problem is in the bind code. There is a select that waits until it times out before assuming there has been a timeout. However, netscape has effectively an itimer that prevents the select from ever timing out, so the code winds up looping infinitely, or some such grief. I wish I had the patch, I'd send it along. Oh, they claim that if your run the name server on your machine, and the host is cached in your name server, the problem goes away. Sorry I didn't speak up sooner... Warner From owner-freebsd-hackers Mon Oct 23 16:08:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA04654 for hackers-outgoing; Mon, 23 Oct 1995 16:08:04 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA04649 for ; Mon, 23 Oct 1995 16:08:00 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id QAA19117; Mon, 23 Oct 1995 16:57:42 -0600 Message-Id: <199510232257.QAA19117@rover.village.org> To: peter@haywire.dialix.com (Peter Wemm) Subject: Re: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of 24 Oct 1995 02:14:48 +0800 Date: Mon, 23 Oct 1995 16:57:41 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.ORG Precedence: bulk : FreeBSD has fixed the hole, IMHO better than the others, but it used : one of the advanced 4.4BSD stdio features to do it more securely : (fwopen()/vfprintf() instead of umpteen strlen()/snprintf()). : : They covered FreeBSD/NetBSD (not by name) by saying: there are : different patches available for other operating systems, but these : have not been evaluated by cert, blah, blah. Both Free/NetBSD did it : their own way. Does somebody have just this patch? I must have missed it as it went by. I know that it is in current, but I need to patch a 1.1.5.1R router.... Warner From owner-freebsd-hackers Mon Oct 23 16:16:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05410 for hackers-outgoing; Mon, 23 Oct 1995 16:16:37 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05400 for ; Mon, 23 Oct 1995 16:16:21 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA24039; Mon, 23 Oct 1995 17:18:23 -0600 Date: Mon, 23 Oct 1995 17:18:23 -0600 From: Nate Williams Message-Id: <199510232318.RAA24039@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: ache@freefall.freebsd.org, John Polstra , freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: Sender: owner-hackers@freebsd.org Precedence: bulk > >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid > >programs? If not, I think that the recent change should be removed from > >rtld.c. > > In this case I keep in mind some shell script execution which calls > setuid programs. By setiing LD_NOSTD_PATH user allows such > programs easily fails, it is clear. Why should a program which calls setuid programs fail in the first place? If they are calling a setuid program it will still only look in the 'normal' places for shlibs, which means they are safe. > Here can be very unpleasant > side effect that usually shell scripts not expects setuid > programs failing for such reasons and have lack of error traping > at this point. Can you give a more concrete example of where this is a 'bad thing'? I can't even imagine one, even with this explanation. Nate From owner-freebsd-hackers Mon Oct 23 16:16:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05450 for hackers-outgoing; Mon, 23 Oct 1995 16:16:56 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA05444 for ; Mon, 23 Oct 1995 16:16:53 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA12051 (5.65c8/HUTCS-S 1.4 for ); Tue, 24 Oct 1995 01:16:48 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id BAA17630; Tue, 24 Oct 1995 01:16:59 +0200 Date: Tue, 24 Oct 1995 01:16:59 +0200 Message-Id: <199510232316.BAA17630@shadows.cs.hut.fi> From: Heikki Suonsivu To: "Ron G. Minnich" Cc: freebsd-hackers@freebsd.org In-Reply-To: "Ron G. Minnich"'s message of 23 Oct 1995 21:56:19 +0200 Subject: upgrade 2.05 to 2.1 Sender: owner-hackers@freebsd.org Precedence: bulk keyboards, which will need to go to 2.1 soon i suppose (and hopefully 2.1 has fixed msync ...). Anyone have a reasonable upgrade hack to make this sort of thing easy. I did one script for 2.0 -> 2.05, basically via rdist, but there has to be a better way, right? maybe? I do this to upgrade my machines, though I do upgrades in smaller steps by supping the sources frequently: - do full make world in one machine and create a new kernel, - test it runs fine, - mount the src/obj trees to all other machines to be upgraded - do a make reinstall (patch follows) - switch the kernel - reboot installed machine reinstall rule just reinstalls everything. I have been running these simultaneously. I even have reinstalled a 386-16 machine from on nfs mount over a 38.4k PPP link, within 24 hours. I really missed IP-level compression :-) *** Makefile.orig Fri Aug 4 17:58:32 1995 --- Makefile Thu Aug 24 21:55:08 1995 *************** *** 8,13 **** --- 8,14 ---- # -DMAKE_EBONES to build eBones (KerberosIV) # # -DNOCLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir + # -DNOCLEAN do not clean at all # -DNOCRYPT will prevent building of crypt versions # -DNOLKM do not build loadable kernel modules # -DNOOBJDIR do not run ``${MAKE} obj'' *************** *** 86,103 **** .else OBJDIR= obj .endif .if defined(NOCLEANDIR) CLEANDIR= clean .else CLEANDIR= cleandir .endif ! world: hierarchy mk cleandist includes lib-tools libraries tools @echo "--------------------------------------------------------------" @echo " Rebuilding ${DESTDIR} The whole thing" @echo "--------------------------------------------------------------" @echo ${MAKE} depend all install cd ${.CURDIR}/share/man && ${MAKE} makedb hierarchy: --- 87,119 ---- .else OBJDIR= obj .endif + + .if defined(NOCLEAN) + CLEANDIR= + WORLD_CLEANDIST=obj + .else + WORLD_CLEANDIST=cleandist .if defined(NOCLEANDIR) CLEANDIR= clean .else CLEANDIR= cleandir .endif + .endif ! world: hierarchy mk $(WORLD_CLEANDIST) includes lib-tools libraries tools @echo "--------------------------------------------------------------" @echo " Rebuilding ${DESTDIR} The whole thing" @echo "--------------------------------------------------------------" @echo ${MAKE} depend all install + cd ${.CURDIR}/share/man && ${MAKE} makedb + + reinstall: hierarchy mk includes + @echo "--------------------------------------------------------------" + @echo " Reinstalling ${DESTDIR} The whole thing" + @echo "--------------------------------------------------------------" + @echo + ${MAKE} install cd ${.CURDIR}/share/man && ${MAKE} makedb hierarchy: -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-hackers Mon Oct 23 16:20:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA05785 for hackers-outgoing; Mon, 23 Oct 1995 16:20:31 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA05775 for ; Mon, 23 Oct 1995 16:20:29 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id QAA21109; Mon, 23 Oct 1995 16:19:58 -0700 Message-Id: <199510232319.QAA21109@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: ache@freefall.freebsd.org, John Polstra , freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 1995 01:39:38 +0300." Date: Mon, 23 Oct 1995 16:19:58 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >In message John Polstra writes: > >>Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid >>programs? If not, I think that the recent change should be removed from >>rtld.c. > >In this case I keep in mind some shell script execution which calls >setuid programs. By setiing LD_NOSTD_PATH user allows such >programs easily fails, it is clear. Here can be very unpleasant >side effect that usually shell scripts not expects setuid >programs failing for such reasons and have lack of error traping >at this point. It can leads to unpredictable things in >shell script execution flow. > > >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 UN*X systems have clasically given you a shotgun powerfull enough to blow your foot off. If you are knowledgeable enough to use LD_NOSTD_PATH, then you should know its effects. Since it is not a security problem, I don't think it should be removed (as I said in other mail on this subject). -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 23 16:53:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA07978 for hackers-outgoing; Mon, 23 Oct 1995 16:53:28 -0700 Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA07972 for ; Mon, 23 Oct 1995 16:53:24 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id QAA06821 for hackers@freebsd.org; Mon, 23 Oct 1995 16:55:05 -0700 From: Brian Litzinger Message-Id: <199510232355.QAA06821@MediaCity.com> Subject: Still no go on linux emul To: hackers@freebsd.org Date: Mon, 23 Oct 1995 16:55:05 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2361 Sender: owner-hackers@freebsd.org Precedence: bulk Got a -current kernel compiled with options SYSVSHM options SYSVSEM options SYSVMSG options COMPAT_LINUX among others. >ls -l /lib lrwxr-xr-x 1 root wheel 17 Mar 5 1995 /lib@ -> /compat/linux/lib >ls -l /compat/linux/lib total 2780 -rwxr-xr-x 1 root wheel 17412 Oct 23 09:59 ld.so* -rwxr-xr-x 1 root wheel 320516 Oct 23 10:03 libX11.so.3* -rwxr-xr-x 1 root wheel 529412 Oct 23 10:05 libX11.so.6.0* -rwxr-xr-x 1 root wheel 90664 Oct 23 10:17 libXt.sa* -rwxr-xr-x 1 root wheel 291844 Oct 23 10:18 libXt.so.3* -rwxr-xr-x 1 root wheel 320516 Oct 23 10:16 libXt.so.6.0* lrwxr-xr-x 1 root wheel 13 Oct 23 10:33 libc.so.4@ -> libc.so.4.7.2 -rwxr-xr-x 1 root wheel 634880 Oct 23 10:00 libc.so.4.7.2* -rwxr-xr-x 1 root wheel 562683 Oct 23 10:02 libc.so.5.0.9* >modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f08a5000 0018 f08aa000 1 linux_emulator > ls -l /usr/games/doom total 7680 -rw-r--r-- 1 root bin 64572 Dec 7 1994 README.linuxs -rw-r--r-- 1 root wheel 4196020 Oct 23 10:29 doom1.wad -rw-r--r-- 1 root wheel 424853 Mar 1 1995 doom1.wad-part2.gz -rw-r--r-- 1 root wheel 1331200 Mar 1 1995 doom1.wad.gz -rws--x--x 1 root bin 15291 Mar 2 1995 killmouse* -rwxr-xr-x 1 root bin 165 Mar 2 1995 killmouse.sh* -rws--x--x 1 root bin 300036 Dec 7 1994 linuxsdoom* -rwxr-xr-x 1 root bin 304132 Mar 1 1995 linuxxdoom* -rw------- 1 root wheel 1105920 Oct 23 10:33 linuxxdoom.core -rwxr-xr-x 1 root bin 27434 Mar 1 1995 sndserver* -rws--x--x 1 root bin 15291 Mar 2 1995 startmouse* -rwxr-xr-x 1 root bin 165 Mar 2 1995 startmouse.sh* >ls -l /etc/host.conf ls: /etc/host.conf: No such file or directory >DOOMWADDIR=/usr/games/doom >export DOOMWADDIR >cd $DOOMWADDIR >./linuxxdoom zsh: segmentation fault ./linuxxdoom Help. Same happens with Wingz and any other linux app. Perhaps I need a specific set of linux libs? If so, anyone with a working set care to make then available somwhere? -- Brian Litzinger | | brian@mediacity.com | This space intentionally left blank | http://www.mpress.com | | From owner-freebsd-hackers Mon Oct 23 17:05:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA08666 for hackers-outgoing; Mon, 23 Oct 1995 17:05:13 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA08659 for ; Mon, 23 Oct 1995 17:05:10 -0700 Received: by sequent.kiae.su id AA00320 (5.65.kiae-2 ); Tue, 24 Oct 1995 04:01:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 04:01:57 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA07330; Tue, 24 Oct 1995 02:58:52 +0300 To: "Justin T. Gibbs" Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510232319.QAA21109@aslan.cdrom.com> In-Reply-To: <199510232319.QAA21109@aslan.cdrom.com>; from "Justin T. Gibbs" at Mon, 23 Oct 1995 16:19:58 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 02:58:52 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 998 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510232319.QAA21109@aslan.cdrom.com> Justin T. Gibbs writes: >UN*X systems have clasically given you a shotgun powerfull enough >to blow your foot off. If you are knowledgeable enough to use >LD_NOSTD_PATH, then you should know its effects. Since it is not >a security problem, I don't think it should be removed (as I said >in other mail on this subject). Well, but already existen shell scripts, i.e. admin things knows nothing about possibility of failing via LD_NOSTD_PATH. I.e. when they calls "su -c ..." they assume that this command NOT fails. They even disable ^C somethimes to be shure. But LD_NOSTD_PATH as very recent addition and I see no one script which care of it. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 17:05:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA08732 for hackers-outgoing; Mon, 23 Oct 1995 17:05:37 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA08722 for ; Mon, 23 Oct 1995 17:05:33 -0700 Received: by sequent.kiae.su id AA00316 (5.65.kiae-2 ); Tue, 24 Oct 1995 04:01:57 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 04:01:56 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id CAA07323; Tue, 24 Oct 1995 02:55:25 +0300 To: Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510232318.RAA24039@rocky.sri.MT.net> In-Reply-To: <199510232318.RAA24039@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 17:18:23 -0600 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 02:55:24 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 984 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510232318.RAA24039@rocky.sri.MT.net> Nate Williams writes: >> >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid >> >programs? If not, I think that the recent change should be removed from >> >rtld.c. >> >> In this case I keep in mind some shell script execution which calls >> setuid programs. By setiing LD_NOSTD_PATH user allows such >> programs easily fails, it is clear. >Why should a program which calls setuid programs fail in the first >place? If they are calling a setuid program it will still only look in >the 'normal' places for shlibs, which means they are safe. If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 17:10:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09148 for hackers-outgoing; Mon, 23 Oct 1995 17:10:06 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09140 for ; Mon, 23 Oct 1995 17:10:01 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id RAA05000 for ; Mon, 23 Oct 1995 17:08:49 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id SAA24195; Mon, 23 Oct 1995 18:10:45 -0600 Date: Mon, 23 Oct 1995 18:10:45 -0600 From: Nate Williams Message-Id: <199510240010.SAA24195@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: Nate Williams , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510232318.RAA24039@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk > >> >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid > >> >programs? If not, I think that the recent change should be removed from > >> >rtld.c. > >> > >> In this case I keep in mind some shell script execution which calls > >> setuid programs. By setiing LD_NOSTD_PATH user allows such > >> programs easily fails, it is clear. > > >Why should a program which calls setuid programs fail in the first > >place? If they are calling a setuid program it will still only look in > >the 'normal' places for shlibs, which means they are safe. > > If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. Then a system shared binary is *completely* and *utterly* useless. Anyone who writes programs that writes shells scripts that depend on system routines working with LD_NOSTD_PATH should deserve the error messages they get. Why are we un-necessarily complicating the runtime loader with this? Given this, I say the change is gratitious and un-needed. Nate From owner-freebsd-hackers Mon Oct 23 17:15:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09561 for hackers-outgoing; Mon, 23 Oct 1995 17:15:00 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09556 for ; Mon, 23 Oct 1995 17:14:57 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id RAA21318; Mon, 23 Oct 1995 17:14:34 -0700 Message-Id: <199510240014.RAA21318@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: "Justin T. Gibbs" , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 1995 02:58:52 +0300." Date: Mon, 23 Oct 1995 17:14:34 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >In message <199510232319.QAA21109@aslan.cdrom.com> Justin T. Gibbs > writes: > >>UN*X systems have clasically given you a shotgun powerfull enough >>to blow your foot off. If you are knowledgeable enough to use >>LD_NOSTD_PATH, then you should know its effects. Since it is not >>a security problem, I don't think it should be removed (as I said >>in other mail on this subject). > >Well, but already existen shell scripts, i.e. admin things knows >nothing about possibility of failing via LD_NOSTD_PATH. >I.e. when they calls "su -c ..." they assume that this command >NOT fails. They even disable ^C somethimes to be shure. >But LD_NOSTD_PATH as very recent addition and I see no one >script which care of it. But anyone who sets LD_NOSTD_PATH will not be able to run *anything* shared unless the have a sane LD_LIBRARY_PATH. This is not a shell script only problem and I don't think the change is appropriate. >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 23 17:22:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10352 for hackers-outgoing; Mon, 23 Oct 1995 17:22:26 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA10343 for ; Mon, 23 Oct 1995 17:22:23 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id JAA03643; Tue, 24 Oct 1995 09:40:04 +0930 From: Michael Smith Message-Id: <199510240010.JAA03643@genesis.atrad.adelaide.edu.au> Subject: Re: Netscape puzzle To: terry@lambert.org (Terry Lambert) Date: Tue, 24 Oct 1995 09:40:03 +0930 (CST) Cc: kaleb@x.org, nate@rocky.sri.MT.net, hackers@freefall.freebsd.org In-Reply-To: <199510231825.LAA11356@phaeton.artisoft.com> from "Terry Lambert" at Oct 23, 95 11:25:03 am Content-Type: text Content-Length: 965 Sender: owner-hackers@FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > I had tried that and it didn't make any difference with the BSD 2.0b1, > > I still got an "unable to open display" error. :-( ... > We already know there are differences in the way the environment > code works, and you are highly dependeint on that code. > > Have you tried it with an explicit "-display" argument instead of > relying on the environment? FWIW, Terry, DISPLAY=fqdn:0.0 doesn't work, but DISPLAY=1.2.3.4:0.0 _does_ work. I'd suspect that it was a resolver problem, only URL's are resolved fine 8( > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 23 17:26:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA10747 for hackers-outgoing; Mon, 23 Oct 1995 17:26:25 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA10733 for ; Mon, 23 Oct 1995 17:26:17 -0700 Received: by sequent.kiae.su id AA03520 (5.65.kiae-2 ); Tue, 24 Oct 1995 04:24:25 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 04:24:24 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA07440; Tue, 24 Oct 1995 03:23:07 +0300 To: "Justin T. Gibbs" Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240014.RAA21318@aslan.cdrom.com> In-Reply-To: <199510240014.RAA21318@aslan.cdrom.com>; from "Justin T. Gibbs" at Mon, 23 Oct 1995 17:14:34 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 03:23:07 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 32 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1502 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240014.RAA21318@aslan.cdrom.com> Justin T. Gibbs writes: >>In message <199510232319.QAA21109@aslan.cdrom.com> Justin T. Gibbs >> writes: >> >>>UN*X systems have clasically given you a shotgun powerfull enough >>>to blow your foot off. If you are knowledgeable enough to use >>>LD_NOSTD_PATH, then you should know its effects. Since it is not >>>a security problem, I don't think it should be removed (as I said >>>in other mail on this subject). >> >>Well, but already existen shell scripts, i.e. admin things knows >>nothing about possibility of failing via LD_NOSTD_PATH. >>I.e. when they calls "su -c ..." they assume that this command >>NOT fails. They even disable ^C somethimes to be shure. >>But LD_NOSTD_PATH as very recent addition and I see no one >>script which care of it. >But anyone who sets LD_NOSTD_PATH will not be able to run *anything* >shared unless the have a sane LD_LIBRARY_PATH. This is not a >shell script only problem and I don't think the change is appropriate. Well, we have a lot static utils, i.e. whole /bin, /sbin and few from other places. They still works in this situation. Moreover, current shared shell works too, it is already in memory. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 17:31:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA11341 for hackers-outgoing; Mon, 23 Oct 1995 17:31:53 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA11322 for ; Mon, 23 Oct 1995 17:31:49 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id RAA21409; Mon, 23 Oct 1995 17:31:23 -0700 Message-Id: <199510240031.RAA21409@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: "Justin T. Gibbs" , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 1995 03:23:07 +0300." Date: Mon, 23 Oct 1995 17:31:23 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >>But anyone who sets LD_NOSTD_PATH will not be able to run *anything* >>shared unless the have a sane LD_LIBRARY_PATH. This is not a >>shell script only problem and I don't think the change is appropriate. > >Well, we have a lot static utils, i.e. whole /bin, /sbin and >few from other places. They still works in this situation. >Moreover, current shared shell works too, it is already in memory. Bogus argument in my opinion. The people who are going to use LD_NOSTD_PATH will know its effects. If you still want to argue about this, fine, but I'd like to put this issue to a vote. >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 23 17:37:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12278 for hackers-outgoing; Mon, 23 Oct 1995 17:37:40 -0700 Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12268 for ; Mon, 23 Oct 1995 17:37:38 -0700 Received: from vixen.Dartmouth.EDU (vixen.dartmouth.edu [129.170.208.15]) by dartvax.dartmouth.edu (8.6.12-DND/8.6.12) with SMTP id UAA25675 for ; Mon, 23 Oct 1995 20:37:35 -0400 Message-id: <9872290@vixen.Dartmouth.EDU> Date: 23 Oct 95 20:37:35 EDT From: Ting.Cai@Dartmouth.EDU (Ting Cai) Subject: Network Status Problem To: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk Hi! All: I am trying to find out an easy and quick way to tell if the network is up or down.I found that ioctl could retrieve the 'ifflags' which contains the infomation on if the network is up, but after hours of trying, ioctl still returns error: ioctl: Device not configured Here is the little program I wrote: struct ifreq data; struct sockaddr_in address; size = sizeof(struct sockaddr_in); if ((id = socket(PF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } bzero ((char *) &address, sizeof(address)); address.sin_family = PF_INET; address.sin_port = htons(SERV_TCP_PORT); address.sin_addr.s_addr = htonl (INADDR_ANY); if (bind(id,(struct sockaddr *) &address, size)) { perror("bind"); exit(1); } if ( ioctl(id,SIOCGIFFLAGS,&data ) < 0) { perror("ioctl"); exit(1); } /************* end of program ************************************/ Do you have some suggestions? or any other way to get the network status information? Many thanks to you all. Ting Cai at Dartmouth College email: tcai@cs.dartmouth.edu --UAA25927.814494928/dartvax.dartmouth.edu-- From owner-freebsd-hackers Mon Oct 23 17:41:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12834 for hackers-outgoing; Mon, 23 Oct 1995 17:41:01 -0700 Received: from sloop.cis.ufl.edu (sycheng@sloop.cis.ufl.edu [128.227.176.62]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12818 for ; Mon, 23 Oct 1995 17:40:54 -0700 From: sycheng@cis.ufl.edu Received: by sloop.cis.ufl.edu (8.6.7/cis.ufl.edu) id UAA05057; Mon, 23 Oct 1995 20:40:48 -0400 Message-Id: <199510240040.UAA05057@sloop.cis.ufl.edu> Subject: Cannot install in one big / To: hackers@freebsd.org Date: Mon, 23 Oct 1995 20:40:47 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24 ME7a] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 872 Sender: owner-hackers@freebsd.org Precedence: bulk Hi : I've tried several times on several machines to install 951020 SNAP into one big / partition instead of (/, /usr, /var), but always got errors and couldn't continue the installation. It then force me to use the auto function to create several slices instead of one. Could you please correct that ? Thanks a lot. -- Cheng, Hsiao-Yang Graduate Student ___ . TEL: 9 0 4 - 3 3 Department of Computer Information Science / \ / 8 University of Florida, Gainesville | /^~~) (~~) )Hsiao--_ 8 E-mail: sycheng@cis.ufl.edu \ // ( (~~~ / ( Yang) 4 WWW : http://www.cis.ufl.edu/~sycheng ```` ` ~~~` ` / 9 <> WE GROW GREAT BY DREAMS. ALL BIG ARE DREAMERS \ / 1 `` From owner-freebsd-hackers Mon Oct 23 17:41:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12869 for hackers-outgoing; Mon, 23 Oct 1995 17:41:14 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12860 for ; Mon, 23 Oct 1995 17:41:10 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA12297; Mon, 23 Oct 1995 17:33:21 -0700 From: Terry Lambert Message-Id: <199510240033.RAA12297@phaeton.artisoft.com> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Mon, 23 Oct 1995 17:33:20 -0700 (MST) Cc: ache@astral.msk.su, gibbs@freefall.freebsd.org, ache@freefall.freebsd.org, freebsd-hackers@FreeBSD.ORG, jdp@polstra.com In-Reply-To: <199510240031.RAA21409@aslan.cdrom.com> from "Justin T. Gibbs" at Oct 23, 95 05:31:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1314 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >>But anyone who sets LD_NOSTD_PATH will not be able to run *anything* > >>shared unless the have a sane LD_LIBRARY_PATH. This is not a > >>shell script only problem and I don't think the change is appropriate. > > > >Well, we have a lot static utils, i.e. whole /bin, /sbin and > >few from other places. They still works in this situation. > >Moreover, current shared shell works too, it is already in memory. > > Bogus argument in my opinion. The people who are going to use > LD_NOSTD_PATH will know its effects. If you still want to argue > about this, fine, but I'd like to put this issue to a vote. Sun can use LD_NOSTD_PATH because all it does is turn off the search path from ldconfig. When you compile a binary with a shared lib on SunOS, it remembers the path of the library it actually linked with. I thought FreeBSD did this as well? The point is to prevent a hack of ldconfig or the database from being a security problem (even if it's just a Trojan used for the hack). If FreeBSD "does the right thing" when the library path searching is disabled (ie: "knows" the path used on the link), then LD_NOSTD_PATH is a valid change. Otherwise, it is not. 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 Oct 23 17:52:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA14246 for hackers-outgoing; Mon, 23 Oct 1995 17:52:13 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id RAA14238 for ; Mon, 23 Oct 1995 17:52:06 -0700 Received: by sequent.kiae.su id AA07885 (5.65.kiae-2 ); Tue, 24 Oct 1995 04:47:53 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 04:47:52 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id DAA07550; Tue, 24 Oct 1995 03:46:31 +0300 To: "Justin T. Gibbs" Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240031.RAA21409@aslan.cdrom.com> In-Reply-To: <199510240031.RAA21409@aslan.cdrom.com>; from "Justin T. Gibbs" at Mon, 23 Oct 1995 17:31:23 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 03:46:31 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1115 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240031.RAA21409@aslan.cdrom.com> Justin T. Gibbs writes: >>>But anyone who sets LD_NOSTD_PATH will not be able to run *anything* >>>shared unless the have a sane LD_LIBRARY_PATH. This is not a >>>shell script only problem and I don't think the change is appropriate. >> >>Well, we have a lot static utils, i.e. whole /bin, /sbin and >>few from other places. They still works in this situation. >>Moreover, current shared shell works too, it is already in memory. >Bogus argument in my opinion. The people who are going to use >LD_NOSTD_PATH will know its effects. If you still want to argue >about this, fine, but I'd like to put this issue to a vote. Yes, it can be used by intruder for hackers purposes, if he examine previously what script does. Ok with me, lets put this issue to a vote. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 17:59:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA14787 for hackers-outgoing; Mon, 23 Oct 1995 17:59:16 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA14773 for ; Mon, 23 Oct 1995 17:59:08 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA09267; Mon, 23 Oct 1995 17:58:51 -0700 To: sycheng@cis.ufl.edu cc: hackers@freebsd.org Subject: Re: Cannot install in one big / In-reply-to: Your message of "Mon, 23 Oct 1995 20:40:47 EDT." <199510240040.UAA05057@sloop.cis.ufl.edu> Date: Mon, 23 Oct 1995 17:58:51 -0700 Message-ID: <9265.814496331@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > I've tried several times on several machines to install 951020 SNAP > into one big / partition instead of (/, /usr, /var), but always got > errors and couldn't continue the installation. It then force me to use What sort of errors? You need to be a lot more detailed in your bug reports than this if you expect me to be able to do anything with them! :-( Jordan From owner-freebsd-hackers Mon Oct 23 18:03:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15133 for hackers-outgoing; Mon, 23 Oct 1995 18:03:04 -0700 Received: from mom.hooked.net (root@mom.hooked.net [199.2.134.16]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15107 for ; Mon, 23 Oct 1995 18:02:52 -0700 Received: from worm-8.ppp.hooked.net (worm-8.ppp.hooked.net [204.212.195.200]) by mom.hooked.net (8.6.10/8.6.5) with SMTP id SAA28921 for ; Mon, 23 Oct 1995 18:03:50 -0700 Date: Mon, 23 Oct 1995 18:03:50 -0700 Message-Id: <199510240103.SAA28921@mom.hooked.net> X-Sender: danai@mailhost.hooked.net 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: danai lamb Subject: Adaptec AIC-7850 Sender: owner-hackers@freebsd.org Precedence: bulk Hi all ! Does someone know something about the support of the Adaptec AIC-7850 ? Have one here and can't install FreeBSD at the moment :( Bye, Ulf. From owner-freebsd-hackers Mon Oct 23 18:05:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15419 for hackers-outgoing; Mon, 23 Oct 1995 18:05:43 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA15408 for ; Mon, 23 Oct 1995 18:05:38 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7Xo8-000078C; Mon, 23 Oct 95 18:05 PDT Message-Id: Date: Mon, 23 Oct 95 18:05 PDT From: jdp@polstra.com (John Polstra) To: ache@freefall.freebsd.org Cc: freebsd-hackers@freebsd.org, gibbs@freefall.freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Sender: owner-hackers@freebsd.org Precedence: bulk > >Bogus argument in my opinion. The people who are going to use > >LD_NOSTD_PATH will know its effects. If you still want to argue > >about this, fine, but I'd like to put this issue to a vote. > > Yes, it can be used by intruder for hackers purposes, if he examine > previously what script does. I don't think it can be used for hacking purposes. All it can possibly do is make a command fail to execute at all. Any shell script would have to be pretty silly to permit that to result in a security breach. If you're going to worry about LD_NOSTD_PATH in ld.so, then why not also have it reset PATH, IFS, DISPLAY, and many other environment variables? (I am *not* recommending that!). > Ok with me, lets put this issue to a vote. Who gets to vote? John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon Oct 23 18:17:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16287 for hackers-outgoing; Mon, 23 Oct 1995 18:17:08 -0700 Received: from rover.village.org (rover.village.org [198.137.146.49]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA16279 for ; Mon, 23 Oct 1995 18:16:58 -0700 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id TAA20162; Mon, 23 Oct 1995 19:16:36 -0600 Message-Id: <199510240116.TAA20162@rover.village.org> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Subject: Re: Netscape puzzle Cc: Terry Lambert , hackers@freefall.freebsd.org, "Kaleb S. KEITHLEY" In-reply-to: Your message of Tue, 24 Oct 1995 03:00:47 +0300 Date: Mon, 23 Oct 1995 19:16:36 -0600 From: Warner Losh Sender: owner-hackers@FreeBSD.org Precedence: bulk : >Oh, they claim that if your run the name server on your machine, and : >the host is cached in your name server, the problem goes away. : It isn't true, just check. I'll take your word for it. I've not tried it personally. I was merely reporting what I had heard. Warner From owner-freebsd-hackers Mon Oct 23 18:19:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16557 for hackers-outgoing; Mon, 23 Oct 1995 18:19:29 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA16543 for ; Mon, 23 Oct 1995 18:19:24 -0700 Received: by sequent.kiae.su id AA11274 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:16:08 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:16:06 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00246; Tue, 24 Oct 1995 04:15:05 +0300 To: "Justin T. Gibbs" , Terry Lambert Cc: ache@freefall.freebsd.org, freebsd-hackers@FreeBSD.ORG, jdp@polstra.com References: <199510240033.RAA12297@phaeton.artisoft.com> In-Reply-To: <199510240033.RAA12297@phaeton.artisoft.com>; from Terry Lambert at Mon, 23 Oct 1995 17:33:20 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:15:04 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 46 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1999 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510240033.RAA12297@phaeton.artisoft.com> Terry Lambert writes: >> >>But anyone who sets LD_NOSTD_PATH will not be able to run *anything* >> >>shared unless the have a sane LD_LIBRARY_PATH. This is not a >> >>shell script only problem and I don't think the change is appropriate. >> > >> >Well, we have a lot static utils, i.e. whole /bin, /sbin and >> >few from other places. They still works in this situation. >> >Moreover, current shared shell works too, it is already in memory. >> >> Bogus argument in my opinion. The people who are going to use >> LD_NOSTD_PATH will know its effects. If you still want to argue >> about this, fine, but I'd like to put this issue to a vote. >Sun can use LD_NOSTD_PATH because all it does is turn off the search >path from ldconfig. >When you compile a binary with a shared lib on SunOS, it remembers the >path of the library it actually linked with. >I thought FreeBSD did this as well? >The point is to prevent a hack of ldconfig or the database from being >a security problem (even if it's just a Trojan used for the hack). >If FreeBSD "does the right thing" when the library path searching is >disabled (ie: "knows" the path used on the link), then LD_NOSTD_PATH >is a valid change. Otherwise, it is not. Yes, Terry, I agree with you. FreeBSD NOT does right thing here, i.e. it not remember path actually linked with, it relays on ld.so.hints only, so my change is valid. And most interesting thing is that LD_NOSTD_PATH not works at all yet. You can check it by setting LD_NOSTD_PATH, nothing happens then. I.e. you can still run all shared binaries with STD path. :-) I assume that it will be implemented properly in future. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 18:25:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17315 for hackers-outgoing; Mon, 23 Oct 1995 18:25:18 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA17304 for ; Mon, 23 Oct 1995 18:25:11 -0700 Received: by sequent.kiae.su id AB12006 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:22:31 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:22:30 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00294; Tue, 24 Oct 1995 04:22:00 +0300 To: ache@freefall.freebsd.org, John Polstra Cc: freebsd-hackers@freebsd.org, gibbs@freefall.freebsd.org References: In-Reply-To: ; from John Polstra at Mon, 23 Oct 95 18:05 PDT Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:22:00 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 35 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1406 Sender: owner-hackers@freebsd.org Precedence: bulk In message John Polstra writes: >> >Bogus argument in my opinion. The people who are going to use >> >LD_NOSTD_PATH will know its effects. If you still want to argue >> >about this, fine, but I'd like to put this issue to a vote. >> >> Yes, it can be used by intruder for hackers purposes, if he examine >> previously what script does. >I don't think it can be used for hacking purposes. All it can possibly >do is make a command fail to execute at all. Any shell script would >have to be pretty silly to permit that to result in a security breach. Well, simple example: setuid_shared_binary > /tmp/file ... (f.e. few static commands) setuid_static_binary < /tmp/file # OOPS! (umask is restrictive, of course) >If you're going to worry about LD_NOSTD_PATH in ld.so, then why not also >have it reset PATH, IFS, DISPLAY, and many other environment variables? >(I am *not* recommending that!). FYI, all security-aware scripts resets PATH. Did you see any? But all existen scripts already knows about PATH resetting and knows nothing about LD_NOSTD_PATH magic. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 18:25:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17371 for hackers-outgoing; Mon, 23 Oct 1995 18:25:40 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA17355 for ; Mon, 23 Oct 1995 18:25:28 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id SAA21704; Mon, 23 Oct 1995 18:24:57 -0700 Message-Id: <199510240124.SAA21704@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: danai lamb cc: freebsd-hackers@freebsd.org Subject: Re: Adaptec AIC-7850 In-reply-to: Your message of "Mon, 23 Oct 1995 18:03:50 PDT." <199510240103.SAA28921@mom.hooked.net> Date: Mon, 23 Oct 1995 18:24:57 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >Hi all ! > >Does someone know something about the support of the Adaptec AIC-7850 ? >Have one here and can't install FreeBSD at the moment :( > >Bye, Ulf. I'm have one of these controllers and am working on support for it. I don't have an ETA yet, but will post to -announce when we have support for it. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 23 18:26:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17442 for hackers-outgoing; Mon, 23 Oct 1995 18:26:34 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA17435 for ; Mon, 23 Oct 1995 18:26:26 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7Y8B-000078C; Mon, 23 Oct 95 18:26 PDT Message-Id: Date: Mon, 23 Oct 95 18:26 PDT From: jdp@polstra.com (John Polstra) To: ache@freefall.freebsd.org Cc: freebsd-hackers@FreeBSD.ORG, gibbs@freefall.freebsd.org, terry@lambert.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > And most interesting thing is that LD_NOSTD_PATH not works at all yet. > You can check it by setting LD_NOSTD_PATH, nothing happens then. > I.e. you can still run all shared binaries with STD path. :-) Yes. That is because ld.so still uses the hints file even when LD_NOSTD_PATH is set. If it finds a needed library in ld.so.hints, it will use it. I'm not arguing that this behavior is correct; I'm just explaining what's going on. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon Oct 23 18:28:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17588 for hackers-outgoing; Mon, 23 Oct 1995 18:28:11 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA17582 for ; Mon, 23 Oct 1995 18:28:08 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id SAA21729; Mon, 23 Oct 1995 18:27:38 -0700 Message-Id: <199510240127.SAA21729@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: ache@freefall.freebsd.org, John Polstra , freebsd-hackers@freebsd.org, gibbs@freefall.freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 1995 04:22:00 +0300." Date: Mon, 23 Oct 1995 18:27:38 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >In message John Polstra writes: > >>> >Bogus argument in my opinion. The people who are going to use >>> >LD_NOSTD_PATH will know its effects. If you still want to argue >>> >about this, fine, but I'd like to put this issue to a vote. >>> >>> Yes, it can be used by intruder for hackers purposes, if he examine >>> previously what script does. > >>I don't think it can be used for hacking purposes. All it can possibly >>do is make a command fail to execute at all. Any shell script would >>have to be pretty silly to permit that to result in a security breach. > >Well, simple example: > > setuid_shared_binary > /tmp/file Fails since it cannot find its libraries so /tmp/file is empty > ... (f.e. few static commands) > setuid_static_binary < /tmp/file # OOPS! What? It can't handle empty input? > (umask is restrictive, of course) >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Oct 23 18:42:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA18765 for hackers-outgoing; Mon, 23 Oct 1995 18:42:04 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA18758 for ; Mon, 23 Oct 1995 18:42:00 -0700 Received: by sequent.kiae.su id AA14507 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:41:14 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:41:13 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00415; Tue, 24 Oct 1995 04:36:18 +0300 To: "Justin T. Gibbs" Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240127.SAA21729@aslan.cdrom.com> In-Reply-To: <199510240127.SAA21729@aslan.cdrom.com>; from "Justin T. Gibbs" at Mon, 23 Oct 1995 18:27:38 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:36:18 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 760 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240127.SAA21729@aslan.cdrom.com> Justin T. Gibbs writes: >>Well, simple example: >> >> setuid_shared_binary > /tmp/file >Fails since it cannot find its libraries so /tmp/file is empty >> ... (f.e. few static commands) >> setuid_static_binary < /tmp/file # OOPS! >What? It can't handle empty input? It not supposed to handle empty input here, because first one never fails in normal situation (f.e. imagine signals disabled at startup). -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 18:42:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA18827 for hackers-outgoing; Mon, 23 Oct 1995 18:42:40 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA18820 for ; Mon, 23 Oct 1995 18:42:35 -0700 Received: by sequent.kiae.su id AA14518 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:41:16 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:41:16 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00425; Tue, 24 Oct 1995 04:40:48 +0300 To: ache@freefall.freebsd.org, John Polstra Cc: freebsd-hackers@FreeBSD.ORG, gibbs@freefall.freebsd.org, terry@lambert.org References: In-Reply-To: ; from John Polstra at Mon, 23 Oct 95 18:26 PDT Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:40:47 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 22 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 962 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message John Polstra writes: >> And most interesting thing is that LD_NOSTD_PATH not works at all yet. >> You can check it by setting LD_NOSTD_PATH, nothing happens then. >> I.e. you can still run all shared binaries with STD path. :-) >Yes. That is because ld.so still uses the hints file even when >LD_NOSTD_PATH is set. If it finds a needed library in ld.so.hints, it >will use it. >I'm not arguing that this behavior is correct; I'm just explaining >what's going on. Doing my fix I assume it will be implemented correctly in future, i.e. like Sun variable with same name does. Why the same name needed in other case? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 18:42:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA18867 for hackers-outgoing; Mon, 23 Oct 1995 18:42:57 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA18850 for ; Mon, 23 Oct 1995 18:42:51 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA04936; Mon, 23 Oct 1995 18:42:42 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA00275; Mon, 23 Oct 1995 18:41:24 -0700 Message-Id: <199510240141.SAA00275@corbin.Root.COM> To: Nate Williams cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Mon, 23 Oct 95 18:10:45 MDT." <199510240010.SAA24195@rocky.sri.MT.net> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 18:41:19 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >> >> >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid >> >> >programs? If not, I think that the recent change should be removed from >> >> >rtld.c. >> >> >> >> In this case I keep in mind some shell script execution which calls >> >> setuid programs. By setiing LD_NOSTD_PATH user allows such >> >> programs easily fails, it is clear. >> >> >Why should a program which calls setuid programs fail in the first >> >place? If they are calling a setuid program it will still only look in >> >the 'normal' places for shlibs, which means they are safe. >> >> If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. > >Then a system shared binary is *completely* and *utterly* useless. >Anyone who writes programs that writes shells scripts that depend on >system routines working with LD_NOSTD_PATH should deserve the error >messages they get. Why are we un-necessarily complicating the runtime >loader with this? > >Given this, I say the change is gratitious and un-needed. Any shell script which is suseptible to a security hole because a command failed to execute is broken. There are many reasons why things can fail ranging from no diskspace available to who knows what. I think Andrey's hack is an attempt to dam a river with a piece of tissue paper. The real problem is the shell script with the security hole, not the unpredictable nature of potential failures. My "vote" is to remove the hack. Regarding telnetd: I really think the proper solution to the problem is to do an inclusive env check, not an exclusive one. In other words, only specific environment variables should be allowed to be set (DISPLAY, TERM, a few others). It's really impossible to know what environment variables might lurk out there now and in the future - for instance, we check "TZ" in libc, and while I don't know how that could used to spoof telnetd/login, stranger things have happend. -DG From owner-freebsd-hackers Mon Oct 23 18:58:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA19659 for hackers-outgoing; Mon, 23 Oct 1995 18:58:22 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA19646 for ; Mon, 23 Oct 1995 18:58:15 -0700 Received: by sequent.kiae.su id AA16527 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:54:10 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:54:10 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00492; Tue, 24 Oct 1995 04:53:25 +0300 To: davidg@Root.COM, Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240141.SAA00275@corbin.Root.COM> In-Reply-To: <199510240141.SAA00275@corbin.Root.COM>; from David Greenman at Mon, 23 Oct 1995 18:41:19 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:53:25 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1482 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240141.SAA00275@corbin.Root.COM> David Greenman writes: > Any shell script which is suseptible to a security hole because a command >failed to execute is broken. There are many reasons why things can fail >ranging from no diskspace available to who knows what. I think Andrey's hack >is an attempt to dam a river with a piece of tissue paper. The real problem If we try to plug all potential holes that we find, even small ones, probability of security violation becomes reduced. I don't plan to dam whole river, just plug in small leak reducing leaks number at whole. > My "vote" is to remove the hack. Regarding telnetd: I really think the >proper solution to the problem is to do an inclusive env check, not an >exclusive one. In other words, only specific environment variables should be >allowed to be set (DISPLAY, TERM, a few others). It's really impossible to know >what environment variables might lurk out there now and in the future - for >instance, we check "TZ" in libc, and while I don't know how that could used to >spoof telnetd/login, stranger things have happend. For telnetd: I agree. Try to cantact with telnet maintainers on this issue. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 19:05:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA20128 for hackers-outgoing; Mon, 23 Oct 1995 19:05:10 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA20103 for ; Mon, 23 Oct 1995 19:04:59 -0700 Received: by sequent.kiae.su id AA17468 (5.65.kiae-2 ); Tue, 24 Oct 1995 06:00:53 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 06:00:52 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00560; Tue, 24 Oct 1995 05:00:23 +0300 To: davidg@Root.COM, Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240141.SAA00275@corbin.Root.COM> In-Reply-To: ; from =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= at Tue, 24 Oct 1995 04:53:25 +0300 (MSK) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 05:00:22 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 23 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1122 Sender: owner-hackers@freebsd.org Precedence: bulk In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >In message <199510240141.SAA00275@corbin.Root.COM> David Greenman > writes: >> Any shell script which is suseptible to a security hole because a command >>failed to execute is broken. There are many reasons why things can fail >>ranging from no diskspace available to who knows what. I think Andrey's hack >>is an attempt to dam a river with a piece of tissue paper. The real problem >If we try to plug all potential holes that we find, even small ones, >probability of security violation becomes reduced. I don't plan to dam whole >river, just plug in small leak reducing leaks number at whole. BTW, why you stuck on "shell scripts" only? The same hole can hits when commands entered by hand, see my example. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 19:32:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA23327 for hackers-outgoing; Mon, 23 Oct 1995 19:32:37 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA23147 for ; Mon, 23 Oct 1995 19:31:35 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id UAA24556; Mon, 23 Oct 1995 20:33:33 -0600 Date: Mon, 23 Oct 1995 20:33:33 -0600 From: Nate Williams Message-Id: <199510240233.UAA24556@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: Nate Williams , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510232318.RAA24039@rocky.sri.MT.net> <199510240010.SAA24195@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk [ Disabling LD_NOSTD_PATH for suid/guid programs ] > >> If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. > > >Then a system shared binary is *completely* and *utterly* useless. > > Do you mean our /usr/bin/su useless f.e.? > Or maybe /usr/sbin/sendmail? If you unset LD_NOSTD_PATH with these programs they will fail, since they will not be able to find their shlibs. There are *NO* known security risk by leaving the standard library path set in these programs. > All shell scripts writted prior LD_NOSTD_PATH or writted not > in FreeBSD (f.e. SysV scriprs) deserve not only error messages > they get but unpredicatable code flow after it. Huh? > >Given this, I say the change is gratitious and un-needed. > > You need to prove it, not just say. You can't provide me an example where unsetting LD_NOSTD_PATH is needed, so I would say that the burden of proof is on you. Nate From owner-freebsd-hackers Mon Oct 23 19:37:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA23811 for hackers-outgoing; Mon, 23 Oct 1995 19:37:11 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA23800 for ; Mon, 23 Oct 1995 19:37:03 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id UAA24582; Mon, 23 Oct 1995 20:39:09 -0600 Date: Mon, 23 Oct 1995 20:39:09 -0600 From: Nate Williams Message-Id: <199510240239.UAA24582@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: davidg@Root.COM, Nate Williams , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510240141.SAA00275@corbin.Root.COM> Sender: owner-hackers@freebsd.org Precedence: bulk > >If we try to plug all potential holes that we find, even small ones, > >probability of security violation becomes reduced. I don't plan to dam whole > >river, just plug in small leak reducing leaks number at whole. > > BTW, why you stuck on "shell scripts" only? The same hole can hits > when commands entered by hand, see my example. Let's see your example. You haven't provided one. Nate From owner-freebsd-hackers Mon Oct 23 19:44:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA24555 for hackers-outgoing; Mon, 23 Oct 1995 19:44:19 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA24531 for ; Mon, 23 Oct 1995 19:44:04 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id UAA24602; Mon, 23 Oct 1995 20:45:55 -0600 Date: Mon, 23 Oct 1995 20:45:55 -0600 From: Nate Williams Message-Id: <199510240245.UAA24602@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: "Justin T. Gibbs" , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510240014.RAA21318@aslan.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > >>>UN*X systems have clasically given you a shotgun powerfull enough > >>>to blow your foot off. If you are knowledgeable enough to use > >>>LD_NOSTD_PATH, then you should know its effects. Since it is not > >>>a security problem, I don't think it should be removed (as I said > >>>in other mail on this subject). I agree, and it appears that David and John P. are also in agreement. > >>Well, but already existen shell scripts, i.e. admin things knows > >>nothing about possibility of failing via LD_NOSTD_PATH. > >>I.e. when they calls "su -c ..." they assume that this command > >>NOT fails. They even disable ^C somethimes to be shure. > >>But LD_NOSTD_PATH as very recent addition and I see no one > >>script which care of it. Since it is a very recent addition, as Justin pointed out that if they are knowledgable enough to use it, they should know how to use it. > >But anyone who sets LD_NOSTD_PATH will not be able to run *anything* > >shared unless the have a sane LD_LIBRARY_PATH. Actually, it still won't work because setuid/setgid programs (correctly) unsets LD_LIBRARY_PATH. > This is not a > >shell script only problem and I don't think the change is appropriate. > > Well, we have a lot static utils, i.e. whole /bin, /sbin and > few from other places. They still works in this situation. > Moreover, current shared shell works too, it is already in memory. One, I find it hard to believe a program will work because it's in memory even though the shlibs can't be found, and secondly any script that needs to know that the programs it calls are linked static/shared is completely unportable. If you can't give a specific and useful example of *why* it's a good reason to do, I'm backing out the change with the speedup changes I'll be committing as soon as my tests complete. Nate From owner-freebsd-hackers Mon Oct 23 20:10:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA26968 for hackers-outgoing; Mon, 23 Oct 1995 20:10:17 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA26942 ; Mon, 23 Oct 1995 20:10:01 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA04077; Tue, 24 Oct 1995 12:32:06 +0930 From: Michael Smith Message-Id: <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> Subject: Re: startslip isn't just broken - it's EVIL! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 24 Oct 1995 12:32:05 +0930 (CST) Cc: hackers@freebsd.org, ache@freebsd.org In-Reply-To: <521.814475958@time.cdrom.com> from "Jordan K. Hubbard" at Oct 23, 95 12:19:18 pm Content-Type: text Content-Length: 849 Sender: owner-hackers@freebsd.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > I've added VJ compression support to sliplogin, but these other > problems I've been having with it in the wake of making those changes > (I can't even *test* them because the friggin' thing won't log in!!) > make me think that startslip doesn't need to be improved, it needs to > be re-written from scratch and I may just do that right now.. Guys! Use slattach and chat, and save yourselves the stress 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Mon Oct 23 20:16:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA27598 for hackers-outgoing; Mon, 23 Oct 1995 20:16:43 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA27579 ; Mon, 23 Oct 1995 20:16:35 -0700 Received: by sequent.kiae.su id AA01028 (5.65.kiae-2 ); Tue, 24 Oct 1995 07:07:27 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 07:07:25 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id FAA00288; Tue, 24 Oct 1995 05:56:34 +0300 To: Nate Williams Cc: ache@freefall.freebsd.org, David Greenman , freebsd-hackers@freebsd.org References: <199510232318.RAA24039@rocky.sri.MT.net> <199510240010.SAA24195@rocky.sri.MT.net> <199510240233.UAA24556@rocky.sri.MT.net> In-Reply-To: <199510240233.UAA24556@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 20:33:33 -0600 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 05:56:34 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 59 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2022 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240233.UAA24556@rocky.sri.MT.net> Nate Williams writes: >[ Disabling LD_NOSTD_PATH for suid/guid programs ] >> >> If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. >> >> >Then a system shared binary is *completely* and *utterly* useless. >> >> Do you mean our /usr/bin/su useless f.e.? >> Or maybe /usr/sbin/sendmail? >If you unset LD_NOSTD_PATH with these programs they will fail, since >they will not be able to find their shlibs. There are *NO* known >security risk by leaving the standard library path set in these >programs. I mean SET this variable and not UNSET. It is UNSET by default. >> All shell scripts writted prior LD_NOSTD_PATH or writted not >> in FreeBSD (f.e. SysV scriprs) deserve not only error messages >> they get but unpredicatable code flow after it. >Huh? What huh? >You can't provide me an example where unsetting LD_NOSTD_PATH is needed, >so I would say that the burden of proof is on you. unsetting -> setting. I already post it to hackers list, check your mail system, maybe something lost. Here it is again anyway: In message =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: >Well, simple example: > setuid_shared_binary > /tmp/file > ... (f.e. few static commands) > setuid_static_binary < /tmp/file # OOPS! > (umask is restrictive, of course) When LD_NOSTD_PATH is set (when it will works, of course), first binary fails leaving an empty file and second binary got empty input when it isn't suppose it. I assume script was unbreakable, of course, i.e. all signals was disabled. Now it becomes breakable. Basically it means that intruder gains ability to selectively control execution flow. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 20:18:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA27740 for hackers-outgoing; Mon, 23 Oct 1995 20:18:14 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA27731 for ; Mon, 23 Oct 1995 20:18:07 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA05093; Mon, 23 Oct 1995 20:17:59 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id UAA00294; Mon, 23 Oct 1995 20:16:29 -0700 Message-Id: <199510240316.UAA00294@corbin.Root.COM> To: ache@freefall.freebsd.org cc: freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 95 05:00:22 +0300." From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 20:16:28 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >In message > =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: > >>In message <199510240141.SAA00275@corbin.Root.COM> David Greenman >> writes: > >>> Any shell script which is suseptible to a security hole because a command >>>failed to execute is broken. There are many reasons why things can fail >>>ranging from no diskspace available to who knows what. I think Andrey's hack >>>is an attempt to dam a river with a piece of tissue paper. The real problem > >>If we try to plug all potential holes that we find, even small ones, >>probability of security violation becomes reduced. I don't plan to dam whole >>river, just plug in small leak reducing leaks number at whole. > >BTW, why you stuck on "shell scripts" only? The same hole can hits >when commands entered by hand, see my example. If you are capable of entering commands by hand then it is not an issue - the malicious user can set the environment variables directly and he'll see the command failure, so? Actually, I really don't think this is an issue in any case, and I would rather see the hack removed than to continue in this direction. Now that I've had some time to think about this, I would rather that we just remove support for LD_NOSTD_PATH completely. Except for shared library debugging, I can't think of a legitimate use for it. -DG From owner-freebsd-hackers Mon Oct 23 20:21:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA28075 for hackers-outgoing; Mon, 23 Oct 1995 20:21:29 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA28063 for ; Mon, 23 Oct 1995 20:21:16 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7ZvE-000078C; Mon, 23 Oct 95 20:21 PDT Message-Id: Date: Mon, 23 Oct 95 20:21 PDT From: jdp@polstra.com (John Polstra) To: davidg@Root.COM Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Sender: owner-hackers@freebsd.org Precedence: bulk wrote: > Now that I've had some time to think about this, I would rather that > we just remove support for LD_NOSTD_PATH completely. Except for shared > library debugging, I can't think of a legitimate use for it. I agree. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon Oct 23 20:24:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA28374 for hackers-outgoing; Mon, 23 Oct 1995 20:24:52 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA28360 for ; Mon, 23 Oct 1995 20:24:43 -0700 Received: by sequent.kiae.su id AA06333 (5.65.kiae-2 ); Tue, 24 Oct 1995 07:23:47 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 07:23:47 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA00515; Tue, 24 Oct 1995 06:22:05 +0300 To: "Jordan K. Hubbard" , Michael Smith Cc: hackers@freebsd.org References: <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> In-Reply-To: <199510240302.MAA04077@genesis.atrad.adelaide.edu.au>; from Michael Smith at Tue, 24 Oct 1995 12:32:05 +0930 (CST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 06:22:04 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: startslip isn't just broken - it's EVIL! Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1056 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> Michael Smith writes: >Jordan K. Hubbard stands accused of saying: >> I've added VJ compression support to sliplogin, but these other >> problems I've been having with it in the wake of making those changes >> (I can't even *test* them because the friggin' thing won't log in!!) >> make me think that startslip doesn't need to be improved, it needs to >> be re-written from scratch and I may just do that right now.. >Guys! Use slattach and chat, and save yourselves the stress 8) It is taste question. When I got my slip, I was trying to use slattach first, but switched to startslip, slattach works unstable for me. Startslip is better structured and not do anything in signal handlers. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 20:35:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA29260 for hackers-outgoing; Mon, 23 Oct 1995 20:35:26 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA29248 for ; Mon, 23 Oct 1995 20:35:18 -0700 Received: by sequent.kiae.su id AA04988 (5.65.kiae-2 ); Tue, 24 Oct 1995 07:20:00 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 07:19:59 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA00475; Tue, 24 Oct 1995 06:17:58 +0300 To: Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, "Justin T. Gibbs" References: <199510240014.RAA21318@aslan.cdrom.com> <199510240245.UAA24602@rocky.sri.MT.net> In-Reply-To: <199510240245.UAA24602@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 20:45:55 -0600 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 06:17:58 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 37 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1494 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240245.UAA24602@rocky.sri.MT.net> Nate Williams writes: >I agree, and it appears that David and John P. are also in agreement. Well, I and Terry in agreement :-) >Since it is a very recent addition, as Justin pointed out that if they >are knowledgable enough to use it, they should know how to use it. Hackers always know and will use it. >One, I find it hard to believe a program will work because it's in >memory even though the shlibs can't be found, and secondly any script Want experiment? Well. Start tcsh (it is dynamic). Then remove ld.so.hints or use ldconfig -s. You still can prefectly works in shell, but all share binaries dumps core. Don't forget to reboot after. >that needs to know that the programs it calls are linked static/shared >is completely unportable. I agree. As I already mention, all previously existen and working secure shell scripts becomes completely unportable, if my fix not be commited. >If you can't give a specific and useful example of *why* it's a good >reason to do, I'm backing out the change with the speedup changes I'll >be committing as soon as my tests complete. Well, I send this script already two times. Want yet once? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 20:33:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA29026 for hackers-outgoing; Mon, 23 Oct 1995 20:33:52 -0700 Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA28820 for ; Mon, 23 Oct 1995 20:31:21 -0700 Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id NAA04765; Tue, 24 Oct 1995 13:29:36 +1000 From: David Dawes Message-Id: <199510240329.NAA04765@rf900.physics.usyd.edu.au> Subject: Re: Netscape puzzle To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Tue, 24 Oct 1995 13:29:36 +1000 (EST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <199510231924.PAA01221@exalt.x.org> from "Kaleb S. KEITHLEY" at Oct 23, 95 03:24:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 835 Sender: owner-hackers@FreeBSD.org Precedence: bulk >> > I had tried that and it didn't make any difference with the BSD 2.0b1, >> > I still got an "unable to open display" error. :-( >> >> I suggest compiling a program that does a: >> >> main() >> { >> printf( "DISPLAY is '%s'\n", getenv("DISPLAY")); >> } >> >> On a BSDI 2.0 system and running it on a FreeBSD box and seeing what >> you get. > >Would that I had a BSD/OS 2.0 system to do that on. All I've got is a >1.1 CD-ROM. :-( I just tried it (compiled with 'gcc2 -static'), and it dumps core when run on FreeBSD 2.0.5 or the 951020 SNAP. A stack trace from gdb shows it dying in start(). Should it be compiled with a different compiler/options on BSD/OS 2.0? 'file' on BSD/OS says: 386 compact demand paged pure executable not stripped 'file' on FreeBSD says: BSD/386 demand paged (first page unmapped) pure ex David From owner-freebsd-hackers Mon Oct 23 20:35:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA29216 for hackers-outgoing; Mon, 23 Oct 1995 20:35:04 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA29190 for ; Mon, 23 Oct 1995 20:34:53 -0700 Received: by sequent.kiae.su id AA09221 (5.65.kiae-2 ); Tue, 24 Oct 1995 07:33:13 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 07:33:13 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA00556; Tue, 24 Oct 1995 06:32:30 +0300 To: ache@freefall.freebsd.org, davidg@Root.COM Cc: freebsd-hackers@freebsd.org, John Polstra References: <199510240316.UAA00294@corbin.Root.COM> In-Reply-To: <199510240316.UAA00294@corbin.Root.COM>; from David Greenman at Mon, 23 Oct 1995 20:16:28 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 06:32:29 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 35 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1605 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240316.UAA00294@corbin.Root.COM> David Greenman writes: > If you are capable of entering commands by hand then it is not an issue - >the malicious user can set the environment variables directly and he'll see >the command failure, so? Actually, I really don't think this is an issue in Single command failure isn't a case. Imagine that first running program store results somewhere for second one, maybe databases can be involved here. Basically first program can be designed unbreakable, i.e. user can only run it and can't stop or force to fail. With LD_* things it gains more power to control it. >any case, and I would rather see the hack removed than to continue in this >direction. My task here is notify about possible results. So, don't surprise if anybody use this hole in future :-) > Now that I've had some time to think about this, I would rather that we >just remove support for LD_NOSTD_PATH completely. Except for shared library >debugging, I can't think of a legitimate use for it. I agree with this. It is too suspicious. Moreover LD_NOSTD_PATH not work properly now (you can set it and it does nothing). John Polstra says that he already know about it. Yet one moreover: it not works as Sun variant too, Sun's variant have some reasons to live as Terry points. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 21:04:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA02267 for hackers-outgoing; Mon, 23 Oct 1995 21:04:28 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA02242 for ; Mon, 23 Oct 1995 21:04:11 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id VAA01169 for ; Mon, 23 Oct 1995 21:04:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA30871; Tue, 24 Oct 1995 13:48:03 +1000 Date: Tue, 24 Oct 1995 13:48:03 +1000 From: Bruce Evans Message-Id: <199510240348.NAA30871@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, guido@gvr.win.tue.nl Subject: Re: clk interrupts > 150/sec??? Sender: owner-hackers@freebsd.org Precedence: bulk >How can this be explained: >[~] guido@iaehv> vmstat -i >interrupt total rate >clk0 irq0 3884051 156 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >rtc0 irq8 3173264 128 >fdc0 irq6 1 0 >sc0 irq1 2462 0 >ed0 irq5 3667585 147 >I always thought clk0 should have a rate of 100/sec. Perhaps you used pcaudio. If it was open all the time then the clk0 rate should be about 16000. The rates reported will also be wrong when the counters overflow. At 100 Hz, the clk0 counter will overflow after 497 days. At 16000 Hz, it will overflow after only 3 days. Perhaps the counters should be u_quad_t's so that they don't overflow so soon. It is amusing that the process statistics counters (p_uticks, t_sticks and p_iticks) are already u_quad_t's. At a statistics clock frequency of 128 Hz, this prevents overflow for 23502 billion years. This seems excessive :-). u_quad_t's are more expensive than u_longs. u_long counters work for 388 days at 128 Hz. This is probably long enough for a single process (the counters are only incremented while the process is running), but the type is machine- independent so it needs to be large enough for all reasonable statistics clock frequencies. Bruce From owner-freebsd-hackers Mon Oct 23 21:08:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA02881 for hackers-outgoing; Mon, 23 Oct 1995 21:08:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA02862 ; Mon, 23 Oct 1995 21:08:14 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA05067; Mon, 23 Oct 1995 21:06:17 -0700 To: Michael Smith cc: hackers@freebsd.org, ache@freebsd.org Subject: Re: startslip isn't just broken - it's EVIL! In-reply-to: Your message of "Tue, 24 Oct 1995 12:32:05 +0930." <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> Date: Mon, 23 Oct 1995 21:06:16 -0700 Message-ID: <5064.814507576@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Guys! Use slattach and chat, and save yourselves the stress 8) I've never managed to get that combo to work! Chat just dies immediately.. :-( Jordan From owner-freebsd-hackers Mon Oct 23 21:09:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA03087 for hackers-outgoing; Mon, 23 Oct 1995 21:09:48 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA03055 for ; Mon, 23 Oct 1995 21:09:28 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA24768; Mon, 23 Oct 1995 22:11:38 -0600 Date: Mon, 23 Oct 1995 22:11:38 -0600 From: Nate Williams Message-Id: <199510240411.WAA24768@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: "Jordan K. Hubbard" , Michael Smith , hackers@FreeBSD.ORG Subject: Re: startslip isn't just broken - it's EVIL! In-Reply-To: References: <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk [ startslip bugs and other non-intuitiveness ] > >Guys! Use slattach and chat, and save yourselves the stress 8) > > It is taste question. When I got my slip, I was trying to use > slattach first, but switched to startslip, slattach works unstable for me. > Startslip is better structured and not do anything in signal handlers. Again, it's a taste question. I'm just finishing up my very simple slattach addtions and will send it to Jordan for his perusal. Unfortunately, the new sysconfig setup has made it a bit more difficult to edit 'one file' as I could do in 2.0, but it is still a piece of cake to make slattach and chat work with very little work. Nate From owner-freebsd-hackers Mon Oct 23 21:14:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA03804 for hackers-outgoing; Mon, 23 Oct 1995 21:14:58 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA03756 for ; Mon, 23 Oct 1995 21:14:31 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA24786; Mon, 23 Oct 1995 22:16:21 -0600 Date: Mon, 23 Oct 1995 22:16:21 -0600 From: Nate Williams Message-Id: <199510240416.WAA24786@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: Nate Williams , ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, "Justin T. Gibbs" Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510240014.RAA21318@aslan.cdrom.com> <199510240245.UAA24602@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk > In message <199510240245.UAA24602@rocky.sri.MT.net> Nate Williams > writes: > > >I agree, and it appears that David and John P. are also in agreement. > > Well, I and Terry in agreement :-) No, Terry and you are in disagreement. Read again what he wrote. Because FreeBSD's handling of the code is broken, then your fix is also broken. > >One, I find it hard to believe a program will work because it's in > >memory even though the shlibs can't be found, and secondly any script > > Want experiment? Well. Start tcsh (it is dynamic). Then > remove ld.so.hints or use ldconfig -s. You still can prefectly > works in shell, but all share binaries dumps core. > Don't forget to reboot after. Depending on this is a *very* bad thing. > >that needs to know that the programs it calls are linked static/shared > >is completely unportable. > > I agree. As I already mention, all previously existen and working secure > shell scripts becomes completely unportable, if my fix not be commited. I disagree, but anyway... , > >If you can't give a specific and useful example of *why* it's a good > >reason to do, I'm backing out the change with the speedup changes I'll > >be committing as soon as my tests complete. > > Well, I send this script already two times. Want yet once? I don't think you're 'script' is at all convincing, at least not to me. In any case it appears the consensus is to remove this feature from use, which I also agree would be a good thing. Nate From owner-freebsd-hackers Mon Oct 23 21:17:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA04063 for hackers-outgoing; Mon, 23 Oct 1995 21:17:23 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA04029 for ; Mon, 23 Oct 1995 21:17:08 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA24802; Mon, 23 Oct 1995 22:19:14 -0600 Date: Mon, 23 Oct 1995 22:19:14 -0600 From: Nate Williams Message-Id: <199510240419.WAA24802@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: References: <199510232318.RAA24039@rocky.sri.MT.net> <199510240010.SAA24195@rocky.sri.MT.net> <199510240233.UAA24556@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk > >Well, simple example: > > > setuid_shared_binary > /tmp/file > > ... (f.e. few static commands) > > setuid_static_binary < /tmp/file # OOPS! > > (umask is restrictive, of course) How will this example fail if you set LD_NOSTD_PATH? > When LD_NOSTD_PATH is set (when it will works, of course), > first binary fails leaving an empty file and second binary > got empty input when it isn't suppose it. And the problem is? > I assume script was unbreakable, of course, i.e. all signals > was disabled. Now it becomes breakable. Why is the script breakable? > Basically it means that intruder gains ability to selectively > control execution flow. Sigh, I think there are much bigger holes in the system that folks will have problems with if you attempt to use 'secure' shell scripts. Nate From owner-freebsd-hackers Mon Oct 23 21:57:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA08057 for hackers-outgoing; Mon, 23 Oct 1995 21:57:28 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA08042 ; Mon, 23 Oct 1995 21:57:09 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id JAA03948; Tue, 24 Oct 1995 09:53:28 +0500 From: "Serge A. Babkin" Message-Id: <199510240453.JAA03948@hq.icb.chel.su> Subject: Re: startslip isn't just broken - it's EVIL! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 24 Oct 1995 09:53:28 +0500 (GMT+0500) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org In-Reply-To: <5064.814507576@time.cdrom.com> from "Jordan K. Hubbard" at Oct 23, 95 09:06:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 475 Sender: owner-hackers@freebsd.org Precedence: bulk > > > Guys! Use slattach and chat, and save yourselves the stress 8) > > I've never managed to get that combo to work! Chat just dies > immediately.. :-( I got it working under 2.0. There were some strange problems but in common it worked. I remember that chat does not understand the dial-up string in the command line, it needs a file with it. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia From owner-freebsd-hackers Mon Oct 23 21:59:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA08288 for hackers-outgoing; Mon, 23 Oct 1995 21:59:44 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA08272 for ; Mon, 23 Oct 1995 21:59:26 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id XAA24885; Mon, 23 Oct 1995 23:01:31 -0600 Date: Mon, 23 Oct 1995 23:01:31 -0600 From: Nate Williams Message-Id: <199510240501.XAA24885@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: SLIP with chat/slattach (was Re: startslip ...) In-Reply-To: <5064.814507576@time.cdrom.com> References: <199510240302.MAA04077@genesis.atrad.adelaide.edu.au> <5064.814507576@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > > Guys! Use slattach and chat, and save yourselves the stress 8) > > I've never managed to get that combo to work! Chat just dies > immediately.. :-( OK, here is a quick README along with some files that may make your life easier. If someone feels it's worth adding to the FAQ, by all means feel free. Nate ----- # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # README # etc/ppp/slip-dial # etc/start_if.sl0 # etc/sysconfig.dif # etc/host.conf # echo x - README sed 's/^X//' >README << 'END-of-README' XQuick README for Nate's simple slattach/chat scripts. These scripts Xassume the connection is a full-time connection and that you have a Xpermanent IP address assigned to your box. Also, any necessary routing Xhas been taken care of by your ISP in the form of 'proxy arp' and/or Xrouting tables. X XINFORMATION NEEDED: X=================== Xa) Your Internet hostname Xb) Your Internet IP address Xc) The IP address of the machine you are connecting to Xd) Phone #, account, and password of the 'slip' account on the remote X machine X X X XPROVIDED FILE LIST X================== X/etc/ppp/slip-dial: X The dial script X/etc/sysconfig.dif: X Changes made to the stock sysconfig file to add SLIP support X/etc/start_if.sl0: X Commands to run on startup before the network device is ifconfig'd. X/etc/host.conf: X Sets up the resolver to attempt to resolve hostnames locally before X going to the BIND host to save bandwidth. Add any common hosts X into /etc/hosts, and make sure 'localhost' and your IP name/address X are correctly listed. X XLOCAL MODS X========== X/etc/sysconfig; X1) Modify sysconfig to have your hostname as given by your IP provider X X2) Disable TCP extensions as they cause some routers to reboot and/or X they can cause your connection to be very 'slow' X X3) Modify the 'ifconfig_sl0' line to contain first your IP address, and X then the IP address of the machine you are connecting to. X X4) Modify the 'defaultrouter' to also contain the IP address of the X machine you are connecting to, since all of your traffic must route X through your SLIP connection. X X/etc/ppp/slip-dial: X1) Modify the phone #, Account name, and password for your setup. X2) Modify the device to use to your local serial device. X2) Modify the 'chat' script if your login is more complicated. See the X man page for chat for help. X X/etc/start_if.sl0: X1) Modify the speed and device to match your configuration. X X/etc/host.conf: XNo changes necessary, this should work. X XTODO X==== X X- Modify the startup and dialing files in such a manner so that you need X only specify the device, speed, and other information in only one place. X X- Provide more complicated chat script examples. END-of-README echo x - etc/ppp/slip-dial sed 's/^X//' >etc/ppp/slip-dial << 'END-of-etc/ppp/slip-dial' X#!/bin/sh X# X# X# This program uses the chat program to (re)dial and connect back up to the X# SLIP host X XPHONE=1234567 XUSER=slipit XPASSWORD=secret XDEVICE=cuaa1 X X# XXX - As it stands now, we try to dial the remote site every 10 seconds X# or so until it answers. It would be better to have an exponential X# backoff algorithm, but this way is much easier to write and guarantees X# a connection as soon as one is available. X X# Wait just a little for the line to settle down Xsleep 10 X X(if chat -v ABORT "NO CARRIER" ABORT BUSY "" ATZ1 OK ATM0 OK ATDT$PHONE CONNECT "" ogin: $USER ssword: \\q$PASSWORD Xthen X exit 0 Xelse X exit 1 Xfi X) < /dev/$DEVICE > /dev/$DEVICE END-of-etc/ppp/slip-dial echo x - etc/start_if.sl0 sed 's/^X//' >etc/start_if.sl0 << 'END-of-etc/start_if.sl0' X#!/bin/sh Xslattach -a -h -r /etc/ppp/slip-dial -s 115200 cuaa1 END-of-etc/start_if.sl0 echo x - etc/sysconfig.dif sed 's/^X//' >etc/sysconfig.dif << 'END-of-etc/sysconfig.dif' X*** sysconfig.orig Mon Oct 23 22:36:39 1995 X--- sysconfig Mon Oct 23 22:37:53 1995 X*************** X*** 58,64 **** X ######################### Start Of Netconfig Section ####################### X X # Set to the name of your host - this is pretty important! X! hostname=myname.my.domain X X # Set to the NIS domainname of your host, or NO if none X defaultdomainname=NO X--- 58,64 ---- X ######################### Start Of Netconfig Section ####################### X X # Set to the name of your host - this is pretty important! X! hostname="sliphost.do.main" X X # Set to the NIS domainname of your host, or NO if none X defaultdomainname=NO X*************** X*** 68,74 **** X # TCP options. If TCP connections randomly hang, try disabling this, X # and bug the vendor of the losing equipment. X # X! tcp_extensions=YES X X # X # Set to the list of network devices on this host. You must have an X--- 68,74 ---- X # TCP options. If TCP connections randomly hang, try disabling this, X # and bug the vendor of the losing equipment. X # X! tcp_extensions=NO X X # X # Set to the list of network devices on this host. You must have an X*************** X*** 79,85 **** X # ifconfig_ed0="inet 10.0.0.1 netmask 0xffffff00" X # ifconfig_sl0="inet 10.0.1.0 netmask 0xffffff00" X # X! network_interfaces="lo0" X ifconfig_lo0="inet localhost" X X # X--- 79,86 ---- X # ifconfig_ed0="inet 10.0.0.1 netmask 0xffffff00" X # ifconfig_sl0="inet 10.0.1.0 netmask 0xffffff00" X # X! network_interfaces="sl0 lo0" X! ifconfig_sl0="inet 10.0.0.1 10.0.0.2 netmask 255.255.255.0" X ifconfig_lo0="inet localhost" X X # X*************** X*** 91,100 **** X route_loopback="${hostname} localhost" X X # Set to the host you'd like set as your default router, or NO for none. X! defaultrouter=NO X X # These are the flags you'd like to start the routing daemon with X! routedflags=-q X X # timed flags, or NO if you don't want to start the time daemon X timedflags=NO X--- 92,101 ---- X route_loopback="${hostname} localhost" X X # Set to the host you'd like set as your default router, or NO for none. X! defaultrouter="10.0.0.2" X X # These are the flags you'd like to start the routing daemon with X! routedflags="-q" X X # timed flags, or NO if you don't want to start the time daemon X timedflags=NO END-of-etc/sysconfig.dif echo x - etc/host.conf sed 's/^X//' >etc/host.conf << 'END-of-etc/host.conf' X# $Id: host.conf,v 1.2 1993/11/07 01:02:57 wollman Exp $ X# If that doesn't work, then try the /etc/hosts file Xhosts X# Default is to use the nameserver first Xbind X# If you have YP/NIS configured, uncomment the next line X# nis END-of-etc/host.conf exit From owner-freebsd-hackers Mon Oct 23 22:01:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA08518 for hackers-outgoing; Mon, 23 Oct 1995 22:01:26 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA08491 for ; Mon, 23 Oct 1995 22:01:18 -0700 Received: by sequent.kiae.su id AA20434 (5.65.kiae-2 ); Tue, 24 Oct 1995 08:50:08 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 08:50:07 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id HAA01075; Tue, 24 Oct 1995 07:45:13 +0300 To: Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org References: <199510232318.RAA24039@rocky.sri.MT.net> <199510240010.SAA24195@rocky.sri.MT.net> <199510240233.UAA24556@rocky.sri.MT.net> <199510240419.WAA24802@rocky.sri.MT.net> In-Reply-To: <199510240419.WAA24802@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 22:19:14 -0600 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 07:45:13 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 50 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1781 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240419.WAA24802@rocky.sri.MT.net> Nate Williams writes: >> >Well, simple example: >> >> > setuid_shared_binary > /tmp/file >> > ... (f.e. few static commands) >> > setuid_static_binary < /tmp/file # OOPS! >> > (umask is restrictive, of course) >How will this example fail if you set LD_NOSTD_PATH? It produce empty /tmp/file instead of valid data (first binary drops core at startup). Safely LD_NOSTD_PATH itself is not fully implemented in FreeBSD. >> When LD_NOSTD_PATH is set (when it will works, of course), >> first binary fails leaving an empty file and second binary >> got empty input when it isn't suppose it. >And the problem is? Second binary can treat empty data in unpredictable way. >> I assume script was unbreakable, of course, i.e. all signals >> was disabled. Now it becomes breakable. >Why is the script breakable? I mean that script/program writers allow user only _run_ programs, not stop or fail them. >> Basically it means that intruder gains ability to selectively >> control execution flow. >Sigh, I think there are much bigger holes in the system that folks will >have problems with if you attempt to use 'secure' shell scripts. I agree. But disabling even some holes reduces probability of secure violation. As I already mention, it isn't stuck on "shell scripts" only, entering the same command by hand give the same results. Imagine some database manipulations/requests handling with requestor programs started by hand. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 22:01:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA08587 for hackers-outgoing; Mon, 23 Oct 1995 22:01:50 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA08563 for ; Mon, 23 Oct 1995 22:01:41 -0700 Received: by sequent.kiae.su id AA20445 (5.65.kiae-2 ); Tue, 24 Oct 1995 08:50:11 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 08:50:10 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id HAA01083; Tue, 24 Oct 1995 07:48:58 +0300 To: Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, "Justin T. Gibbs" References: <199510240014.RAA21318@aslan.cdrom.com> <199510240245.UAA24602@rocky.sri.MT.net> <199510240416.WAA24786@rocky.sri.MT.net> In-Reply-To: <199510240416.WAA24786@rocky.sri.MT.net>; from Nate Williams at Mon, 23 Oct 1995 22:16:21 -0600 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 07:48:58 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 40 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1508 Sender: owner-hackers@freebsd.org Precedence: bulk In message <199510240416.WAA24786@rocky.sri.MT.net> Nate Williams writes: >> In message <199510240245.UAA24602@rocky.sri.MT.net> Nate Williams >> writes: >> >> >I agree, and it appears that David and John P. are also in agreement. >> >> Well, I and Terry in agreement :-) >No, Terry and you are in disagreement. Read again what he wrote. >Because FreeBSD's handling of the code is broken, then your fix is also >broken. My fix is attempt to cure FreeBSD handling, but seems that full cure will be complete removing of such thing. >> >One, I find it hard to believe a program will work because it's in >> >memory even though the shlibs can't be found, and secondly any script >> >> Want experiment? Well. Start tcsh (it is dynamic). Then >> remove ld.so.hints or use ldconfig -s. You still can prefectly >> works in shell, but all share binaries dumps core. >> Don't forget to reboot after. >Depending on this is a *very* bad thing. Not for true hacker :-) >I don't think you're 'script' is at all convincing, at least not to me. >In any case it appears the consensus is to remove this feature from use, >which I also agree would be a good thing. I vote for complete removing LD_NOSTD_PATH too. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Oct 23 22:18:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09412 for hackers-outgoing; Mon, 23 Oct 1995 22:18:16 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09385 for ; Mon, 23 Oct 1995 22:17:59 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id WAA05260; Mon, 23 Oct 1995 22:17:55 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id WAA00371; Mon, 23 Oct 1995 22:16:08 -0700 Message-Id: <199510240516.WAA00371@corbin.Root.COM> To: ache@freefall.freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 95 07:48:58 +0300." From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 22:16:08 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >>I don't think you're 'script' is at all convincing, at least not to me. >>In any case it appears the consensus is to remove this feature from use, >>which I also agree would be a good thing. > >I vote for complete removing LD_NOSTD_PATH too. Well then, we are in complete unanimous agreement on this issue. John P. has already indicated that he'll be removing it from ld.so. -DG From owner-freebsd-hackers Mon Oct 23 23:02:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA12799 for hackers-outgoing; Mon, 23 Oct 1995 23:02:12 -0700 Received: from nike.efn.org (garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA12772 ; Mon, 23 Oct 1995 23:01:48 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id XAA04848; Mon, 23 Oct 1995 23:03:33 -0700 Date: Mon, 23 Oct 1995 23:03:32 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: "Jordan K. Hubbard" cc: Michael Smith , hackers@FreeBSD.ORG, ache@FreeBSD.ORG Subject: Re: startslip isn't just broken - it's EVIL! In-Reply-To: <5064.814507576@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Mon, 23 Oct 1995, Jordan K. Hubbard wrote: > > Guys! Use slattach and chat, and save yourselves the stress 8) > > I've never managed to get that combo to work! Chat just dies > immediately.. :-( if we need some example scripts I would be willing to submit mine... I found out that it is safest to use chat with a external script as it eliminates the possiblity of a person seeing your password with "ps axwww"... I actually got it so slattach redials when busy or when my provider didn't let me access certain lines (I hadn't payed)... TTYL.. John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Mon Oct 23 23:41:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17588 for hackers-outgoing; Mon, 23 Oct 1995 23:41:02 -0700 Received: from io.org (root@io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17566 for ; Mon, 23 Oct 1995 23:40:51 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id CAA09456 for ; Tue, 24 Oct 1995 02:40:47 -0400 Date: Tue, 24 Oct 1995 02:40:59 -0400 (EDT) From: Brian Tao To: FREEBSD-HACKERS-L Subject: panic: free vnode isn't In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Tue, 17 Oct 1995, Brian Tao wrote: > > I'm starting to see total machine lockup on my IRC/FTP server > (2.1.0-950928-STABLE, 486DX2/66, irc 2.8.21, wu-ftpd 2.4). The only > pattern I can deduce so far is that it happens after about 2 days of > uptime. During those two days, the machine runs beautifully. With 64 > megs, it hardly touches swap even with a fully loaded EFnet IRC server > and 50-100 FTP connections. Then, out of the blue, it just freezes > up (always when I'm away from the office too :-/). I've been running the server with a debugging kernel for the past three days, and finally the darn thing crashed tonight (while I was away from the console too, of course). ddb popped up and left the following message on the console: panic: free vnode isn't Debugger("panic") Stopped at _Debugger+0x2b [/sys/compile/FTPSERV/:261]: movb $0,_inDebugger 110 ddb> Typing "continue" proceeded with the disk sync and reboot. I don't know if this is the cause of the machine hanging the last three times, but it is the only clue I have so far. Any ideas how I can avoid this? The system is an Intel 486DX2/66 on an ASUS SP3G board, 32 megabytes RAM, a 520-meg Maxtor drive on the built-in NCR controller and an NE2000-compatible Ethernet NIC. It is the NFS client for about 26 gigabytes of filesystems, but serving none of its own. I'm running the 2.1.0-950928 snapshot with the following kernel options: machine "i386" cpu "I486_CPU" cpu "I586_CPU" ident FTPSERV maxusers 64 options "CHILD_MAX=128" options "OPEN_MAX=128" options "NMBCLUSTERS=1024" config kernel root on sd0 dumps on sd0 options "COMPAT_43" options SYSVSHM options SYSVSEM options SYSVMSG options UCONSOLE options INET pseudo-device ether pseudo-device loop options FFS options NFS options "CD9660" options MSDOSFS options PROCFS options DDB options KTRACE controller scbus0 device sd0 device st0 device cd0 options SCSI_REPORT_GEOMETRY pseudo-device pty 32 pseudo-device log pseudo-device vn controller isa0 device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint options "PCVT_FREEBSD=210" options FAT_CURSOR device npx0 at isa? port "IO_NPX" irq 13 vector npxintr controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 device lpt0 at isa? port? tty irq 7 vector lptintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device ed1 at isa? port 0x300 net irq 12 iomem 0xd8000 vector edintr controller pci0 device ncr0 options PROBE_VERBOSE -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Mon Oct 23 23:42:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA17792 for hackers-outgoing; Mon, 23 Oct 1995 23:42:49 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA17752 for ; Mon, 23 Oct 1995 23:42:18 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA26867 ; Tue, 24 Oct 1995 07:42:03 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA22876 ; Tue, 24 Oct 1995 07:42:03 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id CAA04677; Tue, 24 Oct 1995 02:46:55 +0100 (MET) From: Ollivier Robert Message-Id: <199510240146.CAA04677@keltia.freenix.fr> Subject: Re: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) To: imp@village.org (Warner Losh) Date: Tue, 24 Oct 1995 02:46:54 +0100 (MET) Cc: peter@haywire.dialix.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510232257.QAA19117@rover.village.org> from "Warner Losh" at Oct 23, 95 04:57:41 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1245 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk It seems that Warner Losh said: > Does somebody have just this patch? I must have missed it as it went > by. I know that it is in current, but I need to patch a 1.1.5.1R > router.... Our current patch won't work in a pre-4.4BSD system (because of fwopen and friends that are only on FreeBSD 2.x). For 1.1.5.1 systems, you should try to get the vsnprintf patch along with vsnprintf itself (I should have one somewhere at work if you want). Send me a mail at roberto@hsc.fr.net and I'll dig it. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Sun Oct 22 20:22:48 MET 1995 From owner-freebsd-hackers Tue Oct 24 00:01:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19158 for hackers-outgoing; Tue, 24 Oct 1995 00:01:30 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA19153 for ; Tue, 24 Oct 1995 00:01:17 -0700 Received: by sequent.kiae.su id AA22163 (5.65.kiae-2 ); Tue, 24 Oct 1995 10:56:32 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 10:56:30 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id JAA02235; Tue, 24 Oct 1995 09:39:43 +0300 To: John-Mark Gurney , "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG, Michael Smith References: In-Reply-To: ; from John-Mark Gurney at Mon, 23 Oct 1995 23:03:32 -0700 (PDT) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 09:39:43 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: startslip isn't just broken - it's EVIL! Lines: 68 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2244 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message John-Mark Gurney writes: >On Mon, 23 Oct 1995, Jordan K. Hubbard wrote: >> > Guys! Use slattach and chat, and save yourselves the stress 8) >> >> I've never managed to get that combo to work! Chat just dies >> immediately.. :-( >if we need some example scripts I would be willing to submit mine... I >found out that it is safest to use chat with a external script as it >eliminates the possiblity of a person seeing your password with "ps >axwww"... I actually got it so slattach redials when busy or when my >provider didn't let me access certain lines (I hadn't payed)... TTYL.. Well, here startslip example scripts (taken from -current): # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # sldown.sh # slip.sh # slup.sh # echo x - sldown.sh sed 's/^X//' >sldown.sh << 'END-of-sldown.sh' X#!/bin/sh X/sbin/ifconfig $1 $2 X/sbin/route delete default END-of-sldown.sh echo x - slip.sh sed 's/^X//' >slip.sh << 'END-of-slip.sh' X#!/bin/sh Xstartslip -b 57600 -U ./slup.sh -D ./sldown.sh \ X -s atd -s atd -s atd \ X -h -t 60 -w 2 -W 20 /dev/cuaa1 END-of-slip.sh echo x - slup.sh sed 's/^X//' >slup.sh << 'END-of-slup.sh' X#!/bin/sh Xmyname= Xgateway= Xnetmask=255.255.255.248 Xtune1="link0 -link2" # force headers compression Xtune2="mtu 296" # for FreeBSD 1.x host X Xcase $LINE in X 0) tune=$tune1;; # 1st phone connected X 1) tune=$tune2;; # 2nd phone connected X *) tune=;; # others Xesac X X/sbin/ifconfig $1 $2 $tune X/sbin/ifconfig $1 inet $myname $gateway netmask $netmask X/sbin/route add default $gateway END-of-slup.sh exit -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 24 00:02:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19201 for hackers-outgoing; Tue, 24 Oct 1995 00:02:01 -0700 Received: from MediaCity.com (root@easy1.mediacity.com [205.216.172.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19188 for ; Tue, 24 Oct 1995 00:01:47 -0700 Received: (from brian@localhost) by MediaCity.com (8.6.11/8.6.9) id AAA13307 for hackers@freebsd.org; Tue, 24 Oct 1995 00:03:39 -0700 From: Brian Litzinger Message-Id: <199510240703.AAA13307@MediaCity.com> Subject: linux emul is go! To: hackers@freebsd.org Date: Tue, 24 Oct 1995 00:03:39 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 467 Sender: owner-hackers@freebsd.org Precedence: bulk Apparently, one has to have exactly the "right" linux libs to get things to work. Amancio was nice enough to make his available. Wingz runs great now, doom pukes after 5 to 10 seconds, but I figure it's my .wad file. -- Brian Litzinger | | brian@mediacity.com | This space intentionally left blank | http://www.mpress.com | | From owner-freebsd-hackers Tue Oct 24 00:47:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA23037 for hackers-outgoing; Tue, 24 Oct 1995 00:47:55 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA23026 for ; Tue, 24 Oct 1995 00:47:50 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA03491; Tue, 24 Oct 1995 17:39:03 +1000 Date: Tue, 24 Oct 1995 17:39:03 +1000 From: Bruce Evans Message-Id: <199510240739.RAA03491@godzilla.zeta.org.au> To: swallace@ece.uci.edu, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> read(struct proc *p, void *v, int retval[]) >> { >> struct read_args /* { >> int fd; >> char *buf; >> u_int nbyte; >> } */ *uap = v; >> int fd = SCARG(uap, fd); >> char *buf = SCARG(uap, buf); >> u_int nbyte = SCARG(uap, nbyte); >> >> ... >> } >> >> That way we don't have SCARG all over the place, and this would >> prepare us for your static function idea. >Seeing this on -hackers, I'd like to have someone back up and explain >"the static function idea", static inline int read(fd, buf, nbytes) int fd; void *buf; size_t nbytes; ssize_t *retval; { /* * Same as for the current read(), except we don't have to grope * unportably in *uap for the args store the retval in an * incompatible type. */ } /* Machine generated - do not edit. */ int freebsd_syscall_entry_read(p, args, retval) struct proc *p; void *args; int *retval; { int fd; void *buf; size_t nbytes; ssize_t nread; int res; fd = machine_dependent_code_to_convert_fd_for_read(args); buf = machine_dependent_code_to_convert_buf_for_read(args); nbytes = machine_dependent_code_to_convert_nbytes_for_read(args); res = read(fd, buf, nbytes, &nread); machine_dependent_code_to_convert_retval_for_read(args, nread); return (res); } >since it seems likely that an alternate >approact to the idea might be more fruitful than rewriting the system >call interface such that we have to hack tables all over hell for >no real gain. This seems unlikely :-). The main disadvantage of the above is that read() would actually have to be non-static inline so that it can be called from emulators. E.g., foo_ossyscall_entry_read() might have different machine-generated machine-dependent code and it's much better for it to convert from that to (int fd, void *buf, size_t nbytes, ssize_t *retval) and call read() than it is to convert to the machine-dependent freebsd args array and call bsd_syscall_entry_read(). Thus read() would be duplicated at least twice (once inline for fast Freebsd syscalls, once extern for slower foo_os syscalls). All this assumes that the args are in a struct. In general, at the beginning of a syscall, some are in registers and some are in user memory. foo_os_syscall() currently has to copy them to args struct. It might be better to delay the copying to the machine-generated foo_os_syscall_entry_xxx() functions to reduce the amount of copying to the wrong places and to support messy ABI's. >> > which passes the args correctly (as void *). Then we need to handle >> > varargs functions and struct padding better. I think all the details >> > can be hidden in machine-generated functions so that the args structs >> > and verbose macros to reference them don't have to appear in the core >> > sources. >I have macros that divorce K&R and ANSI vararg behaviour from the code >itself (I use them for various things myself). Is this what we are >trying to accomplish? No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the ABI. The args for them have to be copied from different places depending on codes in the early args. syscall() currently assumes that the args are on the stack in user space and copies more args than are necessary and sometimes more than are officially supplied. Varargs for syscall xxx should handled by fetching them from the appropriate place in foo_os_syscall_entry_xxx() and passing them in the normal varargs way to xxx(). > > semsys() and shmsys() syscall interfaces are BAD because they > > multiplex several syscalls that have different types of args. > > There was no reason to duplicate this sysv braindamage but now > > we're stuck with it. NetBSD has reimplemented the syscalls properly > > as separate syscalls #220-231. > > I agree. This is yucky! No, this is good -- system calls are a scarce resource and should be consumed conservatively. What's the problem you have with anonymous argument vectors using subfunction codes? No, this (not syscalls #220-231) is yucky. Multiplexing syscalls takes more code to handle even incorrectly like it does now. Non-multiplexed syscalls take one entry in sysent[] and a function to handle them; multiplexed ones require less entries in sysent[] and an extra function to demultiplex them. The demultiplexing function can be simple and unportable like the current ones or complicated and portable or machine-generated. In general it has to have code like freebsd_syscall_entry_read() for each of the variants. > We need a better way to handle these syscall subcodes (as SYSV calls 'em). I guess I don't really understand why these are a problem, unless you are trying to do something silly, like prototype them. They are a problem because they give more special cases to write code for. Bruce From owner-freebsd-hackers Tue Oct 24 01:00:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA24218 for hackers-outgoing; Tue, 24 Oct 1995 01:00:03 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA24181 for ; Tue, 24 Oct 1995 00:59:58 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA04475; Tue, 24 Oct 1995 17:55:21 +1000 Date: Tue, 24 Oct 1995 17:55:21 +1000 From: Bruce Evans Message-Id: <199510240755.RAA04475@godzilla.zeta.org.au> To: imp@village.org, roberto@keltia.freenix.fr Subject: Re: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) Cc: freebsd-hackers@FreeBSD.ORG, peter@haywire.dialix.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >Our current patch won't work in a pre-4.4BSD system (because of fwopen and >friends that are only on FreeBSD 2.x). For 1.1.5.1 systems, you should try fwopen() has been in FreeBSD since prehistoric times. It is a fundamental part of the stdio implementation that i/o is done through functions that happen to be read/write in the usual case. Bruce From owner-freebsd-hackers Tue Oct 24 01:48:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA29313 for hackers-outgoing; Tue, 24 Oct 1995 01:48:48 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA29304 for ; Tue, 24 Oct 1995 01:48:39 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA06640; Tue, 24 Oct 1995 18:43:30 +1000 Date: Tue, 24 Oct 1995 18:43:30 +1000 From: Bruce Evans Message-Id: <199510240843.SAA06640@godzilla.zeta.org.au> To: dennis@etinc.com, terry@lambert.org Subject: Re: Bragging rights.. Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> I really can't believe you guys are bragging about the widespread >> utilization of >> souped-up async. You still don't get the fact that you're losing several >> hundred dollars >> worth of machine (which brings the cost in-line with sync) to save a few >> hundred on >> cards for a less-efficient solution. How much less efficient? For logins, even a local ethernet is only a few times more efficient than 115200 bps async through a 16450. This is mostly because the pty implementation is poor. Actual measurements: $ # Throughput: $ sh -c "od /kernel | head -10000 | wc" 649244 $login-through-sio0 time sh -c "od /kernel | head -10000" ... 57.51 8.04 2.07 $ expr 64924400 / 5751 11289 # bytes/sec $login-through-ethernet time sh -c "od /kernel | head -10000" 17.49 real 6.61 user 2.17 sys $ expr 64924400 / 1749 37120 # bytes/second $ # Ethernet is only 3 times faster than async serial :-(. $ # Server is 486DX/33 $ # `count' is a cpu hog process that does nothing atoi(argv[1]) times $idle-server time count 50000000 7.71 real 7.61 user 0.03 sys $ # Client is 486DX2/66 $idle-client time count 100000000 7.58 real 7.55 user 0.91 sys $ # Server's UART is 16450. $server-writing-infinite-od-output-to-sio0 time count 50000000 11.08 real 8.90 user 0.03 sys $ expr \( 1108 - 771 \) \* 1000 / 1108 304 # overhead 30.4% $ # Other measurements show that serial write overhead on this system is 19.5% $ # Client's UART is 16550. $client-reading-infinite-od-output-from-sio0 time count 100000000 8.79 real 7.88 user 0.03 sys $ expr \( 879 - 758 \) \* 1000 / 879 137 # overhead 13.7% $ # Other measurements show that serial read overhead on this system is 6.3% $ # Server's ethernet is WD8013EBT. $server-writing-infinite-od-output-to-ethernet time count 50000000 17.39 real 7.60 user 0.03 sys $ expr \( 1739 - 771 \) \* 1000 / 1108 556 # overhead 55.6% $ expr 556 \* 11289 / 37120 \* 100 / 304 55 # relative ethernet overhead is 55% of 16450 overhead :-(. $ # Client's ethernet is WD8013EBT. $client-reading-infinite-od-output-from-ethernet time count 100000000 8.83 real 7.45 user 0.03 sys $ expr \( 883 - 758 \) \* 1000 / 883 141 # overhead 14.1% $ expr 141 \* 11289 / 37120 \* 100 / 137 30 # relative ethernet overhead is 30% of 16550 overhead :-(. Bruce From owner-freebsd-hackers Tue Oct 24 01:56:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA00337 for hackers-outgoing; Tue, 24 Oct 1995 01:56:23 -0700 Received: from fgate.flevel.co.uk (fgate.flevel.co.uk [194.6.101.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA00327 for ; Tue, 24 Oct 1995 01:56:15 -0700 Received: (from freebsd@localhost) by fgate.flevel.co.uk (8.6.11/8.6.9) id JAA00991; Tue, 24 Oct 1995 09:58:57 +0100 Date: Tue, 24 Oct 1995 09:58:57 +0100 (BST) From: freebsd To: hackers@freebsd.org Subject: Help URGENT Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="VAA06864.814481166/fgate.flevel.co.uk" Content-ID: Sender: owner-hackers@freebsd.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --VAA06864.814481166/fgate.flevel.co.uk Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: --VAA06864.814481166/fgate.flevel.co.uk Content-Type: MESSAGE/RFC822 Content-ID: Return-Path: freebsd Received: (from freebsd@localhost) by fgate.flevel.co.uk (8.6.11/8.6.9) id VAA06862; Mon, 23 Oct 1995 21:45:54 +0100 Date: Mon, 23 Oct 1995 21:45:54 +0100 (BST) From: freebsd To: hackers@freebsd.ord cc: david@flevel.co.uk Subject: Help URGENT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII HELP please Cc: david@flevel.co.uk Hey we have a freebsd bootable which is refusing to boot :-( It is hanging just after attaching devices to the bpf. System config SCSI Adaptec 2940 This boot drive did boot OK but suddenly appears to have stopped booting. Are there any diagnostioc tools we can use to check the system out? Config = DX4 100 AMD with sirius logic graphics card 16M david S. --VAA06864.814481166/fgate.flevel.co.uk-- From owner-freebsd-hackers Tue Oct 24 02:29:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01630 for hackers-outgoing; Tue, 24 Oct 1995 02:29:45 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA01580 for ; Tue, 24 Oct 1995 02:29:13 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA29519; Tue, 24 Oct 1995 10:27:04 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA16201; Tue, 24 Oct 1995 10:27:04 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id KAA16673; Tue, 24 Oct 1995 10:11:51 +0100 From: J Wunsch Message-Id: <199510240911.KAA16673@uriah.heep.sax.de> Subject: Re: HELP URGENT To: freebsd@fgate.flevel.co.uk (freebsd) Date: Tue, 24 Oct 1995 10:11:51 +0100 (MET) Cc: hackers@freebsd.org, david@flevel.co.uk Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "freebsd" at Oct 23, 95 10:00:51 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 519 Sender: owner-hackers@freebsd.org Precedence: bulk As freebsd wrote: > > We have a freebsd bootable hard disk that now refuses to boot. > > It hangs immediately after attaching bpf This is way too few input. It's most likely that you've got troubles with specifying the disk geometry, but a zillion other things happen right after the "attaching bpf..." message, so please tell us more about your setup. -- 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 Oct 24 02:30:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01705 for hackers-outgoing; Tue, 24 Oct 1995 02:30:38 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA01556 for ; Tue, 24 Oct 1995 02:28:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA29503 for ; Tue, 24 Oct 1995 10:27:00 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA16198 for freebsd-hackers@FreeBSD.ORG; Tue, 24 Oct 1995 10:26:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id KAA16485 for freebsd-hackers@FreeBSD.ORG; Tue, 24 Oct 1995 10:03:31 +0100 From: J Wunsch Message-Id: <199510240903.KAA16485@uriah.heep.sax.de> Subject: Re: (fwd) CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround) To: freebsd-hackers@FreeBSD.ORG Date: Tue, 24 Oct 1995 10:03:31 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510232257.QAA19117@rover.village.org> from "Warner Losh" at Oct 23, 95 04:57:41 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 231 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk As Warner Losh wrote: > > Does somebody have just this patch? Sent. -- 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 Oct 24 02:34:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01858 for hackers-outgoing; Tue, 24 Oct 1995 02:34:09 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA01844 for ; Tue, 24 Oct 1995 02:33:58 -0700 Received: by Sysiphos id AA20734 (5.67b/IDA-1.5 for hackers@freebsd.org); Tue, 24 Oct 1995 10:32:35 +0100 Message-Id: <199510240932.AA20734@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 24 Oct 1995 10:32:34 +0100 In-Reply-To: guido@gvr.win.tue.nl (Guido van Rooij) "clk interrupts > 150/sec???" (Oct 23, 22:59) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: guido@gvr.win.tue.nl (Guido van Rooij) Subject: Re: clk interrupts > 150/sec??? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk On Oct 23, 22:59, Guido van Rooij wrote: } Subject: clk interrupts > 150/sec??? } How can this be explained: } } [~] guido@iaehv> vmstat -i } interrupt total rate } clk0 irq0 3884051 156 } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } rtc0 irq8 3173264 128 } fdc0 irq6 1 0 } sc0 irq1 2462 0 } ed0 irq5 3667585 147 } } I always thought clk0 should have a rate of 100/sec. Well, you got PCI devices in your system ? Don't ask for details :-) Just substract 100 from clk0 to find out the accumulated rate of PCI interrupts ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-hackers Tue Oct 24 04:16:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA05719 for hackers-outgoing; Tue, 24 Oct 1995 04:16:04 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA05713 for ; Tue, 24 Oct 1995 04:16:02 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t7hKq-0003xvC; Tue, 24 Oct 95 04:16 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id MAA02036 for ; Tue, 24 Oct 1995 12:16:00 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: Laptop with 800x600 colour LCD found! Date: Tue, 24 Oct 1995 12:16:00 +0100 Message-ID: <2034.814533360@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk Gateway2000's new Solo has it, at a considerable price, staring at $5000 :-( -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Just that: dried leaves in boiling water ? From owner-freebsd-hackers Tue Oct 24 05:53:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA09415 for hackers-outgoing; Tue, 24 Oct 1995 05:53:46 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA09409 for ; Tue, 24 Oct 1995 05:53:41 -0700 Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQzmvj28122; Tue, 24 Oct 1995 08:53:34 -0400 (EDT) Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Tue, 24 Oct 1995 08:53:35 -0400 Received: by crocodil.monolit.kiev.ua; Tue, 24 Oct 95 14:50:22 +0200 Received: from dog.farm.org (farm-cs.farm.org [193.124.48.230]) by clipper.cs.kiev.ua (8.6.4) with ESMTP id OAA06290 for ; Tue, 24 Oct 1995 14:47:31 +0200 Received: (from dk@localhost) by dog.farm.org (MK54/dk1) id OAA16789 for freebsd-hackers@freebsd.org; Tue, 24 Oct 1995 14:48:23 +0200 Date: Tue, 24 Oct 1995 14:48:23 +0200 From: Dmitry Kohmanyuk Message-Id: <199510241248.OAA16789@dog.farm.org> To: freebsd-hackers@freebsd.org Subject: patch for PTYs not freed? (2.0.5-R) Newsgroups: cs-monolit.gated.lists.freebsd.hackers Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org Precedence: bulk I am gotting that same bug which bites me: under screen, create virtual console (using PTY), run telnet/rlogin under it, kill the shell process (telnet not killed), re-create virtual console (same PTY used), alas, I got input from shell/old telnet process intermixed. secutity hole as well. I remember discussion about this some time ago; was anything like a patch fixing the problem issued? btw, are bug reports / solutions archived somewhere? From owner-freebsd-hackers Tue Oct 24 06:00:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA09917 for hackers-outgoing; Tue, 24 Oct 1995 06:00:47 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA09908 ; Tue, 24 Oct 1995 06:00:37 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id FAA11669; Tue, 24 Oct 1995 05:57:59 -0700 To: "Serge A. Babkin" cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org Subject: Re: startslip isn't just broken - it's EVIL! In-reply-to: Your message of "Tue, 24 Oct 1995 09:53:28 +0500." <199510240453.JAA03948@hq.icb.chel.su> Date: Tue, 24 Oct 1995 05:57:59 -0700 Message-ID: <11667.814539479@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > > > > Guys! Use slattach and chat, and save yourselves the stress 8) > > > > I've never managed to get that combo to work! Chat just dies > > immediately.. :-( > > I got it working under 2.0. There were some strange problems but in > common it worked. I remember that chat does not understand the dial-up > string in the command line, it needs a file with it. No, that's not the problem here - I have my chat script in a file and that very same chat script works just fine with chat if I *don't run it from slattach*. When run from slattach, chat blows up when it first tries to talk to the port. I don't know what's wrong, but slattach clearly isn't setting up things correctly before invoking the external script. I tried for quite a few days to get this to work and finally gave up in disgust. Jordan From owner-freebsd-hackers Tue Oct 24 06:15:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10758 for hackers-outgoing; Tue, 24 Oct 1995 06:15:42 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA10753 for ; Tue, 24 Oct 1995 06:15:39 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA11880; Tue, 24 Oct 1995 06:15:19 -0700 To: Brian Litzinger cc: hackers@freebsd.org Subject: Re: linux emul is go! In-reply-to: Your message of "Tue, 24 Oct 1995 00:03:39 PDT." <199510240703.AAA13307@MediaCity.com> Date: Tue, 24 Oct 1995 06:15:19 -0700 Message-ID: <11877.814540519@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Apparently, one has to have exactly the "right" linux libs to get > things to work. Amancio was nice enough to make his available. We really need to make this a "port" I think. Or at the very least we need to stick them on the CD. :) Amancio? Somebody? Might it be possible for you to get everything one needs in one convenient tarfile that we can distribute? I'm sure that if *Brian* had troubles with this, our average user will simply throw up his hands and claim that our linux emulation doesn't work for spit! :-( Jordan From owner-freebsd-hackers Tue Oct 24 06:22:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA11142 for hackers-outgoing; Tue, 24 Oct 1995 06:22:34 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA11137 for ; Tue, 24 Oct 1995 06:22:24 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id GAA05988; Tue, 24 Oct 1995 06:22:20 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id GAA27405; Tue, 24 Oct 1995 06:19:30 -0700 Message-Id: <199510241319.GAA27405@corbin.Root.COM> To: dk+@ua.net cc: freebsd-hackers@freebsd.org Subject: Re: patch for PTYs not freed? (2.0.5-R) In-reply-to: Your message of "Tue, 24 Oct 95 14:48:23 +0200." <199510241248.OAA16789@dog.farm.org> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 06:19:12 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >I am gotting that same bug which bites me: > >under screen, create virtual console (using PTY), run telnet/rlogin under it, >kill the shell process (telnet not killed), re-create virtual console >(same PTY used), alas, I got input from shell/old telnet process intermixed. > >secutity hole as well. > >I remember discussion about this some time ago; was anything like a patch >fixing the problem issued? The problem has been fixed in both -current and -stable. Index: tty_pty.c =================================================================== RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v retrieving revision 1.20 diff -c -r1.20 tty_pty.c *** 1.20 1995/09/08 11:08:38 --- tty_pty.c 1995/09/21 01:42:42 *************** *** 31,37 **** * SUCH DAMAGE. * * @(#)tty_pty.c 8.2 (Berkeley) 9/23/93 ! * $Id: tty_pty.c,v 1.20 1995/09/08 11:08:38 bde Exp $ */ /* --- 31,37 ---- * SUCH DAMAGE. * * @(#)tty_pty.c 8.2 (Berkeley) 9/23/93 ! * $Id: tty_pty.c,v 1.21 1995/09/19 12:26:47 bde Exp $ */ /* *************** *** 322,328 **** } tp->t_oproc = 0; /* mark closed */ - tp->t_session = 0; return (0); } --- 322,327 ---- From owner-freebsd-hackers Tue Oct 24 06:45:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA12532 for hackers-outgoing; Tue, 24 Oct 1995 06:45:37 -0700 Received: from core.apana.org.au (core.apana.org.au [203.12.236.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA12515 for ; Tue, 24 Oct 1995 06:45:27 -0700 Received: from loose.apana.org.au (root@loose.apana.org.au [202.12.87.26]) by core.apana.org.au (8.6.12/8.6.9) with ESMTP id AAA04715 for ; Wed, 25 Oct 1995 00:44:40 +1100 Received: (from uucp@localhost) by loose.apana.org.au (8.7.1/8.7.1) with UUCP id AAA11991 for apana-lists-os-freebsd-hackers@apana.org.au; Wed, 25 Oct 1995 00:36:48 +1100 Received: (from mjb@localhost) by siva.apana.org.au (8.6.11/8.6.12) id KAA00336; Mon, 23 Oct 1995 10:42:04 +1000 To: apana-lists-os-freebsd-hackers@apana.org.au Path: not-for-mail From: mjb@siva.apana.org.au (Marcus Barczak) Newsgroups: apana.lists.os.freebsd.hackers Subject: Re: A quick vote on pthreads PLZ Date: 23 Oct 1995 10:42:02 +1000 Organization: siva Lines: 8 Message-ID: <46eocq$ac@siva.apana.org.au> References: <199510210416.VAA01397@ref.tfs.com> X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: owner-hackers@FreeBSD.org Precedence: bulk julian@ref.tfs.com (Julian Elischer) writes: >A/port/package >or >B/new base part of the system? I vote B From owner-freebsd-hackers Tue Oct 24 06:57:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13076 for hackers-outgoing; Tue, 24 Oct 1995 06:57:21 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13070 for ; Tue, 24 Oct 1995 06:57:18 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA12218; Tue, 24 Oct 1995 06:55:32 -0700 To: Joe Greco cc: sycheng@cis.ufl.edu, hackers@freebsd.org Subject: Re: Cannot install in one big / In-reply-to: Your message of "Mon, 23 Oct 1995 20:28:56 CDT." <199510240128.UAA02723@brasil.moneng.mei.com> Date: Tue, 24 Oct 1995 06:55:32 -0700 Message-ID: <12216.814542932@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Um, sysinstall barks that there is no /usr partition, like it used to, but > then immediately freaks and claims it cannot continue. Sorry, I don't have > the exact dialog box it came back with. I found and fixed it, thanks guys! Jordan From owner-freebsd-hackers Tue Oct 24 07:03:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13338 for hackers-outgoing; Tue, 24 Oct 1995 07:03:11 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA13296 for ; Tue, 24 Oct 1995 07:01:44 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id JAA16774; Tue, 24 Oct 1995 09:01:40 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id JAA04121; Tue, 24 Oct 1995 09:26:49 -0500 Message-Id: <199510241426.JAA04121@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: "Jordan K. Hubbard" cc: Brian Litzinger , hackers@freebsd.org Subject: Re: linux emul is go! In-reply-to: Your message of "Tue, 24 Oct 1995 06:15:19 PDT." <11877.814540519@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 09:26:48 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk > > Apparently, one has to have exactly the "right" linux libs to get > > things to work. Amancio was nice enough to make his available. > > We really need to make this a "port" I think. Or at the very least we > need to stick them on the CD. :) Amancio? Somebody? Might it be > possible for you to get everything one needs in one convenient tarfile > that we can distribute? I'm sure that if *Brian* had troubles with > this, our average user will simply throw up his hands and claim that > our linux emulation doesn't work for spit! :-( Ok, I just made a working copy of my linux libs, and a port that needs to be tested. In my home dir on freefall, there are two files, a linux_lib-port.tgz, and the corresponding libraries in a tarball, linux_lib.tar.gz. Put the second in /usr/ports/distfiles, or adjust the MASTER_SITES macro in the makefile. > > Jordan > eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Tue Oct 24 07:09:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13577 for hackers-outgoing; Tue, 24 Oct 1995 07:09:52 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA13565 for ; Tue, 24 Oct 1995 07:09:46 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA25390; Tue, 24 Oct 1995 08:12:03 -0600 Date: Tue, 24 Oct 1995 08:12:03 -0600 From: Nate Williams Message-Id: <199510241412.IAA25390@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-Reply-To: <2034.814533360@critter.tfs.com> References: <2034.814533360@critter.tfs.com> Sender: owner-hackers@freebsd.org Precedence: bulk > Gateway2000's new Solo has it, at a considerable price, staring at $5000 :-( NEC and IBM have both had 800x600 laptops I've mentioned a couple times on the list. I think you can get the NEC for under $5K pretty easily. Nate From owner-freebsd-hackers Tue Oct 24 07:19:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14051 for hackers-outgoing; Tue, 24 Oct 1995 07:19:54 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA14034 for ; Tue, 24 Oct 1995 07:19:47 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t7kCZ-0003ycC; Tue, 24 Oct 95 07:19 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA02197; Tue, 24 Oct 1995 15:19:39 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Nate Williams cc: hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-reply-to: Your message of "Tue, 24 Oct 1995 08:12:03 CST." <199510241412.IAA25390@rocky.sri.MT.net> Date: Tue, 24 Oct 1995 15:19:39 +0100 Message-ID: <2195.814544379@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk > > Gateway2000's new Solo has it, at a considerable price, staring at $5000 :- ( > > NEC and IBM have both had 800x600 laptops I've mentioned a couple times > on the list. I think you can get the NEC for under $5K pretty easily. With a P5/90 ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hackers Tue Oct 24 07:27:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14485 for hackers-outgoing; Tue, 24 Oct 1995 07:27:46 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14445 for ; Tue, 24 Oct 1995 07:26:20 -0700 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id JAA16835; Tue, 24 Oct 1995 09:26:09 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.12) with SMTP id JAA04312; Tue, 24 Oct 1995 09:51:22 -0500 Message-Id: <199510241451.JAA04312@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Brian Litzinger cc: hackers@freebsd.org Subject: Re: linux emul is go! In-reply-to: Your message of "Tue, 24 Oct 1995 00:03:39 PDT." <199510240703.AAA13307@MediaCity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 09:51:22 -0500 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org Precedence: bulk > Apparently, one has to have exactly the "right" linux libs to get > things to work. Amancio was nice enough to make his available. > Nate keyed me in on the secret that the libs and ld.so all need to be ZMAGIC (ttyp2@jake)$ pwd /compat/linux/lib (ttyp2@jake)$ file * ld.so: Linux/i386 demand-paged executable (ZMAGIC) libX11.so.3: symbolic link to libX11.so.3.1.0 libX11.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) libXaw.so.3: symbolic link to libXaw.so.3.1.0 libXaw.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) libXt.so.3: symbolic link to libXt.so.3.1.0 libXt.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) libc.so.4: symbolic link to libc.so.4.5.26 libc.so.4.5.26: Linux/i386 demand-paged executable (ZMAGIC) libgr.so.1: symbolic link to libgr.so.1.3 libgr.so.1.3: Linux/i386 demand-paged executable (ZMAGIC) libm.so.4: symbolic link to libm.so.4.5.26 libm.so.4.5.26: Linux/i386 demand-paged executable (ZMAGIC) The short-term fix is to use ZMAGIC libs, the longer term fix should be to get [QZ]MAGIC libs to work. > Wingz runs great now, doom pukes after 5 to 10 seconds, but I > figure it's my .wad file. > > -- > Brian Litzinger | | > brian@mediacity.com | This space intentionally left blank | > http://www.mpress.com | | > eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Tue Oct 24 07:36:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14850 for hackers-outgoing; Tue, 24 Oct 1995 07:36:09 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14844 for ; Tue, 24 Oct 1995 07:36:04 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id KAA13636; Tue, 24 Oct 1995 10:53:54 -0400 Date: Tue, 24 Oct 1995 10:53:54 -0400 Message-Id: <199510241453.KAA13636@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bruce Evans From: dennis@etinc.com (dennis) Subject: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>> I really can't believe you guys are bragging about the widespread >>> utilization of >>> souped-up async. You still don't get the fact that you're losing several >>> hundred dollars >>> worth of machine (which brings the cost in-line with sync) to save a few >>> hundred on >>> cards for a less-efficient solution. > >How much less efficient? For logins, even a local ethernet is only a few >times more efficient than 115200 bps async through a 16450. This is >mostly because the pty implementation is poor. Your numbers, like unix utilization and timing numbers, are garbage. Set up a controlled test where you know the answer and the numbers won't be close. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Tue Oct 24 07:43:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15634 for hackers-outgoing; Tue, 24 Oct 1995 07:43:42 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15627 ; Tue, 24 Oct 1995 07:43:38 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id HAA23772; Tue, 24 Oct 1995 07:40:18 -0700 Message-Id: <199510241440.HAA23772@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: "Serge A. Babkin" , msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org Subject: Re: startslip isn't just broken - it's EVIL! In-reply-to: Your message of "Tue, 24 Oct 1995 05:57:59 PDT." <11667.814539479@time.cdrom.com> Date: Tue, 24 Oct 1995 07:40:18 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >> > >> > > Guys! Use slattach and chat, and save yourselves the stress 8) >> > >> > I've never managed to get that combo to work! Chat just dies >> > immediately.. :-( >> >> I got it working under 2.0. There were some strange problems but in >> common it worked. I remember that chat does not understand the dial-up >> string in the command line, it needs a file with it. > >No, that's not the problem here - I have my chat script in a file and >that very same chat script works just fine with chat if I *don't run >it from slattach*. When run from slattach, chat blows up when it >first tries to talk to the port. I don't know what's wrong, but >slattach clearly isn't setting up things correctly before invoking the >external script. I tried for quite a few days to get this to work >and finally gave up in disgust. > > Jordan Sounds like the same problem I was having getting expect to work. I really wish it would since you write *one*, really intelligent expect script that could login to almost any terminal server and fire up slip. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Tue Oct 24 07:43:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15648 for hackers-outgoing; Tue, 24 Oct 1995 07:43:45 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15633 for ; Tue, 24 Oct 1995 07:43:41 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA25465; Tue, 24 Oct 1995 08:45:59 -0600 Date: Tue, 24 Oct 1995 08:45:59 -0600 From: Nate Williams Message-Id: <199510241445.IAA25465@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: Nate Williams , hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-Reply-To: <2195.814544379@critter.tfs.com> References: <199510241412.IAA25390@rocky.sri.MT.net> <2195.814544379@critter.tfs.com> Sender: owner-hackers@freebsd.org Precedence: bulk [ 800x600 display laptops ] > > > Gateway2000's new Solo has it. > > > > NEC and IBM have both had 800x600 laptops I've mentioned a couple times > > on the list. I think you can get the NEC for under $5K pretty easily. > > With a P5/90 ? A P5/75, but I must warn you that at least with the NEC you need to pull the floppy out and put in the second battery to get any decent battery life on those things, and that's using Lithium Ion batteries. I suspect the P90 is going to have an even worse battery life. Nate From owner-freebsd-hackers Tue Oct 24 07:50:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15969 for hackers-outgoing; Tue, 24 Oct 1995 07:50:10 -0700 Received: from sunny.bog.msu.su (dima@sunny.bog.msu.su [158.250.20.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15951 for ; Tue, 24 Oct 1995 07:49:59 -0700 Received: (from dima@localhost) by sunny.bog.msu.su (8.6.12/8.6.12) id RAA13572; Tue, 24 Oct 1995 17:48:52 +0300 Date: Tue, 24 Oct 1995 17:48:51 +0300 (????) From: Dmitry Khrustalev To: hackers@freefall.freebsd.org cc: bde@zeta.org.au Subject: Re: clk interrupts > 150/sec??? In-Reply-To: <199510240642.XAA17810@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk > > >How can this be explained: > > >[~] guido@iaehv> vmstat -i > >interrupt total rate > >clk0 irq0 3884051 156 > >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >rtc0 irq8 3173264 128 > >fdc0 irq6 1 0 > >sc0 irq1 2462 0 > >ed0 irq5 3667585 147 > > >I always thought clk0 should have a rate of 100/sec. > > Perhaps you used pcaudio. If it was open all the time > then the clk0 rate should be about 16000. > I see this also. Pci (ncr) interrupts get accounted to irq0 for some reason. This causes very weird problems, like gated thinking time is going backwards. -Dima From owner-freebsd-hackers Tue Oct 24 08:30:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA17695 for hackers-outgoing; Tue, 24 Oct 1995 08:30:10 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA17689 ; Tue, 24 Oct 1995 08:30:07 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id IAA17038; Tue, 24 Oct 1995 08:28:08 -0700 To: "Justin T. Gibbs" cc: "Serge A. Babkin" , msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org Subject: Re: startslip isn't just broken - it's EVIL! In-reply-to: Your message of "Tue, 24 Oct 1995 07:40:18 PDT." <199510241440.HAA23772@aslan.cdrom.com> Date: Tue, 24 Oct 1995 08:28:06 -0700 Message-ID: <17032.814548486@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Sounds like the same problem I was having getting expect to work. I really > wish it would since you write *one*, really intelligent expect script that > could login to almost any terminal server and fire up slip. Yeah, slattach is evil too.. I think what really really needs to happen is for us to *merge* the interface for SLIP and PPP outgoing connections since, except for the line discipline used (and the dynamic negotation stuff in ppp), it's kinda the same problem. If we had a decent dialer interface (the BSDI one isn't bad!) then we could treat the SLIP & PPP stuff as a common front-end with differing back ends once the line was opened. Jordan From owner-freebsd-hackers Tue Oct 24 10:36:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA22882 for hackers-outgoing; Tue, 24 Oct 1995 10:36:58 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA22873 for ; Tue, 24 Oct 1995 10:36:56 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id KAA06563; Tue, 24 Oct 1995 10:36:35 -0700 Message-Id: <199510241736.KAA06563@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Poul-Henning Kamp cc: Nate Williams , hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-reply-to: Your message of "Tue, 24 Oct 1995 15:19:39 BST." <2195.814544379@critter.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 10:36:34 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Not that it matters but I think is IBM which has a new laptop with 1024x768 resolution. I will see if I can dig up where I read this. Amancio >>> Poul-Henning Kamp said: > > > Gateway2000's new Solo has it, at a considerable price, staring at $5000 :- > ( > > > > NEC and IBM have both had 800x600 laptops I've mentioned a couple times > > on the list. I think you can get the NEC for under $5K pretty easily. > > With a P5/90 ? > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, I nc. > Future will arrive by its own means, progress not so. > From owner-freebsd-hackers Tue Oct 24 10:38:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA22940 for hackers-outgoing; Tue, 24 Oct 1995 10:38:06 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA22935 for ; Tue, 24 Oct 1995 10:38:03 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA25833; Tue, 24 Oct 1995 11:40:17 -0600 Date: Tue, 24 Oct 1995 11:40:17 -0600 From: Nate Williams Message-Id: <199510241740.LAA25833@rocky.sri.MT.net> To: "Amancio Hasty Jr." Cc: Poul-Henning Kamp , Nate Williams , hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-Reply-To: <199510241736.KAA06563@rah.star-gate.com> References: <2195.814544379@critter.tfs.com> <199510241736.KAA06563@rah.star-gate.com> Sender: owner-hackers@freebsd.org Precedence: bulk > Not that it matters but I think is IBM which has a new laptop with > 1024x768 resolution. I will see if I can dig up where I read this. I'm on the IBM Web site and it's not there. They just announced a new ThinkPad with 800x600 on a 12.4" Active matrix screen though which is very nice. Nate From owner-freebsd-hackers Tue Oct 24 11:06:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24083 for hackers-outgoing; Tue, 24 Oct 1995 11:06:51 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24075 for ; Tue, 24 Oct 1995 11:06:47 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA13732; Tue, 24 Oct 1995 10:55:46 -0700 From: Terry Lambert Message-Id: <199510241755.KAA13732@phaeton.artisoft.com> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs To: nate@rocky.sri.MT.net (Nate Williams) Date: Tue, 24 Oct 1995 10:55:46 -0700 (MST) Cc: ache@astral.msk.su, nate@rocky.sri.MT.net, ache@freefall.freebsd.org, freebsd-hackers@FreeBSD.ORG, gibbs@freefall.freebsd.org In-Reply-To: <199510240416.WAA24786@rocky.sri.MT.net> from "Nate Williams" at Oct 23, 95 10:16:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 520 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > >I agree, and it appears that David and John P. are also in agreement. > > > > Well, I and Terry in agreement :-) > > No, Terry and you are in disagreement. Read again what he wrote. > Because FreeBSD's handling of the code is broken, then your fix is also > broken. Nate's right: I don't agree with you unless the compilation time path has been remembered and it has not. 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 Oct 24 11:10:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24322 for hackers-outgoing; Tue, 24 Oct 1995 11:10:03 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24312 for ; Tue, 24 Oct 1995 11:10:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13749; Tue, 24 Oct 1995 11:01:31 -0700 From: Terry Lambert Message-Id: <199510241801.LAA13749@phaeton.artisoft.com> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs To: davidg@root.com Date: Tue, 24 Oct 1995 11:01:31 -0700 (MST) Cc: ache@freefall.freebsd.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510240516.WAA00371@corbin.Root.COM> from "David Greenman" at Oct 23, 95 10:16:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 875 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >>I don't think you're 'script' is at all convincing, at least not to me. > >>In any case it appears the consensus is to remove this feature from use, > >>which I also agree would be a good thing. > > > >I vote for complete removing LD_NOSTD_PATH too. > > Well then, we are in complete unanimous agreement on this issue. John P. > has already indicated that he'll be removing it from ld.so. Why? This has no effect. It is ignored by startup because the loader does not respect it: the cache path is still checked. A complete fix on the order of the SunOS security update would require that the image contain the link time library path. As it currently sits, it's not harmful, and it represents a direction that is desirable. 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 Oct 24 11:13:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24514 for hackers-outgoing; Tue, 24 Oct 1995 11:13:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24502 for ; Tue, 24 Oct 1995 11:13:20 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13761; Tue, 24 Oct 1995 11:04:43 -0700 From: Terry Lambert Message-Id: <199510241804.LAA13761@phaeton.artisoft.com> Subject: Re: Laptop with 800x600 colour LCD found! To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Tue, 24 Oct 1995 11:04:43 -0700 (MST) Cc: phk@critter.tfs.com, nate@rocky.sri.MT.net, hackers@FreeBSD.ORG In-Reply-To: <199510241736.KAA06563@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 24, 95 10: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 Content-Length: 341 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Not that it matters but I think is IBM which has a new laptop with > 1024x768 resolution. I will see if I can dig up where I read this. DO! The ability to play Nettrek with a cellular modem! AH!!! 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 Oct 24 11:16:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24676 for hackers-outgoing; Tue, 24 Oct 1995 11:16:42 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24669 for ; Tue, 24 Oct 1995 11:16:38 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA25950; Tue, 24 Oct 1995 12:18:12 -0600 Date: Tue, 24 Oct 1995 12:18:12 -0600 From: Nate Williams Message-Id: <199510241818.MAA25950@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: Nate Williams , hackers@freebsd.org Subject: Re: SLIP with chat/slattach (was Re: startslip ...) In-Reply-To: <402.814558257@time.cdrom.com> References: <199510240501.XAA24885@rocky.sri.MT.net> <402.814558257@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > > OK, here is a quick README along with some files that may make your life > > easier. If someone feels it's worth adding to the FAQ, by all means > > feel free. > > Doesn't work.. :-( > > Like I said, slattach and ppp simply don't get along in 2.1.. Hmm, that's news to me, since it's currently running on my box with *NO* problems. trout:/home/sup % uname -a FreeBSD trout.sri.MT.net 2.1.0-951020-SNAP FreeBSD 2.1.0-951020-SNAP #0: Mon Oct 23 22:30:37 MDT 1995 root@trout:/usr/src/sys/compile/TROUT i386 trout:/home/sup % uptime 12:16PM up 13:05, 3 users, load averages: 1.09, 1.18, 1.16 > And so on.. Grrrrrrrr! That's *really* strange. I'm using an external modem connected to cuaa1 which is a serial port with a 16550AF. I don't know what else to tell you. I'm also running a getty on /dev/ttyd1 for occasions on when I kill the link and want to login and re-start it, but I don't think that would make a difference. I haven't recompiled anything on my box and it works, although I'm in the process or re-building things as we speak to install directly from source. Nate From owner-freebsd-hackers Tue Oct 24 11:28:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA25160 for hackers-outgoing; Tue, 24 Oct 1995 11:28:05 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA25152 for ; Tue, 24 Oct 1995 11:28:02 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA27927; Wed, 25 Oct 1995 04:23:48 +1000 Date: Wed, 25 Oct 1995 04:23:48 +1000 From: Bruce Evans Message-Id: <199510241823.EAA27927@godzilla.zeta.org.au> To: bde@zeta.org.au, dennis@etinc.com Subject: Re: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>How much less efficient? For logins, even a local ethernet is only a few >>times more efficient than 115200 bps async through a 16450. This is >>mostly because the pty implementation is poor. >Your numbers, like unix utilization >and timing numbers, are garbage. Set up a controlled test where you know the >answer >and the numbers won't be close. FreeBSD isn't unix. The sum of the user, system and interrupt times is accurate to within 5usec * (number of context switches) under FreeBSD, but since the interrupt time is not available through any syscall and my tests involve a lot of interrupts, I just used the real time, which is accurate to about 1 part in 1000 here. My tests were only accurate to within about 10%. I knew that the numbers would be close because I knew how bad the pty implementation is and picked tests involving ptys to reduce the advantage of ethernet. Ethernet is less than 10 times as efficient as async serial on the test systems anyway (ethernet overhead on the DX2/66 is about 70% for one 10Mb/s channel; async serial overhead per 115200 bps channel is about 6.3%). Bruce From owner-freebsd-hackers Tue Oct 24 11:41:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA25642 for hackers-outgoing; Tue, 24 Oct 1995 11:41:37 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA25629 for ; Tue, 24 Oct 1995 11:41:32 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id OAA00819; Tue, 24 Oct 1995 14:44:10 -0400 Date: Tue, 24 Oct 1995 14:44:10 -0400 Message-Id: <199510241844.OAA00819@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bruce Evans From: dennis@etinc.com (dennis) Subject: Re: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>>How much less efficient? For logins, even a local ethernet is only a few >>>times more efficient than 115200 bps async through a 16450. This is >>>mostly because the pty implementation is poor. > >>Your numbers, like unix utilization >>and timing numbers, are garbage. Set up a controlled test where you know the >>answer >>and the numbers won't be close. > >FreeBSD isn't unix. The sum of the user, system and interrupt times is >accurate to within 5usec * (number of context switches) under FreeBSD, >but since the interrupt time is not available through any syscall and >my tests involve a lot of interrupts, I just used the real time, which >is accurate to about 1 part in 1000 here. > Its not a real measurement, so you can't use it. Period. Figure out the processing requirement for handling one average frame size of bytes with a 16450 with 8-bit I/O cycles and loads of interrupts, add 20% and compare it to a single interrupt and one 16-bit bus transfer per frame. It doesn't take a rocket scientist to know there's a signficant difference in processing requirements. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Tue Oct 24 11:51:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26190 for hackers-outgoing; Tue, 24 Oct 1995 11:51:43 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26185 for ; Tue, 24 Oct 1995 11:51:42 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id LAA09037; Tue, 24 Oct 1995 11:51:39 -0700 Date: Tue, 24 Oct 1995 11:51:38 -0700 (PDT) From: Jaye Mathisen To: Poul-Henning Kamp cc: Nate Williams , hackers@freebsd.org Subject: Re: Laptop with 800x600 colour LCD found! In-Reply-To: <2195.814544379@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Yes, NEC 4000's come in a variety, from 486/75 to P75 to P90. On Tue, 24 Oct 1995, Poul-Henning Kamp wrote: > > > Gateway2000's new Solo has it, at a considerable price, staring at $5000 :- > ( > > > > NEC and IBM have both had 800x600 laptops I've mentioned a couple times > > on the list. I think you can get the NEC for under $5K pretty easily. > > With a P5/90 ? > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. > Future will arrive by its own means, progress not so. > From owner-freebsd-hackers Tue Oct 24 12:15:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26937 for hackers-outgoing; Tue, 24 Oct 1995 12:15:48 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26926 for ; Tue, 24 Oct 1995 12:15:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA13880; Tue, 24 Oct 1995 12:06:38 -0700 From: Terry Lambert Message-Id: <199510241906.MAA13880@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Tue, 24 Oct 1995 12:06:38 -0700 (MST) Cc: swallace@ece.uci.edu, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org In-Reply-To: <199510240739.RAA03491@godzilla.zeta.org.au> from "Bruce Evans" at Oct 24, 95 05:39:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 11822 Sender: owner-hackers@freebsd.org Precedence: bulk > >> That way we don't have SCARG all over the place, and this would > >> prepare us for your static function idea. > > >Seeing this on -hackers, I'd like to have someone back up and explain > >"the static function idea", > > static inline int > read(fd, buf, nbytes) > int fd; > void *buf; > size_t nbytes; > ssize_t *retval; > { > /* > * Same as for the current read(), except we don't have to grope > * unportably in *uap for the args store the retval in an > * incompatible type. > */ > } > > /* Machine generated - do not edit. */ > int > freebsd_syscall_entry_read(p, args, retval) > struct proc *p; > void *args; > int *retval; > { > int fd; > void *buf; > size_t nbytes; > ssize_t nread; > int res; > > fd = machine_dependent_code_to_convert_fd_for_read(args); > buf = machine_dependent_code_to_convert_buf_for_read(args); > nbytes = machine_dependent_code_to_convert_nbytes_for_read(args); > res = read(fd, buf, nbytes, &nread); > machine_dependent_code_to_convert_retval_for_read(args, nread); > return (res); > } > > >since it seems likely that an alternate > >approact to the idea might be more fruitful than rewriting the system > >call interface such that we have to hack tables all over hell for > >no real gain. > > This seems unlikely :-). > > The main disadvantage of the above is that read() would actually have > to be non-static inline so that it can be called from emulators. E.g., > foo_ossyscall_entry_read() might have different machine-generated > machine-dependent code and it's much better for it to convert from that > to (int fd, void *buf, size_t nbytes, ssize_t *retval) and call read() > than it is to convert to the machine-dependent freebsd args array and > call bsd_syscall_entry_read(). Thus read() would be duplicated at least > twice (once inline for fast Freebsd syscalls, once extern for slower > foo_os syscalls). OK. I hate leaving all of the above in for context, but I have to. The disadvantage you cite is false. Internal kernel calls to read do not follow the same rules on inlining. The inlining is to avoid the function call overhead to get to the trap vector. This is, in fact, something that can be done in any case, without a change to the system call interface. The problem seems to be one of understanding trap vector argument decodes. When a system call is made, arguments are pushed on the user stack and then the trap vector is called. There is a necessity to copy the arguments as if they were on the stack down to a kernel space buffer area because of the address space differences. The amount that is copied is determined by an integer count of integers: that is, it is some number 'n' * sizeof(int) bytes that get copied. This is dependent on the arguments pushed on the stack being representable as integer values (we are guaranteed this by the fact that we are calling a non-local function that is not inlined). In any case, the copyin from user to system space in the trap code must occur, since the kernel can not address the process data otherwise. The area where the copyin takes place is a per process work area, and it's a pointer to this that is passed as the argument vector pointer, which assumes packing such that the structure dereference of this data will result in the arguments as referenced from the argument structure. So far, we do not have a use for the change. Now each of the arguments are themselves, potentially, pointers to additional information in call/subcode specific user space structures that must, additionally be copied in (or out to). The potential use for the hack is to get the copyin all out of the way at once with a single verification check, ala Linux system calls. The problem with this idea is that the address space in the user program is then assumed (potentially incorrectly) to be non-discontiguous. While BSD could very well benefit from a single verification, avoiding the mapping issues in copyin/copyout, giving one check instead of two for a reuesd area, the actual benefits of this are fairly small. The biggest benefit would be in the copyinstr area, and there, the algorithm would potentially fail because of indeterminate string length. When we add in the concept of multithreading, it's possible to alter the process address space promiscuously during a long delay operation, such that an area that was viable for a copyout is no longer a viable target. So the benefits are lost. Further, the use of null termination instead of byte count on strings makes the copyinstr() operation extremely onerous. There are only a few locations where the facility is used, and even there, the overhead introduced is largely an issue of bad call interface design. There are two types of strings that get copied in (1) paths and (2) structure arguments (like lkm module but not path names, or NFS server names for NFS mount). In actuality, the structure arguments should be packed into fixed length structure elements and the copyinstr disacarded. The paths can stay, but a seperation of the file system name space from the act of string copying (Linux does this too, though I had to fix a bug in an error path) is a necessary part of the required cleanup for this to happen. Still, we do not benefit from the change. What does it do? What use is the change? In the end, it allows us to alter our argument packing. But the same effect of the optimizer that does that, and destabilizes the structure and stack packing from the historical (and processor efficient) integer norm, also has the effect of (potentiall) using register argument passing at certain optimization levels. This is, of course, crap. It won't work across the trap vector interface for all the registers gcc likes to use. If we are trying for this small an incremental improvement, I suggest spending coding time on getting callee pop working within the kernel code. It would be a much higher gain for less effort. > All this assumes that the args are in a struct. In general, at the > beginning of a syscall, some are in registers and some are in user memory. > foo_os_syscall() currently has to copy them to args struct. It might > be better to delay the copying to the machine-generated > foo_os_syscall_entry_xxx() functions to reduce the amount of copying > to the wrong places and to support messy ABI's. The copying is, in all cases, to the stack, by way of "push". The use of registers for calling in a system call interface is bogus. Removing the function call overhead by inlining the traps is one then, but trying to get rid of stack argument passing to system calls is quite another. This would not be a problem were it not for the prototypes that allowed the compiler to bogusly "optimize" the calls to include register argument passing for system call "functions". The correct way to deal with tis problem is to disable such optimizations, such that each system call becomes a push of the call number and a trap, and can itself be inlined. Probably this requires a #pragma on the compiler's behalf to force the argument push. It's very arguable that the compiler would generate incorrectly window optimized code for inlined system calls at present. Specifically, it would fail to see the need to push the arguments. Even with a workaround that forced the push in the inlined code, the arguments would be incorrectly trated prior to the push, potentitally resulting in pessimal code. > >> > which passes the args correctly (as void *). Then we need to handle > >> > varargs functions and struct padding better. I think all the details > >> > can be hidden in machine-generated functions so that the args structs > >> > and verbose macros to reference them don't have to appear in the core > >> > sources. > > >I have macros that divorce K&R and ANSI vararg behaviour from the code > >itself (I use them for various things myself). Is this what we are > >trying to accomplish? > > No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the > ABI. The args for them have to be copied from different places depending > on codes in the early args. syscall() currently assumes that the args > are on the stack in user space and copies more args than are necessary > and sometimes more than are officially supplied. Varargs for syscall > xxx should handled by fetching them from the appropriate place in > foo_os_syscall_entry_xxx() and passing them in the normal varargs way > to xxx(). This is incorrect. The argument count specified in the systent[] table should result in the correct copyin size. Note that if the size was not validly known in any case, then the amount of stack copied would be mismatched, and some system calls would certainly fail. > > >> > semsys() and shmsys() syscall interfaces are BAD because they > >> > multiplex several syscalls that have different types of args. > >> > There was no reason to duplicate this sysv braindamage but now > >> > we're stuck with it. NetBSD has reimplemented the syscalls properly > >> > as separate syscalls #220-231. > >> > >> I agree. This is yucky! > > > >No, this is good -- system calls are a scarce resource and should be > >consumed conservatively. What's the problem you have with anonymous > >argument vectors using subfunction codes? > > No, this (not syscalls #220-231) is yucky. Multiplexing syscalls > takes more code to handle even incorrectly like it does now. The amount of code is a single computed goto. One might as well argue that locking was "yucky" using this yardstick. But it fails the "yucky" result of varying argument size (it uses a single fixed size structure that does not change). The yardstick is flawed. Depending on the logical grouping of calls, you can easily argue that a compare's worth of overhead is less expensive than a function call's worth, in function preamble/postamble, if nothing else (ignoreing the 3-6 cycles depending on how the call is made). > Non-multiplexed syscalls take one entry in sysent[] and a function > to handle them; multiplexed ones require less entries in sysent[] > and an extra function to demultiplex them. The demultiplexing > function can be simple and unportable like the current ones or > complicated and portable or machine-generated. In general it has > to have code like freebsd_syscall_entry_read() for each of the > variants. What portability problems do you see in the system call multiplex interfaces, and under what circumstances can you cause incorrect code to be generated? > >> We need a better way to handle these syscall subcodes (as SYSV calls 'em). > > > >I guess I don't really understand why these are a problem, unless you > >are trying to do something silly, like prototype them. > > They are a problem because they give more special cases to write code for. As opposed to generating code? I don't see less total code in the long run, and applying a cookie cutter and forcing all the calls to fit the mold is not an optimal approach to solving the problem. The biggest problem I see in the system call interface is the use of a per process call argument stack scratch area makes it per process non-reentrant, or at the very least prevents context change until the arguments have been decoded. This introduces a large latency in async operations through the normal vector, or sync-to-async conversion through an alternate vector. A better resoloution to this particular problem requires per entrancy call argument stack scratch areas, and I see the proposed changes as antithetical to that approach. This is a sacrafice of long term goals for no perceivable short term gain. 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 Oct 24 12:24:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27432 for hackers-outgoing; Tue, 24 Oct 1995 12:24:47 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27427 for ; Tue, 24 Oct 1995 12:24:44 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id MAA08806; Tue, 24 Oct 1995 12:23:47 -0700 From: Julian Elischer Message-Id: <199510241923.MAA08806@ref.tfs.com> Subject: Re: upgrade 2.05 to 2.1 To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Tue, 24 Oct 1995 12:23:47 -0700 (PDT) Cc: rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org In-Reply-To: <199510232316.BAA17630@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 24, 95 01:16:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 847 Sender: owner-hackers@freebsd.org Precedence: bulk I have proof that a 2.0.5 kernel can run correctly with all 2.1 binaries.. (i'm doing it here as the 2.0.5-> 2.1 upgrade failed and I'm about to try the next versin of it ) :) anyhow, you can upgrade all your binaries 'on the fly' (shut down to single user mode first eh?) as long as you get the libraries (shared) over first.. then replace the kernel and reboot (mv init to init.old first) (also manually replace the shell and anything else that might be still running) (mv the old ones aside) +----------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / On assignment | / \ julian@ref.tfs.com +------>x USA \ in a very strange | ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country ! +- X_.---._/ USA+(510) 645-3137(wk) \_/ \\ v From owner-freebsd-hackers Tue Oct 24 12:44:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28304 for hackers-outgoing; Tue, 24 Oct 1995 12:44:05 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28295 for ; Tue, 24 Oct 1995 12:43:54 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA03539; Tue, 24 Oct 1995 14:43:22 -0500 From: Joe Greco Message-Id: <199510241943.OAA03539@brasil.moneng.mei.com> Subject: Kerberized Encrypted Telnet for 2.0.5R To: hackers@freebsd.org Date: Tue, 24 Oct 1995 14:43:21 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk The question: how to prevent people from indiscriminately snooping on Ethernets and stuff. I don't like people to see what I am doing via telnet - especially if it involves su :-) Since people had asked, and some other side issues forced me to, I thought it was time to re-do my Kerberized encrypted telnet under 2.0.5R. There weren't many changes from the 2.0R stuff I posted many moons ago. Made a great lunchtime project. For the brave amongst us, I thought I would share my notes on how I did it. Please pardon the format. It was designed to allow easy cut'n'paste operation. It is not guaranteed to be 100% correct as it was modified as I went along, but it should hit all the key items you need in order to get the code compiled and installed. Prerequisites: a 2.0.5R system loaded with the DES and Kerberos distributions. Kerberos configured and operational. ----------------->%----------------------- Install /usr/src/secure, /usr/src/eBones sources Install 4.4BSD-Lite/usr/src/kerberosIV Install /usr/src/lib/Makefile.inc # A few strategic substitutions. The eBones DES is lacking some functions # we need - so we steal them from 4.4BSD-Lite kerberosIV. cd /usr/src/eBones mv des des.eBones mv /usr/src/kerberosIV/{des,make_key_perm,make_p_table,make_s_table,make_ip,make_p,make_fp,make_odd} . cp /usr/src/kerberosIV/include/mit-copyright.h include foreach i ( make_key_perm make_p_table make_s_table make_ip make_p make_fp make_odd ) ln -s . $i/obj end make; make install # Build the securelibs. Add SHLIB_MAJOR?= 2 SHLIB_MINOR?= 0 to /usr/src/secure/Makefile.inc Add CFLAGS+=-DAUTHENTICATION -DENCRYPTION -DDES_ENCRYPTION -DKRB4 -I/usr/include/kerberosIV to /usr/src/secure/lib/libtelnet/Makefile Edit /usr/src/secure/lib/Makefile, changing SUBDIR= libcipher libcrypt to SUBDIR= libcipher libcrypt libtelnet cd /usr/src/secure/lib make; make install # Build the executables. Note: I was only interested in telnet/telnetd. remove comment chars from CFLAGS+=-DAUTHENTICATION -DENCRYPTION LDADD+= -lkrb -ldes in /usr/src/secure/libexec/telnetd/Makefile cd /usr/src/secure/libexec/telnetd make; make "DESTDIR=" "BINDIR=/usr/libexec" install remove comment chars from CFLAGS+=-DTERMCAP -DKLUDGELINEMODE -DUSE_TERMIO -DAUTHENTICATION -DENCRYPTION ^------- CFLAGS+= -DKRB4 LDADD+= -lkrb -ldes in /usr/src/secure/usr.bin/telnet/Makefile make; make "DESTDIR=" "BINDIR=/usr/bin" install # Test it. > telnet -a -x -l jgreco smyrno.sol.net Trying 206.55.64.117... Connected to smyrno.sol.net. Escape character is '^]'. [ Trying KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] Last login: Tue Oct 24 14:27:24 from smyrno Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 2.0.5-RELEASE (GENERIC) #0: Sat Jun 10 10:46:56 1995 > telnet> status Connected to smyrno.sol.net. Operating with LINEMODE option No line editing Local catching of signals Special characters are local values Remote character echo Local flow control Currently encrypting output with DES_CFB64 Currently decrypting input with DES_CFB64 Escape character is '^]'. Wasn't that ever easy! ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Tue Oct 24 12:53:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28787 for hackers-outgoing; Tue, 24 Oct 1995 12:53:19 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28777 for ; Tue, 24 Oct 1995 12:53:13 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA30444; Wed, 25 Oct 1995 05:51:42 +1000 Date: Wed, 25 Oct 1995 05:51:42 +1000 From: Bruce Evans Message-Id: <199510241951.FAA30444@godzilla.zeta.org.au> To: bde@zeta.org.au, dennis@etinc.com Subject: Re: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > Its not a real measurement, so you can't use it. Period. It is a real measurement. >Figure out the processing requirement for handling one average frame size of > bytes with a 16450 with 8-bit I/O cycles and loads of interrupts, add 20% >and compare I do that routinely, but it's not as accurate as an actual measurement. E.g., typical 16550 input on a 486DX2/66 8MHz ISA bus (non-multiport case), for a typical receiver interrupt: interrupt overhead 5-10 us i/o's for line status 14 i/o's for data 14 i/o's for modem status 1 i/o's for interrupt id 1 total i/o's 30 @ 1.25 us each 37.5 us ------- h/w dominated i/o overhead 3-3.5 us/byte ----------- measured total overhead 6.3 us/byte For a typical 16550 transmitter interrupt: interrupt overhead 5-10 us i/o's for line status 1 i/o's for data 16 i/o's for modem status 1 i/o's for interrupt id 1 total i/o's 19 @ 1.25 us each 24 us ------- h/w dominated i/o overhead 1.8-2.1 us/byte ----------- measured total overhead 2.9 us/byte For typical 16450 input: interrupt overhead 5-10 us i/o's for line status 1 i/o's for data 1 i/o's for modem status 1 i/o's for interrupt id 1 total i/o's 4 @ 1.25 us each 5 us ------- h/w dominated i/o overhead 10-15 us/byte ----------- measured total overhead 16 us/byte For WB8013EBT input, per 1500 byte packet: interrupt overhead low i/o's for interrupt 3 low memory mapped i/o's for data 750 @ 0.625 us each other things I forgot low? ------------- more than h/w dominated i/o overhead 0.3125 us/byte ------------- measured total overhead 0.7 us/byte >it to a single interrupt and one 16-bit bus transfer per frame. It doesn't >take a rocket scientist >to know there's a signficant difference in processing requirements. The factor tends to get reduced a lot by non-data i/o's and protocol protocol processing. Bruce From owner-freebsd-hackers Tue Oct 24 13:28:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00134 for hackers-outgoing; Tue, 24 Oct 1995 13:28:36 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00129 for ; Tue, 24 Oct 1995 13:28:32 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id NAA24760; Tue, 24 Oct 1995 13:26:50 -0700 Message-Id: <199510242026.NAA24760@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Joe Greco cc: hackers@freebsd.org Subject: Re: Kerberized Encrypted Telnet for 2.0.5R In-reply-to: Your message of "Tue, 24 Oct 1995 14:43:21 CDT." <199510241943.OAA03539@brasil.moneng.mei.com> Date: Tue, 24 Oct 1995 13:26:50 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >The question: how to prevent people from indiscriminately snooping on >Ethernets and stuff. I don't like people to see what I am doing via >telnet - especially if it involves su :-) Or, you could just get the telnet and eBones from -STABLE. 2.1 will ship with encrypting telnet if you install the kerberos distribution. >Wasn't that ever easy! > >... Joe > >------------------------------------------------------------------------------ >- >Joe Greco - Systems Administrator jgreco@ns.sol.net >Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Tue Oct 24 13:32:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00268 for hackers-outgoing; Tue, 24 Oct 1995 13:32:00 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00263 for ; Tue, 24 Oct 1995 13:31:53 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id QAA01095; Tue, 24 Oct 1995 16:34:39 -0400 Date: Tue, 24 Oct 1995 16:34:39 -0400 Message-Id: <199510242034.QAA01095@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bruce Evans From: dennis@etinc.com (dennis) Subject: Re: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> Its not a real measurement, so you can't use it. Period. > >It is a real measurement. > >>Figure out the processing requirement for handling one average frame size of >> bytes with a 16450 with 8-bit I/O cycles and loads of interrupts, add 20% >>and compare > >I do that routinely, but it's not as accurate as an actual measurement. >E.g., typical 16550 input on a 486DX2/66 8MHz ISA bus (non-multiport case), >for a typical receiver interrupt: > > interrupt overhead 5-10 us > i/o's for line status 14 > i/o's for data 14 > i/o's for modem status 1 > i/o's for interrupt id 1 > total i/o's 30 @ 1.25 us each 37.5 us > ------- > h/w dominated i/o overhead 3-3.5 us/byte > ----------- > measured total overhead 6.3 us/byte > >For a typical 16550 transmitter interrupt: > interrupt overhead 5-10 us > i/o's for line status 1 > i/o's for data 16 > i/o's for modem status 1 > i/o's for interrupt id 1 > total i/o's 19 @ 1.25 us each 24 us > ------- > h/w dominated i/o overhead 1.8-2.1 us/byte > ----------- > measured total overhead 2.9 us/byte > >For typical 16450 input: > > interrupt overhead 5-10 us > i/o's for line status 1 > i/o's for data 1 > i/o's for modem status 1 > i/o's for interrupt id 1 > total i/o's 4 @ 1.25 us each 5 us > ------- > h/w dominated i/o overhead 10-15 us/byte > ----------- > measured total overhead 16 us/byte > >For WB8013EBT input, per 1500 byte packet: > > interrupt overhead low > i/o's for interrupt 3 low > memory mapped i/o's for data 750 @ 0.625 us each > other things I forgot low? > ------------- > more than > h/w dominated i/o overhead 0.3125 us/byte > ------------- > measured total overhead 0.7 us/byte > >>it to a single interrupt and one 16-bit bus transfer per frame. It doesn't >>take a rocket scientist >>to know there's a signficant difference in processing requirements. > >The factor tends to get reduced a lot by non-data i/o's and protocol >protocol processing. This is way too much to have to figure out.....I was talking much more philosophically...... So much of the processing is in software....aside from the hardware aspect you have the additional tasks for an async implementation such as frame assembly, manual checksum (OK tables are fast I guess) and async PPP has more steps than sync ppp because of character mapping and such. I'm not sure why you're arguing since no-one really disagrees that async is faster or more efficient...the bottom line is price. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Tue Oct 24 13:35:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00425 for hackers-outgoing; Tue, 24 Oct 1995 13:35:12 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00415 for ; Tue, 24 Oct 1995 13:35:07 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA03675; Tue, 24 Oct 1995 15:34:28 -0500 From: Joe Greco Message-Id: <199510242034.PAA03675@brasil.moneng.mei.com> Subject: Re: Kerberized Encrypted Telnet for 2.0.5R To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs) Date: Tue, 24 Oct 1995 15:34:27 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199510242026.NAA24760@aslan.cdrom.com> from "Justin T. Gibbs" at Oct 24, 95 01:26:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Or, you could just get the telnet and eBones from -STABLE. 2.1 will > ship with encrypting telnet if you install the kerberos distribution. Or you could just say yeeeeech phooey :-) Ah well, I tried. ;-) ... JG From owner-freebsd-hackers Tue Oct 24 13:37:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00570 for hackers-outgoing; Tue, 24 Oct 1995 13:37:26 -0700 Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA00560 for ; Tue, 24 Oct 1995 13:37:17 -0700 Received: by sovcom.kiae.su id AA06124 (5.65.kiae-1 ); Tue, 24 Oct 1995 23:33:29 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 23:33:29 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id XAA00788; Tue, 24 Oct 1995 23:15:19 +0300 To: davidg@root.com, Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG References: <199510241801.LAA13749@phaeton.artisoft.com> In-Reply-To: <199510241801.LAA13749@phaeton.artisoft.com>; from Terry Lambert at Tue, 24 Oct 1995 11:01:31 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 23:15:19 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 25 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 962 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510241801.LAA13749@phaeton.artisoft.com> Terry Lambert writes: >Why? This has no effect. It is ignored by startup because the >loader does not respect it: the cache path is still checked. For existen libraries only. >A complete fix on the order of the SunOS security update would require >that the image contain the link time library path. I agree. >As it currently sits, it's not harmful, and it represents a direction >that is desirable. Since it isn't implemented correctly, it just increase startup time, let's wait until author implement it properly (in Sun style). If proper implementation never happens, we don't need to keep it too. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Tue Oct 24 13:53:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01258 for hackers-outgoing; Tue, 24 Oct 1995 13:53:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01249 for ; Tue, 24 Oct 1995 13:53:02 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA32111; Wed, 25 Oct 1995 06:52:22 +1000 Date: Wed, 25 Oct 1995 06:52:22 +1000 From: Bruce Evans Message-Id: <199510242052.GAA32111@godzilla.zeta.org.au> To: bde@zeta.org.au, dennis@etinc.com Subject: Re: Async utilization..... Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>>Figure out the processing requirement for handling one average frame size of >>> bytes with a 16450 with 8-bit I/O cycles and loads of interrupts, add 20% >>>and compare >> [finally enough data to overwhelm Dennis :-)] >>>it to a single interrupt and one 16-bit bus transfer per frame. It doesn't >>>take a rocket scientist >>>to know there's a signficant difference in processing requirements. >> >>The factor tends to get reduced a lot by non-data i/o's and protocol >>protocol processing. >This is way too much to have to figure out.....I was talking much more >philosophically...... Yes, I usually just count the i/o accesses and interrupts myself. Bruce From owner-freebsd-hackers Tue Oct 24 14:17:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02402 for hackers-outgoing; Tue, 24 Oct 1995 14:17:51 -0700 Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02384 for ; Tue, 24 Oct 1995 14:17:29 -0700 Received: from hprbg8.informatik.tu-muenchen.de ([131.159.0.75]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26466-1>; Tue, 24 Oct 1995 22:17:03 +0100 Received: by hprbg8.informatik.tu-muenchen.de id <219872>; Tue, 24 Oct 1995 22:16:48 +0100 Subject: Re: The source of dump (fwd) From: Elmar Bartel To: hackers@freebsd.org Date: Tue, 24 Oct 1995 22:16:39 +0100 (MEZ) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 5634 Message-Id: <95Oct24.221648+0100mesz.219872+3242@hprbg8.informatik.tu-muenchen.de> Sender: owner-hackers@freebsd.org Precedence: bulk Hello, I postet a bug fix for dump to Jordan, an also an excerpt of my enhanced dump and asked whether this is interesting for the FreeBSD project. He suggested to post this here to get a wider discussion. So, here I come: I've implemented an enhancement to dump that allows youy to restrict the dump to parts of a filesystem. So you can exclude (and include parts of this excluded part) parts of a filesystem which you do not need to have dumped, or do not want to. The enhancement is completly upward compatible; if you do not use it, dump behaves exactly as before. I'll quote here the changes to the man-page of dump, so you can see what I've done: ================================================================================ DUMP(8) UNIX System Manager's Manual DUMP(8) NAME dump - filesystem backup SYNOPSIS dump [0123456789BbhfusTdWn [argument ...]] [filesystem] DESCRIPTION This version of dump is special in that it should behave as the tradi- tional dump, but knows some extensions. Look for this in the section GRAPH-EXTENSION. Everything else in this description is the same as the original. [... following unchanged text not quoted ... ] GRAPH-EXTENSION Previous versions of dump could only dump whole filesystems. It was not possible to restrict the dump to parts of a filesystem. This version of dump supports the handling of graph specifications. A graph specification is nothing more than an inode of the filesystem specified via a tradi- tional path string. You tell dump whether to include or exclude all in- odes (and the inode itself) below the specified inode. These options must be placed after the arguments and before the filesystem arguments. If no such option is given, dump behaves exactly as versions without this fea- ture If the graph mode of dump is used, dump performs an additional pass over the filesystem to select those inodes, which have to be dumped ac- cording to the graph specification. -i include-path this option tells dump to include the specified inode and all in- odes below in the dump. -e exclude-path this option tells dump to exclude the specified inode and all in- odes below from the dump. -g graph-file If it is too cumbersome to specify the include and exlude paths on the commandline, this information can be placed into the graph- file. The format of this file is simple: the first column is one of the characters i or e followed by a blank, followed by the path- name. -d directory This option is very special, and its existence is merely due to easy integration of the graph feature into the amanda backup sys- tem. (Really it was the other way; the amanda system initiated the implementation of the partial dump feature). This version of dump recognizes extensions to the filesystem-device This extension is seperated from the real device name with a dot. The extension names a graph file which is found in the directory given with the -d option. This way, the only modification to amanda necessary is when calling the dump command (adding this -d option). The disklist contains the real file-system device names extended with the names of graph files. For example the command dump 1f - -d /usr/local/amanda/etc/ /dev/rdsk/3s0.usr instructs dump to look for a graphfile /usr/local/amanda/etc/usr and dumps only those parts of the filesystem on /dev/rdsk/3s0 spec- ified in the graphfile. [ ... FILES, SEE ALSO, DIAGNOSTICS remain the same, so no quoted here ... ] BUGS Fewer than 32 read errors on the filesystem are ignored. Each reel re- quires a new process, so parent processes for reels already written just hang around until the entire tape is written. Dump with the W or w options does not report filesystems that have never been recorded in _tc/dumpdates, even if listed in /etc/fstab. It would be nice if dump knew about the dump sequence, kept track of the tapes scribbled on, told the operator which tape to mount when, and pro- vided more assistance for the operator running restore. When using the graph feature of dump it cannot determine the device-file where the filesystem resides when only the mountpoint is given. This is due to the lazyness of the implementor to support the different mounttab layouts of different Unix flavours. HISTORY A dump command appeared in Version 6 AT&T UNIX. The graph feature was implemented by Elmar Bartel in 1994. 4th Berkeley Distribution June 16, 1993 4 ================================================================================ So if there is interest to include this into the normal FreeBSD distribition let me know, where to put the source. What I have to mention: this source contains additional #ifdefs for HPUX, SunOS, SunSolaris and DecUltrix; I think that should not disturb anyone. Yours, Elmar Bartel, RBG. -- preferred: bartel@informatik.tu-muenchen.de secondary: fax: +49 89 2105-8232 or phone: -2025 Last resort: Institut fuer Informatik, TU Muenchen, Arcisstrasse 21, D-80333 Muenchen, Germany ... frau kann durch einen deutschen Artikel nicht diskriminiert werden. From owner-freebsd-hackers Tue Oct 24 14:58:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06050 for hackers-outgoing; Tue, 24 Oct 1995 14:58:25 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06034 for ; Tue, 24 Oct 1995 14:58:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA01465; Wed, 25 Oct 1995 07:57:12 +1000 Date: Wed, 25 Oct 1995 07:57:12 +1000 From: Bruce Evans Message-Id: <199510242157.HAA01465@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >OK. I hate leaving all of the above in for context, but I have to. I left it out to stop the context expanding forever :-). >The disadvantage you cite is false. Internal kernel calls to read >do not follow the same rules on inlining. The inlining is to They can do whatever is convenient. >The problem seems to be one of understanding trap vector argument >decodes. >When a system call is made, arguments are pushed on the user stack >and then the trap vector is called. There is a necessity to copy >the arguments as if they were on the stack down to a kernel space >buffer area because of the address space differences. The amount >that is copied is determined by an integer count of integers: that >is, it is some number 'n' * sizeof(int) bytes that get copied. Only in some ABI's. This is probably the best way, but it may requires messy conversions in the library to put the args on the stack with consistent padding. Since we don't control foreign ABI's we shouldn't assume this. For example, in Linux all the args are passed in registers. In Minix, the args are stored in a syscall-dependent struct and a pointer to the struct is passed in %ebx. The struct is not always nicely padded (it can have packed char and short fields). >This is dependent on the arguments pushed on the stack being >representable as integer values (we are guaranteed this by the >fact that we are calling a non-local function that is not inlined). There is no such guarantee. gcc for the i386 happens to use this slow parameter passing convention for portability. (Unless you compile with -mregparm. -mregparm is officially supported in gcc-2.7.0. It is apparently necessary for OS/2 or Windows-NT.) >[copyin() of the args] >Now each of the arguments are themselves, potentially, pointers to >additional information in call/subcode specific user space structures >that must, additionally be copied in (or out to). Not quite. The args may be padded. In NetBSD for the alpha, the args are apparently padded to 8 bytes and the SCARG macro is mainly to extract the relevant subfield which is usually 4 bytes. There may be complications for endianness. >While BSD could very well benefit from a single verification, avoiding >the mapping issues in copyin/copyout, giving one check instead of two It could benefit most from passing args in registers, as in Linux, so that no copyin() is required. >What does it do? What use is the change? It avoids scattering unportable casts and ugly macros to perform them throughout the "machine-independent" code. Now we have only unportable casts. 4.4lite2 has slightly less unportable casts and ugly macros. NetBSD has much less unportable casts and ugly macros. >If we are trying for this small an incremental improvement, I suggest >spending coding time on getting callee pop working within the kernel >code. It would be a much higher gain for less effort. That will work when I get everything prototyped properly. Prototyping syscalls is one of the easiest parts. >It's very arguable that the compiler would generate incorrectly window >optimized code for inlined system calls at present. Specifically, >it would fail to see the need to push the arguments. Earth to Terry :-). We're talking about inlining syscall handlers, not syscalls. >> No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the >> ABI. The args for them have to be copied from different places depending >> on codes in the early args. syscall() currently assumes that the args >> are on the stack in user space and copies more args than are necessary >> and sometimes more than are officially supplied. Varargs for syscall >> xxx should handled by fetching them from the appropriate place in >> foo_os_syscall_entry_xxx() and passing them in the normal varargs way >> to xxx(). >This is incorrect. The argument count specified in the systent[] table >should result in the correct copyin size. There may be no correct size. A size of 3 ints wouldn't work for open("foo", 0) if the caller has perversely passed 2 args on the stack at the top of the address space. Where are the ABI specs that disallow this? Also, a single number doesn't tell you where the args are. In general you need an offset and a size for each arg on the user stack (let's not worry about endianness conversions :-) and a mapping of user registers to args. >> No, this (not syscalls #220-231) is yucky. Multiplexing syscalls >> takes more code to handle even incorrectly like it does now. >The amount of code is a single computed goto. One might as well Not if there are nontrivial conversions. >What portability problems do you see in the system call multiplex >interfaces, and under what circumstances can you cause incorrect code >to be generated? A reasonable parameter passing convention should put the first few args (a fixed number) in registers but stop at the first `...' arg or the one before (so a variable number of args may be in registers. Where are you going to translate this? Portability problems would result from delaying the translation. Incorrect code would be generated, as usual, due to bugs. >> They are a problem because they give more special cases to write code for. >As opposed to generating code? I don't see less total code in the long >run, and applying a cookie cutter and forcing all the calls to fit the >mold is not an optimal approach to solving the problem. Er, isn't the array of args a mold? I want to make args in the kernel fit the same molds as args in user space: int open(path, flags, ...) is a completely different mold from int open(path, flags, mode) For the former, the compiler should use a special, slow parameter passing convention and pop the args in the caller. For the latter, the compiler should pass at least the first one or two args in registers and pop the args in the callee. Bruce From owner-freebsd-hackers Tue Oct 24 15:28:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA08003 for hackers-outgoing; Tue, 24 Oct 1995 15:28:16 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA07989 for ; Tue, 24 Oct 1995 15:27:55 -0700 Received: from rk.ios.com (rk.ios.com [198.4.75.55]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id PAA08248 for ; Tue, 24 Oct 1995 15:27:48 -0700 Received: (from rashid@localhost) by rk.ios.com (8.6.11/8.6.9) id GAA06295 for hackers@freebsd.org; Wed, 25 Oct 1995 06:25:38 -0400 From: Rashid Karimov Message-Id: <199510251025.GAA06295@rk.ios.com> Subject: panic: free vnode isn't(2.1-Stable) To: hackers@freebsd.org Date: Wed, 25 Oct 1995 06:25:38 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 527 Sender: owner-hackers@freebsd.org Precedence: bulk Hi there folx, Yesterday I upgraded one of the servers here with more RAM ( now it's 128M comparing to 64M it used to have) and extra 4 GB HDD. The kernel was tuned for MAXMEM of 131*** something to deal with more RAM. FYI - before the modificaion the server was up'n'running with 4000 accounts onboard for almost 30 days. But the beast crashed yesterday (after the upgrade) with "panic: free vnode isn't". I've never seend this message before ... what does it mean ? What exactly went/is wrong ? Rashid From owner-freebsd-hackers Tue Oct 24 16:23:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11221 for hackers-outgoing; Tue, 24 Oct 1995 16:23:11 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11216 for ; Tue, 24 Oct 1995 16:23:07 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA14454; Tue, 24 Oct 1995 16:13:00 -0700 From: Terry Lambert Message-Id: <199510242313.QAA14454@phaeton.artisoft.com> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 24 Oct 1995 16:13:00 -0700 (MST) Cc: davidg@root.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 24, 95 11:15:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 453 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >As it currently sits, it's not harmful, and it represents a direction > >that is desirable. > > Since it isn't implemented correctly, it just increase startup time, > let's wait until author implement it properly (in Sun style). If > proper implementation never happens, we don't need to keep it too. #ifdef? 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 Oct 24 16:37:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11625 for hackers-outgoing; Tue, 24 Oct 1995 16:37:20 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11612 for ; Tue, 24 Oct 1995 16:36:56 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA13147 ; Wed, 25 Oct 1995 00:36:38 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA25468 ; Wed, 25 Oct 1995 00:36:38 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id AAA16768; Wed, 25 Oct 1995 00:35:23 +0100 (MET) From: Ollivier Robert Message-Id: <199510242335.AAA16768@keltia.freenix.fr> Subject: Re: Kerberized Encrypted Telnet for 2.0.5R To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Wed, 25 Oct 1995 00:35:23 +0100 (MET) Cc: gibbs@freefall.freebsd.org, hackers@FreeBSD.org In-Reply-To: <199510242034.PAA03675@brasil.moneng.mei.com> from "Joe Greco" at Oct 24, 95 03:34:27 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1245 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that Joe Greco said: > > ship with encrypting telnet if you install the kerberos distribution. > > Or you could just say yeeeeech phooey :-) Not to undermine our encrypting telnet, but you should try SSH... It has many features that are better than telnet. It can do X11 encryption, replace rlogin/rcp/rsh, support more encryption algorithms and more. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Sun Oct 22 20:22:48 MET 1995 From owner-freebsd-hackers Tue Oct 24 16:45:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11862 for hackers-outgoing; Tue, 24 Oct 1995 16:45:11 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11857 for ; Tue, 24 Oct 1995 16:45:01 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA27093; Tue, 24 Oct 1995 17:47:14 -0600 Date: Tue, 24 Oct 1995 17:47:14 -0600 From: Nate Williams Message-Id: <199510242347.RAA27093@rocky.sri.MT.net> To: Terry Lambert Cc: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=), freebsd-hackers@FreeBSD.ORG Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-Reply-To: <199510242313.QAA14454@phaeton.artisoft.com> References: <199510242313.QAA14454@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert writes: > > >As it currently sits, it's not harmful, and it represents a direction > > >that is desirable. > > > > Since it isn't implemented correctly, it just increase startup time, > > let's wait until author implement it properly (in Sun style). If > > proper implementation never happens, we don't need to keep it too. > > #ifdef? Since the run-time loader code affects the memory size of *every* single binary in the system, removing un-necessary/un-needed functionality from it is a win. We still have the CVS tree which we can use to pull out the code from if we need it at a later date. This does assume one has access to the CVS tree, but given the extreme interest that has been shown in the code up till this point I'd be very suprised to get a sudden rash of volunteers wanting to implement LD_NOSTD_PATH but they don't have enough code to work with. :) Nate From owner-freebsd-hackers Tue Oct 24 16:47:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11961 for hackers-outgoing; Tue, 24 Oct 1995 16:47:35 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA11950 ; Tue, 24 Oct 1995 16:47:30 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7t3W-000jCJC; Tue, 24 Oct 95 18:46 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id SAA13180; Tue, 24 Oct 1995 18:46:50 -0500 Message-Id: <199510242346.SAA13180@sunc210.tellabs.com> Subject: 2.1.0-951020-SNAP: Major bug in NFS again! To: hackers@freebsd.org Date: Tue, 24 Oct 1995 18:46:50 -0500 (CDT) Cc: bugs@freebsd.org, mikebo (Mike Borowiec) 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 Precedence: bulk Greetings - There is a major bug somewhere in the bowels of RPC or NFS... When the hacks were backed out of /usr/src/lib/libc/rpc/clnt_udp.c a couple months ago, I expected NFS to multi-homed servers to work again - it doesn't! While the NFS mount works OK, subsequent accesses to the filesystem (a "df" for example) lock up the session... The following is Solaris snoop output which shows the problem. TOYBOX is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed server running SunOS 4.1.3 and "routed -q". First we do the mount: # mount tellabk:/export/home/tellabk-4 /usr/home toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP sunk -> toybox PORTMAP R GETPORT port=2049 toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP sunk -> toybox PORTMAP R GETPORT port=737 toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 sunk -> toybox MOUNT R Mount OK F=075B Looks like the mount completed OK, even though the replies came from SUNK, TELLABK's alter-ego. So let's do a "df": # df toybox -> tellabk NFS C STATFS FH=075B sunk -> toybox NFS R STATFS OK toybox -> sunk ICMP Destination unreachable (Bad port) toybox -> tellabk NFS C STATFS FH=075B (retransmit) sunk -> toybox NFS R STATFS OK toybox -> sunk ICMP Destination unreachable (Bad port) ... ... ad infinitum ... As you can see, TOYBOX seems to be expecting the STATFS response from TELLABK, not its SUNK alter ego, and complains by sending ICMP Dest Unreachables. At this point, the session is locked up and "df" can never be killed - it is stuck in the kernel. Granted, most users won't be affected by this problem - but for me, this is a show stopper supreme - the single biggest problem I had with 2.0.5R. Because of it, I cannot use automounter at all and any NFS is crippled. I will gladly assist in any way I can to resolve this... work nights, weekends, whatever.... Please don't press this bug into the 2.1 CDs! - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Oct 24 17:06:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12581 for hackers-outgoing; Tue, 24 Oct 1995 17:06:35 -0700 Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.97.216]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12576 for ; Tue, 24 Oct 1995 17:06:33 -0700 Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.6.12/8.6.9) id RAA17284; Tue, 24 Oct 1995 17:05:55 -0700 From: "Steven G. Kargl" Message-Id: <199510250005.RAA17284@troutmask.apl.washington.edu> Subject: Re: linux emul is go! To: erich@lodgenet.com (Eric L. Hernes) Date: Tue, 24 Oct 1995 17:05:55 -0700 (PDT) Cc: jkh@time.cdrom.com, brian@MediaCity.com, hackers@freebsd.org In-Reply-To: <199510241426.JAA04121@jake.lodgenet.com> from "Eric L. Hernes" at Oct 24, 95 09:26:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1519 Sender: owner-hackers@freebsd.org Precedence: bulk According to Eric L. Hernes: > > > > > Apparently, one has to have exactly the "right" linux libs to get > > > things to work. Amancio was nice enough to make his available. > > > > > We really need to make this a "port" I think. Or at the very least we > > need to stick them on the CD. :) Amancio? Somebody? Might it be > > possible for you to get everything one needs in one convenient tarfile > > that we can distribute? I'm sure that if *Brian* had troubles with > > this, our average user will simply throw up his hands and claim that > > our linux emulation doesn't work for spit! :-( > > Ok, I just made a working copy of my linux libs, and a port that needs > to be tested. > > In my home dir on freefall, there are two files, a linux_lib-port.tgz, and > the corresponding libraries in a tarball, linux_lib.tar.gz. Put the second > in /usr/ports/distfiles, or adjust the MASTER_SITES macro in the makefile. > > > > > Jordan > > > > eric. > What about the sources for the linux libraries that you distribute in binary form? Will you make these available for the next 3(?) years? Will this violate the GPL? Yes, I know the sources are probably useless for everyone who runs FreeBSD (and occasionally emulates linux). But, some one has to be a devils advocate. -- Steven G. Kargl | Phone: 206-685-4677 | Applied Physics Lab | Fax: 206-543-6785 | Univ. of Washington |---------------------| 1013 NE 40th St | FreeBSD 2.x-stable | Seattle, WA 98105 |---------------------| From owner-freebsd-hackers Tue Oct 24 17:22:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13059 for hackers-outgoing; Tue, 24 Oct 1995 17:22:18 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13053 for ; Tue, 24 Oct 1995 17:22:16 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.12/8.6.9) id UAA15337 for hackers@freebsd.org; Tue, 24 Oct 1995 20:26:47 -0400 From: Mark Hittinger Message-Id: <199510250026.UAA15337@ns1.win.net> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs (fwd) To: hackers@freebsd.org Date: Tue, 24 Oct 1995 20:26:46 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1340 Sender: owner-hackers@freebsd.org Precedence: bulk On Tops-10 (an olden day DEC OS) there was a hack called the "meddle bit". Programs that ran with "JACCT" (suid root) were allowed to load shareable segements in the default way. When Tops-10 detected an unusual condition during the execution of such a program it set a bit in the process data called "the meddle bit". When loading a shareable image, if this bit was set then changes in path were ignored. When the "meddle bit" was set, a program which would normally be allowed to write in a shared memory segment would be refused. Anyplace where the OS developers felt something weird was going on they would just turn on "meddle". As is usual with these sorts of things I found something that fell through the cracks. Each process could load its own pagefault handler. I discovered that I could load my own page fault handler and gain write access to shared images. It was easy to fix, just turn on meddle if a non-default page fault handler was loaded. No programs broke, no procedures changed. The fix for telnetd seems too concentrated to me, it seems that we are grappling with a much broader problem that may pop up elsewhere. Perhaps we could prevent SUID images from connecting with shared libraries that are not owned by root/bin? Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net From owner-freebsd-hackers Tue Oct 24 17:24:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13301 for hackers-outgoing; Tue, 24 Oct 1995 17:24:58 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13271 for ; Tue, 24 Oct 1995 17:24:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA17462; Tue, 24 Oct 1995 17:16:03 -0700 From: Terry Lambert Message-Id: <199510250016.RAA17462@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Tue, 24 Oct 1995 17:16:03 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510242157.HAA01465@godzilla.zeta.org.au> from "Bruce Evans" at Oct 25, 95 07:57:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10667 Sender: owner-hackers@freebsd.org Precedence: bulk > >When a system call is made, arguments are pushed on the user stack > >and then the trap vector is called. There is a necessity to copy > >the arguments as if they were on the stack down to a kernel space > >buffer area because of the address space differences. The amount > >that is copied is determined by an integer count of integers: that > >is, it is some number 'n' * sizeof(int) bytes that get copied. > > Only in some ABI's. This is probably the best way, but it may > requires messy conversions in the library to put the args on the > stack with consistent padding. Pushing on the stack is a messy conversion? What about dead register usage from not knowing about the stack? I think you are going to have to burn the cycles on an opaque function call in any case. > Since we don't control foreign ABI's we shouldn't assume this. For > example, in Linux all the args are passed in registers. In Minix, > the args are stored in a syscall-dependent struct and a pointer > to the struct is passed in %ebx. The struct is not always nicely > padded (it can have packed char and short fields). That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's either 'int' or 'long' or '*'. So we take a hit when processing these non-standard mechanisms; we do so through the system call table for the ABI, so we will be taking a function encapsulation hit anyway. I think it is unlikely that iBCS2 or Linux develeopement will occur on BSD in a non-emulated environment. > >This is dependent on the arguments pushed on the stack being > >representable as integer values (we are guaranteed this by the > >fact that we are calling a non-local function that is not inlined). > > There is no such guarantee. gcc for the i386 happens to use this > slow parameter passing convention for portability. (Unless you > compile with -mregparm. -mregparm is officially supported in gcc-2.7.0. > It is apparently necessary for OS/2 or Windows-NT.) UNIX typically uses this, period. Stack argument passing to system calls is the way things are done. The use of registers is fine, as long as the interface is general enough. The OS/2 and NT (and Win95) conventions derive from the DOS interrupt mechanisms and require assembly function stubs in any case, even if the routines are then tagged "naked" -- even then, there are problems intordiced that the compiler can't understand a call will trash EAX (and maybe EDX) without hacking an "xor eax,eax" into the thing to make it know that the function to be called trashes it and it can't leave a local variable in it over the call. > >[copyin() of the args] > >Now each of the arguments are themselves, potentially, pointers to > >additional information in call/subcode specific user space structures > >that must, additionally be copied in (or out to). > > Not quite. The args may be padded. In NetBSD for the alpha, the args > are apparently padded to 8 bytes and the SCARG macro is mainly to > extract the relevant subfield which is usually 4 bytes. There may be > complications for endianness. They are padded to the default bus transfer size for the machine, which is supposed to be 'int'. I'd argue that 'int' was the wrong size, not that there was extraneous padding. There is a limit on the address space on the alpha anyway; it's not the full 64 bits. I'd really dealy love to know how there could be an endianess issue, considering system calls are only ever going to run as compiled code on one endianess of machine. > >While BSD could very well benefit from a single verification, avoiding > >the mapping issues in copyin/copyout, giving one check instead of two > > It could benefit most from passing args in registers, as in Linux, so > that no copyin() is required. 1) BSDI binary compatability 2) FreeBSD/NetBSD binary backward compatability 3) Register conversion from a Linux emulation mismatch. 4) Register collision verification in the function so that the register is not used directly for local storage/scratch. 5) Async reentrancy/multithreading reentrancy. It's a can of worms that, frankly, buys so little as to be useless. > >What does it do? What use is the change? > > It avoids scattering unportable casts and ugly macros to perform them > throughout the "machine-independent" code. Now we have only unportable > casts. 4.4lite2 has slightly less unportable casts and ugly macros. > NetBSD has much less unportable casts and ugly macros. The structure casts, I presume? The answer is to compile with the packing being the default for data matchup -- in the alpha case, 64 bits. For devices that need it, use packing #pragma's to tighten them up on a case by case basis, in the header file defining the structure. Aligned element accesses are faster anyway. > >It's very arguable that the compiler would generate incorrectly window > >optimized code for inlined system calls at present. Specifically, > >it would fail to see the need to push the arguments. > > Earth to Terry :-). We're talking about inlining syscall handlers, not > syscalls. Sorry -- you're the one that brought up ABI, which is kernel code, not user space code. The only way you can effect the ABI code is if you call the inlined versions and match the user and kernel usage. Actually, the only way you can guarantee interface usability is to use the inlines to make the calls -- otherwise, your plan to pass in registers fails when you try to call the BSD system call from the ABI system call code. 8-(. > >This is incorrect. The argument count specified in the systent[] table > >should result in the correct copyin size. > > There may be no correct size. A size of 3 ints wouldn't work for > open("foo", 0) if the caller has perversely passed 2 args on the stack > at the top of the address space. Where are the ABI specs that disallow > this? There are none. However, you are wrong; it would work, you'd just get a garbage value (stack direction grows the right direction for the third argument to be optional). Since in that case the garbage value is unreferenced (or the call generated a prototype warning ...not 8-)), then it will work. Getting a bogus value from the stack vs. getting a bogus value from a register is a tossup in any case. > Also, a single number doesn't tell you where the args are. In general > you need an offset and a size for each arg on the user stack (let's not > worry about endianness conversions :-) and a mapping of user registers > to args. I'd really like to see your biendian binary machine that didn't do the switch in the trap code in the kernel (PPC). Throwing that out, the offset is "one stack entry per". The biggest bugger here is preinitialization of the high word of a quad for portability -- but of course, the resulting code fails to operate after certain file lengths are hit instead of immediately, so all that's been done is that the problem has been relocated, not solved. Even assuming the problem is "fixed" by doing this, the only compatability guaranteed is with applications compiled using the same techniques -- that is, applications that don't exist because this is a change in call behaviour as well. I think moving to register parameter passing is too architecture specific. [ ... multiplexed system calls (like, oh, say open with O_CREAT as the multiplexing flag) ... ] > >The amount of code is a single computed goto. One might as well > > Not if there are nontrivial conversions. Then it's a non-trivial case, and splitting it out isn't going to make it more trivial. [ ... and now to the meat ... ] > >What portability problems do you see in the system call multiplex > >interfaces, and under what circumstances can you cause incorrect code > >to be generated? > > A reasonable parameter passing convention should put the first few > args (a fixed number) in registers but stop at the first `...' arg or > the one before (so a variable number of args may be in registers. > Where are you going to translate this? Portability problems would > result from delaying the translation. Incorrect code would be generated, > as usual, due to bugs. I have to point out that it would then be impossible to make system calls without prototype references. If this is a "fix" for the quad word passing problem (which is a "non-use of system call prototype" problem), then, isn't this just making things worse? > > >> They are a problem because they give more special cases to write code for. > > >As opposed to generating code? I don't see less total code in the long > >run, and applying a cookie cutter and forcing all the calls to fit the > >mold is not an optimal approach to solving the problem. > > Er, isn't the array of args a mold? I want to make args in the kernel > fit the same molds as args in user space: > > int open(path, flags, ...) > > is a completely different mold from > > int open(path, flags, mode) > > For the former, the compiler should use a special, slow parameter passing > convention and pop the args in the caller. For the latter, the compiler > should pass at least the first one or two args in registers and pop the > args in the callee. Callee pop only works when using the same stack. When you get to the kernel, the kernel thread (or just process) will be using its own stack, so that argument won't wash. My complaint on callee pop as a more fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. The only problem right now is that the quad argument takes more than one stack position to do its dirty deed. And that's more a result of the thing being an invalid C type than anything else. If were weren't in violation of POSIX/ANSI on quad_t, then it wouldn't be a problem. Probably the correct soloution is to make seperate "quad-knowledgable" functions for the things that take quad arguments. This is actually described in __syscall(2) -- which *guarantees* padding. Right now the screwable functions are truncate, ftruncate, seek, lseek, and mmap -- and mmap() is bogus because of the kernel address space restrictions currently on "vmio". The others are in violation of one or more standards because "quad" isn't an allowable type. Might as well violate them further by using inline references to the __syscall(2) instead of syscall(2) to get to them so that: (1) they are undefined without proper header inclusion, and (2) the padding is guaranteed (as the __syscall(2) states in the man page). That at least would solve the screwups without adding to them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Oct 24 17:44:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA14124 for hackers-outgoing; Tue, 24 Oct 1995 17:44:35 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA14109 for ; Tue, 24 Oct 1995 17:44:31 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA07521; Tue, 24 Oct 1995 17:43:50 -0700 To: "Steven G. Kargl" cc: erich@lodgenet.com (Eric L. Hernes), brian@MediaCity.com, hackers@freebsd.org Subject: Re: linux emul is go! In-reply-to: Your message of "Tue, 24 Oct 1995 17:05:55 PDT." <199510250005.RAA17284@troutmask.apl.washington.edu> Date: Tue, 24 Oct 1995 17:43:50 -0700 Message-ID: <7519.814581830@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > What about the sources for the linux libraries that you distribute > in binary form? Will you make these available for the next 3(?) years? > Will this violate the GPL? You need to either make them available, be willing to make them available or point to a location where they're freely available. I believe that the GPL makes loose provisions for all 3. Also, I hardly expect that this is going to cause undue friction where that whole thing is concerned. Jordan From owner-freebsd-hackers Tue Oct 24 18:02:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA14833 for hackers-outgoing; Tue, 24 Oct 1995 18:02:54 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA14828 for ; Tue, 24 Oct 1995 18:02:51 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.12/8.6.9) id SAA24656 for hackers@freefall; Tue, 24 Oct 1995 18:02:31 -0700 Date: Tue, 24 Oct 1995 18:02:31 -0700 From: "Jordan K. Hubbard" Message-Id: <199510250102.SAA24656@time.cdrom.com> To: hackers@freefall.FreeBSD.org Subject: Accounting system for ISPs.. Sender: owner-hackers@FreeBSD.org Precedence: bulk Anyone seen this? http://www.rtd.com/software/uta.html I don't know how well it works, but it's available for FreeBSD 2.0.5 and might fill the bill for a number of ISPs out there if it does everything it advertises.. I have absolutely no connection with the company, I was simply contacted by one of the firm's people to let me know about the existance of the product and I'm passing the information on.. Jordan From owner-freebsd-hackers Tue Oct 24 18:21:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15415 for hackers-outgoing; Tue, 24 Oct 1995 18:21:46 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15403 ; Tue, 24 Oct 1995 18:21:35 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA06946; Tue, 24 Oct 1995 18:21:27 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA27638; Tue, 24 Oct 1995 18:17:03 -0700 Message-Id: <199510250117.SAA27638@corbin.Root.COM> To: mikebo@tellabs.com cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 95 18:46:50 CDT." <199510242346.SAA13180@sunc210.tellabs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 18:17:02 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >The following is Solaris snoop output which shows the problem. TOYBOX >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed >server running SunOS 4.1.3 and "routed -q". First we do the mount: > ># mount tellabk:/export/home/tellabk-4 /usr/home > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > sunk -> toybox PORTMAP R GETPORT port=2049 > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > sunk -> toybox PORTMAP R GETPORT port=737 > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > sunk -> toybox MOUNT R Mount OK F=075B > >Looks like the mount completed OK, even though the replies came from SUNK, >TELLABK's alter-ego. So let's do a "df": Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - it looks like the Sun is replying out a different interface then it received the mount request from. FreeBSD rightfully thinks this is crap coming from some irrelevant machine. I think you should be able to work around it by using the name/address of "sunk" when doing the mount. -DG From owner-freebsd-hackers Tue Oct 24 18:35:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15976 for hackers-outgoing; Tue, 24 Oct 1995 18:35:47 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15965 for ; Tue, 24 Oct 1995 18:35:42 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id SAA09454; Tue, 24 Oct 1995 18:35:38 -0700 Date: Tue, 24 Oct 1995 18:35:37 -0700 (PDT) From: Jaye Mathisen To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: Accounting system for ISPs.. In-Reply-To: <199510250102.SAA24656@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk Yes, I have this. It works OK, but not great, it seems to be missing a fair number of promised features, (Or I've gotten off the announce list). We're having problems with it reading Portmaster log files, but I haven't messed with it that much. On Tue, 24 Oct 1995, Jordan K. Hubbard wrote: > Anyone seen this? > > http://www.rtd.com/software/uta.html > > I don't know how well it works, but it's available for FreeBSD 2.0.5 > and might fill the bill for a number of ISPs out there if it does everything > it advertises.. > > I have absolutely no connection with the company, I was simply contacted > by one of the firm's people to let me know about the existance of the > product and I'm passing the information on.. > > Jordan > From owner-freebsd-hackers Tue Oct 24 18:38:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16090 for hackers-outgoing; Tue, 24 Oct 1995 18:38:42 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA16082 for ; Tue, 24 Oct 1995 18:38:32 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id SAA06974; Tue, 24 Oct 1995 18:38:30 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id SAA27692; Tue, 24 Oct 1995 18:34:04 -0700 Message-Id: <199510250134.SAA27692@corbin.Root.COM> To: Brian Tao cc: FREEBSD-HACKERS-L Subject: Re: panic: free vnode isn't In-reply-to: Your message of "Tue, 24 Oct 95 02:40:59 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 18:34:03 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >panic: free vnode isn't >Debugger("panic") >Stopped at _Debugger+0x2b [/sys/compile/FTPSERV/:261]: movb $0,_inDebugger 110 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Where did that come from? Did you build your kernel with -g or something? I wouldn't recommend doing that and it's not needed for DDB. > Typing "continue" proceeded with the disk sync and reboot. I >don't know if this is the cause of the machine hanging the last three >times, but it is the only clue I have so far. Any ideas how I can >avoid this? The system is an Intel 486DX2/66 on an ASUS SP3G board, >32 megabytes RAM, a 520-meg Maxtor drive on the built-in NCR >controller and an NE2000-compatible Ethernet NIC. It is the NFS >client for about 26 gigabytes of filesystems, but serving none of its >own. I'm running the 2.1.0-950928 snapshot with the following kernel >options: Are your using msdosfs on this machine? -DG From owner-freebsd-hackers Tue Oct 24 18:47:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA17362 for hackers-outgoing; Tue, 24 Oct 1995 18:47:17 -0700 Received: from Shug-Internet.Saar.DE (root@shug-internet.saar.de [192.109.53.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA17326 for ; Tue, 24 Oct 1995 18:47:03 -0700 Received: from TMPuhf.Saar.DE (tmpuhf.saar.de [192.109.53.3]) by Shug-Internet.Saar.DE (8.6.8.1/8.5) with SMTP id CAA13612; Wed, 25 Oct 1995 02:46:32 +0100 Received: from ramsey by TMPuhf.Saar.DE with uucp (Smail3.1.28.1 #1) id m0t7uvD-00020zC; Wed, 25 Oct 95 02:46 WET Received: by ramsey.saar.de (/\oo/\ Smail3.1.29.1 #1) id ; Wed, 25 Oct 95 02:27 MET Message-Id: Date: Wed, 25 Oct 95 02:27 MET From: torstenb@ramsey.saar.de (Torsten Blum) To: hackers@FreeBSD.org Cc: roberto@keltia.freenix.fr Reply-To: torstenb@FreeBSD.org Subject: Re: Kerberized Encrypted Telnet for 2.0.5R References: <199510242034.PAA03675@brasil.moneng.mei.com> <199510242335.AAA16768@keltia.freenix.fr> Sender: owner-hackers@FreeBSD.org Precedence: bulk Olliver Robert wrote: >Not to undermine our encrypting telnet, but you should try SSH... It has >many features that are better than telnet. It can do X11 encryption, >replace rlogin/rcp/rsh, support more encryption algorithms and more. > ports/security/ssh/ ;) -tb From owner-freebsd-hackers Tue Oct 24 19:22:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA19256 for hackers-outgoing; Tue, 24 Oct 1995 19:22:56 -0700 Received: from ccslinux.dlsu.edu.ph (root@linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA19211 for ; Tue, 24 Oct 1995 19:22:14 -0700 Received: by ccslinux.dlsu.edu.ph (Linux Smail3.1.28.1 #13) Sender: owner-hackers@FreeBSD.org Precedence: bulk id m0t7vJ8-000A5dC; Wed, 25 Oct 95 10:11 GMT+0800 Date: Wed, 25 Oct 1995 10:11:09 +48000 From: Gavin Lim Subject: Process Migration in FreeBSD To: hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We're developing a process migration facility for FreeBSD 2.0.5. Process migration is the procedure by which running processes are transferred from one computer to another in a network. This would make load sharing and load balancing in distributed systems possible. In order to transfer a process, we have to save the process state, probably save it to a file, and transfer this file to the destination computer, where it would be deserialized and converted back to data structures. When this is done, the process can resume execution on the destination computer. Do you have any suggestions to do this? 1. How do we suspend the process? (sleep()?) 2. How do we save the process state? (/proc? core image?) 3. How do we restart the process? We sure could use your help. Hope to hear from you as soon as possible. Thanks! ============================================================================== Gavin Lim Gavin@linux1.dlsu.edu.ph ============================================================================== From owner-freebsd-hackers Tue Oct 24 19:29:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA19806 for hackers-outgoing; Tue, 24 Oct 1995 19:29:57 -0700 Received: from gold.interlog.com (gold.interlog.com [198.53.145.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA19763 for ; Tue, 24 Oct 1995 19:29:43 -0700 Received: from lotbiniere.interlog.com (lotbiniere.interlog.com [198.53.146.76]) by gold.interlog.com (8.6.10/8.6.10) with ESMTP id WAA20402; Tue, 24 Oct 1995 22:29:33 -0400 Received: from localhost (localhost [127.0.0.1]) by lotbiniere.interlog.com (8.6.11/8.6.9) with SMTP id UAA02174; Tue, 24 Oct 1995 20:51:40 -0400 Message-Id: <199510250051.UAA02174@lotbiniere.interlog.com> X-Authentication-Warning: lotbiniere.interlog.com: Host localhost didn't use HELO protocol From: "Michel Joly de Lotbiniere" Reply-to: "Michel Joly de Lotbiniere" To: "Eric L. Hernes" cc: Brian Litzinger , hackers@freebsd.org Subject: Re: linux emul is go! In-reply-to: Message from "Eric L. Hernes" of "Tue, 24 Oct 1995 09:51:22 CDT." <199510241451.JAA04312@jake.lodgenet.com> Date: Tue, 24 Oct 1995 20:51:39 -0400 Sender: owner-hackers@freebsd.org Precedence: bulk > From: "Eric L. Hernes" > Subject: Re: linux emul is go! {snip] > > Nate keyed me in on the secret that the libs and ld.so all need to be ZMAGIC > > (ttyp2@jake)$ pwd > /compat/linux/lib > (ttyp2@jake)$ file * > ld.so: Linux/i386 demand-paged executable (ZMAGIC) > libX11.so.3: symbolic link to libX11.so.3.1.0 > libX11.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) > libXaw.so.3: symbolic link to libXaw.so.3.1.0 > libXaw.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) > libXt.so.3: symbolic link to libXt.so.3.1.0 > libXt.so.3.1.0: Linux/i386 demand-paged executable (ZMAGIC) > libc.so.4: symbolic link to libc.so.4.5.26 > libc.so.4.5.26: Linux/i386 demand-paged executable (ZMAGIC) > libgr.so.1: symbolic link to libgr.so.1.3 > libgr.so.1.3: Linux/i386 demand-paged executable (ZMAGIC) > libm.so.4: symbolic link to libm.so.4.5.26 > libm.so.4.5.26: Linux/i386 demand-paged executable (ZMAGIC) > I recall reading somewhere that the recommendation that people use the 4.5.27 versions of libc/libm when using the XFree86 3.1 Linux libraries; it seems there were various small gotcha's with the earlier version (which antedated Xfree 3.1, I believe). Might be worth testing; I'm still running vanilla 2.0.5R2, so that excludes me from doing it, I think. ========================= Michel Joly de Lotbiniere mjdl@interlog.com ========================= From owner-freebsd-hackers Tue Oct 24 19:45:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA21987 for hackers-outgoing; Tue, 24 Oct 1995 19:45:55 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA21974 ; Tue, 24 Oct 1995 19:45:51 -0700 From: mikebo@tellabs.com Received: from tellabk.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7vqB-000jCNC; Tue, 24 Oct 95 21:45 CDT Received: by tellabk.tellabs.com (4.1/1.9) id AA11614; Tue, 24 Oct 95 21:45:18 CDT Message-Id: <9510250245.AA11614@tellabk.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Tue, 24 Oct 1995 21:45:17 -0500 (CDT) Cc: hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250117.SAA27638@corbin.Root.COM> from "David Greenman" at Oct 24, 95 06:17:02 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3577 Sender: owner-hackers@freebsd.org Precedence: bulk David G. wrote: > Mike Borowiec wrote: > >The following is Solaris snoop output which shows the problem. TOYBOX > >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed > >server running SunOS 4.1.3 and "routed -q". First we do the mount: > > > ># mount tellabk:/export/home/tellabk-4 /usr/home > > > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > > sunk -> toybox PORTMAP R GETPORT port=2049 > > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > > sunk -> toybox PORTMAP R GETPORT port=737 > > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > > sunk -> toybox MOUNT R Mount OK F=075B > > > >Looks like the mount completed OK, even though the replies came from SUNK, > >TELLABK's alter-ego. So let's do a "df": > > Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - > it looks like the Sun is replying out a different interface then it received > the mount request from. FreeBSD rightfully thinks this is crap coming from > some irrelevant machine. I think you should be able to work around it by using > the name/address of "sunk" when doing the mount. > Yes, the Sun is replying from a different interface than it received the mount request from. That's because the Sun is running "routed" and learns its route back to TOYBOX from a RIP announcement made by a router. Using the name/addr of SUNK may work today - what if tomorrow the router decides TELLABK is best, or SUNK2, or SUNK3, etc. "Correct" or not, Suns do not always reply back on the same interface from which they receive a request. It is basically a crap-shoot... Worse, if the router dynamically changes the route back to TOYBOX, for whatever reason (down interface, route optimization), the Sun will dutifully begin replying on a new interface as soon as the RIP announcement is received. This isn't something that can be changed on a Sun. Even configuring a Sun with static routes won't really solve the problem, as someone/sometime is bound to request a mount from an interface which is not the server's default route. In that case, the reply would come from the interface tagged with the default route. The onus is on the client to deal with it... This situation is correctly handled by every commercial UNIX OS I've worked with. I don't know what security implications that has, but I do know that FreeBSD's NFS (and so the whole OS) is useless to me (and others running in a similar environment) unless it works with Suns and plays by their rules. If I can't use the OS, the security doesn't do me a damn bit of good! I can document this behavior in SunOS, Solaris and HP/UX if it will help strengthen the argument. This is the real world behavior, and I'm inclined to believe that FreeBSD is not in a position to dictate what's "proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest of the commerical UNIX market. Sorry for the rambling discourse, but I need this fixed or I can't use FreeBSD. At the least, can the "Sun behavior" I need be added as an option to the mount command? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Oct 24 20:21:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23710 for hackers-outgoing; Tue, 24 Oct 1995 20:21:13 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23704 for ; Tue, 24 Oct 1995 20:21:09 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.12/8.6.9) id XAA00130 for hackers@freebsd.org; Tue, 24 Oct 1995 23:25:16 -0400 From: Mark Hittinger Message-Id: <199510250325.XAA00130@ns1.win.net> Subject: re: process migration To: hackers@freebsd.org Date: Tue, 24 Oct 1995 23:25:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1734 Sender: owner-hackers@freebsd.org Precedence: bulk > From: Gavin Lim > We're developing a process migration facility for FreeBSD 2.0.5. Process > migration is the procedure by which running processes are transferred > from one computer to another in a network. This would make load sharing > and load balancing in distributed systems possible. > In order to transfer a process, we have to save the process state, > probably save it to a file, and transfer this file to the destination > computer, where it would be deserialized and converted back to data > structures. When this is done, the process can resume execution on the > destination computer. This sort of thing has been attempted before in TOPS-10 and VMS. In TOPS-10 it was called "system sleep" and in VMS it was RUN/CHECKPOINT. This would be a very useful feature even in a single processor environment. If you need to shut the system down for some sort of maintenance, you could "sleep" the processes and shut down the machine. Then you could reboot and continue the checkpointed processes. It is important to note that these features were beta only and never made it into an official release (the TOPS-10 one may have). Basically the implementation idea was to create a page fault scenario and page out the entire image. The context of the process would also be saved in the swap space. Then you'd have to copy the swap space context of the process to another machine, or shutdown/reboot, and then swap the process back in. The problems are in file locking, shared memory segments, buffers that need to be flushed to the file system, etc. Its a big problem but a neat idea. Good Luck! Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net From owner-freebsd-hackers Tue Oct 24 20:42:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA24420 for hackers-outgoing; Tue, 24 Oct 1995 20:42:08 -0700 Received: from nike.efn.org (garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA24411 ; Tue, 24 Oct 1995 20:41:52 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id UAA06732; Tue, 24 Oct 1995 20:41:56 -0700 Date: Tue, 24 Oct 1995 20:41:55 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: "Jordan K. Hubbard" cc: "Serge A. Babkin" , msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, ache@FreeBSD.ORG Subject: Re: startslip isn't just broken - it's EVIL! In-Reply-To: <11667.814539479@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Tue, 24 Oct 1995, Jordan K. Hubbard wrote: > > > > > > > Guys! Use slattach and chat, and save yourselves the stress 8) > > > > > > I've never managed to get that combo to work! Chat just dies > > > immediately.. :-( > > > > I got it working under 2.0. There were some strange problems but in > > common it worked. I remember that chat does not understand the dial-up > > string in the command line, it needs a file with it. > > No, that's not the problem here - I have my chat script in a file and > that very same chat script works just fine with chat if I *don't run > it from slattach*. When run from slattach, chat blows up when it > first tries to talk to the port. I don't know what's wrong, but > slattach clearly isn't setting up things correctly before invoking the > external script. I tried for quite a few days to get this to work > and finally gave up in disgust. did you put in a sleep before calling the chat script? It looks like you have to sleep 2 before you call the chat script to let the line settle down after slattach dropped and raised dtr on the modem... this might help... TTYL.. John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Tue Oct 24 20:43:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA24498 for hackers-outgoing; Tue, 24 Oct 1995 20:43:33 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA24493 ; Tue, 24 Oct 1995 20:43:30 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA07118; Tue, 24 Oct 1995 20:43:29 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id UAA27854; Tue, 24 Oct 1995 20:38:46 -0700 Message-Id: <199510250338.UAA27854@corbin.Root.COM> To: mikebo@tellabs.com cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 95 21:45:17 CDT." <9510250245.AA11614@tellabk.tellabs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 20:38:46 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >This isn't something that can be changed on a Sun. Even configuring a >Sun with static routes won't really solve the problem, as someone/sometime >is bound to request a mount from an interface which is not the server's >default route. In that case, the reply would come from the interface >tagged with the default route. The onus is on the client to deal with it... The client should ignore NFS packets from hosts that it's not talking to or doesn't know about, and that's what all 4.4BSD derived OSs do. >This situation is correctly handled by every commercial UNIX OS I've >worked with. I don't know what security implications that has, but I >do know that FreeBSD's NFS (and so the whole OS) is useless to me >(and others running in a similar environment) unless it works with >Suns and plays by their rules. If I can't use the OS, the security >doesn't do me a damn bit of good! > >I can document this behavior in SunOS, Solaris and HP/UX if it will >help strengthen the argument. This is the real world behavior, and I'm >inclined to believe that FreeBSD is not in a position to dictate what's >"proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest >of the commerical UNIX market. This is obviously flamebait and I'm not going to respond to it. >Sorry for the rambling discourse, but I need this fixed or I can't >use FreeBSD. At the least, can the "Sun behavior" I need be added >as an option to the mount command? If you choose not to use my suggested work-around, then I guess you can't use FreeBSD. For the NFS server, FreeBSD (and all other 4.4BSD derived systems) keep an authentication list in the kernel that is constructed from /etc/exports. For the NFS client, FreeBSD requires that replies to its RPC requests come from the same address that they were issued to. If it didn't work this way, then *anyone* could send bogus udp datagrams with hand-tailored RPC calls/replies to you and as long as that someone can come up with a file handle (which is relatively easy), he can do unchecked file operations and bypass the system security. Other commercial vendors are running old security- broken versions of NFS and this makes them wide open for security attacks. The best I could offer you would be a kernel option to disable this security, but I'll say right now that this *won't* be in the 2.1 release. -DG From owner-freebsd-hackers Tue Oct 24 21:01:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25206 for hackers-outgoing; Tue, 24 Oct 1995 21:01:46 -0700 Received: from kaiwan.kaiwan.com (4@kaiwan.kaiwan.com [198.178.203.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25201 for ; Tue, 24 Oct 1995 21:01:42 -0700 Received: from exit.com (uucp@localhost) by kaiwan.kaiwan.com (8.6.12/8.6.12) with UUCP id VAA04875 for hackers@freebsd.org; Tue, 24 Oct 1995 21:01:12 -0700 *** KAIWAN Internet Access *** Received: (from frank@localhost) by exit.com (8.6.12/8.6.12) id UAA26267 for hackers@freebsd.org; Tue, 24 Oct 1995 20:55:46 -0700 From: Frank Mayhar Message-Id: <199510250355.UAA26267@exit.com> Subject: Re: process migration To: hackers@freebsd.org Date: Tue, 24 Oct 1995 20:55:46 -0700 (PDT) In-Reply-To: <199510250325.XAA00130@ns1.win.net> from "Mark Hittinger" at Oct 24, 95 11:25:14 pm X-Mailer: ELM [version 2.4 PL24 ME5a] Content-Type: text Content-Length: 583 Sender: owner-hackers@freebsd.org Precedence: bulk Regarding process migration, Locus "Transparent Network Computing" (TNC) does this using a virtual-process layer analogous to the vnode layer in file systems. TNC does it dynamically using an RPC mechanism. It _is_ a complex problem, particularly when you have to handle things like shared semaphores, locked files, etc., ad nauseum. There were a couple of white papers written on the subject a few years ago. If there's sufficient interest I'll see if I can dig them up. There may also be references on the Locus Web page, http://www.locus.com/. -- Frank Mayhar frank@exit.com From owner-freebsd-hackers Tue Oct 24 21:07:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25679 for hackers-outgoing; Tue, 24 Oct 1995 21:07:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25671 for ; Tue, 24 Oct 1995 21:07:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA18032; Tue, 24 Oct 1995 20:59:29 -0700 From: Terry Lambert Message-Id: <199510250359.UAA18032@phaeton.artisoft.com> Subject: Re: process migration To: bugs@ns1.win.net (Mark Hittinger) Date: Tue, 24 Oct 1995 20:59:29 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510250325.XAA00130@ns1.win.net> from "Mark Hittinger" at Oct 24, 95 11:25:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2557 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > From: Gavin Lim > > We're developing a process migration facility for FreeBSD 2.0.5. Process > > migration is the procedure by which running processes are transferred > > from one computer to another in a network. This would make load sharing > > and load balancing in distributed systems possible. > > In order to transfer a process, we have to save the process state, > > probably save it to a file, and transfer this file to the destination > > computer, where it would be deserialized and converted back to data > > structures. When this is done, the process can resume execution on the > > destination computer. > > This sort of thing has been attempted before in TOPS-10 and VMS. In TOPS-10 > it was called "system sleep" and in VMS it was RUN/CHECKPOINT. > > This would be a very useful feature even in a single processor environment. > If you need to shut the system down for some sort of maintenance, you could > "sleep" the processes and shut down the machine. Then you could reboot > and continue the checkpointed processes. > > It is important to note that these features were beta only and never made > it into an official release (the TOPS-10 one may have). > > Basically the implementation idea was to create a page fault scenario and > page out the entire image. The context of the process would also be saved > in the swap space. > > Then you'd have to copy the swap space context of the process to another > machine, or shutdown/reboot, and then swap the process back in. > > The problems are in file locking, shared memory segments, buffers that > need to be flushed to the file system, etc. There's also other problems: 1) File as swap store. The executable file is acting as its own swap store; this means you must reopen the file (which means you need its name) and reestablish the flags on the vnode to orevent writes to it. 2) Memory overcommit. There very well may not be enough swap to checkpoint the program. 3) Shared libraries. The shared library mappings must be restored, probably seperately. 4) Shared memory, semaphores, etc. 5) Open file descriptors. 6) Network listens (recoverable) and network connections (not recoverable if reliable stream delivery, recoverable for stateless datagrams). 7) Mapped files (other than shared libraries). 8) FIFO/pipe/cooperating process recovery. This is a non-trivial task. 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 Oct 24 21:08:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA25786 for hackers-outgoing; Tue, 24 Oct 1995 21:08:55 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA25778 for ; Tue, 24 Oct 1995 21:08:46 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id VAA11519 for ; Tue, 24 Oct 1995 21:08:36 -0700 Message-Id: <199510250408.VAA11519@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: (Re: Laptop with 800x600 colour LCD found! ) In-reply-to: Your message of "Tue, 24 Oct 1995 11:51:38 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 21:08:34 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk The article in from of me claims that the display is capable of 1024x768 however I just went to Dell's Web site and discover that the display unit is only capable of 800x600 so I would call Dell to get final verification. At any rate, the article is on Computer Currents for October 17-31 on page, 17. Dell 90Mhz Pentium-based Latitude XPiP90St starts at 4,299 for a unit with 8MB of memory, a 420MB hard drive , and a .... 10.4-inch Super VGA Active Matrix capable of resolutions up to ???? http:/www.dell.com Amancio From owner-freebsd-hackers Tue Oct 24 21:21:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26289 for hackers-outgoing; Tue, 24 Oct 1995 21:21:36 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26264 ; Tue, 24 Oct 1995 21:21:24 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id VAA16934; Tue, 24 Oct 1995 21:20:41 -0700 From: Julian Elischer Message-Id: <199510250420.VAA16934@ref.tfs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Tue, 24 Oct 1995 21:20:41 -0700 (PDT) Cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250338.UAA27854@corbin.Root.COM> from "David Greenman" at Oct 24, 95 08:38:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2426 Sender: owner-hackers@freebsd.org Precedence: bulk > > The client should ignore NFS packets from hosts that it's not talking to or > doesn't know about, and that's what all 4.4BSD derived OSs do. unfortunatly it doesn't gain you anything in security to do so however > This is obviously flamebait and I'm not going to respond to it. I'm pretty sure FreeBSD can be made to do the same thing too, given the right icmp packets > > >Sorry for the rambling discourse, but I need this fixed or I can't > >use FreeBSD. At the least, can the "Sun behavior" I need be added > >as an option to the mount command? like most misguided security attempts it should be optional. > > If you choose not to use my suggested work-around, then I guess you can't > use FreeBSD. For the NFS server, FreeBSD (and all other 4.4BSD derived systems) well 4.4BSD derived OS's comprise OSF/1, NetBSD, FreeBSD and BSD/OS. Not exactly aearthshaking combination, and I wouldn't be surprised to see that OSF1 might act differently.. (they are actually net2.5 based) > keep an authentication list in the kernel that is constructed from > /etc/exports. For the NFS client, FreeBSD requires that replies to its RPC > requests come from the same address that they were issued to. If it didn't > work this way, then *anyone* could send bogus udp datagrams with hand-tailored > RPC calls/replies to you and as long as that someone can come up with a file > handle (which is relatively easy), he can do unchecked file operations and > bypass the system security. So? I can make my machine have any address you wish.. and probably still get a packet to your machine.. I mean the source address is not looked at for routing.. It's a security feature to keep out SIMPLE attacks but fails on any really dedicated attack. anyway we're talking being a CLIENT here.. you're talking about being a server, with the exports list.. I didn't notice the exports list being involved in the client side of things.. I think that if we get a patch to make this optional, then we should allow it to be included.. certainly there should be some way to tell NFS that two addresses are equivalent. A Mount option MIGHT work, but you'd have to feed it an alternate IP address.. (not a name) possibbly a routing table entry could be used to do it.. > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. > > -DG > From owner-freebsd-hackers Tue Oct 24 21:27:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26558 for hackers-outgoing; Tue, 24 Oct 1995 21:27:22 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26543 for ; Tue, 24 Oct 1995 21:27:09 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id NAA06939 for hackers@freebsd.org; Wed, 25 Oct 1995 13:53:03 +0930 From: Michael Smith Message-Id: <199510250423.NAA06939@genesis.atrad.adelaide.edu.au> Subject: AF_UNSPEC/SOCK_RAW and such... To: hackers@freebsd.org Date: Wed, 25 Oct 1995 13:53:03 +0930 (CST) Content-Type: text Content-Length: 891 Sender: owner-hackers@freebsd.org Precedence: bulk So I'm getting somewhere with the '485 multidrop stuff. My apologies for being so clueless about the Big Picture 8( I'd _really_ like to be able to talk to it at a socket level, as this will avoid toying around with pcap/bpf and the like. What I'm wondering is whether AF_UNSPEC/SOCK_RAW will just hand my driver the packet as written, or whether it'll break something else. Obviously, suck it and see applies here, but some casual advice from those that have gone before would be muchly appreciated 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Tue Oct 24 21:36:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26975 for hackers-outgoing; Tue, 24 Oct 1995 21:36:30 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26970 for ; Tue, 24 Oct 1995 21:36:28 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id VAA16988; Tue, 24 Oct 1995 21:34:48 -0700 From: Julian Elischer Message-Id: <199510250434.VAA16988@ref.tfs.com> Subject: Re: process migration To: terry@lambert.org (Terry Lambert) Date: Tue, 24 Oct 1995 21:34:47 -0700 (PDT) Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: <199510250359.UAA18032@phaeton.artisoft.com> from "Terry Lambert" at Oct 24, 95 08:59:29 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1624 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > There's also other problems: > > 1) File as swap store. The executable file is acting as its own > swap store; this means you must reopen the file (which means > you need its name) and reestablish the flags on the vnode to > orevent writes to it. write the entire process space including non resident pages.. (implies that shared programs become static ) > > 2) Memory overcommit. There very well may not be enough swap > to checkpoint the program. put it out to a file....... > > 3) Shared libraries. The shared library mappings must be > restored, probably seperately. static.. quite possibly this might be used in a specialist environment (such as what russel is working on,) where shared libs might not be required in any case) > > 4) Shared memory, semaphores, etc. this gets hard, > > 5) Open file descriptors. you can only do a single process, file descriptors not open to files probably are pointed deadfs (as if the other end died) > > 6) Network listens (recoverable) and network connections (not > recoverable if reliable stream delivery, recoverable for > stateless datagrams). listens can probably be re-established if you can track them down.. certainly a certain amount of info can be stored on each fd, and a listen sounds feasible to restart.. > > 7) Mapped files (other than shared libraries). > > 8) FIFO/pipe/cooperating process recovery. > > This is a non-trivial task. I guess that's whey they decided to do it :) > > > > 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 Oct 24 22:04:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27712 for hackers-outgoing; Tue, 24 Oct 1995 22:04:40 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27706 for ; Tue, 24 Oct 1995 22:04:37 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id WAA08911; Tue, 24 Oct 1995 22:03:12 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id WAA04762; Tue, 24 Oct 1995 22:00:39 -0700 Message-Id: <199510250500.WAA04762@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: Julian Elischer cc: terry@lambert.org (Terry Lambert), bugs@ns1.win.net, hackers@FreeBSD.ORG Subject: Re: process migration In-reply-to: Your message of "Tue, 24 Oct 1995 21:34:47 PDT." <199510250434.VAA16988@ref.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Oct 1995 22:00:38 -0700 From: "Russell L. Carter" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > > > There's also other problems: > > > > 1) File as swap store. The executable file is acting as its own > > swap store; this means you must reopen the file (which means > > you need its name) and reestablish the flags on the vnode to > > orevent writes to it. > write the entire process space including non resident pages.. > (implies that shared programs become static ) > > > > 2) Memory overcommit. There very well may not be enough swap > > to checkpoint the program. > put it out to a file....... If overcommitted ignore it. Too bad. > > > > 3) Shared libraries. The shared library mappings must be > > restored, probably seperately. > static.. quite possibly this might be used in a specialist environment > (such as what russel is working on,) where shared libs might not be required > in any case) Righto. Cray Research machines have been checkpointing fine for 10 years. Of course, they only swap and don't page (or didn't use to, I haven't played with the SPARC stuff). Everything is statically linked. Primitive model, works fine with the bulk of *their* workload. Would work fine with my model too, as long as it just applied to user apps. A great deal of effort is expended to protect users from themselves, but if they need checkpointing, the users often are very savvy about getting themselves on the boat. That includes app developers too. Note: this is for jobs that run a minimum of several days, sometimes weeks. Regards, Russell From owner-freebsd-hackers Tue Oct 24 22:11:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA27902 for hackers-outgoing; Tue, 24 Oct 1995 22:11:41 -0700 Received: from subnet.sub.net (root@subnet.sub.net [192.101.75.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA27897 for ; Tue, 24 Oct 1995 22:11:37 -0700 Received: from ud.dinoex.sub.org (root@localhost) by subnet.sub.net (8.6.12/8.6.12) with UUCP id GAA14474; Wed, 25 Oct 1995 06:10:26 +0100 Received: from phase23.dinoex.sub.org by ud.dinoex.sub.org with uucp (Linux Smail3.1.28.1 #14) id m0t7xRL-000JiQC; Wed, 25 Oct 95 05:27 MET Received: from citylink.dinoex.sub.org by phase23.dinoex.sub.org with uucp (CY Smail3.1.28.1 #6) id m0t7xKh-0005KfC; Wed, 25 Oct 95 05:20 MET From: peter@citylink.dinoex.sub.org (Peter Much) Message-Id: <199510241504.QAA05680@citylink.dinoex.sub.org> Received: by citylink.dinoex.sub.org (8.6.12 FreeBSD-1/PMuch) id QAA05680; Tue, 24 Oct 1995 16:04:20 +0100 Subject: Re: modf.S (in libc.a): stack access fault To: bde@zeta.org.au (Bruce Evans) Date: Tue, 24 Oct 1995 16:04:18 +0100 (MET) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199510230625.QAA15714@godzilla.zeta.org.au> from "Bruce Evans" at Oct 23, 95 04:25:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 499 Sender: owner-hackers@freebsd.org Precedence: bulk > $ cc -Wall prog.c > prog.c:4: warning: return-type defaults to `int' > prog.c: In function `main': > prog.c:12: warning: implicit declaration of function `modf' > prog.c:18: warning: control reaches end of non-void function > > `modf' is not declared and so the compiler has to assume that > it returns `int'. Since it actually returns double, the behaviour > is undefined. Oh well... Next time i get stack access trobles, i will look for the most possible explanation first... thanks, Peter From owner-freebsd-hackers Tue Oct 24 22:14:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA28013 for hackers-outgoing; Tue, 24 Oct 1995 22:14:13 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA28006 ; Tue, 24 Oct 1995 22:14:09 -0700 From: mikebo@tellabs.com Received: from tellabk.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t7y9X-000jC3C; Wed, 25 Oct 95 00:13 CDT Received: by tellabk.tellabs.com (4.1/1.9) id AA12294; Wed, 25 Oct 95 00:13:26 CDT Message-Id: <9510250513.AA12294@tellabk.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Wed, 25 Oct 1995 00:13:25 -0500 (CDT) Cc: hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250338.UAA27854@corbin.Root.COM> from "David Greenman" at Oct 24, 95 08:38:46 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2852 Sender: owner-hackers@freebsd.org Precedence: bulk David G. wrote: > The client should ignore NFS packets from hosts that it's not talking to or > doesn't know about, and that's what all 4.4BSD derived OSs do. > OK... thanks for pointing this out. It's news to me. > >I can document this behavior in SunOS, Solaris and HP/UX if it will > >help strengthen the argument... > > This is obviously flamebait and I'm not going to respond to it. > I'm merely trying to make a case: that in order to use FreeBSD in a heterogenous (business) environment, it needs to work with NFS servers in the same way as commerical OSes. I didn't know this was a 4.4BSD-ism. > If you choose not to use my suggested work-around, then I guess you can't > use FreeBSD. OUCH! C'mon, is this how things are supposed to work around here? Your workaround will not work... the routes change on-the-fly! Just to find out _which_ server interface is currently responding requires the client admin to do a "netstat -r | grep destination-net" on the server, and then fix the client system. How do I create an automounter map or fstab that deals with this? Answer: Can't > ... For the NFS client, FreeBSD requires that replies to its RPC > requests come from the same address that they were issued to. ... I know that in some places such security is a necessity - but it's hard for me to picture one of my fellow engineers hand-tailoring RPC calls/replies to hack into a system they can walk up to and reboot with ... ;v) I can't dictate major changes in my corporate network to accomodate what is essentially a hobbyist system. If I can't make it work in that context, what is the likelyhood that this OS will be chosen for anything serious? I agree with the spirit in which the change was made, but let's be practical. If you can't make it work, what good is the security? > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. > I really appreciate that you would consider doing this! I know of at least one other site where this is a problem. I take it this could not simply be an option to mount? - Mike PS> I don't want to come off as being grumpy or confrontational. I like FreeBSD and appreciate all the hard work everyone here does for free. I've been an advocate of FreeBSD (been running it since 1.1), have a lot of time invested in it, and it steams me to think that I can't use it! Sorry for the length of the post. -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Oct 24 22:36:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA28895 for hackers-outgoing; Tue, 24 Oct 1995 22:36:53 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA28890 for ; Tue, 24 Oct 1995 22:36:51 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id WAA17892; Tue, 24 Oct 1995 22:36:23 -0700 From: Julian Elischer Message-Id: <199510250536.WAA17892@ref.tfs.com> Subject: Re: process migration To: rcarter@geli.com (Russell L. Carter) Date: Tue, 24 Oct 1995 22:36:22 -0700 (PDT) Cc: terry@lambert.org, bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: <199510250500.WAA04762@geli.clusternet> from "Russell L. Carter" at Oct 24, 95 10:00:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1923 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > > > > > > > There's also other problems: > > > > > > 1) File as swap store. The executable file is acting as its own > > > swap store; this means you must reopen the file (which means > > > you need its name) and reestablish the flags on the vnode to > > > orevent writes to it. > > write the entire process space including non resident pages.. > > (implies that shared programs become static ) > > > > > > 2) Memory overcommit. There very well may not be enough swap > > > to checkpoint the program. > > put it out to a file....... > > If overcommitted ignore it. Too bad. > > > > > > > 3) Shared libraries. The shared library mappings must be > > > restored, probably seperately. > > static.. quite possibly this might be used in a specialist environment > > (such as what russel is working on,) where shared libs might not be required > > in any case) > > Righto. Cray Research machines have been checkpointing fine for 10 years. Of > course, they only swap and don't page (or didn't use to, I haven't played > with the SPARC stuff). Everything is statically linked. Primitive > model, works fine with the bulk of *their* workload. > > Would work fine with my model too, as long as it just applied to user apps. > > A great deal of effort is expended to protect users from themselves, but > if they need checkpointing, the users often are very savvy about getting > themselves on the boat. That includes app developers too. > > Note: this is for jobs that run a minimum of several days, sometimes > weeks. I could imagine it in the form of a signal that asks the process to pack itself up.. the system supplies the tools to do so, it just has to no which things aren't savable.. then it does a foo() call and when it returns, it's a week later.. and it resumes everything it stopped.. not so good for random processes, but good for specialist stuff > > Regards, > Russell > > > From owner-freebsd-hackers Tue Oct 24 22:50:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA29233 for hackers-outgoing; Tue, 24 Oct 1995 22:50:16 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA29223 for ; Tue, 24 Oct 1995 22:50:14 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id WAA17927; Tue, 24 Oct 1995 22:49:30 -0700 From: Julian Elischer Message-Id: <199510250549.WAA17927@ref.tfs.com> Subject: Re: AF_UNSPEC/SOCK_RAW and such... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 24 Oct 1995 22:49:29 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199510250423.NAA06939@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 25, 95 01:53:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1486 Sender: owner-hackers@freebsd.org Precedence: bulk > > So I'm getting somewhere with the '485 multidrop stuff. My apologies for > being so clueless about the Big Picture 8( > > I'd _really_ like to be able to talk to it at a socket level, as this > will avoid toying around with pcap/bpf and the like. > > What I'm wondering is whether AF_UNSPEC/SOCK_RAW will just hand my > driver the packet as written, or whether it'll break something else. > > Obviously, suck it and see applies here, but some casual advice from those > that have gone before would be muchly appreciated 8) WARNING WARNING WARNING it's been a few years.. what protocol are you wanting to run? will your driver only be handling your packets? do you have your own protocol stack? you can do this but it really depends on you writing it int eh right way for it to work (duh!) coming up: You have to make sure your driver calls the correct protocol with the correct arguments going down: You have to make sure your protocol knows how to decide which interface to send it to.. it does work, but it (in general) requires you to fill in the missing pieces > > -- > ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ > ]] Genesis Software genesis@atrad.adelaide.edu.au [[ > ]] High-speed data acquisition and [[ > ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ > ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ > From owner-freebsd-hackers Tue Oct 24 23:04:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA29595 for hackers-outgoing; Tue, 24 Oct 1995 23:04:09 -0700 Received: from gateway.net.hk (john@gateway.hk.linkage.net [202.76.7.50]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29589 for ; Tue, 24 Oct 1995 23:04:05 -0700 Received: (from john@localhost) by gateway.net.hk (8.6.12/8.6.9) id OAA23769; Wed, 25 Oct 1995 14:00:31 +0800 Date: Wed, 25 Oct 1995 14:00:30 +0800 (HKT) From: John Beukema To: FreeBSD hackers Subject: Telnet and ftp problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I have just installed fbsd 2.05R using the UPDATE boot.flp. The machine is a 386/DX33 with 8MG RAM and a ne1000 clone card. The installation went flawlessly. It is on a LAN with a BSD/OS server and another 2.05R machine. After installation of the generic kernel I can ping the machine (firewall) and it can ping the world. 1. firewall can telnet anywhere but no one can telnet to it. 2. firewall can ftp anywhere, login but when (for example) ls is executed, I get '200 PORT command successful.' and then it hangs until '425 Can't build data connection: Operation timed out.' 3. ftp to firewall acts the same way. I tried tcp.extensions=NO. There is no nameserver problem -- nslookup works on firewall through the BSD/OS server for the whole world (there is no nameserver running on firewall. I get the same behavior trying to telnet from the other fbsd machine, winjef. No problem connecting winjef to the BSD/OS or vice versa. the only difference I can see is ifconfig ef0 flags=8863 on BSD/OS and ifconfig ed1 flags=8863 on firewall. arp appears ok and arp -a shows both as permanent and published. Any assistanace appreciated. jbeukema From owner-freebsd-hackers Tue Oct 24 23:06:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA29672 for hackers-outgoing; Tue, 24 Oct 1995 23:06:04 -0700 Received: from io.org (io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29662 for ; Tue, 24 Oct 1995 23:05:59 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id CAA20413; Wed, 25 Oct 1995 02:05:52 -0400 Date: Wed, 25 Oct 1995 02:06:05 -0400 (EDT) From: Brian Tao To: David Greenman cc: FREEBSD-HACKERS-L Subject: Re: panic: free vnode isn't In-Reply-To: <199510250134.SAA27692@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Tue, 24 Oct 1995, David Greenman wrote: > > >panic: free vnode isn't > >Debugger("panic") > >Stopped at _Debugger+0x2b [/sys/compile/FTPSERV/:261]: movb $0,_inDebugger 110 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Where did that come from? Did you build your kernel with -g or something? > I wouldn't recommend doing that and it's not needed for DDB. I used "config -g FTPSERV" and then a normal "make depend && make". The regular, non-debugging kernel was just a "config FTPSERV". The above three lines were on ttyv0 in white-on-red text (I'm using the pcvt console driver) with the ddb> prompt waiting below it. > Are your using msdosfs on this machine? Nope. I switched back to the non-debugging kernel today and it only ran for about a day before it locked up. Again, no syslog messages or any indication that something went wrong (except that everything is frozen). We left the office at 9:20pm for dinner, and it died at 9:30pm (figures). Is there any other information I should be posting? It runs stock irc 2.8.21 (around 140 users connected to it at peak) and stock wu-ftpd 2.4 (around 40 users connected to it at peak). Could that be too much of a load on the server? The FTP server is chroot'd to a local directory, but anything beneath ~ftp/pub is NFS-mounted. All user home directories are also NFS-mounted. Should I upgrade to the latest snapshot, or fall back to 2.0.5? -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Tue Oct 24 23:14:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA29950 for hackers-outgoing; Tue, 24 Oct 1995 23:14:40 -0700 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA29933 ; Tue, 24 Oct 1995 23:14:16 -0700 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id LAA02274; Wed, 25 Oct 1995 11:12:39 +0500 From: "Serge A. Babkin" Message-Id: <199510250612.LAA02274@hq.icb.chel.su> Subject: Re: startslip isn't just broken - it's EVIL! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 25 Oct 1995 11:12:38 +0500 (GMT+0500) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org In-Reply-To: <11667.814539479@time.cdrom.com> from "Jordan K. Hubbard" at Oct 24, 95 05:57:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1600 Sender: owner-hackers@freebsd.org Precedence: bulk > > > > > > > > Guys! Use slattach and chat, and save yourselves the stress 8) > > > > > > I've never managed to get that combo to work! Chat just dies > > > immediately.. :-( > > > > I got it working under 2.0. There were some strange problems but in > > common it worked. I remember that chat does not understand the dial-up > > string in the command line, it needs a file with it. > > No, that's not the problem here - I have my chat script in a file and > that very same chat script works just fine with chat if I *don't run > it from slattach*. When run from slattach, chat blows up when it > first tries to talk to the port. I don't know what's wrong, but > slattach clearly isn't setting up things correctly before invoking the > external script. I tried for quite a few days to get this to work > and finally gave up in disgust. I remember one more thing. Slattach worked without -z (forced redial) and -u (unit command) flag but hanged if they were set set. Exactly the working configuration was: /etc/start_if.sl0: ------------------ slattach -chs 38400 -r /etc/dialcmd cuaa0 /etc/dialcmd: ------------- chat -t 50 -f /etc/scr >/dev/cuaa0 ; Tue, 24 Oct 1995 23:21:59 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA07301; Tue, 24 Oct 1995 23:21:57 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA28141; Tue, 24 Oct 1995 23:16:54 -0700 Message-Id: <199510250616.XAA28141@corbin.Root.COM> To: Brian Tao cc: FREEBSD-HACKERS-L Subject: Re: panic: free vnode isn't In-reply-to: Your message of "Wed, 25 Oct 95 02:06:05 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 23:16:53 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >On Tue, 24 Oct 1995, David Greenman wrote: >> >> >panic: free vnode isn't >> >Debugger("panic") >> >Stopped at _Debugger+0x2b [/sys/compile/FTPSERV/:261]: movb $0,_inDebugger 110 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Where did that come from? Did you build your kernel with -g or something? >> I wouldn't recommend doing that and it's not needed for DDB. > > I used "config -g FTPSERV" and then a normal "make depend && >make". The regular, non-debugging kernel was just a "config FTPSERV". >The above three lines were on ttyv0 in white-on-red text (I'm using >the pcvt console driver) with the ddb> prompt waiting below it. Okay...but for DDB this really isn't necessary and only results in you losing about 4-6MB of memory for all the unused gdb debugging symbols. In fact, this in itself might cause you problems. >> Are your using msdosfs on this machine? > > Nope. I switched back to the non-debugging kernel today and it >only ran for about a day before it locked up. Again, no syslog >messages or any indication that something went wrong (except that >everything is frozen). We left the office at 9:20pm for dinner, and >it died at 9:30pm (figures). > > Is there any other information I should be posting? It runs stock >irc 2.8.21 (around 140 users connected to it at peak) and stock >wu-ftpd 2.4 (around 40 users connected to it at peak). Could that be >too much of a load on the server? The FTP server is chroot'd to a >local directory, but anything beneath ~ftp/pub is NFS-mounted. All >user home directories are also NFS-mounted. Well, we run a load about ten times that on wcarchive and have failures about once a week that are caused by two known bugs (one disk controller related and the other a VM system problem). I've recently added a bunch of extra debugging code to the kernel in an attempt to isolate the latter problem...but I'm still waiting for the next crash. I think your problem is caused by bug(s) in the NFS client code. While we do test it relatively thoroughly, we don't pond on it in the way that you are doing and that likely explains why the bug hasn't been seen before and fixed. :-) Debugging this problem will almost certainly be quite difficult. It will likely require careful analysis of a variety of data structures, following pointers, etc, and perhaps even analyzing the NFS traffic just before the hang/crash. It's probably caused by some kind of failure condition which isn't properly handled in the NFS client code. Unfortunately, without a lot more information, it's unlikely that I'll be able solve this problem. > Should I upgrade to the latest snapshot, or fall back to 2.0.5? That's always a good idea, perhaps SUPing -stable might be easier. Unfortunately, we haven't fixed any problems that would directly fix the "free vnode isn't" panic, but we have fixed other bugs - so I think you'd benefit by upgrading. -DG From owner-freebsd-hackers Wed Oct 25 00:17:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA01582 for hackers-outgoing; Wed, 25 Oct 1995 00:17:41 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA01577 ; Wed, 25 Oct 1995 00:17:37 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id BAA27796; Wed, 25 Oct 1995 01:19:03 -0600 Date: Wed, 25 Oct 1995 01:19:03 -0600 From: Nate Williams Message-Id: <199510250719.BAA27796@rocky.sri.MT.net> To: "Serge A. Babkin" Cc: jkh@time.cdrom.com (Jordan K. Hubbard), msmith@atrad.adelaide.edu.au, hackers@freebsd.org, ache@freebsd.org Subject: Re: startslip isn't just broken - it's EVIL! In-Reply-To: <199510250612.LAA02274@hq.icb.chel.su> References: <11667.814539479@time.cdrom.com> <199510250612.LAA02274@hq.icb.chel.su> Sender: owner-hackers@freebsd.org Precedence: bulk > I remember one more thing. Slattach worked without -z (forced redial) > and -u (unit command) flag but hanged if they were set set. Exactly the > working configuration was: > Hmm, I'll echo that from my side as well. /etc/start_if.sl0 #!/bin/sh slattach -a -h -r /etc/ppp/slip-dial -s 115200 cuaa1 Jordan, did you use my stuff as I sent it or did you modify the flags and such? Nate From owner-freebsd-hackers Wed Oct 25 00:53:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA02821 for hackers-outgoing; Wed, 25 Oct 1995 00:53:43 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA02671 for ; Wed, 25 Oct 1995 00:46:01 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id RAA07498; Wed, 25 Oct 1995 17:11:35 +0930 From: Michael Smith Message-Id: <199510250741.RAA07498@genesis.atrad.adelaide.edu.au> Subject: Re: AF_UNSPEC/SOCK_RAW and such... To: julian@ref.tfs.com (Julian Elischer) Date: Wed, 25 Oct 1995 17:11:34 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org In-Reply-To: <199510250549.WAA17927@ref.tfs.com> from "Julian Elischer" at Oct 24, 95 10:49:29 pm Content-Type: text Content-Length: 1967 Sender: owner-hackers@freebsd.org Precedence: bulk Julian Elischer stands accused of saying: > > What I'm wondering is whether AF_UNSPEC/SOCK_RAW will just hand my > > driver the packet as written, or whether it'll break something else. > > > > Obviously, suck it and see applies here, but some casual advice from those > > that have gone before would be muchly appreciated 8) > WARNING WARNING WARNING > it's been a few years.. > > what protocol are you wanting to run? PKT-1. It's an inhouse protocol we run over '485. It's light and stupid and designed with microcontrollers in mind. > will your driver only be handling your packets? No; I was hoping to support IP as well, just for genericity's sake. AFAICT, this is only an issue when it comes to handing a datagram upwards. > do you have your own protocol stack? Yes. The protocol is very simple, so it's implemented as a C library at the moment. (We currently talk to these devices under DOS, which is a total loser outside the workshop). > you can do this but it really depends on you writing it int eh right way > for it to work (duh!) Obviously 8) > coming up: > You have to make sure your driver calls the correct protocol with the correct > arguments Indeed. Which protocol to call for AF_UNSPEC? How does NETISR_RAW and schednetisr() come in to this? > going down: > You have to make sure your protocol knows how to decide which interface > to send it to.. Is this not what ifa_ifwithaf() (net/if.c) does? I can't find anything that calls it of course 8( I guess I could go AF_INET and invent SOCK_RAWRAW, but that sounds like just as much work 8( -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 25 01:46:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA04394 for hackers-outgoing; Wed, 25 Oct 1995 01:46:54 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA04356 ; Wed, 25 Oct 1995 01:46:21 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA18410 ; Wed, 25 Oct 1995 09:46:11 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA26653 ; Wed, 25 Oct 1995 09:46:11 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id JAA22857; Wed, 25 Oct 1995 09:39:53 +0100 (MET) From: Ollivier Robert Message-Id: <199510250839.JAA22857@keltia.freenix.fr> Subject: Re: Kerberized Encrypted Telnet for 2.0.5R To: torstenb@FreeBSD.org Date: Wed, 25 Oct 1995 09:39:52 +0100 (MET) Cc: hackers@FreeBSD.org In-Reply-To: from "Torsten Blum" at Oct 25, 95 02:27:00 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1255 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that Torsten Blum said: > > ports/security/ssh/ I know :-) I was just pointing people to the Web site for all the bells and whistles about SSH. The author is very friendly and the program is well thought and made. The X11 forwarding/encrypting is a must. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Sun Oct 22 20:22:48 MET 1995 From owner-freebsd-hackers Wed Oct 25 02:06:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA05290 for hackers-outgoing; Wed, 25 Oct 1995 02:06:15 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA05284 ; Wed, 25 Oct 1995 02:06:10 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t81mi-0003x4C; Wed, 25 Oct 95 02:06 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA03187; Wed, 25 Oct 1995 10:06:06 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: mikebo@tellabs.com cc: davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Wed, 25 Oct 1995 00:13:25 EST." <9510250513.AA12294@tellabk.tellabs.com> Date: Wed, 25 Oct 1995 10:06:05 +0100 Message-ID: <3185.814611965@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk > David G. wrote: > > The client should ignore NFS packets from hosts that it's not talking to or > > doesn't know about, and that's what all 4.4BSD derived OSs do. > > > OK... thanks for pointing this out. It's news to me. I guess you could fix this if you have proper multihoming defined in the DNS/hosts, and let mountd handle it. The other way would be to connect(2) the udp socket or alternatively to use tcp (and nfsv3 ?)... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-hackers Wed Oct 25 02:13:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA05595 for hackers-outgoing; Wed, 25 Oct 1995 02:13:44 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA05582 for ; Wed, 25 Oct 1995 02:13:19 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id SAA07697 for hackers@freebsd.org; Wed, 25 Oct 1995 18:40:09 +0930 From: Michael Smith Message-Id: <199510250910.SAA07697@genesis.atrad.adelaide.edu.au> Subject: Debugging interrupt service routines... To: hackers@freebsd.org Date: Wed, 25 Oct 1995 18:40:08 +0930 (CST) Content-Type: text Content-Length: 735 Sender: owner-hackers@freebsd.org Precedence: bulk Can someone give me a definite 'yes' or 'no' to "Is it safe to call printf() in the kernel from an interrupt handler?" I'm getting a lot of GP faults courtesy of syslogd, and I suspect that this is the problem, but I'd like to be sure. (Then there's the nuisance where savecore causes an IO check and another panic. This goes around in circles 8( ) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 25 03:03:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA07466 for hackers-outgoing; Wed, 25 Oct 1995 03:03:20 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA07418 for ; Wed, 25 Oct 1995 03:02:33 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id SAA00668 for freebsd-hackers@freebsd.org; Wed, 25 Oct 1995 18:01:39 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-hackers@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-hackers@freebsd.org Date: 25 Oct 1995 18:01:34 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <46l1tu$km$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199510231841.MAA22178@rocky.sri.MT.net>, <199510232113.OAA11769@phaeton.artisoft.com> Subject: Re: Netscape puzzle Sender: owner-hackers@freebsd.org Precedence: bulk terry@lambert.org (Terry Lambert) writes: >> Terry Lambert writes: >> [ Netscape not working ] >> > Another potential datapoint: >> > >> > We are all aware of the bind/sendmail static data initialization shared >> > library changes, right? >> >> Refreh my memory. >They changed the initializations to something that would allow copy on >write shared library data to be used as well. >Basically, it's getting rid of local data for crappy shared library >implementations. Uhh... Am I missing something? This thread is about netscape, yes? Netscape is linked *static*, and has it's own self-contained resolver. Shared libraries dont even come into the picture, because BSDI (1.1) doesn't *have* them... >If you mixed old and new implementations (check the bind release notes), >then the behaviour became undefined, even if you recompiled everything. >One (hack) fix is to call the initialization before it's strictly >allowed. Our implementation of the resolver is not an issue with netscape, because our resolver is not loaded into netscape. Sendmail had the problem, yes. >> > The ones that Matt Day reported and provided patches for in both Linux >> > and BSD and to the package authors? >> >> I don't remember seeing it. Was in on the ports mailing list? >No. It was on hackers and it was sent to one or more NetBSD and Linux >lists, as well as being mailed to Allman & company. If you mean the RES_INIT and res_init() patch, that's already in sendmail, but isn't a 'netscape puzzle' issue... From memory somebody's already mentioned that there is an issue of the resolver code inside the statically linked netscape/bsdi executable using select for a timeout, while netscape is using setitimer which is disturbing the method that the resolver is using to detect a timeout on the select. (or something like that.. :-) -Peter > 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 Oct 25 05:03:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA10885 for hackers-outgoing; Wed, 25 Oct 1995 05:03:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA10877 for ; Wed, 25 Oct 1995 05:03:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA00368; Wed, 25 Oct 1995 21:41:46 +1000 Date: Wed, 25 Oct 1995 21:41:46 +1000 From: Bruce Evans Message-Id: <199510251141.VAA00368@godzilla.zeta.org.au> To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: Debugging interrupt service routines... Sender: owner-hackers@freebsd.org Precedence: bulk >Can someone give me a definite 'yes' or 'no' to >"Is it safe to call printf() in the kernel from an interrupt handler?" It isn't safe, but we do it anyway. Suppose syscons is doing some critical operation and you interrupt it and print something. Who can say what might happen? Even ddb uses ordinary console output although it has its own printf routine (it doesn't really need one - printf itself is reentrant). The serial console i/o routines are simpler and can't crash the system due to interference with ordinary serial i/o AFAIK. Bruce From owner-freebsd-hackers Wed Oct 25 06:19:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13368 for hackers-outgoing; Wed, 25 Oct 1995 06:19:03 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13358 for ; Wed, 25 Oct 1995 06:19:00 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27314; Wed, 25 Oct 1995 06:17:07 -0700 To: Gavin Lim Cc: hackers@freefall.FreeBSD.org In-reply-to: Your message of "Tue, 24 Oct 1995 19:22:56 PDT." <199510250226.TAA19363@freefall.freebsd.org> Date: Wed, 25 Oct 1995 06:17:07 -0700 Message-ID: <27312.814627027@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > In order to transfer a process, we have to save the process state, > probably save it to a file, and transfer this file to the destination > computer, where it would be deserialized and converted back to data > structures. When this is done, the process can resume execution on the > destination computer. Ah, my favorite axe to grind! :-) [ everyone else covers their eyes: "Oh no! Not this again!" :) ] Yes, you've stumbled onto one of the "hard problems" that a lot of UNIX vendors have simply punted on after examining it. It's not a trivial one and solving it will take a fairly fundamental re-think about how a process' "relationship" with the host computer is handled. The biggest bugaboo is the file table. Assuming that saving the process text, data and stack information is a problem you've solved (which would either require that we stop paging directly out of executables or that the relationship between process and executable became rather more abstract) you've still got to worry about all the files it has open and its controlling TTY. What happens when the image is reactivated on the other host? Do its file I/O requests to any now non-local files go back to the original host, do you assume a homogenous AFS-like file system for which all files have universal IDs, or what? The Sprite project's efforts to solve this problem ended up producing a system that didn't look much like UNIX anymore! In other words, I doubt that the people on this list are going to be able to help you all that much, at least not relative to our current code base. You have some substantial re-architecting ahead of you! Jordan From owner-freebsd-hackers Wed Oct 25 06:28:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13791 for hackers-outgoing; Wed, 25 Oct 1995 06:28:15 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13764 ; Wed, 25 Oct 1995 06:28:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27344; Wed, 25 Oct 1995 06:27:34 -0700 To: davidg@Root.COM cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Tue, 24 Oct 1995 20:38:46 PDT." <199510250338.UAA27854@corbin.Root.COM> Date: Wed, 25 Oct 1995 06:27:33 -0700 Message-ID: <27341.814627653@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > This is obviously flamebait and I'm not going to respond to it. I don't think he meant it as flamebait, I read it as him simply trying to state a position (which he did at least mark with a "soapbox on", thus indicating that he knew it to be a contraversal issue) that if FreeBSD can't interoperate with the big boys, then people aren't going to praise FreeBSD for taking the high road, they're going to say that FreeBSD is crap because it can't even talk to the most popular workstation platform on the planet. I can at least see where he's coming from! > bypass the system security. Other commercial vendors are running old security > broken versions of NFS and this makes them wide open for security attacks. And I can see your point as well. Clearly, it's Sun that needs to clean their house and not us.. They've screwed the pooch and I hope Mike can at least understand the natural horror reaction at proposing we lobotomize our security just to cope with someone else's total lack of it. Maybe we can reach a compromise.. > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. I agree - 2.1 is simply too close, though I see no reason why the power-users won't be able to retrofit your solution from 2.2. Still, this strikes me as a problem we're going to see reported often enough that maybe we should make it a MIB variable instead of a kernel compile option, ala the net.inet.tcp.rfc* knobs we already support. Jordan From owner-freebsd-hackers Wed Oct 25 07:05:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14849 for hackers-outgoing; Wed, 25 Oct 1995 07:05:38 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14844 for ; Wed, 25 Oct 1995 07:05:35 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id KAA27493; Wed, 25 Oct 1995 10:02:26 -0400 Date: Wed, 25 Oct 1995 10:02:26 -0400 (EDT) From: "Ron G. Minnich" To: "Jordan K. Hubbard" cc: Gavin Lim , hackers@freefall.freebsd.org Subject: migration In-Reply-To: <27312.814627027@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk i forgot to mention condor source code for checkpoint/migrate is available for the cost of an ftp to cs.wisc.edu. It works, does not solve every problem, but is good enough to use for many things. ron From owner-freebsd-hackers Wed Oct 25 07:21:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15334 for hackers-outgoing; Wed, 25 Oct 1995 07:21:56 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15324 ; Wed, 25 Oct 1995 07:21:52 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27480; Wed, 25 Oct 1995 06:56:01 -0700 To: Nate Williams cc: "Serge A. Babkin" , msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org, ache@FreeBSD.org Subject: Re: startslip isn't just broken - it's EVIL! In-reply-to: Your message of "Wed, 25 Oct 1995 01:19:03 MDT." <199510250719.BAA27796@rocky.sri.MT.net> Date: Wed, 25 Oct 1995 06:56:01 -0700 Message-ID: <27477.814629361@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk I used it just as you sent it, and what's more I just finished re-installing the machine from the ground up with -stable bits. Kernel and all. Same problem! :-( Jordan > > I remember one more thing. Slattach worked without -z (forced redial) > > and -u (unit command) flag but hanged if they were set set. Exactly the > > working configuration was: > > > > Hmm, I'll echo that from my side as well. > > /etc/start_if.sl0 > > #!/bin/sh > slattach -a -h -r /etc/ppp/slip-dial -s 115200 cuaa1 > > > Jordan, did you use my stuff as I sent it or did you modify the flags > and such? > > > Nate From owner-freebsd-hackers Wed Oct 25 07:33:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15914 for hackers-outgoing; Wed, 25 Oct 1995 07:33:32 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA15800 for ; Wed, 25 Oct 1995 07:32:25 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from sirius.physik.fu-berlin.de (130.133.3.140) with smtp id ; Wed, 25 Oct 95 15:27 MET Received: by sirius.physik.fu-berlin.de; id AA00851; Wed, 25 Oct 1995 15:27:32 +0100 From: Thomas Graichen Message-Id: <9510251427.AA00851@sirius.physik.fu-berlin.de> Subject: disk-sriping To: hackers@freebsd.org Date: Wed, 25 Oct 1995 15:27:32 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 837 Sender: owner-hackers@freebsd.org Precedence: bulk hello i remember that someone experimented with disk-striping in the past - is there anything coming into the FreeBSD tree in the next time ? - is anybody working on that ? - if not i would like to adapt the NetBSD ccd driver to FreeBSD - has anybody else tried it (to avoid reinventing the wheel) thanks in advance - t _______________________________________________________||_____________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| ___________________________||____email: graichen@omega.physik.fu-berlin.de____ From owner-freebsd-hackers Wed Oct 25 07:58:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA17771 for hackers-outgoing; Wed, 25 Oct 1995 07:58:24 -0700 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA17750 ; Wed, 25 Oct 1995 07:58:14 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id JAA09084; Wed, 25 Oct 1995 09:58:04 -0500 Date: Wed, 25 Oct 1995 09:58:04 -0500 From: Mark Tinguely Message-Id: <199510251458.JAA09084@plains.nodak.edu> To: davidg@Root.COM, mikebo@tellabs.com Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Cc: bugs@freebsd.org, hackers@freebsd.org Content-Length: 555 Sender: owner-hackers@freebsd.org Precedence: bulk what is the IP number of tellabk and sunk (or if this is private, what is the relationship between these two numbers is sunk IP < tellabk IP)? If I remember correctly when I was playing with IP aliases (ie "multi-homed"), on a new connection from a multi-homed FreeBSD machine, the multi-homed machine used lowest IP number whether the lowest IP was the real (ifconfig without an alias) interface address or not. I think this operation is incorrect. UDP and TCP should alway orginate the real address not the lowest (possibly and alias) address. --mark. From owner-freebsd-hackers Wed Oct 25 08:09:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18480 for hackers-outgoing; Wed, 25 Oct 1995 08:09:39 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18464 for ; Wed, 25 Oct 1995 08:09:31 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA10257; Thu, 26 Oct 1995 01:06:56 +1000 Date: Thu, 26 Oct 1995 01:06:56 +1000 From: Bruce Evans Message-Id: <199510251506.BAA10257@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >> >When a system call is made, arguments are pushed on the user stack >> >and then the trap vector is called. There is a necessity to copy >> ... >> Only in some ABI's. This is probably the best way, but it may >> requires messy conversions in the library to put the args on the >> stack with consistent padding. >Pushing on the stack is a messy conversion? What about dead register Deciding what to push is messy. You have to decode the flags that say where the args are. This may have to be written in assembler. >usage from not knowing about the stack? I think you are going to >have to burn the cycles on an opaque function call in any case. I hope that null conversions won't cost anything. Conversions of the form `int fd = uap->fd;' (actually machine-generated code to load fd from an ABI-dependent offset from `void *uap') may even have a negative cost if they happen to load fd into the right register at the right time. >> Since we don't control foreign ABI's we shouldn't assume this. For > >That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's >either 'int' or 'long' or '*'. Which one? In NetBSD it's register_t, which may be longer than an int. This causes problems. >So we take a hit when processing these non-standard mechanisms; we do >so through the system call table for the ABI, so we will be taking >a function encapsulation hit anyway. Inlining should remove the hit. Perhaps given smarter encapsulation functions, the hit from syscall() could be removed: call the encapsulation function directly from Xsyscall() and duplicate what syscall() does (copyin(), etc, iff necessary) in each encapsulation function. >They are padded to the default bus transfer size for the machine, >which is supposed to be 'int'. >I'd argue that 'int' was the wrong size [on the alpha], not that >there was extraneous >padding. This may be true if you control the ABI. >I'd really dealy love to know how there could be an endianess issue, >considering system calls are only ever going to run as compiled code >on one endianess of machine. To run user code on one machine and syscalls on another. I wouldn't want that. >> >What does it do? What use is the change? >> >> It avoids scattering unportable casts and ugly macros to perform them >> throughout the "machine-independent" code. Now we have only unportable >> casts. 4.4lite2 has slightly less unportable casts and ugly macros. >> NetBSD has much less unportable casts and ugly macros. >The structure casts, I presume? Yes. >The answer is to compile with the packing being the default for data >matchup -- in the alpha case, 64 bits. For devices that need it, use >packing #pragma's to tighten them up on a case by case basis, in the >header file defining the structure. That won't help much. The problem is that syscall args don't form a struct. Even if they are in memory, the packing may be different. This can probably be handled by using __attribute__ ((packed)) for every arg to enforce a particular layout. But that would only work with gcc. I suggest using machine-generated code of the form `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. >Aligned element accesses are faster anyway. OFFSET would usually be a multiple of the alignment so it would be easy to calculate :-). >> Earth to Terry :-). We're talking about inlining syscall handlers, not >> syscalls. >Sorry -- you're the one that brought up ABI, which is kernel code, not >user space code. The only way you can effect the ABI code is if you >call the inlined versions and match the user and kernel usage. The ABI is a convention, and can't be changed. >> There may be no correct size. A size of 3 ints wouldn't work for >> open("foo", 0) if the caller has perversely passed 2 args on the stack >> at the top of the address space. Where are the ABI specs that disallow >> this? >There are none. However, you are wrong; it would work, you'd just >get a garbage value (stack direction grows the right direction for >the third argument to be optional). Since in that case the garbage >value is unreferenced (or the call generated a prototype warning >...not 8-)), then it will work. I should get an EFAULT return if the args are at the top of the address space like I said. >> >What portability problems do you see in the system call multiplex >> >interfaces, and under what circumstances can you cause incorrect code >> >to be generated? >> >> A reasonable parameter passing convention should put the first few >> args (a fixed number) in registers but stop at the first `...' arg or >> the one before (so a variable number of args may be in registers. >> Where are you going to translate this? Portability problems would >> result from delaying the translation. Incorrect code would be generated, >> as usual, due to bugs. >I have to point out that it would then be impossible to make system >calls without prototype references. If this is a "fix" for the quad >word passing problem (which is a "non-use of system call prototype" >problem), then, isn't this just making things worse? It requires either prototypes or passing parameters of the correct type just like it always did. Since there is a lot of broken code out there, most compilers use inferior parameter passing conventions to support the broken code. >Callee pop only works when using the same stack. When you get to the >kernel, the kernel thread (or just process) will be using its own stack, >so that argument won't wash. My complaint on callee pop as a more >fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. Of course you wouldn't want to use it across interfaces, but how do you stop a C compiler that is optimized for compiling user code from producing wrong code for interfaces that it doesn't support? (Writing masses of interface code in assembler isn't acceptable.) >Right now the screwable functions are truncate, ftruncate, seek, lseek, >and mmap -- and mmap() is bogus because of the kernel address space >restrictions currently on "vmio". The others are in violation of one >or more standards because "quad" isn't an allowable type. Might as >well violate them further by using inline references to the __syscall(2) >instead of syscall(2) to get to them so that: (1) they are undefined >without proper header inclusion, and (2) the padding is guaranteed >(as the __syscall(2) states in the man page). That at least would solve >the screwups without adding to them. I've thought of changing the compiler to always check format args and print a diagnostic if there is a mismatch for a quad arg. Something similar could be done for the above functions - make them builtins and complain about type mismatches for them. For functions it's easier to silently DTRT (promote the args). Bruce From owner-freebsd-hackers Wed Oct 25 09:21:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23884 for hackers-outgoing; Wed, 25 Oct 1995 09:21:11 -0700 Received: from pancake.remcomp.fr (pancake.remcomp.fr [194.51.30.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA23805 for ; Wed, 25 Oct 1995 09:20:28 -0700 Received: from zapata.omnix.fr.org (zapata.omnix.fr.org [128.127.10.1]) by zapata.omnix.fr.org (8.6.9/8.6.9) with SMTP id SAA00306 for ; Wed, 25 Oct 1995 18:16:25 +0100 Date: Wed, 25 Oct 1995 18:16:25 +0100 (MET) From: Didier Derny To: hackers@freebsd.org Subject: help: (question not directly on freebsd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hi a friend of mine wants to start a non profit organization (association) to help people to get the best information on aids (specially the new treatment). So I try to find a company or organization that could host a small web server (a few pages) and a mailing list for a very low cost. I would prefer a site using FreeBSD Thanks for your help +---------------------+ | Didier Derny | | didier@omnix.fr.org | +---------------------+ From owner-freebsd-hackers Wed Oct 25 09:30:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24760 for hackers-outgoing; Wed, 25 Oct 1995 09:30:07 -0700 Received: from public.wintek.com (public.wintek.com [199.233.104.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA24754 for ; Wed, 25 Oct 1995 09:30:05 -0700 Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by public.wintek.com (8.6.12/1.05wintek(3.6davy)) with ESMTP id LAA10630; Wed, 25 Oct 1995 11:29:24 -0500 Received: (from rjk@localhost) by watson.grauel.com (8.6.11/8.6.9) id LAA04488; Wed, 25 Oct 1995 11:34:40 -0500 Date: Wed, 25 Oct 1995 11:34:40 -0500 Message-Id: <199510251634.LAA04488@watson.grauel.com> From: Richard J Kuhns To: freebsd-hackers@freebsd.org Subject: mytinfo configuration -- FreeBSD 2.0.5 Sender: owner-hackers@freebsd.org Precedence: bulk Is there a (good) reason that the default configuration for libmytinfo.a doesn't include terminfo support? I'm working on an enhanced print spooler that will support some/all of the `-o' options (to set chars/line, lines/inch, etc), and it would be very nice to use the same terminfo files I use under SVR4. All I had to do to include the terminfo support was 1) in /usr/src/lib/libmytinfo/config.h, change `#undef USE_TERMINFO' to `#define USE_TERMINFO', 2) make install, 3) mkdir /usr/lib/terminfo, 4) and `tic' my printer's terminfo file. I'd like to suggest that future releases (I know it's probably too late for 2.1) include terminfo support as the default. This change shouldn't affect existing programs that use mytinfo, since there are no terminfo files in a standard installation. -- Rich Kuhns rjk@grauel.com PO Box 6249 100 Sawmill Road Lafayette, IN 47903 (317)477-6000 x319 From owner-freebsd-hackers Wed Oct 25 09:41:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25279 for hackers-outgoing; Wed, 25 Oct 1995 09:41:43 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA25268 ; Wed, 25 Oct 1995 09:41:41 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA13947; Wed, 25 Oct 1995 12:41:30 -0400 Date: Wed, 25 Oct 1995 12:41:30 -0400 From: "Garrett A. Wollman" Message-Id: <9510251641.AA13947@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: davidg@root.com, mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-Reply-To: <27341.814627653@time.cdrom.com> References: <199510250338.UAA27854@corbin.Root.COM> <27341.814627653@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk < said: > I agree - 2.1 is simply too close, though I see no reason why the > power-users won't be able to retrofit your solution from 2.2. Still, > this strikes me as a problem we're going to see reported often enough > that maybe we should make it a MIB variable instead of a kernel > compile option, ala the net.inet.tcp.rfc* knobs we already support. Wrong part of the MIB. You can add support for practically any NFS parameter you want under fs.nfs. There should probably be a lot more; I only implemented the statistics because of the pressing need to get `nfsstat' working with LKMed NFS. Someone who knows a lot about NFS should be able to come up with all sorts of useful parameters to tune. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hackers Wed Oct 25 09:47:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25868 for hackers-outgoing; Wed, 25 Oct 1995 09:47:25 -0700 Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA25847 for ; Wed, 25 Oct 1995 09:47:14 -0700 From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id RAA04194; Wed, 25 Oct 1995 17:46:31 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 25 Oct 95 17:43:11 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 25 Oct 95 16:43:08 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Wed, 25 Oct 95 16:43:08 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:369-951025164308-2939] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Wed, 25 Oct 95 16:43:08 +0000 Content-Identifier: Re(2): panic: fr Message-Id: <"MAC-951025164255-1E49*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: FREEBSD-HACKERS-L Cc: taob@io.org, David Greenman In-Reply-To: <"SunOS:857-951025122108-11BB*/DD.RFC-822=owner-hackers(a)freebsd.org/O=internet/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/"@MHS> Subject: Re(2): panic: free vnode isn't Sender: owner-hackers@freebsd.org Precedence: bulk > Nope. I switched back to the non-debugging kernel today and it > only ran for about a day before it locked up. Again, no syslog > messages or any indication that something went wrong (except that > everything is frozen). We left the office at 9:20pm for dinner, and > it died at 9:30pm (figures). > ... > too much of a load on the server? The FTP server is chroot'd to a > local directory, but anything beneath ~ftp/pub is NFS-mounted. All > user home directories are also NFS-mounted. This sounds a little like a problem we have been having - which I haven't reported previously as I have not had time to characterise it properly. However, it goes somthing like this... Server is running 2.0.5R (with more recent SCSI drivers from -STABLE a few weeks ago, probably not important). It is configured as both NFS server and client, and also runs SAMBA to serve files to Windows machines. Some of the Windows users mount partitions through SAMBA which are in turn NFS mounted by the server from a third machine. All this worked fine for some months, although with very occasional freezes - usually when one of the DOS machines had been crashed and rebooted, but otherwise inexplicable. More recently, Windows 95 has appeared on the scene, and when a Win95 machine accesses files on one of these SAMBA->NFS mounted partitions, the freeze happens consistently. The nature of the freeze is some kind of deadlock in the filesystem - if you catch it just after the freeze, terminal/telnet sessions are normally still alive, but as soon as they touch the filesystem they also block forever - and things like mail check in the shell etc. means that most processes end up frozen after a few minutes. The problem has completely gone away since we moved all the files used by the Windows users onto local discs on the server, so the problem would appear to lie in the NFS client code. My best guess is that this relates to the fact that SAMBA appears to do non-blocking I/O on files, in order to serve multiple request in parallel from a given client (there is one SAMBA process per client) - presumably Win3.11 never makes multiple requests in parallel apart from the special case of crashing between submitting a request and getting the result, wheras Win95 requests in parallel as a matter of course??? Changing compile options on SAMBA to USE_MMAP=1 appeared to have a beneficial effect, though I can't afford to run these sort of tests on our main fileserver to be sure. [Apologies if this is a known bug or not relevant to the problem in hand - I had been meaning to set up a spare machine with -STABLE and reproduce the problem there before posting about it]. Andrew. andrew.gordon@net-tel.co.uk From owner-freebsd-hackers Wed Oct 25 09:57:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA26883 for hackers-outgoing; Wed, 25 Oct 1995 09:57:58 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA26864 ; Wed, 25 Oct 1995 09:57:54 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA28528; Wed, 25 Oct 1995 09:56:45 -0700 To: "Garrett A. Wollman" cc: davidg@root.com, mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Wed, 25 Oct 1995 12:41:30 EDT." <9510251641.AA13947@halloran-eldar.lcs.mit.edu> Date: Wed, 25 Oct 1995 09:56:45 -0700 Message-ID: <28525.814640205@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > compile option, ala the net.inet.tcp.rfc* knobs we already support. > > Wrong part of the MIB. You can add support for practically any NFS > parameter you want under fs.nfs. There should probably be a lot more; Sorry, I by no means meant to imply that the NFS options should go under net.inet.tcp.*! I'm not quite *that* stupid.. :-) I merely cited these as examples of "work around" options that deal with broken external-world situations and are implemented as MIB variables. Jordan From owner-freebsd-hackers Wed Oct 25 11:20:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03041 for hackers-outgoing; Wed, 25 Oct 1995 11:20:01 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03030 ; Wed, 25 Oct 1995 11:19:56 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19141; Wed, 25 Oct 1995 11:11:38 -0700 From: Terry Lambert Message-Id: <199510251811.LAA19141@phaeton.artisoft.com> Subject: SUGGESTED PROJECT To: current@freebsd.org, hackers@freebsd.org Date: Wed, 25 Oct 1995 11:11:38 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 340 Sender: owner-hackers@freebsd.org Precedence: bulk TO DO: A File system that presents a mail spool directory but is in fact a POP3/IMAP client. When iterated by a user, it shows only that user's mailbox (this should allow automatic authentication). 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 Oct 25 11:38:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03945 for hackers-outgoing; Wed, 25 Oct 1995 11:38:23 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03940 for ; Wed, 25 Oct 1995 11:38:21 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id LAA24356; Wed, 25 Oct 1995 11:37:49 -0700 From: Julian Elischer Message-Id: <199510251837.LAA24356@ref.tfs.com> Subject: Re: Correct kernel ops for Panic To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Wed, 25 Oct 1995 11:37:49 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199510251803.OAA08396@crh.cl.msu.edu> from "Charles Henrich" at Oct 25, 95 02:03:57 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 510 Sender: owner-hackers@freebsd.org Precedence: bulk > On some versions of FreeBSD, you can see the last panic with dmesg.. no idea what decides if this will happen or not.. > What would the correct set of kernel options be to ensure that during a system > panic I get: > > 1) The panic and related messages in /var/log/messages > 2) The system immediatly reboots with no user intervention > > Thanks! > > -Crh > > Charles Henrich Michigan State University henrich@crh.cl.msu.edu > > http://rs560.msu.edu/~henrich/ > From owner-freebsd-hackers Wed Oct 25 11:44:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA04596 for hackers-outgoing; Wed, 25 Oct 1995 11:44:45 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA04590 for ; Wed, 25 Oct 1995 11:44:42 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA19200; Wed, 25 Oct 1995 11:35:29 -0700 From: Terry Lambert Message-Id: <199510251835.LAA19200@phaeton.artisoft.com> Subject: Re: process migration To: julian@ref.tfs.com (Julian Elischer) Date: Wed, 25 Oct 1995 11:35:28 -0700 (MST) Cc: terry@lambert.org, bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: <199510250434.VAA16988@ref.tfs.com> from "Julian Elischer" at Oct 24, 95 09:34:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3936 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 1) File as swap store. The executable file is acting as its own > > swap store; this means you must reopen the file (which means > > you need its name) and reestablish the flags on the vnode to > > orevent writes to it. > > write the entire process space including non resident pages.. > (implies that shared programs become static ) If we could easily do this, we'd be doing it already for file systems flagged remote and we'd be over the Sun "dataless client hang on server down" bug already. For a remote file system, we'd force clean pages into swap and dissociate the binaries fd. This is also the fix for returning ETXTBSY messages: when you are thinking of returning one,force the image to swap, dissociate the fd, and never return an ETXTBSY. Shared libraries don't necessarily need to be included IF the fixup vectors can be reset so future reference cause a refixup -- the shared library could be swapped out under a running process, assuming the migration waited for the library to not be entered. Since this is a kernel operation in any case, this could be done using the program counter to check. The alternative to delaying is to cause the library to "go static" if it is entered, or reset the vector table if it is not. > > 2) Memory overcommit. There very well may not be enough swap > > to checkpoint the program. > > put it out to a file....... This is unsatisfactory, actually. The migration of a process is tantamount to 1/Nth (N == average number of processes) of the work needed for a full suspend/resume. > > 3) Shared libraries. The shared library mappings must be > > restored, probably seperately. > > static.. quite possibly this might be used in a specialist environment > (such as what russel is working on,) where shared libs might not be required > in any case) That's certainly one possible cop-out. 8-). > > 4) Shared memory, semaphores, etc. > > this gets hard, Anything involving potentitally unrecoverable state is. It means you must shadow the state creation process to allow the state to be recreated. > > 5) Open file descriptors. > > you can only do a single process, file descriptors not open to files > probably are pointed deadfs (as if the other end died) The file descriptors open to files are the problem. This is because of the vnode issue for open-but-deleted files, and for the inode mapping issue. All you have to go on is the inode and device, and on a target system after migration, they won't necessarily be the same (the probably won't be) since files are accessed symbolically (by name). You will need to record the file names at open/creat time, and deal with descriptor cloning in fcntl, dup, dup2, etc. -- in the kernel. This is expensive, and can't be a general facilty because of the memory requirements. > > 6) Network listens (recoverable) and network connections (not > > recoverable if reliable stream delivery, recoverable for > > stateless datagrams). > > listens can probably be re-established if you can track them down.. > certainly a certain amount of info can be stored on each fd, and a listen > sounds feasible to restart.. Yeah. Though without content addressing on the network (something I've been pushing on for literally years), client won't necessarily be able to find the migrated process, since it has to be done by machine address. [ ... ] > > This is a non-trivial task. > I guess that's whey they decided to do it :) The first step is checkpoint/restart on a single system. Worry about actually migrating the things later. This saves you the kernel code for file name and similar per-system uniform symbolic translations. It's quite possible to recover an fd from a dev/inode pair if you are on the same system and it's not a deleted file: NFS does it all the time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 25 11:49:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA04885 for hackers-outgoing; Wed, 25 Oct 1995 11:49:36 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA04878 for ; Wed, 25 Oct 1995 11:49:33 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA16635 for ; Wed, 25 Oct 1995 11:49:25 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id OAA28724; Wed, 25 Oct 1995 14:43:02 -0400 Date: Wed, 25 Oct 1995 14:43:02 -0400 (EDT) From: "Ron G. Minnich" To: Theo de Raadt , hackers@freebsd.org Subject: anatomy of rfork, part 1: minherit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk i've had enough q's on this, and time is tight, so i thought i'd just put out a few messages on how to do rfork. The code is small, so bear with me. To do rfork as i needed it, you really need two parts to start with: a way to share data after fork and a way to share file tables after fork. AIX/370 implemented DCE threads with these two things. I thought i'd show minherit first. I don't know the plan9 environment erasing stuff, although that is pretty easy to add -- could be useful. minherit is shown below. Calls are much like mprotect: minherit(caddr, len, new inherit values) Look in vm/vm_inherit.h All you need to do is take the mprotect call code and redo it just a bit so it calls vm_map_inherit. Here we go: struct mprotect_args { caddr_t addr; int len; int inherit; }; int minherit(p, uap, retval) struct proc *p; struct mprotect_args *uap; int *retval; { vm_offset_t addr; vm_size_t size; register vm_inherit_t inherit; #ifdef DEBUG printf("minherit(%d): addr %x len %x prot %d\n", p->p_pid, uap->addr, uap->len, uap->inherit); #endif addr = (vm_offset_t)uap->addr; if ((addr & PAGE_MASK) || uap->len < 0) return(EINVAL); size = (vm_size_t)uap->len; inherit = uap->inherit; switch (vm_map_inherit(&p->p_vmspace->vm_map, addr, addr+size, inherit)) { case KERN_SUCCESS: #ifdef DEBUG printf("works\n"); #endif return (0); case KERN_PROTECTION_FAILURE: #ifdef DEBUG printf("fails\n"); #endif return (EACCES); } #ifdef DEBUG printf("return einval\n"); #endif return (EINVAL); } From owner-freebsd-hackers Wed Oct 25 12:04:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA05854 for hackers-outgoing; Wed, 25 Oct 1995 12:04:24 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA05837 for ; Wed, 25 Oct 1995 12:04:19 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA28836; Wed, 25 Oct 1995 15:02:54 -0400 Date: Wed, 25 Oct 1995 15:02:53 -0400 (EDT) From: "Ron G. Minnich" To: Theo de Raadt , hackers@freebsd.org Subject: Re: anatomy of rfork, part 2: fork code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk This one is really easy. Basically you have to mod the fork code to take an option that indicates whether you dup the open file table for the process or simply bump the use count and use it for the child. The segment inheritance management has been done at this point: it gets done in user mode via the minherit() i showed in the previous note. I delete the middle parts that don't change ... it's about 10 lines of difference from a regular fork. Points to note: parameter from user mode, which if has bit 0x80 set, means 'dup the file table'. SO i set the dupfd variable at the beginning. At the end, code decides to either dupfd() or just bump counters. Note in include sys/vnode.h, and to make it work correctly, i have to under KERNEL before and redefine it after the include. Ah well ... i think this oughtta get fixed somehow. note the implication of the option: fork is a special case of rfork. /* * Copyright (c) 1982, 1986, 1989, 1991, 1993 * The Regents of the University of California. All rights reserved. * (c) UNIX System Laboratories, Inc. * All or some portions of this file are derived from material licensed * to the University of California by American Telephone and Telegraph * Co. or Unix System Laboratories, Inc. and are reproduced herein with * the permission of UNIX System Laboratories, Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * @(#)kern_fork.c 8.6 (Berkeley) 4/8/94 */ #include #include #include #include #include #include #include #include #include #include /* oh, yuck */ /* this is due to include of vnode_if.h, which is automatically * generated. ouch. */ #undef KERNEL #include #define KERNEL #define VREF(vp) (vp)->v_usecount++ /* increase reference */ struct rfa { int opts; }; /* ARGSUSED */ rfork(p1, uap, retval) struct proc *p1; struct rfa *uap; int retval[]; { int dupfd = 0; /* added for rfork() */ register struct proc *p2; register uid_t uid; struct proc *newproc; struct proc **hash; int count; static int nextpid, pidchecked = 0; if (uap->opts&0x80) dupfd = 1; /* DUPLICATE FORK CODE DELETED HERE ... */ . . . /* END DELETED FORK CODE */ /* bump references to the text vnode (for procfs) */ p2->p_textvp = p1->p_textvp; if (p2->p_textvp) VREF(p2->p_textvp); /* BEGIN CHANGED CODE FOR RFORK FOR DUPFD () */ if (dupfd) p2->p_fd = fdcopy(p1); else { /* make this a function at some point */ /* danger!!! no locks!!! */ p2->p_fd = p1->p_fd; p2->p_fd->fd_refcnt++; } /* END CHANGED CODE FOR RFORK() */ /* MORE DELETED UNCHANGED CODE */ /* END DELETED CODE */ /* * Return child pid to parent process, * marking us as parent via retval[1]. */ retval[0] = p2->p_pid; retval[1] = 0; return (0); } From owner-freebsd-hackers Wed Oct 25 12:11:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06314 for hackers-outgoing; Wed, 25 Oct 1995 12:11:06 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06281 for ; Wed, 25 Oct 1995 12:10:52 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA07928 for hackers@freebsd.org; Wed, 25 Oct 1995 20:11:00 +0100 From: Luigi Rizzo Message-Id: <199510251911.UAA07928@labinfo.iet.unipi.it> Subject: 951020 bug report To: hackers@freebsd.org Date: Wed, 25 Oct 1995 20:10:59 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1327 Sender: owner-hackers@freebsd.org Precedence: bulk It is really a pleasure see the installation go on ttyv1... Anyways afew small problems: KERNEL CONFIG: * the documentation claims that the "probe" command is available, while it is not (and it has not been available since september, I believe) * in visual mode, I tried to configure lnc0 at address 0xff80 (as my pci card), but the program limits you to 0x2000 X installation * the "lbx" archive is missing from the menu, so it is not installed. PACKAGE INSTALL * from sysinstall, I was not able to install them, not even after setting the media. I think the program insists in looking for an "INDEX" file in the directoyy where the packages are. From pkg_install, the program seems unable to find the files archives in the extract step, even if previous steps (looking for the dir, indexing etc) work ok. Also, in pkg_install, the "Total marked:" field quickly overflows and shows negative numbers. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-hackers Wed Oct 25 12:20:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06862 for hackers-outgoing; Wed, 25 Oct 1995 12:20:09 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06850 for ; Wed, 25 Oct 1995 12:20:07 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA28689 for ; Wed, 25 Oct 1995 11:00:58 -0700 To: hackers@freebsd.org Subject: User group meeting in Silicon Valley area. 2nd try.. Date: Wed, 25 Oct 1995 11:00:58 -0700 Message-ID: <28687.814644058@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Well, I received all of *two* responses to my call for the first meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly enough to actually hold it. I can just see the 3 of us sitting around going "Erm. Anyone for ice cream? How about a movie?" Not that I'm adverse to such social activities, but I'm going to need a bit more buy-in than this to make it worth doing. So I'll try again: Is anyone in this area interested in holding a user group meeting? If so, please send me mail! Otherwise I'll just assume that this is an idea who's time has not quite come and go on to other things.. Also, don't let it stop you if you're not in the Bay Area - you're more than encouraged to organize and send out a call for a meeting in your own! Jordan From owner-freebsd-hackers Wed Oct 25 12:28:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA07497 for hackers-outgoing; Wed, 25 Oct 1995 12:28:38 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA07483 for ; Wed, 25 Oct 1995 12:28:35 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA29138; Wed, 25 Oct 1995 15:27:15 -0400 Date: Wed, 25 Oct 1995 15:27:15 -0400 (EDT) From: "Ron G. Minnich" To: Theo de Raadt , hackers@freebsd.org Subject: rfork part 3: library code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk All this function does is: 1)minherit the data space 2) call rfork with zero as the options value 3) return values. Only funniness is that you have to fake the return 0 to kid behavior of fork(), so there's fooling around with getpid() before the call and testing of return values after the call. Also, there's a call to something called 'syscallfind' in here for the modload case. IF anyone wants that code let me know. It uses modstat code to find the named syscall number. There you are. rfork in 3 parts. Questions to me. ron #include #include #include #include int minherit(caddr_t, unsigned int, int); int rfork(int i) { extern int end, sbrk(); int pid, newpid; /* until it's a real syscall, we have to fake the zero-return */ unsigned long start, last; static int rfsyscallnum = -1; if (rfsyscallnum < 0) rfsyscallnum = syscallfind("rfork"); if (rfsyscallnum < 0) { perror("rfork syscallfind"); return -1; } /* for the modload version, we don't get two return values, * so we have to fake the fork 'return 0 to kid' behavior */ pid = getpid(); start = (unsigned long) ctob(btoc(&end)); last = sbrk(0); /* the man page lies: * it won't return page-aligned values from sbrk * the seg is actually several pages larger! */ last = ctob(btoc(last)+4); /* may be nothing to share, ignore return errors */ if (minherit(start, last-start, VM_INHERIT_SHARE) < 0) perror("minherit failed"); newpid = syscall(rfsyscallnum,i); if (newpid == pid) newpid = 0; return newpid; } Ron Minnich |Like a knife through Daddy's heart: rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Wed Oct 25 12:54:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA09453 for hackers-outgoing; Wed, 25 Oct 1995 12:54:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA09442 for ; Wed, 25 Oct 1995 12:54:26 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA19300; Wed, 25 Oct 1995 12:46:01 -0700 From: Terry Lambert Message-Id: <199510251946.MAA19300@phaeton.artisoft.com> Subject: Re: Netscape puzzle To: peter@haywire.dialix.com (Peter Wemm) Date: Wed, 25 Oct 1995 12:46:00 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <46l1tu$km$1@haywire.DIALix.COM> from "Peter Wemm" at Oct 25, 95 06:01:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1879 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >> > We are all aware of the bind/sendmail static data initialization shared > >> > library changes, right? > >> > >> Refreh my memory. > > >They changed the initializations to something that would allow copy on > >write shared library data to be used as well. > > >Basically, it's getting rid of local data for crappy shared library > >implementations. > > Uhh... Am I missing something? This thread is about netscape, yes? > Netscape is linked *static*, and has it's own self-contained resolver. > Shared libraries dont even come into the picture, because BSDI (1.1) > doesn't *have* them... Yeah. You're missing that it introduced a general bind incompatability that you must code around to make it work, and perhaps the NetScape people didn't code around it. You can hack it by modifying the default contents for the statically initialized data (basically, blowing instructions in the binary), or by hacking the bind check call. > Our implementation of the resolver is not an issue with netscape, > because our resolver is not loaded into netscape. Sendmail had the > problem, yes. The implementation of the resolver to which the NetScape binary is statically linked is the issue. > If you mean the RES_INIT and res_init() patch, that's already in > sendmail, but isn't a 'netscape puzzle' issue... From memory > somebody's already mentioned that there is an issue of the resolver > code inside the statically linked netscape/bsdi executable using > select for a timeout, while netscape is using setitimer which is > disturbing the method that the resolver is using to detect a timeout > on the select. (or something like that.. :-) I mentioned it -- the system call restart issue on the select is only one possibility. 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 Oct 25 13:20:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA11481 for hackers-outgoing; Wed, 25 Oct 1995 13:20:57 -0700 Received: from io.org (io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA11437 for ; Wed, 25 Oct 1995 13:20:08 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id QAA08589; Wed, 25 Oct 1995 16:19:23 -0400 Date: Wed, 25 Oct 1995 16:19:23 -0400 (EDT) From: Brian Tao To: Andrew.Gordon@net-tel.co.uk cc: FREEBSD-HACKERS-L Subject: Re: Re(2): panic: free vnode isn't In-Reply-To: <"MAC-951025164255-1E49*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Wed, 25 Oct 1995 Andrew.Gordon@net-tel.co.uk wrote: > > Server is running 2.0.5R (with more recent SCSI drivers from -STABLE a > few weeks ago, probably not important). Ack, don't say that... I just downgraded our server to 2.0.5-RELEASE to see if that will give us longer uptimes. :-/ > The nature of the freeze is some kind of deadlock in the filesystem - > if you catch it just after the freeze, terminal/telnet sessions are > normally still alive, Yeah, it's more serious than that here. When the system locks up, everything is dead. As I said, I've put 2.0.5-RELEASE on with a kernel to handle a larger number of open files and mbuf clusters. The one major thing that is missing is the pcvt driver. Unfortunately, I can't rule out NFS because our anonymous FTP archive sits on a BSD/OS drive (which I don't think FreeBSD will recognize) and user home directories are mounted from another central server. I could probably move ftp.io.org over to another machine for a week (if 2.0.5R crashes in the next couple of days) and see what effect that has. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Wed Oct 25 13:44:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13208 for hackers-outgoing; Wed, 25 Oct 1995 13:44:32 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA13187 ; Wed, 25 Oct 1995 13:44:25 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8CfU-000jBzC; Wed, 25 Oct 95 15:43 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id PAA00582; Wed, 25 Oct 1995 15:43:19 -0500 Message-Id: <199510252043.PAA00582@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 25 Oct 1995 15:43:18 -0500 (CDT) Cc: bugs@freebsd.org, hackers@freebsd.org, davew@sees.bangor.ac.uk In-Reply-To: <9510251423.AA07418@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 25, 95 10:23:33 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 Precedence: bulk Garrett wrote: > Actually, connect(2) is what is presently being done and part of what > causes the breakage. From mount_nfs(8): > > -c For UDP mount points, do not do a connect(2). This must be used > for servers that do not reply to requests from the standard NFS > port number 2049. > > Unfortunately, I don't believe that even this option will help, since > the problem is that the server is replying from an address that the > client has no way of knowing represents the same host. But it may be > worth a try. (This option can also be accessed through the deprecated > syntax `noconn'.) > Wahoo! This option did the trick, even though the ip_addrs didn't match. This option did _not_ work under 2.0.5R, due to bad hackage of the RPC code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to think of it, the "bad hackage" was, in fact, a connect() being done in lib/libc/rpc/clnt_udp.c. Hopefully, now that we know this is a workaround for strict 4.4BSD net security, the "-o noconn" option will not be removed. I must admit I don't understand why a connect(2) is being done. Isn't UDP a connection- LESS protocol? Perhaps someone can explain... I am only an egg. ;v) Thanks everyone for your suggestions! - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Wed Oct 25 13:56:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA14353 for hackers-outgoing; Wed, 25 Oct 1995 13:56:43 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA14344 for ; Wed, 25 Oct 1995 13:56:41 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19391; Wed, 25 Oct 1995 13:47:35 -0700 From: Terry Lambert Message-Id: <199510252047.NAA19391@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Wed, 25 Oct 1995 13:47:35 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510251506.BAA10257@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 01:06:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 14129 Sender: owner-hackers@freebsd.org Precedence: bulk > >usage from not knowing about the stack? I think you are going to > >have to burn the cycles on an opaque function call in any case. > > I hope that null conversions won't cost anything. Conversions of > the form `int fd = uap->fd;' (actually machine-generated code to > load fd from an ABI-dependent offset from `void *uap') may even > have a negative cost if they happen to load fd into the right > register at the right time. It may have zero cost (a *net* negative cost), I agree. > >> Since we don't control foreign ABI's we shouldn't assume this. For > > > >That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's > >either 'int' or 'long' or '*'. > > Which one? In NetBSD it's register_t, which may be longer than an > int. This causes problems. Yeah. They ignored the definition of "int". That's a problem. The real problem is the lack of atomic sized types and the use of "short" as a synonym for "16 bit value", "long" for "32 bit value" and "quad" for "64 bit value". The real screwup is when int goes greater than 32 bits, the standard *stupidly* requires long to go up as well because it can concieve of a maximally sized type named anything other than "long". That's a bug in the standard in not having mechanisms for obtaining sized types. For a 64 bit int (requiring a 64 bit long), short is either 16 or 32 bits (undefined) and we lose access to either 32 or 16 bit types (respectively). I guess the real question is is there an overflow condition for some (long)lvalue = (int)rvalue; I'd say there isn't, simply because no one has ever expected int's to get bigger than longs, and so the content range isn't there. The only failure modes are in pseudo randomness depending on integer overflow. > >So we take a hit when processing these non-standard mechanisms; we do > >so through the system call table for the ABI, so we will be taking > >a function encapsulation hit anyway. > > Inlining should remove the hit. Perhaps given smarter encapsulation > functions, the hit from syscall() could be removed: call the encapsulation > function directly from Xsyscall() and duplicate what syscall() does > (copyin(), etc, iff necessary) in each encapsulation function. I suppose this assumes that the compiler will correctly adjust the register graph for the inlined assembly's register usage? I don't believe GCC is capable of this now, and I *know* Microsoft's compiler dies when this happens. I think using registers for calls and inlining are antithetical. You may be able to allow the optimizer to choose register passing for you (or not), but the actual choice will vary based on optimization level, etc.. I think this is a tricky failure mode that would require explicit register designation (via #pragma?) which would *decrease* portability, not increase it. > >They are padded to the default bus transfer size for the machine, > >which is supposed to be 'int'. > > >I'd argue that 'int' was the wrong size [on the alpha], not that > >there was extraneous > >padding. > > This may be true if you control the ABI. You *do* control the ABI. You are either running a known ABI paradigm (ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are running a compatability ABI, in which case you know at binary load time and can force alternate argument call gating without much trouble (but some runtime overhead: to be expected in any case of non-native code execution anyway). > >I'd really dealy love to know how there could be an endianess issue, > >considering system calls are only ever going to run as compiled code > >on one endianess of machine. > > To run user code on one machine and syscalls on another. I wouldn't > want that. I agree. The main issue I'm trying to consider here is emulated execution environments on the order of Xenix 286 support. Specifically, I have code for running a process in an emulated x86 environment and making system calls that are serviced by native code. The reason for doing this is running Intel iBCS2 code on PPC and Alpha. Clearly it's insufficient at present, without the ability to do a full 386 emulation, but it's sufficient for kernel interfaces to be allowed to be native rather than emulated as well. It's a sound concept, but it goes to hell under close approach, like what you'd have in wrappering all the system calls, or using register passing. > >> >What does it do? What use is the change? > >> > >> It avoids scattering unportable casts and ugly macros to perform them > >> throughout the "machine-independent" code. Now we have only unportable > >> casts. 4.4lite2 has slightly less unportable casts and ugly macros. > >> NetBSD has much less unportable casts and ugly macros. > > >The structure casts, I presume? > > Yes. Structure casts are not a portability problem (as below). > >The answer is to compile with the packing being the default for data > >matchup -- in the alpha case, 64 bits. For devices that need it, use > >packing #pragma's to tighten them up on a case by case basis, in the > >header file defining the structure. > > That won't help much. The problem is that syscall args don't form > a struct. Even if they are in memory, the packing may be different. This is not allowed to be the case. Either the nature of the push must be changed to ensure a register_t sized push, or the structure packing must be specifiable at declaration time, or (preferrably) both. This is the current case with GCC and AIX/Sun/DEC/SGI compilers, so it shouldn't be an issue. > This can probably be handled by using __attribute__ ((packed)) for > every arg to enforce a particular layout. But that would only work > with gcc. I suggest using machine-generated code of the form > `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. Code readability is an issue. The vnode_if.h file is an allowable exception because of the export layering used in vnode.h's inclusion of the file. The general case of machine generated code is a bad one for code readability. > >Aligned element accesses are faster anyway. > > OFFSET would usually be a multiple of the alignment so it would be > easy to calculate :-). Well, as long as sizeof(int) == sizeof(register_t), it wouldn't ever be an issue in the first place unless you tried to send arguments as themselves and the argument in question too multiple pushes to get there. That's only the quad arguments on Intel, and since the off_t definition is a standards violation, there's no problem with making an interface extension in those cases (already enumerated) to deal with it. > The ABI is a convention, and can't be changed. The ABI is an agreement between user and kernel space, and is abstracted from implementation by (1) binary file identification, (2) execution class, and (3) call gate. That means we can vary it without changing the underlying implementation, with the cost being restricted to the abstraction layering (already in place as additional overhead anyway for ABI class emulation) and additional overhead for non-native ABI's. > >> There may be no correct size. A size of 3 ints wouldn't work for > >> open("foo", 0) if the caller has perversely passed 2 args on the stack > >> at the top of the address space. Where are the ABI specs that disallow > >> this? > > >There are none. However, you are wrong; it would work, you'd just > >get a garbage value (stack direction grows the right direction for > >the third argument to be optional). Since in that case the garbage > >value is unreferenced (or the call generated a prototype warning > >...not 8-)), then it will work. > > I should get an EFAULT return if the args are at the top of the address > space like I said. I think this would be hard to enforce without dictating either stack probes or argument count pushing (ala the VAX Calling Standard) in any implementation. Consider a quad first argument on an Intel architecture. > >I have to point out that it would then be impossible to make system > >calls without prototype references. If this is a "fix" for the quad > >word passing problem (which is a "non-use of system call prototype" > >problem), then, isn't this just making things worse? > > It requires either prototypes or passing parameters of the correct > type just like it always did. Since there is a lot of broken code > out there, most compilers use inferior parameter passing conventions > to support the broken code. And? I don't see that as a problem. It's not possible for FreeBSD to dictate coding practices; unlike Microsoft, it isn't 70% of the market. Because of this, it is necessary to compromise to make the code run. We already do this in a number of cases. You might as well mandate that TERMIOS be the only tty control mechanism, and all applications that expect to run on FreeBSD "must conform". I wouldn't have a problem with an alternate execution class, and potentially trap gate, to cause there to be a "very fast" calling mechanism that is there *as*an*aternative*to*the*default* "portable" calling mechanism. But mandating that the default be such that the majority of code on the net would require patching to make it run (admittedly, mostly header files) is *bogus*. > >Callee pop only works when using the same stack. When you get to the > >kernel, the kernel thread (or just process) will be using its own stack, > >so that argument won't wash. My complaint on callee pop as a more > >fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. > > Of course you wouldn't want to use it across interfaces, but how do > you stop a C compiler that is optimized for compiling user code from > producing wrong code for interfaces that it doesn't support? (Writing > masses of interface code in assembler isn't acceptable.) This is an interesting question... but I can't see a situation where it could be applicable. There *must* be a mechanism for making OS service requests to implement the standard libraries. There is no other option to avoid isolating the program from all of it's I/O (I/O, at least, must use system interfaces, even if everything else is faked, including lying about the time, etc.). The answer to your question is that the compiler must know about some system interface mechanism, then the system must provide the requested mechanism. I object to needing to include standard system call prototypes to allow their use. I put up with lseek/truncate/ftruncate/mmap BS because it's impossible to support all of quads, 32 bit ints, and trap-based call mechanisms and not violate either ANSI C, POSIX or both. I just happen to disagree with where the violation takes place. Note that prototypes of system calls screw up your ability to properly utilize the syscall(2) call gate mechanism the way it was intended. A user space checkpointing mechanism that defines it's own open interface and calls the real open call via syscall (to remember the file names) will fail to compiler when the inlined open conflicts with the user definition. And then you're back to unprototyped or buggered header files (which are *very* system dependent) to implement your application interface. It's a reduction in "portability to BSD". As a "marketing strategy", on should make an OS easy to port to and hard to port from. Idealogically, I'm opposed to the "hard to port from" part of this, but no matter what ideology you follow, making it "hard to port to" is a big, big mistake. > >Right now the screwable functions are truncate, ftruncate, seek, lseek, > >and mmap -- and mmap() is bogus because of the kernel address space > >restrictions currently on "vmio". The others are in violation of one > >or more standards because "quad" isn't an allowable type. Might as > >well violate them further by using inline references to the __syscall(2) > >instead of syscall(2) to get to them so that: (1) they are undefined > >without proper header inclusion, and (2) the padding is guaranteed > >(as the __syscall(2) states in the man page). That at least would solve > >the screwups without adding to them. > > I've thought of changing the compiler to always check format args and > print a diagnostic if there is a mismatch for a quad arg. Something > similar could be done for the above functions - make them builtins > and complain about type mismatches for them. For functions it's > easier to silently DTRT (promote the args). That's one approach, on the order of printf argument checking, and probably requiring a higher-than-default error/warning level to cause to be active. I think most people will fail this test. If you put a mechanism like this in, it's hard to argue that the compiler should bitch at the user instead of just pushing a high order 0 and "making the code work" -- turn the error to a warning. Probably a "correct" approach would be to either (1) push 64 bits per for all arguments, using type identification to decide on pushing a 0 for the quad high order dword or pushing a value that really exists at the time of the call, or (2) choose a different violation of the ANSI C and POSIX standards -- interface extension -- instead of passing quad's for the default truncate/seek/mmap call interfaces. The additional calls would only exist as inlines, not in libc, and would thus be unusable without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And you wouldn't even implement qmmap until the vmio file windowing is fixed in the kernel VM system. I think that changing the interface in such a way as to cause large amounts of "third party" (ie: ftp'able and/or commercial) code to "show its brokenness" is a mistake. The quad system call arguments are mistakes of this family. In any case, I think the benefits are questionable, and should be explored as an execution class other than the default execution class (ABI) before they are integrated. Even after they are integrated, portability would dictate that their use be optional. 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 Oct 25 14:12:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15713 for hackers-outgoing; Wed, 25 Oct 1995 14:12:10 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15698 for ; Wed, 25 Oct 1995 14:12:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19472; Wed, 25 Oct 1995 14:02:58 -0700 From: Terry Lambert Message-Id: <199510252102.OAA19472@phaeton.artisoft.com> Subject: Re: anatomy of rfork, part 2: fork code To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Wed, 25 Oct 1995 14:02:57 -0700 (MST) Cc: deraadt@theos.com, hackers@FreeBSD.org In-Reply-To: from "Ron G. Minnich" at Oct 25, 95 03:02:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1385 Sender: owner-hackers@FreeBSD.org Precedence: bulk > /* bump references to the text vnode (for procfs) */ > p2->p_textvp = p1->p_textvp; > if (p2->p_textvp) > VREF(p2->p_textvp); > > /* BEGIN CHANGED CODE FOR RFORK FOR DUPFD () */ > if (dupfd) > p2->p_fd = fdcopy(p1); > else > { > /* make this a function at some point */ > /* danger!!! no locks!!! */ > p2->p_fd = p1->p_fd; > p2->p_fd->fd_refcnt++; > } One presumes exit(2) knows how to clean this up? I implemented fd table sharing in UnixWare 2.0 using something similar to the following in the user process: /* * Set up proc so normal for will cause FD's to be * inherited. */ /* get our name in procfs*/ sprintf( pnamebuf, "/proc/%d", getpid()); /* open ourselves*/ if( ( procfd = open( pnamebuf, O_RDWR)) == -1) { perror( "open: context sharing"); exit( 1); } /* unset the defualt "copy fd table on fork" flag*/ if( ioctl( procfd, PFS_INHERITFDTAB, 1)) { perror( "ioctl: context sharing"); exit( 1); } /* done*/ close( procfd); Which does the same thing without requiring the introduction of an additional system call interface or fork abstraction. 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 Oct 25 14:12:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15768 for hackers-outgoing; Wed, 25 Oct 1995 14:12:26 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15491 for ; Wed, 25 Oct 1995 14:10:28 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id TAA03689; Wed, 25 Oct 1995 19:19:41 GMT Date: Wed, 25 Oct 1995 19:19:41 +0000 () From: Sergio Lenzi To: "Jordan K. Hubbard" cc: hackers@FreeBSD.org Subject: startslip perhaps a solution... In-Reply-To: <27477.814629361@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1830129266-814648781=:3633" Sender: owner-hackers@FreeBSD.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1830129266-814648781=:3633 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, I use slattach (not the command but a shell) that that creates a temporary data-set to remove routes and setup the ifconfig, so the whole thing looks like: /etc/slip/slattach /dev/cuaa5 to.peer.ip from.peer.ip 9600 where to.peer.ip and from.peer.ip are the ip number or names that are setup in ifconfig for interface. Here, attached in this message goes the slip.tgz that install in /etc ok??? I hope this would help. In my sites, this works very well. Lenzi. --0-1830129266-814648781=:3633 Content-Type: APPLICATION/octet-stream; name="slip.tgz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sIAAAAAAAAA+2X326bMBTGcxs/xZHiSu0Fwfy1hppp2v2eYJ1USkxBcWKE na6T9vA7hpRl7dZW2qCT4t8FYGw+Gx2+c7AwhT8bGYgZ5xxmYGGPzocGpCyO EpbwKME25zGfQTL2wix7bfIWYNYqZZ4b97USQk6xoGkRGH8t62bMj8DGP0le Gf8kBQgYDxIX/ykY4v8p34iylmKEOQLG0jh+Jv4ht/EPeJBGPAww/mHMwhmw EdbyhBOPfy5lBlquhcmLCi9yYy/IWy/LMRGD/x9Cv9TVv57jJf8nSdz7Pwyw BkTo/wgzgPP/FNQlfAa6AG8nIIYvxFRiR+aiqBTstQDKYC3uwCgoW7UF3Qix xu772pCyJmbblCsfjz6lS002eDU0N6Q9brYEdVY0IFZnRUNi1IpGpBNc0ZgU uYHLyzN4D9Sqkros1K6sbzElXdEQaDc9xXXshNnmegPsvuxgjLRb8MrDc2fH SnYFpFV7I/AtpMDToPPoNgp3XVarfwyFqq1aA+OM9dqHDl/f1LvBLuDllQRv fxjiaaDdO4En+vHg44v7FA//ZVI98n9fA8bx//P/f3yo/3EQ2PofsZQ7/08B +vcub/12//OTXtJg2dRr0qUG+0GXQ17Y1FLCtXUYLa9tBnjr5Tv+ksH/TVvv TJE3I8zxUv2PorD3f8TCyP4LBGESBs7/U7CYfzhfXDwEf54sIzj/KNoN1sVv F5D6EfPfMUIWsvkuVZFLkDX+KXTjRZtdkcU8k1jlbY2TTabXfTrRjVISb6wz eUgwUt3atifaVmeE/EnuWM2w3+gBjtEq01WmbzKF4nuN4vUNdvq4fUUV3S2k dKnpVTyp/yPM8er6H7IkDJNu/58y5/8pcPX/tHmy/x9hjpf8/+v+P3X1f0Lc /v+09/8Oh8PhcDgcDofjdPgBTEqDsQAoAAA= --0-1830129266-814648781=:3633-- From owner-freebsd-hackers Wed Oct 25 14:14:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16081 for hackers-outgoing; Wed, 25 Oct 1995 14:14:36 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA16050 for ; Wed, 25 Oct 1995 14:14:27 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id TAA03700; Wed, 25 Oct 1995 19:24:34 GMT Date: Wed, 25 Oct 1995 19:24:34 +0000 () From: Sergio Lenzi To: hackers@freebsd.org Subject: boot disk.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I am trying to install a 2.1 version of FreeBSD in a drive that has more than 1024 cyl. It does not install, gives a message saying that bios cannot access more than 1023 clys. I am trying a solution, by making a boot.flp from the release with the disk.c file from the 2.0.5 version. Has anyone have a better Idea??? Please.?.?.?....??? From owner-freebsd-hackers Wed Oct 25 14:14:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16137 for hackers-outgoing; Wed, 25 Oct 1995 14:14:47 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16054 ; Wed, 25 Oct 1995 14:14:28 -0700 From: John Dyson Message-Id: <199510252114.OAA16054@freefall.freebsd.org> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: terry@lambert.org (Terry Lambert) Date: Wed, 25 Oct 1995 14:14:27 -0700 (PDT) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252047.NAA19391@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 01:47:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1644 Sender: owner-hackers@freebsd.org Precedence: bulk > > Probably a "correct" approach would be to either (1) push 64 bits per > for all arguments, using type identification to decide on pushing a 0 > for the quad high order dword or pushing a value that really exists at > the time of the call, or (2) choose a different violation of the ANSI C > and POSIX standards -- interface extension -- instead of passing quad's > for the default truncate/seek/mmap call interfaces. The additional > calls would only exist as inlines, not in libc, and would thus be unusable > without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And > you wouldn't even implement qmmap until the vmio file windowing is fixed > in the kernel VM system. > Terry, I am confused whe you talk about file windowing. There is absolutely NO windowing or mapping of files into the kernel space except for reading an executables file header. Files take only the KVA space to support the buffer cache and paging I/O. I believe that there are *totally* broken schemes whereby file I/O is done through kernel page faults -- but that is not what we do. All I/O is explicit -- it is nicer that way. Pages from files are simply bulk data residing in VM objects. Some of which have buffers associated with them. The problem with the addressibility in the lower levels of the VM system is that the size of a VM offset is a unsigned long. I do not want to change that to a long long for efficiency reasons. I have a method that will keep the size of the data structure mostly the same, and give a 2^12 increase in the size of the address space. It *might* be a 2.2 thing... John dyson@freebsd.org From owner-freebsd-hackers Wed Oct 25 14:30:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA18023 for hackers-outgoing; Wed, 25 Oct 1995 14:30:28 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA17998 for ; Wed, 25 Oct 1995 14:30:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19573; Wed, 25 Oct 1995 14:20:48 -0700 From: Terry Lambert Message-Id: <199510252120.OAA19573@phaeton.artisoft.com> Subject: Re: boot disk.... To: lenzi@cwbone.bsi.com.br (Sergio Lenzi) Date: Wed, 25 Oct 1995 14:20:48 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: from "Sergio Lenzi" at Oct 25, 95 07:24:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 925 Sender: owner-hackers@FreeBSD.org Precedence: bulk > I am trying to install a 2.1 version of FreeBSD > in a drive that has more than 1024 cyl. > > It does not install, gives a message saying that > bios cannot access more than 1023 clys. It can't. You can't guarantee to be able to read data (like /kernel) from an 'a' slice that ends after the 1023'rd cylinder because you can only stuff a 10 bit value into the INT 21/13 calls. Since the boot code on DOS systems is BIOS based, you are screwed. > I am trying a solution, by making a boot.flp > from the release with the disk.c file from > the 2.0.5 version. > > Has anyone have a better Idea??? That's one. Others are: 1) Rewrite the BIOS. 8-). 2) Rewrite the boot code to be controller specific and not use the BIOS. 3) Set your tanslation so all cylinders are below 1024. 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 Oct 25 14:31:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA18162 for hackers-outgoing; Wed, 25 Oct 1995 14:31:24 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA17988 ; Wed, 25 Oct 1995 14:30:16 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id TAA03750; Wed, 25 Oct 1995 19:40:48 GMT Date: Wed, 25 Oct 1995 19:40:48 +0000 () From: Sergio Lenzi To: questions@freebsd.org cc: hackers@freebsd.org Subject: DBASE.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hello, I am in need of reading some dbase files (.dbf) Does anyone have an idea where can I get the structure of a .dbf file ???? Thanks Lenzi. From owner-freebsd-hackers Wed Oct 25 14:35:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA18755 for hackers-outgoing; Wed, 25 Oct 1995 14:35:49 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA18739 ; Wed, 25 Oct 1995 14:35:44 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id PAA05072; Wed, 25 Oct 1995 15:39:47 -0600 From: Ade Barkah Message-Id: <199510252139.PAA05072@hemi.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Wed, 25 Oct 1995 15:39:47 -0600 (MDT) Cc: wollman@lcs.mit.edu, bugs@freebsd.org, hackers@freebsd.org, davew@sees.bangor.ac.uk In-Reply-To: <199510252043.PAA00582@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 25, 95 03:43:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 814 Sender: owner-hackers@freebsd.org Precedence: bulk [Michael Borowiec wrote] > Hopefully, now that we know this is a workaround for strict 4.4BSD net > security, the "-o noconn" option will not be removed. I must admit I > don't understand why a connect(2) is being done. Isn't UDP a connection- > LESS protocol? Perhaps someone can explain... I am only an egg. ;v) I'm not familiar with your specific problem (jumped in the middle of the thread) but although UDP is a connectionless proctocol, one can still use connect() on a udp socket to associate the udp destina- tion address. Alternatively such address can be specified on each send*(). -Ade Barkah -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-hackers Wed Oct 25 14:38:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA19114 for hackers-outgoing; Wed, 25 Oct 1995 14:38:30 -0700 Received: from maelstrom.cc.mcgill.ca (maelstrom.CC.McGill.CA [132.206.35.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA19089 ; Wed, 25 Oct 1995 14:38:23 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id RAA04706; Wed, 25 Oct 1995 17:38:13 -0400 (GMT-0400) Message-Id: <199510252138.RAA04706@maelstrom.cc.mcgill.ca> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage Date: Wed, 25 Oct 95 17:38:11 -0400 To: Sergio Lenzi Subject: Re: DBASE.... cc: questions@freebsd.org, hackers@freebsd.org Reply-To: yves@CC.McGill.CA References: Sender: owner-hackers@freebsd.org Precedence: bulk Hello, >I am in need of reading some dbase files (.dbf) >Does anyone have an idea where can I get the >structure of a .dbf file ???? I'd suggest giving Oracle a phone call since Oracle uses that naming scheme. However, I am having problems fitting this question in the freebsd-questions category or the freebsd-hackers categogy. Unless you're going to say: "Well, I want to read these files on a freebsd machine"... but even then.... Regards, Yves Lepage yves@cc.mcgill.ca From owner-freebsd-hackers Wed Oct 25 14:39:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA19258 for hackers-outgoing; Wed, 25 Oct 1995 14:39:14 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA19220 for ; Wed, 25 Oct 1995 14:38:56 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id TAA03767; Wed, 25 Oct 1995 19:49:27 GMT Date: Wed, 25 Oct 1995 19:49:26 +0000 () From: Sergio Lenzi To: hackers@freebsd.org Subject: Re: more boot disk.... In-Reply-To: <199510252120.OAA19573@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Wed, 25 Oct 1995, Terry Lambert wrote: > > It can't. You can't guarantee to be able to read data (like /kernel) > from an 'a' slice that ends after the 1023'rd cylinder because you > can only stuff a 10 bit value into the INT 21/13 calls. > > Since the boot code on DOS systems is BIOS based, you are screwed. > Ok but... If I make a FreeBSD slice that begins on cyl 1 for example, and in that slice I make some filesystems this way: rootfs 60Mb starting on cyl 1 swap 100MB usr 500MB home 700MB I supose that the rootf ,where the kernel resides, is in the beggining of the disk, so accessible by the bios right???? So if I partition the disk this way the system will work. Thanks any oppinion... Lenzi. From owner-freebsd-hackers Wed Oct 25 14:45:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA20064 for hackers-outgoing; Wed, 25 Oct 1995 14:45:05 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA20052 for ; Wed, 25 Oct 1995 14:45:00 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19692; Wed, 25 Oct 1995 14:35:48 -0700 From: Terry Lambert Message-Id: <199510252135.OAA19692@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: dyson@freefall.freebsd.org (John Dyson) Date: Wed, 25 Oct 1995 14:35:47 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252114.OAA16054@freefall.freebsd.org> from "John Dyson" at Oct 25, 95 02:14:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2914 Sender: owner-hackers@freebsd.org Precedence: bulk > > Probably a "correct" approach would be to either (1) push 64 bits per > > for all arguments, using type identification to decide on pushing a 0 > > for the quad high order dword or pushing a value that really exists at > > the time of the call, or (2) choose a different violation of the ANSI C > > and POSIX standards -- interface extension -- instead of passing quad's > > for the default truncate/seek/mmap call interfaces. The additional > > calls would only exist as inlines, not in libc, and would thus be unusable > > without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And > > you wouldn't even implement qmmap until the vmio file windowing is fixed > > in the kernel VM system. > > > Terry, > I am confused whe you talk about file windowing. There is > absolutely NO windowing or mapping of files into the kernel > space except for reading an executables file header. Files > take only the KVA space to support the buffer cache and paging > I/O. I believe that there are *totally* broken schemes whereby > file I/O is done through kernel page faults -- but that is not > what we do. All I/O is explicit -- it is nicer that way. > > Pages from files are simply bulk data residing in VM objects. Some > of which have buffers associated with them. > > The problem with the addressibility in the lower levels of the VM > system is that the > size of a VM offset is a unsigned long. I do not want to change that > to a long long for efficiency reasons. I have a method that > will keep the size of the data structure mostly the same, and > give a 2^12 increase in the size of the address space. > > It *might* be a 2.2 thing... 2^12 * 2^31 = 2^43. 2^43 << 2^63. The problem is for large file systems, and a lesser problem, large files on large file systems (lesser because a file will always be smaller than the FS that contains it). Causing the access to the file to be windowed through the available address space would resolve the problem once and for all and put it at 2^63 -- the highest bit still being reserved for error return on lseek and for indirect block identification. Right now it is impossible to support those files for which quad is a desirable type for off_t because of VM limitations imposed. The imposition is present codified in ffs_vmlimits() in the source file /sys/ufs/ffs/ffs_vfsops.c. The only value of quad is as an annoyance and as a spur to further annoyance and standards violations, as well as an advocacy of evil portability sabatoge to the ABI calling interface. The codification in ffs_vmlimits() is an interface violation in any case: it is a machine architecture dependency, and in acutality a vmio dependency and doesn't belong in the supposedly machine independent FS code anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Oct 25 14:47:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA20327 for hackers-outgoing; Wed, 25 Oct 1995 14:47:01 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA20316 ; Wed, 25 Oct 1995 14:46:55 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19709; Wed, 25 Oct 1995 14:37:12 -0700 From: Terry Lambert Message-Id: <199510252137.OAA19709@phaeton.artisoft.com> Subject: Re: DBASE.... To: yves@CC.McGill.CA Date: Wed, 25 Oct 1995 14:37:12 -0700 (MST) Cc: lenzi@cwbone.bsi.com.br, questions@FreeBSD.org, hackers@FreeBSD.org In-Reply-To: <199510252138.RAA04706@maelstrom.cc.mcgill.ca> from "Yves Lepage" at Oct 25, 95 05:38:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 702 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >I am in need of reading some dbase files (.dbf) > >Does anyone have an idea where can I get the > >structure of a .dbf file ???? > > I'd suggest giving Oracle a phone call since Oracle uses > that naming scheme. > > However, I am having problems fitting this question in the > freebsd-questions category or the freebsd-hackers categogy. > > Unless you're going to say: "Well, I want to read these files on > a freebsd machine"... but even then.... There is a company that supports a dBase clone for FreeBSD. It was in comp.unix.freebsd.announce recently. 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 Oct 25 15:46:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25910 for hackers-outgoing; Wed, 25 Oct 1995 15:46:48 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25884 for ; Wed, 25 Oct 1995 15:46:32 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id UAA03874; Wed, 25 Oct 1995 20:55:19 GMT Date: Wed, 25 Oct 1995 20:55:19 +0000 () From: Sergio Lenzi To: Stefan Esser cc: hackers@freebsd.org Subject: Re: more boot disk.... In-Reply-To: <199510252238.AA15774@Sysiphos> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Ok. if the disk has 4096 cyl, 6 heads and 32 sectors per track creating a freebsd slice with 60MB I see no problem... I setup the adaptec to not translate sectors, I use the bios of the adaptec (1542) to low level format the drive when it finish the geometry says: 3096 cyl, 6 heads, 32 sec. An attempt to boot a 2.0.5 release works fine. the drive is working ok. An attempt to boot a 2.1 fails.... Lenzi. From owner-freebsd-hackers Wed Oct 25 16:59:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA01360 for hackers-outgoing; Wed, 25 Oct 1995 16:59:45 -0700 Received: from hermes.sees.bangor.ac.uk (hermes.sees.bangor.ac.uk [147.143.102.8]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA01346 ; Wed, 25 Oct 1995 16:59:35 -0700 From: Mr D Whitehead (Ext 2703) Message-Id: <17209.9510252357@hermes.sees.bangor.ac.uk> Received: from sol (sol.sees.bangor.ac.uk) by hermes.sees.bangor.ac.uk; Thu, 26 Oct 95 00:57:09 BST Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Wed, 25 Oct 1995 23:57:09 +0000 (GMT) Cc: bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <199510252043.PAA00582@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 25, 95 03:43:18 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2010 Sender: owner-hackers@freebsd.org Precedence: bulk > > Garrett wrote: > > Actually, connect(2) is what is presently being done and part of what > > causes the breakage. From mount_nfs(8): > > > > -c For UDP mount points, do not do a connect(2). This must be used > > for servers that do not reply to requests from the standard NFS > > port number 2049. > > > > Unfortunately, I don't believe that even this option will help, since > > the problem is that the server is replying from an address that the > > client has no way of knowing represents the same host. But it may be > > worth a try. (This option can also be accessed through the deprecated > > syntax `noconn'.) > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC ^^^^^ I beg to differ, we are using 2.0.5R (from the CD) and it _was_ the solution to our problem! > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > think of it, the "bad hackage" was, in fact, a connect() being done in > lib/libc/rpc/clnt_udp.c. > > Hopefully, now that we know this is a workaround for strict 4.4BSD net > security, the "-o noconn" option will not be removed. I must admit I > don't understand why a connect(2) is being done. Isn't UDP a connection- > LESS protocol? Perhaps someone can explain... I am only an egg. ;v) > -- Dave Whitehead (Computer Support Staff) ------------------------------------------------------------------------------- EMAIL:- | TELEPHONE (work):- (work) davew@sees.bangor.ac.uk | +44 1248 382703 (Direct line) (home) 100023.1076@compuserve.com | +44 1248 351151 ext 2703 ------------------------------------------------------------------------------- SNAIL MAIL:- Dave Whitehead School of Electronic Engineering & Computer Systems, University College of North Wales, Dean Street, Bangor LL57 1UT ------------------------------------------------------------------------------ From owner-freebsd-hackers Wed Oct 25 17:23:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA02807 for hackers-outgoing; Wed, 25 Oct 1995 17:23:03 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA02802 for ; Wed, 25 Oct 1995 17:23:00 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.12/8.6.9) id RAA08169 for hackers@freebsd.org; Wed, 25 Oct 1995 17:22:32 -0700 Date: Wed, 25 Oct 1995 17:22:32 -0700 From: "Jordan K. Hubbard" Message-Id: <199510260022.RAA08169@time.cdrom.com> To: hackers@freebsd.org Subject: This may interest some of you.. Sender: owner-hackers@freebsd.org Precedence: bulk http://home.netscape.com/escapes/index.html No, it's not a flagrant plug for WC, it's actually a plug for FreeBSD too.. I think that this can only help us! Jordan From owner-freebsd-hackers Wed Oct 25 17:42:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA04599 for hackers-outgoing; Wed, 25 Oct 1995 17:42:08 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA04592 for ; Wed, 25 Oct 1995 17:42:05 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id RAA22053; Wed, 25 Oct 1995 17:41:48 -0700 Message-Id: <199510260041.RAA22053@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: This may interest some of you.. In-reply-to: Your message of "Wed, 25 Oct 1995 17:22:32 PDT." <199510260022.RAA08169@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 17:41:47 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Hmm... May ask what are we supposed to be looking at :) ? Tnks, Amancio >>> "Jordan K. Hubbard" said: > http://home.netscape.com/escapes/index.html > > No, it's not a flagrant plug for WC, it's actually a plug for FreeBSD > too.. I think that this can only help us! > > Jordan > From owner-freebsd-hackers Wed Oct 25 17:44:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA04942 for hackers-outgoing; Wed, 25 Oct 1995 17:44:11 -0700 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA04917 for ; Wed, 25 Oct 1995 17:43:59 -0700 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id TAA20357; Wed, 25 Oct 1995 19:43:50 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Oct 1995 19:43:50 -0500 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: This may interest some of you.. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk At 7:22 PM 10/25/95, Jordan K. Hubbard wrote: >http://home.netscape.com/escapes/index.html > >No, it's not a flagrant plug for WC, it's actually a plug for FreeBSD >too.. I think that this can only help us! > > Jordan Did you mean http://www.cdrom.com/ ? ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-hackers Wed Oct 25 17:50:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA05723 for hackers-outgoing; Wed, 25 Oct 1995 17:50:01 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA05700 for ; Wed, 25 Oct 1995 17:49:52 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA08280; Wed, 25 Oct 1995 17:49:14 -0700 To: "Amancio Hasty Jr." cc: hackers@freebsd.org Subject: Re: This may interest some of you.. In-reply-to: Your message of "Wed, 25 Oct 1995 17:41:47 PDT." <199510260041.RAA22053@rah.star-gate.com> Date: Wed, 25 Oct 1995 17:49:13 -0700 Message-ID: <8277.814668553@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Hmm... May ask what are we supposed to be looking at :) ? Feh, I didn't realize until just now that Netscape gives you different adverts on that page depending on which of their servers you happen to hit.. :-( I was just lucky in getting the WC add (which has "FreeBSD" in a little starburst) on the very first try, I guess! If you whack "Reload" a few times, you'll see it. Sorry about that folks! I guess I learned something new about netscape's advertising service today! Jordan From owner-freebsd-hackers Wed Oct 25 18:30:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA09993 for hackers-outgoing; Wed, 25 Oct 1995 18:30:52 -0700 Received: (from dima@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA09983 ; Wed, 25 Oct 1995 18:30:50 -0700 Message-Id: <199510260130.SAA09983@freefall.freebsd.org> Subject: Re: User group meeting in Silicon Valley area. 2nd try.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 25 Oct 1995 18:30:50 -0700 (PDT) Cc: hackers@FreeBSD.org In-Reply-To: <28687.814644058@time.cdrom.com> from "Jordan K. Hubbard" at Oct 25, 95 11:00:58 am From: dima@FreeBSD.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 884 Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > > Well, I received all of *two* responses to my call for the first > meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly > enough to actually hold it. I can just see the 3 of us sitting around > going "Erm. Anyone for ice cream? How about a movie?" Not that I'm And what about some beer? ;-) > adverse to such social activities, but I'm going to need a bit more > buy-in than this to make it worth doing. > > So I'll try again: Is anyone in this area interested in holding a user > group meeting? If so, please send me mail! Otherwise I'll just > assume that this is an idea who's time has not quite come and go on to > other things.. I am. > > Also, don't let it stop you if you're not in the Bay Area - you're > more than encouraged to organize and send out a call for a meeting in > your own! > > Jordan > -- dima From owner-freebsd-hackers Wed Oct 25 18:34:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10343 for hackers-outgoing; Wed, 25 Oct 1995 18:34:24 -0700 Received: from escape.com (escape.com [198.6.71.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA10336 ; Wed, 25 Oct 1995 18:34:21 -0700 Received: (from dima@localhost) by escape.com (8.6.12/8.6.9) id VAA18610; Wed, 25 Oct 1995 21:18:18 -0400 Date: Wed, 25 Oct 1995 21:18:17 -0400 (EDT) From: "Dima (ELO)" To: hackers@freebsd.org cc: help@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hello, I've got FreeBSD 2.05 could someone tell me what files from /src directory should I get to recompile kernel and how to unpack those files with .aa .ab .ac etc extention? dima@escape.com From owner-freebsd-hackers Wed Oct 25 18:46:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA11675 for hackers-outgoing; Wed, 25 Oct 1995 18:46:04 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA11650 ; Wed, 25 Oct 1995 18:45:55 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA08617; Wed, 25 Oct 1995 18:45:26 -0700 To: dima@FreeBSD.org (Dima Ruban) cc: hackers@FreeBSD.org Subject: Re: User group meeting in Silicon Valley area. 2nd try.. In-reply-to: Your message of "Wed, 25 Oct 1995 18:30:50 PDT." <199510260130.SAA09983@freefall.freebsd.org> Date: Wed, 25 Oct 1995 18:45:26 -0700 Message-ID: <8615.814671926@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > And what about some beer? ;-) Most of us don't drink alcohol, remember? We go for the harder stuff: Jolt! :-) Russell Carter has kindly agreed to take over the organization of this so that it doesn't slip through the cracks should I (quite likely, actually) become trapped in 2.1 hell and run out of time to organize the event. I'm sure he'll see this message and add you to whatever mailing list he's putting together! Jordan From owner-freebsd-hackers Wed Oct 25 19:04:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13511 for hackers-outgoing; Wed, 25 Oct 1995 19:04:08 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13499 for ; Wed, 25 Oct 1995 19:04:04 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA22705; Wed, 25 Oct 1995 19:03:52 -0700 Message-Id: <199510260203.TAA22705@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: User group meeting in Silicon Valley area. 2nd try.. In-reply-to: Your message of "Wed, 25 Oct 1995 11:00:58 PDT." <28687.814644058@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 19:03:51 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Count me in. Can we have the meeting in South Beach Billiard, S.F.? cool place to have a meeting and to play pool and he hold it at the right time then we can just step out and hit the Night Scene. Cheers, Amancio >>> "Jordan K. Hubbard" said: > Well, I received all of *two* responses to my call for the first > meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly > enough to actually hold it. I can just see the 3 of us sitting around > going "Erm. Anyone for ice cream? How about a movie?" Not that I'm > adverse to such social activities, but I'm going to need a bit more > buy-in than this to make it worth doing. > > So I'll try again: Is anyone in this area interested in holding a user > group meeting? If so, please send me mail! Otherwise I'll just > assume that this is an idea who's time has not quite come and go on to > other things.. > > Also, don't let it stop you if you're not in the Bay Area - you're > more than encouraged to organize and send out a call for a meeting in > your own! > > Jordan > From owner-freebsd-hackers Wed Oct 25 19:48:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA18709 for hackers-outgoing; Wed, 25 Oct 1995 19:48:30 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA18695 for ; Wed, 25 Oct 1995 19:48:24 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id TAA00685 for ; Wed, 25 Oct 1995 19:48:21 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id TAA11750 for ; Wed, 25 Oct 1995 19:45:47 -0700 Message-Id: <199510260245.TAA11750@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: freebsd-hackers@freebsd.org Subject: BAFUG breathes, it's alive! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 1995 19:45:47 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org Precedence: bulk Ok folks, Looks like I'm the idiot^H^H^H^H^Hvolunteer who's going to coordinate the end of the year BAFUG. I held an earlier one at my house that had an illustrious crew of 25 or so. I would like input on where to do it; a restaraunt, house, billiards, or Trocadero; and the geographical location: SF, East Bay, South Bay. Due to those unavoidable constraints I mildly opine that it makes sense to hold it here in Silicon Valley. We could do it at the IHOP that lotsa Silicon Valley Professional Societies use, including the local LUG, which would also cost a bit; alternatively, we could do it at my place, a moderately spacious tract home in anonymous Santa Clara. Or somebody else's house! Having it at somebodies house is nice in that you get to chat until chased out several days later, when the fridge is finally empty of beer ;-) And Jolt 8-) Usually crash space is available too... Now that hackers is nice and lurkable again, this is the last message I post there until we finalize this thing. So vote early, and often! Write-in ballots perfectly legal too... Cheers, Russell rcarter@geli.com From owner-freebsd-hackers Wed Oct 25 20:26:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23703 for hackers-outgoing; Wed, 25 Oct 1995 20:26:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23696 for ; Wed, 25 Oct 1995 20:26:14 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA02246; Thu, 26 Oct 1995 13:21:32 +1000 Date: Thu, 26 Oct 1995 13:21:32 +1000 From: Bruce Evans Message-Id: <199510260321.NAA02246@godzilla.zeta.org.au> To: dyson@freefall.freebsd.org, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, bde@zeta.org.au, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >2^63 -- the highest bit still being reserved for error return on lseek >and for indirect block identification. The highest bit is not reserved for error return on lseek. Only one value ((off_t)-1) is reserved. >The only value of quad is as an annoyance and as a spur to further It is expedient. Would you prefer off_t to be double? (That's in the ABI; inside the kernel and on disks offsets should be represented in an efficient way, perhaps as quads.) Bruce From owner-freebsd-hackers Wed Oct 25 20:26:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23752 for hackers-outgoing; Wed, 25 Oct 1995 20:26:39 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23704 for ; Wed, 25 Oct 1995 20:26:21 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA09677; Thu, 26 Oct 1995 12:53:17 +0930 From: Michael Smith Message-Id: <199510260323.MAA09677@genesis.atrad.adelaide.edu.au> Subject: Re: more boot disk.... To: lenzi@cwbone.bsi.com.br (Sergio Lenzi) Date: Thu, 26 Oct 1995 12:53:16 +0930 (CST) Cc: hackers@FreeBSD.org In-Reply-To: from "Sergio Lenzi" at Oct 25, 95 07:49:26 pm Content-Type: text Content-Length: 1029 Sender: owner-hackers@FreeBSD.org Precedence: bulk Sergio Lenzi stands accused of saying: > Ok but... If I make a FreeBSD slice that begins on cyl 1 for example, > and in that slice I make some filesystems this way: > > rootfs 60Mb starting on cyl 1 > swap 100MB > usr 500MB > home 700MB > > I supose that the rootf ,where the kernel resides, is in the > beggining of the disk, so accessible by the bios right???? > > So if I partition the disk this way the system will work. It's my experience that this will be fine. You're obviously aware of the cylinder 1 requirement, so everything else should be fine. Be careful that the BIOS and FreeBSD sectors per cylinder counts match. > Lenzi. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 25 20:53:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA25702 for hackers-outgoing; Wed, 25 Oct 1995 20:53:26 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA25621 for ; Wed, 25 Oct 1995 20:53:00 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id NAA09839; Thu, 26 Oct 1995 13:17:28 +0930 From: Michael Smith Message-Id: <199510260347.NAA09839@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: terry@lambert.org (Terry Lambert) Date: Thu, 26 Oct 1995 13:17:27 +0930 (CST) Cc: lenzi@cwbone.bsi.com.br, hackers@FreeBSD.org In-Reply-To: <199510252120.OAA19573@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 02:20:48 pm Content-Type: text Content-Length: 754 Sender: owner-hackers@FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > 3) Set your tanslation so all cylinders are below 1024. Here's a question for any poor sucker with low-level BIOS experience : If I rewrite the BPT with a new geometry for the disk, can I assume that subsequent BIOS activity will honour the new geometry? My guess is no, but it's always worth dreaming 8) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Wed Oct 25 22:13:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA04892 for hackers-outgoing; Wed, 25 Oct 1995 22:13:48 -0700 Received: from ulc199.residence.gatech.edu (root@ulc199.residence.gatech.edu [199.77.162.99]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA04869 for ; Wed, 25 Oct 1995 22:13:44 -0700 Received: (from ken@localhost) by ulc199.residence.gatech.edu (8.6.11/8.6.11) id BAA15139; Thu, 26 Oct 1995 01:13:24 -0400 From: Kenneth Merry Message-Id: <199510260513.BAA15139@ulc199.residence.gatech.edu> Subject: Re: This may interest some of you.. To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Thu, 26 Oct 1995 01:13:23 -0400 (EDT) Cc: jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199510260041.RAA22053@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 25, 95 05:41:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1061 Sender: owner-hackers@freebsd.org Precedence: bulk Amancio said: > Hmm... May ask what are we supposed to be looking at :) ? > > Tnks, > Amancio > >>> "Jordan K. Hubbard" said: > > http://home.netscape.com/escapes/index.html > > > > No, it's not a flagrant plug for WC, it's actually a plug for FreeBSD > > too.. I think that this can only help us! > > > > Jordan > > Hmm....I think I know what it may be. The graphic 'ad' in the middle of that page seems to change every-so-often. I'm not sure how often, but I pulled up the page a little before 0100 EDT, and then reloaded at ~ 0105 EDT, and there was a different ad there. Hmm..and now there's another add (an intel ad) there. It must change fairly often. Anyway, take a look at: http://home.mcom.com/ads/index.html. Walnut Creek is on the list of sponsors. If you look at: http://home.mcom.com/www_s/inserts/insert62.html You'll see what is probably Walnut Creek's ad insert on that page. It mentions FreeBSD. :) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-hackers Wed Oct 25 22:23:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA06185 for hackers-outgoing; Wed, 25 Oct 1995 22:23:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA06158 for ; Wed, 25 Oct 1995 22:23:31 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA07866; Thu, 26 Oct 1995 15:20:48 +1000 Date: Thu, 26 Oct 1995 15:20:48 +1000 From: Bruce Evans Message-Id: <199510260520.PAA07866@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >> Which one? In NetBSD it's register_t, which may be longer than an >> int. This causes problems. >Yeah. They ignored the definition of "int". That's a problem. "int" is machine-dependent. On 68000's you would have to support some user compilers using 16 bit ints (for speed) and others using 32 bit ints (for easy porting). We're close to having the same problems with 32 vs 64 bit ints. >The real problem is the lack of atomic sized types and the use of "short" >as a synonym for "16 bit value", "long" for "32 bit value" and "quad" >for "64 bit value". NetBSD has fixed this. It uses the typedefs in (int16_t, int32_t, int64_t) a lot. >The real screwup is when int goes greater than 32 bits, the standard >*stupidly* requires long to go up as well because it can concieve of >a maximally sized type named anything other than "long". This is fundamental. longs are at least as large as ints. >> Inlining should remove the hit. Perhaps given smarter encapsulation >I suppose this assumes that the compiler will correctly adjust the >register graph for the inlined assembly's register usage? I don't >believe GCC is capable of this now, and I *know* Microsoft's compiler >dies when this happens. Everything assumes a correct compiler. gcc justs produces slower code when you give it a register allocation problem that is too hard for it. >I think using registers for calls and inlining are antithetical. You Calls to inline functions don't use the standard calling convention. >> >I'd argue that 'int' was the wrong size [on the alpha], not that >> >there was extraneous >> >padding. >> >> This may be true if you control the ABI. >You *do* control the ABI. You are either running a known ABI paradigm >(ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are >running a compatability ABI, in which case you know at binary load time You know it but you don't control it. >and can force alternate argument call gating without much trouble (but >some runtime overhead: to be expected in any case of non-native code >execution anyway). I've thought of using alternative gates to stop the compatibility interface (for other OS's) from slowing down the standard interface. We plan to use trap gates instead of call gates for standard syscalls. We already support int 0x80 for Linux and NetBSD uses int 0x80 for its native syscalls. If everything used int 0x80, then decoding would be expensive. The expense can be pushed to image activation time using alternative TSS's and gates. We might end up with the following: int 0x80 (trap gate) for native syscalls int 0x80 (trap gate) for NetBSD syscalls int 0x80 (trap gate) for Linux syscalls lcall(7, 0) (call gate) for ibcs2 compatibility and slowness ... >The main issue I'm trying to consider here is emulated execution >environments on the order of Xenix 286 support. Specifically, I >... >to be native rather than emulated as well. It's a sound concept, >but it goes to hell under close approach, like what you'd have in >wrappering all the system calls, or using register passing. Er, you have this exactly backwards. My wrappers provide part of what is required to handle nontrivial conversions from a 16 bit ABI to a 32 bit one. >Structure casts are not a portability problem (as below). >> >The answer is to compile with the packing being the default for data >> >matchup -- in the alpha case, 64 bits. For devices that need it, use >> >packing #pragma's to tighten them up on a case by case basis, in the >> >header file defining the structure. >> >> That won't help much. The problem is that syscall args don't form >> a struct. Even if they are in memory, the packing may be different. >This is not allowed to be the case. Either the nature of the push >must be changed to ensure a register_t sized push, or the structure Yeah, right. Change the Xenix 286 ABI to push 386 register_t's. >packing must be specifiable at declaration time, or (preferrably) both. Packing can't be specified in C. That's why my my machine generated wrappers are required - to provide portability. It isn't worth supporting both because if you support the worst case (weird packing) then it just takes more code to support the array case. >> This can probably be handled by using __attribute__ ((packed)) for >> every arg to enforce a particular layout. But that would only work >> with gcc. I suggest using machine-generated code of the form >> `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. >Code readability is an issue. The vnode_if.h file is an allowable >exception because of the export layering used in vnode.h's inclusion >of the file. The general case of machine generated code is a bad one >for code readability. My ideas for syscalls are based on what is done for vnodes :-). It is possible to do better for syscalls (remove the uap's from the non- machine-generated code) because stacking isn't required. Stacking seems to require passing around uap's because one layer might modify *uap. This is too hard to do with call-by-value function call args. >> The ABI is a convention, and can't be changed. >The ABI is an agreement between user and kernel space, and is abstracted >from implementation by (1) binary file identification, (2) execution >class, and (3) call gate. >That means we can vary it without changing the underlying implementation, >with the cost being restricted to the abstraction layering (already in >place as additional overhead anyway for ABI class emulation) and >additional overhead for non-native ABI's. You can't vary Xenix 286's syscall parameter passing conventions! >> >I have to point out that it would then be impossible to make system >> >calls without prototype references. If this is a "fix" for the quad >> >word passing problem (which is a "non-use of system call prototype" >> >problem), then, isn't this just making things worse? >> >> It requires either prototypes or passing parameters of the correct >> type just like it always did. Since there is a lot of broken code >> out there, most compilers use inferior parameter passing conventions >> to support the broken code. >And? >I don't see that as a problem. It's not possible for FreeBSD to dictate >coding practices; unlike Microsoft, it isn't 70% of the market. Because >of this, it is necessary to compromise to make the code run. We already >do this in a number of cases. I write Standard code and don't wan't it slowed down by inferior parameter passing conventions required for broken code. Unfortunately the parameter passing convention must be the same as the libraries, and the library must use a portable convention internally as well as to interface because using variant conventions would be too hard and isn't fully supported. I don't want the library code cluttered with __attribute((__fast__calling_ convention__)) anyway. >I wouldn't have a problem with an alternate execution class, and potentially >trap gate, to cause there to be a "very fast" calling mechanism that is >there *as*an*aternative*to*the*default* "portable" calling mechanism. >But mandating that the default be such that the majority of code on the >net would require patching to make it run (admittedly, mostly header >files) is *bogus*. The default should be fast. Since the convention is enforced by mostly machine generated glue in /usr/src/lib/libc/i386, the C convention is irrelevant except for its impact on the complexity of the glue. >I object to needing to include standard system call prototypes to allow >their use. I put up with lseek/truncate/ftruncate/mmap BS because it's It isn't required. However, passing of args that have the correct type (after the default promotions) is required. The second arg to lseek must be off_t, not long, except of course if off_t is long. >Note that prototypes of system calls screw up your ability to properly >utilize the syscall(2) call gate mechanism the way it was intended. A The use of syscall() in general requires handling all the messy conversion issues that we have been discussing in your own code. >user space checkpointing mechanism that defines it's own open interface >and calls the real open call via syscall (to remember the file names) >will fail to compiler when the inlined open conflicts with the user >definition. Yes, it can't work in general :-]. It assumes all machines are vaxes. >Probably a "correct" approach would be to either (1) push 64 bits per >for all arguments, using type identification to decide on pushing a 0 >for the quad high order dword or pushing a value that really exists at >the time of the call, or This would be slow and is beside the point. It's easy to implement a good ABI for a particular when you can design it. We'll have just one chance to redesigned the ABI when we switch to int 0x80 syscalls. (2) choose a different violation of the ANSI C >and POSIX standards -- interface extension -- instead of passing quad's POSIX allows most reasonable extensions. >for the default truncate/seek/mmap call interfaces. The additional It even allows nonstandard syscalls such as truncate/mmap :-). >without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And >you wouldn't even implement qmmap until the vmio file windowing is fixed >in the kernel VM system. Linux has llseek. That way leads to many ifdefs. >In any case, I think the benefits are questionable, and should be >explored as an execution class other than the default execution class >(ABI) before they are integrated. Even after they are integrated, >portability would dictate that their use be optional. This discussion has become sidetracked. Please restrict durther discussion to the original point, which is to simplify the apparent interface to syscalls without changing the actual interface at all and without reducing efficiency significantly. Bruce From owner-freebsd-hackers Wed Oct 25 22:33:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA07137 for hackers-outgoing; Wed, 25 Oct 1995 22:33:54 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA07132 for ; Wed, 25 Oct 1995 22:33:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA08288; Thu, 26 Oct 1995 15:31:43 +1000 Date: Thu, 26 Oct 1995 15:31:43 +1000 From: Bruce Evans Message-Id: <199510260531.PAA08288@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, terry@lambert.org Subject: Re: boot disk.... Cc: hackers@FreeBSD.org, lenzi@cwbone.bsi.com.br Sender: owner-hackers@FreeBSD.org Precedence: bulk >Here's a question for any poor sucker with low-level BIOS experience : >If I rewrite the BPT with a new geometry for the disk, can I assume that >subsequent BIOS activity will honour the new geometry? >My guess is no, but it's always worth dreaming 8) No. The (DOS) BPT reflects the BIOS geometry at the time the partition was formatted. If you change the BIOS geometry (which can be changed at least for IDE drives under AMI BIOSes simply by typing the new geometry in the BIOS setup), then the BPT would have to be changed to match. The BPT is one of the few file system tables that (stupidly) depends on the BIOS geometry. If you change just the BPT, then DOS may use the changed geometry, but since it doesn't match the actual (current translated) geometry, it won't work. Bruce From owner-freebsd-hackers Wed Oct 25 22:37:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA07478 for hackers-outgoing; Wed, 25 Oct 1995 22:37:02 -0700 Received: from mail.infinet.com (mail.infinet.com [198.30.154.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA07432 ; Wed, 25 Oct 1995 22:36:47 -0700 Received: by mail.infinet.com (Smail3.1.28.1 #9) id m0t8KvI-000KGrC; Thu, 26 Oct 95 01:32 EDT Message-Id: From: macgyver@infinet.com (Wilson Liaw) Subject: Re: tech docs? (fwd) To: freebsd-chat@freebsd.org, freebsd-hackers@freebsd.org Date: Thu, 26 Oct 1995 01:32:16 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 693 Sender: owner-hackers@freebsd.org Precedence: bulk Something some of you might be interested. It would be nice to have FreeBSD support. > From: RealAudio Support Program > Subject: Re: tech docs? > > Progressive Networks will be releasing RealAudio players for SGI, Sun, > and Linux platforms before the end of 1995. > > We would like to ask all UNIX users who are interested in the player to > please specify there platform ond OS version in all communications with > us. > Those of you running UNIX systems on Intel platforms (e.g. Linux) are > also asked to specify the type of soundcard they have, this will help us > to target the most popular platforms in a timely manner. > > Tony Taylor > Product Support From owner-freebsd-hackers Wed Oct 25 22:55:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA09421 for hackers-outgoing; Wed, 25 Oct 1995 22:55:31 -0700 Received: from io.org (io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA09396 for ; Wed, 25 Oct 1995 22:55:19 -0700 Received: from flinch.io.org (flinch.io.org [198.133.36.153]) by io.org (8.6.12/8.6.12) with SMTP id BAA21610 for ; Thu, 26 Oct 1995 01:55:15 -0400 Date: Thu, 26 Oct 1995 01:55:15 -0400 (EDT) From: Brian Tao To: FREEBSD-HACKERS-L Subject: New lmbench available (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I think we should get the biggest, baddest FreeBSD machines around and submit lmbench results for them... Russell Carter, you there? :) -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" ---------- Forwarded message ---------- Date: Wed, 25 Oct 95 22:28:09 PDT From: Larry McVoy To: lmbench-users@slovax.engr.sgi.com Subject: New lmbench available Hi- All 900 or so of you have download lmbench in the past. I'm writing, with Carl Staelin, a usenix paper about lmbench and I have to give it to them in a week or so. I would really like it if you got the latest and greatest and ran it on any hot machines you have sitting around. And send me the results. When you run the benchmark it now asks you if you want to mail back the results, please say yes. I would like to have a wide set of results for the publication. The paper will not be published until January of 1996. The marketing folks at a different vendor have agreed to send me their results of an as of yet unannounced machine provided that I not publish them before their announcement. If you have access to unannounced machines that will be announced by January, consider including those results. I suggest that you mail me directly to make sure that I know that your results are to be held back from the public until the paper is published. I thank all of you for your use and feedback about lmbench. Your comments have helped make it a better tool. Thanks, --lm P.S. Almost forgot. I stuck the latest on ftp.sgi.com:/pub/lmb.tgz. You need gunzip to unpack it and rcs to build it, and perl to see the results. If you have a linux box, all of the scripts for making fancy graphs work. Cd to lmbench/Results and say "make ps", and then look at the ps files in PS/*. Drafts of the usenix paper are in ftp.sgi.com:/pub/lmbench.ps. Comments welcome, remember this is an as of yet unpublished document.... From owner-freebsd-hackers Wed Oct 25 23:02:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA10209 for hackers-outgoing; Wed, 25 Oct 1995 23:02:07 -0700 Received: from condor.physics.montana.edu (condor.physics.montana.edu [153.90.240.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA10196 for ; Wed, 25 Oct 1995 23:01:57 -0700 Received: (from handy@localhost) by condor.physics.montana.edu (8.6.11/8.6.9) id AAA01411; Thu, 26 Oct 1995 00:01:20 -0600 Date: Thu, 26 Oct 1995 00:01:19 -0600 (MDT) From: Brian Handy To: hackers@freebsd.org Subject: Re: User group meeting in Silicon Valley area. 2nd try.. In-Reply-To: <199510260130.SAA09983@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk > Jordan K. Hubbard writes: > > > > Well, I received all of *two* responses to my call for the first > > meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly > > enough to actually hold it. I can just see the 3 of us sitting around > > going "Erm. Anyone for ice cream? How about a movie?" Not that I'm > > And what about some beer? ;-) Count me in! I'm on semi-permanent travel to Palo Alto and I'd be up for meeting the guys who actually know what they're doing. :-) Brian handy@umbra.space.lockheed.com From owner-freebsd-hackers Wed Oct 25 23:20:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA12951 for hackers-outgoing; Wed, 25 Oct 1995 23:20:50 -0700 Received: from khipx2-gate.csl.ntt.jp (khipx2-gate.csl.ntt.jp [163.138.61.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA12914 for ; Wed, 25 Oct 1995 23:20:42 -0700 Received: from kh10.csl.ntt.jp (kh10.csl.ntt.jp [163.138.61.4]) by khipx2-gate.csl.ntt.jp (8.6.12+2.4W/3.4W95061711) with ESMTP id PAA06734 for ; Thu, 26 Oct 1995 15:16:36 +0900 Message-Id: <199510260616.PAA06734@khipx2-gate.csl.ntt.jp> To: hackers@freebsd.org Subject: Multicast on 3com509 From: Masayuki Yanagiya (=?ISO-2022-JP?B?GyRCTHhDKxsoQg==?= =?ISO-2022-JP?B?GyRCMm1HNxsoQg==?= ) Reply-To: yanagiya@csl.ntt.jp X-Mailer: Mew beta version 0.89 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 26 Oct 1995 15:16:31 +0900 Sender: owner-hackers@freebsd.org Precedence: bulk Dear All, I put multicast-capability on 3com509 by making very small modification on i386/isa/if_ep.c. I checked the function by receiving NASA shuttle Mission with vic-2.6. Also mrouted3.4 works on the card correctly. There are two modifications: 1. Add IFF_MULTICAST flag in epattach(), 2. Add SIOCADDMULTI and SIOCDELMULTI handling in epioctl(). I included the context-diff file at the end of this mail. Best regards, Masayuki Yanagiya --- Masayuki Yanagiya NTT Communication Switching Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180 Japan yanagiya@csl.ntt.jp +81 422 59 4466 Fax +81 422 59 2473 --- cut here --- *** if_ep.c.current Thu Oct 26 14:23:13 1995 --- if_ep.c Thu Oct 26 14:40:27 1995 *************** *** 50,55 **** --- 50,61 ---- * babkin@hq.icb.chel.su */ + /* + 1995/10/26 + Multicast-capability added. + Masayuki Yanagiya (NTT) yanagiya@csl.ntt.jp + */ + #include "ep.h" #if NEP > 0 *************** *** 424,429 **** --- 430,436 ---- ifp->if_name = "ep"; ifp->if_mtu = ETHERMTU; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX; + ifp->if_flags |= IFF_MULTICAST; ifp->if_init = epinit; ifp->if_output = ether_output; ifp->if_start = epstart; *************** *** 1217,1223 **** ifp->if_mtu = ifr->ifr_mtu; } break; ! default: error = EINVAL; } --- 1224,1240 ---- ifp->if_mtu = ifr->ifr_mtu; } break; ! case SIOCADDMULTI: ! error = ether_addmulti((struct ifreq *)data, &sc->arpcom); ! goto reset; ! case SIOCDELMULTI: ! error = ether_delmulti((struct ifreq *)data, &sc->arpcom); ! reset: ! if (error == ENETRESET) { ! epinit(ifp->if_unit); ! error = 0; ! } ! break; default: error = EINVAL; } --- cut here --- From owner-freebsd-hackers Wed Oct 25 23:50:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA15486 for hackers-outgoing; Wed, 25 Oct 1995 23:50:16 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAB15479 for ; Wed, 25 Oct 1995 23:50:11 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id QAA10310; Thu, 26 Oct 1995 16:09:05 +0930 From: Michael Smith Message-Id: <199510260639.QAA10310@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: bde@zeta.org.au (Bruce Evans) Date: Thu, 26 Oct 1995 16:09:04 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.org, lenzi@cwbone.bsi.com.br In-Reply-To: <199510260531.PAA08288@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 03:31:43 pm Content-Type: text Content-Length: 1083 Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > No. The (DOS) BPT reflects the BIOS geometry at the time the partition Hang on a sec. When I say "BPT" I mean "BIOS Parameter Table", aka the BIOS equipment list. Apologies for the TLA 8( > depends on the BIOS geometry. If you change just the BPT, then DOS > may use the changed geometry, but since it doesn't match the actual > (current translated) geometry, it won't work. What I am asking is; if as a bootloader I establish that the drive is just Too Damn Big, if I frob the advertised drive geometry, will the BIOS honour that, or does it keep a private copy? I really don't give a damn about DOS; it doesn't figure anywhere in my plans 8) > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 26 00:18:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA17081 for hackers-outgoing; Thu, 26 Oct 1995 00:18:27 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA17074 for ; Thu, 26 Oct 1995 00:18:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA11866; Thu, 26 Oct 1995 17:14:10 +1000 Date: Thu, 26 Oct 1995 17:14:10 +1000 From: Bruce Evans Message-Id: <199510260714.RAA11866@godzilla.zeta.org.au> To: bde@zeta.org.au, msmith@atrad.adelaide.edu.au Subject: Re: boot disk.... Cc: hackers@FreeBSD.org, lenzi@cwbone.bsi.com.br, terry@lambert.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> No. The (DOS) BPT reflects the BIOS geometry at the time the partition >Hang on a sec. When I say "BPT" I mean "BIOS Parameter Table", aka the >BIOS equipment list. Apologies for the TLA 8( The DOS BPT seems to be named the BPB (B = block). I often confuse this with the BPT. Now I don't know what you mean by the BPT. There is the BIOS disk parameters table pointed to by vector 0x1E, but that is only for floppies and changing it has little effect. >What I am asking is; if as a bootloader I establish that the drive is just >Too Damn Big, if I frob the advertised drive geometry, will the BIOS >honour that, or does it keep a private copy? I really don't give a damn >about DOS; it doesn't figure anywhere in my plans 8) I'm not sure about the BIOS, but for IDE drives the drive keeps a private copy and you can;t expect the BIOS to reprogram that for every i/o. It might work to change the hard disk parameters pointed to by the int 0x41 and/or int 0x46 vectors and then tell the BIOS to initialize the drive using int 0x13, ah = 9. Bruce From owner-freebsd-hackers Thu Oct 26 00:34:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18301 for hackers-outgoing; Thu, 26 Oct 1995 00:34:50 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18288 for ; Thu, 26 Oct 1995 00:34:45 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id RAA10545; Thu, 26 Oct 1995 17:01:47 +0930 From: Michael Smith Message-Id: <199510260731.RAA10545@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: bde@zeta.org.au (Bruce Evans) Date: Thu, 26 Oct 1995 17:01:47 +0930 (CST) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org, lenzi@cwbone.bsi.com.br, terry@lambert.org In-Reply-To: <199510260714.RAA11866@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 05:14:10 pm Content-Type: text Content-Length: 1210 Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > The DOS BPT seems to be named the BPB (B = block). I often confuse this > with the BPT. Now I don't know what you mean by the BPT. There is the > BIOS disk parameters table pointed to by vector 0x1E, but that is only > for floppies and changing it has little effect. Booger; a thinko on my part. Indeed, the equipment list doesn't have anything to say about harddisks. > I'm not sure about the BIOS, but for IDE drives the drive keeps a private > copy and you can;t expect the BIOS to reprogram that for every i/o. It > might work to change the hard disk parameters pointed to by the int 0x41 > and/or int 0x46 vectors and then tell the BIOS to initialize the drive > using int 0x13, ah = 9. Indeed; I can imagine what something like DiskManager would think about that 8( > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 26 02:02:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA27385 for hackers-outgoing; Thu, 26 Oct 1995 02:02:50 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA27367 for ; Thu, 26 Oct 1995 02:02:20 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA15566; Thu, 26 Oct 1995 10:02:08 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA10764; Thu, 26 Oct 1995 10:02:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA27021; Thu, 26 Oct 1995 09:11:03 +0100 From: J Wunsch Message-Id: <199510260811.JAA27021@uriah.heep.sax.de> Subject: Re: boot disk.... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 26 Oct 1995 09:11:02 +0100 (MET) Cc: terry@lambert.org, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199510260347.NAA09839@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 26, 95 01:17:27 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1086 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Michael Smith wrote: > > Here's a question for any poor sucker with low-level BIOS experience : > > If I rewrite the BPT with a new geometry for the disk, can I assume that ^^^ > subsequent BIOS activity will honour the new geometry? BPT == breakpoint trap? :-) No. For IDE disks (without magic things in the way, like ``disk managers''), the BIOS is looking up the disk values from the CMOS and/or the built-in disk geometry tables, and it performs a simple seek test to what it thinks is the very last sector of the drive. IDE drives pick just this value during the POST, remember it and take it as their geometry to re-calculate all externally given C/H/S numbers into the internal block number. This way, IDE remained compatible with the ST-506 disk handling in the regular BIOS, but gained the ability to be ``self-learning'', and to use more sophisticated geometry conceptions like ZBR. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 26 02:08:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA27675 for hackers-outgoing; Thu, 26 Oct 1995 02:08:05 -0700 Received: from esoc.esa.de (com19.esoc.esa.de [131.176.86.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA27654 for ; Thu, 26 Oct 1995 02:07:29 -0700 Received: by esoc.esa.de (8.6.12/ESARLY1.8) id JAA07061; Thu, 26 Oct 1995 09:12:46 GMT Received: from dpd14.dev.esoc.esa.de(131.176.66.144) by com19.esoc.esa.de via smap (V1.3) id sma007059; Thu Oct 26 09:12:28 1995 Received: from dpd16.dpd.esoc.esa.de by scosii.esoc.esa.de (8.6.12/ESASRV1.7a) id JAA20833; Thu, 26 Oct 1995 09:06:30 GMT Received: by dpd16.dpd.esoc.esa.de (5.0/SMI-SVR4) id AA17142; Thu, 26 Oct 1995 10:06:28 +0100 Date: Thu, 26 Oct 1995 10:06:28 +0100 From: vcapuano@esoc.esa.de (Vincenzo Capuano) Message-Id: <9510260906.AA17142@dpd16.dpd.esoc.esa.de> To: freebsd-hackers@freebsd.org Subject: _SC_PAGESIZE patch to sysconf(3) X-Sun-Charset: US-ASCII content-length: 2213 Sender: owner-hackers@freebsd.org Precedence: bulk I was porting a program I developed on Solaris to FreeBSD when I got into a missing call: sysconf(_SC_PAGESIZE). I know I could use getpagesize(3), but I then had to ifdef my code. So, if you like it here is a patch to sysconf that will recognise _SC_PAGESIZE. Here are the diffs: ------------------------------------------------------------------------------- *** /usr/src/lib/libc/gen/sysconf.c.orig Wed Oct 25 20:57:03 1995 --- /usr/src/lib/libc/gen/sysconf.c Wed Oct 25 21:15:33 1995 *************** *** 179,184 **** --- 179,188 ---- return (-1); return (value); break; + case _SC_PAGESIZE: + mib[0] = CTL_HW; + mib[1] = HW_PAGESIZE; + break; default: errno = EINVAL; return (-1); *** /usr/src/lib/libc/gen/sysconf.3.orig Thu Oct 26 00:13:26 1995 --- /usr/src/lib/libc/gen/sysconf.3 Thu Oct 26 00:20:38 1995 *************** *** 142,147 **** --- 142,150 ---- .It Li _SC_2_UPE Return 1 if the system supports the User Portability Utilities Option, otherwise \-1. + .It Li _SC_PAGESIZE + Number of bytes in a system memory page. Page granularity is the granularity + of many of the memory management calls. See also getpagesize(3). .El .Sh RETURN VALUES If the call to *** /usr/include/sys/unistd.h.orig Wed Oct 25 21:00:56 1995 --- /usr/include/sys/unistd.h Thu Oct 26 00:27:55 1995 *************** *** 115,120 **** --- 115,121 ---- #define _SC_2_UPE 25 #define _SC_STREAM_MAX 26 #define _SC_TZNAME_MAX 27 + #define _SC_PAGESIZE 28 /* configurable system strings */ #define _CS_PATH 1 ------------------------------------------------------------------------------- They apply to -current. Vincenzo ======================================================================== Vincenzo Capuano, Vitrociset /\_/\ Tel: +49 (0)6151 90-3159 European Space Agency - ESOC ( o.o ) Fax: +49 (0)6151 90-3414 Robert Bosch Strasse 5 > - < Email: vcapuano@vmprofs.esoc.esa.de D-64293 Darmstadt, Germany From owner-freebsd-hackers Thu Oct 26 02:37:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA28752 for hackers-outgoing; Thu, 26 Oct 1995 02:37:27 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA28747 for ; Thu, 26 Oct 1995 02:37:21 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t8OkS-0003xWC; Thu, 26 Oct 95 02:37 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA00675 for ; Thu, 26 Oct 1995 10:37:18 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: cpp question Date: Thu, 26 Oct 1995 10:37:18 +0100 Message-ID: <673.814700238@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk My new testament is at home, can somebody tell me in the meantime: What do I write in a macro to make a token a string ? I want to do something like this: #define FOO(ptr,fmt,name) \ printf("%s =" fmt "\n", XXXX, (ptr)->name) What do I need to put at XXXX ? to convert the name to "name" ? Thanks in advance, -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Just that: dried leaves in boiling water ? From owner-freebsd-hackers Thu Oct 26 02:51:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA29136 for hackers-outgoing; Thu, 26 Oct 1995 02:51:23 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA29131 for ; Thu, 26 Oct 1995 02:51:18 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id CAA27831; Thu, 26 Oct 1995 02:50:55 -0700 From: Julian Elischer Message-Id: <199510260950.CAA27831@ref.tfs.com> Subject: Re: _SC_PAGESIZE patch to sysconf(3) To: vcapuano@esoc.esa.de (Vincenzo Capuano) Date: Thu, 26 Oct 1995 02:50:55 -0700 (PDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <9510260906.AA17142@dpd16.dpd.esoc.esa.de> from "Vincenzo Capuano" at Oct 26, 95 10:06:28 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2701 Sender: owner-hackers@freebsd.org Precedence: bulk It's not a bad addition, but it's not in the POSIX definitions that I can see, though I only have the XPG4 definitions which allign this call to posix-1 despite having some posix 2 definitions in it (the posix 2 standard was still not approved when XPG4 went to print I think) if this is not POSIX standard it should be hidden behind a #ifndef _POSIX_SOURCE > > I was porting a program I developed on Solaris to FreeBSD when I got into a > missing call: sysconf(_SC_PAGESIZE). I know I could use getpagesize(3), but > I then had to ifdef my code. > So, if you like it here is a patch to sysconf that will recognise _SC_PAGESIZE. > > Here are the diffs: > ------------------------------------------------------------------------------- > *** /usr/src/lib/libc/gen/sysconf.c.orig Wed Oct 25 20:57:03 1995 > --- /usr/src/lib/libc/gen/sysconf.c Wed Oct 25 21:15:33 1995 > *************** > *** 179,184 **** > --- 179,188 ---- > return (-1); > return (value); > break; > + case _SC_PAGESIZE: > + mib[0] = CTL_HW; > + mib[1] = HW_PAGESIZE; > + break; > default: > errno = EINVAL; > return (-1); > *** /usr/src/lib/libc/gen/sysconf.3.orig Thu Oct 26 00:13:26 1995 > --- /usr/src/lib/libc/gen/sysconf.3 Thu Oct 26 00:20:38 1995 > *************** > *** 142,147 **** > --- 142,150 ---- > .It Li _SC_2_UPE > Return 1 if the system supports the User Portability Utilities Option, > otherwise \-1. > + .It Li _SC_PAGESIZE > + Number of bytes in a system memory page. Page granularity is the granularity > + of many of the memory management calls. See also getpagesize(3). > .El > .Sh RETURN VALUES > If the call to > *** /usr/include/sys/unistd.h.orig Wed Oct 25 21:00:56 1995 > --- /usr/include/sys/unistd.h Thu Oct 26 00:27:55 1995 > *************** > *** 115,120 **** > --- 115,121 ---- > #define _SC_2_UPE 25 > #define _SC_STREAM_MAX 26 > #define _SC_TZNAME_MAX 27 > + #define _SC_PAGESIZE 28 > > /* configurable system strings */ > #define _CS_PATH 1 > > ------------------------------------------------------------------------------- > > They apply to -current. > > > Vincenzo > ======================================================================== > Vincenzo Capuano, Vitrociset /\_/\ Tel: +49 (0)6151 90-3159 > European Space Agency - ESOC ( o.o ) Fax: +49 (0)6151 90-3414 > Robert Bosch Strasse 5 > - < Email: vcapuano@vmprofs.esoc.esa.de > D-64293 Darmstadt, Germany > From owner-freebsd-hackers Thu Oct 26 05:16:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA03846 for hackers-outgoing; Thu, 26 Oct 1995 05:16:47 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA03840 for ; Thu, 26 Oct 1995 05:16:44 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA07403; Thu, 26 Oct 1995 08:15:09 -0400 Date: Thu, 26 Oct 1995 08:15:08 -0400 (EDT) From: "Ron G. Minnich" To: Terry Lambert cc: deraadt@theos.com, hackers@FreeBSD.org Subject: Re: anatomy of rfork, part 2: fork code In-Reply-To: <199510252102.OAA19472@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk > One presumes exit(2) knows how to clean this up? (in reference to the shared fd tables) exit() cleans it up quite nicely. It decrements the reference count and if it goes to 0 deletes the table. No big deal. I did not do any real work for fd table sharing, all the needed pieces were there: i just used them. > I implemented fd table sharing in UnixWare 2.0 using something similar > to the following in the user process: > ... > Which does the same thing without requiring the introduction of an > additional system call interface or fork abstraction. rfork is much more than just fd table sharing. Check previous messages. Also, fork is a subset of rfork, so all you really have to do is implement rfork and fork comes for free. Net change in number of system calls: zero. Your fd table sharing via /proc is interesting, but it adds more state to the process which the kernel has to track and act on. Also, user code needs to track and act on that state too, since it may or may not want to have the same behaviour on each fork. I prefer the rfork approach. ron From owner-freebsd-hackers Thu Oct 26 06:05:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA05364 for hackers-outgoing; Thu, 26 Oct 1995 06:05:21 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA05345 for ; Thu, 26 Oct 1995 06:04:58 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from omega.physik.fu-berlin.de (130.133.3.51) with smtp id ; Thu, 26 Oct 95 14:04 MET Received: by omega.physik.fu-berlin.de; id AA09283; Thu, 26 Oct 1995 14:04:34 +0100 From: Thomas Graichen Message-Id: <9510261304.AA09283@omega.physik.fu-berlin.de> Subject: disk-striping To: hackers@freebsd.org Date: Thu, 26 Oct 1995 14:04:33 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1191 Sender: owner-hackers@freebsd.org Precedence: bulk sorry if this mail should appear the second time here - i sent it yesterday to hackers - but i did'nt appear on hackers for me (... or is majordomo working that way that i won't get my own mails sent to the list if i'm subscribed ?) and also not in the archive (maybe it is updated over longer terms) -> thus i think it got lost somethere - here is it hello i remember that someone experimented with disk-striping in the past - is there anything coming into the FreeBSD tree in the next time ? - is anybody working on that ? - if not i would like to adapt the NetBSD ccd driver to FreeBSD - has anybody else tried it (to avoid reinventing the wheel) thanks in advance - t _______________________________________________________||_____________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| ___________________________||____email: graichen@omega.physik.fu-berlin.de____ From owner-freebsd-hackers Thu Oct 26 06:13:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA05680 for hackers-outgoing; Thu, 26 Oct 1995 06:13:54 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA05675 for ; Thu, 26 Oct 1995 06:13:51 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id IAA03114; Thu, 26 Oct 1995 08:12:27 -0500 Message-Id: <199510261312.IAA03114@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Brian Handy cc: hackers@freebsd.org Subject: Re: User group meeting in Silicon Valley area. 2nd try.. In-reply-to: Your message of "Thu, 26 Oct 1995 00:01:19 MDT." Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Thu, 26 Oct 1995 08:12:26 -0500 From: Jon Loeliger Sender: owner-hackers@freebsd.org Precedence: bulk Apparently, Brian Handy scribbled: > > Jordan K. Hubbard writes: > > > > > > Well, I received all of *two* responses to my call for the first > > > meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly > > > enough to actually hold it. I can just see the 3 of us sitting around > > > going "Erm. Anyone for ice cream? How about a movie?" Not that I'm > > > > And what about some beer? ;-) Well, now... Why didn't he say that in the first place? Hmmm? :-) > Count me in! I'm on semi-permanent travel to Palo Alto and Similar situation here. Not permanent travel, but rather end up in Mtn View for a week a month. Naturally, with little effort that week could be well timed... > I'd be up for meeting the guys who actually know what they're doing. :-) Oh, sorry. Guess I won't be going after all. :-) jdl From owner-freebsd-hackers Thu Oct 26 06:56:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA06873 for hackers-outgoing; Thu, 26 Oct 1995 06:56:31 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA06844 ; Thu, 26 Oct 1995 06:56:19 -0700 From: John Dyson Message-Id: <199510261356.GAA06844@freefall.freebsd.org> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: terry@lambert.org (Terry Lambert) Date: Thu, 26 Oct 1995 06:56:19 -0700 (PDT) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252135.OAA19692@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 02:35:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2426 Sender: owner-hackers@freebsd.org Precedence: bulk > > 2^12 * 2^31 = 2^43. > 2^43 << 2^63. > > The problem is for large file systems, and a lesser problem, large files > on large file systems (lesser because a file will always be smaller > than the FS that contains it). > > Right now it is impossible to support those files for which quad is > a desirable type for off_t because of VM limitations imposed. The > imposition is present codified in ffs_vmlimits() in the source file > /sys/ufs/ffs/ffs_vfsops.c. > The VM limitations are due to extreme performance hits if we have to go to a (long long) type representation of a page. I propose that we (in fact we will) move from page offsets to page indexes. For a 32 bit machine, it gives us at least 8TB (and probably more with sign extension fixes) for file/filesystem sizes. For a 64 bit machine it would give us even more (by a factor of 4,000,000). As far as the API is concerned, we can use whatever we want -- long, long long, or whatever. We will just have that terrible, limiting capability of supporting only 8TB files on 32 bit machines with 4K pagesizes. We haven't worked on the sign extension problems, because simply we do not support files > 4GB (or is it 2GB???) period right now. I don't believe that there is a problem with block devices (we do NOT use vmio for those.) But additionally we do not support mmaping them right now. > > The codification in ffs_vmlimits() is an interface violation in any > case: it is a machine architecture dependency, and in acutality a > vmio dependency and doesn't belong in the supposedly machine independent > FS code anyway. > I agree - but it made it work for now. The changes have been so vast that there has been significant ugliness added to the code. That is being worked on, and I suggest that if there are some architectural problems that you see -- 'corrected' code would be helpful. Note also some sort of performance analysis and architectural impact review is desirable. All I can say is that I spent nearly a year working on the most horrible OS code that I ever saw -- SVR4, and I don't want us to go down the low performance path that they did. They got both the hackery and low performance. At least we are working on cleaning up the hackery aspects, including that which was inherited from Mach (because of the differences in the philosophy -- Mach VM and the original BSD port was certainly interesting.) John dyson@freebsd.org From owner-freebsd-hackers Thu Oct 26 07:08:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07256 for hackers-outgoing; Thu, 26 Oct 1995 07:08:29 -0700 Received: from maelstrom.cc.mcgill.ca (maelstrom.CC.McGill.CA [132.206.35.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA07251 for ; Thu, 26 Oct 1995 07:08:24 -0700 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id KAA00449; Thu, 26 Oct 1995 10:07:47 -0400 (GMT-0400) Message-Id: <199510261407.KAA00449@maelstrom.cc.mcgill.ca> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Yves Lepage Date: Thu, 26 Oct 95 10:07:45 -0400 To: yanagiya@csl.ntt.jp Subject: Re: Multicast on 3com509 cc: hackers@freebsd.org Reply-To: yves@CC.McGill.CA References: <199510260616.PAA06734@khipx2-gate.csl.ntt.jp> Sender: owner-hackers@freebsd.org Precedence: bulk Hello, >I put multicast-capability on 3com509 by making very small >modification on i386/isa/if_ep.c. I checked the function by receiving >NASA shuttle Mission with vic-2.6. Also mrouted3.4 works on the card >correctly. Yup :-) I've applied that patch for my 3c509c and I've had mrouted 3.4 working fine for a few months. Mrouted 3.6 works as fine with it and my 7 down feeds receive MBONE traffic no problems. Just so you know you will not have any problems :-) Regards, Yves Lepage yves@cc.mcgill.ca From owner-freebsd-hackers Thu Oct 26 07:17:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07470 for hackers-outgoing; Thu, 26 Oct 1995 07:17:49 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA07463 ; Thu, 26 Oct 1995 07:17:44 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8T7E-000jBzC; Thu, 26 Oct 95 09:17 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id JAA01701; Thu, 26 Oct 1995 09:17:03 -0500 Message-Id: <199510261417.JAA01701@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davew@sees.bangor.ac.uk (Mr D Whitehead) Date: Thu, 26 Oct 1995 09:17:03 -0500 (CDT) Cc: bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <17209.9510252357@hermes.sees.bangor.ac.uk> from "Mr D Whitehead" at Oct 25, 95 11:57:09 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 Precedence: bulk Dave wrote: > > Garrett wrote: > > > Actually, connect(2) is what is presently being done and part of what > > > causes the breakage. From mount_nfs(8): > > > > > > -c For UDP mount points, do not do a connect(2). This must be used > > > for servers that do not reply to requests from the standard NFS > > > port number 2049. > > > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC > ^^^^^ > I beg to differ, we are using 2.0.5R (from the CD) and > it _was_ the solution to our problem! > > > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > > think of it, the "bad hackage" was, in fact, a connect() being done in > > lib/libc/rpc/clnt_udp.c. > I did try "noconn" while monitoring with snoop and a Sniffer, and under 2.0.5R (from the CD also), it did not solve the problem of differing ip_addrs. My traces showed ICMP Destination unreachable (Bad port) with or without noconn. But, there's no arguing with results. I couldn't get it to work, and documented it months ago. No sense going back now... - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Thu Oct 26 07:43:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08295 for hackers-outgoing; Thu, 26 Oct 1995 07:43:04 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA08290 for ; Thu, 26 Oct 1995 07:42:59 -0700 Received: from JIMI.MIT.EDU by MIT.EDU with SMTP id AA08024; Thu, 26 Oct 95 10:42:13 EDT Received: by jimi.MIT.EDU (5.57/4.7) id AA07426; Thu, 26 Oct 95 10:42:56 -0400 Message-Id: <9510261442.AA07426@jimi.MIT.EDU> To: hackers@freebsd.org Subject: Pthreads and 2.1 Date: Thu, 26 Oct 1995 10:42:55 EDT From: Christopher Provenzano Sender: owner-hackers@freebsd.org Precedence: bulk I have a new version of my work that runs on FreeBSD and I'd like to see it ship in 2.1 under ports or something. Can someone do this? CAP From owner-freebsd-hackers Thu Oct 26 07:58:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08793 for hackers-outgoing; Thu, 26 Oct 1995 07:58:38 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA08788 for ; Thu, 26 Oct 1995 07:58:33 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id LAA06118 for hackers@freebsd.org; Thu, 26 Oct 1995 11:01:07 -0400 From: Peter Dufault Message-Id: <199510261501.LAA06118@hda.com> Subject: Physically contig memory in user process To: hackers@freebsd.org Date: Thu, 26 Oct 1995 11:01:06 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 710 Sender: owner-hackers@freebsd.org Precedence: bulk I want to allocate DMA-friendly buffers that are physically contiguous and within the isa space from a user process so that I know I can do DMA into them without going through bounce buffers or splitting up the transfer. I figure I can allocate the memory in the kernel using isa_physmem or something similar; I haven't looked through this completely yet. What should the semantics be from a user process? A new minor number to mmap to in /dev/mem? Maybe with "addr" equal to the value desired for the low bits of the physical address? -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Thu Oct 26 08:03:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA08990 for hackers-outgoing; Thu, 26 Oct 1995 08:03:28 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA08984 for ; Thu, 26 Oct 1995 08:03:16 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id LAA08336; Thu, 26 Oct 1995 11:01:38 -0400 Date: Thu, 26 Oct 1995 11:01:37 -0400 (EDT) From: "Ron G. Minnich" To: hackers@freebsd.org, Chuck Cranor , Theo de Raadt Subject: msync is basically busted still (2.1 snap) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk well, i've been fighting msync in 2.05 now for a bit, trying to get proper behaviour. It doesn't work. A quick walk through 2.1 shows the same set of problems. description: given the following code: main() { int f = open("/some_nfs_file", 2); char *c = mmap(that file); char *x = *c; msync(c, sizeof(*c), MS_INVALIDATE); *x = *c; } I should see: nfs read, (for *c), nfs write (for *msync), nfs read (for *c). What i see is: nfs read. That's it. The write gets swallowed up by the kernel, and even if i force the write to happen by hacking the code, the second read won't happen anyway. SO let's look at msync: msync(p, uap, retval) struct proc *p; struct msync_args *uap; int *retval; msync just calls: /* * Clean the pages and interpret the return value. */ rv = vm_map_clean(map, addr, addr + size, (flags & MS_ASYNC) == 0, (flags & MS_INVALIDATE) != 0); note the last flag is invalidate. after contortions in vm_map_clean we see: if (current->protection & VM_PROT_WRITE) vm_object_page_clean(object, offset, offset + size, syncio); note the invalidate flag has just gotten lost. SHouldn't matter, right? wrong. The underlying objects need to know invalidate in the event that they cache. They need a flag that says: blow this data out of your buffer cache. Or, in recognition of VM caching, we need to decide if buffer caches still make sense. So this is the first problem: 1) we should pass invalidate info to underlying objects Back to our story. vm_object_page_clean does (for vnodes): VOP_LOCK(vp); _vm_object_page_clean(object, start, end, syncio); VOP_UNLOCK(vp); and _vm_object_page_clean does (after much work): tincr = vm_pageout_clean(p, VM_PAGEOUT_FORCE); A minor problem is we're not really doing more than page io at this point, which is going to (later down) require us to be smart and try to cluster IO. We've tossed information away at the higher levels, and we're going to do work at the lower levels to recreate it. This translates to "we'll be slow". think of this when you run lmbench and get beat by Linux :-( vm_pageout_clean does another very large blob of work, including trying to group some pages, but finally: if (pageout_count == 1) { pageout_status[0] = pager ? vm_pager_put(pager, m, ((sync || (object == kernel_object)) ? TRUE : etc. at some point, we get to: /* * generic vnode pager output routine */ int vnode_pager_output(vnp, m, count, rtvals) if all has gone well we have a list of pages in m to output, and a count. Any statistics on how often the count is > 1? We no longer really have any knowledge of: should the file system try to cache the data or not, is the io synchronous, etc. It's gone. This is the Mach way of doing things: layers with information hiding. I think it's busted: i prefer systems that add more and more info as you go down the layers, so less recomputing is done. There's an amazing amount of redundant computation in the msync path so far. Some of it is because information seems to be lost on the way down. (that said, the mach vm is sure nicer than what preceded it ...) But we're never going to go fast this way. And going fast is what we want. Anyway, from vnode_pager_output: aiov.iov_base = (caddr_t) 0; aiov.iov_len = maxsize; auio.uio_iov = &aiov; auio.uio_iovcnt = 1; auio.uio_offset = m[0]->offset; auio.uio_segflg = UIO_NOCOPY; auio.uio_rw = UIO_WRITE; auio.uio_resid = maxsize; auio.uio_procp = (struct proc *) 0; error = VOP_WRITE(vp, &auio, IO_VMIO, curproc->p_ucred); Finally! IO, right? Maybe ... this will go to nfs_write: we something else weird: if (ioflag & (IO_APPEND | IO_SYNC)) { if (np->n_flag & NMODIFIED) { np->n_attrstamp = 0; error = nfs_vinvalbuf(vp, V_SAVE, cred, p, 1); if (error) return (error); } ouch! append or sync io means invalidate ALL buffered data? even in the VM cache? Yup, even in the vm cache: nfs_vinvalbuf calls vinvalbuf which will try to clean buffered pages. It is possible (i just exercised this path yesterday while fooling around) to have msync call the vm system, which calls nfs_write, which will in turn call the vm system, and you'll deadlock because you've got stuff locked because you're doing an msync. oooch, ouch. In the case of standard msync though, io append and/or sync are not set, so we keep going and see: /* * If the new write will leave a contiguous dirty * area, just update the b_dirtyoff and b_dirtyend, * otherwise force a write rpc of the old dirty area. */ OUCH! so msync has no way of ensuring that io will actually happen! That's why msync won't work for me ... Of course there's another path below this test, ... /* * If the lease is non-cachable or IO_SYNC do bwrite(). */ if ((np->n_flag & NQNFSNONCACHE) || (ioflag & IO_SYNC)) { bp->b_proc = p; error = VOP_BWRITE(bp); if (error) return (error); we can't get here if IO_SYNC is set! we already tested for it and took a different path way up at the top of nfs_write. Not only that the cache is not getting invalidated, and i have not found a reasonable way to do it that doesn't pull in the vm system and cause deadlock. now what? msync still won't work in 2.1 ... but the bigger problem is, the vm system overall seems overloaded with work. ron From owner-freebsd-hackers Thu Oct 26 08:42:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10318 for hackers-outgoing; Thu, 26 Oct 1995 08:42:09 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10309 ; Thu, 26 Oct 1995 08:42:07 -0700 From: John Dyson Message-Id: <199510261542.IAA10309@freefall.freebsd.org> Subject: Re: msync is basically busted still (2.1 snap) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Thu, 26 Oct 1995 08:42:06 -0700 (PDT) Cc: hackers@freebsd.org, chuck@maria.wustl.edu, deraadt@theos.com In-Reply-To: from "Ron G. Minnich" at Oct 26, 95 11:01:37 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 448 Sender: owner-hackers@freebsd.org Precedence: bulk > > well, i've been fighting msync in 2.05 now for a bit, trying to get > proper behaviour. It doesn't work. A quick walk through 2.1 shows the > same set of problems. > Painful discussion deleted :-(. Thanks for that observation. Methinks that I will be rethinking things a bit. And I thought we were done. Actually I did know that the msync was bad, but not THAT bad!!!. Another busy weekend coming up I guess. John dyson@freebsd.org From owner-freebsd-hackers Thu Oct 26 08:47:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10604 for hackers-outgoing; Thu, 26 Oct 1995 08:47:51 -0700 Received: from rage.dsw.com (rage.dsw.com [206.43.0.250]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10592 for ; Thu, 26 Oct 1995 08:47:48 -0700 Received: from rage.dsw.com (localhost [127.0.0.1]) by rage.dsw.com (8.6.12/8.6.12) with SMTP id JAA20874 for ; Thu, 26 Oct 1995 09:51:01 -0600 Date: Thu, 26 Oct 1995 09:51:01 -0600 (MDT) From: Pete Kruckenberg To: hackers@freebsd.org Subject: In-place upgrading in 10/20 SNAP? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I apologize for asking this here, but I didn't see any mention of it in the announcement for the latest SNAP. Is in-place upgrading now available in this SNAP, so I can upgrade my exising 2.0.5R system without starting from scratch? Thanks. Pete Kruckenberg pete@dsw.com From owner-freebsd-hackers Thu Oct 26 08:58:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11234 for hackers-outgoing; Thu, 26 Oct 1995 08:58:18 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA11228 for ; Thu, 26 Oct 1995 08:58:12 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA05820; Thu, 26 Oct 1995 10:57:17 -0500 From: Joe Greco Message-Id: <199510261557.KAA05820@brasil.moneng.mei.com> Subject: Re: disk-striping To: graichen@omega.physik.fu-berlin.de (Thomas Graichen) Date: Thu, 26 Oct 1995 10:57:16 -0500 (CDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <9510261304.AA09283@omega.physik.fu-berlin.de> from "Thomas Graichen" at Oct 26, 95 02:04:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > hello > > i remember that someone experimented with disk-striping in the past - is there > anything coming into the FreeBSD tree in the next time ? - is anybody working > on that ? - if not i would like to adapt the NetBSD ccd driver to FreeBSD - > has anybody else tried it (to avoid reinventing the wheel) > > thanks in advance - t I had originally located a striping disk device driver down at Caltech - I think it was called "ilv" - Rod Grimes started to hack on this but decided it wasn't worth the effort. You might wish to ask him what his current status is- He seems to have dropped off the face of the earth lately. The NetBSD ccd stuff looks promising (never having used it). Go for it :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Oct 26 09:37:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12829 for hackers-outgoing; Thu, 26 Oct 1995 09:37:29 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA12824 for ; Thu, 26 Oct 1995 09:37:24 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA01143; Thu, 26 Oct 1995 10:39:31 -0600 Date: Thu, 26 Oct 1995 10:39:31 -0600 From: Nate Williams Message-Id: <199510261639.KAA01143@rocky.sri.MT.net> To: Brian Tao Cc: FREEBSD-HACKERS-L , Larry McVoy Subject: Re: New lmbench available (fwd) In-Reply-To: References: Sender: owner-hackers@freebsd.org Precedence: bulk > I think we should get the biggest, baddest FreeBSD machines around > and submit lmbench results for them... Russell Carter, you there? :) I got a pretty nasty one sitting here that Rod put together for me, but I can't get the lmbench stuff working. I don't have time to mess around with it either, so if it doesn't work I'm not going to take the time to figure it out. Even minimal instructions would be helpful... Hmm, I used RCS to checkout the top-level files, and it now requires something called rccs. This is really standardized. ;( Ahh, I see it requires that . is in your path. Still going. The build blew up when the Makefile attempted to copy /bin/true, which is /usr/bin/true on BSD systems. In any case, I've got it working now. I'm running it first to make sure I don't have any bogus answers, at which point I'll have it sent off to the list. Nate > Subject: New lmbench available > > > P.S. Almost forgot. I stuck the latest on ftp.sgi.com:/pub/lmb.tgz. You > need gunzip to unpack it and rcs to build it, and perl to see the results. > If you have a linux box, all of the scripts for making fancy graphs work. > Cd to lmbench/Results and say "make ps", and then look at the ps files > in PS/*. > > Drafts of the usenix paper are in ftp.sgi.com:/pub/lmbench.ps. Comments > welcome, remember this is an as of yet unpublished document.... From owner-freebsd-hackers Thu Oct 26 10:56:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA15945 for hackers-outgoing; Thu, 26 Oct 1995 10:56:38 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA15934 for hackers; Thu, 26 Oct 1995 10:56:36 -0700 Date: Thu, 26 Oct 1995 10:56:36 -0700 From: Jeffrey Hsu Message-Id: <199510261756.KAA15934@freefall.freebsd.org> To: hackers Subject: Re: cpp question Sender: owner-hackers@FreeBSD.org Precedence: bulk Well, if you use gcc -E or an ANSI cpp, you can use #name. From owner-freebsd-hackers Thu Oct 26 11:12:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16671 for hackers-outgoing; Thu, 26 Oct 1995 11:12:23 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16663 ; Thu, 26 Oct 1995 11:12:20 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id NAA24979; Thu, 26 Oct 1995 13:11:37 -0500 Received: by olympus (4.1/TSS2.1) id AA28231; Thu, 26 Oct 95 13:11:44 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9510261811.AA28231@olympus> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Thu, 26 Oct 1995 13:11:43 -0500 (CDT) Cc: davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <9510250245.AA11614@tellabk.tellabs.com> from "mikebo@tellabs.com" at Oct 24, 95 09:45:17 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 4392 Sender: owner-hackers@freebsd.org Precedence: bulk Mike, Is this your rpc problem again, or are you past that now? Last time you had problems of this sort, I recommended using the noconn option for NFS. It was not the solution for you last time but the symptoms I see here seem more in line with this fix. You mount and then all packets start coming from another interface. Using noconn, keeps you from connecting until you know about the new interface. I hope this works for you this time. Boyd > > David G. wrote: > > Mike Borowiec wrote: > > >The following is Solaris snoop output which shows the problem. TOYBOX > > >is running 2.1.0-951020-SNAP and TELLABK (aka SUNK) is a multi-homed > > >server running SunOS 4.1.3 and "routed -q". First we do the mount: > > > > > ># mount tellabk:/export/home/tellabk-4 /usr/home > > > > > > toybox -> tellabk PORTMAP C GETPORT prog=100003 (NFS) vers=2 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=2049 > > > toybox -> tellabk PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP > > > sunk -> toybox PORTMAP R GETPORT port=737 > > > toybox -> tellabk MOUNT C Mount /export/home/tellabk-4 > > > sunk -> toybox MOUNT R Mount OK F=075B > > > > > >Looks like the mount completed OK, even though the replies came from SUNK, > > >TELLABK's alter-ego. So let's do a "df": > > > > Yeah, that's the problem. This doesn't look like a FreeBSD problem to me - > > it looks like the Sun is replying out a different interface then it received > > the mount request from. FreeBSD rightfully thinks this is crap coming from > > some irrelevant machine. I think you should be able to work around it by using > > the name/address of "sunk" when doing the mount. > > > Yes, the Sun is replying from a different interface than it received > the mount request from. That's because the Sun is running "routed" and > learns its route back to TOYBOX from a RIP announcement made by a router. > Using the name/addr of SUNK may work today - what if tomorrow the router > decides TELLABK is best, or SUNK2, or SUNK3, etc. > > > "Correct" or not, Suns do not always reply back on the same interface > from which they receive a request. It is basically a crap-shoot... Worse, > if the router dynamically changes the route back to TOYBOX, for whatever > reason (down interface, route optimization), the Sun will dutifully begin > replying on a new interface as soon as the RIP announcement is received. > > This isn't something that can be changed on a Sun. Even configuring a > Sun with static routes won't really solve the problem, as someone/sometime > is bound to request a mount from an interface which is not the server's > default route. In that case, the reply would come from the interface > tagged with the default route. The onus is on the client to deal with it... > > This situation is correctly handled by every commercial UNIX OS I've > worked with. I don't know what security implications that has, but I > do know that FreeBSD's NFS (and so the whole OS) is useless to me > (and others running in a similar environment) unless it works with > Suns and plays by their rules. If I can't use the OS, the security > doesn't do me a damn bit of good! > > I can document this behavior in SunOS, Solaris and HP/UX if it will > help strengthen the argument. This is the real world behavior, and I'm > inclined to believe that FreeBSD is not in a position to dictate what's > "proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest > of the commerical UNIX market. > > > Sorry for the rambling discourse, but I need this fixed or I can't > use FreeBSD. At the least, can the "Sun behavior" I need be added > as an option to the mount command? > - Mike > -- > -------------------------------------------------------------------------- > Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. > Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 > 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA > -------------------------------------------------------------------------- > -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-hackers Thu Oct 26 11:20:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17128 for hackers-outgoing; Thu, 26 Oct 1995 11:20:34 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17104 for ; Thu, 26 Oct 1995 11:20:28 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA21395; Thu, 26 Oct 1995 11:11:23 -0700 From: Terry Lambert Message-Id: <199510261811.LAA21395@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Thu, 26 Oct 1995 11:11:23 -0700 (MST) Cc: dyson@freefall.freebsd.org, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, bde@zeta.org.au, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510260321.NAA02246@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 01:21:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 926 Sender: owner-hackers@freebsd.org Precedence: bulk > >2^63 -- the highest bit still being reserved for error return on lseek > >and for indirect block identification. > > The highest bit is not reserved for error return on lseek. Only one value > ((off_t)-1) is reserved. Sorry; "most significant bit". Or if you prefer "sign bit". There, now the location of the bit itself is sufficiently confused. 8-). At least the number of non-sign bits is invariant, if discontiguous. > >The only value of quad is as an annoyance and as a spur to further > > It is expedient. Would you prefer off_t to be double? (That's in the > ABI; inside the kernel and on disks offsets should be represented in > an efficient way, perhaps as quads.) I would prefer it to be whatever unit was used for stack alignment. In this case, int32 on a 386. 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 Oct 26 11:56:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18529 for hackers-outgoing; Thu, 26 Oct 1995 11:56:16 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18515 for ; Thu, 26 Oct 1995 11:56:13 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id LAA28611; Thu, 26 Oct 1995 11:56:04 -0700 From: Julian Elischer Message-Id: <199510261856.LAA28611@ref.tfs.com> Subject: Re: Pthreads and 2.1 To: proven@MIT.EDU (Christopher Provenzano) Date: Thu, 26 Oct 1995 11:56:04 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <9510261442.AA07426@jimi.MIT.EDU> from "Christopher Provenzano" at Oct 26, 95 10:42:55 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 464 Sender: owner-hackers@freebsd.org Precedence: bulk > > > I have a new version of my work that runs on FreeBSD and I'd like > to see it ship in 2.1 under ports or something. Can someone do this? > > CAP We're presently looking (as you know) at official support for pthreads under 2.2 with support for thread-safe modifications under the standard libc sources Your present code might be able to be just able to be squeezed in as a port but it is almost too late to be part of the base distribution.. julian > From owner-freebsd-hackers Thu Oct 26 12:22:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19213 for hackers-outgoing; Thu, 26 Oct 1995 12:22:35 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19207 for ; Thu, 26 Oct 1995 12:22:30 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id MAA28679; Thu, 26 Oct 1995 12:22:20 -0700 From: Julian Elischer Message-Id: <199510261922.MAA28679@ref.tfs.com> Subject: Re: Pthreads and 2.1 To: julian@ref.tfs.com (Julian Elischer) Date: Thu, 26 Oct 1995 12:22:19 -0700 (PDT) Cc: proven@MIT.EDU, hackers@freebsd.org In-Reply-To: <199510261856.LAA28611@ref.tfs.com> from "Julian Elischer" at Oct 26, 95 11:56:04 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 535 Sender: owner-hackers@freebsd.org Precedence: bulk > > > > > > > I have a new version of my work that runs on FreeBSD and I'd like > > to see it ship in 2.1 under ports or something. Can someone do this? > > > > CAP > > We're presently looking (as you know) at official support for > pthreads under 2.2 with support for thread-safe modifications > under the standard libc sources > > Your present code might be able to be just able to be squeezed in as a port > but it is almost too late to be part of the base distribution.. ^^^^^^ certainly > > julian > > > > From owner-freebsd-hackers Thu Oct 26 12:24:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19308 for hackers-outgoing; Thu, 26 Oct 1995 12:24:00 -0700 Received: from devnull (devnull.mpd.tandem.com [131.124.4.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19291 ; Thu, 26 Oct 1995 12:23:57 -0700 Received: from olympus by devnull (8.6.8/8.6.6) id OAA00203; Thu, 26 Oct 1995 14:23:14 -0500 Received: by olympus (4.1/TSS2.1) id AA28585; Thu, 26 Oct 95 14:23:11 CDT From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9510261923.AA28585@olympus> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: mikebo@tellabs.com Date: Thu, 26 Oct 1995 14:23:10 -0500 (CDT) Cc: davew@sees.bangor.ac.uk, bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <199510261417.JAA01701@sunc210.tellabs.com> from "mikebo@tellabs.com" at Oct 26, 95 09:17:03 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1696 Sender: owner-hackers@freebsd.org Precedence: bulk > > Dave wrote: > > > Garrett wrote: > > > > Actually, connect(2) is what is presently being done and part of what > > > > causes the breakage. From mount_nfs(8): > > > > > > > > -c For UDP mount points, do not do a connect(2). This must be used > > > > for servers that do not reply to requests from the standard NFS > > > > port number 2049. > > > > > > > Wahoo! This option did the trick, even though the ip_addrs didn't match. > > > This option did _not_ work under 2.0.5R, due to bad hackage of the RPC > > ^^^^^ > > I beg to differ, we are using 2.0.5R (from the CD) and > > it _was_ the solution to our problem! > > > > > code in libc. It does seem to work under 2.1.0-951020-SNAP! Come to > > > think of it, the "bad hackage" was, in fact, a connect() being done in > > > lib/libc/rpc/clnt_udp.c. > > > I did try "noconn" while monitoring with snoop and a Sniffer, and under > 2.0.5R (from the CD also), it did not solve the problem of differing > ip_addrs. My traces showed ICMP Destination unreachable (Bad port) with > or without noconn. But, there's no arguing with results. I couldn't get > it to work, and documented it months ago. No sense going back now... > - Mike > -- I remember seeing it, too. Oddly enough, the rpc problem did not affect amd which was handling my mounts. (I was already running with noconn.) But, if I tried to connect with mount, it would fail. Boyd -- _______________________________________________________________________ Boyd Faulkner - faulkner@isd.tandem.com - http://cactus.org/~faulkner _______________________________________________________________________ From owner-freebsd-hackers Thu Oct 26 12:40:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19764 for hackers-outgoing; Thu, 26 Oct 1995 12:40:40 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA19757 for ; Thu, 26 Oct 1995 12:40:36 -0700 Received: from JIMI.MIT.EDU by MIT.EDU with SMTP id AA27668; Thu, 26 Oct 95 15:39:50 EDT Received: by jimi.MIT.EDU (5.57/4.7) id AA07699; Thu, 26 Oct 95 15:40:28 -0400 Message-Id: <9510261940.AA07699@jimi.MIT.EDU> To: Richard Toren Cc: hackers@freebsd.org, proven@MIT.EDU Subject: Re: A quick vote on pthreads PLZ In-Reply-To: Your message of "Sat, 21 Oct 1995 21:32:39 EDT." Date: Thu, 26 Oct 1995 15:40:27 EDT From: Christopher Provenzano Sender: owner-hackers@freebsd.org Precedence: bulk > Has the FPU save/restore been fixed in pthreads recently? Yes. > > With the locking in the libraries, what will the gratutious mutex locking > cost in time if the app is not threaded? For the most part it shouldn't be noticable. (There are a few exceptions namely getc()/putc()) In general mutexes are cheap, debugging race conditions isn't. > > Just some food for thought. I have used pthreads since this summer to > practice threaded code analysis and construction, but I knew it was just > a package, and had limitations. If it is advertised as being part of the > OS, (and possibly POSIX) wil lit mislead people? I hope not, but to be safe a non threaded one should be provided. It will take time to hammer out the bugs such that the threaded one will be as reliable as the non threaded one. CAP From owner-freebsd-hackers Thu Oct 26 13:47:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA23958 for hackers-outgoing; Thu, 26 Oct 1995 13:47:34 -0700 Received: from bacchus.eng.umd.edu (bacchus.eng.umd.edu [129.2.94.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA23953 for ; Thu, 26 Oct 1995 13:47:28 -0700 Received: from espresso.eng.umd.edu (espresso.eng.umd.edu [129.2.98.13]) by bacchus.eng.umd.edu (8.7/8.7) with ESMTP id QAA14280; Thu, 26 Oct 1995 16:47:25 -0400 (EDT) Received: (chuckr@localhost) by espresso.eng.umd.edu (8.7/8.6.4) id QAA16791; Thu, 26 Oct 1995 16:47:23 -0400 (EDT) Date: Thu, 26 Oct 1995 16:47:21 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@espresso.eng.umd.edu To: Poul-Henning Kamp cc: hackers@freebsd.org Subject: Re: cpp question In-Reply-To: <673.814700238@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Thu, 26 Oct 1995, Poul-Henning Kamp wrote: > > My new testament is at home, can somebody tell me in the meantime: > > What do I write in a macro to make a token a string ? > > I want to do something like this: > > #define FOO(ptr,fmt,name) \ > printf("%s =" fmt "\n", XXXX, (ptr)->name) > > What do I need to put at XXXX ? to convert the name to "name" ? Testament (H&S), page 41: #define TEST(a,b) printf( #a "<" #b "=%d\n", (a)<(b) ) TEST(0,0xFFFF); becomes printf("0<0xFFFF=%d\n", (0)<(0xFFFF)) ); > > Thanks in advance, > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. > Just that: dried leaves in boiling water ? > ========================================================================== Chuck Robey chuckr@eng.umd.edu, I run FreeBSD-current on n3lxx + Journey2 Three Accounts for the Super-users in the sky, Seven for the Operators in their halls of fame, Nine for Ordinary Users doomed to crie, One for the Illegal Cracker with his evil game In the Domains of Internet where the data lie. One Account to rule them all, One Account to watch them, One Account to make them all and in the network bind them. From owner-freebsd-hackers Thu Oct 26 14:06:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA25359 for hackers-outgoing; Thu, 26 Oct 1995 14:06:27 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA25351 for ; Thu, 26 Oct 1995 14:06:22 -0700 Received: from JIMI.MIT.EDU by MIT.EDU with SMTP id AA11938; Thu, 26 Oct 95 17:05:32 EDT Received: by jimi.MIT.EDU (5.57/4.7) id AA07977; Thu, 26 Oct 95 17:06:14 -0400 Message-Id: <9510262106.AA07977@jimi.MIT.EDU> To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Pthreads and 2.1 In-Reply-To: Your message of "Thu, 26 Oct 1995 11:56:04 PDT." <199510261856.LAA28611@ref.tfs.com> Date: Thu, 26 Oct 1995 17:06:12 EDT From: Christopher Provenzano Sender: owner-hackers@freebsd.org Precedence: bulk > > > > > > I have a new version of my work that runs on FreeBSD and I'd like > > to see it ship in 2.1 under ports or something. Can someone do this? > > > > CAP > > We're presently looking (as you know) at official support for > pthreads under 2.2 with support for thread-safe modifications > under the standard libc sources > > Your present code might be able to be just able to be squeezed in as a port > but it is almost too late to be part of the base distribution.. Squeezing it in as a port is all I'm asking for right now. There is a lot of work to be done to get rolled into the standard libc sources. CAP From owner-freebsd-hackers Thu Oct 26 14:11:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA25665 for hackers-outgoing; Thu, 26 Oct 1995 14:11:49 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA25653 for ; Thu, 26 Oct 1995 14:11:45 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA21640; Thu, 26 Oct 1995 14:02:50 -0700 From: Terry Lambert Message-Id: <199510262102.OAA21640@phaeton.artisoft.com> Subject: Re: cpp question To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 26 Oct 1995 14:02:50 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <673.814700238@critter.tfs.com> from "Poul-Henning Kamp" at Oct 26, 95 10:37:18 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 464 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > My new testament is at home, can somebody tell me in the meantime: > > What do I write in a macro to make a token a string ? > > I want to do something like this: > > #define FOO(ptr,fmt,name) \ > printf("%s =" fmt "\n", XXXX, (ptr)->name) > > What do I need to put at XXXX ? to convert the name to "name" ? #name 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 Oct 26 14:34:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA27759 for hackers-outgoing; Thu, 26 Oct 1995 14:34:28 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27754 for ; Thu, 26 Oct 1995 14:34:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA21688; Thu, 26 Oct 1995 14:24:07 -0700 From: Terry Lambert Message-Id: <199510262124.OAA21688@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: dyson@freefall.freebsd.org (John Dyson) Date: Thu, 26 Oct 1995 14:24:07 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510261356.GAA06844@freefall.freebsd.org> from "John Dyson" at Oct 26, 95 06:56:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4035 Sender: owner-hackers@freebsd.org Precedence: bulk > The VM limitations are due to extreme performance hits if we have to > go to a (long long) type representation of a page. I propose that we > (in fact we will) move from page offsets to page indexes. For a 32 bit > machine, it gives us at least 8TB (and probably more with sign extension > fixes) for file/filesystem sizes. For a 64 bit machine it would give us > even more (by a factor of 4,000,000). As far as the API is concerned, > we can use whatever we want -- long, long long, or whatever. We will > just have that terrible, limiting capability of supporting only 8TB files on > 32 bit machines with 4K pagesizes. I think we have to work in the scope of device block addressing, which is 2^31 * 512 or 1TB, as opposed to page addressing at 4TB. The 8TB figure, I think, represents the value without the use of the "improved" UFS indirect block handling that came with 4.4. There are a number of ideas (like page anonymity based page protection) which can't be implemented without a large statistical range for the hash -- typically larger than 32 bits with machine memory sizes running into the 100's of MB. For the Alpha, at least (a nominally 64bit machine), the address range for real memory is restricted to less than 64 bits. The problem that is arising in all these cases is the buffer cache mapping of file data for large ranges requiring a linear relationship throughout the file instead of a smaller linear "window" onto the file. This would require a domain/range based offset + length mapping, allowing multiple mapping windows per file to address the issue completely satisfactorily for 64 bit block and file offsets on 32 bit Intel architectures. Such an approach would not have the "long long" drawbacks that would otherwise be introduced, though there would be *some* (lesser) overhead involved. > We haven't worked on the sign extension problems, because simply we do not > support files > 4GB (or is it 2GB???) period right now. I don't believe that > there is a problem with block devices (we do NOT use vmio for those.) But > additionally we do not support mmaping them right now. It's 2G of file, 1T of file system at present, with a single 32 bit sector offset for a max of 8G based on the dos partitioning and disklabel issues. Ie: a very big partition is allowable, but it must start in the 0-8G range, and disklabellimits the length. I'd like to address the 2G file size problem. The 2G limit currently makes the use of quad off_t's in our internal interfaces a laughable and gratuitous barrier to source compatability with legacy code (the only kind we have, unless you know about a commercial venture that I don't). > The changes have been so vast that there has been significant ugliness > added to the code. That is being worked on, and I suggest that if there > are some architectural problems that you see -- 'corrected' code would be > helpful. Note also some sort of performance analysis and architectural > impact review is desirable. All I can say is that I spent nearly a year > working on the most horrible OS code that I ever saw -- SVR4, and I don't > want us to go down the low performance path that they did. They got both > the hackery and low performance. At least we are working on cleaning up > the hackery aspects, including that which was inherited from Mach (because > of the differences in the philosophy -- Mach VM and the original BSD port > was certainly interesting.) I agree with all of this. It seems that the most interesting places to work are the boundries, and right now the 2G file size limit is one of those, at least for me. At the very least, I'd like to see the system limits on VM mappable space go away as part of the necessary changes. Has any consideration been made to pulling in the NetBSD non-vmio based changes, or to making the vmio/non-vmio switch a bit smoother and less intrusive? 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 Oct 26 14:52:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28782 for hackers-outgoing; Thu, 26 Oct 1995 14:52:03 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28745 for ; Thu, 26 Oct 1995 14:51:43 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17570; Thu, 26 Oct 1995 22:50:51 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA16547; Thu, 26 Oct 1995 22:50:51 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id WAA29123; Thu, 26 Oct 1995 22:37:33 +0100 From: J Wunsch Message-Id: <199510262137.WAA29123@uriah.heep.sax.de> Subject: Re: cpp question To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 26 Oct 1995 22:37:33 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <673.814700238@critter.tfs.com> from "Poul-Henning Kamp" at Oct 26, 95 10:37:18 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 740 Sender: owner-hackers@freebsd.org Precedence: bulk As Poul-Henning Kamp wrote: > > > My new testament is at home, can somebody tell me in the meantime: > > What do I write in a macro to make a token a string ? > > I want to do something like this: > > #define FOO(ptr,fmt,name) \ > printf("%s =" fmt "\n", XXXX, (ptr)->name) > > What do I need to put at XXXX ? to convert the name to "name" ? #define FOO(ptr,fmt,name) \ printf("%s =" fmt "\n", # name, (ptr)->name) or simpler: #define FOO(ptr,fmt,name) \ printf(# name " =" fmt "\n", (ptr)->name) (ANSI mandates that "foo" "bar" yields the single string "foobar".) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Oct 26 15:08:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA29839 for hackers-outgoing; Thu, 26 Oct 1995 15:08:50 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA29801 ; Thu, 26 Oct 1995 15:08:29 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8aSZ-000jCvC; Thu, 26 Oct 95 17:07 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id RAA00763; Thu, 26 Oct 1995 17:07:34 -0500 Message-Id: <199510262207.RAA00763@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: faulkner@mpd.tandem.com (Boyd Faulkner) Date: Thu, 26 Oct 1995 17:07:33 -0500 (CDT) Cc: mikebo (Mike Borowiec), davidg@Root.COM, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <9510261811.AA28231@olympus> from "Boyd Faulkner" at Oct 26, 95 01:11:43 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 Precedence: bulk Boyd wrote: > Is this your rpc problem again, or are you past that now? Last time you > had problems of this sort, I recommended using the noconn option for NFS. > It was not the solution for you last time but the symptoms I see here seem > more in line with this fix. You mount and then all packets start coming > from another interface. Using noconn, keeps you from connecting until you > know about the new interface. I hope this works for you this time. > -------------------------------------------------------------------------- PROBLEM DEFINITION: Server: Multi-homed Sun server running routed (receiving routes via RIP) Client: distant FreeBSD 2.x client (not on any of the servers ethernets) The Server's IP route to Client's network is unknown, and may change whenever the Server receives a RIP update from router. The following scenarios assume that: 1) The client is not on any network to which the server has a direct ethernet connection. 2) Packets arrive from the client on server's ethernet interface 'A'. 3) The server's route table contains a route to the client's network. 4) The route in 3) causes packets sent to the client to leave server's ethernet interface 'B'. Result: reply source address is different than request destination address. Under 2.0.5R (with or without noconn option): MOUNT command hangs unkillable on Client. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (without noconn option): MOUNT command completes OK. Provided no other access to the file- system are attempted first, UMOUNT also completes OK. However, any commands which access the now mounted filesystem (such as df or ls) hang unkillable and file system can not be UMOUNTED. Client reaction: ICMP message "Destination unreachable (Bad port)" sent to responding IP address. Under 2.1.0-951020-SNAP (with noconn option): MOUNT and UMOUNT command completes OK. All accesses to mounted filesystem complete OK. Everything appears OK. This is the normal behaviour of most major commercial UNIX and UNIX-like OSes. -------------------------------------------------------------------------- Hopefully, this is the last time I need to document this. ;v) I do have a question: Would a FreeBSD server always respond to a client from the same interface on which it received a request - even though its route table has a different route to the clients network? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Thu Oct 26 16:12:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA03473 for hackers-outgoing; Thu, 26 Oct 1995 16:12:48 -0700 Received: from plains.nodak.edu (89@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA03466 for ; Thu, 26 Oct 1995 16:12:45 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id SAA01148; Thu, 26 Oct 1995 18:12:26 -0500 Date: Thu, 26 Oct 1995 18:12:26 -0500 From: Mark Tinguely Message-Id: <199510262312.SAA01148@plains.nodak.edu> To: dufault@hda.com, hackers@freebsd.org Subject: Re: Physically contig memory in user process Content-Length: 636 Sender: owner-hackers@freebsd.org Precedence: bulk if you implement contigous page allocation using vm_page_alloc_contig, start above the 1 MB mark, because I found writing the meteor capture driver that if you allocate a good size chunk that starts below the 1 MB mark it could panic the system when you free the chunk. my video buffer was large enough to do it every time. starting above the 1MB mark works correctly every time. I figure it had to do with the hole between 640KB and 1MB, but that is not backed with real evidence. why not allocate the buffers as part of the device's driver and mmap them into user space instead of allocating them into users space directly? --mark. From owner-freebsd-hackers Thu Oct 26 16:45:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA06534 for hackers-outgoing; Thu, 26 Oct 1995 16:45:17 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA06505 for ; Thu, 26 Oct 1995 16:45:13 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id TAA07049; Thu, 26 Oct 1995 19:47:44 -0400 From: Peter Dufault Message-Id: <199510262347.TAA07049@hda.com> Subject: Re: Physically contig memory in user process To: tinguely@plains.nodak.edu (Mark Tinguely) Date: Thu, 26 Oct 1995 19:47:43 -0400 (EDT) Cc: hackers@freebsd.org In-Reply-To: <199510262312.SAA01148@plains.nodak.edu> from "Mark Tinguely" at Oct 26, 95 06:12:26 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 554 Sender: owner-hackers@freebsd.org Precedence: bulk > why not allocate the buffers as part of the device's driver and mmap them into > user space instead of allocating them into users space directly? I thought one may not usually care about going through bounce buffers or splitting up the transfer, and that when you did you may as well have a generic way of doing it by mmapping /dev/mem and not having it in the individual drivers. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Thu Oct 26 17:39:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA08994 for hackers-outgoing; Thu, 26 Oct 1995 17:39:54 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA08988 for ; Thu, 26 Oct 1995 17:39:51 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.12/8.6.9) id RAA26084 for hackers@freebsd.org; Thu, 26 Oct 1995 17:39:14 -0700 Date: Thu, 26 Oct 1995 17:39:14 -0700 From: "Jordan K. Hubbard" Message-Id: <199510270039.RAA26084@time.cdrom.com> To: hackers@freebsd.org Subject: Of possible interest.. Sender: owner-hackers@freebsd.org Precedence: bulk This software was, BTW, apparently developed under FreeBSD! The authors have also indicated that they will be making this software available under special terms (I believe "free") to non-profit organizations. It looks very interesting! http://www.p3.com/p3/p3bullet.html From owner-freebsd-hackers Thu Oct 26 18:10:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10398 for hackers-outgoing; Thu, 26 Oct 1995 18:10:53 -0700 Received: from news.us.world.net (news.us.world.net [192.243.32.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA10384 for ; Thu, 26 Oct 1995 18:10:40 -0700 Received: from merix.merix.com (merix.com [198.145.172.40]) by news.us.world.net (8.6.9/8.6.9) with SMTP id SAA01669 for ; Thu, 26 Oct 1995 18:10:36 -0700 Received: from sandy.merix.com by merix.merix.com (4.1/1.1) id AA20121; Thu, 26 Oct 95 18:08:04 PDT Received: by sandy.merix.com (4.1/8.0) id AA08545; Thu, 26 Oct 95 18:08:55 PDT Date: Thu, 26 Oct 95 18:08:55 PDT From: troyc@sandy.merix.com (Troy Curtiss) Message-Id: <9510270108.AA08545@sandy.merix.com> To: freebsd-hackers@freebsd.org Subject: Interested in PS/2 driver re-write... Sender: owner-hackers@freebsd.org Precedence: bulk Hi, I am interested in rewriting the PS/2 mouse driver. I was told it would make more sense to integrate it into the console driver, so before I go any farther, could someone enlighten me about the pitfalls of this. I remember something about probing certain keyboard controllers breaks stuff... Getting rid of the kernel re-compile to add the ps/2 mouse would be a big gain for freebsd... Thanx Regards, Troy Curtiss From owner-freebsd-hackers Thu Oct 26 18:43:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA12364 for hackers-outgoing; Thu, 26 Oct 1995 18:43:33 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA12358 for ; Thu, 26 Oct 1995 18:43:27 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id VAA06090; Thu, 26 Oct 1995 21:43:12 -0400 From: Charles Henrich Message-Id: <199510270143.VAA06090@crh.cl.msu.edu> Subject: Important 951020-SNAP bugs To: freebsd-hackers@freebsd.org Date: Thu, 26 Oct 1995 21:43:12 -0400 (EDT) Cc: jkh@time.cdrom.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 369 Sender: owner-hackers@freebsd.org Precedence: bulk Two verra important things: 1) The installer requires a /usr partition, it will fail without it :( :( 2) Once you actually get it installed, if you run telnet you get Can't find shared library "libdes.2.0.so" and telnet exits. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Thu Oct 26 18:44:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA12458 for hackers-outgoing; Thu, 26 Oct 1995 18:44:45 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA12452 for ; Thu, 26 Oct 1995 18:44:40 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA03300; Thu, 26 Oct 1995 18:43:50 -0700 To: Charles Henrich cc: freebsd-hackers@freebsd.org Subject: Re: Important 951020-SNAP bugs In-reply-to: Your message of "Thu, 26 Oct 1995 21:43:12 EDT." <199510270143.VAA06090@crh.cl.msu.edu> Date: Thu, 26 Oct 1995 18:43:50 -0700 Message-ID: <3298.814758230@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Two verra important things: > > 1) The installer requires a /usr partition, it will fail without it :( :( Already fixed. > 2) Once you actually get it installed, if you run telnet you get > Can't find shared library "libdes.2.0.so" and telnet exits. I just did this, and it works fine. What distributions are you selecting? Jordan From owner-freebsd-hackers Thu Oct 26 18:58:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA13049 for hackers-outgoing; Thu, 26 Oct 1995 18:58:19 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA13043 for ; Thu, 26 Oct 1995 18:58:17 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id VAA06176; Thu, 26 Oct 1995 21:57:57 -0400 From: Charles Henrich Message-Id: <199510270157.VAA06176@crh.cl.msu.edu> Subject: Re: Important 951020-SNAP bugs To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 26 Oct 1995 21:57:57 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <3298.814758230@time.cdrom.com> from "Jordan K. Hubbard" at Oct 26, 95 06:43:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 938 Sender: owner-hackers@freebsd.org Precedence: bulk > Already fixed. Great! Any chance of a new floppy soon? > > 2) Once you actually get it installed, if you run telnet you get > > Can't find shared library "libdes.2.0.so" and telnet exits. > > I just did this, and it works fine. What distributions are you > selecting? Here is exactly what I did (this has happneed on 5+ install attempts) custom operations (debug to yes, yes to all) part all label 100M / 100M /usr 100M swap distributions, custom bin,des,dict,info,man,proflibs,src des(des) src(sys) Media ftp active commit stand boot --- A new one: If you dont create a /usr then go through the commit and it fails and then you go back and add a /usr it fails to properly create the partition, causing /usr to fail mounting on reboot (blks x,x,x,x unreadable is the error msg) -Crh From owner-freebsd-hackers Thu Oct 26 19:11:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13566 for hackers-outgoing; Thu, 26 Oct 1995 19:11:19 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13539 for ; Thu, 26 Oct 1995 19:10:39 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id NAA00256; Thu, 26 Oct 1995 13:24:02 GMT Date: Thu, 26 Oct 1995 13:24:02 +0000 () From: Sergio Lenzi To: hackers@freebsd.org Subject: Re: A few questions.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-952326419-814713842=:194" Sender: owner-hackers@freebsd.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-952326419-814713842=:194 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello jason, I use this kind of thing (ppp and slip) here. I put "options GATEWAY" in the conf file run routed with options -s Make a table in the form: tty ip ttyd1 200.123.14.14 ttyd2 200.123.14.15 ttyd3 200.123.14.16 .... When a user logs_in it starts an awk program that given a tty it returns an ip. ip=awk "\$1 == \"$1\"{print \$2}' < tbl after that, the ppp program is run.... pppd passive :$ip in the /etc/ppp options -> Bmodem crtscts For the slip question I coded an slip program... that runs un ifconfig + route command at start and route delete + ifconfig at carrier lost.... --0-952326419-814713842=:194 Content-Type: APPLICATION/octet-stream; name="slip.tar" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: c2xpcC5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADEwMDY2NCAAICAxNzczIAAgIDE3NjMgACAgICAgIDEwMzY1 ICA2MDQxMTcxNzQ0ICAxMjE0MAAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAGNhZGFz dHJvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY2FkYXN0cm8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiNpbmNs dWRlIDxzeXMvc29ja2V0Lmg+CiNpbmNsdWRlIDxzeXMvc2lnbmFsLmg+CiNp bmNsdWRlIDxzeXMvZmlsZS5oPgojaW5jbHVkZSA8c3lzL3N5c2xvZy5oPgoj aW5jbHVkZSA8bmV0ZGIuaD4KCiNpbmNsdWRlIDxzeXMvdGVybWlvcy5oPgoj aW5jbHVkZSA8c3lzL2lvY3RsLmg+CiNpbmNsdWRlIDx0dHllbnQuaD4KI2lu Y2x1ZGUgPG5ldC9zbGlwLmg+CgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1 ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxjdHlwZS5oPgojaW5jbHVkZSA8c3Ry aW5nLmg+CgpzdGF0aWMgaW50CXVuaXQ7CnN0YXRpYyBpbnQJc3BlZWQ7CnN0 YXRpYyBpbnQJdWlkOwpzdGF0aWMgY2hhcglsb2dpbm5hbWVbQlVGU0laXTsK c3RhdGljIGNoYXIJKmxvZ291dGZpbGU7CnN0YXRpYyBjaGFyICppcDEsKmlw MjsKCmNoYXIgKgpzaWdzdHIocykKCWludCBzOwp7CglzdGF0aWMgY2hhciBi dWZbMzJdOwoKCXN3aXRjaCAocykgewoJY2FzZSBTSUdIVVA6CXJldHVybigi SFVQIik7CgljYXNlIFNJR0lOVDoJcmV0dXJuKCJJTlQiKTsKCWNhc2UgU0lH UVVJVDoJcmV0dXJuKCJRVUlUIik7CgljYXNlIFNJR0lMTDoJcmV0dXJuKCJJ TEwiKTsKCWNhc2UgU0lHVFJBUDoJcmV0dXJuKCJUUkFQIik7CgljYXNlIFNJ R0lPVDoJcmV0dXJuKCJJT1QiKTsKCWNhc2UgU0lHRU1UOglyZXR1cm4oIkVN VCIpOwoJY2FzZSBTSUdGUEU6CXJldHVybigiRlBFIik7CgljYXNlIFNJR0tJ TEw6CXJldHVybigiS0lMTCIpOwoJY2FzZSBTSUdCVVM6CXJldHVybigiQlVT Iik7CgljYXNlIFNJR1NFR1Y6CXJldHVybigiU0VHViIpOwoJY2FzZSBTSUdT WVM6CXJldHVybigiU1lTIik7CgljYXNlIFNJR1BJUEU6CXJldHVybigiUElQ RSIpOwoJY2FzZSBTSUdBTFJNOglyZXR1cm4oIkFMUk0iKTsKCWNhc2UgU0lH VEVSTToJcmV0dXJuKCJURVJNIik7CgljYXNlIFNJR1VSRzoJcmV0dXJuKCJV UkciKTsKCWNhc2UgU0lHU1RPUDoJcmV0dXJuKCJTVE9QIik7CgljYXNlIFNJ R1RTVFA6CXJldHVybigiVFNUUCIpOwoJY2FzZSBTSUdDT05UOglyZXR1cm4o IkNPTlQiKTsKCWNhc2UgU0lHQ0hMRDoJcmV0dXJuKCJDSExEIik7CgljYXNl IFNJR1RUSU46CXJldHVybigiVFRJTiIpOwoJY2FzZSBTSUdUVE9VOglyZXR1 cm4oIlRUT1UiKTsKCWNhc2UgU0lHSU86CXJldHVybigiSU8iKTsKCWNhc2Ug U0lHWENQVToJcmV0dXJuKCJYQ1BVIik7CgljYXNlIFNJR1hGU1o6CXJldHVy bigiWEZTWiIpOwoJY2FzZSBTSUdWVEFMUk06CXJldHVybigiVlRBTFJNIik7 CgljYXNlIFNJR1BST0Y6CXJldHVybigiUFJPRiIpOwoJY2FzZSBTSUdXSU5D SDoJcmV0dXJuKCJXSU5DSCIpOwojaWZkZWYgU0lHTE9TVAoJY2FzZSBTSUdM T1NUOglyZXR1cm4oIkxPU1QiKTsKI2VuZGlmCgljYXNlIFNJR1VTUjE6CXJl dHVybigiVVNSMSIpOwoJY2FzZSBTSUdVU1IyOglyZXR1cm4oIlVTUjIiKTsK CX0KCSh2b2lkKXNwcmludGYoYnVmLCAic2lnICVkIiwgcyk7CglyZXR1cm4o YnVmKTsKfQoKdm9pZCBodXBfaGFuZGxlcihzKQoJaW50IHM7CnsKCWNoYXIg Y21kWzIqTUFYUEFUSExFTiszMl07CgoJc2V0ZXVpZCgwKTsKCWlmIChhY2Nl c3MobG9nb3V0ZmlsZSwgUl9PS3xYX09LKSA9PSAwKSB7CgkJc3ByaW50Zihj bWQsICIlcyAlZCAlcyAlcyIsIGxvZ291dGZpbGUsIHVuaXQsaXAxLGlwMik7 CgkJc3lzdGVtKGNtZCk7Cgl9CgljbG9zZSgwKTsKCXN5c2xvZyhMT0dfSU5G TywgImNsb3NlZCAlcyBzbGlwIHVuaXQgJWQgKCVzKVxuIiwKCQlsb2dpbm5h bWUsCgkJdW5pdCwKCQlzaWdzdHIocykpOwoJZXhpdCgwKTsKCS8qIE5PVFJF QUNIRUQgKi8KfQoKbWFpbihpbnQgYWMsY2hhciAqKmF2KSB7CglpbnQgZmQs IHMsIGxkaXNjLCBvZGlzYzsKCWNoYXIgKm5hbWUsKmxvZ2luZmlsZTsKCXN0 cnVjdCB0ZXJtaW9zIHRpb3MsIG90aW9zOwoJY2hhciBsb2dpbmNtZFsyKkJV RlNJWiszMl07CglleHRlcm4gdWlkX3QgZ2V0dWlkKCk7CglleHRlcm4gY2hh ciAqZ2V0bG9naW4oKTsKCglpZiAoYWMgPCA1KSB7CgkJZnByaW50ZihzdGRl cnIsInVzZSAlcyBpY21kIG91dGNtZCBpcGZyb20gaXB0b1xuIiwKCQkJYXZb MF0pOwoJCWV4aXQgKDEpOwoJfQoJcyA9IGdldGR0YWJsZXNpemUoKTsKCWZv ciAoZmQgPSAzIDsgZmQgPCBzIDsgZmQrKykKCQkodm9pZCkgY2xvc2UoZmQp OwoJbG9naW5maWxlPWF2WzFdOwoJbG9nb3V0ZmlsZT1hdlsyXTsKCWlwMT1h dlszXTsKCWlwMj1hdls0XTsKCW9wZW5sb2cobmFtZSwgTE9HX1BJRCwgTE9H X0RBRU1PTik7Cgl1aWQgPSBnZXR1aWQoKTsKCglpZiAoKG5hbWUgPSBnZXRs b2dpbigpKSA9PSBOVUxMKSB7CgkJZnByaW50ZihzdGRlcnIsICJhY2Nlc3Mg ZGVuaWVkIC0gbm8gdXNlcm5hbWVcbiIpOwoJCWV4aXQoMSk7Cgl9CglzdHJj cHkobG9naW5uYW1lLG5hbWUpOwoJKHZvaWQpIGZjaG1vZCgwLCAwNjAwKTsK CWZwcmludGYoc3RkZXJyLCAic3RhcnRpbmcgc2xpcCBsb2dpbiBmb3IgJXNc biIsIGxvZ2lubmFtZSk7CgkvKiBzZXQgdXAgdGhlIGxpbmUgcGFyYW1ldGVy cyAqLwoJaWYgKHRjZ2V0YXR0cigwLCAmdGlvcykgPCAwKSB7CgkJc3lzbG9n KExPR19FUlIsICJ0Y2dldGF0dHI6ICVtIik7CgkJZXhpdCgxKTsKCX0KCW90 aW9zID0gdGlvczsKCWNmbWFrZXJhdygmdGlvcyk7Cgl0aW9zLmNfaWZsYWcg Jj0gfklNQVhCRUw7CglpZiAodGNzZXRhdHRyKDAsIFRDU0FGTFVTSCwgJnRp b3MpIDwgMCkgewoJCXN5c2xvZyhMT0dfRVJSLCAidGNzZXRhdHRyOiAlbSIp OwoJCWV4aXQoMSk7Cgl9CglzcGVlZCA9IGNmZ2V0aXNwZWVkKCZ0aW9zKTsK CS8qIGZpbmQgb3V0IHdoYXQgbGRpc2Mgd2Ugc3RhcnRlZCB3aXRoICovCglp ZiAoaW9jdGwoMCwgVElPQ0dFVEQsIChjYWRkcl90KSZvZGlzYykgPCAwKSB7 CgkJc3lzbG9nKExPR19FUlIsICJpb2N0bChUSU9DR0VURCkgKDEpOiAlbSIp OwoJCWV4aXQoMSk7Cgl9CglsZGlzYyA9IFNMSVBESVNDOwoJaWYgKGlvY3Rs KDAsIFRJT0NTRVRELCAoY2FkZHJfdCkmbGRpc2MpIDwgMCkgewoJCXN5c2xv ZyhMT0dfRVJSLCAiaW9jdGwoVElPQ1NFVEQpOiAlbSIpOwoJCWV4aXQoMSk7 Cgl9CgkvKiBmaW5kIG91dCB3aGF0IHVuaXQgbnVtYmVyIHdlIHdlcmUgYXNz aWduZWQgKi8KCWlmIChpb2N0bCgwLCBTTElPQ0dVTklULCAoY2FkZHJfdCkm dW5pdCkgPCAwKSB7CgkJc3lzbG9nKExPR19FUlIsICJpb2N0bCAoU0xJT0NH VU5JVCk6ICVtIik7CgkJZXhpdCgxKTsKCX0KCSh2b2lkKSBzaWduYWwoU0lH SFVQLCBodXBfaGFuZGxlcik7Cgkodm9pZCkgc2lnbmFsKFNJR1RFUk0sIGh1 cF9oYW5kbGVyKTsKCglzeXNsb2coTE9HX0lORk8sCgkJImF0dGFjaGluZyBz bGlwIHVuaXQgJWQgZm9yICVzXG4iLAoJCXVuaXQsCgkJbG9naW5uYW1lKTsK CSh2b2lkKXNwcmludGYobG9naW5jbWQsICIlcyAlZCAlcyAlcyIsCgkJbG9n aW5maWxlLAoJCXVuaXQsCgkJaXAxLAoJCWlwMik7CgkvKgoJICogYWltIHN0 ZG91dCBhbmQgZXJyb3V0IGF0IC9kZXYvbnVsbCBzbyBsb2dpbmNtZCBvdXRw dXQgd29uJ3QKCSAqIGJhYmJsZSBpbnRvIHRoZSBzbGlwIHR0eSBsaW5lLgoJ ICovCgkodm9pZCkgY2xvc2UoMSk7CglpZiAoKGZkID0gb3BlbigiL2Rldi9u dWxsIiwgT19XUk9OTFkpKSAhPSAxKSB7CgkJaWYgKGZkIDwgMCkgewoJCQlz eXNsb2coTE9HX0VSUiwgIm9wZW4gL2Rldi9udWxsOiAlbSIpOwoJCQlleGl0 KDEpOwoJCX0KCQkodm9pZCkgZHVwMihmZCwgMSk7CgkJKHZvaWQpIGNsb3Nl KGZkKTsKCX0KCSh2b2lkKSBkdXAyKDEsIDIpOwoKCS8qCgkgKiBSdW4gbG9n aW4gYW5kIGxvZ291dCBzY3JpcHRzIGFzIHJvb3QgKHJlYWwgYW5kIGVmZmVj dGl2ZSk7CgkgKiBjdXJyZW50IHJvdXRlKDgpIGlzIHNldHVpZCByb290LCBh bmQgY2hlY2tzIHRoZSByZWFsIHVpZAoJICogdG8gc2VlIHdoZXRoZXIgY2hh bmdlcyBhcmUgYWxsb3dlZCAob3IganVzdCAicm91dGUgZ2V0IikuCgkgKi8K CSh2b2lkKSBzZXR1aWQoMCk7CglpZiAocyA9IHN5c3RlbShsb2dpbmNtZCkp IHsKCQlzeXNsb2coTE9HX0VSUiwKCQkJIiVzIGxvZ2luIGZhaWxlZDogZXhp dCBzdGF0dXMgJWQgZnJvbSAlcyIsCgkJICAgICAgIGxvZ2lubmFtZSwKCQkg ICAgICAgcywKCQkgICAgICAgbG9naW5maWxlKTsKCQlpb2N0bCgwLCBUSU9D U0VURCwgKGNhZGRyX3QpJm9kaXNjKTsKCQlleGl0KDYpOwoJfQoKCS8qIHJl c2V0IHVpZCB0byB1c2VycycgdG8gYWxsb3cgdGhlIHVzZXIgdG8gZ2l2ZSBh IHNpZ25hbC4gKi8KCXNldGV1aWQodWlkKTsKCS8qIHR3aWRkbGUgdGh1bWJz IHVudGlsIHdlIGdldCBhIHNpZ25hbCAqLwoJcGF1c2UoKTsKfQoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzbGlwbG9naW4u c2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MTAwNjY2IAAgIDE3NzMgACAgMTc2MyAAICAgICAgICAxMjAgIDYwMzcyNjcy NzYgIDEzMzIyACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAY2FkYXN0cm8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABjYWRhc3RybwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACMhL2Jpbi9zaAppZmFjZT0kMQppcDE9JDIKaXAyPSQzCmlmY29u ZmlnIHNsJGlmYWNlICRpcDEgJGlwMiBuZXRtYXNrIDB4ZmZmZmZmZmYKAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAc2xpcGxvZ291dC5zaAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEwMDY2NiAAICAx NzczIAAgIDE3NjMgACAgICAgICAgMTMzICA2MDQxMTcxMzAyICAxMzUwMgAg MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB1c3RhciAgAGNhZGFzdHJvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAY2FkYXN0cm8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjIS9i aW4vc2gKaWZhY2U9JDEKaXAxPSQyCmlwMj0kMwovc2Jpbi9pZmNvbmZpZyBz bCRpZmFjZSBkb3duCi9zYmluL3JvdXRlIGRlbGV0ZSAkaXAxICRpcDIKAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --0-952326419-814713842=:194-- From owner-freebsd-hackers Thu Oct 26 19:11:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13589 for hackers-outgoing; Thu, 26 Oct 1995 19:11:38 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13583 for ; Thu, 26 Oct 1995 19:11:34 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id TAA05071; Thu, 26 Oct 1995 19:10:37 -0700 To: Charles Henrich cc: freebsd-hackers@freebsd.org Subject: Re: Important 951020-SNAP bugs In-reply-to: Your message of "Thu, 26 Oct 1995 21:57:57 EDT." <199510270157.VAA06176@crh.cl.msu.edu> Date: Thu, 26 Oct 1995 19:10:36 -0700 Message-ID: <5062.814759836@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > Already fixed. > > Great! Any chance of a new floppy soon? Late tonite (PST). 951026-SNAP is building now.. >Here is exactly what I did (this has happneed on 5+ install attempts) > >custom Uhhh.. It's details of just what you selected in the above that I'm most lacking! :-) Jordan From owner-freebsd-hackers Thu Oct 26 19:12:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13722 for hackers-outgoing; Thu, 26 Oct 1995 19:12:47 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA13702 for ; Thu, 26 Oct 1995 19:12:42 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id WAA06253; Thu, 26 Oct 1995 22:12:19 -0400 From: Charles Henrich Message-Id: <199510270212.WAA06253@crh.cl.msu.edu> Subject: Re: Important 951020-SNAP bugs To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 26 Oct 1995 22:12:19 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <5062.814759836@time.cdrom.com> from "Jordan K. Hubbard" at Oct 26, 95 07:10:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 311 Sender: owner-hackers@freebsd.org Precedence: bulk > >custom > > Uhhh.. It's details of just what you selected in the above that I'm > most lacking! :-) Hmm I listed everything I selected. Custom meaning custom install... -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Thu Oct 26 19:15:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA13906 for hackers-outgoing; Thu, 26 Oct 1995 19:15:09 -0700 Received: from ccslinux.dlsu.edu.ph (root@linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA13815 for ; Thu, 26 Oct 1995 19:13:21 -0700 Received: by ccslinux.dlsu.edu.ph (Linux Smail3.1.28.1 #13) Sender: owner-hackers@FreeBSD.org Precedence: bulk id m0t8e6r-000A5UC; Fri, 27 Oct 95 10:01 GMT+0800 Date: Fri, 27 Oct 1995 10:01:29 +48000 From: Gavin Lim Subject: Re: your mail To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org In-Reply-To: <27312.814627027@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Oct 1995, Jordan K. Hubbard wrote: > > In order to transfer a process, we have to save the process state, > > probably save it to a file, and transfer this file to the destination > > computer, where it would be deserialized and converted back to data > > structures. When this is done, the process can resume execution on the > > destination computer. > > Ah, my favorite axe to grind! :-) > > [ everyone else covers their eyes: "Oh no! Not this again!" :) ] Sorry guys, who else could we turn to? > > Yes, you've stumbled onto one of the "hard problems" that a lot of > UNIX vendors have simply punted on after examining it. It's not a > trivial one and solving it will take a fairly fundamental re-think > about how a process' "relationship" with the host computer is handled. > > The biggest bugaboo is the file table. Assuming that saving the > process text, data and stack information is a problem you've solved > (which would either require that we stop paging directly out of > executables or that the relationship between process and executable > became rather more abstract) you've still got to worry about all the > files it has open and its controlling TTY. What happens when the > image is reactivated on the other host? Do its file I/O requests to > any now non-local files go back to the original host, do you assume a > homogenous AFS-like file system for which all files have universal > IDs, or what? The Sprite project's efforts to solve this problem > ended up producing a system that didn't look much like UNIX anymore! We've made several assumptions regarding the processes that would be migratable. 1. The processes will not have any files explicitly opened. 2. The processes do not use any means of IPC except through signals. 3. The processes are background processes and are not associated with any controlling terminal. (although we figure that we could have a simple rprintf() call to make a printf() RPC call on the source host.) 4. We assume a homogeneous system of 486 PCs with FreeBSD 2.0.5 on them. To use the process migration facility, we would be adding a system call through a LKM. This system call looks like this. int migrate(pid, destination_host); where pid is the ID of the process to be migrated, and destination host is the address of the destination processor. We figure that we are to make variations of the following calls: 1. fork() 2. wait() 3. kill() 4. getpid() 5. getppid() Only processes which use these variations are migratable. We are to make the process migration facility without modifying FreeBSD. We already have an idea how to do it. It has been done before, and was implemented on 4.2BSD. They did it without any rearchitecturing. Maybe these would make things clearer and easier. We already have a general design, but we would have to know the details of FreeBSD to implement it. That's why we're turning to you guys. ============================================================================== Gavin Lim Gavin@linux1.dlsu.edu.ph ============================================================================== From owner-freebsd-hackers Thu Oct 26 19:19:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA14043 for hackers-outgoing; Thu, 26 Oct 1995 19:19:45 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA14036 for ; Thu, 26 Oct 1995 19:19:40 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id TAA07651; Thu, 26 Oct 1995 19:18:55 -0700 To: Charles Henrich cc: freebsd-hackers@freebsd.org Subject: Re: Important 951020-SNAP bugs In-reply-to: Your message of "Thu, 26 Oct 1995 22:12:19 EDT." <199510270212.WAA06253@crh.cl.msu.edu> Date: Thu, 26 Oct 1995 19:18:55 -0700 Message-ID: <7649.814760335@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > >custom > > > > Uhhh.. It's details of just what you selected in the above that I'm > > most lacking! :-) > > Hmm I listed everything I selected. Custom meaning custom install... No no, I need the *distributions* you selected. The other information was actually of no use for debugging this. Jordan From owner-freebsd-hackers Thu Oct 26 19:37:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA15074 for hackers-outgoing; Thu, 26 Oct 1995 19:37:49 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA15065 for ; Thu, 26 Oct 1995 19:37:41 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id UAA02757; Thu, 26 Oct 1995 20:39:37 -0600 Date: Thu, 26 Oct 1995 20:39:37 -0600 From: Nate Williams Message-Id: <199510270239.UAA02757@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: Of possible interest.. In-Reply-To: <199510270039.RAA26084@time.cdrom.com> References: <199510270039.RAA26084@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > This software was, BTW, apparently developed under FreeBSD! > The authors have also indicated that they will be making this > software available under special terms (I believe "free") to > non-profit organizations. If you look around, it looks like it's not quite 'free'. It's $1, which I'll be happy to donate if the product turns out. :) > It looks very interesting! No kidding. I'm going to be contacting the authors with some questions and comments I have on their software. Thanks for the pointer. Nate From owner-freebsd-hackers Thu Oct 26 19:58:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA16839 for hackers-outgoing; Thu, 26 Oct 1995 19:58:17 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA16814 for ; Thu, 26 Oct 1995 19:58:09 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA12415; Fri, 27 Oct 1995 12:16:17 +0930 From: Michael Smith Message-Id: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: terry@lambert.org (Terry Lambert) Date: Fri, 27 Oct 1995 12:16:16 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG In-Reply-To: <199510261817.LAA21413@phaeton.artisoft.com> from "Terry Lambert" at Oct 26, 95 11:17:03 am Content-Type: text Content-Length: 2273 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert stands accused of saying: > Define "work". 8-). If I have a disk that claims to be 2000/10/17, and I rewrite it to 1000/20/17, will the BIOS make the right calculations. It would appear not 8( Here are some scribbles wrt. what I'm trying to work out... Bootmanager (MBR) looks up first sector of FreeBSD slice. Have to assume (for now) that it knows how to reach beyond the 1024 cyl. mark. Stage 0 bootstrap (first sector of FreeBSD slice) reads Stage 1 bootstrap from next N sectors of FreeBSD slice. Uses same technique as the MBR code to reach beyond 1024 cyls. Stage 1 boostrap (lives in first track(s) of FreeBSD slice) (code that currently gives the Boot: prompt) should search all FreeBSD slices and partitions looking for an 'a' filesystem containing a file called 'boot2' (or whatever - it's the stage 2 bootstrap code). This should be read in (version checks? checksums? fallbacks?) and called. (Still in real mode) Stage 2 boostrap runs in real mode under the BIOS. It should provide facilities to select the root filesystem and kernel. It should be able to read the device configuration out of the kernel, and thus inherit the functionality of userconfig(). It should perform MBR fixup to guarantee that the absolute offset field in the MBR matches the c/h/s values for the slice under the BIOS geometry. It should also be buildable as a DOS program, to allow it to work with Ontrack's Disk Mangler. The ability to provide the correct major/minor numbers to the kernel (automatic detection of the wd/hd/sd stuff in the current idiom) would follow as a matter of course. ... Now, I'm sure that the purists and the serial console people are screaming here, so there's a need to continue to support the current scheme as well. Input and, naturally, time are required. Alternatively, if someone wants to pick this up and play with it, please do! -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Thu Oct 26 20:14:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA18343 for hackers-outgoing; Thu, 26 Oct 1995 20:14:15 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA18331 for ; Thu, 26 Oct 1995 20:14:01 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id VAA02829; Thu, 26 Oct 1995 21:16:18 -0600 Date: Thu, 26 Oct 1995 21:16:18 -0600 From: Nate Williams Message-Id: <199510270316.VAA02829@rocky.sri.MT.net> To: hackers@FreeBSD.org Subject: User-mode PPP, -auto, and -direct Sender: owner-hackers@FreeBSD.org Precedence: bulk Unfortunately, there is no English documentation on the 'dedicated' options in ijpp. However, after viewing the source it appears that 'dedicated' == using a dedicated slip line, which is a good thing. However, it also assumes that the dedicated line is not a modem line, but a dedicated serial line. My line is dedicated, it's just that I have to actually make a phone call and login to get it started (and re-started in case of a bad connection). Aha, what I need is the 'auto' option. However, this option has one feature that I'd rather do away with. Even if I set the timeout value to zero it: 1) Will only start the connection if there is data to send. 2) Will not re-start the connection if it falls down and there is no data to send. This may not seem like a problem for most folks, but for me much of the time I'm not initiating the sending of data, but my host is. This means that I want the line to stay up no matter what, and if the line goes down I want it to re-dial ASAP. I've been looking through the code, and I've noticed the variable 'VarOpenMode', which can have two states, 'active' or 'passive'. Although I've set both of these hoping they had something to do with the program 'passively' initiating the connection, or 'actively' initiating the connection, but unfortunately not. Before I go off and hack the code (actually, I'll still probably do that just to have fun *grin*), does anyone know if it's possible to setup PPP to be a dedicated auto-dialing program? Also, what do the openmode 'passive' and 'active' flags stand for? Thanks! Nate From owner-freebsd-hackers Thu Oct 26 20:51:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA21974 for hackers-outgoing; Thu, 26 Oct 1995 20:51:52 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA21965 for ; Thu, 26 Oct 1995 20:51:49 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id UAA26076; Thu, 26 Oct 1995 20:51:21 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id UAA04313; Thu, 26 Oct 1995 20:48:57 -0700 Message-Id: <199510270348.UAA04313@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: Nate Williams cc: Brian Tao , FREEBSD-HACKERS-L , Larry McVoy Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Thu, 26 Oct 1995 10:39:31 MDT." <199510261639.KAA01143@rocky.sri.MT.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 1995 20:48:56 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org Precedence: bulk > > I think we should get the biggest, baddest FreeBSD machines around > > and submit lmbench results for them... Russell Carter, you there? :) Sorry folks, my ISP is downgrading from FreeBSD Pentiums to SGI multiprocessor boxes (no offense Larry ;-), so guess what, I've been basically hosed for the last three days. But of course, I'll run lmbench on my systems, currently 1 P54C-100-PB256K-32MB FBSD 2.1 and 1 P54CS-133-PB512K-32MB-FBSD-current. (Another P54-C100 WINDOZE-NT box is the accounting system, can't touch it...) Where's this problem code at? I'll have a crack at it. The previous lmbench was very bsd friendly... Russell > > I got a pretty nasty one sitting here that Rod put together for me, but > I can't get the lmbench stuff working. I don't have time to mess around > with it either, so if it doesn't work I'm not going to take the time to > figure it out. Even minimal instructions would be helpful... > > Hmm, I used RCS to checkout the top-level files, and it now requires > something called rccs. This is really standardized. ;( Ahh, I see it > requires that . is in your path. > > Still going. The build blew up when the Makefile attempted to copy > /bin/true, which is /usr/bin/true on BSD systems. In any case, I've got > it working now. I'm running it first to make sure I don't have any > bogus answers, at which point I'll have it sent off to the list. > > > Nate > > > > Subject: New lmbench available > > > > > > P.S. Almost forgot. I stuck the latest on ftp.sgi.com:/pub/lmb.tgz. You > > need gunzip to unpack it and rcs to build it, and perl to see the results. > > If you have a linux box, all of the scripts for making fancy graphs work. > > Cd to lmbench/Results and say "make ps", and then look at the ps files > > in PS/*. > > > > Drafts of the usenix paper are in ftp.sgi.com:/pub/lmbench.ps. Comments > > welcome, remember this is an as of yet unpublished document.... > From owner-freebsd-hackers Thu Oct 26 20:53:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA22122 for hackers-outgoing; Thu, 26 Oct 1995 20:53:03 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA22102 for ; Thu, 26 Oct 1995 20:52:55 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id XAA06584; Thu, 26 Oct 1995 23:52:22 -0400 From: Charles Henrich Message-Id: <199510270352.XAA06584@crh.cl.msu.edu> Subject: Re: Important 951020-SNAP bugs To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 26 Oct 1995 23:52:22 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <7649.814760335@time.cdrom.com> from "Jordan K. Hubbard" at Oct 26, 95 07:18:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 716 Sender: owner-hackers@freebsd.org Precedence: bulk > > Hmm I listed everything I selected. Custom meaning custom install... > > No no, I need the *distributions* you selected. The other information > was actually of no use for debugging this. Must be getting late Jordan :) I listed them: > distributions, custom > bin,des,dict,info,man,proflibs,src > des(des) > src(sys) That is I did a custom dist, and selected bin, des, dict, info, man, proflibs and src. For the des submenu I selected des, src submenu I selected sys. -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Thu Oct 26 21:01:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA22951 for hackers-outgoing; Thu, 26 Oct 1995 21:01:20 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA22937 for ; Thu, 26 Oct 1995 21:01:17 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA12541; Thu, 26 Oct 1995 21:00:32 -0700 To: Charles Henrich cc: freebsd-hackers@freebsd.org Subject: Re: Important 951020-SNAP bugs In-reply-to: Your message of "Thu, 26 Oct 1995 23:52:22 EDT." <199510270352.XAA06584@crh.cl.msu.edu> Date: Thu, 26 Oct 1995 21:00:32 -0700 Message-ID: <12539.814766432@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Must be getting late Jordan :) I listed them: > > > distributions, custom > > bin,des,dict,info,man,proflibs,src > > des(des) > > src(sys) Sorry, I'm more than somewhat distracted at the moment.. :-( I think this is the DES problem that has already been reported on fairly extensively in the -hackers group these last couple of days... Jordan From owner-freebsd-hackers Thu Oct 26 21:07:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA23789 for hackers-outgoing; Thu, 26 Oct 1995 21:07:27 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA23768 for ; Thu, 26 Oct 1995 21:07:22 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id WAA02932; Thu, 26 Oct 1995 22:09:26 -0600 Date: Thu, 26 Oct 1995 22:09:26 -0600 From: Nate Williams Message-Id: <199510270409.WAA02932@rocky.sri.MT.net> To: "Russell L. Carter" Cc: Nate Williams , FREEBSD-HACKERS-L Subject: Re: New lmbench available (fwd) In-Reply-To: <199510270348.UAA04313@geli.clusternet> References: <199510261639.KAA01143@rocky.sri.MT.net> <199510270348.UAA04313@geli.clusternet> Sender: owner-hackers@freebsd.org Precedence: bulk > > > I think we should get the biggest, baddest FreeBSD machines around > > > and submit lmbench results for them... Russell Carter, you there? :) > > Sorry folks, my ISP is downgrading from FreeBSD Pentiums to SGI > multiprocessor boxes (no offense Larry ;-), so guess what, I've been > basically hosed for the last three days. You went from FAST machines to SLOW machines? Why in earth would you do that? > But of course, I'll run lmbench on my systems, currently 1 > P54C-100-PB256K-32MB FBSD 2.1 and 1 > P54CS-133-PB512K-32MB-FBSD-current. (Another P54-C100 WINDOZE-NT box > is the accounting system, can't touch it...) I got it working after some hackery. I didn't want to spend time on it, but once I started hacking on it I couldn't stop. > Where's this problem code at? I'll have a crack at it. > The previous lmbench was very bsd friendly... Yeah, the previous version did things much easier. Oh well, my results are now sent off to Larry. If you want the code, it's where it is mentioned in the email you just sent. Nate From owner-freebsd-hackers Thu Oct 26 21:35:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26964 for hackers-outgoing; Thu, 26 Oct 1995 21:35:52 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26955 for ; Thu, 26 Oct 1995 21:35:49 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA16300; Thu, 26 Oct 1995 21:34:54 -0700 To: Nate Williams cc: "Russell L. Carter" , FREEBSD-HACKERS-L Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Thu, 26 Oct 1995 22:09:26 MDT." <199510270409.WAA02932@rocky.sri.MT.net> Date: Thu, 26 Oct 1995 21:34:54 -0700 Message-ID: <16298.814768494@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > Sorry folks, my ISP is downgrading from FreeBSD Pentiums to SGI > > multiprocessor boxes (no offense Larry ;-), so guess what, I've been > > basically hosed for the last three days. > > You went from FAST machines to SLOW machines? Why in earth would you do > that? Actually, they're not the only ones. BEST did the same thing and apparently the SGI is working fairly well for them.. But hey, let's compare apples with apples here.. The SGI machines are multiprocessor R4000 boxes costing tens of thousands of dollars, and a fully loaded P5 system will run you $5K or so.. The big problem all ISPs are having is that this stuff just doesn't scale very well. If you could just drop another P5 into the soup and "cluster" it transparently then we'd be looking at a whole 'nother ballgame, but.. This kind of forces the really big ISPs into doing exactly what Russell's ISP has done.. :-( Jordan From owner-freebsd-hackers Thu Oct 26 22:33:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00231 for hackers-outgoing; Thu, 26 Oct 1995 22:33:55 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00225 for ; Thu, 26 Oct 1995 22:33:51 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id WAA05366; Thu, 26 Oct 1995 22:33:47 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id WAA05178; Thu, 26 Oct 1995 22:31:24 -0700 Message-Id: <199510270531.WAA05178@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Thu, 26 Oct 1995 21:34:54 PDT." <16298.814768494@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 1995 22:31:23 -0700 From: "Russell L. Carter" Sender: owner-hackers@freebsd.org Precedence: bulk > > > Sorry folks, my ISP is downgrading from FreeBSD Pentiums to SGI > > > multiprocessor boxes (no offense Larry ;-), so guess what, I've been > > > basically hosed for the last three days. > > > > You went from FAST machines to SLOW machines? Why in earth would you do > > that? > > Actually, they're not the only ones. BEST did the same thing and > apparently the SGI is working fairly well for them.. But hey, let's > compare apples with apples here.. The SGI machines are multiprocessor > R4000 boxes costing tens of thousands of dollars, and a fully loaded > P5 system will run you $5K or so.. ahem. cough. "BEST" is my ISP... and there is more fun to come, seems we have had a (and I paraphrase here) "sophisticated and persistant" attack that has killed the SGIs in many interesting ways. All through this the lonely little P5-90 box with the NCR controller running a July kernel is just chugging along, so web service has been unaffected, as far as I can tell. > > The big problem all ISPs are having is that this stuff just doesn't > scale very well. If you could just drop another P5 into the soup and > "cluster" it transparently then we'd be looking at a whole 'nother > ballgame, but.. This kind of forces the really big ISPs into doing > exactly what Russell's ISP has done.. :-( So here is a market opportunity: how do you scale a bunch of httpd servers working in concert (maybe like timed?) so that when one goes down, the remainders elect a master and life goes on? Cheers, Russell > > Jordan > From owner-freebsd-hackers Thu Oct 26 22:48:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00655 for hackers-outgoing; Thu, 26 Oct 1995 22:48:11 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00650 for ; Thu, 26 Oct 1995 22:48:08 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA11844 for ; Thu, 26 Oct 1995 22:47:57 -0700 Message-Id: <199510270547.WAA11844@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: freebsd-hackers@freebsd.org Subject: Xess -- Linux Spreadsheet for FreeBSD :) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 1995 22:47:56 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk This is a commercial spreadsheet for Linux which appears to work in FreeBSD with the Linux emulator :) At any rate, a cursory test of the spreadsheet proves that it works in FreeBSD. So go and check it out and if you happen to buy the spreadsheet from these guys please do mention that is for FreeBSD . You see there is such a thing as "bean counters". http://www.ais.com Have a ball, Amancio From owner-freebsd-hackers Thu Oct 26 22:52:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00792 for hackers-outgoing; Thu, 26 Oct 1995 22:52:20 -0700 Received: from tsunami.jurai.net (root@tsunami.jurai.net [205.218.122.50]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00787 for ; Thu, 26 Oct 1995 22:52:18 -0700 Received: (from winter@localhost) by tsunami.jurai.net (8.6.12/8.6.12) id AAA13835; Fri, 27 Oct 1995 00:52:53 -0500 Date: Fri, 27 Oct 1995 00:52:52 -0500 (CDT) From: "Matthew N. Dodd" X-Sender: winter@tsunami To: FREEBSD-HACKERS-L Subject: Re: New lmbench available (fwd) In-Reply-To: <16298.814768494@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Thu, 26 Oct 1995, Jordan K. Hubbard wrote: > The big problem all ISPs are having is that this stuff just doesn't > scale very well. If you could just drop another P5 into the soup and > "cluster" it transparently then we'd be looking at a whole 'nother > ballgame, but.. This kind of forces the really big ISPs into doing > exactly what Russell's ISP has done.. :-( If we had more shell users SGIs might be an option, but I don't think I'm ready to get rid of my FreeBSD machines yet... (If we had enough shell users to load down the P90 and kept the same ratio of shell/PPP-SLIP then we would have about 3000-4000 users...) Have a good one. | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-hackers Thu Oct 26 22:56:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00904 for hackers-outgoing; Thu, 26 Oct 1995 22:56:09 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00899 for ; Thu, 26 Oct 1995 22:56:05 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA11913; Thu, 26 Oct 1995 22:55:41 -0700 Message-Id: <199510270555.WAA11913@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Russell L. Carter" cc: "Jordan K. Hubbard" , hackers@freebsd.org Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Thu, 26 Oct 1995 22:31:23 PDT." <199510270531.WAA05178@geli.clusternet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 1995 22:55:40 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> "Russell L. Carter" said: > > > > Sorry folks, my ISP is downgrading from FreeBSD Pentiums to SGI > > > > multiprocessor boxes (no offense Larry ;-), so guess what, I've been > > > > basically hosed for the last three days. > > > > > > You went from FAST machines to SLOW machines? Why in earth would you do > > > that? > > > > Actually, they're not the only ones. BEST did the same thing and > > apparently the SGI is working fairly well for them.. But hey, let's > > compare apples with apples here.. The SGI machines are multiprocessor > > R4000 boxes costing tens of thousands of dollars, and a fully loaded > > P5 system will run you $5K or so.. > > > ahem. cough. "BEST" is my ISP... and there is more fun to come, > seems we have had a (and I paraphrase here) "sophisticated and persistant" > attack that has killed the SGIs in many interesting ways. All through > this the lonely little P5-90 box with the NCR controller running a > July kernel is just chugging along, so web service has been unaffected, > as far as I can tell. You of course are joking when saying that Best is using an ncr controllers. Cheers, Amancio From owner-freebsd-hackers Thu Oct 26 22:58:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00993 for hackers-outgoing; Thu, 26 Oct 1995 22:58:08 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00984 for ; Thu, 26 Oct 1995 22:58:05 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id WAA13848; Thu, 26 Oct 1995 22:57:15 -0700 To: "Amancio Hasty Jr." cc: "Russell L. Carter" , hackers@freebsd.org Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Thu, 26 Oct 1995 22:55:40 PDT." <199510270555.WAA11913@rah.star-gate.com> Date: Thu, 26 Oct 1995 22:57:15 -0700 Message-ID: <13845.814773435@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > You of course are joking when saying that Best is using an ncr controllers. Why? They work just fine in a number of situations.. Jordan From owner-freebsd-hackers Thu Oct 26 23:01:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA01107 for hackers-outgoing; Thu, 26 Oct 1995 23:01:30 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA01102 for ; Thu, 26 Oct 1995 23:01:28 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA14491 for ; Thu, 26 Oct 1995 23:00:49 -0700 To: hackers@freefall.FreeBSD.org Subject: Tonite's snap... Date: Thu, 26 Oct 1995 23:00:49 -0700 Message-ID: <14486.814773649@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk Is taking longer to build than I thought.. It'd going to be tomorrow morning for this one, I'm afraid. I'll also be releasing another atapi.flp for IDE CDROM testing. Jordan From owner-freebsd-hackers Thu Oct 26 23:02:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA01168 for hackers-outgoing; Thu, 26 Oct 1995 23:02:34 -0700 Received: from nike.efn.org (gurney_j@haus.efn.org [198.68.17.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA01163 for ; Thu, 26 Oct 1995 23:02:27 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id WAA11368; Thu, 26 Oct 1995 22:59:29 -0700 Date: Thu, 26 Oct 1995 22:59:29 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Nate Williams cc: hackers@FreeBSD.ORG Subject: Re: User-mode PPP, -auto, and -direct In-Reply-To: <199510270316.VAA02829@rocky.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Thu, 26 Oct 1995, Nate Williams wrote: [...] > to be a dedicated auto-dialing program? Also, what do the openmode > 'passive' and 'active' flags stand for? I'm not sure if this is correct... but on pppd in active mode it would send out lcp packets (I think they're the ones) to tell the other end that it is there and ready to talk... in passive mode it just waits for them... hope this is right... TTYL.. John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Thu Oct 26 23:15:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA01609 for hackers-outgoing; Thu, 26 Oct 1995 23:15:07 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA01603 for ; Thu, 26 Oct 1995 23:15:01 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id AAA03235; Fri, 27 Oct 1995 00:17:15 -0600 Date: Fri, 27 Oct 1995 00:17:15 -0600 From: Nate Williams Message-Id: <199510270617.AAA03235@rocky.sri.MT.net> To: John-Mark Gurney Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: User-mode PPP, -auto, and -direct In-Reply-To: References: <199510270316.VAA02829@rocky.sri.MT.net> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > to be a dedicated auto-dialing program? Also, what do the openmode > > 'passive' and 'active' flags stand for? > > I'm not sure if this is correct... but on pppd in active mode it would > send out lcp packets (I think they're the ones) to tell the other end that > it is there and ready to talk... in passive mode it just waits for > them... hope this is right... TTYL.. Yep, thanks for answering my question. Nate From owner-freebsd-hackers Thu Oct 26 23:40:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA02311 for hackers-outgoing; Thu, 26 Oct 1995 23:40:42 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02306 for ; Thu, 26 Oct 1995 23:40:37 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id AAA03303; Fri, 27 Oct 1995 00:42:57 -0600 Date: Fri, 27 Oct 1995 00:42:57 -0600 From: Nate Williams Message-Id: <199510270642.AAA03303@rocky.sri.MT.net> To: Nate Williams Cc: hackers@FreeBSD.org Subject: Re: User-mode PPP, -auto, and -direct In-Reply-To: <199510270316.VAA02829@rocky.sri.MT.net> References: <199510270316.VAA02829@rocky.sri.MT.net> Sender: owner-hackers@FreeBSD.org Precedence: bulk [ Having PPP auto-dial the connection no matter if it's needed or not ] OK. The PPP code is quite readable, so I was able to get it to do what I wanted in 5 lines of actual code. However, being a good programmer, I also updated the documentation and changed some of the error messages to reflect the new option so the diffs come out to be 5K as a context diff. If anyone is interested in the code I can send it to them. I'm passing it by Atsushi first before I commit it, but it's *really* short so let me know if you want it. With the addition of this and the use of ipfw, FreeBSD now has all of the features of MorningStar PPP which we paid $700 for, plus we have the source and a great support staff which answer their email pretty quickly. *grin* Kudos! Nate From owner-freebsd-hackers Thu Oct 26 23:42:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA02423 for hackers-outgoing; Thu, 26 Oct 1995 23:42:50 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02418 for ; Thu, 26 Oct 1995 23:42:48 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id XAA01065; Thu, 26 Oct 1995 23:42:32 -0700 From: Julian Elischer Message-Id: <199510270642.XAA01065@ref.tfs.com> Subject: Re: Of possible interest.. To: nate@rocky.sri.MT.net (Nate Williams) Date: Thu, 26 Oct 1995 23:42:31 -0700 (PDT) Cc: jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199510270239.UAA02757@rocky.sri.MT.net> from "Nate Williams" at Oct 26, 95 08:39:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 634 Sender: owner-hackers@freebsd.org Precedence: bulk > put the limited version on the CD.. :) how does it compare with rcvs? > > This software was, BTW, apparently developed under FreeBSD! > > > The authors have also indicated that they will be making this > > software available under special terms (I believe "free") to > > non-profit organizations. > > If you look around, it looks like it's not quite 'free'. It's $1, which > I'll be happy to donate if the product turns out. :) > > > It looks very interesting! > > No kidding. I'm going to be contacting the authors with some questions > and comments I have on their software. > > Thanks for the pointer. > > > Nate > From owner-freebsd-hackers Thu Oct 26 23:44:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA02515 for hackers-outgoing; Thu, 26 Oct 1995 23:44:02 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02510 for ; Thu, 26 Oct 1995 23:44:00 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id XAA01050; Thu, 26 Oct 1995 23:41:37 -0700 From: Julian Elischer Message-Id: <199510270641.XAA01050@ref.tfs.com> Subject: Re: boot disk.... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 26 Oct 1995 23:41:37 -0700 (PDT) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2488 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Terry Lambert stands accused of saying: > > Define "work". 8-). > > If I have a disk that claims to be 2000/10/17, and I rewrite it to > 1000/20/17, will the BIOS make the right calculations. It would appear not 8( > > Here are some scribbles wrt. what I'm trying to work out... > > Bootmanager (MBR) looks up first sector of FreeBSD slice. > Have to assume (for now) that it knows how to reach beyond the 1024 cyl. > mark. > > Stage 0 bootstrap (first sector of FreeBSD slice) reads Stage 1 bootstrap > from next N sectors of FreeBSD slice. Uses same technique as the MBR code > to reach beyond 1024 cyls. > > Stage 1 boostrap (lives in first track(s) of FreeBSD slice) (code that > currently gives the Boot: prompt) should search all FreeBSD slices > and partitions looking for an 'a' filesystem containing a file called > 'boot2' (or whatever - it's the stage 2 bootstrap code). > This should be read in (version checks? checksums? fallbacks?) and called. > (Still in real mode) > > Stage 2 boostrap runs in real mode under the BIOS. It should provide > facilities to select the root filesystem and kernel. It should be able > to read the device configuration out of the kernel, and thus inherit > the functionality of userconfig(). It should perform MBR fixup to > guarantee that the absolute offset field in the MBR matches the c/h/s > values for the slice under the BIOS geometry. It should also be buildable > as a DOS program, to allow it to work with Ontrack's Disk Mangler. The > ability to provide the correct major/minor numbers to the kernel > (automatic detection of the wd/hd/sd stuff in the current idiom) would > follow as a matter of course. > major/minor numbers etc. will GO AWAY over the new year The only valid way of specifying a device will be BY NAME this goes for ALL instances EVERYWHERE. Internal to the kernel or External to it. the more ambitious aspect is: dev_t will become a (vnode_t *) it will hold a reference to the vnode you should never fill out a dev_t without incrementing the reference count on the vnode.. (otherwise how can you be sure the device isn't going to go away?) I'm planning on spending the entire of My summer vacation in Australia doing this. (4 weeks minus 4 hours a day swimming etc.) a 'translation scheme' in the startup code will initially translate a code number (e.g. dev_t) to a name. (along with AF_INET being redefined as "inet" not 2.. (how else can you add protcols dynamically?) julian From owner-freebsd-hackers Thu Oct 26 23:56:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03055 for hackers-outgoing; Thu, 26 Oct 1995 23:56:09 -0700 Received: from escape.com (escape.com [198.6.71.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03049 for ; Thu, 26 Oct 1995 23:56:06 -0700 Received: (from dima@localhost) by escape.com (8.6.12/8.6.9) id CAA10347; Fri, 27 Oct 1995 02:56:43 -0400 Date: Fri, 27 Oct 1995 02:56:40 -0400 (EDT) From: "Dima (ELO)" To: hackers@freebsd.org Subject: Netscape Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hello, I've got some problems with Netscape when I start it, what I am getting is Warning: ... found while parsing 'c osfPageDown:PageDownOrRight(1)' Warning: translation table syntax error: Unknown keysym name: osfPageDown Warning: ... found while parsing 'osfPageDown:PageDownOrRight(0)' Warning: translation table syntax error: Unknown keysym name: osfHelp Warning: ... found while parsing 'osfHelp:PrimitiveHelp()' Warning: translation table syntax error: Unknown keysym name: osfUp and my keyboard doesnt work. what exactly should I do? Dima. From owner-freebsd-hackers Fri Oct 27 00:03:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA03305 for hackers-outgoing; Fri, 27 Oct 1995 00:03:44 -0700 Received: from escape.com (escape.com [198.6.71.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA03300 ; Fri, 27 Oct 1995 00:03:40 -0700 Received: (from dima@localhost) by escape.com (8.6.12/8.6.9) id DAA13722; Fri, 27 Oct 1995 03:03:47 -0400 Date: Fri, 27 Oct 1995 03:03:46 -0400 (EDT) From: "Dima (ELO)" To: hardware@freebsd.org cc: hackers@freebsd.org Subject: Logitech Cordless Mouse Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="DAA12147.814777237/escape.com" Content-ID: Sender: owner-hackers@freebsd.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --DAA12147.814777237/escape.com Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: --DAA12147.814777237/escape.com Content-Type: MESSAGE/RFC822 Content-ID: Return-Path: dima Received: (from dima@localhost) by escape.com (8.6.12/8.6.9) id DAA12139; Fri, 27 Oct 1995 03:00:34 -0400 Date: Fri, 27 Oct 1995 03:00:33 -0400 (EDT) From: "Dima (ELO)" To: support@freebsd.org Subject: Logitech Cordless Mouse Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I have Logitech Cordless mouse and when I start X11R6 sometimes it's stocked and sometimes it's working. But when I do reboot when it doesn't working, after reboot it works fine. And if I do another reboot it stock again. so it works every other time I reboot my system. Sounds strange but it's true :) Has anyone ever had similar problems? Dima. --DAA12147.814777237/escape.com-- From owner-freebsd-hackers Fri Oct 27 01:10:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA06051 for hackers-outgoing; Fri, 27 Oct 1995 01:10:27 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA06038 for ; Fri, 27 Oct 1995 01:10:16 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id RAA13125 for hackers@freebsd.org; Fri, 27 Oct 1995 17:38:15 +0930 From: Michael Smith Message-Id: <199510270808.RAA13125@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: hackers@freebsd.org Date: Fri, 27 Oct 1995 17:38:15 +0930 (CST) In-Reply-To: <199510270641.XAA01050@ref.tfs.com> from "Julian Elischer" at Oct 26, 95 11:41:37 pm Content-Type: text Content-Length: 715 Sender: owner-hackers@freebsd.org Precedence: bulk Julian Elischer stands accused of saying: > major/minor numbers etc. will GO AWAY over the new year > The only valid way of specifying a device will be BY NAME > this goes for ALL instances EVERYWHERE. > Internal to the kernel or External to it. Yes! Yaya! Can I say "kernel environment variables"? This is a Good Thing 8) > julian -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[ From owner-freebsd-hackers Fri Oct 27 01:15:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA06369 for hackers-outgoing; Fri, 27 Oct 1995 01:15:40 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA06354 ; Fri, 27 Oct 1995 01:15:32 -0700 Message-Id: <199510270815.BAA06354@freefall.freebsd.org> Subject: Re: User-mode PPP, -auto, and -direct To: nate@rocky.sri.MT.net (Nate Williams) Date: Fri, 27 Oct 1995 01:15:31 -0700 (PDT) Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.org In-Reply-To: <199510270642.AAA03303@rocky.sri.MT.net> from "Nate Williams" at Oct 27, 95 00:42:57 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1328 Sender: owner-hackers@FreeBSD.org Precedence: bulk In reply to Nate Williams who wrote: > > [ Having PPP auto-dial the connection no matter if it's needed or not ] > > OK. The PPP code is quite readable, so I was able to get it to do what > I wanted in 5 lines of actual code. However, being a good programmer, I > also updated the documentation and changed some of the error messages to > reflect the new option so the diffs come out to be 5K as a context diff. > If anyone is interested in the code I can send it to them. I'm passing > it by Atsushi first before I commit it, but it's *really* short so let > me know if you want it. We want it ! (or at least I do :) > With the addition of this and the use of ipfw, FreeBSD now has all of > the features of MorningStar PPP which we paid $700 for, plus we have the > source and a great support staff which answer their email pretty > quickly. *grin* well, I've played alot with PPP the last couple of days to support my connection to my new ISP (cybercity.dk) and after reading through the sources as Nate did to figure out how it works, it has served my needs perfectly. This new option will come in very handy... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Fri Oct 27 03:22:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA11286 for hackers-outgoing; Fri, 27 Oct 1995 03:22:21 -0700 Received: from hutcs.cs.hut.fi (root@hutcs.cs.hut.fi [130.233.192.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA11274 for ; Fri, 27 Oct 1995 03:22:17 -0700 Received: from shadows.cs.hut.fi by hutcs.cs.hut.fi with SMTP id AA10377 (5.65c8/HUTCS-S 1.4 for ); Fri, 27 Oct 1995 12:22:12 +0200 Received: (hsu@localhost) by shadows.cs.hut.fi (8.6.10/8.6.10) id MAA06076; Fri, 27 Oct 1995 12:22:23 +0200 Date: Fri, 27 Oct 1995 12:22:23 +0200 Message-Id: <199510271022.MAA06076@shadows.cs.hut.fi> From: Heikki Suonsivu To: "Jordan K. Hubbard" Cc: freebsd-hackers@freefall.FreeBSD.org In-Reply-To: "Jordan K. Hubbard"'s message of 27 Oct 1995 02:54:22 +0200 Subject: Of possible interest.. Sender: owner-hackers@FreeBSD.org Precedence: bulk It looks very interesting! http://www.p3.com/p3/p3bullet.html Also it looks very expensive, $10000. But I guess it is worth that for someone... I'll stick with CVS :-) -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN From owner-freebsd-hackers Fri Oct 27 03:53:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA12657 for hackers-outgoing; Fri, 27 Oct 1995 03:53:31 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA12652 for ; Fri, 27 Oct 1995 03:53:30 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id DAA01662; Fri, 27 Oct 1995 03:53:09 -0700 From: Julian Elischer Message-Id: <199510271053.DAA01662@ref.tfs.com> Subject: Re: Of possible interest.. To: hsu@cs.hut.fi (Heikki Suonsivu) Date: Fri, 27 Oct 1995 03:53:09 -0700 (PDT) Cc: jkh@time.cdrom.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199510271022.MAA06076@shadows.cs.hut.fi> from "Heikki Suonsivu" at Oct 27, 95 12:22:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 649 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > It looks very interesting! > > http://www.p3.com/p3/p3bullet.html lat year TFS payed 200,000 for a CM system (then threw it away.. I would have rather used CVS, and they had a perfectly usable (if a bit slow) system already..) that's 10,000 for 40 users.. that's only 250 per user..ONCE a large company will budget 20,000 PER EMPLOYEE over a 3 year period in such things > > Also it looks very expensive, $10000. But I guess it is worth that for > someone... I'll stick with CVS :-) > > -- > Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, > hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN > From owner-freebsd-hackers Fri Oct 27 06:08:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA17496 for hackers-outgoing; Fri, 27 Oct 1995 06:08:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA17487 ; Fri, 27 Oct 1995 06:08:12 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA13158; Fri, 27 Oct 1995 23:04:39 +1000 Date: Fri, 27 Oct 1995 23:04:39 +1000 From: Bruce Evans Message-Id: <199510271304.XAA13158@godzilla.zeta.org.au> To: hackers@freefall.freebsd.org, hsu@freefall.freebsd.org Subject: Re: cpp question Sender: owner-hackers@FreeBSD.org Precedence: bulk >Well, if you use gcc -E or an ANSI cpp, you can use #name. If you use a 4.4BSD derived system, then you can #include (perhaps indirectly) and use __STRING(), which is supposed to hide the unportability of #name. Don't use it in portable code. __STRING() and __P(() are less portable than #name or prototypes. For portability, you should define your own macros, e.g., for ANSI: #define P__(x) x #define STR(x) STR1(x) #define STR1(x) #x STR(x) should normally be used instead of #x even if there are no portablility considerations, since STR1(x) usually does the wrong thing if x is a macro (x doesn't get expanded). The nested macro trick for STR(x) doesn't work in traditional mode and isn't used in . Bruce From owner-freebsd-hackers Fri Oct 27 06:30:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA18554 for hackers-outgoing; Fri, 27 Oct 1995 06:30:41 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA18549 for ; Fri, 27 Oct 1995 06:30:37 -0700 Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA13472; Fri, 27 Oct 1995 09:28:52 -0400 Date: Fri, 27 Oct 1995 09:28:52 -0400 (EDT) From: "Ron G. Minnich" To: "Russell L. Carter" cc: Nate Williams , Brian Tao , FREEBSD-HACKERS-L , Larry McVoy Subject: Re: New lmbench available (fwd) In-Reply-To: <199510270348.UAA04313@geli.clusternet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk actually the big surprise for me was walking the results and seeing freebsd outrunning linux in so many areas on the 100 mhz boxes. I knew that it was marginally faster in places but the margin this time (except for ctx) was surprising. Also the aix ctx results are interesting: kind of shows the advantage of single-address-space operating systems, as opposed to the unix model. It's useful to show freebsd performance at the limit. But it's also useful to show it on a plain vanilla 133 mhz box without $$$ boltons. BTW ttcp on freebsd on 100BT interfaces (SMC) is at about 56 Mhz. These are neptune, i understand triton would be better. ron Ron Minnich |Like a knife through Daddy's heart: rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Fri Oct 27 07:24:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA20845 for hackers-outgoing; Fri, 27 Oct 1995 07:24:05 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA20835 ; Fri, 27 Oct 1995 07:23:51 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA03757; Fri, 27 Oct 1995 08:26:11 -0600 Date: Fri, 27 Oct 1995 08:26:11 -0600 From: Nate Williams Message-Id: <199510271426.IAA03757@rocky.sri.MT.net> To: sos@FreeBSD.org Cc: nate@rocky.sri.MT.net (Nate Williams), hackers@FreeBSD.org Subject: Re: User-mode PPP, -auto, and -direct In-Reply-To: <199510270815.BAA06354@freefall.freebsd.org> References: <199510270642.AAA03303@rocky.sri.MT.net> <199510270815.BAA06354@freefall.freebsd.org> Sender: owner-hackers@FreeBSD.org Precedence: bulk > In reply to Nate Williams who wrote: > > > > [ Having PPP auto-dial the connection no matter if it's needed or not ] > > > > OK. The PPP code is quite readable, so I was able to get it to do what > > I wanted in 5 lines of actual code. However, being a good programmer, I > > also updated the documentation and changed some of the error messages to > > reflect the new option so the diffs come out to be 5K as a context diff. > > If anyone is interested in the code I can send it to them. I'm passing > > it by Atsushi first before I commit it, but it's *really* short so let > > me know if you want it. > > We want it ! (or at least I do :) I've got enough requests for it that I'm posting it to the list. It's short enough that it's smaller than most of Terry's posts anyway. *grin* The new mode is called 'ddial', which stands for either 'dedicated dial' or 'demon dial', whichever you prefer. Instead of using $ ppp -auto remotesite you now do $ ppp -ddial remotesite Nate ----- Index: command.c =================================================================== RCS file: /home/CVS/src/usr.sbin/ppp/command.c,v retrieving revision 1.5.4.2 diff -c -r1.5.4.2 command.c *** command.c 1995/10/06 11:24:32 1.5.4.2 --- command.c 1995/10/27 06:26:51 *************** *** 95,101 **** { char *mes = NULL; ! if (mode & MODE_AUTO) mes = "Working in auto mode."; else if (mode & MODE_DIRECT) mes = "Working in direct mode."; --- 95,103 ---- { char *mes = NULL; ! if (mode & MODE_DDIAL) ! mes = "Working in dedicated dial mode."; ! else if (mode & MODE_AUTO) mes = "Working in auto mode."; else if (mode & MODE_DIRECT) mes = "Working in direct mode."; Index: defs.h =================================================================== RCS file: /home/CVS/src/usr.sbin/ppp/defs.h,v retrieving revision 1.2.4.1 diff -c -r1.2.4.1 defs.h *** defs.h 1995/10/06 11:24:33 1.2.4.1 --- defs.h 1995/10/27 05:46:27 *************** *** 59,64 **** --- 59,65 ---- #define MODE_AUTO 2 /* Auto calling mode */ #define MODE_DIRECT 4 /* Direct connection mode */ #define MODE_DEDICATED 8 /* Dedicated line mode */ + #define MODE_DDIAL 16 /* Dedicated dialing line mode */ #define EX_NORMAL 0 #define EX_START 1 Index: main.c =================================================================== RCS file: /home/CVS/src/usr.sbin/ppp/main.c,v retrieving revision 1.5.4.2 diff -c -r1.5.4.2 main.c *** main.c 1995/10/06 11:24:42 1.5.4.2 --- main.c 1995/10/27 06:29:32 *************** *** 198,204 **** void Usage() { ! fprintf(stderr, "Usage: ppp [-auto | -direct | -dedicated] [system]\n"); exit(EX_START); } --- 198,205 ---- void Usage() { ! fprintf(stderr, ! "Usage: ppp [-auto | -direct | -dedicated | -ddial ] [system]\n"); exit(EX_START); } *************** *** 217,222 **** --- 218,225 ---- mode |= MODE_DIRECT; else if (strcmp(cp, "dedicated") == 0) mode |= MODE_DEDICATED; + else if (strcmp(cp, "ddial") == 0) + mode |= MODE_DDIAL|MODE_AUTO; else Usage(); optc++; *************** *** 289,297 **** printf("Interactive mode\n"); netfd = 0; } else if (mode & MODE_AUTO) { ! printf("Automatic mode\n"); if (dstsystem == NULL) { ! fprintf(stderr, "Destination system must be specified in auto mode.\n"); exit(EX_START); } } --- 292,301 ---- printf("Interactive mode\n"); netfd = 0; } else if (mode & MODE_AUTO) { ! printf("Automatic Dialer mode\n"); if (dstsystem == NULL) { ! fprintf(stderr, ! "Destination system must be specified in auto or ddial mode.\n"); exit(EX_START); } } *************** *** 330,336 **** Cleanup(EX_START); } if ((mode & MODE_AUTO) && DefHisAddress.ipaddr.s_addr == INADDR_ANY) { ! fprintf(stderr, "Must specify dstaddr with auto mode.\n"); Cleanup(EX_START); } } --- 334,340 ---- Cleanup(EX_START); } if ((mode & MODE_AUTO) && DefHisAddress.ipaddr.s_addr == INADDR_ANY) { ! fprintf(stderr, "Must specify dstaddr with auto or ddial mode.\n"); Cleanup(EX_START); } } *************** *** 614,619 **** --- 618,630 ---- if ( modem ) IpStartOutput(); FD_ZERO(&rfds); FD_ZERO(&wfds); FD_ZERO(&efds); + + /* + * If the link is down and we're in DDIAL mode, bring it back + * up. + */ + if (mode & DDIAL && LcpFsm.state <= ST_CLOSED &&) + dial_up = TRUE; /* * If Ip packet for output is enqueued and require dial up, Index: ppp.8 =================================================================== RCS file: /home/CVS/src/usr.sbin/ppp/ppp.8,v retrieving revision 1.8.4.2 diff -c -r1.8.4.2 ppp.8 *** ppp.8 1995/10/06 11:24:45 1.8.4.2 --- ppp.8 1995/10/27 06:11:28 *************** *** 9,15 **** Point to Point Protocol (aka iijppp) .Sh SYNOPSIS .Nm ! .Op Fl auto \*(Ba Fl direct Fl dedicated .Sh DESCRIPTION This is a user process .Em PPP --- 9,15 ---- Point to Point Protocol (aka iijppp) .Sh SYNOPSIS .Nm ! .Op Fl auto \*(Ba Fl direct \*(Ba Fl dedicated \*(Ba Fl ddial .Sh DESCRIPTION This is a user process .Em PPP *************** *** 52,57 **** --- 52,64 ---- link. When this happens, the daemon automatically dials and establishes the connection. + In almost the same manner ddial mode (dedicated dialing or demon dialing) + also automatically dials and establishes the connection. However, it + differs in that it will dial the remote site any time it detects the + link is down, even if there are no packets to be sent. This mode is + useful for full-time connections who worry less about line charges + and more about being connected full time. + .It Supports server-side PPP connections. Can act as server which accepts incoming .Em PPP *************** *** 274,279 **** --- 281,288 ---- To play with demand dialing, you must use the .Fl auto + or + .Fl ddial option. You must also specify the destination label in .Pa /etc/ppp/ppp.conf to use. It should contain the *************** *** 287,292 **** --- 296,303 ---- When .Fl auto + or + .Fl ddial is specified, .Nm runs as a daemon but you can still configure or examine its From owner-freebsd-hackers Fri Oct 27 08:07:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22948 for hackers-outgoing; Fri, 27 Oct 1995 08:07:01 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA22936 ; Fri, 27 Oct 1995 08:06:56 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8qMP-000jBiC; Fri, 27 Oct 95 10:06 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id KAA00739; Fri, 27 Oct 1995 10:06:14 -0500 Message-Id: <199510271506.KAA00739@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Fri, 27 Oct 1995 10:06:13 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <9510271410.AA22857@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 27, 95 10:10:51 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 Precedence: bulk Garret wrote: > < > I do have a question: > > Would a FreeBSD server always respond to a client from the same interface > > on which it received a request - even though its route table has a > > different route to the clients network? > > No. Source address != interface. If the source address is already > set in the outgoing IP packet, ip_output() will not change it even if > the packet goes out an interface which does not have that address on > it. (Otherwise forwarding would not work!) > So, a multi-homed FreeBSD NFS server would behave the same as a multi- homed Sun NFS server and adhere to the route table. That's what I thought, but is contrary to some grumblings I've heard about the way Sun serves NFS. Some people have sworn that the "proper" thing for the server to do is send replies out the same interface that received the request - evidently not caring whether it adhered to the route table or not. The bottom line is that people mounting filesystems from a multi-homed FreeBSD server could potentially run into the same problem I experienced (NFS replies with a different source addr than the request's destination addr), and be forced to use the "noconn" option. So much for my feeling bad about using those damn rogue Suns. ;v) Since, in this situation, the FreeBSD NFS client doesn't behave according to the "Industry standard" (requires a special option to mount), perhaps this issue should be included in the FAQ. Even though it is not an issue that pops up _frequently_, it is a real hair-puller. Since posting my problem, I've had several people write saying they had the same experience, and it took several days until some kind soul pointed out the deprecated noconn option, which is buried in the mount_nfs man page. Hopefully, deprecated doesn't mean it will be removed anytime soon. ;v) Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Fri Oct 27 08:08:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA23089 for hackers-outgoing; Fri, 27 Oct 1995 08:08:29 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA23065 ; Fri, 27 Oct 1995 08:08:21 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id BAA14094; Sat, 28 Oct 1995 01:08:04 +1000 From: michael butler Message-Id: <199510271508.BAA14094@asstdc.scgt.oz.au> Subject: Re: User-mode PPP, -auto, and -direct To: sos@FreeBSD.org Date: Sat, 28 Oct 1995 01:08:03 +1000 (EST) Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.org In-Reply-To: <199510270815.BAA06354@freefall.freebsd.org> from "sos@FreeBSD.org" at Oct 27, 95 01:15:31 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 981 Sender: owner-hackers@FreeBSD.org Precedence: bulk Nate wrote .. > > [ Having PPP auto-dial the connection no matter if it's needed or not ] > > OK. The PPP code is quite readable, so I was able to get it to do what > > I wanted in 5 lines of actual code. [ .. ] .. then Soren wrote .. > We want it ! (or at least I do :) Er .. I was under the impression that a "dial" command in the relevant (host-specific) section of ppp.conf did just this .. did I miss something ? I've given up trying to use user-land PPP, however, as it is very (too) strict about getting either LQR or LCP echos. Modem-based links around here are almost always saturated to the point of losing the occasional echo response (people trying to slurp "full" newsfeeds down it and so on) .. in that event, user-land PPP will happily drop the call and 10 secs later dial back again because it thinks the link went away. The result is simply too many $$$$$$ added to the 'phone bill. I'd appreciate some mechanism of turning it off completely, michael From owner-freebsd-hackers Fri Oct 27 08:25:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA24575 for hackers-outgoing; Fri, 27 Oct 1995 08:25:28 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA24555 for ; Fri, 27 Oct 1995 08:25:21 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id LAA09006; Fri, 27 Oct 1995 11:24:57 -0400 From: Charles Henrich Message-Id: <199510271524.LAA09006@crh.cl.msu.edu> Subject: Re: Important 951020-SNAP bugs To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 27 Oct 1995 11:24:57 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <12539.814766432@time.cdrom.com> from "Jordan K. Hubbard" at Oct 26, 95 09:00:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 611 Sender: owner-hackers@freebsd.org Precedence: bulk > > > distributions, custom > > > bin,des,dict,info,man,proflibs,src > > > des(des) > > > src(sys) > > Sorry, I'm more than somewhat distracted at the moment.. :-( > > I think this is the DES problem that has already been reported on > fairly extensively in the -hackers group these last couple of days... Yes, but I've done installs without DES and get the same effect :( -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Fri Oct 27 08:38:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA25618 for hackers-outgoing; Fri, 27 Oct 1995 08:38:13 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA25603 for ; Fri, 27 Oct 1995 08:38:07 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA03916; Fri, 27 Oct 1995 09:39:56 -0600 Date: Fri, 27 Oct 1995 09:39:56 -0600 From: Nate Williams Message-Id: <199510271539.JAA03916@rocky.sri.MT.net> To: michael butler Cc: hackers@FreeBSD.org Subject: Re: User-mode PPP, -auto, and -direct In-Reply-To: <199510271508.BAA14094@asstdc.scgt.oz.au> References: <199510270815.BAA06354@freefall.freebsd.org> <199510271508.BAA14094@asstdc.scgt.oz.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk michael butler writes: [ User-land PPP ] I wrote about: > [ Having PPP auto-dial the connection no matter if it's needed or not ] > > Er .. I was under the impression that a "dial" command in the relevant > (host-specific) section of ppp.conf did just this .. did I miss something ? Yes, but want it done non-interactively all the time. If the connection goes down, bring it back up irregardless of the status of outgoing packets. > I've given up trying to use user-land PPP, however, as it is very (too) > strict about getting either LQR or LCP echos. Add these lines to your default rules in /etc/ppp/ppp.conf disable lqr deny lqr The man page, although poor at least documents most of these. Nate From owner-freebsd-hackers Fri Oct 27 09:46:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA01090 for hackers-outgoing; Fri, 27 Oct 1995 09:46:57 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA01081 for ; Fri, 27 Oct 1995 09:46:54 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id JAA02822; Fri, 27 Oct 1995 09:46:48 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id JAA00169; Fri, 27 Oct 1995 09:45:52 -0700 Message-Id: <199510271645.JAA00169@corbin.Root.COM> To: mikebo@tellabs.com cc: wollman@lcs.mit.edu (Garrett A. Wollman), hackers@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! In-reply-to: Your message of "Fri, 27 Oct 95 10:06:13 CDT." <199510271506.KAA00739@sunc210.tellabs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 27 Oct 1995 09:45:52 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >Garret wrote: >> <> > I do have a question: >> > Would a FreeBSD server always respond to a client from the same interface >> > on which it received a request - even though its route table has a >> > different route to the clients network? >> >> No. Source address != interface. If the source address is already >> set in the outgoing IP packet, ip_output() will not change it even if >> the packet goes out an interface which does not have that address on >> it. (Otherwise forwarding would not work!) >> >So, a multi-homed FreeBSD NFS server would behave the same as a multi- >homed Sun NFS server and adhere to the route table. That's what I >thought, but is contrary to some grumblings I've heard about the way Sun >serves NFS. Some people have sworn that the "proper" thing for the server >to do is send replies out the same interface that received the request - >evidently not caring whether it adhered to the route table or not. I think you might be confusing this a bit. As was said above, just because the packet goes out an interface because of a prefered route doesn't mean that it will have that interface's address. The problem you've been having is source address related, not specifically a route problem. I don't know what FreeBSD does for UDP NFS, but for TCP NFS I'm quite sure that the address used by the server is constant regardless of the route. If FreeBSD servers reply to NFS UDP packets the same way that the Sun machines do (packets always have the source address of the interface they are going out on), then FreeBSD would be broken, too, IMO. ...but again, I haven't tested this. -DG From owner-freebsd-hackers Fri Oct 27 09:52:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA01595 for hackers-outgoing; Fri, 27 Oct 1995 09:52:15 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA01588 for ; Fri, 27 Oct 1995 09:52:11 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id JAA02832; Fri, 27 Oct 1995 09:52:07 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id JAA00187; Fri, 27 Oct 1995 09:51:10 -0700 Message-Id: <199510271651.JAA00187@corbin.Root.COM> To: "Ron G. Minnich" cc: FREEBSD-HACKERS-L , Larry McVoy Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Fri, 27 Oct 95 09:28:52 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 27 Oct 1995 09:51:09 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >actually the big surprise for me was walking the results and seeing >freebsd outrunning linux in so many areas on the 100 mhz boxes. I knew >that it was marginally faster in places but the margin this time (except >for ctx) was surprising. Also the aix ctx results are interesting: kind of >shows the advantage of single-address-space operating systems, as opposed >to the unix model. > >It's useful to show freebsd performance at the limit. But it's also >useful to show it on a plain vanilla 133 mhz box without $$$ boltons. > >BTW ttcp on freebsd on 100BT interfaces (SMC) is at about 56 Mhz. These >are neptune, i understand triton would be better. Yes, Triton works *much* better. You should be able to get full 100Mbit performance using a pair of 133Mhz Triton-based machines - I can tell you that I get nearly 80Mbits when doing TCP from a 90Mhz Triton machine. The pipeline burst cache also makes a tremendous difference, BTW... -DG From owner-freebsd-hackers Fri Oct 27 10:28:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA06693 for hackers-outgoing; Fri, 27 Oct 1995 10:28:14 -0700 Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA06680 for ; Fri, 27 Oct 1995 10:28:01 -0700 Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.12/8.6.12) id MAA02039; Fri, 27 Oct 1995 12:27:51 -0500 Date: Fri, 27 Oct 1995 12:27:50 -0500 (EST) From: John Fieber To: hackers@freebsd.org Subject: Re: User group meeting in Silicon Valley area. 2nd try.. In-Reply-To: <28687.814644058@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Wed, 25 Oct 1995, Jordan K. Hubbard wrote: > Well, I received all of *two* responses to my call for the first > meeting of the Bay Area FreeBSD Users Group (BAFUG?) which is hardly > enough to actually hold it. I can just see the 3 of us sitting around On a slight tangent, I'm constructing a little section in the FreeBSD WWW pages for user groups. Digging through my saved mail I've found reference to one in Milwaukee (WI) and Washington DC. If there are any others in hiding out there, *let me know!* If you have mailing lists, and/or WWW pages, I'd like to make links to them. -john == jfieber@indiana.edu =========================================== == http://fieber-john.campusview.indiana.edu/~jfieber ============ From owner-freebsd-hackers Fri Oct 27 10:36:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07170 for hackers-outgoing; Fri, 27 Oct 1995 10:36:48 -0700 Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA07141 ; Fri, 27 Oct 1995 10:36:40 -0700 From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0t8shM-000jC3C; Fri, 27 Oct 95 12:36 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id MAA00863; Fri, 27 Oct 1995 12:36:01 -0500 Message-Id: <199510271736.MAA00863@sunc210.tellabs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Fri, 27 Oct 1995 12:36:00 -0500 (CDT) Cc: mikebo (Mike Borowiec), wollman@lcs.mit.edu, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510271645.JAA00169@corbin.Root.COM> from "David Greenman" at Oct 27, 95 09:45:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk David wrote: > >Garret wrote: > ... > >> No. Source address != interface. > ... > I think you might be confusing this a bit. As was said above, just because > the packet goes out an interface because of a prefered route doesn't mean that > it will have that interface's address. ... chop ... Dohhhhh! I see the light... been working with Suns too long. ;v) Can anyone point me at a document that describes the proper, 4.4BSD operation vs. the old, insecure method? I'm assuming this is an RFC or architectural paper? Thanks everyone for your patience. - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-hackers Fri Oct 27 10:38:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07307 for hackers-outgoing; Fri, 27 Oct 1995 10:38:30 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07298 for ; Fri, 27 Oct 1995 10:38:24 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA04408; Fri, 27 Oct 1995 11:40:38 -0600 Date: Fri, 27 Oct 1995 11:40:38 -0600 From: Nate Williams Message-Id: <199510271740.LAA04408@rocky.sri.MT.net> To: hackers@FreeBSD.org CC: "Garrett A. Wollman" Subject: ARP and routing table problems Sender: owner-hackers@FreeBSD.org Precedence: bulk Here's the situation. My ISP happens to be a FreeBSD box sitting at the office. This box is on it's way to becoming our router/terminal server/DNS/firewall box, but it's more than adequate to the task as a nicely loaded 486/66. I've been setting it up this week to accept both SLIP/PPP connections from the different machines we have locally, and of course the best way to do this is with my box at home. So, my box can login as both a SLIP host, and a PPP host. I'm using kernel mode SLIP/PPP for the dialin lines to avoid any extra overhead. I have two problems, but they may be related. First of all, if I make a SLIP connection to the box (which works fine), and then make a PPP connection to the box the routing table is in a manner where it will try to route all the traffic to my box via the now-dead slip connection, even though the interface is marked down. This is no good since I'm validly logged in via the SLIP interface. It's obvious that I'm using the same IP address for both of the interfaces, but this is necessary since my remote box is on the internet full-time and has a set address. This problem isn't so bad since normally I won't be switching protocols on the fly, but it's a pain in the butt and I am hoping that the behavior can be fixed. Next is a more serious problem. As you may have noted, I just finished my mods to make the user-mode PPP do full-time connections irregardless of the outgoing packet situation. So, if the link goes down, the remote end will attempt to re-establish the connection immediately. This behavior seems to work fine for the most part, however it appears that somehow the arp table entry for my box is getting re-imported after it's deleted on my server box. Nomenclature: ------------- remote - Remote machine connecting via PPP server - PPP server machine local - FreeBSD box on the same local network as the PPP server machine sunloc - Sun box on the local network 'remote' calls 'server', which attaches itself to the proper line and does a proxyarp for the new IP address. The arp table entry is propagated to 'local' who then knows to send any data to 'remote' via 'server'. So far so good. However, the link goes down for some reason (like me turning off my modem to make sure the re-dial code works). At this point 'server' deletes the arp table entry for 'remote'. But, 'local' still has the copy of the arp table entry, and it's got data to send to 'remote' (since it was in the middle of a TCP seesion when I killed the session). So, 'local' sends data to 'server' who no longer has any idea how to get to 'remote'. At this point, 'server' makes an entry into it's arp table for 'remote' that looks like this. remote.do.main (10.5.5.5) at (incomplete) Now, 'remote' is in 'demon dialer' mode and by now has gotten the idea that the link went down, so it is now re-dialing 'server' for the connection. Once 'remote' connects to 'server' the PPP process adds another arp entry into the table usint it's ethernet address, so now we have two entries in the table for 'remote'. remote.do.main (10.5.5.5) at (incomplete) remote.do.main (10.5.5.5) at 00:00:00:00:00:00 At this point in time, 'server' won't talk to 'remote' since it appears that it's trying to route the information to the ethernet. The only solution at this point is to do a route flush and delete all entries in the routing table and add them back by hand, which is impossible to do if you happen to be at the remote site. What can I do to avoid this problem? In this case I'm using correct procedure for routing and such. Note, I need to use proxyarp instead of adding routing table entries because one of our boxes a laptop can be on the network or connected remotely via PPP. Since it's ARP table entry can exist on either network hard-coding the routing information is not a workable solution. I don't have these sorts of problems with the Sun boxes and we've been running a similar setup for 8 months, so I suspect this is a FreeBSD specific problem. Nate From owner-freebsd-hackers Fri Oct 27 11:20:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09819 for hackers-outgoing; Fri, 27 Oct 1995 11:20:07 -0700 Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09809 for ; Fri, 27 Oct 1995 11:20:00 -0700 From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id TAA10672 for freebsd-hackers@freebsd.org; Fri, 27 Oct 1995 19:18:40 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 27 Oct 95 19:15:08 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 27 Oct 95 18:15:05 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 27 Oct 95 18:15:05 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:290-951027181505-7501] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: freebsd-hackers@freebsd.org Date: Fri, 27 Oct 95 18:15:05 +0000 Message-Id: <"MAC-951027181449-3B5E*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>BTW ttcp on freebsd on 100BT interfaces (SMC) is at about 56 Mhz. These >>are neptune, i understand triton would be better. > > Yes, Triton works *much* better. You should be able to get full 100Mbit >performance using a pair of 133Mhz Triton-based machines - I can tell you that >I get nearly 80Mbits when doing TCP from a 90Mhz Triton machine. The pipeline >burst cache also makes a tremendous difference, BTW... But not if you are unfortunate enough to have your Triton chipset installed in an Intel Zappa motherboard.... With the SMC card set to 100Mb/sec, so many packets get dropped that the throughput is less than 10Mb/sec. When set to 10Mb/sec mode they work normally. Andrew [whose network is still running at 10Mb/sec :-( ]. From owner-freebsd-hackers Fri Oct 27 11:22:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA10025 for hackers-outgoing; Fri, 27 Oct 1995 11:22:17 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA10015 ; Fri, 27 Oct 1995 11:22:15 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA10810; Fri, 27 Oct 1995 11:21:32 -0700 To: announce@freebsd.org cc: hackers@freebsd.org Subject: I forgot to mention (re: 2.1.0-951026-SNAP). Reply-To: hackers@freebsd.org Date: Fri, 27 Oct 1995 11:21:32 -0700 Message-ID: <10808.814818092@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk This snapshot also tries again to address the IDE CDROM and 4MB issues (the features that wouldn't die! :). Please send me ANY success/fail reports you may have with either 4MB configurations or the atapi.flp boot image with IDE CDROM drives. Thank you! Jordan From owner-freebsd-hackers Fri Oct 27 11:24:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA10217 for hackers-outgoing; Fri, 27 Oct 1995 11:24:01 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA10211 ; Fri, 27 Oct 1995 11:23:59 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA10820; Fri, 27 Oct 1995 11:23:15 -0700 To: announce@freebsd.org cc: hackers@freebsd.org Subject: Come and get it! 2.1.0-951026-SNAP is released! Reply-to: hackers@freebsd.org Date: Fri, 27 Oct 1995 11:23:15 -0700 Message-ID: <10818.814818195@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk I know I said that the previous snapshot would be the last one before 2.1, but the best laid plans and all that.. This snapshot incorporates 6 days worth of some of the most frenetic development I can remember in recent history. MANY MANY problems were fixed, some additional features were added and extensive updates to the documentation were made. Forget what I said about the last snapshot being the release candidate - THIS is the release candidate! :-) Some of the fixes from this snapshot include: o All /etc/sysconfig information now written correctly. o WEB server option now works properly. o The package installation menu now works. o All the auto-installation instrumentation (installation by config file) now works. It's possible to install everything from start to finish on a new system in a fully-automated fashion (if you install a lot of systems, this is a big help). o You may now read the HTML Handbook and FAQ documents directly from the boot floppy after installation (as well as visit any other WEB site). o Failure to create a /usr is no longer an error, just a warning. o The matcd driver was shrunk down some more, *possibly* resulting in a return to 4MB operation (please test this). o The latest ATAPI CDROM changes were merged in and another atapi.flp boot image generated. Again, please test. And many many other things, far too numerous to mention. I'm very grateful to all of those who took time out from their busy schedules to install and comment on the last snapshot. If I can prevail on all of you to do so just one more time, the final 2.1 release will surely be the better for it. Things are actually solid enough at this stage that I don't expect the actual 2.1 release to be functionally much different than this snapshot. The commercial and experimental distributions still need to be updated (this snapshot references the 2.0.5 ones) and now that I'm basically finished with just trying to make all of this work, I'll be attending to this over the next couple of days (apologies to all of our friends in the commercial software community who have been waiting patiently for me to get back to them). Installation feedback, as always, to me please.. Also, if you find something that looks to be more "generally" wrong (e.g. not a simple side-effect of the installation itself) then I'm not actually the best person to send it to - please address all such comments to the stable@freebsd.org mailing list, where they may receive wider feedback (I'm on this mailing list too, so if something looks like it's mine I'll field it). Thank you! Jordan From owner-freebsd-hackers Fri Oct 27 11:44:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA11410 for hackers-outgoing; Fri, 27 Oct 1995 11:44:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA11388 for ; Fri, 27 Oct 1995 11:43:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA23625; Fri, 27 Oct 1995 11:32:28 -0700 From: Terry Lambert Message-Id: <199510271832.LAA23625@phaeton.artisoft.com> Subject: Re: boot disk.... To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 27 Oct 1995 11:32:28 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4798 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Terry Lambert stands accused of saying: > > Define "work". 8-). > > If I have a disk that claims to be 2000/10/17, and I rewrite it to > 1000/20/17, will the BIOS make the right calculations. It would appear not 8( I should have said "define work right". 8-). IF the BIOS is hooked via INT 13 redirector AND IF the redirector respects the table contents when doing its multiply by the C/H/S value to get an absolute sector offset which it uses internally on the controller (since drives are not addressed by a C/H/S value internally), THEN your INT 21 operations will not fail. BUT since the reason you need INT 21 operations is to translate the C/H/S value in the DOS partition table into an absolute sector offset so that the BSD protected mode driver, which doesn't know anything about C/H/S values except phisical ones to use them to get absolute real disk sectors, THEN your use of the DOS patition table contents will fail AND THEN your attempt to locate the BSD partition on the disk will fail AND THEN your BSD will fail. > Here are some scribbles wrt. what I'm trying to work out... > > Bootmanager (MBR) looks up first sector of FreeBSD slice. > Have to assume (for now) that it knows how to reach beyond the 1024 cyl. > mark. It doesn't. It can't. What it *MIGHT* be able to do *IF* it's a non-standard MBR replacement (which we will tromp on anyway to put in a boot selector) is use the standard-but-implemented-by-no-programs-because-it's-not-portable LBA INT 21 extensions to do the loading instead of C/H/S values. This is useless because the BSD BIOS-based second stage boot doesn't know about non-standard-about-to-be-stomped-on-by-boot-selector-replacement LBA-type addressing. It only knows about standard INT 21. > Stage 0 bootstrap (first sector of FreeBSD slice) reads Stage 1 bootstrap > from next N sectors of FreeBSD slice. Uses same technique as the MBR code > to reach beyond 1024 cyls. That would be BIOS-based geometry translation (for most SCSI devices) and OnTrack 6.x INT-13-redirector-TSR-based geometry translation for most IDE devices (which are otherwise too stupid to translate the geometry on their own). Currently, this is called the second stage (or OS specific) bootstrap. > Stage 1 boostrap (lives in first track(s) of FreeBSD slice) (code that > currently gives the Boot: prompt) should search all FreeBSD slices > and partitions looking for an 'a' filesystem containing a file called > 'boot2' (or whatever - it's the stage 2 bootstrap code). > This should be read in (version checks? checksums? fallbacks?) and called. > (Still in real mode) This is the "boot program without the 8k limit" idea. This would in fact be a third stage bootstrap. I find it really questionable that this much work would be put into what is basically a kludge to get around the lack of firmware access in the protected mode code. It's really a much less general soloution than the implementation of a VM86() mode, considering there are three working examples (1) Linux, (2) NetBSD, and (3) CMU Mach, on how to implement a VM86() mode. Consider that a generlization of the boot process for PPC/Alpha/Sun/etc. will require the ability to make firmware calls from protected mode. The difference is that for those systems, the interface is implemented, and for Intel it (VM86) is not. > Stage 2 boostrap runs in real mode under the BIOS. It should provide > facilities to select the root filesystem and kernel. It should be able > to read the device configuration out of the kernel, and thus inherit > the functionality of userconfig(). It should perform MBR fixup to > guarantee that the absolute offset field in the MBR matches the c/h/s > values for the slice under the BIOS geometry. It should also be buildable > as a DOS program, to allow it to work with Ontrack's Disk Mangler. The > ability to provide the correct major/minor numbers to the kernel > (automatic detection of the wd/hd/sd stuff in the current idiom) would > follow as a matter of course. A lot of work to replace exisiting functionality. I believe that we could benefit from discarding the segments containing the code after boot (ie: code/data/boot code/boot data/etc.), but I think doing the BIOS thing in a third stage boot is unnecessary. > Now, I'm sure that the purists and the serial console people are screaming > here, so there's a need to continue to support the current scheme as well. That would make me a purist. 8-). > Input and, naturally, time are required. Alternatively, if someone wants > to pick this up and play with it, please do! Not me, at least not right now. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Oct 27 12:08:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13033 for hackers-outgoing; Fri, 27 Oct 1995 12:08:31 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13024 for ; Fri, 27 Oct 1995 12:08:25 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA24658; Sat, 28 Oct 1995 05:03:48 +1000 Date: Sat, 28 Oct 1995 05:03:48 +1000 From: Bruce Evans Message-Id: <199510271903.FAA24658@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >> >I think using registers for calls and inlining are antithetical. You >> >> Calls to inline functions don't use the standard calling convention. >Calls to system calls *must* use *some* calling convention agreed upon >in advance and invariant under optimization, or it will be indeterminate >under optimization. This is obvious. I was talking about inline functions in the kernel. >> >> This may be true if you control the ABI. >> >> >You *do* control the ABI. You are either running a known ABI paradigm >> >(ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are >> >running a compatability ABI, in which case you know at binary load time >> >> You know it but you don't control it. >Excuse me? You are attempting to assert exactly that control on the >Intel ABI and you are arguing that it can't be done? I was talking about ABI-decoding functions in the kernel (until this discussions got sidetracked into talking about changes to the FreeBSD ABI that we control (FreeBSD != ibcs2)). >> Er, you have this exactly backwards. My wrappers provide part of >> what is required to handle nontrivial conversions from a 16 bit >> ABI to a 32 bit one. >If I produce new code for an emulated environment, I'm *not* going >to be doing so in a native environment. The code production will >be in the cross environment as well. >Wrappering is a non-issue for conversions. Wrappering *is* an issue >in code complexity. I believe complexity should be reduced wherever >possible -- and this is not done by imposing ever more rigid standards >on the programmer, it's done by making the code environment more >flexible. I was talking about reducing code complexity by doing all conversions automatically. >What wall time differentials do you expect from the conversion, and >why? Small. The current unportable code is close to optimal. I wouldn't make it slower. The machine generated code for the current FreeBSD i386 ABI might even be exactly the same as now because all conversions can be reduced to no-ops (this must be possible because the unportable code actually works). >Consider for example a PPC port of FreeBSD capable of running Intel >FreeBSD binaries. The capability and the endianess issues must be >handled in the ABI call emulation layers. The code will execute >in an emulated 386 environment, but all kernel support will be >native. >This is on the order of an XDR interface that is contextualized for >the native byte/word order of the machine instead of network byte >order. >The point is that the call conversion is layered seperately from the >call implementation. Conceptually it's a different layer but it shouldn't be implemented as a separate layer. My idea is to introduce such a conceptual layer somewhere between the syscall entry point (Xsyscall()) and the syscall implementing functions (e.g., read()) and then merge the layers as much as possible using machine-generated code. >> >packing must be specifiable at declaration time, or (preferrably) both. >> >> Packing can't be specified in C. That's why my my machine generated >> wrappers are required - to provide portability. It isn't worth >> supporting both because if you support the worst case (weird packing) >> then it just takes more code to support the array case. >#pragma. If we are talking about compiler modifications, packing #pragma's >are much more generally useful than register call wrappings and the >internal code you have suggested for varargs. All #pragmas are unportable. >What is your wrapper for open( const char *, int, ...)? On the user side (so that the open syscall doesn't have a variable number of args: int open(char const *path, int flags, ...) { va_list argp; int retval; va_start(argp, flags); if (flags & O_CREAT) { /* * This code is written for maximal portability to expose the full * braindamage of the open() interface. Actual implementations * should use one of the easier alternatives and shoot themselves * in the foot by using e.g., `long double' for mode_t. mode_t * is guaranteed to be an arithmetic type (POSIX.1 2.5) and * va_arg is only guaranteed to work for types that are their * own default promotion, so there are many cases. */ /* * Actually I'm too lazy to write all the tests to decide the * promotion of mode_t. Assume it is `promoted_mode_t'. Also * assume that we pass args of fixed size to syscalls and that * registered_mode_t is a type that has that size and holds * mode_t's without loss of information. */ promoted_mode_t mode; registered_mode_t rmode; mode = va_arg(argp, int); rmode = = (registered_mode_t)mode; retval = three_arg_open_syscall(path, flags, rmode); } else retval = two_arg_open_syscall(path, flags); va_end(argp); return retval; } On the kernel side: I can't write it without knowing the target machine. Assuming a simple case where the user side stored the args in a uniform way on the stack or in registers and the lower level kernel code has copied the args from to memory: int syscall_entry_open(struct proc *p, void *argp, int *retval) { char const *path; int flags; promoted_mode_t mode; path = *(char const *)((char *)argp + PATH_OFFSET); flags = *(int *)((char *)argp + FLAGS_OFFSET); if (flags & O_CREAT) { mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); return open(p, retval, path, flags, mode); } return open(p, retval, path, flags); } >> My ideas for syscalls are based on what is done for vnodes :-). It >What about non-native architecture ABI support? It requires more code to generate the conversion code. In particular, sizeof() and `struct' can't be used, because the non-native compiler may have completely different behaviour (of course, it's not practical to emulate a machine with a larger address space or ints larger than your quads). >> You can't vary Xenix 286's syscall parameter passing conventions! >What have I said that implied this? The abstraction layering, since >it is *in the kernel* in the class-call handling code, would be >transparent. Perhaps I mean something nonstandard by the ABI. I mean the parameter passing conventions more than the syscall semantics... >The point is to have a native ABI that matches the kernel exported ABI >to reduce overhead for native apps. ... and I mean `I' to stand for interface, not implementation. By definition, the ABI is whatever the kernel exports, and native apps use it. >By going to a register passing mechanism, you destroy this, and complicate >the non-native ABI's at the same time... don't you see this as well? The register passing mechanism for syscalls is a side issue. I only mentioned it as an example of an ABI that we have to emulate (for Linux) and which is better so we should use it. There would be no new complications (except for improvements) because we already support the Linux ABI. >> >I object to needing to include standard system call prototypes to allow >> >their use. I put up with lseek/truncate/ftruncate/mmap BS because it's >> >> It isn't required. However, passing of args that have the correct type >> (after the default promotions) is required. The second arg to lseek >> must be off_t, not long, except of course if off_t is long. >??? If it's not required, then either you *aren't* talking about passing >arguments to system calls in registers *or* you expect the compiler to >"do the right thing" magically. I'm talking about the requirement in C to pass parameters of the correct type (if a prototype is in scope, then there are more correct types). >Right now I can write code that makes system calls in assembly. With >register passing conventions, I will need to either use library or >machine generated external routine calls (unacceptable), or I will have >to have documentation of what the compiler has done so that I can do >the same thing (non-portable as hell -- ever use M4 to write machine >independent assembly code?). It's always been necessary to know what what the compiler does if you write glue functions in assembler. (gcc) inline assembler has many advantages here. You don't need to know what the compiler does (you just tell it how to load syscall args), and one layer of glue can be avoided. >> >Note that prototypes of system calls screw up your ability to properly >> >utilize the syscall(2) call gate mechanism the way it was intended. A >> >> The use of syscall() in general requires handling all the messy conversion >> issues that we have been discussing in your own code. >Why is that? A push is a push. A trap is a trap. >The only "messy conversion" is in pushing the arguments on the stack, >and I still fail to see the benefit of playing "keep up with Linux" >in this regard. syscall() is written in C, so the compiler can pass args to it anywhere it wants. syscall() then has the task of putting the args where the kernel expects them. In general, it would have to know about all syscalls and do the inverse of the conversions that I'm talking about doing in the kernel. Consider a 68K compiler that passes the first 2 pointer args (if any) in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other args on the stack. How are you going to push the args in syscall()? Hint: you'll need to know the arg types of all syscalls. >> (2) choose a different violation of the ANSI C >> >and POSIX standards -- interface extension -- instead of passing quad's >> >> POSIX allows most reasonable extensions. >Yeah, well using quad for off_t isn't one of them. Would you prefer double? Allowing it seems to be a bug in POSIX.1-1990. More things would break. >> Linux has llseek. That way leads to many ifdefs. >It leads to: >#ifdef HAS_QUADS >#ifndef INT_IS_64 >#if BSD44 >#define lseek(filedes,offset,whence) qlseek(filedes,offset,whence) >#define off_t quad_t >#endif /* BSD44*/ >#if LINUX >#define lseek(filedes,offset,whence) llseek(filedes,offset,whence) >#define off_t quad_t >#endif /* LINUX*/ >#endif /* !INT_IS_64*/ >#endif /* HAS_QUADS*/ >in one app-specific header file. It's worse than that. Linux doesn't have quads. Applications have to use pairs of longs and do their own (equivalent to quad) arithmetic on them. So ifdefs like the above all through the code might be necessary. >I believe the wrappering to constitute obfuscation, not simplification. >There is a difference between conceptual simplification (but no >document to reference to determine conception) and implementational >simplification. >I'm opposed to additional obfuscation of the call interface to >allow questionable processor specific optimization to take place >at the expense of ABI emulation portability. We're in violent agreement :-). I'd like to hide the current unportabilities and scattered casts in a conceptually simple layer. This requires a complicated and unportable implementation for the layer. Bruce From owner-freebsd-hackers Fri Oct 27 12:14:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13694 for hackers-outgoing; Fri, 27 Oct 1995 12:14:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13655 for ; Fri, 27 Oct 1995 12:13:54 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA23671; Fri, 27 Oct 1995 12:03:47 -0700 From: Terry Lambert Message-Id: <199510271903.MAA23671@phaeton.artisoft.com> Subject: Re: New lmbench available (fwd) To: rcarter@geli.com (Russell L. Carter) Date: Fri, 27 Oct 1995 12:03:47 -0700 (MST) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510270531.WAA05178@geli.clusternet> from "Russell L. Carter" at Oct 26, 95 10:31:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3156 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > So here is a market opportunity: how do you scale a bunch of > httpd servers working in concert (maybe like timed?) so that when one > goes down, the remainders elect a master and life goes on? #ifdef TERRY_IN_FUTURIST_MODE You connect to services instead of machines, of course, and the underlying transport is permitted to load balance you off onto another server. I coined the term "server anonymity" for this four years ago. The problem is in the protocols... they are server connection rather than service connection oriented. Consider: do I really give a damn where the next 512 frames of my "Raiders of the Lost Ark" come from, as long as they get to me? I really want to be able to ask for them and not care *who* sends them to me, as long as *someone* does. The next step after the implementation of "server anonymity" is implementation of "content addressable networking". Domain proximity is also what dictates network path congestion probability. The higher the proximity, the lower the probability. At that point, the service that gets charged for is data vaulting and service replication level. If I release a movie into this type of system, my ability to deliver it to 'N' people is based on how many places the service exists. So my costs are based on the number of vaulting locations I rent and their domain proximity (in hops) to the people who want the information. Obviously, there's a lot of vested interest in the wire companies for connection/circuit oriented delivery systems. That's because everyone has been killing each other and themselves to sell you the wire into your house on the expectation that they will be able to meter your usage and charge accordingly. On the other side of the coin are the people who want to deluge you with "junk email", which you'll refuse to pay metered rates for. After all, you're not stupid. You've paid air-time for unsolicited cell phone calls, and you know that metering fails under those conditions. Turns out the real money is going to be in vaulting (distribution) and production of content. (BTW, I want credit for this if you repeat it or use it. 8-).) #endif /* TERRY_IN_FUTURIST_MODE*/ For now, scaling is based on the assumption that session duration for a series of transactions over a connection to a server will be statistically normative. So you "load balance" by rotoring the machine that gets the actual connection by setting up a DNS rotor. When the address is requested for a given machine name, the query is responded to by iterating a set of hosts such that the load is distributed round-robin. Of course, this fails to load balance under caching (which DNS does), and it fails to load balance under non-homogeneous connection duration (which humans do), and it fails to load balance under disparate data served from a single server (which humans also do). Basically, it fails to load balance. But it *is* the way things are currently done, and you do get some marginal increase in capability from it. 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 Oct 27 12:25:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14365 for hackers-outgoing; Fri, 27 Oct 1995 12:25:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14358 for ; Fri, 27 Oct 1995 12:25:16 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA25068; Sat, 28 Oct 1995 05:19:20 +1000 Date: Sat, 28 Oct 1995 05:19:20 +1000 From: Bruce Evans Message-Id: <199510271919.FAA25068@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, terry@lambert.org Subject: Re: boot disk.... Cc: hackers@FreeBSD.ORG, lenzi@cwbone.bsi.com.br Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> If I have a disk that claims to be 2000/10/17, and I rewrite it to >> 1000/20/17, will the BIOS make the right calculations. It would appear not 8( >I should have said "define work right". 8-). >IF the BIOS is hooked via INT 13 redirector >... Boot Manager does it, so it can work. Complications may arise when INT 13 has been hooked `N' times by `N' boot managers :-). Bruce From owner-freebsd-hackers Fri Oct 27 12:33:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14836 for hackers-outgoing; Fri, 27 Oct 1995 12:33:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14817 for ; Fri, 27 Oct 1995 12:33:32 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA25371; Sat, 28 Oct 1995 05:29:30 +1000 Date: Sat, 28 Oct 1995 05:29:30 +1000 From: Bruce Evans Message-Id: <199510271929.FAA25371@godzilla.zeta.org.au> To: julian@ref.tfs.com, vcapuano@esoc.esa.de Subject: Re: _SC_PAGESIZE patch to sysconf(3) Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >It's not a bad addition, but it's not in the POSIX definitions >that I can see, though I only have the XPG4 definitions which >allign this call to posix-1 despite having some posix 2 definitions in it >(the posix 2 standard was still not approved when XPG4 went to print I think) >if this is not POSIX standard it should be hidden behind a >#ifndef _POSIX_SOURCE >> >> I was porting a program I developed on Solaris to FreeBSD when I got into a >> missing call: sysconf(_SC_PAGESIZE). I know I could use getpagesize(3), but >> I then had to ifdef my code. It's already hidden by using an identifier in implementation's namespace. An application that is careful enough to define _POSIX_SOURCE should be careful enough not to reference nonstandard indentifiers. Bruce From owner-freebsd-hackers Fri Oct 27 12:43:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15509 for hackers-outgoing; Fri, 27 Oct 1995 12:43:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA15504 for ; Fri, 27 Oct 1995 12:43:27 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA25718; Sat, 28 Oct 1995 05:40:54 +1000 Date: Sat, 28 Oct 1995 05:40:54 +1000 From: Bruce Evans Message-Id: <199510271940.FAA25718@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, terry@lambert.org Subject: Re: boot disk.... Cc: hackers@freebsd.org, lenzi@cwbone.bsi.com.br Sender: owner-hackers@freebsd.org Precedence: bulk >Stage 2 boostrap ... >... should perform MBR fixup to >guarantee that the absolute offset field in the MBR matches the c/h/s >values for the slice under the BIOS geometry. Only for its own benefit. Drivers don't want to know about yet another translation. >It should also be buildable >as a DOS program, to allow it to work with Ontrack's Disk Mangler. The Nothing should require DOS utilitites to build. Bruce From owner-freebsd-hackers Fri Oct 27 12:52:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA16228 for hackers-outgoing; Fri, 27 Oct 1995 12:52:51 -0700 Received: from tesla.cview.com (root@tesla.cview.com [204.95.57.17]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA16214 for ; Fri, 27 Oct 1995 12:52:43 -0700 Received: by tesla.cview.com (Smail3.1.29.0 #1) id m0t8ulQ-0001F9C; Fri, 27 Oct 95 14:48 CDT Message-Id: Date: Fri, 27 Oct 95 14:48 CDT From: malenovi@cview.com (Nik Malenovic) To: freebsd-hackers@freebsd.org Subject: Re: patch for PTYs not freed? (2.0.5-R) (screen problem) Newsgroups: cview.freebsd.hackers In-Reply-To: Organization: CView Inc. Cc: dk@dog.farm.org Sender: owner-hackers@freebsd.org Precedence: bulk In article you write: >I am gotting that same bug which bites me: >under screen, create virtual console (using PTY), run telnet/rlogin under it, >kill the shell process (telnet not killed), re-create virtual console >(same PTY used), alas, I got input from shell/old telnet process intermixed. blah. you are lucky - I can't even get screen to work on ANY of my boxes. all the way since 1.5.1 - I am having this darn problem - screen hangs. I know people had complained about it - but no one ever offered a fix. I tried to debug it - and the problem was that the master process was dying and spawned processes would just bomb out. WHY the master process was dying? no clue. anyway - if anyone has any clues... please let me know! :) Nik From owner-freebsd-hackers Fri Oct 27 13:20:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA17934 for hackers-outgoing; Fri, 27 Oct 1995 13:20:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA17904 for ; Fri, 27 Oct 1995 13:20:03 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23809; Fri, 27 Oct 1995 13:09:47 -0700 From: Terry Lambert Message-Id: <199510272009.NAA23809@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 13:09:46 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510271903.FAA24658@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 05:03:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9639 Sender: owner-hackers@freebsd.org Precedence: bulk > >What wall time differentials do you expect from the conversion, and > >why? > > Small. The current unportable code is close to optimal. I wouldn't > make it slower. The machine generated code for the current FreeBSD > i386 ABI might even be exactly the same as now because all conversions > can be reduced to no-ops (this must be possible because the unportable > code actually works). The reason for my asking was to determine if you believed this to be a speed optimization (which I might be able to get behind) or if it's simply an interface change (which I suspected it was, and so it's now an issue of whether it's gratuitious or if ti really buys something). [ ... reordered for coherency ... ] > >#pragma. If we are talking about compiler modifications, packing #pragma's > >are much more generally useful than register call wrappings and the > >internal code you have suggested for varargs. > > All #pragmas are unportable. All packing assumptions are unportable. I argue that a #pragma beats the __attrib crap because a compiler may ignore it. > Conceptually it's a different layer but it shouldn't be implemented as > a separate layer. My idea is to introduce such a conceptual layer > somewhere between the syscall entry point (Xsyscall()) and the syscall > implementing functions (e.g., read()) and then merge the layers as > much as possible using machine-generated code. [ ...] > >What is your wrapper for open( const char *, int, ...)? > > On the user side (so that the open syscall doesn't have a variable number > of args: > > int open(char const *path, int flags, ...) Whoah. Right there we have a problem. I'll be happy to give you my varrarg macros to make them ANSI-C and K&R C independent. Usign varrargs in an ANSI dependent fashion reduces portability to non-ANIC-C envirnments. The things belong in ctypes.h anyway. [ ... ] > int open(char const *path, int flags, ...) > { > va_list argp; > int retval; > > va_start(argp, flags); > if (flags & O_CREAT) { > promoted_mode_t mode; > registered_mode_t rmode; > > mode = va_arg(argp, int); > rmode = = (registered_mode_t)mode; > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = two_arg_open_syscall(path, flags); > va_end(argp); > return retval; > } I think that the system call itself could make the decision based on the O_CREAT itself. I'd suggest changing: > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = two_arg_open_syscall(path, flags); to: > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = three_arg_open_syscall(path, flags, 0); [ ... ] > On the kernel side: I can't write it without knowing the target machine. > Assuming a simple case where the user side stored the args in a uniform > way on the stack or in registers and the lower level kernel code has > copied the args from to memory: [ ... ] > path = *(char const *)((char *)argp + PATH_OFFSET); > flags = *(int *)((char *)argp + FLAGS_OFFSET); > mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); Forgive me... but this is butt-ugly. I mean really, *really* butt-ugly. I find this horribly obfucated. This is exactly what I feared when I objected. 8-(. BTW: the 'path' line is broken... "*(const char **)", maybe? Since the stack variable assigns are based on an entry argument, then the assignments can be done at declaration time. Therefore something like: #define ARG(argtype,arg) \ argtype arg = *(__CONCAT(argtype,*))((char *)argp + \ __CONCAT(arg,_OFFSET)); Then: > int syscall_entry_open(struct proc *p, void *argp, int *retval) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > if (flags & O_CREAT) { > return open(p, retval, PATH, FLAGS, MODE); > } > return open(p, retval, PATH, FLAGS); > } Would be more readable. I don't understand why passing a bogus mode to open when O_CREAT wasn't present would be a problem??? That is, why not: > int syscall_entry_open(struct proc *p, void *argp, int *retval) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > return open(p, retval, PATH, FLAGS, MODE); > } ??? Hell: #define SYSCALL_ENTRY(function) \ int __CONCAT(syscall_entry_,function) \ (struct proc *p, void *argp, int *retval) > SYSCALL_ENTRY(open) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > return open(p, retval, PATH, FLAGS, MODE); > } > >What about non-native architecture ABI support? > > It requires more code to generate the conversion code. In particular, > sizeof() and `struct' can't be used, because the non-native compiler > may have completely different behaviour (of course, it's not practical > to emulate a machine with a larger address space or ints larger than > your quads). I agree with the practicality argument: after all, that's exactly what we are doing already with lseek, et al. 8-). I know the XDR aspects re structure packing are an issue, though since you seem to be assuming the same compiler source everywhere (GCC), I don't see where a packing paragma would be more of an issue than any other approach requiring compiler modifications. > >By going to a register passing mechanism, you destroy this, and complicate > >the non-native ABI's at the same time... don't you see this as well? > > The register passing mechanism for syscalls is a side issue. I only > mentioned it as an example of an ABI that we have to emulate (for Linux) > and which is better so we should use it. There would be no new > complications (except for improvements) because we already support the > Linux ABI. I'm glad to see this. I think, though, the rationale for the changes still hasn't been clarified. > >??? If it's not required, then either you *aren't* talking about passing > >arguments to system calls in registers *or* you expect the compiler to > >"do the right thing" magically. > > I'm talking about the requirement in C to pass parameters of the correct > type (if a prototype is in scope, then there are more correct types). OK. I buy this too. But this implies that if there is not a prototype in scope, a function that uses a type that is not correct without a prototype in scope should not generate a bogus call reference. This was my point on the quad crap and reverting the default interfaces to POSIX compliance (and double doesn't count unless you can use it without a prototype in scope). > >Right now I can write code that makes system calls in assembly. With > >register passing conventions, I will need to either use library or > >machine generated external routine calls (unacceptable), or I will have > >to have documentation of what the compiler has done so that I can do > >the same thing (non-portable as hell -- ever use M4 to write machine > >independent assembly code?). > > It's always been necessary to know what what the compiler does if you > write glue functions in assembler. (gcc) inline assembler has many > advantages here. You don't need to know what the compiler does (you > just tell it how to load syscall args), and one layer of glue can be > avoided. But *lord*! Having to happen to know what register the argument goes into before the call! > >> >Note that prototypes of system calls screw up your ability to properly > >> >utilize the syscall(2) call gate mechanism the way it was intended. A > >> > >> The use of syscall() in general requires handling all the messy conversion > >> issues that we have been discussing in your own code. > > >Why is that? A push is a push. A trap is a trap. > > >The only "messy conversion" is in pushing the arguments on the stack, > >and I still fail to see the benefit of playing "keep up with Linux" > >in this regard. > > syscall() is written in C, so the compiler can pass args to it anywhere it > wants. syscall() then has the task of putting the args where the kernel > expects them. In general, it would have to know about all syscalls and > do the inverse of the conversions that I'm talking about doing in the > kernel. Bletch. How does Linux deal with it (my linux box is running Win95 right now)? > Consider a 68K compiler that passes the first 2 pointer args (if any) > in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other > args on the stack. How are you going to push the args in syscall()? > Hint: you'll need to know the arg types of all syscalls. That's an evil way to pass arguments, then. 8-(. > >> (2) choose a different violation of the ANSI C > >> >and POSIX standards -- interface extension -- instead of passing quad's > >> > >> POSIX allows most reasonable extensions. > > >Yeah, well using quad for off_t isn't one of them. > > Would you prefer double? Allowing it seems to be a bug in POSIX.1-1990. > More things would break. No. I'd prefer int/long. > It's worse than that. Linux doesn't have quads. Applications have to use > pairs of longs and do their own (equivalent to quad) arithmetic on them. > So ifdefs like the above all through the code might be necessary. Linux has GCC. Linux has quads. > We're in violent agreement :-). I'd like to hide the current > unportabilities and scattered casts in a conceptually simple layer. I agree. > This requires a complicated and unportable implementation for the > layer. I don't agree. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Oct 27 13:21:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18066 for hackers-outgoing; Fri, 27 Oct 1995 13:21:31 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18046 for ; Fri, 27 Oct 1995 13:21:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23822; Fri, 27 Oct 1995 13:11:18 -0700 From: Terry Lambert Message-Id: <199510272011.NAA23822@phaeton.artisoft.com> Subject: Re: _SC_PAGESIZE patch to sysconf(3) To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 13:11:18 -0700 (MST) Cc: julian@ref.tfs.com, vcapuano@esoc.esa.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199510271929.FAA25371@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 05:29:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 823 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >if this is not POSIX standard it should be hidden behind a > >#ifndef _POSIX_SOURCE > >> > >> I was porting a program I developed on Solaris to FreeBSD when I got into a > >> missing call: sysconf(_SC_PAGESIZE). I know I could use getpagesize(3), but > >> I then had to ifdef my code. > > It's already hidden by using an identifier in implementation's namespace. > An application that is careful enough to define _POSIX_SOURCE should be > careful enough not to reference nonstandard indentifiers. Disagree. Non-standard system features should be diked out so that code portability can be determined with a compilation attempt. SunOS did this with their _POSIX_SOURCE as well. 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 Oct 27 13:26:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18286 for hackers-outgoing; Fri, 27 Oct 1995 13:26:19 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18274 for ; Fri, 27 Oct 1995 13:26:11 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23839; Fri, 27 Oct 1995 13:15:53 -0700 From: Terry Lambert Message-Id: <199510272015.NAA23839@phaeton.artisoft.com> Subject: Re: boot disk.... To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 13:15:53 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@freebsd.org, lenzi@cwbone.bsi.com.br In-Reply-To: <199510271940.FAA25718@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 05:40:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1216 Sender: owner-hackers@freebsd.org Precedence: bulk > >Stage 2 boostrap ... > >... should perform MBR fixup to > >guarantee that the absolute offset field in the MBR matches the c/h/s > >values for the slice under the BIOS geometry. > > Only for its own benefit. Drivers don't want to know about yet another > translation. If this is there, then there is NO SUCH THING AS TRANSLATION from the kernel perspecitve. The kernel ignores the C/H/S values, using the 32 bit sector offsets instead (which are now guaranteed to be valid). Almost all translation problems bite the dust. The exception is for non-linear translation (BIOS-based sector sparing, etc.), and then you are screwed on a shared disk in any case unless you can turn it off. You are also screwed unless the disk is used as a naked BSD disk without a DOS partition table/MBR. It works with the BIOS boot code because the cylinder offset on a naked partition is invariant under translation. > >It should also be buildable > >as a DOS program, to allow it to work with Ontrack's Disk Mangler. The > > Nothing should require DOS utilitites to build. Agree. 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 Oct 27 13:34:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18771 for hackers-outgoing; Fri, 27 Oct 1995 13:34:56 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id NAA18762 for ; Fri, 27 Oct 1995 13:34:50 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA23654; Fri, 27 Oct 1995 16:33:51 -0400 Date: Fri, 27 Oct 1995 16:33:51 -0400 From: "Garrett A. Wollman" Message-Id: <9510272033.AA23654@halloran-eldar.lcs.mit.edu> To: Terry Lambert Cc: hackers@freebsd.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-Reply-To: <199510272009.NAA23809@phaeton.artisoft.com> References: <199510271903.FAA24658@godzilla.zeta.org.au> <199510272009.NAA23809@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org Precedence: bulk [CC list trimmed. I don't read -hackers.] < said: > But this implies that if there is not a prototype in scope, a function > that uses a type that is not correct without a prototype in scope should > not generate a bogus call reference. Not at all. IT IS THE CALLER'S RESPONSIBILITY TO PASS THE CORRECT TYPES AND ALWAYS HAS BEEN. In particular, it is incorrect to call lseek() with a `where' argument of any type other than `off_t', and if a prototype is not in scope, the the programmer damn well better use a cast to ensure that the correct type is being used. >> [Bruce wrote:] >> Consider a 68K compiler that passes the first 2 pointer args (if any) >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other >> args on the stack. How are you going to push the args in syscall()? >> Hint: you'll need to know the arg types of all syscalls. > That's an evil way to pass arguments, then. 8-(. That's a fast way to pass arguments on a slow architecture. If you don't like it, tough, because I /know/ that there are compilers out there that do this, or something nearly like it. (And don't forget the SPARC, where under Sun's compiler all aggregates are passed by hidden reference.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-hackers Fri Oct 27 13:35:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA18858 for hackers-outgoing; Fri, 27 Oct 1995 13:35:38 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA18852 for ; Fri, 27 Oct 1995 13:35:35 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id NAA02708 for hackers@freebsd.org; Fri, 27 Oct 1995 13:35:20 -0700 Received: from inetgwy.asctmd.com (inetgwy.asctmd.com [198.59.170.33]) by ref.tfs.com (8.6.12/8.6.12) with ESMTP id HAA02082 for ; Fri, 27 Oct 1995 07:31:41 -0700 From: supervisor@alb.asctmd.com Received: from alb.asctmd.com (alb.asctmd.com [198.59.170.34]) by inetgwy.asctmd.com (8.6.11/8.6.9) with SMTP id IAA00456 for ; Fri, 27 Oct 1995 08:31:45 -0600 Received: from ALBUQUERQUE-Message_Server by alb.asctmd.com with WordPerfect_Office; Fri, 27 Oct 1995 08:32:37 -0700 Message-Id: X-Mailer: WordPerfect Office 4.0 Date: Fri, 27 Oct 1995 08:30:36 -0700 To: julian@ref.tfs.com Cc: jhay@mikom.csir.co.za Subject: Re: IPX feedback request -Reply Sender: owner-hackers@FreeBSD.org Precedence: bulk I saw some of the messages on the "freebsd-commit" mailing list concerning the IPX stuff. Julian, thank you for your time. Some goals which I think may merit further attention: 1. SPX requires further testing. I have not ever written an application that actually tests the implementation. Two programs should be written-the first generates packets of known content and sends them. The second receives packets and checks them for known content. It must be determined that packets are received in the exact order that they were sent. Following this, random breaks in the transmission line should be introduced so that the transmission recovery mechanism can be checked. The SPX connection must be terminated correctly to both programs OR recover as if there were not a problem with the transmission line. 2. Modification of the libc/net/get* routines to support multiple address families, especially for look up of hosts and networks in files located in /etc. DNS routines should not be touched. I forget which man page suggests that this is possible, but all of these routines deal EXCLUSIVELY with AF_INET. This is kind of bogus. Example, if I want to enter IPX type addresses in /etc/hosts, I should be able to... 3. IPXrouted should be enhanced to support (for LAN to WAN issues): a. command line tuneable RIP/SAP rebroadcast timeouts b. "directed broadcast" of RIP/SAP information across routers c. command line tuneable for omission of RIP or SAP information? d. look at the Novell NLSP stuff concerning RIP/SAP for other ideas 4. IPX compatible SNMP daemon. I like some of the tools available that use SNMP over IPX to collect information from remote nodes. Anyone know where to get low level implementation details on this kind of stuff? White papers? 5. Port Samba to make use of the IPX transport. Windows 3.11 and Windows 95 use this protocol as a default one after installation. I think it would be cool to use FreeBSD as a "server" for these type of machines... Most of the code already exists, and this would be a great way to ring out the IPX/SPX implementation. (Hidden agenda--Windows NT has nice network connectivity, lets design some of these features back into our favorite brand of Unix... ;-) 6. After IPX has been fixed, maybe we should check into merging the netns directory into netipx (or the other way around) and eliminate one of the directories. These two protocols are pretty similar, there are a few fundamental differences in RIP, SAP, and other protocols using the IPX transport, but these issues should probably not be handled by the IPX transport driver. Does anyone use really use netns? From owner-freebsd-hackers Fri Oct 27 13:42:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19387 for hackers-outgoing; Fri, 27 Oct 1995 13:42:22 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19373 for ; Fri, 27 Oct 1995 13:42:15 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id NAA02727; Fri, 27 Oct 1995 13:40:40 -0700 From: Julian Elischer Message-Id: <199510272040.NAA02727@ref.tfs.com> Subject: Re: IPX feedback request -Reply To: supervisor@alb.asctmd.com Date: Fri, 27 Oct 1995 13:40:39 -0700 (PDT) Cc: jhay@mikom.csir.co.za, hackers@freebsd.org In-Reply-To: from "supervisor@alb.asctmd.com" at Oct 27, 95 08:30:36 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2642 Sender: owner-hackers@freebsd.org Precedence: bulk I saw some of the messages on the "freebsd-commit" mailing list concerning the IPX stuff. Julian, thank you for your time. Some goals which I think may merit further attention: 1. SPX requires further testing. I have not ever written an application that actually tests the implementation. Two programs should be written-the first generates packets of known content and sends them. The second receives packets and checks them for known content. It must be determined that packets are received in the exact order that they were sent. Following this, random breaks in the transmission line should be introduced so that the transmission recovery mechanism can be checked. The SPX connection must be terminated correctly to both programs OR recover as if there were not a problem with the transmission line. 2. Modification of the libc/net/get* routines to support multiple address families, especially for look up of hosts and networks in files located in /etc. DNS routines should not be touched. I forget which man page suggests that this is possible, but all of these routines deal EXCLUSIVELY with AF_INET. This is kind of bogus. Example, if I want to enter IPX type addresses in /etc/hosts, I should be able to... 3. IPXrouted should be enhanced to support (for LAN to WAN issues): a. command line tuneable RIP/SAP rebroadcast timeouts b. "directed broadcast" of RIP/SAP information across routers c. command line tuneable for omission of RIP or SAP information? d. look at the Novell NLSP stuff concerning RIP/SAP for other ideas 4. IPX compatible SNMP daemon. I like some of the tools available that use SNMP over IPX to collect information from remote nodes. Anyone know where to get low level implementation details on this kind of stuff? White papers? 5. Port Samba to make use of the IPX transport. Windows 3.11 and Windows 95 use this protocol as a default one after installation. I think it would be cool to use FreeBSD as a "server" for these type of machines... Most of the code already exists, and this would be a great way to ring out the IPX/SPX implementation. (Hidden agenda--Windows NT has nice network connectivity, lets design some of these features back into our favorite brand of Unix... ;-) 6. After IPX has been fixed, maybe we should check into merging the netns directory into netipx (or the other way around) and eliminate one of the directories. These two protocols are pretty similar, there are a few fundamental differences in RIP, SAP, and other protocols using the IPX transport, but these issues should probably not be handled by the IPX transport driver. Does anyone use really use netns? From owner-freebsd-hackers Fri Oct 27 13:48:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19817 for hackers-outgoing; Fri, 27 Oct 1995 13:48:21 -0700 Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19797 for ; Fri, 27 Oct 1995 13:48:02 -0700 Received: from section05 (morse.sarnoff.com [130.33.10.158]) by terra.Sarnoff.COM (8.6.12/8.6.12) with SMTP id QAA16064 for ; Fri, 27 Oct 1995 16:46:34 -0400 Received: from morse (localhost.section05.Sarnoff.COM) by section05 (5.x/SECTION05-Client) id AA02600; Fri, 27 Oct 1995 16:45:53 -0400 Message-Id: <9510272045.AA02600@section05> Date: Fri, 27 Oct 95 16:45:53 -0400 From: "Ron G. Minnich" X-Mailer: Mozilla 1.12 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: hackers@freebsd.org Subject: David Sarnoff Research Center Clusters Page X-Url: ftp://www.sarnoff.com/pub/mnfs/www/cgi-bin/cluster.html Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@freebsd.org Precedence: bulk Folks: i'm in the process of reviving my old clusters home page. Since the new one describes the new FreeBSD-based cluster here at Sarnoff I thought you would be interested. I'd appreciate any comments you have as well. Thanks! ftp://www.sarnoff.com/pub/mnfs/www/cgi-bin/cluster.html -- Ron Minnich |Like a knife through Daddy's heart: rminnich@sarnoff.com |"Don't make fun of Windows, daddy! It takes care (609)-734-3120 | of all my files and it's reliable and I like it". From owner-freebsd-hackers Fri Oct 27 13:53:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20117 for hackers-outgoing; Fri, 27 Oct 1995 13:53:32 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20098 ; Fri, 27 Oct 1995 13:53:20 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id TAA16204; Fri, 27 Oct 1995 19:04:27 GMT Date: Fri, 27 Oct 1995 19:04:26 +0000 () From: Sergio Lenzi To: questions@freebsd.org cc: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hello, I am trying to build a boot (install floppy) from an 2.0.5 release that has atapi ide cdrom Questions: Where can I find doc on how to make a release? What command (make boot.flp RELEASEDIR=/usr/release)? this command replys "cannot find builtins.c". Help..... Lenzi. From owner-freebsd-hackers Fri Oct 27 14:00:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA20602 for hackers-outgoing; Fri, 27 Oct 1995 14:00:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA20596 for ; Fri, 27 Oct 1995 14:00:49 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23967; Fri, 27 Oct 1995 13:51:26 -0700 From: Terry Lambert Message-Id: <199510272051.NAA23967@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Fri, 27 Oct 1995 13:51:26 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <9510272033.AA23654@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 27, 95 04:33:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1315 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > But this implies that if there is not a prototype in scope, a function > > that uses a type that is not correct without a prototype in scope should > > not generate a bogus call reference. > > Not at all. IT IS THE CALLER'S RESPONSIBILITY TO PASS THE CORRECT > TYPES AND ALWAYS HAS BEEN. THEN PROTOTYPES SHOULD WARN AND NEVER COERCE. > In particular, it is incorrect to call lseek() with a `where' argument > of any type other than `off_t', and if a prototype is not in scope, > the the programmer damn well better use a cast to ensure that the > correct type is being used. I agree, although I believe definine off_t as quad to be illegal. > > That's an evil way to pass arguments, then. 8-(. > > That's a fast way to pass arguments on a slow architecture. If you > don't like it, tough, because I /know/ that there are compilers out > there that do this, or something nearly like it. (And don't forget > the SPARC, where under Sun's compiler all aggregates are passed by > hidden reference.) Sun is, at least, consistent. You can predict without knowledge of the compiler or the particular call stub implementation what the arguments should be in assembler. 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 Oct 27 14:18:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21587 for hackers-outgoing; Fri, 27 Oct 1995 14:18:19 -0700 Received: from freebie.polstra.com (freebie.polstra.com [198.211.214.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA21575 for ; Fri, 27 Oct 1995 14:18:12 -0700 Received: from freebie.polstra.com (jdp@localhost) by freebie.polstra.com (8.6.11/8.6.9) with ESMTP id OAA07337 for ; Fri, 27 Oct 1995 14:18:03 -0700 Message-Id: <199510272118.OAA07337@freebie.polstra.com> X-Mailer: exmh version 1.6.4 10/10/95 To: freebsd-hackers@freebsd.org Subject: What does MAP_COPY do? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Oct 1995 14:18:02 -0700 From: John Polstra Sender: owner-hackers@freebsd.org Precedence: bulk Could somebody please explain to me what mmap(2) does when the flag MAP_COPY is passed to it? The only documentation I can find is a comment in /usr/include/sys/mman.h: #define MAP_COPY 0x0004 /* "copy" region at mmap time */ It sounds like this means that a private copy is immediately made of the region. I.e., if two processes map the same file, each with MAP_COPY, they will get completely separate copies of the data. Is that right? Is the actual data copied, or just the page table entries? The only reason I can think of that this behavior would be desired would be as a work-around for a non-working copy-on-write implementation. Is that what it's for? Thanks -- enquiring minds gotta know. -- 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 Fri Oct 27 15:00:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24543 for hackers-outgoing; Fri, 27 Oct 1995 15:00:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24535 for ; Fri, 27 Oct 1995 15:00:09 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA29637; Sat, 28 Oct 1995 07:57:34 +1000 Date: Sat, 28 Oct 1995 07:57:34 +1000 From: Bruce Evans Message-Id: <199510272157.HAA29637@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >> All #pragmas are unportable. >All packing assumptions are unportable. I argue that a #pragma beats >the __attrib crap because a compiler may ignore it. A compiler may exec /usr/games/hack to handle every pragma. gcc used to do this. >> path = *(char const *)((char *)argp + PATH_OFFSET); >> flags = *(int *)((char *)argp + FLAGS_OFFSET); >> mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); >Forgive me... but this is butt-ugly. I mean really, *really* butt-ugly. >I find this horribly obfucated. This is exactly what I feared when I >objected. 8-(. It's machine generated. It looks better than va_arg(). Don't look at it. >BTW: the 'path' line is broken... "*(const char **)", maybe? Oops. >Since the stack variable assigns are based on an entry argument, then >the assignments can be done at declaration time. Therefore something >like: >#define ARG(argtype,arg) \ > argtype arg = *(__CONCAT(argtype,*))((char *)argp + \ > __CONCAT(arg,_OFFSET)); Assignment at declaration time is consider bad style by the 4.4lite2 style guide and by me. The offsets would actually be literal numbers. They are too hard to create using macros. >I don't understand why passing a bogus mode to open when O_CREAT wasn't >present would be a problem??? >That is, why not: >> int syscall_entry_open(struct proc *p, void *argp, int *retval) >> { >> ARG( char const *, PATH); >> ARG( int, FLAGS); >> ARG( promoted_mode_t, MODE); >> >> return open(p, retval, PATH, FLAGS, MODE); >> } The last ARG() might cause a fatal trap if the arg doesn't exist. It might be worth guaranteeing that argp points to a safe place to ARG() can't trap here. But then the caller might have to do more work to provide a safe place or recover from the trap. This is currently handled very efficiently by copyin() recovering from traps if the user doesn't supply enough args. >Hell: >#define SYSCALL_ENTRY(function) \ > int __CONCAT(syscall_entry_,function) \ > (struct proc *p, void *argp, int *retval) >> SYSCALL_ENTRY(open) >> { >> ARG( char const *, PATH); >> ARG( int, FLAGS); >> ARG( promoted_mode_t, MODE); >> >> return open(p, retval, PATH, FLAGS, MODE); >> } This would require large table of #defines of OFFSETs. I prefer to use literal offsets. >I know the XDR aspects re structure packing are an issue, though since >you seem to be assuming the same compiler source everywhere (GCC), No, the OFFSETs depend on the compiler. I assumed the same endianness in my example, but endianness changes can be handled by more complicated ARG() code. Pointer alignment for *(foo_t *) is unlikely to be a problem because the args are usually laid out so that they can be accessed. >I don't see where a packing paragma would be more of an issue than >any other approach requiring compiler modifications. It would take about the same work to machine-generate all the pragmas and padding as to machine-generate all the offsets, e.g., #pragma pack(0) /* or whatever stops all packing */ struct read_args { char const *path; int flags; char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ mode_t mode; char pad2[6]; }; vs. #define read_path_OFFSET 0 #define read_path_type char const * #define read_flags_OFFSET 8 #define read_flags_type int #define read_mode_OFFSET 16 #define read_mode_type mode_t >> The register passing mechanism for syscalls is a side issue. I only >> mentioned it as an example of an ABI that we have to emulate (for Linux) >> and which is better so we should use it. There would be no new >> complications (except for improvements) because we already support the >> Linux ABI. >I'm glad to see this. I think, though, the rationale for the changes >still hasn't been clarified. `lcall' allow users to trace into syscalls. This can be recovered from but is ugly. Trap gates don't have this problem. NetBSD and Linux already use trap gates for their native system calls and we don't want to be uglier or slower than NetBSD or Linux :-). We need to support trap gates for emulation anyway. If we change to trap gates then we should consider changing other parts of the syscall interface. We don't need to copy NetBSD's or Linux's interface except for emulation. >This was my point on the quad crap and reverting the default interfaces >to POSIX compliance (and double doesn't count unless you can use it >without a prototype in scope). if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) perror("lseek"); works without a prototype in scope even if off_t is quad or double. >> syscall() is written in C, so the compiler can pass args to it anywhere it >> wants. syscall() then has the task of putting the args where the kernel >> expects them. In general, it would have to know about all syscalls and >> do the inverse of the conversions that I'm talking about doing in the >> kernel. >Bletch. How does Linux deal with it (my linux box is running Win95 >right now)? i386's are enough like vaxes and gcc uses stupid enough function call conventions for there to be no problems. Just put the first arg in the first register, etc. >> Consider a 68K compiler that passes the first 2 pointer args (if any) >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other >> args on the stack. How are you going to push the args in syscall()? >> Hint: you'll need to know the arg types of all syscalls. >That's an evil way to pass arguments, then. 8-(. But not stupid :-). >> It's worse than that. Linux doesn't have quads. Applications have to use >> pairs of longs and do their own (equivalent to quad) arithmetic on them. >> So ifdefs like the above all through the code might be necessary. >Linux has GCC. Linux has quads. I thought it doesn't use them for llseek. I guess it doesn't matter. Two longs together look like a quad. Bruce From owner-freebsd-hackers Fri Oct 27 15:46:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA27731 for hackers-outgoing; Fri, 27 Oct 1995 15:46:30 -0700 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA27726 for ; Fri, 27 Oct 1995 15:46:27 -0700 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id RAA02523; Fri, 27 Oct 1995 17:46:23 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 17:46:24 -0500 To: hackers@FreeBSD.ORG From: rkw@dataplex.net (Richard Wackerbarth) Subject: 2.1.0-951026-SNAP still fails on 4meg system Cc: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk At 1:21 PM 10/27/95, Jordan K. Hubbard wrote: >This snapshot also tries again to address the IDE CDROM and 4MB issues >(the features that wouldn't die! :). > >Please send me ANY success/fail reports you may have with either >4MB configurations or the atapi.flp boot image with IDE CDROM drives. boot.flp 386 640k/3072k memory fd0, fd1, wd0, ed1 Although it takes forever the uncompress the kernel, the probes seemed to work properly. The system announces that the rootfs is 1000K compile in MFS. THere is another pause.... Trap 12 Page fault in kernel instruction pointer = 0x8:0xf018c56d panic: page fault syncing disks... done Automatic reboot [...] Sorry :-( ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-hackers Fri Oct 27 17:00:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00345 for hackers-outgoing; Fri, 27 Oct 1995 17:00:47 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00331 for ; Fri, 27 Oct 1995 17:00:36 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA24249; Fri, 27 Oct 1995 16:50:51 -0700 From: Terry Lambert Message-Id: <199510272350.QAA24249@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 16:50:50 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510272157.HAA29637@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 07:57:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5255 Sender: owner-hackers@freebsd.org Precedence: bulk > >> All #pragmas are unportable. > > >All packing assumptions are unportable. I argue that a #pragma beats > >the __attrib crap because a compiler may ignore it. > > A compiler may exec /usr/games/hack to handle every pragma. gcc used > to do this. It doesn't any more. Stahlman did this to be an ass. > >I don't understand why passing a bogus mode to open when O_CREAT wasn't > >present would be a problem??? > > >That is, why not: > > >> int syscall_entry_open(struct proc *p, void *argp, int *retval) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > The last ARG() might cause a fatal trap if the arg doesn't exist. It > might be worth guaranteeing that argp points to a safe place to ARG() > can't trap here. But then the caller might have to do more work to > provide a safe place or recover from the trap. This is currently > handled very efficiently by copyin() recovering from traps if the user > doesn't supply enough args. Hence, my use of the 0 argument on the open in user space in the last posting to provide a valid call on vararg. The open(2) call is not a traditional vararg -- it's a limited one. The "..." in its case means "0 or one argument here" instead of "0 or n arguments here". I don't know of a real vararg system call. > >> SYSCALL_ENTRY(open) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > This would require large table of #defines of OFFSETs. I prefer to use > literal offsets. Keep all paths at the same offset, etc. > > >I know the XDR aspects re structure packing are an issue, though since > >you seem to be assuming the same compiler source everywhere (GCC), > > No, the OFFSETs depend on the compiler. I assumed the same endianness > in my example, but endianness changes can be handled by more complicated > ARG() code. Pointer alignment for *(foo_t *) is unlikely to be a problem > because the args are usually laid out so that they can be accessed. Yeah. Only makes sense. Actually, MSC doesn't align stuff correctly. They (Microsoft) pad many things to even alignment boundries, but structure contents themselves are tightly packed. One ABI to consider is WINE. > >I don't see where a packing paragma would be more of an issue than > >any other approach requiring compiler modifications. > > It would take about the same work to machine-generate all the pragmas > and padding as to machine-generate all the offsets, e.g., > > #pragma pack(0) /* or whatever stops all packing */ > struct read_args { > char const *path; > int flags; > char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ > mode_t mode; > char pad2[6]; > }; That would be better expressed as: > #pragma pack(8) /* quad stack alignment, pointers are quads*/ > struct read_args { > char const *path; > int flags; > mode_t mode; > }; [ ... ] > >I'm glad to see this. I think, though, the rationale for the changes > >still hasn't been clarified. > > `lcall' allow users to trace into syscalls. This can be recovered from > but is ugly. Trap gates don't have this problem. NetBSD and Linux > already use trap gates for their native system calls and we don't want > to be uglier or slower than NetBSD or Linux :-). We need to support > trap gates for emulation anyway. If we change to trap gates then we > should consider changing other parts of the syscall interface. We don't > need to copy NetBSD's or Linux's interface except for emulation. I understand the rationale for considering the changes. I don't understand the rationale for making them. It seems the rationale is "to compete with NetBSD and Linux regarding speed". Is this correct? I personally don't find that compelling (that's not to say that the majority doesn't outweigh me on this -- only that it does not convince me, personally). > >This was my point on the quad crap and reverting the default interfaces > >to POSIX compliance (and double doesn't count unless you can use it > >without a prototype in scope). > > if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) > perror("lseek"); > > works without a prototype in scope even if off_t is quad or double. But violates POSIX (in the quad case) or the spirit of POSIX (in the double case -- you yourself suggested that this is probably an error in the spec). > >> Consider a 68K compiler that passes the first 2 pointer args (if any) > >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other > >> args on the stack. How are you going to push the args in syscall()? > >> Hint: you'll need to know the arg types of all syscalls. > > >That's an evil way to pass arguments, then. 8-(. > > But not stupid :-). OK. I admit it's probably minisculely faster. Is it worth the clutter of the xxx_OFFSET and the xxx_type and the unreadable glue routines to get that miniscule speed "improvement"? Just my opinion, but I think the answer is "no". 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 Oct 27 17:03:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00474 for hackers-outgoing; Fri, 27 Oct 1995 17:03:11 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00448 for ; Fri, 27 Oct 1995 17:02:46 -0700 Received: from uucp4.UU.NET by relay5.UU.NET with SMTP id QQznie02494; Fri, 27 Oct 1995 20:02:19 -0400 (EDT) Received: from uanet.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Fri, 27 Oct 1995 20:02:19 -0400 Received: by crocodil.monolit.kiev.ua; Sat, 28 Oct 95 01:36:02 +0200 Received: from dog.farm.org (farm-cs.farm.org [193.124.48.230]) by clipper.cs.kiev.ua (8.6.4) with ESMTP id BAA01741; Sat, 28 Oct 1995 01:29:33 +0200 Received: (from dk@localhost) by dog.farm.org (MK54/dk1) id BAA00989; Sat, 28 Oct 1995 01:31:18 +0200 From: Dmitry Kohmanyuk Message-Id: <199510272331.BAA00989@dog.farm.org> Subject: Re: patch for PTYs not freed? (2.0.5-R) (screen problem) To: malenovi@cview.com (Nik Malenovic) Date: Fri, 27 Oct 1995 23:31:16 +0000 () Cc: freebsd-hackers@freebsd.org, screen@uni-erlangen.de In-Reply-To: from "Nik Malenovic" at Oct 27, 95 02:48:00 pm Reply-To: dk+@ua.net X-Class: Fast X-OS-Of-Choice: FreeBSD 2.0.5-RELEASE X-NIC-Handle: DK379 X-Mailer: ELM [version 2.4 PL22 dk9] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Quoting Nik Malenovic: > blah. you are lucky - I can't even get screen to work on ANY of my boxes. > all the way since 1.5.1 - I am having this darn problem - screen hangs. > I know people had complained about it - but no one ever offered a fix. > I tried to debug it - and the problem was that the master process was > dying and spawned processes would just bomb out. WHY the master process > was dying? no clue. anyway - if anyone has any clues... please let me know! :) screen is working for me now after I have applied the following patch (version 3.6.2, FreeBSD 2.0.5): --- process.c.orig Tue Sep 12 19:30:14 1995 +++ process.c Tue Sep 12 19:31:47 1995 @@ -149,8 +149,9 @@ extern char *multi; #endif #ifdef PASSWORD +#include int CheckPassword; -char Password[30]; +char Password[_PASSWORD_LEN]; #endif struct plop plop_tab[MAX_PLOP_DEFS]; CREDIT >>>>> thanks to "Tam T. Lien" for discovering this. <<<<< the problem is, when using MD5-based security, encrypted passwords are longer than 30 chars (about 35 chars in my machine) and memory gets overwritten. on my box, this have cured the problem of screen freezing on startup. p.s. I consider the screen the most essensial for me utility (not counting tcsh and vim, of course ;-)) thanks do all the developers and maintainers! From owner-freebsd-hackers Fri Oct 27 17:09:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00705 for hackers-outgoing; Fri, 27 Oct 1995 17:09:24 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00686 ; Fri, 27 Oct 1995 17:09:20 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id RAA03189; Fri, 27 Oct 1995 17:09:12 -0700 From: Julian Elischer Message-Id: <199510280009.RAA03189@ref.tfs.com> Subject: Re: Come and get it! 2.1.0-951026-SNAP is released! To: hackers@freebsd.org Date: Fri, 27 Oct 1995 17:09:11 -0700 (PDT) Cc: announce@freebsd.org In-Reply-To: <10818.814818195@time.cdrom.com> from "Jordan K. Hubbard" at Oct 27, 95 11:23:15 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 204 Sender: owner-hackers@freebsd.org Precedence: bulk > the documentation were made. Forget what I said about the last > snapshot being the release candidate - THIS is the release candidate! > :-) Oh it was a candidate alright, but nobody voted for it... From owner-freebsd-hackers Fri Oct 27 17:16:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01061 for hackers-outgoing; Fri, 27 Oct 1995 17:16:06 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA01054 for ; Fri, 27 Oct 1995 17:16:00 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id RAA15750; Fri, 27 Oct 1995 17:15:58 -0700 Date: Fri, 27 Oct 1995 17:15:58 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Anybody using ftp groups with the wu ftpd compiled for freeBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I always get an invalid password, although I've stuffed it in the groups file a kazillion times. Same setup (modulo a DES password rather than crypt) works fine under BSD/OS, so I'm starting to think maybe it's got something to do with the MD5 stuff... From owner-freebsd-hackers Fri Oct 27 17:45:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA02135 for hackers-outgoing; Fri, 27 Oct 1995 17:45:29 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA02130 for ; Fri, 27 Oct 1995 17:45:26 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA12052; Fri, 27 Oct 1995 17:44:37 -0700 To: rkw@dataplex.net (Richard Wackerbarth) cc: hackers@FreeBSD.ORG Subject: Re: 2.1.0-951026-SNAP still fails on 4meg system In-reply-to: Your message of "Fri, 27 Oct 1995 17:46:24 CDT." Date: Fri, 27 Oct 1995 17:44:37 -0700 Message-ID: <12049.814841077@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Although it takes forever the uncompress the kernel, the probes seemed to > work properly. > The system announces that the rootfs is 1000K compile in MFS. > THere is another pause.... > Trap 12 Page fault in kernel > instruction pointer = 0x8:0xf018c56d > > panic: page fault > syncing disks... done > Automatic reboot [...] > > Sorry :-( Ah well! We tried. Folks, you heard the man: 5MB it still is! Jordan From owner-freebsd-hackers Fri Oct 27 19:21:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05307 for hackers-outgoing; Fri, 27 Oct 1995 19:21:42 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05295 for ; Fri, 27 Oct 1995 19:21:37 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id TAA03378 for hackers@freebsd.org; Fri, 27 Oct 1995 19:21:28 -0700 Date: Fri, 27 Oct 1995 19:21:28 -0700 From: Julian Elischer Message-Id: <199510280221.TAA03378@ref.tfs.com> To: hackers@freebsd.org Subject: lkms break on make world.. Sender: owner-hackers@freebsd.org Precedence: bulk ===> secure/usr.bin/bdes ===> lkm ===> lkm/cd9660 ===> lkm/coff ld -r -o tmp.o coff.o imgact_coff.o symorder -c symb.tmp tmp.o symorder: 1 symbol not found: _ibcs2_coff_mod *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Is there something I need to do? I've done a make world and just to be sure, a make instal followed by another make, but it still bombs.. I saw a mention of lkms bombing recently.. anyone get a resolution? julian From owner-freebsd-hackers Fri Oct 27 19:52:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06471 for hackers-outgoing; Fri, 27 Oct 1995 19:52:05 -0700 Received: from psychotic.communica.com.au (root@gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06459 for ; Fri, 27 Oct 1995 19:51:46 -0700 Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id MAA18561; Sat, 28 Oct 1995 12:21:33 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA29408; Sat, 28 Oct 95 12:21:30 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9510280251.AA29408@communica.com.au> Subject: Re: A few questions.. To: lenzi@cwbone.bsi.com.br (Sergio Lenzi) Date: Sat, 28 Oct 1995 12:21:30 +0930 (CST) Cc: hackers@FreeBSD.org In-Reply-To: from "Sergio Lenzi" at Oct 26, 95 01:24:02 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 4587 Sender: owner-hackers@FreeBSD.org Precedence: bulk Sergio Lenzi wrote: > I use this kind of thing (ppp and slip) here. I have a solution using user-mode PPP here. cleese.apana.org.au is a public access UNIX which offers dialup PPP to its subscribers. Some PPP accounts have their addresses dynamically assigned for each dialup session, some of them have static addresses which they always get (so that, for example, the PPP user can have MX records and the like pointing directly at him). > I put "options GATEWAY" in the conf file Blurgh; "sysctl -w net.inet.ip.forwarding=1" at boot time. > run routed with options -s Don't need that; just a static default route to my IP provider. > When a user logs_in it starts an awk program > that given a tty it returns an ip. Novel. I have a PPP login shell that I'll include at the end of this message. Basically, the hostname of the dialing-in site is coded into argv[0], unless argv[0] is "ppp-dialup", in which case the script works out which tty you're on (ie: behaves as if it was called as "ppp-ttyd1" if a user logs in on ttyd1). Each PPP user has a logni shell of the form "ppp-token", which is a symlink back to ppp-shell. ppp-shell is where all the smart stuff is. The login shell script ends up calling "/usr/sbin/ppp -direct token", where "token" is the bit after the hyphen in $0, or the tty name if $0 is ppp-dialup. My /etc/ppp/ppp.conf file has entries like this: ttyd4: set ifaddr 203.14.159.10 203.14.159.161 set debug phase enable proxy set timeout 900 smokey: set ifaddr 203.14.159.10 203.14.159.148 set debug phase enable proxy set timeout 900 The first one would be used if a PPP user was on ttyd4; it assigns 203.14.159.161 as the address for the remote end. The "enable proxy" command turns on proxy ARP, so routed is unnecessary. The second entry is used for when smokey.apana.org.au dials in; it gives him his own IP address, so he doesn't get it dynamically assigned to him. Result: My ppp.conf has four "tty" entries for dynamic IPs (one for each dialup modem) and a collection of hostname entries. I get to use the same login shell for all of them regardless of whether they're static or dynamic. My PPP users have accounts like this: newton@cleese> finger Psmokey Login: Psmokey Name: smokey.apana.org.au Directory: /u/noacct Shell: /etc/ppp/ppp-smokey Last login Sat Oct 28 10:07 (CST) on ttyd2 No Mail. No Plan. ... with /etc/ppp/ppp-smokey being a symlink to /etc/ppp/ppp-shell (included at the end of this message). Dynamic PPP accounts are the same, 'cept they use /etc/ppp/ppp-dialup as a shell (which is, again, a symlink to /etc/ppp/ppp-shell). - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au #!/bin/sh - ## ## Copyright (c) 1995 Mark Newton ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted provided that the following conditions ## are met: ## 1. Redistributions of source code must retain the above copyright ## notice, this list of conditions and the following disclaimer. ## 2. Redistributions in binary form must reproduce the above copyright ## notice, this list of conditions and the following disclaimer in the ## documentation and/or other materials provided with the distribution. ## ## THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ## ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE ## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ## ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE ## FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL ## DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS ## OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ## HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT ## LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY ## OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF ## SUCH DAMAGE. ## ## @(#)ppp-shell.sh 1.03 951019 newton@cleese.apana.org.au ## IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" echo "~~~~~~~~~~~~~~~~~~~~~~~~~" exec /usr/sbin/ppp -direct $IDENT From owner-freebsd-hackers Fri Oct 27 19:52:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06502 for hackers-outgoing; Fri, 27 Oct 1995 19:52:24 -0700 Received: from nike.efn.org (garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06479 for ; Fri, 27 Oct 1995 19:52:13 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id TAA12872; Fri, 27 Oct 1995 19:55:21 -0700 Date: Fri, 27 Oct 1995 19:55:17 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: hackers@freebsd.org Subject: 951026-SNAP and 4megs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk well... I just thought you guys would like to know... I pulled 4megs of ram out of a 8meg machine to test it... even though I read the message about it failing on his machine... and it worked on my machine... right now I am testing it on my laptop and it reports 639/3328k... and the install screen came up... so it looks like 4meg does work... John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Fri Oct 27 20:13:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07396 for hackers-outgoing; Fri, 27 Oct 1995 20:13:29 -0700 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07381 for ; Fri, 27 Oct 1995 20:13:12 -0700 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id WAA03372; Fri, 27 Oct 1995 22:12:27 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 22:12:29 -0500 To: John-Mark Gurney From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: 951026-SNAP and 4megs Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk At 9:55 PM 10/27/95, John-Mark Gurney wrote: >well... I just thought you guys would like to know... I pulled 4megs of >ram out of a 8meg machine to test it... even though I read the message >about it failing on his machine... and it worked on my machine... right >now I am testing it on my laptop and it reports 639/3328k... and the >install screen came up... so it looks like 4meg does work... Some do, some don't. We appear to be right near the edge. Mine has only 3027k available because of "shadow" ram that does not get used by FreeBSD. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-hackers Fri Oct 27 20:56:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09054 for hackers-outgoing; Fri, 27 Oct 1995 20:56:23 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09045 for ; Fri, 27 Oct 1995 20:56:17 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id UAA12660; Fri, 27 Oct 1995 20:55:24 -0700 To: John-Mark Gurney cc: hackers@freebsd.org Subject: Re: 951026-SNAP and 4megs In-reply-to: Your message of "Fri, 27 Oct 1995 19:55:17 PDT." Date: Fri, 27 Oct 1995 20:55:23 -0700 Message-ID: <12658.814852523@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > well... I just thought you guys would like to know... I pulled 4megs of > ram out of a 8meg machine to test it... even though I read the message > about it failing on his machine... and it worked on my machine... right > now I am testing it on my laptop and it reports 639/3328k... and the > install screen came up... so it looks like 4meg does work... Huh! Great.. So now I can tell people: "It *might* work in 4MB." Why couldn't it have just fallen over on your machine, like everyone else's? :-) Thanks for the report. Jordan From owner-freebsd-hackers Fri Oct 27 21:52:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA12485 for hackers-outgoing; Fri, 27 Oct 1995 21:52:57 -0700 Received: from shzkgw.cs.inf.shizuoka.ac.jp (shzkgw.cs.inf.shizuoka.ac.jp [133.70.169.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA12480 for ; Fri, 27 Oct 1995 21:52:52 -0700 Received: from rhinoceros.cs.inf.shizuoka.ac.jp (rhinoceros.cs.inf.shizuoka.ac.jp [133.70.170.94]) by shzkgw.cs.inf.shizuoka.ac.jp (8.6.12/3.3Wb-shzkgw2) with ESMTP id NAA16486; Sat, 28 Oct 1995 13:51:27 +0900 Received: (from purna@localhost) by rhinoceros.cs.inf.shizuoka.ac.jp (8.7/rhino-sunos4) id NAA08873; Sat, 28 Oct 1995 13:51:25 +0900 (JST) Date: Sat, 28 Oct 1995 13:51:25 +0900 (JST) From: Yusuf Wilajati Purna Message-Id: <199510280451.NAA08873@rhinoceros.cs.inf.shizuoka.ac.jp> To: dima@escape.com, hackers@freebsd.org Subject: Re: Netscape Sender: owner-hackers@freebsd.org Precedence: bulk > Hello, I've got some problems with Netscape > when I start it, what I am getting is > Warning: ... found while parsing 'c > osfPageDown:PageDownOrRight(1)' > ... > ... > and my keyboard doesnt work. what exactly should I do? > > Dima. Have you already put the 'XKeysymDB' (included in the distribution) in the appropriate directory (e.g., /usr/lib/X11)? If not, try doing it and run Netscape again. Regards, YWP (purna@cs.inf.shizuoka.ac.jp) From owner-freebsd-hackers Fri Oct 27 22:51:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15168 for hackers-outgoing; Fri, 27 Oct 1995 22:51:22 -0700 Received: from nike.efn.org (garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15163 for ; Fri, 27 Oct 1995 22:51:18 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id WAA13404; Fri, 27 Oct 1995 22:11:31 -0700 Date: Fri, 27 Oct 1995 22:11:29 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: 951026-SNAP and 4megs In-Reply-To: <12658.814852523@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Fri, 27 Oct 1995, Jordan K. Hubbard wrote: > > well... I just thought you guys would like to know... I pulled 4megs of > > ram out of a 8meg machine to test it... even though I read the message > > about it failing on his machine... and it worked on my machine... right > > now I am testing it on my laptop and it reports 639/3328k... and the > > install screen came up... so it looks like 4meg does work... > > Huh! Great.. So now I can tell people: "It *might* work in 4MB." > Why couldn't it have just fallen over on your machine, like everyone > else's? :-) sorry :)... also... on my 8meg machine the ram reported was 640/3456k... just for the record... also... we could say just disable the shadow ram for install and then reable it after... > Thanks for the report. no problem.. John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Fri Oct 27 23:27:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16803 for hackers-outgoing; Fri, 27 Oct 1995 23:27:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16775 for ; Fri, 27 Oct 1995 23:27:13 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA16949; Sat, 28 Oct 1995 16:12:09 +1000 Date: Sat, 28 Oct 1995 16:12:09 +1000 From: Bruce Evans Message-Id: <199510280612.QAA16949@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-hackers@freebsd.org Precedence: bulk >> >I don't understand why passing a bogus mode to open when O_CREAT wasn't >> >present would be a problem??? >... >Hence, my use of the 0 argument on the open in user space in the last >posting to provide a valid call on vararg. The open(2) call is not The difficulty is to extract the 3rd arg if it exists. >a traditional vararg -- it's a limited one. The "..." in its case >means "0 or one argument here" instead of "0 or n arguments here". This only reduces the difficulty. In general you might have to decode all previous args to decide how to extract eacg arg. >I don't know of a real vararg system call. Grepping for \.\.\. in shows the following: open, fcntl, ioctl, msgsys, semsys, shmsys. The last 3 have more than one varargs arg. >> >> SYSCALL_ENTRY(open) >> >> { >> >> ARG( char const *, PATH); >> >> ARG( int, FLAGS); >> >> ARG( promoted_mode_t, MODE); >> >> >> >> return open(p, retval, PATH, FLAGS, MODE); >> >> } >> >> This would require large table of #defines of OFFSETs. I prefer to use >> literal offsets. >Keep all paths at the same offset, etc. You can't. The offsets depend on the ABI. In particular they depend on the word size and endianness even if the packing is the natural one. >Actually, MSC doesn't align stuff correctly. They (Microsoft) pad many >things to even alignment boundries, but structure contents themselves >are tightly packed. This is probably inherited from 16-bit packing and calling conventions. >> #pragma pack(0) /* or whatever stops all packing */ >> struct read_args { >> char const *path; >> int flags; >> char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ >> mode_t mode; >> char pad2[6]; >> }; >That would be better expressed as: >> #pragma pack(8) /* quad stack alignment, pointers are quads*/ >> struct read_args { >> char const *path; >> int flags; >> mode_t mode; >> }; gcc-2.6 only supports pack(1)..pack(4) - the natural padding can't be increased. Note that it need may need to be increased to support a foreign ABI, and it isn't even natural on Pentiums (doubles should have 8 byte alignment). #pragma is unportable. My version has the advantage of requiring only 1 pragma per struct, while yours requires up to one pragma per struct member and it may still require padding. Consider alignment of 4-byte quantities on boundaries 4, 9, 16, 25, ... >> `lcall' allow users to trace into syscalls. This can be recovered from >I understand the rationale for considering the changes. I don't understand >the rationale for making them. It seems the rationale is "to compete with >NetBSD and Linux regarding speed". Is this correct? To compete in speed and elegance. >> >This was my point on the quad crap and reverting the default interfaces >> >to POSIX compliance (and double doesn't count unless you can use it >> >without a prototype in scope). >> >> if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) >> perror("lseek"); >> >> works without a prototype in scope even if off_t is quad or double. >But violates POSIX (in the quad case) or the spirit of POSIX (in the >double case -- you yourself suggested that this is probably an error >in the spec). Doesn't matter. The call and check must be written something like the above so that it works independent of the type of off_t even if off_t is one of char, short, int or long. Actually if foo is a variable then it should have type off_t, and the cast of -1 is unnecessary because off_t is _signed_ arithmetic, so the statement should normally be written as if (lseek(fd, foo, SEEK_SET) == -1) perror("lseek"); >> >> Consider a 68K compiler that passes the first 2 pointer args (if any) >> >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other >> ... >> But not stupid :-). >OK. I admit it's probably minisculely faster. Is it worth the clutter >of the xxx_OFFSET and the xxx_type and the unreadable glue routines to >get that miniscule speed "improvement"? If it is the compiler or ABI's calling convention, then you have no choice. Bruce From owner-freebsd-hackers Fri Oct 27 23:58:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA18252 for hackers-outgoing; Fri, 27 Oct 1995 23:58:59 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA18247 for ; Fri, 27 Oct 1995 23:58:57 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id XAA01126; Fri, 27 Oct 1995 23:58:46 -0700 Message-Id: <199510280658.XAA01126@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Ron G. Minnich" cc: hackers@freebsd.org Subject: Re: David Sarnoff Research Center Clusters Page In-reply-to: Your message of "Fri, 27 Oct 1995 16:45:53 EDT." <9510272045.AA02600@section05> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Oct 1995 23:58:45 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Must cool system !! I think it would be cool if you could create an mpeg movie of the Daemon landing on the Moon 8) Regards, Amancio >>> "Ron G. Minnich" said: > Folks: i'm in the process of reviving my old clusters home page. Since the n ew > one describes the new FreeBSD-based cluster here at Sarnoff I thought you wo uld > be interested. I'd appreciate any comments you have as well. Thanks! > > > ftp://www.sarnoff.com/pub/mnfs/www/cgi-bin/cluster.html > > -- > Ron Minnich |Like a knife through Daddy's heart: > rminnich@sarnoff.com |"Don't make fun of Windows, daddy! It takes care > (609)-734-3120 | of all my files and it's reliable and I like it ". > > > From owner-freebsd-hackers Sat Oct 28 00:00:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18322 for hackers-outgoing; Sat, 28 Oct 1995 00:00:15 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18317 for ; Sat, 28 Oct 1995 00:00:13 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id AAA01160; Sat, 28 Oct 1995 00:00:07 -0700 Message-Id: <199510280700.AAA01160@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: "Ron G. Minnich" cc: hackers@freebsd.org Subject: Re: David Sarnoff Research Center Clusters Page In-reply-to: Your message of "Fri, 27 Oct 1995 16:45:53 EDT." <9510272045.AA02600@section05> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 00:00:06 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Sorry to post again on this subject ... I forgot to ask how viable is such a system as a scalable Web Server or NFS server for lets say an ISP? Tnks! Amancio From owner-freebsd-hackers Sat Oct 28 00:06:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18603 for hackers-outgoing; Sat, 28 Oct 1995 00:06:26 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18598 for ; Sat, 28 Oct 1995 00:06:22 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id AAA01197; Sat, 28 Oct 1995 00:05:58 -0700 Message-Id: <199510280705.AAA01197@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: rcarter@geli.com (Russell L. Carter), jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Fri, 27 Oct 1995 12:03:47 PDT." <199510271903.MAA23671@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 00:05:58 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I am a bit a lost here . What is the big deal with having a network object server whose target objects are replicated in a network? Oh, don't know there has been quite a number of papers, architectures, and also CORBA comes to mind not to mentioned decnet's remote distributed object architecture, etc... Cheers, Amancio >>> Terry Lambert said: > > So here is a market opportunity: how do you scale a bunch of > > httpd servers working in concert (maybe like timed?) so that when one > > goes down, the remainders elect a master and life goes on? > > #ifdef TERRY_IN_FUTURIST_MODE > > You connect to services instead of machines, of course, and the > underlying transport is permitted to load balance you off onto > another server. Boy isn't this very similar to Novell's service schemes except that I don't think that Novell provides for load balancing but then again that is probably not to hard to implement if you can agree on the metrics... > I coined the term "server anonymity" for this four years ago. > > The problem is in the protocols... they are server connection > rather than service connection oriented. > > Consider: do I really give a damn where the next 512 frames of my > "Raiders of the Lost Ark" come from, as long as they get to me? I > really want to be able to ask for them and not care *who* sends > them to me, as long as *someone* does. > > The next step after the implementation of "server anonymity" is > implementation of "content addressable networking". > > Domain proximity is also what dictates network path congestion > probability. The higher the proximity, the lower the probability. > > At that point, the service that gets charged for is data vaulting > and service replication level. If I release a movie into this type > of system, my ability to deliver it to 'N' people is based on how > many places the service exists. So my costs are based on the number > of vaulting locations I rent and their domain proximity (in hops) > to the people who want the information. > > Obviously, there's a lot of vested interest in the wire companies for > connection/circuit oriented delivery systems. That's because everyone > has been killing each other and themselves to sell you the wire into > your house on the expectation that they will be able to meter your > usage and charge accordingly. > > On the other side of the coin are the people who want to deluge you > with "junk email", which you'll refuse to pay metered rates for. > After all, you're not stupid. You've paid air-time for unsolicited > cell phone calls, and you know that metering fails under those > conditions. > > Turns out the real money is going to be in vaulting (distribution) > and production of content. > > (BTW, I want credit for this if you repeat it or use it. 8-).) > > #endif /* TERRY_IN_FUTURIST_MODE*/ > > > For now, scaling is based on the assumption that session duration > for a series of transactions over a connection to a server will be > statistically normative. > > So you "load balance" by rotoring the machine that gets the actual > connection by setting up a DNS rotor. When the address is requested > for a given machine name, the query is responded to by iterating a > set of hosts such that the load is distributed round-robin. > > Of course, this fails to load balance under caching (which DNS does), > and it fails to load balance under non-homogeneous connection > duration (which humans do), and it fails to load balance under > disparate data served from a single server (which humans also do). > > Basically, it fails to load balance. But it *is* the way things are > currently done, and you do get some marginal increase in capability > from it. > > > > 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 Oct 28 00:11:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18840 for hackers-outgoing; Sat, 28 Oct 1995 00:11:28 -0700 Received: from netcom7.netcom.com (root@netcom7.netcom.com [192.100.81.115]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18831 for ; Sat, 28 Oct 1995 00:11:24 -0700 Received: from netcomsv.netcom.com by netcom7.netcom.com (8.6.12/Netcom) id AAA12586; Sat, 28 Oct 1995 00:09:51 -0700 Message-Id: <199510280709.AAA12586@netcom7.netcom.com> X-Sender: mcstout@netcom.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 1995 00:06:34 -0700 To: hackers@FreeBSD.ORG From: Mark Stout Subject: Re: Anybody using ftp groups with the wu ftpd compiled for freeBSD? Sender: owner-hackers@FreeBSD.ORG Precedence: bulk At 05:15 PM 10/27/95 -0700, you wrote: > > >I always get an invalid password, although I've stuffed it in the groups >file a kazillion times. > >Same setup (modulo a DES password rather than crypt) works fine under BSD/OS, >so I'm starting to think maybe it's got something to do with the MD5 stuff... I'm having no luck setting up restricted ftp access. I want my accounts to ftp into their account and do what they want from there, but that's as far as they go. Their home directory in effect becomes their '/' directory, just /usr/home/ftp becomes the '/' for the anonymous user. I'm using the ftpaccess file and trying to setup 'guestgroups'. However, it fails on me everytime. The anonymous user can log in, but valid users can not. I've done just about everything there is to do and i's not working. For example, here's what I've done: 1. Ensured that the users shell is in /etc/shells and that it's world readable 2. Setup the correct permissions in regards to /ftp/bin, /ftp/etc & /ftp/pub along with the necessary files in /ftp/bin and /ftp/etc. 3. Made sure that the passwd file has the right home directory structure, e.g. /ftp/./user:/bin/ftponly 4. That there is a 'ftp' group and a 'guest' group in /etc/group 5. That the users can login using telnet, which I've restricted in /etc/login.access to all but a few The only thing that I'm thinking can be the problem is the permissions on the ftp directory structure. I'm ioncluding it in this message in the hopes that someone out there can see a problem. total 12 drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ./ drwxr-xr-x 32 root wheel 2048 Oct 24 00:00 ../ drwxr-xr-x 2 asgs guest 512 Oct 26 21:26 asgs/ drwxr-xr-x 2 root ftp 512 Oct 21 11:55 bin/ drwxr-xr-x 2 root ftp 512 Oct 25 12:50 etc/ -rw-r--r-- 1 root wheel 908 Oct 27 00:37 index.html drwxr-xr-x 2 root wheel 512 Oct 21 11:47 lib/ drwxr-xr-x 3 root wheel 512 Oct 26 20:48 pub/ drwxr-xr-x 2 rldc guest 512 Oct 24 23:51 rldc/ drwxr-xr-x 3 root wheel 512 Oct 21 11:48 usr/ /ftp/asgs: total 8 drwxr-xr-x 2 asgs guest 512 Oct 26 21:26 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ /ftp/bin: total 494 drwxr-xr-x 2 root ftp 512 Oct 21 11:55 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ -r-xr-xr-x 1 root wheel 16384 Oct 21 11:55 compress* -r-xr-xr-x 1 root wheel 94208 Oct 21 11:55 gzip* ---x--x--x 1 root wheel 147456 Oct 21 11:54 ls* -r-xr-xr-x 1 root wheel 225280 Oct 21 11:55 tar* /ftp/etc: total 5 drwxr-xr-x 2 root ftp 512 Oct 25 12:50 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ -rwxr-xr-x 1 root ftp 37 Oct 25 13:10 group* -rwxr-xr-x 1 root ftp 396 Oct 27 13:05 passwd* /ftp/lib: total 2 drwxr-xr-x 2 root wheel 512 Oct 21 11:47 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ /ftp/mcs: total 5224 drwxr-xr-x 7 mcs webmast 512 Oct 26 21:27 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ /ftp/pub: total 3 drwxr-xr-x 3 root wheel 512 Oct 26 20:48 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ drwxrwxrwx 2 ftp ftp 512 Oct 27 13:10 incoming/ /ftp/pub/incoming: total 32 drwxrwxrwx 2 ftp ftp 512 Oct 27 13:10 ./ drwxr-xr-x 3 root wheel 512 Oct 26 20:48 ../ /ftp/rldc: total 9 drwxr-xr-x 2 rldc guest 512 Oct 24 23:51 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ /ftp/usr: total 3 drwxr-xr-x 3 root wheel 512 Oct 21 11:48 ./ drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ drwxrwxr-x 2 root wheel 512 Oct 21 11:48 bin/ /ftp/usr/bin: total 2 drwxrwxr-x 2 root wheel 512 Oct 21 11:48 ./ drwxr-xr-x 3 root wheel 512 Oct 21 11:48 ../ ========================================================================== Mark Stout | The Village Potpourri Mall: http://www.vpm.com/ ---------------+---------------------------------------------------------- VPM Enterprises; P.O.Box 6427; Folsom, CA 95763-6427 Commercial Internet Sales, Marketing and Advertising Specialist ========================================================================== From owner-freebsd-hackers Sat Oct 28 04:04:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA02593 for hackers-outgoing; Sat, 28 Oct 1995 04:04:17 -0700 Received: from strider.ibenet.it (root@strider.ibe.net [194.179.130.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA02577 for ; Sat, 28 Oct 1995 04:04:03 -0700 Received: (from piero@localhost) by strider.ibenet.it (8.6.12/8.6.12) id LAA17193; Sat, 28 Oct 1995 11:59:31 +0100 From: Piero Serini Message-Id: <199510281059.LAA17193@strider.ibenet.it> Subject: Re: ftp tree permissions To: mcs@vpm.com (Mark Stout) Date: Sat, 28 Oct 1995 11:59:30 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510280709.AAA12586@netcom7.netcom.com> from "Mark Stout" at Oct 28, 95 00:06:34 am Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-NCC-RegID: it.ibenet X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2909 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hello. Quoting from Mark Stout (Sat Oct 28 08:06:34 1995): > The only thing that I'm thinking can be the problem is the permissions on > the ftp directory structure. I'm ioncluding it in this message in the hopes > that someone out there can see a problem. IMO they should be (corrections on the right): > total 12 > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ./ 555 > drwxr-xr-x 32 root wheel 2048 Oct 24 00:00 ../ > drwxr-xr-x 2 asgs guest 512 Oct 26 21:26 asgs/ > drwxr-xr-x 2 root ftp 512 Oct 21 11:55 bin/ 111 > drwxr-xr-x 2 root ftp 512 Oct 25 12:50 etc/ 111 > -rw-r--r-- 1 root wheel 908 Oct 27 00:37 index.html > drwxr-xr-x 2 root wheel 512 Oct 21 11:47 lib/ 111 > drwxr-xr-x 3 root wheel 512 Oct 26 20:48 pub/ 555 > drwxr-xr-x 2 rldc guest 512 Oct 24 23:51 rldc/ > drwxr-xr-x 3 root wheel 512 Oct 21 11:48 usr/ 111 > > /ftp/asgs: > total 8 > drwxr-xr-x 2 asgs guest 512 Oct 26 21:26 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > > /ftp/bin: > total 494 > drwxr-xr-x 2 root ftp 512 Oct 21 11:55 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > -r-xr-xr-x 1 root wheel 16384 Oct 21 11:55 compress* 111 > -r-xr-xr-x 1 root wheel 94208 Oct 21 11:55 gzip* 111 > ---x--x--x 1 root wheel 147456 Oct 21 11:54 ls* 111 > -r-xr-xr-x 1 root wheel 225280 Oct 21 11:55 tar* 111 > > /ftp/etc: > total 5 > drwxr-xr-x 2 root ftp 512 Oct 25 12:50 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > -rwxr-xr-x 1 root ftp 37 Oct 25 13:10 group* 444 > -rwxr-xr-x 1 root ftp 396 Oct 27 13:05 passwd* 444 > > /ftp/lib: > total 2 > drwxr-xr-x 2 root wheel 512 Oct 21 11:47 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > > /ftp/mcs: > total 5224 > drwxr-xr-x 7 mcs webmast 512 Oct 26 21:27 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > > /ftp/pub: > total 3 > drwxr-xr-x 3 root wheel 512 Oct 26 20:48 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > drwxrwxrwx 2 ftp ftp 512 Oct 27 13:10 incoming/ 333 > > /ftp/pub/incoming: > total 32 > drwxrwxrwx 2 ftp ftp 512 Oct 27 13:10 ./ > drwxr-xr-x 3 root wheel 512 Oct 26 20:48 ../ > > /ftp/rldc: > total 9 > drwxr-xr-x 2 rldc guest 512 Oct 24 23:51 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > > /ftp/usr: > total 3 > drwxr-xr-x 3 root wheel 512 Oct 21 11:48 ./ > drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ > drwxrwxr-x 2 root wheel 512 Oct 21 11:48 bin/ 111 > > /ftp/usr/bin: > total 2 > drwxrwxr-x 2 root wheel 512 Oct 21 11:48 ./ > drwxr-xr-x 3 root wheel 512 Oct 21 11:48 ../ Bye, -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-hackers Sat Oct 28 05:01:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA06449 for hackers-outgoing; Sat, 28 Oct 1995 05:01:00 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA06434 for ; Sat, 28 Oct 1995 05:00:57 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id FAA00247; Sat, 28 Oct 1995 05:00:56 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id FAA00169; Sat, 28 Oct 1995 05:00:52 -0700 Message-Id: <199510281200.FAA00169@corbin.Root.COM> To: John-Mark Gurney cc: hackers@freebsd.org Subject: Re: 951026-SNAP and 4megs In-reply-to: Your message of "Fri, 27 Oct 95 22:11:29 PDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 28 Oct 1995 05:00:51 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >On Fri, 27 Oct 1995, Jordan K. Hubbard wrote: > >> > well... I just thought you guys would like to know... I pulled 4megs of >> > ram out of a 8meg machine to test it... even though I read the message >> > about it failing on his machine... and it worked on my machine... right >> > now I am testing it on my laptop and it reports 639/3328k... and the >> > install screen came up... so it looks like 4meg does work... >> >> Huh! Great.. So now I can tell people: "It *might* work in 4MB." >> Why couldn't it have just fallen over on your machine, like everyone >> else's? :-) > >sorry :)... also... on my 8meg machine the ram reported was >640/3456k... just for the record... also... we could say just disable Hmmm, I think your 8MB machine has problems. Does the BIOS report 8MB during it's memory test? -DG From owner-freebsd-hackers Sat Oct 28 06:45:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13244 for hackers-outgoing; Sat, 28 Oct 1995 06:45:33 -0700 Received: from netcom7.netcom.com (root@netcom7.netcom.com [192.100.81.115]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13239 for ; Sat, 28 Oct 1995 06:45:32 -0700 Received: from netcomsv.netcom.com by netcom7.netcom.com (8.6.12/Netcom) id GAA07028; Sat, 28 Oct 1995 06:43:23 -0700 Message-Id: <199510281343.GAA07028@netcom7.netcom.com> X-Sender: mcstout@netcom.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 1995 06:39:58 -0700 To: piero@strider.ibenet.it From: Mark Stout Subject: Re: ftp tree permissions Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk At 11:59 AM 10/28/95 +0100, Piero Serini wrote: >Hello. > >Quoting from Mark Stout (Sat Oct 28 08:06:34 1995): >> The only thing that I'm thinking can be the problem is the permissions on >> the ftp directory structure. I'm ioncluding it in this message in the hopes >> that someone out there can see a problem. > >IMO they should be (corrections on the right): > I tried your suggestions and the users still can't login. What else besides permissions can be causing it? Thanks, Mark ========================================================================== Mark Stout | The Village Potpourri Mall: http://www.vpm.com/ ---------------+---------------------------------------------------------- VPM Enterprises; P.O.Box 6427; Folsom, CA 95763-6427 Commercial Internet Sales, Marketing and Advertising Specialist ========================================================================== From owner-freebsd-hackers Sat Oct 28 07:02:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13714 for hackers-outgoing; Sat, 28 Oct 1995 07:02:12 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA13705 for ; Sat, 28 Oct 1995 07:02:08 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id PAA17288 ; Sat, 28 Oct 1995 15:01:22 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id PAA06647 ; Sat, 28 Oct 1995 15:01:22 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id OAA18620; Sat, 28 Oct 1995 14:31:39 +0100 (MET) From: Ollivier Robert Message-Id: <199510281331.OAA18620@keltia.freenix.fr> Subject: Re: Netscape To: purna@rhinoceros.cs.inf.shizuoka.ac.jp (Yusuf Wilajati Purna) Date: Sat, 28 Oct 1995 14:31:38 +0100 (MET) Cc: dima@escape.com, hackers@freebsd.org In-Reply-To: <199510280451.NAA08873@rhinoceros.cs.inf.shizuoka.ac.jp> from "Yusuf Wilajati Purna" at Oct 28, 95 01:51:25 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1255 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Yusuf Wilajati Purna said: > > and my keyboard doesnt work. what exactly should I do? > > > > Dima. > > Have you already put the 'XKeysymDB' (included in the distribution) in > the appropriate directory (e.g., /usr/lib/X11)? The fastest way is to make a symlink /usr/X11 -> /usr/X11R6. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #3: Wed Oct 25 02:00:10 MET 1995 From owner-freebsd-hackers Sat Oct 28 07:09:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13988 for hackers-outgoing; Sat, 28 Oct 1995 07:09:37 -0700 Received: from strider.ibenet.it (root@strider.ibe.net [194.179.130.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA13975 for ; Sat, 28 Oct 1995 07:09:23 -0700 Received: (from piero@localhost) by strider.ibenet.it (8.6.12/8.6.12) id PAA17699; Sat, 28 Oct 1995 15:05:21 +0100 From: Piero Serini Message-Id: <199510281405.PAA17699@strider.ibenet.it> Subject: Re: ftp tree permissions To: mcs@vpm.com (Mark Stout) Date: Sat, 28 Oct 1995 15:05:21 +0100 (MET) Cc: piero@strider.ibenet.it, hackers@FreeBSD.ORG In-Reply-To: <199510281343.GAA07028@netcom7.netcom.com> from "Mark Stout" at Oct 28, 95 06:39:58 am Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-NCC-RegID: it.ibenet X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 613 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hello. Quoting from Mark Stout (Sat Oct 28 14:39:58 1995): > I tried your suggestions and the users still can't login. What else besides > permissions can be causing it? Sorry, I wasn't clear: those permissions are just a matter of security, with the permissions you set up before I (everyone) could cmpromise your security. The problem of your users not connecting is a different one. Bye, -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-hackers Sat Oct 28 07:31:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14719 for hackers-outgoing; Sat, 28 Oct 1995 07:31:05 -0700 Received: from nike.efn.org (garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14702 for ; Sat, 28 Oct 1995 07:30:55 -0700 Received: (from gurney_j@localhost) by nike.efn.org (8.6.11/8.6.9) id HAA16587; Sat, 28 Oct 1995 07:30:14 -0700 Date: Sat, 28 Oct 1995 07:30:14 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: David Greenman cc: hackers@freebsd.org Subject: Re: 951026-SNAP and 4megs In-Reply-To: <199510281200.FAA00169@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 28 Oct 1995, David Greenman wrote: > >On Fri, 27 Oct 1995, Jordan K. Hubbard wrote: > > > >> > well... I just thought you guys would like to know... I pulled 4megs of > >> > ram out of a 8meg machine to test it... even though I read the message > >> > about it failing on his machine... and it worked on my machine... right > >> > now I am testing it on my laptop and it reports 639/3328k... and the > >> > install screen came up... so it looks like 4meg does work... > >> > >> Huh! Great.. So now I can tell people: "It *might* work in 4MB." > >> Why couldn't it have just fallen over on your machine, like everyone > >> else's? :-) > > > >sorry :)... also... on my 8meg machine the ram reported was > >640/3456k... just for the record... also... we could say just disable > > Hmmm, I think your 8MB machine has problems. Does the BIOS report 8MB > during it's memory test? nope... when I took out the 4megs memory... it reports 004096 KB... normally it reports 8192 kb... sorry... I was providing a distinction between my laptop and my other machine that I said I took the 4megs ram out of... TTYL... John-Mark gurney_j@efn.org Modem/FAX: (503) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Sat Oct 28 07:35:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14985 for hackers-outgoing; Sat, 28 Oct 1995 07:35:33 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA14971 for ; Sat, 28 Oct 1995 07:35:27 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id HAA00574; Sat, 28 Oct 1995 07:35:24 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id HAA00704; Sat, 28 Oct 1995 07:35:21 -0700 Message-Id: <199510281435.HAA00704@corbin.Root.COM> To: John-Mark Gurney cc: hackers@freebsd.org Subject: Re: 951026-SNAP and 4megs In-reply-to: Your message of "Sat, 28 Oct 95 07:30:14 PDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 28 Oct 1995 07:35:21 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >On Sat, 28 Oct 1995, David Greenman wrote: > >> >On Fri, 27 Oct 1995, Jordan K. Hubbard wrote: >> > >> >> > well... I just thought you guys would like to know... I pulled 4megs of >> >> > ram out of a 8meg machine to test it... even though I read the message >> >> > about it failing on his machine... and it worked on my machine... right >> >> > now I am testing it on my laptop and it reports 639/3328k... and the >> >> > install screen came up... so it looks like 4meg does work... >> >> >> >> Huh! Great.. So now I can tell people: "It *might* work in 4MB." >> >> Why couldn't it have just fallen over on your machine, like everyone >> >> else's? :-) >> > >> >sorry :)... also... on my 8meg machine the ram reported was >> >640/3456k... just for the record... also... we could say just disable >> >> Hmmm, I think your 8MB machine has problems. Does the BIOS report 8MB >> during it's memory test? > >nope... when I took out the 4megs memory... it reports 004096 KB... >normally it reports 8192 kb... sorry... I was providing a distinction between >my laptop and my other machine that I said I took the 4megs ram out of... >TTYL... Ohh...I understand what you mean now. Yes, this difference (3456 vs. 3328) ca happen when the chipset does/doesn't support remapping some of the memory that is normally lost in the ISA hole. This can be up to 384K of difference, but most chipsets only remap 256K. I think the failure cases are with the machines that *don't* do this remapping - there just isn't quite enough memory. -DG From owner-freebsd-hackers Sat Oct 28 07:39:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15151 for hackers-outgoing; Sat, 28 Oct 1995 07:39:28 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15143 for ; Sat, 28 Oct 1995 07:39:21 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id KAA12888 for ; Sat, 28 Oct 1995 10:44:40 -0400 Date: Sat, 28 Oct 1995 10:44:40 -0400 Message-Id: <199510281444.KAA12888@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: Re: Come and get it! 2.1.0-951026-SNAP is released! Sender: owner-hackers@freebsd.org Precedence: bulk > o WEB server option now works properly. Which web server is included? db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Oct 28 08:53:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA22947 for hackers-outgoing; Sat, 28 Oct 1995 08:53:30 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA22923 for ; Sat, 28 Oct 1995 08:53:15 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id QAA18016 ; Sat, 28 Oct 1995 16:53:01 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id QAA06829 ; Sat, 28 Oct 1995 16:53:00 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id QAA26158; Sat, 28 Oct 1995 16:40:34 +0100 (MET) From: Ollivier Robert Message-Id: <199510281540.QAA26158@keltia.freenix.fr> Subject: Re: Anybody using ftp groups with the wu ftpd compiled for To: mcs@vpm.com (Mark Stout) Date: Sat, 28 Oct 1995 16:40:34 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: <199510280709.AAA12586@netcom7.netcom.com> from "Mark Stout" at Oct 28, 95 00:06:34 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1255 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk It seems that Mark Stout said: > I'm having no luck setting up restricted ftp access. I want my accounts to > ftp into their account and do what they want from there, but that's as far > as they go. Their home directory in effect becomes their '/' directory, > just /usr/home/ftp becomes the '/' for the anonymous user. I'm using the > ftpaccess file and trying to setup 'guestgroups'. However, it fails on me > everytime. The anonymous user can log in, but valid users can not. I just tried it and it worked. I was not able to "DIR" or "LS" but I was restricted to my home directory and a "GET" succeeded. 306 [16:04] roberto@keltia:/build> ftp localhost Connected to localhost. 220 keltia.freenix.fr FTP server (Version wu-2.4(1) Mon Aug 14 12:20:49 MET DST 1995) ready. Name (localhost:roberto): 331 Password required for roberto. Password: 230 User roberto logged in. Access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> cd .. 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> cd shell 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> get aliaslist local: aliaslist remote: aliaslist 200 PORT command successful. 150 Opening BINARY mode data connection for aliaslist (1156 bytes). 226 Transfer complete. 1156 bytes received in 0.035 seconds (33 Kbytes/s) ftp> 221 Goodbye. > 4. That there is a 'ftp' group and a 'guest' group in /etc/group I have a group named ftponly in both ftpaccess and in /etc/group. ftponly:*:40:roberto # specify which group of users will be treated as "guests". guestgroup ftponly The "LS" problem is interesting. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #3: Wed Oct 25 02:00:10 MET 1995 From owner-freebsd-hackers Sat Oct 28 10:47:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA01674 for hackers-outgoing; Sat, 28 Oct 1995 10:47:45 -0700 Received: from cwbone.bsi.com.br ([200.250.250.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA01635 ; Sat, 28 Oct 1995 10:47:30 -0700 Received: (from lenzi@localhost) by cwbone.bsi.com.br (8.6.11/8.6.9) id PAA00973; Sat, 28 Oct 1995 15:57:55 GMT Date: Sat, 28 Oct 1995 15:57:53 +0000 () From: Sergio Lenzi To: hackers@freebsd.org cc: questions@freebsd.org Subject: INGRES Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Helo, There is an INGRES distribution in my WWW! It is an source and binary dist. I have recoded various parts of the system and is now bug free (I hope). The equel processor now has "context sensitivity" (now you can define a variable name more than once in the code). It is imcompatible from the original version in the database files (beware to export your dbs before installing it). It can detect the enviroment (machine) you are compiling in from a file calc.c in the directory source/conf/h. the makefile (gnumake) builds the correct include files based on the calculations of word size and struct padding. The system installs on /usr/ingres...... The more, mail me..... Lenzi. From owner-freebsd-hackers Sat Oct 28 12:48:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14898 for hackers-outgoing; Sat, 28 Oct 1995 12:48:13 -0700 Received: from dtihost.datatrek.com (dtihost.datatrek.com [204.31.148.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14886 ; Sat, 28 Oct 1995 12:48:10 -0700 Received: from laptop ([205.162.141.3]) by dtihost.datatrek.com (8.6.12/8.6.9) with SMTP id MAA16304; Sat, 28 Oct 1995 12:46:24 -0700 X-Mailer: Mi'Mail from IRISoft Works, Evaluation Version 1.11 From: gcrutcher@datatrek.com (Gary Crutcher) Subject: Sendmail problems Mime-Version: 1.0 Date: Sat, 28 Oct 1995 13:08:31 Message-Id: <28101995131320680.II26500@datatrek.com> To: hackers@freebsd.org, questions@freebsd.org Content-Transfer-Encoding: Quoted-Printable Content-Type: Text/plain; charset=ISO-8859-1 Sender: owner-hackers@freebsd.org Precedence: bulk I have just connected a laptop via ethernet to my freebsd machine. I am trying to use Eudora to get mail. I keep getting a connection refused=20 error message. I have also tried other mail programs with no luck. Is= =20 there something that needs to be set on ther server side or in my mail=20 program that would let me get mail from the server via my laptop mail=20 program. Thanks, Gary From owner-freebsd-hackers Sat Oct 28 13:03:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA16611 for hackers-outgoing; Sat, 28 Oct 1995 13:03:36 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA16598 for ; Sat, 28 Oct 1995 13:03:28 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA00217; Sat, 28 Oct 1995 12:52:43 -0700 From: Terry Lambert Message-Id: <199510281952.MAA00217@phaeton.artisoft.com> Subject: Re: New lmbench available (fwd) To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Sat, 28 Oct 1995 12:52:42 -0700 (MST) Cc: terry@lambert.org, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510280705.AAA01197@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 28, 95 00:05:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1317 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > #ifdef TERRY_IN_FUTURIST_MODE > > > > You connect to services instead of machines, of course, and the > > underlying transport is permitted to load balance you off onto > > another server. > > Boy isn't this very similar to Novell's service schemes except that > I don't think that Novell provides for load balancing but then > again that is probably not to hard to implement if you can > agree on the metrics... It isn't even remotely similar. Novell's scheme involves NDS, which is a push model for replication. Push models are inherently broken. Also in NDS, you must still get to the server, though you do authenticate to the network. Not "any server", "THE server". Novell's servers have no means of anonymity. Novell's servers must also go to a particular location to look up a resource identity. That leaves the location as a bottleneck. Novell's servers are broken. The closest thing to this is the SGI video servers; but of course, they must be a cluster located in close proximity, not distributed all over the landscape. SGI's servers are broken. Any "soloution" that supposedly "solves" the problem by assuming a larger pipe is broken, IMO. 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 Oct 28 13:36:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21605 for hackers-outgoing; Sat, 28 Oct 1995 13:36:57 -0700 Received: from madonna.ic.net (root@[152.160.131.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21547 ; Sat, 28 Oct 1995 13:36:39 -0700 Received: (from rob@localhost) by madonna.ic.net (8.6.12/8.6.9) id QAA00672; Sat, 28 Oct 1995 16:23:28 -0400 Posted-Date: Sat, 28 Oct 1995 16:23:28 -0400 Message-Id: <199510282023.QAA00672@madonna.ic.net> Subject: Re: Sendmail problems To: gcrutcher@datatrek.com (Gary Crutcher) Date: Sat, 28 Oct 1995 16:23:27 -0400 (EDT) Cc: hackers@freebsd.org, questions@freebsd.org In-Reply-To: <28101995131320680.II26500@datatrek.com> from "Gary Crutcher" at Oct 28, 95 01:08:31 pm From: "Rob Misiak" Reply-To: rdm@ic.net X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 735 Sender: owner-hackers@freebsd.org Precedence: bulk Gary Crutcher ("Sendmail problems") wrote: > > I have just connected a laptop via ethernet to my freebsd machine. I am > trying to use Eudora to get mail. I keep getting a connection refused=20 > error message. I have also tried other mail programs with no luck. Is= > =20 > there something that needs to be set on ther server side or in my mail=20 > program that would let me get mail from the server via my laptop mail=20 > program. Do you think the problem might be that you don't have a POP server set up on the FreeBSD box? You should have a line which is something like: pop3 stream tcp nowait root /usr/local/libexec/popper -s in /etc/inetd.conf, and (obviously) a POP daemon installed on your machine. Rob From owner-freebsd-hackers Sat Oct 28 14:09:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA27173 for hackers-outgoing; Sat, 28 Oct 1995 14:09:35 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27162 for ; Sat, 28 Oct 1995 14:09:29 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id WAA24986; Sat, 28 Oct 1995 22:09:12 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199510282109.WAA24986@gvr.win.tue.nl> Subject: Re: clk interrupts > 150/sec??? To: se@zpr.uni-koeln.de (Stefan Esser) Date: Sat, 28 Oct 1995 22:09:11 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199510240932.AA20734@Sysiphos> from "Stefan Esser" at Oct 24, 95 10:32:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 364 Sender: owner-hackers@freebsd.org Precedence: bulk > } I always thought clk0 should have a rate of 100/sec. > > Well, you got PCI devices in your system ? > > Don't ask for details :-) > > Just substract 100 from clk0 to find out > the accumulated rate of PCI interrupts ... I do. Indeed that seems to explain things. Shouldn't this be corrected somehow? I cant believe this is without consequences.? -Guido From owner-freebsd-hackers Sat Oct 28 14:17:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28126 for hackers-outgoing; Sat, 28 Oct 1995 14:17:07 -0700 Received: from cats.ucsc.edu (root@cats-po-1.UCSC.EDU [128.114.129.22]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28096 ; Sat, 28 Oct 1995 14:16:55 -0700 Received: from scruz.ucsc.edu by cats.ucsc.edu with SMTP id OAA18235; Sat, 28 Oct 1995 14:16:41 -0700 Received: from osprey by scruz.ucsc.edu id aa04092; 28 Oct 95 14:15 PDT Received: (from markd@localhost) by Grizzly.COM (8.6.9/8.6.9) id NAA15018; Sat, 28 Oct 1995 13:39:49 -0700 Date: Sat, 28 Oct 1995 13:39:49 -0700 From: Mark Diekhans Message-Id: <199510282039.NAA15018@Grizzly.COM> To: gcrutcher@datatrek.com CC: hackers@freebsd.org, questions@freebsd.org In-reply-to: <28101995131320680.II26500@datatrek.com> (message from Gary Crutcher on Sat, 28 Oct 1995 13:08:31) Subject: Re: Sendmail problems Sender: owner-hackers@freebsd.org Precedence: bulk >I have just connected a laptop via ethernet to my freebsd machine. I am >trying to use Eudora to get mail. I keep getting a connection refused=20 >error message. I have also tried other mail programs with no luck. Is= >=20 >there something that needs to be set on ther server side or in my mail=20 >program that would let me get mail from the server via my laptop mail=20 >program. While Eudora uses SMTP to talk to sendmail for sending mail, it uses the POP protocal from retrieving mail from a mailbox on a Unix system. This requires a POP server on said unix system. The most common POP server is popper, but its buggy, with several version floating around with various bugs fixed. I highly recommend the POP server that comes with Mark Crispin's excellent IMAP package available from ftp://ftp.cac.washington.edu/mail/* (you probably want the 3.? beta version, which is actually release quality, not the 4.0 alpha version). Let me know if you have problems, mark From owner-freebsd-hackers Sat Oct 28 14:32:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA00112 for hackers-outgoing; Sat, 28 Oct 1995 14:32:08 -0700 Received: from strider.ibenet.it (root@strider.ibe.net [194.179.130.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29972 for ; Sat, 28 Oct 1995 14:31:58 -0700 Received: (from piero@localhost) by strider.ibenet.it (8.6.12/8.6.12) id WAA18261; Sat, 28 Oct 1995 22:27:51 +0100 From: Piero Serini Message-Id: <199510282127.WAA18261@strider.ibenet.it> Subject: Re: INGRES To: lenzi@cwbone.bsi.com.br (Sergio Lenzi) Date: Sat, 28 Oct 1995 22:27:50 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: from "Sergio Lenzi" at Oct 28, 95 03:57:53 pm Reply-To: piero@strider.ibenet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 58113562 X-NCC-RegID: it.ibenet X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 801 Sender: owner-hackers@freebsd.org Precedence: bulk Quoting from Sergio Lenzi (Sat Oct 28 16:57:53 1995): > Helo, 250 strider.ibenet.it Hello lenzi@cwbone.bsi.com.br [200.250.250.14], pleased to meet you :) > There is an INGRES distribution in my WWW! Coooooool, I'll try it on a 1.1.5.1. > It is an source and binary dist. > > I have recoded various parts of the system and is now > bug free (I hope). The equel processor now has "context sensitivity" ... > The more, mail me..... Maybe it's not perfect, but I'd say to include it in the tree somewhere (if Paolo agrees, obviously), as it would be a *great* tool to have. Bye, -- # $Id: .signature,v 1.12 1995/08/14 12:10:54 piero Exp $ Piero Serini Via Giambologna, 1 I 20136 Milano - ITALY From owner-freebsd-hackers Sat Oct 28 14:33:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA00278 for hackers-outgoing; Sat, 28 Oct 1995 14:33:34 -0700 Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA00265 for ; Sat, 28 Oct 1995 14:33:28 -0700 Received: from localhost (localhost [127.0.0.1]) by spooky.rwwa.com (8.6.11/8.6.9) with SMTP id RAA00232 for ; Sat, 28 Oct 1995 17:34:33 -0400 Message-Id: <199510282134.RAA00232@spooky.rwwa.com> X-Authentication-Warning: spooky.rwwa.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.3 12/28/94 To: hackers@freebsd.org Subject: Re: Come and get it! 2.1.0-951026-SNAP is released! In-reply-to: Your message of "Fri, 27 Oct 1995 11:23:15 PDT." <10818.814818195@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Oct 1995 17:34:33 -0400 From: Robert Withrow Sender: owner-hackers@freebsd.org Precedence: bulk Two 2.1.0-951026-SNAP atapi install failures: 1) on one system it fails to probe the toshiba cdrom on wdc1. 2) on another system it probes the sony cdrom on wdc1, but install doesn't know it's there. In both cases I tried both with and without a disk in the drive. I also fiddled using boot -c removing all things that aren't there, or just plain booting. ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430 Net: witr@rwwa.COM R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA From owner-freebsd-hackers Sat Oct 28 14:34:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA00435 for hackers-outgoing; Sat, 28 Oct 1995 14:34:48 -0700 Received: from jraynard.demon.co.uk (jraynard.demon.co.uk [158.152.42.77]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA00424 for ; Sat, 28 Oct 1995 14:34:41 -0700 Received: (from james@localhost) by jraynard.demon.co.uk (8.6.11/8.6.9) id VAA00650; Sat, 28 Oct 1995 21:10:45 GMT Date: Sat, 28 Oct 1995 21:10:43 +0000 () From: James Raynard To: hackers@freebsd.org Subject: ld problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk I'm trying to port a concurrent language which was originally written on SunOS4 to FreeBSD. The idea is that you compile a non-concurrent version, load the extra code and dump the image, using the 'unexec' file that comes with emacs, to get the final executable. The problem is that the initial version only works if it is statically linked, which means that _DYNAMIC is a null pointer and the dump seg faults. There is a built-in version of unexec with the language, but it produces the executable in NMAGIC format, which the kernel loader refuses to run! Can anyone suggest a way around this? (If I can get it working, I will of course make the port available) James Segmentation fault (core dumped): cannot find file '.signature' From owner-freebsd-hackers Sat Oct 28 14:50:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01687 for hackers-outgoing; Sat, 28 Oct 1995 14:50:27 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA01671 for ; Sat, 28 Oct 1995 14:50:25 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id OAA10066; Sat, 28 Oct 1995 14:49:57 -0700 Message-Id: <199510282149.OAA10066@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Sat, 28 Oct 1995 12:52:42 PDT." <199510281952.MAA00217@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 14:49:52 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >>> Terry Lambert said: > > Novell's servers have no means of anonymity. > > Novell's servers must also go to a particular location to look up > a resource identity. That leaves the location as a bottleneck. > > Novell's servers are broken. You mean that Novell does not have a mechanism to search for a service in a network. So lets say that if I wanted to print to a "lan" printer and I don't care where it is , it can't do that?? Amancio From owner-freebsd-hackers Sat Oct 28 15:08:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02618 for hackers-outgoing; Sat, 28 Oct 1995 15:08:23 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA02611 for hackers@freebsd.org; Sat, 28 Oct 1995 15:08:21 -0700 Date: Sat, 28 Oct 1995 15:08:21 -0700 From: Jeffrey Hsu Message-Id: <199510282208.PAA02611@freefall.freebsd.org> To: hackers@freebsd.org Subject: Re: ld problems Sender: owner-hackers@freebsd.org Precedence: bulk > I'm trying to port a concurrent language which was originally written > The problem is that the initial version only works if it is statically > linked This is the biggest single reason I know of to move to a standard executable format, namely ELF. There are a lot of unported languages, debuggers, and useful programming utilities out there for which the biggest obstacle is having to write ad-hoc code specifically for FreeBSD's current binary format. Whenever I port a new language, this is usually the first thing I have to modify. At some point, you really start wishing for a standard executable format. Jeffrey From owner-freebsd-hackers Sat Oct 28 15:34:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05220 for hackers-outgoing; Sat, 28 Oct 1995 15:34:12 -0700 Received: from dux.ru (dux.ru [193.125.210.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA05199 for ; Sat, 28 Oct 1995 15:34:04 -0700 Received: from myframe.dux.ru (uucp@localhost) by dux.ru (8.6.10/8.6.6) with UUCP id BAA01643; Sun, 29 Oct 1995 01:33:03 +0300 Received: from myframe.dux.ru (uucp@localhost) by tetris.dux.ru (8.6.8/8.6.6) with UUCP id BAA22782; Sun, 29 Oct 1995 01:18:37 +0300 Received: (from ptitz@localhost) by myframe.dux.ru (8.6.11/8.6.6) id BAA03589; Sun, 29 Oct 1995 01:04:15 +0300 To: Piero Serini Cc: hackers@FreeBSD.ORG, Mark Stout References: <199510281059.LAA17193@strider.ibenet.it> In-Reply-To: <199510281059.LAA17193@strider.ibenet.it>; from Piero Serini at Sat, 28 Oct 1995 11:59:30 +0100 (MET) Message-ID: Organization: DUX Date: Sun, 29 Oct 1995 01:04:12 +0300 (MSK) X-Mailer: Mail/@ [v2.36 FreeBSD] From: "Dmitry Mishin" Reply-To: ptitz@dux.ru Subject: Re: ftp tree permissions Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 826 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199510281059.LAA17193@strider.ibenet.it> Piero Serini writes: >Quoting from Mark Stout (Sat Oct 28 08:06:34 1995): >> The only thing that I'm thinking can be the problem is the permissions on >> the ftp directory structure. I'm ioncluding it in this message in the hopes >> that someone out there can see a problem. >IMO they should be (corrections on the right): [skipped] >> /ftp/etc: >> total 5 >> drwxr-xr-x 2 root ftp 512 Oct 25 12:50 ./ >> drwxrwxrwx 10 root wheel 512 Oct 26 20:53 ../ >> -rwxr-xr-x 1 root ftp 37 Oct 25 13:10 group* 444 >> -rwxr-xr-x 1 root ftp 396 Oct 27 13:05 passwd* 444 there are reason to use pwd.db instead of passwd - probably there are required changes of corresponding places in man pages (for both fbsd ftpd and wu-ftpd package). -- D.Mishin From owner-freebsd-hackers Sat Oct 28 15:36:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05518 for hackers-outgoing; Sat, 28 Oct 1995 15:36:50 -0700 Received: from w8hd.w8hd.org (w8hd.w8hd.org [198.252.159.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA05507 for ; Sat, 28 Oct 1995 15:36:45 -0700 Received: (from root@localhost) by w8hd.w8hd.org (8.6.12/8.6.9) id SAA00312; Sat, 28 Oct 1995 18:36:43 -0400 Date: Sat, 28 Oct 1995 18:36:43 -0400 (EDT) From: Charlie ROOT To: hackers@freebsd.org Subject: netscape 2.0b1 fouls directory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Netscape 2.0b1 created a directory ~/.netscape-cache which cannot be rm'd. I mv'd it to .foo and restart netscape which recreated the file .netscape Then tried to cd to .foo, works.. now say ls and it returns: ls: .: No such file or directory The machine has been rebooted which should have run fsck on the partition (I think..) no complaints of file system problems. How can I repair this netscape damage ? regards kim -- kimc@w8hd.org From owner-freebsd-hackers Sat Oct 28 15:54:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA07643 for hackers-outgoing; Sat, 28 Oct 1995 15:54:10 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA07637 for ; Sat, 28 Oct 1995 15:54:07 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02954; Sat, 28 Oct 1995 15:43:16 -0700 From: Terry Lambert Message-Id: <199510282243.PAA02954@phaeton.artisoft.com> Subject: Re: New lmbench available (fwd) To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Sat, 28 Oct 1995 15:43:15 -0700 (MST) Cc: terry@lambert.org, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199510282149.OAA10066@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 28, 95 02:49:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1767 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Novell's servers have no means of anonymity. > > > > Novell's servers must also go to a particular location to look up > > a resource identity. That leaves the location as a bottleneck. > > > > Novell's servers are broken. > > You mean that Novell does not have a mechanism to search for a > service in a network. So lets say that if I wanted to print to > a "lan" printer and I don't care where it is , it can't do that?? I'd like to see you replicate the buildings only color printer. 8-). A print queue is "a service on a server". The distinction is impossible to abstract for physicality. The services I'm talking about are things like "the next 1024 frames of 'Batman Returns'" or "the latest release of pkzip". Physical devices are peripherals to the network; they are not contained within the network. Content-based addressing can only work for things that are *within* the network. In theory, you could not care where the queue that you are printing to or where the printer servicing that queue resizes (assuming a pull model for print queuing). But you always care where the printer lives, just as you care where your floppy drive and CDROM drive (and maybe a tape drive) lives. Services based on data retrieval, on the other hand, are not dependent on the locality of the storage device containing the data, only the timeliness of its arrival at the requesting location. Ie: I can't afford packet transfer times exceeding my pool retnetion time for my video data. This discussion is probably getting too arcane for the general list readership; we should probably move it to private email. 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 Oct 28 16:15:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09351 for hackers-outgoing; Sat, 28 Oct 1995 16:15:05 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09344 for ; Sat, 28 Oct 1995 16:15:03 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id QAA16633; Sat, 28 Oct 1995 16:14:49 -0700 Received: from localhost (localhost [127.0.0.1]) by geli.clusternet (8.6.12/8.6.9) with SMTP id QAA17833; Sat, 28 Oct 1995 16:12:20 -0700 Message-Id: <199510282312.QAA17833@geli.clusternet> X-Authentication-Warning: geli.clusternet: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: Terry Lambert cc: hasty@rah.star-gate.com (Amancio Hasty Jr.), rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Arcanity in services on servers In-reply-to: Your message of "Sat, 28 Oct 1995 15:43:15 PDT." <199510282243.PAA02954@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 16:12:19 -0700 From: "Russell L. Carter" Sender: owner-hackers@FreeBSD.org Precedence: bulk [ Lot's of interesting services on servers stuff deleted ] > The services I'm talking about are things like "the next 1024 frames > of 'Batman Returns'" or "the latest release of pkzip". Or the object pointed to by a URL, or the next "newsgroup"... > > > This discussion is probably getting too arcane for the general > list readership; we should probably move it to private email. Now, isn't this the sort of thing that should be on hackers? Where else can we get multiplatform design discussions that we can use to help figure out where we (and FreeBSD:) should go next? It gets arcane when the discussion gets down to details, which of course is where the truth is... Cheers, Russell > > > 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 Oct 28 16:29:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA10208 for hackers-outgoing; Sat, 28 Oct 1995 16:29:30 -0700 Received: from ulantris.neosoft.com (ulantris.NeoSoft.COM [198.64.81.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA10203 for ; Sat, 28 Oct 1995 16:29:23 -0700 Received: (from jkurtz@localhost) by ulantris.neosoft.com (8.6.9/8.6.9) id SAA00950; Sat, 28 Oct 1995 18:18:29 GMT From: John Kurtz Message-Id: <199510281818.SAA00950@ulantris.neosoft.com> Subject: adding cursor saving and regions to syscons To: hackers@freebsd.org Date: Sat, 28 Oct 1995 18:18:28 +0000 () X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 5061 Sender: owner-hackers@freebsd.org Precedence: bulk Hello Team! This is my first hack on the kernel, so here goes. In my testing of certain ANSI features offered on muds (yes, I visit them and run one), I found the cursor position saving/restoring and scroll regions not supported. I have tested this on my machine, but I feel that I didn't quite cover all the cases on the scrolling regions. This is done with diff on the syscons.c file. The full path is /usr/src/sys/i386/isa/syscons.c and is still in the 2.0R version of source so I am not sure how well this integrates into FreeBSD-current. Anyhow, here is the diff file... ------------------------------------------------------ CLIP HERE ----------- 162a163,169 > int xpos_saved; /* saved X position */ > int ypos_saved; /* saved Y position */ > char position_saved; /* has the cursor position */ > /* been saved? */ > char region_set; /* is a scroll region active? */ > int region_top; /* top of scroll region */ > int region_bottom; /* bottom of scroll region */ 739a747 > scp->region_set = 0; 1464a1473 > scp->region_set = 0; 1601c1610,1625 < if (scp->ypos > 0) --- > if (scp->region_set) { > if (scp->ypos > scp->region_top) > move_crsr(scp, scp->xpos, scp->ypos - 1); > else if(scp->ypos == scp->region_top) { > move_up(scp->crt_base + > (scp->xsize * scp->region_top), > scp->crt_base + > (scp->xsize * > (scp->region_top+1)), > (scp->region_bottom - > scp->region_top) * scp->xsize); > fillw(scp->term.cur_attr | scr_map[0x20], > scp->crt_base + (scp->xsize * > scp->region_top), scp->xsize); > } > } else if (scp->ypos > 0) 1735a1760 > /* does this need to work for regions? */ 1747a1773 > /* does this need to work for regions? */ 1784a1811,1826 > if(scp->region_set) { > if (n > scp->region_bottom-scp->region_top+1) > n = scp->region_bottom- > scp->region_top+1; > bcopy(scp->crt_base + > (scp->xsize * (n+scp->region_top)), > scp->crt_base + > (scp->xsize * scp->region_top), > scp->xsize * (scp->ysize - n) * > sizeof(u_short)); > fillw(scp->term.cur_attr | scr_map[0x20], > scp->crt_base + scp->xsize * > (scp->region_bottom - n + 1), > scp->xsize * n); > break; > } 1798a1841,1856 > if(scp->region_set) { > if (n > scp->region_bottom-scp->region_top+1) > n = scp->region_bottom- > scp->region_top+1; > bcopy(scp->crt_base + > (scp->xsize * scp->region_top), > scp->crt_base + > (scp->xsize * (n+scp->region_top)), > scp->xsize * (scp->ysize - n) * > sizeof(u_short)); > fillw(scp->term.cur_attr | scr_map[0x20], > scp->crt_base + scp->xsize * > scp->region_top, > scp->xsize * n); > break; > } 1891a1950,1995 > case 'r': /* Region setting */ > if (scp->term.num_param == 0) > scp->region_set = 0; > else if (scp->term.num_param == 2) { > if(!scp->term.param[0] && !scp->term.param[1]) > scp->region_set = 0; > else { > scp->region_set = 1; > scp->region_top = scp->term.param[0]; > scp->region_bottom = scp->term.param[1]; > if(scp->region_top > scp->region_bottom) > scp->region_set = 0; > else { > if(--scp->region_top < 0) > scp->region_top = 0; > if(scp->region_top >= > scp->ysize) > scp->region_top = > scp->ysize; > if(--scp->region_bottom < 0) > scp->region_bottom = 0; > if(scp->region_bottom >= > scp->ysize) > scp->region_bottom = > scp->ysize; > } > } > } > break; > case 's': /* save the cursor position -- should this be */ > /* allowed to save multiple points??? */ > scp->position_saved = 1; > scp->xpos_saved = scp->xpos; > scp->ypos_saved = scp->ypos; > break; > > case 'u': /* restore the cursor position -- should this be */ > /* allowed to restore multiple points??? */ > if(scp->position_saved) { > scp->position_saved = 0; > scp->xpos = scp->xpos_saved; > scp->ypos = scp->ypos_saved; > move_crsr(scp, scp->xpos, scp->ypos); > } > break; > 2075c2179,2193 < if (scp->crtat >= scp->crt_base + scp->ysize * scp->xsize) { --- > if(scp->region_set) { > if (scp->crtat == > scp->crt_base + (scp->region_bottom+1) * scp->xsize) { > bcopy(scp->crt_base + (scp->region_top+1)*scp->xsize, > scp->crt_base + scp->region_top*scp->xsize, > scp->xsize * > (scp->region_bottom-scp->region_top) * > sizeof(u_short)); > fillw(scp->term.cur_attr | scr_map[0x20], > scp->crt_base + scp->xsize * scp->region_bottom, > scp->xsize); > scp->crtat -= scp->xsize; > scp->ypos--; > } > } else if (scp->crtat >= scp->crt_base + scp->ysize * scp->xsize) { 2163a2282,2283 > scp->position_saved = 0; > scp->region_set = 0; ------------------------------------------------------ CLIP HERE ----------- John Kurtz (jkurtz@neosoft.com) From owner-freebsd-hackers Sat Oct 28 16:41:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11091 for hackers-outgoing; Sat, 28 Oct 1995 16:41:32 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11081 ; Sat, 28 Oct 1995 16:41:26 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA20558 ; Sun, 29 Oct 1995 00:41:23 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA07841 ; Sun, 29 Oct 1995 00:41:22 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id AAA29854; Sun, 29 Oct 1995 00:22:09 +0100 (MET) From: Ollivier Robert Message-Id: <199510282322.AAA29854@keltia.freenix.fr> Subject: Re: Sendmail problems To: gcrutcher@datatrek.com (Gary Crutcher) Date: Sun, 29 Oct 1995 00:22:07 +0100 (MET) Cc: hackers@freebsd.org, questions@freebsd.org In-Reply-To: <28101995131320680.II26500@datatrek.com> from "Gary Crutcher" at Oct 28, 95 01:08:31 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1255 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Gary Crutcher said: > error message. I have also tried other mail programs with no luck. Is > there something that needs to be set on ther server side or in my mail > program that would let me get mail from the server via my laptop mail > program. You need to install a POP server on the FreeBSD machine. See /usr/ports/mail/popper. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #3: Wed Oct 25 02:00:10 MET 1995 From owner-freebsd-hackers Sat Oct 28 16:48:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11512 for hackers-outgoing; Sat, 28 Oct 1995 16:48:44 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA11506 for ; Sat, 28 Oct 1995 16:48:39 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id TAA14372 for hackers@freebsd.org; Sat, 28 Oct 1995 19:52:11 -0400 From: Peter Dufault Message-Id: <199510282352.TAA14372@hda.com> Subject: TI Pentium travelmate To: hackers@freebsd.org Date: Sat, 28 Oct 1995 19:52:10 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 375 Sender: owner-hackers@freebsd.org Precedence: bulk I was just looking at a TI Travelmate with a 75MHz Pentium, PCI bus, 640x480 Active Matrix display, 8 MB RAM, 520MB disk for $2300.00. Is anyone running FreeBSD on this? I came awfully close to buying it. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-hackers Sat Oct 28 17:00:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12084 for hackers-outgoing; Sat, 28 Oct 1995 17:00:44 -0700 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12079 for ; Sat, 28 Oct 1995 17:00:42 -0700 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id UAA01396 for freebsd-hackers@freebsd.org; Sat, 28 Oct 1995 20:01:00 -0400 From: Charles Henrich Message-Id: <199510290001.UAA01396@crh.cl.msu.edu> Subject: LINT addition please To: freebsd-hackers@freebsd.org Date: Sat, 28 Oct 1995 20:01:00 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 731 Sender: owner-hackers@freebsd.org Precedence: bulk For those systems that do not correctly report memory size, could we please add this to LINT. Currently MAXMEM isnt documented anywhere. # MAXMEM Specified the maximum amount of ram in the system in kilobytes. Only # use this if your BIOS is broken (I.e. Compaq's). You can specify as # large an amount as you expect will eventually be in the system, as # FreeBSD is smart enough to recompute the max memory size by scanning # for the presence of this much memory. # # MAXMEM = MB*1024 (so a 16mb system would use MAXMEM=16384) # #options MAXMEM=262144 # -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ From owner-freebsd-hackers Sat Oct 28 17:16:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA12795 for hackers-outgoing; Sat, 28 Oct 1995 17:16:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA12788 for ; Sat, 28 Oct 1995 17:16:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03284; Sat, 28 Oct 1995 17:04:52 -0700 From: Terry Lambert Message-Id: <199510290004.RAA03284@phaeton.artisoft.com> Subject: Re: Arcanity in services on servers To: rcarter@geli.com (Russell L. Carter) Date: Sat, 28 Oct 1995 17:04:52 -0700 (MST) Cc: terry@lambert.org, hasty@rah.star-gate.com, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199510282312.QAA17833@geli.clusternet> from "Russell L. Carter" at Oct 28, 95 04:12:19 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 663 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > This discussion is probably getting too arcane for the general > > list readership; we should probably move it to private email. > > Now, isn't this the sort of thing that should be on hackers? Where > else can we get multiplatform design discussions that we can use to > help figure out where we (and FreeBSD:) should go next? It gets > arcane when the discussion gets down to details, which of course is > where the truth is... With respect, if it belongs in a public forum, it's one of the comp.protocols groups. 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 Oct 28 17:21:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13175 for hackers-outgoing; Sat, 28 Oct 1995 17:21:06 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13165 for ; Sat, 28 Oct 1995 17:20:56 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03302; Sat, 28 Oct 1995 17:08:42 -0700 From: Terry Lambert Message-Id: <199510290008.RAA03302@phaeton.artisoft.com> Subject: Re: New lmbench available (fwd) To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sat, 28 Oct 1995 17:08:42 -0700 (MST) Cc: hasty@rah.star-gate.com, terry@lambert.org, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199510282329.AAA00288@keltia.freenix.fr> from "Ollivier Robert" at Oct 29, 95 00:29:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1051 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > It seems that Amancio Hasty Jr. said: > > You mean that Novell does not have a mechanism to search for a > > service in a network. So lets say that if I wanted to print to > > a "lan" printer and I don't care where it is , it can't do that?? > > With Netware 3.x I don't think so (Terry ?). With Netware 4.x and NDS > (Network Directory Services, a naming service based on X.500), I think > there is the concept of multiple servers so you can attach to another > server. I may be wrong though :-) There is the concept of directory services branch replication. Not the concept of server content replication. You could do it anyway, if you wanted, but you'd have to extend the directory (meaning Netware 4.2 or better). Even then, you'd need your own service management tools to implement it. Lotus Notes is closer to the target. (we need to be able to redirect followups when posting). 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 Oct 28 18:20:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA15644 for hackers-outgoing; Sat, 28 Oct 1995 18:20:55 -0700 Received: from ix10.ix.netcom.com (ix10.ix.netcom.com [199.182.120.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA15639 for ; Sat, 28 Oct 1995 18:20:51 -0700 Received: from by ix10.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id SAA02949; Sat, 28 Oct 1995 18:18:45 -0700 Date: Sat, 28 Oct 1995 18:18:45 -0700 Message-Id: <199510290118.SAA02949@ix10.ix.netcom.com> From: tulchins@ix.netcom.com (Steven Tulchinsky ) Subject: Help! To: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk ---- Begin Forwarded Message Well.. It happened. I accidentally did rm -f in /dev. And in addition to killing all devices it removed MAKEDEV itself. Any ideas? I think I need to create a boot floppy but I can't find any instructions on it. Please point me in the right direction. Thanks a lot Steven tulchins@ix.netcom.com From owner-freebsd-hackers Sat Oct 28 18:47:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA16765 for hackers-outgoing; Sat, 28 Oct 1995 18:47:46 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA16760 for ; Sat, 28 Oct 1995 18:47:43 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA05824; Sat, 28 Oct 1995 18:47:26 -0700 To: Charlie ROOT cc: hackers@freebsd.org Subject: Re: netscape 2.0b1 fouls directory In-reply-to: Your message of "Sat, 28 Oct 1995 18:36:43 EDT." Date: Sat, 28 Oct 1995 18:47:25 -0700 Message-ID: <5822.814931245@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Which user did you do this as? Please elaborate on the part where you say "cannot be rm'd" Thanks! Jordan > > Netscape 2.0b1 created a directory ~/.netscape-cache which cannot be rm'd. > I mv'd it to .foo and restart netscape which recreated the file .netscape > > Then tried to cd to .foo, works.. now say ls and it returns: > ls: .: No such file or directory > > The machine has been rebooted which should have run fsck on the partition > (I think..) no complaints of file system problems. > > How can I repair this netscape damage ? > > regards > kim > > -- > kimc@w8hd.org > From owner-freebsd-hackers Sat Oct 28 19:28:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA18696 for hackers-outgoing; Sat, 28 Oct 1995 19:28:41 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA18689 for ; Sat, 28 Oct 1995 19:28:34 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA00410; Sat, 28 Oct 1995 19:28:01 -0700 Message-Id: <199510290228.TAA00410@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: rcarter@geli.com (Russell L. Carter), jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: Arcanity in services on servers In-reply-to: Your message of "Sat, 28 Oct 1995 17:04:52 PDT." <199510290004.RAA03284@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 19:28:00 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> Terry Lambert said: > > > This discussion is probably getting too arcane for the general > > > list readership; we should probably move it to private email. > > > > Now, isn't this the sort of thing that should be on hackers? Where > > else can we get multiplatform design discussions that we can use to > > help figure out where we (and FreeBSD:) should go next? It gets > > arcane when the discussion gets down to details, which of course is > > where the truth is... > > With respect, if it belongs in a public forum, it's one of the > comp.protocols groups. Well, you see we can come up with a beatiful architecture however I am sure that at some we will need OS support. Nah, it belongs right here or maybe on the multimedia list unfortunatly if I move the discussion to the multimedia mailing list the discussion would move right back in here. Gee I wonder why? Folks, we already have good networking, fast disk access, video capture but wait no video servers, no sound servers, no app servers... I don't think that discussions of implementing video servers, etc.. are arcane rather forward thinking well at least to some for me it should have been a reality now. *It sure would be nice for FreeBSD to take the lead and in upcoming necessary technology* Amancio From owner-freebsd-hackers Sat Oct 28 19:44:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA19337 for hackers-outgoing; Sat, 28 Oct 1995 19:44:44 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA19324 for ; Sat, 28 Oct 1995 19:44:39 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA00523; Sat, 28 Oct 1995 19:44:20 -0700 Message-Id: <199510290244.TAA00523@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: hackers@FreeBSD.org Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Sat, 28 Oct 1995 17:08:42 PDT." <199510290008.RAA03302@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 19:44:20 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> Terry Lambert said: > > It seems that Amancio Hasty Jr. said: > > > You mean that Novell does not have a mechanism to search for a > > > service in a network. So lets say that if I wanted to print to > > > a "lan" printer and I don't care where it is , it can't do that?? > > > > With Netware 3.x I don't think so (Terry ?). With Netware 4.x and ND S > > (Network Directory Services, a naming service based on X.500), I thin k > > there is the concept of multiple servers so you can attach to anothe r > > server. I may be wrong though :-) > > There is the concept of directory services branch replication. > > Not the concept of server content replication. > Either X.500 is a piece of shit or Novell failed to implement X.500 correctly. For sure at some point there was the concept of X.500 server's content replication. I shudder to have to look at another OSI document... Hmmm... I still have my "Decnet Phase V An OSI implementation" book which deals with a lot of this issues. So I will be back !! 8) Why? very simple, we are very , very close to a horde of multimedia chipsets to hit the market some of them are capable of H.260 encoding , mpeg encoding, 3d rendering , wave table sound and some of them are capable *billions* of instructions per seconds for special cases . The November issue of Byte Magazine has a good round up of some these cool chipsets so check it out! BTW: A side issue I did try to convince Xing Technologies to try to port their video server technology to FreeBSD however they have they decided to be assholes and are not going to do it . There is a linux port of their crap however I doubt that we would be able to use it for it requires driver support for the video recording/playback gear. Amancio From owner-freebsd-hackers Sat Oct 28 19:59:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA19978 for hackers-outgoing; Sat, 28 Oct 1995 19:59:27 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA19972 for ; Sat, 28 Oct 1995 19:59:20 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id TAA00620; Sat, 28 Oct 1995 19:58:56 -0700 Message-Id: <199510290258.TAA00620@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Terry Lambert cc: rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Sat, 28 Oct 1995 15:43:15 PDT." <199510282243.PAA02954@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Oct 1995 19:58:55 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >>> Terry Lambert said: > > I'd like to see you replicate the buildings only color printer. 8-). Thats one scenario the other scenario is in a reasonable small building when you install a printer you have to go in and dig around with your configuration files to tell every single workstation where the freaking thing is or lets say that it goes down and there is another printer in your vecinity the service should have the capability to redirect the printing to the next near printer . > A print queue is "a service on a server". Should a user really care about the distinction about server or service . Isn't that what we should try to abstract? > The distinction is impossible to abstract for physicality. Sure however as an architect would you be willing to cripple your architecture to services which don't require phisicality such as a printer? > The services I'm talking about are things like "the next 1024 frames > of 'Batman Returns'" or "the latest release of pkzip". > Services based on data retrieval, on the other hand, are not dependent > on the locality of the storage device containing the data, only the > timeliness of its arrival at the requesting location. > > Ie: I can't afford packet transfer times exceeding my pool retnetion > time for my video data. Hmm... have you heard of RTPv2 with it you can measure bandwith so you can send out a test stream to measure the bandwith or try to further encode down the video stream or/an change the frame rate base on the current bandwith. We got the bits and pieces necessary to implement what we want . We just don't have the architecture! Amancio From owner-freebsd-hackers Sat Oct 28 21:00:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA24697 for hackers-outgoing; Sat, 28 Oct 1995 21:00:59 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA24678 for ; Sat, 28 Oct 1995 21:00:53 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id WAA13338; Sat, 28 Oct 1995 22:58:35 -0500 Message-Id: <199510290358.WAA13338@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: "Amancio Hasty Jr." cc: Terry Lambert , hackers@FreeBSD.org Subject: Re: New lmbench available (fwd) In-reply-to: Your message of "Sat, 28 Oct 1995 19:44:20 PDT." <199510290244.TAA00523@rah.star-gate.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Sat, 28 Oct 1995 22:58:34 -0500 From: Jon Loeliger Sender: owner-hackers@FreeBSD.org Precedence: bulk Apparently, "Amancio Hasty Jr." scribbled: > Why? very simple, we are very , very close to a horde of multimedia > chipsets to hit the market some of them are capable of H.260 encoding , > mpeg encoding, 3d rendering , wave table sound and some of them > are capable *billions* of instructions per seconds for special > cases . The November issue of Byte Magazine has a good round up of some > these cool chipsets so check it out! Hmmm.... And some of them read this list... What was my address? -------------------------------------------------------------------- Jon Loeliger | There's a heart on her sleeve, from a spill of Chromatic Research Inc | red wine; there's a piece of green in the blue jdl@chromatic.com | of her eyes; she named it after me. Marillion From owner-freebsd-hackers Sat Oct 28 21:58:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA28163 for hackers-outgoing; Sat, 28 Oct 1995 21:58:44 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA28157 for ; Sat, 28 Oct 1995 21:58:41 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA12081 (5.67a/IDA-1.5 for hackers@freebsd.org); Sat, 28 Oct 1995 23:53:39 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id XAA01910 for hackers@freebsd.org; Sat, 28 Oct 1995 23:45:59 -0500 Date: Sat, 28 Oct 1995 23:45:59 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199510290445.XAA01910@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: WD8013 problem Organization: Taronga Park BBS References: <199509290848.JAA17224@gilberto.physik.rwth-aachen.de> Sender: owner-hackers@freebsd.org Precedence: bulk In article <199509290848.JAA17224@gilberto.physik.rwth-aachen.de>, Christoph P. Kukulies wrote: > (note the missing login: prompt - it only appears when I type ) I've seen this symptom when telnetting from a BSDI 1.x machine to another BSDI box as well as to my FreeBSD box at home. All connections are SLIP. Haven't seen the missing character problem. Have seen a missing *password* prompt, on occasion, when telnet's delivered a login name, but only on the BSDI box. From owner-freebsd-hackers Sat Oct 28 22:47:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00282 for hackers-outgoing; Sat, 28 Oct 1995 22:47:38 -0700 Received: from io.org (io.org [142.77.70.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00272 for ; Sat, 28 Oct 1995 22:47:36 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by io.org (8.6.12/8.6.12) with SMTP id BAA14926; Sun, 29 Oct 1995 01:47:03 -0400 Date: Sun, 29 Oct 1995 01:47:02 -0400 (EDT) From: Brian Tao To: David Greenman cc: FREEBSD-HACKERS-L Subject: Re: panic: free vnode isn't In-Reply-To: <199510250616.XAA28141@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Tue, 24 Oct 1995, David Greenman wrote: > > Okay...but for DDB this really isn't necessary and only results in you > losing about 4-6MB of memory for all the unused gdb debugging symbols. So I noticed... sysctl -a reported 20 megs of hw.usermem on a 32-meg machine. :( > I think your problem is caused by bug(s) in the NFS client code. While > we do test it relatively thoroughly, we don't pond on it in the way > that you are doing and that likely explains why the bug hasn't been > seen before and fixed. :-) At least it has been isolated to an NFS-related bug. :) The server died again today (2.0.5R was installed on it), but this time it managed to send a message to the console before keeling over completely: biodone: page busy < 0, off: 3162112, foff: 3162112, resid: 4096, index: 0 iozone: 8192, lblkno: 386 valid: 0xff, dirty: 0x0, mapped: 0 panic: biodone: page busy < 0 Then a bunch of attempts at syncing which eventually failed, then it rebooted. I'm in the process of installing 2.1.0-951026-SNAP right now. I'm also going to move our FTP server over to another machine, and mount only the staff home directories (a single 2-gig drive). Since I'm really the only person who uses this machine for interactive use, NFS traffic will be significantly reduced. If it is a problem with NFS load, the machine should be stable. My machines back in Taiwan had everything but the base FreeBSD distribution NFS-mounted from an SGI server (including user home directories and work directories) without encountering this problem. If this incarnation survives for a week, then I'll try moving the FTP service back on and take it from there. Oh, I'm getting "nfs send error 55" in syslog quite often... is this a symptom of an overrun buffer? I should add that the collision rate on our LAN averages 50% and can spike above 100%. It's absolutely horrid, but I hope it isn't the cause of the kernel panics. > Debugging this problem will almost certainly be quite difficult. ... > Unfortunately, without a lot more information, it's unlikely that I'll > be able solve this problem. *sigh* I'll try the latest snapshot and see what happens then. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sat Oct 28 22:54:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00558 for hackers-outgoing; Sat, 28 Oct 1995 22:54:40 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA00548 for ; Sat, 28 Oct 1995 22:54:38 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id WAA00255; Sat, 28 Oct 1995 22:54:35 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id WAA03343; Sat, 28 Oct 1995 22:54:25 -0700 Message-Id: <199510290554.WAA03343@corbin.Root.COM> To: Brian Tao cc: FREEBSD-HACKERS-L Subject: Re: panic: free vnode isn't In-reply-to: Your message of "Sun, 29 Oct 95 01:47:02 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 28 Oct 1995 22:54:25 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk > At least it has been isolated to an NFS-related bug. :) The >server died again today (2.0.5R was installed on it), but this time it >managed to send a message to the console before keeling over >completely: > >biodone: page busy < 0, off: 3162112, foff: 3162112, resid: 4096, index: 0 >iozone: 8192, lblkno: 386 >valid: 0xff, dirty: 0x0, mapped: 0 >panic: biodone: page busy < 0 Yes, this particular bug has already been fixed... > If this incarnation survives for a week, then I'll try moving the >FTP service back on and take it from there. Oh, I'm getting "nfs send >error 55" in syslog quite often... is this a symptom of an overrun >buffer? I should add that the collision rate on our LAN averages 50% >and can spike above 100%. It's absolutely horrid, but I hope it isn't >the cause of the kernel panics. Yeah, I see similarly high collision rates on wcarchive's ethernet - but this isn't a surprise with 325 users banging on it. :-) -DG From owner-freebsd-hackers Sat Oct 28 23:21:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA01423 for hackers-outgoing; Sat, 28 Oct 1995 23:21:46 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA01413 for ; Sat, 28 Oct 1995 23:21:33 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA26463; Sun, 29 Oct 1995 17:17:32 +1100 Date: Sun, 29 Oct 1995 17:17:32 +1100 From: Bruce Evans Message-Id: <199510290617.RAA26463@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, henrich@crh.cl.msu.edu Subject: Re: LINT addition please Sender: owner-hackers@freebsd.org Precedence: bulk ># MAXMEM Specified the maximum amount of ram in the system in kilobytes. Only ># use this if your BIOS is broken (I.e. Compaq's). You can specify as Compaq's BIOS support isn't broken. FreeBSD's BIOS support is broken and fails on recalcitrant machines with < 64M and on all machines with >= 64M. Bruce