From owner-freebsd-hackers Sun Dec 7 01:22:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA29405 for hackers-outgoing; Sun, 7 Dec 1997 01:22:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA29400 for ; Sun, 7 Dec 1997 01:22:12 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: by outmail.utsunomiya-u.ac.jp id AA20035; Sun, 7 Dec 1997 18:22:00 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id SAA13504; Sun, 7 Dec 1997 18:28:55 +0900 (JST) Message-Id: <199712070928.SAA13504@zodiac.mech.utsunomiya-u.ac.jp> To: dk+@ua.net Cc: archie@whistle.com (Archie Cobbs), freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: 2.2.5 problems In-Reply-To: Your message of "Sat, 06 Dec 1997 17:16:04 PST." <199712070116.RAA04103@dog.farm.org> References: <199712070116.RAA04103@dog.farm.org> Date: Sun, 07 Dec 1997 18:28:54 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > what's wrong with just running 'startx' to start X AND start some >> > xterms? >> > integrates steps 2,3,4 & 5 > >> Nothing. I already have a workaround; that's not the point. >> We're trying to identify a bug. > >to add to this: > >I _always_ had the problem with syscons driver locking up keyboard >completely while X server is starting and I press alt-ctrl-Fn to switch >to text screen. I had this problem on _all_ freebsd machines running >X that I ever had, back to 2.1 days, up to 2.2-stable with XFree 3.3. > >one more test case is this: > >run xdm with local X server, or run X server from init (in /etc/ttys); >{ > switch to X server screen (e.g., alt-ctrl-F4); > kill X server by ctrl-alt-backspace > while server is restarting, try to return to text screen by alt-ctrl-F1 > (here, timing is somehow important; you should press these keys > _while_ the new server is starting) >} or { > switch to text screen (alt-ctrl-f1); > kill X server process; > the server is restarting, switching console for you (that's a bug > in X server, IMHO) - just after it switched screens, press alt-ctrl-f1 >} >screen switching locked - all ctrl-alt-Fn keys beep. still can work in X. This is a bug in the XFree86 server; the X server does not respond to the screen switching sequence properly _while_ reseting itself, thus, the console driver is left with intermediate state, thinking that the X server is still in the middle of screen switching process. I filed a bug report on this to XFree86 Inc. >maybe that's a different bug. Yes, it appears. The problem reported by archie@whistle.com seems to be different from the above bug ;-< Kazu From owner-freebsd-hackers Sun Dec 7 02:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03203 for hackers-outgoing; Sun, 7 Dec 1997 02:50:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA03169 for ; Sun, 7 Dec 1997 02:49:55 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id CAA25498; Sun, 7 Dec 1997 02:49:26 -0800 (PST) Message-ID: <19971207024925.07278@hydrogen.nike.efn.org> Date: Sun, 7 Dec 1997 02:49:25 -0800 From: John-Mark Gurney To: Paul Traina Cc: Charles Mott , Doug White , hackers@FreeBSD.ORG Subject: Re: metricom & freebsd References: <199712060649.WAA20382@precipice.shockwave.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712060649.WAA20382@precipice.shockwave.com>; from Paul Traina on Fri, Dec 05, 1997 at 10:49:46PM -0800 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Paul Traina scribbled this message on Dec 5: > FYI, someone pointed me at (wow!) a NetBSD STAR mode driver. That's close > enough that I may just get it up and running some time I'm flying off on a > plane somewhere. I started looking at the netbsd driver... it'll take some work getting it into the FreeBSD framework.. but so far, it doesn't look that hard.. there so far has been a few minor nits with the code... but I am almost half way through reading over the code... there are a few things that I'm going to change from the driver before thinking about committing.. just minor design issues... the thing is that it only supports inet for transport... it shouldn't be that hard to try and support other modes like IPX and Appletalk... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Sun Dec 7 03:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04228 for hackers-outgoing; Sun, 7 Dec 1997 03:20:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA04221; Sun, 7 Dec 1997 03:20:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id LAA05153; Sun, 7 Dec 1997 11:18:57 GMT Date: Sun, 7 Dec 1997 11:18:57 +0000 (GMT) From: Doug Rabson To: John Birrell cc: Nate Williams , tlambert@primenet.com, jkh@time.cdrom.com, mike@smith.net.au, hsu@freebsd.org, hackers@hub.freebsd.org Subject: Re: shared library with static Motif? In-Reply-To: <199712070015.LAA01594@freebsd1.cimlogic.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 7 Dec 1997, John Birrell wrote: > Nate Williams wrote: > > But, aside from legalities the real issue hasn't been answered. Is it > > *technically* possible to link in a 'static' library into a 'shared' > > library so that the end-user doesn't need a Motif library to get access > > to the shared library? > > Yes (I think 8-). You still use ld -Bshareable so that you get a shared > object, but you list the Motif static libraries with the objects that you > link into your shared library. The linker (should) then resolve all Motif > references in your shared library, leaving the X11 ones as external > references to the X shared libraries. > > Just don't use the -l option to search for libraries because ld will > try to translate these to shared libraries. Use an explicit reference > like /usr/lib/X11/libXm.a The problem with linking a dynamic library with a static one is that the object files in the static lib will not normally be compiled with -fpic and so the resulting shared object will have a lot of text relocations. This will still work but will not share particularly well since the runtime linker will have to write into the text section to fix the text relocations. The normal solution to this is to have a static lib containing PIC objects (e.g. /usr/lib/libc_pic.a). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 From owner-freebsd-hackers Sun Dec 7 08:25:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA06202 for hackers-outgoing; Sun, 7 Dec 1997 08:25:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA06180 for ; Sun, 7 Dec 1997 08:25:37 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id LAA17544; Sun, 7 Dec 1997 11:24:11 -0500 (EST) Date: Sun, 7 Dec 1997 11:24:11 -0500 (EST) From: John Fieber To: David Greenman cc: Thomas David Rivers , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: <199712070158.RAA29662@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 6 Dec 1997, David Greenman wrote: > > But... the 2.2.5 release of machdep.c doesn't include "opt_cpu.h", > >thus, I586_CPU isn't defined... so the F00F workaround doesn't get > >compiled in... (perhaps somewhere after the 2.2.5-RELEASE cut, this > >include was added?) > > This was fixed yesterday in 2.2-stable by jmg. The patch in the updates directory on ftp.freebsd.org should be updated. The errata says: o Intel "F00F bug" enables users to hang machines with Pentium processors if they have access to the machine and can execute programs. Fix: Update to the 2.2-stable version of the kernel or apply the patch found in: ftp://ftp.freebsd.org/pub/FreeBSD/2.2.5-RELEASE/updates/f00f.diff.2.2 -john From owner-freebsd-hackers Sun Dec 7 09:26:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09719 for hackers-outgoing; Sun, 7 Dec 1997 09:26:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09671; Sun, 7 Dec 1997 09:25:35 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id PAA17469; Sun, 7 Dec 1997 15:25:33 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199712071725.PAA17469@gaia.coppe.ufrj.br> Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c In-Reply-To: <199712070809.AAA01213@freefall.freebsd.org> from Kazutaka YOKOTA at "Dec 7, 97 00:09:21 am" To: yokota@FreeBSD.ORG (Kazutaka YOKOTA) Date: Sun, 7 Dec 1997 15:25:33 -0200 (EDT) Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Kazutaka YOKOTA) // - The `psm' driver is made to recognize various models of PS/2 mice // and enable their extra features so that their additional buttons and // wheel/roller are recognized. The name of the detected model will be // printed at boot time. How much memory does this model info waste ? I don't like the ideia of using kernel memory (which cannot yet be swapped out) for something almost useless. This (and also the VGA type info) could be in some memory area that could later be released for VM usage. Something like pre-alocated VM pages, disposable after booting. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Sun Dec 7 10:56:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14410 for hackers-outgoing; Sun, 7 Dec 1997 10:56:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA14343 for ; Sun, 7 Dec 1997 10:55:10 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id UAA06227; Sun, 7 Dec 1997 20:53:41 +0200 (SAT) From: John Hay Message-Id: <199712071853.UAA06227@zibbi.mikom.csir.co.za> Subject: Re: IP/IPX routing In-Reply-To: from Jaroslav Klaus at "Dec 5, 97 11:03:00 pm" To: J.Klaus@sh.cvut.cz (Jaroslav Klaus) Date: Sun, 7 Dec 1997 20:53:41 +0200 (SAT) Cc: FreeBSD-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jarda, > I have inet/ipx network like this (only fragment): > > II I 1 ... Novell 3.12 > | ------- | 2 ... MS DOS/Win95/WinNT user + NW > ------- | | | | 3 ... my FreeBSD 2.2.2 box > | | | | 2 |---| 4 ... MS DOS/Win95/WinNT user + NW > | 4 |---| | | | ------- > | | | ------- | | | > ------- | |---| 1 |--> INTERNET > | ------- | | | > | | | | ------- network: > |---| 3 |---| I ... ipx: 337b030 > | | | | inet mask: /27 > ------- | II ... ipx: 337b031 > | inet mask: /30 > . | > . | > . > BUT look at ed1 MAC address - the same as ed0. What's wrong? > > ed0: flags=8843 mtu 1500 > inet 194.108.141.148 netmask 0xffffffe0 broadcast 194.108.141.159 > ipx 337b030.b472aa83 > ether 00:00:b4:72:aa:83 > ed1: flags=8843 mtu 1500 > inet 194.108.141.157 netmask 0xfffffffc broadcast 194.108.141.159 > ipx 337b031.b472aa83 > ^^^^^^^^ > ether 00:40:95:13:8f:77 This is because you are probably using FreeBSD 2.2.2 or older. In those versions the IPX code used the same MAC address on all interfaces with varying degrees of success. It is fixed in 2.2.5 and later. > Q1: Could I add record to ipx routing table manually (not by IPXrouted)? Well you should be able to, but route(8) does not know about the IPX protocol yet. > Q2: And could I specify record in ipx routing table only for one MAC adress? While the routing table code will probably be able to handle it, I doubt if the rest of the IPX networking will. > Q3: Will machine No.4 be able to attach Novell server No.1 ? If everything is configured correctly it should be able to yes. > Q4: Is it possible to configure Network II to be also Network I for ipx? > I want to have only 1 logical segment No. 337b030 (Network I) composed > of two physical Networks I & II. This will be a time restricted > configuration for games... (I know all needed MAC address) It sounds like you are not looking for a router, but a bridge? :-) Why is it important to have the same net address? There are 4G of them. > Q5: How could I specify gateway by MAC address in inet routing table (like > 194.108.141.148 0:0:b4:72:aa:83)? That is probably the arp code that also use routing tables to speed things up, but that is only my guess. > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 194.108.141.129 UGSc 11 45 ed0 > 127.0.0.1 127.0.0.1 UH 0 67 lo0 > 194.108.141.128/27 link#1 UC 0 0 > 194.108.141.129 0:0:e8:da:e5:fa UHLW 10 0 ed0 1102 > 194.108.141.148 0:0:b4:72:aa:83 UHLW 1 4551 lo0 > 194.108.141.156/30 link#2 UC 0 0 > --- PS. Remember that the FreeBSD IPX code only supports Ethernet_II frames. John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Sun Dec 7 12:14:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18404 for hackers-outgoing; Sun, 7 Dec 1997 12:14:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18397; Sun, 7 Dec 1997 12:14:21 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA13248; Sun, 7 Dec 1997 13:26:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd013237; Sun Dec 7 13:26:46 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA27830; Sun, 7 Dec 1997 13:13:34 -0700 (MST) From: Terry Lambert Message-Id: <199712072013.NAA27830@usr02.primenet.com> Subject: Re: shared library with static Motif? To: nate@mt.sri.com (Nate Williams) Date: Sun, 7 Dec 1997 20:13:34 +0000 (GMT) Cc: tlambert@primenet.com, jkh@time.cdrom.com, mike@smith.net.au, hsu@FreeBSD.ORG, hackers@hub.freebsd.org In-Reply-To: <199712062317.QAA06878@mt.sri.com> from "Nate Williams" at Dec 6, 97 04:17:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But, aside from legalities the real issue hasn't been answered. Is it > *technically* possible to link in a 'static' library into a 'shared' > library so that the end-user doesn't need a Motif library to get access > to the shared library? Yes. There are about 5 ways I can think of off the top of my head, starting with a proxy server that you IPC to to get the desired effect. Actually, you might be able to do this one legally, with high overhead: you could write the proxy server in JAVA. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Dec 7 12:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18628 for hackers-outgoing; Sun, 7 Dec 1997 12:17:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18601; Sun, 7 Dec 1997 12:17:17 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA10344; Sun, 7 Dec 1997 13:28:10 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd010335; Sun Dec 7 13:28:07 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA28018; Sun, 7 Dec 1997 13:16:37 -0700 (MST) From: Terry Lambert Message-Id: <199712072016.NAA28018@usr02.primenet.com> Subject: Re: shared library with static Motif? To: mike@smith.net.au (Mike Smith) Date: Sun, 7 Dec 1997 20:16:37 +0000 (GMT) Cc: nate@mt.sri.com, tlambert@primenet.com, jkh@time.cdrom.com, mike@smith.net.au, hsu@FreeBSD.ORG, hackers@hub.freebsd.org In-Reply-To: <199712070640.RAA00701@word.smith.net.au> from "Mike Smith" at Dec 7, 97 05:10:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > But, aside from legalities the real issue hasn't been answered. Is it > > *technically* possible to link in a 'static' library into a 'shared' > > library so that the end-user doesn't need a Motif library to get access > > to the shared library? > > Fairly obviously, no. Shared libraries are built PIC, as their load > address is not known (and may vary across different mappings of a given > copy). Static libraries are fixed up at link time, as offsets in them > are relative to their position in the executable, which is loaded at a > known (fixed) address. rpc.motifd Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Dec 7 12:31:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19644 for hackers-outgoing; Sun, 7 Dec 1997 12:31:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tarkin.qualcomm.com (tarkin.qualcomm.com [129.46.111.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19614; Sun, 7 Dec 1997 12:30:37 -0800 (PST) (envelope-from rmallory@qualcomm.com) Received: (from rmallory@localhost) by tarkin.qualcomm.com (8.8.5/1.4/8.7.2/1.13) id MAA15886; Sun, 7 Dec 1997 12:26:44 -0800 (PST) From: Rob Mallory Message-Id: <199712072026.MAA15886@tarkin.qualcomm.com> Subject: Re: AFS for FreeBSD - OK, I think we're ready! In-Reply-To: <199712070223.VAA11570@dyson.iquest.net> from "John S. Dyson" at "Dec 6, 97 09:23:12 pm" To: dyson@freebsd.org Date: Sun, 7 Dec 1997 12:26:44 -0800 (PST) Cc: hackers@freebsd.org, freebsd-afs@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John Dyson said: > I just took a look at the CODA stuff, and noticed the FreeBSD name in > some of it. It really shouldn't be too hard to get it working, but I > don't know enough to accurately make that judgement. If you have some > work that appears to be close, maybe I can help and take a look at it? > > (I only have about 10% time to work on it :-(, but I do think that this > is important.) (here is 1/2 of 1% you can spend right now ;-) OK, I spent a few minutes bringing my old stuff up to -current. John, can you review/commit these diffs? Getting these out of the way now makes porting much easier... If the syscall id numbers conflict with the AFS numbers, go ahead and bump them up. -rob [rmallory@Qualcomm.com] diff -r -c -d -C 2 -P sys.orig/conf/files sys/conf/files *** sys.orig/conf/files Tue Dec 2 13:26:31 1997 --- sys/conf/files Sun Dec 7 11:28:07 1997 *************** *** 14,17 **** --- 14,23 ---- clean "aic7xxx_seq.h aic7xxx_reg.h" \ dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/scsi/scsi_message.h aicasm" + cfs/cfs_namecache.c optional vcfs + cfs/cfs_nbsd.c optional vcfs + cfs/cfs_psdev.c optional vcfs + cfs/cfs_subr.c optional vcfs + cfs/cfs_vfsops.c optional vcfs + cfs/cfs_vnodeops.c optional vcfs ddb/db_access.c optional ddb ddb/db_aout.c optional ddb diff -r -c -d -C 2 -P sys.orig/i386/conf/files.i386 sys/i386/conf/files.i386 *** sys.orig/i386/conf/files.i386 Mon Dec 1 01:29:50 1997 --- sys/i386/conf/files.i386 Sun Dec 7 11:30:51 1997 *************** *** 304,305 **** --- 304,312 ---- gnu/i386/isa/dgb.c optional dgb device-driver pci/ide_pci.c optional wd device-driver + cfs/cfs_subr.c optional vcfs + cfs/cfs_namecache.c optional vcfs + cfs/cfs_vfsops.c optional vcfs + cfs/cfs_nbsd.c optional vcfs + cfs/cfs_vnodeops.c optional vcfs + cfs/cfs_psdev.c optional vcfs + diff -r -c -d -C 2 -P sys.orig/kern/init_sysent.c sys/kern/init_sysent.c *** sys.orig/kern/init_sysent.c Sun Oct 26 12:28:51 1997 --- sys/kern/init_sysent.c Sun Dec 7 11:24:55 1997 *************** *** 266,269 **** --- 266,281 ---- { 0, (sy_call_t *)nosys }, /* 239 = timer_getoverrun */ { 2, (sy_call_t *)nanosleep }, /* 240 = nanosleep */ + #ifdef CFS + { 6, (sys_call_t *)icreate }, /* 241 = icreate */ + { 3, (sys_call_t *)iopen }, /* 242 = iopen */ + { 6, (sys_call_t *)iread }, /* 243 = iread */ + { 6, (sys_call_t *)iwrite }, /* 244 = iwrite */ + { 3, (sys_call_t *)iinc }, /* 245 = iinc */ + { 3, (sys_call_t *)idec }, /* 246 = idec */ + { 4, (sys_call_t *)pioctl }, /* 247 = pioctl */ + { 0, (sy_call_t *)nosys }, /* 248 = unimplemented setpag */ + { 0, (sy_call_t *)nosys }, /* 249 = unimplemented */ + { 3, (sy_call_t *)minherit }, /* 250 = minherit */ + #else /* !CFS */ { 0, (sy_call_t *)nosys }, /* 241 = nosys */ { 0, (sy_call_t *)nosys }, /* 242 = nosys */ *************** *** 276,279 **** --- 288,292 ---- { 0, (sy_call_t *)nosys }, /* 249 = nosys */ { 3, (sy_call_t *)minherit }, /* 250 = minherit */ + #endif /* !CFS */ { 1, (sy_call_t *)rfork }, /* 251 = rfork */ { 3, (sy_call_t *)openbsd_poll }, /* 252 = openbsd_poll */ diff -r -c -d -C 2 -P sys.orig/kern/syscalls.c sys/kern/syscalls.c *** sys.orig/kern/syscalls.c Sun Oct 26 12:28:54 1997 --- sys/kern/syscalls.c Sun Dec 7 11:24:55 1997 *************** *** 255,258 **** --- 255,269 ---- "#239", /* 239 = timer_getoverrun */ "nanosleep", /* 240 = nanosleep */ + #ifdef CFS + "icreate", /* 241 = icreate */ + "iopen", /* 242 = iopen */ + "iread", /* 243 = iread */ + "iwrite", /* 244 = iwrite */ + "iinc", /* 245 = iinc */ + "idec", /* 246 = idec */ + "pioctl", /* 247 = pioctl */ + "#248", /* 248 = unimplemented setpag */ + "#249", /* 249 = unimplemented */ + #else /* !CFS */ "#241", /* 241 = nosys */ "#242", /* 242 = nosys */ *************** *** 264,267 **** --- 275,279 ---- "#248", /* 248 = nosys */ "#249", /* 249 = nosys */ + #endif /* !CFS */ "minherit", /* 250 = minherit */ "rfork", /* 251 = rfork */ diff -r -c -d -C 2 -P sys.orig/kern/syscalls.master sys/kern/syscalls.master *** sys.orig/kern/syscalls.master Sun Oct 26 12:27:51 1997 --- sys/kern/syscalls.master Sun Dec 7 11:24:55 1997 *************** *** 382,385 **** --- 382,403 ---- 240 STD POSIX { int nanosleep(const struct timespec *rqtp, \ struct timespec *rmtp); } + ; system calls 241-249 reserved for Coda File System + #ifdef CFS + 241 STD { int sys_icreate(int dev, int near_inode, int param1, \ + int param2, int param3, int param4); } + 242 STD { int sys_iopen(int dev, int inode, int usermode); } + 243 STD { int sys_iread(int dev, int inode, long inode_p1, \ + unsigned int offset, char *cbuf, \ + unsigned int count); } + 244 STD { int sys_iwrite(int dev, int inode, long inode_p1, \ + unsigned int offset, char *cbuf, \ + unsigned int count); } + 245 STD { int sys_iinc(int dev, int inode, long inode_p1); } + 246 STD { int sys_idec(int dev, int inode, long inode_p1); } + 247 STD { int sys_pioctl(char *path, int com, caddr_t comarg, \ + int follow); } + 248 UNIMPL setpag + 249 UNIMPL + #else /* !CFS */ 241 UNIMPL NOHIDE nosys 242 UNIMPL NOHIDE nosys *************** *** 391,394 **** --- 409,413 ---- 248 UNIMPL NOHIDE nosys 249 UNIMPL NOHIDE nosys + #endif /* !CFS */ ; syscall numbers initially used in OpenBSD 250 STD BSD { int minherit(caddr_t addr, size_t len, int inherit); } diff -r -c -d -C 2 -P sys.orig/sys/mount.h sys/sys/mount.h *** sys.orig/sys/mount.h Mon Nov 24 23:07:47 1997 --- sys/sys/mount.h Sun Dec 7 11:24:14 1997 *************** *** 108,112 **** #define MOUNT_EXT2FS 17 /* Linux EXT2FS */ #define MOUNT_TFS 18 /* Netcon Novell filesystem */ ! #define MOUNT_MAXTYPE 18 #define INITMOUNTNAMES { \ --- 108,113 ---- #define MOUNT_EXT2FS 17 /* Linux EXT2FS */ #define MOUNT_TFS 18 /* Netcon Novell filesystem */ ! #define MOUNT_CFS 19 /* Coda Filesystem */ ! #define MOUNT_MAXTYPE 19 #define INITMOUNTNAMES { \ *************** *** 130,134 **** "ext2fs", /* 17 MOUNT_EXT2FS */ \ "tfs", /* 18 MOUNT_TFS */ \ ! 0, /* 18 MOUNT_SPARE */ \ } --- 131,136 ---- "ext2fs", /* 17 MOUNT_EXT2FS */ \ "tfs", /* 18 MOUNT_TFS */ \ ! "cfs", /* 19 MOUNT_TFS */ \ ! 0, /* 19 MOUNT_SPARE */ \ } diff -r -c -d -C 2 -P sys.orig/sys/syscall.h sys/sys/syscall.h *** sys.orig/sys/syscall.h Sun Oct 26 12:28:41 1997 --- sys/sys/syscall.h Sun Dec 7 11:24:14 1997 *************** *** 241,243 **** #define SYS_munlockall 325 #define SYS___getcwd 326 ! #define SYS_MAXSYSCALL 327 --- 241,250 ---- #define SYS_munlockall 325 #define SYS___getcwd 326 ! #define SYS_icreate 327 ! #define SYS_iopen 328 ! #define SYS_iread 329 ! #define SYS_iwrite 330 ! #define SYS_iinc 331 ! #define SYS_idec 332 ! #define SYS_pioctl 333 ! #define SYS_MAXSYSCALL 334 diff -r -c -d -C 2 -P sys.orig/sys/sysproto.h sys/sys/sysproto.h *** sys.orig/sys/sysproto.h Thu Nov 6 11:29:49 1997 --- sys/sys/sysproto.h Sun Dec 7 11:24:14 1997 *************** *** 736,739 **** --- 736,783 ---- struct timespec * rmtp; }; + struct icreate_args { + int dev; + int near_inode; + int param1; + int param2; + int param3; + int param4; + }; + struct iopen_args { + int dev; + int inode; + int usermode; + }; + struct iread_args { + int dev; + int inode; + long inode_p1; + unsigned int offset; + char * cbuf; + }; + struct iwrite_args { + int dev; + int inode; + long inode_p1; + unsigned int offset; + char * cbuf; + unsigned int count; + }; + struct iinc_args { + int dev; + int inode; + long inode_p1; + }; + struct idec_args { + int dev; + int inode; + long inode_p1; + }; + struct pioctl_args { + char * path; + int com; + caddr_t comarg; + int follow; + }; struct minherit_args { caddr_t addr; diff -r -c -d -C 2 -P sys.orig/sys/vnode.h sys/sys/vnode.h *** sys.orig/sys/vnode.h Fri Dec 5 11:55:49 1997 --- sys/sys/vnode.h Sun Dec 7 11:24:14 1997 *************** *** 61,65 **** VT_NON, VT_UFS, VT_NFS, VT_MFS, VT_PC, VT_LFS, VT_LOFS, VT_FDESC, VT_PORTAL, VT_NULL, VT_UMAP, VT_KERNFS, VT_PROCFS, VT_AFS, VT_ISOFS, ! VT_UNION, VT_MSDOSFS, VT_DEVFS, VT_TFS }; --- 61,65 ---- VT_NON, VT_UFS, VT_NFS, VT_MFS, VT_PC, VT_LFS, VT_LOFS, VT_FDESC, VT_PORTAL, VT_NULL, VT_UMAP, VT_KERNFS, VT_PROCFS, VT_AFS, VT_ISOFS, ! VT_UNION, VT_MSDOSFS, VT_DEVFS, VT_TFS, VT_CFS }; *** dinode.h Sat Feb 22 01:47:37 1997 --- dinode.h.coda Sun Sep 28 15:06:45 1997 diff -r -c -d -C 2 -P sys.orig/ufs/ufs/dinode.h sys/ufs/ufs/dinode.h *** sys.orig/ufs/ufs/dinode.h Sat Feb 22 01:47:37 1997 --- sys/ufs/ufs/dinode.h Sun Sep 28 15:06:45 1997 *************** *** 75,80 **** --- 75,83 ---- union { u_int16_t oldids[2]; /* 4: Ffs: old user and group ids. */ int32_t inumber; /* 4: Lfs: inode number. */ + #ifdef CFS + int32_t volumeid; /* 4: Coda volume number */ + #endif CFS } di_u; u_int64_t di_size; /* 8: File byte count. */ int32_t di_atime; /* 16: Last access time. */ From owner-freebsd-hackers Sun Dec 7 12:31:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19690 for hackers-outgoing; Sun, 7 Dec 1997 12:31:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19670; Sun, 7 Dec 1997 12:31:08 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA12187; Sun, 7 Dec 1997 13:42:01 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd012146; Sun Dec 7 13:41:53 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA28719; Sun, 7 Dec 1997 13:30:24 -0700 (MST) From: Terry Lambert Message-Id: <199712072030.NAA28719@usr02.primenet.com> Subject: Re: shared library with static Motif? To: hsu@FreeBSD.ORG (Jeffrey Hsu) Date: Sun, 7 Dec 1997 20:30:24 +0000 (GMT) Cc: jkh@time.cdrom.com, mike@smith.net.au, hackers@hub.freebsd.org, tlambert@primenet.com In-Reply-To: <199712070013.QAA26928@hub.freebsd.org> from "Jeffrey Hsu" at Dec 6, 97 04:13:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That is what I was trying to do. The 2 points I was asking are > o How to do this technically. You get the dreaded RSS relocation > error messages when trying to statically link libXm.a functions > into a shared library. I now believe this is not possible. > o Does this qualify as static linking for redistribution purposes? > If I pulled functions out of libXm.so and combined them into > my liba.so, then the answer is obviously no. Pulling functions > out of libXm.a does not appear to be technically feasible (point > one above). > So it appears that this solution loses on both points. Linking Motif > routines statically into the final executable (rather than an intermediate > shared library) does work okay. I guess I'll have to do it that way. You make a data reference to a routine or datum in each of the .o's in libXm.a, and force the inclusion of your data object by making a non called stub function to reference it: void *library_datum[] = { (void *)datum_from_object_one, (void *)function_from_object_two, (void *)function_from_object_three, ... (void *)datum_from_object_N }; void my_dummy_function( void) { void *save; save = library_datum[ 0]; library_datum[ 0] = library_datum[ 1]; library_datum[ 1] = save; } The function reference from a non-library .o drags in the things it references from libXm.a. When you link, link ld -r and link with the .a instead of as a lib so that no relocation is done on the Motif library. You now have an object which includes the Motif library. Archive the object in your library. You now have a library which includes Motif. If you are ill, instead of making data references, you can make function references using stub functions. You can link the Motif library high in the program address space so it is unlikely to collide with data or code from a user program. Then the library can stay "shared". I still don't think this is within the terms of the license. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Dec 7 13:14:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23189 for hackers-outgoing; Sun, 7 Dec 1997 13:14:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA23171 for ; Sun, 7 Dec 1997 13:14:05 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id NAA08160; Sun, 7 Dec 1997 13:13:58 -0800 (PST) (envelope-from jdp) Message-Id: <199712072113.NAA08160@austin.polstra.com> To: jbryant@unix.tfs.net Subject: Re: CVS tags (was: Re: emacs core dumping on -current?) In-Reply-To: <199712041259.GAA24107@unix.tfs.net> References: <199712041259.GAA24107@unix.tfs.net> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Sun, 07 Dec 1997 13:13:58 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199712041259.GAA24107@unix.tfs.net>, Jim Bryant wrote: > > Does this imply that if you specify an invalid tag to cvs, it just > > ignores it? > > > > Greg > > nope... it just sends you -current! It's not clear whether you were talking about cvs or CVSup, but in either case that answer is incorrect. If you specify an invalid tag to cvs, it will complain that the tag is invalid and quit. If you specify an invalid tag to CVSup, it will give you no files. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Sun Dec 7 13:43:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA25206 for hackers-outgoing; Sun, 7 Dec 1997 13:43:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA25195; Sun, 7 Dec 1997 13:43:46 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id IAA08041; Sun, 7 Dec 1997 08:15:22 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd008035; Sun Dec 7 08:15:19 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA02196; Sun, 7 Dec 1997 14:43:10 -0700 (MST) From: Terry Lambert Message-Id: <199712072143.OAA02196@usr02.primenet.com> Subject: Re: AFS for FreeBSD - OK, I think we're ready! To: rmallory@qualcomm.com (Rob Mallory) Date: Sun, 7 Dec 1997 21:43:10 +0000 (GMT) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG In-Reply-To: <199712072026.MAA15886@tarkin.qualcomm.com> from "Rob Mallory" at Dec 7, 97 12:26:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > + #ifdef CFS > + { 6, (sys_call_t *)icreate }, /* 241 = icreate */ > + { 3, (sys_call_t *)iopen }, /* 242 = iopen */ > + { 6, (sys_call_t *)iread }, /* 243 = iread */ > + { 6, (sys_call_t *)iwrite }, /* 244 = iwrite */ > + { 3, (sys_call_t *)iinc }, /* 245 = iinc */ > + { 3, (sys_call_t *)idec }, /* 246 = idec */ > + { 4, (sys_call_t *)pioctl }, /* 247 = pioctl */ > + { 0, (sy_call_t *)nosys }, /* 248 = unimplemented setpag */ > + { 0, (sy_call_t *)nosys }, /* 249 = unimplemented */ > + { 3, (sy_call_t *)minherit }, /* 250 = minherit */ > + #else /* !CFS */ I don't suppose you'd be willing to change this to: { 7, (sys_call_t *)coda }, /* 241 = coda*/ And then wrap them: int icreate( a1, a2, a3, a4, a5, a6) { return coda( CODA_ICREATE, a1, a2, a3, a4, a5, a6); } int iopen( a1, a2, a3) { return coda( CODA_IOPEN, a1, a2, a3, 0, 0, 0); } Etc.? Taking up that many call slots is a bit painful... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Dec 7 15:58:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05113 for hackers-outgoing; Sun, 7 Dec 1997 15:58:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA05099; Sun, 7 Dec 1997 15:58:21 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: by outmail.utsunomiya-u.ac.jp id AA20724; Mon, 8 Dec 1997 08:54:25 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id JAA28710; Mon, 8 Dec 1997 09:01:20 +0900 (JST) Message-Id: <199712080001.JAA28710@zodiac.mech.utsunomiya-u.ac.jp> To: Joao Carlos Mendes Luis Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org, hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c In-Reply-To: Your message of "Sun, 07 Dec 1997 15:25:33 -0200." <199712071725.PAA17469@gaia.coppe.ufrj.br> References: <199712071725.PAA17469@gaia.coppe.ufrj.br> Date: Mon, 08 Dec 1997 09:01:19 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >// - The `psm' driver is made to recognize various models of PS/2 mice >// and enable their extra features so that their additional buttons and >// wheel/roller are recognized. The name of the detected model will be >// printed at boot time. > >How much memory does this model info waste ? int*5 = 20 bytes >I don't like the ideia of using kernel memory (which cannot yet be >swapped out) for something almost useless. In general, I agree that the kernel shouldn't waste memory. But, the `psm' driver's info is NOT useless. I didn't add it just for fun. It is used by `moused' and possibly by the X server (I have contacted XFree86 people on this issue). Recent PS/2 mice with wheels and additional buttons use vairous proprietary data formats to report wheel/button events. Therefore it is essential to know which model of mice is attached to the system in order to decode mouse data. >This (and also the VGA type info) could be in some memory area that ~~~~~~~~~~~~~~~~~ Which info are you talking about? I don't think the console driver currently distinguishes VGA types. >could later be released for VM usage. Something like pre-alocated >VM pages, disposable after booting. > > Jonny Kazu From owner-freebsd-hackers Sun Dec 7 16:17:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06364 for hackers-outgoing; Sun, 7 Dec 1997 16:17:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06345; Sun, 7 Dec 1997 16:16:57 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id WAA22731; Sun, 7 Dec 1997 22:16:46 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199712080016.WAA22731@gaia.coppe.ufrj.br> Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c In-Reply-To: <199712080001.JAA28710@zodiac.mech.utsunomiya-u.ac.jp> from Kazutaka YOKOTA at "Dec 8, 97 09:01:19 am" To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Sun, 7 Dec 1997 22:16:46 -0200 (EDT) Cc: jonny@coppe.ufrj.br, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org, hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #define quoting(Kazutaka YOKOTA) // >// - The `psm' driver is made to recognize various models of PS/2 mice // >// and enable their extra features so that their additional buttons and // >// wheel/roller are recognized. The name of the detected model will be // >// printed at boot time. // > // >How much memory does this model info waste ? // // int*5 = 20 bytes // // >I don't like the ideia of using kernel memory (which cannot yet be // >swapped out) for something almost useless. // // In general, I agree that the kernel shouldn't waste memory. But, the // `psm' driver's info is NOT useless. I didn't add it just for fun. It // is used by `moused' and possibly by the X server (I have contacted // XFree86 people on this issue). You said it would be "printed", so I imagine an array of strings. Obviously, an (int) for type identifying by programs is useful. // >This (and also the VGA type info) could be in some memory area that // ~~~~~~~~~~~~~~~~~ // Which info are you talking about? I don't think the console driver // currently distinguishes VGA types. Take a look at the vga_probe() routine, in sys/pci/pcisupport.c ($Id: pcisupport.c,v 1.58 1997/11/11 01:50:06 wollman Exp $) It is in ftp.freebsd.org -current sources tree right now. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Sun Dec 7 16:18:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06511 for hackers-outgoing; Sun, 7 Dec 1997 16:18:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06503; Sun, 7 Dec 1997 16:18:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id AAA07847; Mon, 8 Dec 1997 00:18:26 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA10105; Mon, 8 Dec 1997 01:17:57 +0100 (MET) To: Brian Somers Cc: freebsd-hackers@FreeBSD.ORG Subject: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) References: <199712070409.UAA29789@freefall.freebsd.org> From: Eivind Eklund Date: 08 Dec 1997 01:17:56 +0100 In-Reply-To: Brian Somers's message of Sat, 6 Dec 1997 20:09:16 -0800 (PST) Message-ID: <8690twpu17.fsf@bitbox.follo.net> Lines: 36 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Somers writes: > brian 1997/12/06 20:09:16 PST > > Modified files: > usr.sbin/ppp command.c ppp.8 route.c > Log: > Only allow one arg to `delete' - the mask & gateway aren't necessary. > Delete AF_LINK routes as well as AF_INET. > Allow the word `default' as the arg to `delete' or in place of the > first two args (dest & netmask) to `add'. > Accept INTERFACE as the third arg to `add'. > > You can now say `add default interface' to create a default route > through the tun interface. It's reported that subsequent bind()s > will bind to a broadcast address and not to the address currently > assigned to the tun device - this is the first step towards > supporting that first connection that was around from before the > dynamic IP negotiation.... I've been thinking a bit more about it, and now I consider this binding a bug. With an interface route to an interface with no assigned address, we're actually sending packets onto the network that hasn't got a legit source address. This works for the single case where there is a NAT engine at the other end of that link, but that is also the _only_ case it works for. I'm still a bit uncertain about what would be the best approach - probably binding to another interface in the machine. That's weird too, but probably less surprising never the less What do other people think? Is this feasible given the way routing is implemented in the FreeBSD kernel? Eivind. From owner-freebsd-hackers Sun Dec 7 16:19:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06645 for hackers-outgoing; Sun, 7 Dec 1997 16:19:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tarkin.qualcomm.com (tarkin.qualcomm.com [129.46.111.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06612; Sun, 7 Dec 1997 16:19:43 -0800 (PST) (envelope-from rmallory@qualcomm.com) Received: (from rmallory@localhost) by tarkin.qualcomm.com (8.8.5/1.4/8.7.2/1.13) id QAA17518; Sun, 7 Dec 1997 16:15:33 -0800 (PST) From: Rob Mallory Message-Id: <199712080015.QAA17518@tarkin.qualcomm.com> Subject: Re: AFS for FreeBSD - OK, I think we're ready!gy In-Reply-To: <199712072143.OAA02196@usr02.primenet.com> from Terry Lambert at "Dec 7, 97 09:43:10 pm" To: tlambert@primenet.com (Terry Lambert) Date: Sun, 7 Dec 1997 16:15:33 -0800 (PST) Cc: dyson@freebsd.org, hackers@freebsd.org, freebsd-afs@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Agreed, but to tell you the truth, at this point its a bit over my head. I'll leave it up to whomever does the commit, as long as the functionality and API remains the same.. in addition to those patches, I also got lost on the malloc.h, there used to be a couple lines which could be added like this: + #define M_CFS 93 /* Coda file system structures and tables. */ + "cfs", /* 93 M_CFS */ \ + MALLOC_MAKE_TYPE(M_CFS, "CFS", "CFS header"); ...Where do those now go? Since Coda is freely redistributeable, I'll post a Coda-kit howto + patches to in a bit. That way people can easily get up to speed and help out! -Rob > > I don't suppose you'd be willing to change this to: > > { 7, (sys_call_t *)coda }, /* 241 = coda*/ > > And then wrap them: > > int > icreate( a1, a2, a3, a4, a5, a6) > { > return coda( CODA_ICREATE, a1, a2, a3, a4, a5, a6); > } > > int > iopen( a1, a2, a3) > { > return coda( CODA_IOPEN, a1, a2, a3, 0, 0, 0); > } > > Etc.? > > Taking up that many call slots is a bit painful... > > From owner-freebsd-hackers Sun Dec 7 17:07:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10430 for hackers-outgoing; Sun, 7 Dec 1997 17:07:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA10414; Sun, 7 Dec 1997 17:07:30 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: by outmail.utsunomiya-u.ac.jp id AA21100; Mon, 8 Dec 1997 10:07:16 +0900 Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id KAA00192; Mon, 8 Dec 1997 10:14:01 +0900 (JST) Message-Id: <199712080114.KAA00192@zodiac.mech.utsunomiya-u.ac.jp> To: Joao Carlos Mendes Luis Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org, hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c In-Reply-To: Your message of "Sun, 07 Dec 1997 22:16:46 -0200." <199712080016.WAA22731@gaia.coppe.ufrj.br> References: <199712080016.WAA22731@gaia.coppe.ufrj.br> Date: Mon, 08 Dec 1997 10:13:41 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >// >How much memory does this model info waste ? >// >// int*5 = 20 bytes [snip] > >You said it would be "printed", so I imagine an array of strings. Ah, yes, information is stored in memory for later use AND a human-readable string corresponding to the information is printed. The driver has the following static strings: "NetScroll Mouse", "NetMouse", "GlidePoint", "ThinkingMouse", "IntelliMouse", "MouseMan+", "Generic PS/2 mouse" Maybe you are thinking this is too much? Kazu From owner-freebsd-hackers Sun Dec 7 17:16:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11305 for hackers-outgoing; Sun, 7 Dec 1997 17:16:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from DNS.Lamb.net (root@DNS.Lamb.net [207.90.181.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11212; Sun, 7 Dec 1997 17:15:50 -0800 (PST) (envelope-from ulf@Gatekeeper.Alameda.net) Received: (from uucp@localhost) by DNS.Lamb.net (8.8.6/8.8.6) id RAA22914; Sun, 7 Dec 1997 17:15:52 -0800 (PST) Received: from gatekeeper.Alameda.net(207.90.181.2) via SMTP by DNS.Lamb.net, id smtpd022912; Sun Dec 7 17:15:50 1997 Received: (from ulf@localhost) by Gatekeeper.Alameda.net (8.8.6/8.7.6) id RAA12140; Sun, 7 Dec 1997 17:15:45 -0800 (PST) From: Ulf Zimmermann Message-Id: <199712080115.RAA12140@Gatekeeper.Alameda.net> Subject: Re: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) In-Reply-To: <8690twpu17.fsf@bitbox.follo.net> from Eivind Eklund at "Dec 8, 97 01:17:56 am" To: perhaps@yes.no (Eivind Eklund) Date: Sun, 7 Dec 1997 17:15:45 -0800 (PST) Cc: brian@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Brian Somers writes: > > > brian 1997/12/06 20:09:16 PST > > > > Modified files: > > usr.sbin/ppp command.c ppp.8 route.c > > Log: > > Only allow one arg to `delete' - the mask & gateway aren't necessary. > > Delete AF_LINK routes as well as AF_INET. > > Allow the word `default' as the arg to `delete' or in place of the > > first two args (dest & netmask) to `add'. > > Accept INTERFACE as the third arg to `add'. > > > > You can now say `add default interface' to create a default route > > through the tun interface. It's reported that subsequent bind()s > > will bind to a broadcast address and not to the address currently > > assigned to the tun device - this is the first step towards > > supporting that first connection that was around from before the > > dynamic IP negotiation.... > > I've been thinking a bit more about it, and now I consider this > binding a bug. With an interface route to an interface with no > assigned address, we're actually sending packets onto the network that > hasn't got a legit source address. Looking at Ciscos way, they have the command "ip unnumbered ", which tells the Cisco to use as the source address, the ip of a different interface. Then you can add a route to the unnumbered interface and packets will be sent with the src of the used interface, like: interface ethernet 0 ip address 192.168.1.1 255.255.255.0 interface serial 0 ip unnumbered ethernet 0 ip route 0.0.0.0 0.0.0.0 serial 0 > > This works for the single case where there is a NAT engine at the > other end of that link, but that is also the _only_ case it works for. > > I'm still a bit uncertain about what would be the best approach - > probably binding to another interface in the machine. That's weird > too, but probably less surprising never the less > > What do other people think? Is this feasible given the way routing is > implemented in the FreeBSD kernel? I like the way Cisco is doing it and wouldn't mind to see it on FreeBSD. > > Eivind. > Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 From owner-freebsd-hackers Sun Dec 7 17:17:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11392 for hackers-outgoing; Sun, 7 Dec 1997 17:17:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11320; Sun, 7 Dec 1997 17:16:23 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id BAA12071; Mon, 8 Dec 1997 01:04:39 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199712080104.BAA12071@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Eivind Eklund cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) In-reply-to: Your message of "08 Dec 1997 01:17:56 +0100." <8690twpu17.fsf@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 01:04:39 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Brian Somers writes: > > > brian 1997/12/06 20:09:16 PST > > > > Modified files: > > usr.sbin/ppp command.c ppp.8 route.c > > Log: > > Only allow one arg to `delete' - the mask & gateway aren't necessary. > > Delete AF_LINK routes as well as AF_INET. > > Allow the word `default' as the arg to `delete' or in place of the > > first two args (dest & netmask) to `add'. > > Accept INTERFACE as the third arg to `add'. > > > > You can now say `add default interface' to create a default route > > through the tun interface. It's reported that subsequent bind()s > > will bind to a broadcast address and not to the address currently > > assigned to the tun device - this is the first step towards > > supporting that first connection that was around from before the > > dynamic IP negotiation.... > > I've been thinking a bit more about it, and now I consider this > binding a bug. With an interface route to an interface with no > assigned address, we're actually sending packets onto the network that > hasn't got a legit source address. > > This works for the single case where there is a NAT engine at the > other end of that link, but that is also the _only_ case it works for. Perhaps ppp should automatically replace 255.255.255.255 src addresses with the correct source address.... Is this the IP that gets assigned by the kernel ? I haven't checked - see below. > I'm still a bit uncertain about what would be the best approach - > probably binding to another interface in the machine. That's weird > too, but probably less surprising never the less > > What do other people think? Is this feasible given the way routing is > implemented in the FreeBSD kernel? Well, the only other person that seems even partially interested is Julian (from Whistle). I believe he added the -iface option to route in the first place. That's about all I know of his setup. Others are interested, but I think they'll expect to maintain connections after a carrier loss. It's difficult to make some people understand that the ISP just doesn't route the old connection to you any more - there's nothing that can be done locally. We need a smart radius server...... Me, I'd like to come up with a solution, but I haven't got a setup for assigning dynamic IPs. To this end, I've been looking at the radius port with plans to make ppp fully functional on the server side - I'm not sure if the mpd stuff is more important though. Too much to do and too little time to do it.... nothing new there. I've got a list of other things a mile long too :-/ I'd like to get this ``first connection'' thing working - I'll keep looking at it :-O > Eivind. -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Dec 7 17:30:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12207 for hackers-outgoing; Sun, 7 Dec 1997 17:30:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12192; Sun, 7 Dec 1997 17:30:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA27708; Sun, 7 Dec 1997 17:22:25 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd027706; Sun Dec 7 17:22:17 1997 Date: Sun, 7 Dec 1997 17:19:50 -0800 (PST) From: Julian Elischer To: Eivind Eklund cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) In-Reply-To: <8690twpu17.fsf@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I had changes that made the outgoing packets take the first IP address of the interface if there was no address already bound.. don't know what happenned to them. On 8 Dec 1997, Eivind Eklund wrote: > Brian Somers writes: > > > brian 1997/12/06 20:09:16 PST > > > > Modified files: > > usr.sbin/ppp command.c ppp.8 route.c > > Log: > > Only allow one arg to `delete' - the mask & gateway aren't necessary. > > Delete AF_LINK routes as well as AF_INET. > > Allow the word `default' as the arg to `delete' or in place of the > > first two args (dest & netmask) to `add'. > > Accept INTERFACE as the third arg to `add'. > > > > You can now say `add default interface' to create a default route > > through the tun interface. It's reported that subsequent bind()s > > will bind to a broadcast address and not to the address currently > > assigned to the tun device - this is the first step towards > > supporting that first connection that was around from before the > > dynamic IP negotiation.... > > I've been thinking a bit more about it, and now I consider this > binding a bug. With an interface route to an interface with no > assigned address, we're actually sending packets onto the network that > hasn't got a legit source address. > > This works for the single case where there is a NAT engine at the > other end of that link, but that is also the _only_ case it works for. > > I'm still a bit uncertain about what would be the best approach - > probably binding to another interface in the machine. That's weird > too, but probably less surprising never the less > > What do other people think? Is this feasible given the way routing is > implemented in the FreeBSD kernel? > > Eivind. > From owner-freebsd-hackers Sun Dec 7 17:31:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12319 for hackers-outgoing; Sun, 7 Dec 1997 17:31:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12307; Sun, 7 Dec 1997 17:31:26 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id XAA24122; Sun, 7 Dec 1997 23:31:12 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199712080131.XAA24122@gaia.coppe.ufrj.br> Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c In-Reply-To: <199712080114.KAA00192@zodiac.mech.utsunomiya-u.ac.jp> from Kazutaka YOKOTA at "Dec 8, 97 10:13:41 am" To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Sun, 7 Dec 1997 23:31:12 -0200 (EDT) Cc: jonny@coppe.ufrj.br, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-sys@freebsd.org, hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #define quoting(Kazutaka YOKOTA) // >You said it would be "printed", so I imagine an array of strings. // // Ah, yes, information is stored in memory for later use AND a // human-readable string corresponding to the information is printed. // // The driver has the following static strings: // // "NetScroll Mouse", "NetMouse", "GlidePoint", "ThinkingMouse", // "IntelliMouse", "MouseMan+", "Generic PS/2 mouse" // // Maybe you are thinking this is too much? Sorry if I let you think it was personal. I'm not worried about one or two (or seven :) ) strings in kernel, but with the general growing interest in putting this kind of info in non-swapable memory. It's not a problem if you have a server with lots of memory, but it's a pain for small machines. Unfortunatly, kernel swapping or kernel routines memory disposal is not an easy thing to do. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Sun Dec 7 17:48:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13913 for hackers-outgoing; Sun, 7 Dec 1997 17:48:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tarkin.qualcomm.com (tarkin.qualcomm.com [129.46.111.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13804; Sun, 7 Dec 1997 17:48:03 -0800 (PST) (envelope-from rmallory@qualcomm.com) Received: (from rmallory@localhost) by tarkin.qualcomm.com (8.8.5/1.4/8.7.2/1.13) id RAA18186; Sun, 7 Dec 1997 17:44:11 -0800 (PST) From: Rob Mallory Message-Id: <199712080144.RAA18186@tarkin.qualcomm.com> Subject: Coda startup kit To: hackers@freebsd.org, freebsd-afs@freebsd.org Date: Sun, 7 Dec 1997 17:44:11 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a starter kit to begin work on getting the CODA distributed filesystem integrated into FreeBSD-current. http://coda.cs.cmu.edu/ I've been tracking coda for a couple years, and about 3 months ago, it was looking good enough to pull up the boots and give it a shot. Late September I had a coda-kernel which came real-damn-close to running. ..then I let the bits rust. If anyone else has also been doing the same, Speak up!! (and also tell braam@cs.cmu.edu,inamura@isl.ntt.co.jp) All the userland code should still compile. The kernel code needs a bit of work. "she just needs a Fresh Coat of Paint(tm), and some air for the tires, really!" -Rob Mallory [rmallory@Qualcomm.com] begin 664 coda-4.1.3-f3.kit.2.tar.gz M'XL("%1(BS0"`V-O9&$M-"XQ+C,M9C,N:VET+C(N=&%R`.P]:9/;-K+^*OT* M6'Y5ML<4Q4OG)/MV,L=ZLG.]T7@WV;R4BB(AB1F*9'C,6''YO[]N@+>H8VS' M;SAN-(!NV7!-O:V)LJBV9ZIX;X6BTGGVA1^B2?U^ESPC^$BE MS_B%]#1-Z6FRW.\1(BN2)#TCW6=?X8F"4/<)>>:[;K@-[G%!J?WL#_<8%?._ MU&W;-<2%Z.FAL?C\/F1)ZO6TC?.O2*K,Y[\+8L+F7^LIZC,BU?/_NS]W"TJ2 M^2;&0G?F-"#ZU(U"HI.EZX0+HL]=LG`#:I(0@(_/QH3)!=1/05R:Y\1P(]LD MCAN2F>68!#CE4Q*Z1#>QB16(A+S%(BN`.CUD:%QHP=!`=TW;=>\!O6W=4U%L M-@\.#D@G6`7L+R6.D#&T'5,/!(8H\DC11I)&Y.&PWVRWVZ0"GHPCAS<8@$B- MNO)('?`&!\6']2BK`T'6%,(*"'EA4A@-C67TFBY#C%TX`D)0C\R MP@B8U@2H`.8'@\ M!P<=P)U"(O\8RS@X0BH%GC/P-PFX,0MR>!FX&C,UQOL1A]5\5C]_AJ=J_;\] M/3JY/)V@.DW.?$J_&Y^(,\L/PK8'LO:EUW]%[BM:[/])BMH#?9;[JM*OU_^O M\32_=Q>.`#;7(2LW(CY]L.ACQW"72XLMU`$EIC6;!?]-_D;#T'+F<2$Z".X, M7YJ/^@H6_T=P(^[!T'JNS\"6$;@(5`\LZHNXJ)\S8+3,!JS0Q`*'(5I.J1^` M^^#,;,L(R:,%W@8"'8$QBFL%`MZ'CHL+::(-GT9+#V&6)/(`:]MWI^0GGRWZ M_NJO_Q/I-M(NPC\_-YM(.6G[I&V0MDG:QT0A[1LD071]:][!CCNX7@3,>\A> MF:&N`&O<192<4`.$%A;+D=(;@>=:\$!RL.A\,-@^D<%;&8RD_A;G0Q/D?K8F MP*NB)BM"P["I[C0:+=TR^N_?OY\$]%?P;Y(WG\[%1:O1:(`NH?ENF-2CCDD= M8]5H_=>X8]*'3@R;?(H?H)$`:#X2``B,P&+_3)8T"/0YY?-MI8,;-UMOFX+P`B,T!;H(+HJF_#[Z' M6>!Z00:Y$."UV1CP*(3`<=ZR'YEH36DOJ3.0U=D!4;\L*:@7N/N][4A0;7OL>0!1DVR_"I M'M(<+AEP):4,4]I876OL@L'.-56P*2LK-ESOU<=U,6NH8D-6MJOAHV\5J-6P M)2_<1:SE&+F&76R(1;N:F33?K(?-L*C83"LW\RS7".UM5]:SH("7S,4792RM)@+&;7!I8+* MYWP;MI>X,PGC9?NV4/(M*I6P#SK7SROA8"`H0V5_)60,*E+UB2QQP+:M\40N MX?)GKG^?0X0\X66;>D>]`J,]\5R;RQ5KAYPIU$#S?6QK[,X&><.:E558U:RR MPJ1J%2:UU&!_>]KM"DIWD)M*+``#FTQEZP58S-8^QK.5VL36WJ:RT8J-7TO8 M9!`!!%F>`I3,'E2C*4NK2\8-JIF]2NO+)@P`P"ZU-E@JJ`7ST]I@D!HM;F-2 MY&6S@]S3!JT]K0N#SGB]R8A4F0%L*;9QN>D MHCRNQ7 M^SI5K?;63G6@".H@[T-#@2:E>SY0L,;X[J1Q2Z_\:>@+?`[+=8`7$,O1>'Y*/,%>'R2$I&P2*5AOGTX?-O?\`$@F\ MYP>J9WB@.F:P925'>63G['*SMK_`=G%F!CX+J_L1"3YB_>[JO M+V6!'5$"V6F1DJM6<]^UF'X4]FU]HR$I]ISK-()!+N$MQ:5NQ856IQ*7[3IS M_GWBR?Q4-1Y'Y`36W`$^(K0[FX$Y$/!^Q2<'QC2:)2>P5="&&SEA2IFVE3)F M[_Z_2.MN)0U,[6["4ER]K;C`,#\!5W\;+F[%7_'Q>GJX$.*1+?$4S#3]"7O1 M_;F0,0$A9N`6N(]I)P.&]]W5^>7-1=P)-_FL=IBKK;;LH#L-7M^XNGY[?G+: M8(:4U2B5-95V9"@+ZC!WFZ!)0T&3@<=^-3Q!WEULO>(MM5V+M7R4LQ@^!!-9O%%YLZB33RJ`8DW<8?7;7 MA^(H+K*[/_Y>-/&Y"G8ZU[<)RHO>$%Q6ORSCP'4(.$/**A@8GF`+CV7$- M-]GY"ZRXB\NC'^Y^O#F%ENN74@RB=-7'R%5+5WU?@=RXU3&V&C:22[NS_<8V MW#FVZHM=29"3&S=T->C[4,%;,.Q>[I/\H),[L$8K9!`,9)`-E=<_)PVI5#>^ M.;H]+=R@\1M5&;KN9=[5E^B:7^'Q^N$6TH8;2=M#M6)USRE76K*N7FG5^IY& MD]<5K`B^MXJ!Q11PI2ZIV/C'\609.;9KW`/2AJIT2Y43W-$8CR94]7*RA54@ M6?!Q?'1Q`96<2-8+>*@ES?C$7@A6);L>?+";4BW;\I"X=E"N93N>I'98KN7[ M'5ZK2N5:W.TD;56Y7(N[G;16*=7&FYVX5BW59GS#6FU/@?)\-W2+$A4758I4 M7->X6T3,:),>$Y+A"%;7*IE*X)\D5'VU)_35W(D'*QADER]K/C1!)_H05>D0 M%LNX.I[B";@-`?F0'@C%/LMAH2#S@(OEW!.N*%,.R7JA6@&H8=G'P_3^)2$. M)6POTBJH2ESE#:A1/#\%=<%SRXHK?-.LDOML!)W40T9$80:8*CR!%/+%:*EN MP7SEPS*5H))?A%T%I*#)FY"23\;*+4`9;SQN=)R+!(//G.-.P9$N`G(_.NXM MV:,V$@U66I8$^$EF MI2<+O6[J'5WP]N\N^)=WETWU\?QUZ/X\WR,&-$]P#97YS$YE^.3 MZW$,!/A6;[XCV!Q"^4>:*YKFY89_*3\?!B'FA&B MCIJ%K#-\%XF/#C#>G MXN:KNPJD#ZX=+:EE'A:0LFT)KXJQ%HXXN2SQYR,(R"0Z;!;&W],8Y MA[F0.T(&(WZP-EV!_\:6BL+8,_)2'#JZ((\9_]V&#EL3_:Y($W^6NW*OCO[_*PP*S=8S77E",YP[`/:4FQGJ[!#8T1"=S MUS59="]!3H5-T/DDQHO90P"<@9!,`[.MBA+1`XP+PT`I-#4PL]P^=8?DYN2. MFYLFFC9F)]]YIA[RSMI&Y/L4_`.&8$2*RVVW/Y*[Y&:<8`!J5Q@X%E@!^F:C M)I*BR2I'2\!0I='E@!O<$`^5C=&+5L=&JV.@Q6AE@6QDZKYO9;3Q!\UI&,%K MQI8I(L+XN)CR9/3)`$)X%QD>V*CG"+I;6`&/@4>>GQ/83N!PR8P^$E-?`:7^ MB@78<#A47\R'$0 MI2(JKTD9VZ/KWV,EM$IH%PGYZ1XO]``U]&..")B_Y]\2O/"@-EGH!GS[F;&? M9):#@%Q,\6R0!?#%?;\,R%G,&.A=E&]9?Z/F+/1&G0[\RU93T0`N+2.1FE'' MBZ8=+.L$OM')L(OA_+=F'-$46V&3-,6H< M.$X=#/AN>[8>8G3YMQB4-)D!14ISCL&*;`AL,)R1,Q"Y*9U;#JQ#S>6]:?D\ M#0&F$>RNX9&V%W.BC20^P/(*R#2M MMA4'*B&@5F[(E3$3YF_:?R$/U(D"IES(@EAI?P)F@68`N3^#LG!BH7IY#RL^ M+(08W@A]2,3`O!"IB=?6G@ND@&RS47.D,-B`4M0]X(M/K)")8P"(+EV0ED1W M`V"(P3)5HB`"<8/=2@0XX(_ZHV9'Q^"LG,3Z[B_4"`,NK2`3S>8=&J:%_I!# M29=6.]$UG&]&C(W'J@)8E1!$2"#_M)QAMW-UQ[)?SLG<>N`6.0A-U&_#UO%J M'HI8^HS%PVR13-WV%GK[5Z#5"E>@X3ABD^IV+'79*2S(]'>@ON!GA;J'"1$P M:C;],]\"GP8ZOG6GY)('TA)2&5*+GN#G/\TD&4@G@6-Y'D@R$W^=T*5NV:1@ MP;8]?T5N[6T\:S-IYZ] M$LE1&*)TF0135)+\HW.B+U/KAVP"LP?SQEWW*0T?*1B$Y2H1!K3G/'\$TY]0 M:F^/Q]B!&U@A,BMP="]8N#`S8%0<7""9EST$*Y*.=>$^AJZ(W01\O06HV+>* M[:-`P(0#;?,(G3G,IIKCF1*CBC))PC8(J]RB`<%OW?;XZN@&YHZTR9&)&50P MS"F%_35ZD"[I1('/S&GI;D,D)Z[S$O?B/C,DF*OU"WA":[YWX0!>;&;:6S[- MY^4__/`*=@6_PN(?4/C7,6ANV3EW-IS<"VO=5F2II*?E6:8*'_-+OK5[R4<, MRKXD#Z$^9YDZ_.)OG0W)R<#>;(N3RC(&;,A&Z@^S;*3KDZ-\-E+.NR]QHI`T M)+"TN2R]APE-@C$#'A"Q=,\*%'(831KZ#YY?DI6%'+#:& M'96^1$_;I.!T6%-^@?OJX#7"^W0:6;`]SSL':/Z@'/9((CF?P9X`F/-(;1N, M%I21.'&`!#KS8#&16IS@"RX,[%/4+L6J.SEEIJ`7W_(.+9K1O9 M.K/U>;-L=?`L9L;_4%Q15D4DP$G9C?W%W@T!$DRWB0N]$)^7,N>!^8.8J@-D MX*T[FPO@`2P68#9@X0-KSDV.Q5:0)E(40A\&+([@J-C(5;Z$H?*"R.D@:80< M+?7?H`/TKIESL=!A50:1/\G_DU6EB^<_6D^NSW^^QE.GR-4I MGR-4IGR-4IFQC_!#?Q>AXW=`$/%M.%([646>I]N MV&$5S[6`AB-%2O?25>8:=JU=*7$XR$'.TEV(Y#):+JG/$B#X"0YXH78$]O*; M(#0MV#/]I5B(G@]L=&E85&L&<,.Y;#416PZ0$L`&M] MV(\>PX*'F;*@I5=3GS"H-YM(?/IHGT+Z_F*WH+J]2^HXS':AXS!LI_Q]9./) MDC0<=7N%X*\].BF+G#I2I2TBIPA:[B817P?IL4EN,GS+F:]QW<"Y*!>"I)C3 M+S!QH$&EHA:.4ERTGC`WL*,.+8RZVC5!.<#MLY0#K#`/@SVG*H]E;;XD^4\[ M7P'L*G=-%8?9/DL/Z6+BIWZ^K\CPIL-)NGJ>N(G1S.H2O_R8Z9%@;9FZO6?)I M@'\\%W;S+!7!-LY2$:RD2ETIM5+;9JF$HSA+*LS2EKUK5Q5ZJ3.T:]'F!U`; MIZ6]OZM0-6%;':"TO4AL%\*LW[B9EG*.R?Z9;U M)0^T6;1R0.M62^GO(51Y#$5QDGM;(\)ZBM"7UVW6=I/#:Q[T2J:S\_L*Y>Y8 MLUTJOX<=S#9&63GU?:=27MCO;I2\"&9)6OQ\F8U]?1G]`F-_LP?9G\R3SQW[ M7N+-LE,[L\"=&#,><:ALLZ35X!M%OAJ\Y%AUN^`7[1;^#;A*5G4XDK8MW5+J M8'U5JYJ?I9F#Y\:3Y.?!)A,H[73(&!I0\N#Y['_@O7?WNF\F=8W9`.Y;]9*)['U?K.1@6^J=TJ?/O3Z4N1/?O^3_ZFR M+]'']OL?K:_TTM]_!%"%W?^H6GW_\S6>:X?_*`C[H1+VZV28#4_M_VOO6)O: MR)&?V5\A^)"U86)F_#9LD?K`G/H,;V1S?'8CCZ]I/J@ERXE+[4$O=_K1B MJTA\,"N*W[981^!)C9&AL`IB?:M-A_478FYK:)D498B;YO%A(0L\.6/PY&BW M6ZB=@%J@'AFAYXI:S=IZ]5EPF-2 M%T,E)Y^QT]L/,$`8''H4>.+XK-I-GI;XE793-G)L"RP5?B)E4X`7_6K)99!* MI<:#GH^>%R>``W8MA>YVT6ZN7JD>GYY=U=YH120ZDIVB[VG\+36IZ;>!4_=/ MUW4]L\!OEY5Z.5(@K;603$%8H,)<^0R/>C@J\?[]^VUT7]4F5XAXVA/WMY\% MD0E\],?X>=AM2=DC@`B:CMBF&2<82$JL8MEDM%" MGH>J/7_0D"_I`_7E,_N9P MXZ*#K'*!+?VOB)G?F@Q&_Y":(]O"_W,"FP4I)R=V=PU/+8UA,I$\5`"R+FS: MRSOIM&MHI:S0Y0SZF(A(GT:'UC&7\D[&]4SW.R4GD];WI]\`(.2%"3>I-JY= M\L[=NFWV;YA[2E$MDW+-Y73>,.$[MRK8LA[NZMZ0BO M9T1H9=MZG?4;:&=#)'+VME%^?PQ[:>6Z++[BS\MR_?(#$4ZXE2@\5EK;(XQH M!$NN?]_L3\;D>!'^]='WH=\6"(+?WA_YG9^!(XEW($?(@C"Q/3&C#,,Z?65! MWO129/%>S<7'>K&`*]&E\8%OT1NZY66`5Q;BX)%ON2WY-++[# M=Y4P"]FLO,1A9@FRZQ]3/W[/I,13YD'<4TQN6="3>2NZ;%]KFV'V%A5V'K7J MO%(CEBG-6Z:4RX:/9^C?H+A@-O..9YA'X>Z7,3:_-Y5:O7KY@7\$?3@S7&J[ M](^X]&?=,0H`7BK/7]`C*0D<:B.B_O<];]]S!:I@X'_:3;?@MD2D+?2E6"KE ML18J`Q0/TKD#&)+XV!]\O/.Y^%$;XQHT0>YIWO0'XTD7L'_KM[AS!I?VFCG& MU4Y@;L@;!M'I2_)FVX&V1B#QD2]=;([B!G3&''H!.;.-O&UDJM4=,Z@$1+B= M9U-BR*QX@:O9$(!F<#%HL^U_G-X[#F.-VV$%\PK$-BUFM\`0$6.-`7 MAS-VNQ._ESRD'9KW2=D;%\)5UE26':`'*Q+?6!2;0"N`WO% M1N,BD>!.D\1CC5*![6&DU+99:NS?`5=]J"TX(S8GD]$#I<;S2A'->R!>>?HX M_DS#0;=#6^*9AV.=K1PL<4-?AL\6RF_""Y11V!0,#_-.>%#2@9+VC+-MUN() M"E>3DR;KR5_:\$%6[/6:0UF-/#+A-W\T@C7VC2RG,3]6J3/^W&^%.Z-/JB_^ MH23F?!K&G`\?^=8Q9IS%<"73T13-\=\[6KN;KYR3+N:,K0UH!\81FJ/$+"F[ M9/*9(8W])4KG=`( MJ(M'P1]0RX)VW+FU"0HR[&20)W)Y@\30,'RC@/P`4JJC[3A)YJ8&Y.%#H='* M\[)I)Z-440D+6]V.2$CX6GWX7ZO?P$/C6+P0B3='M5^O3D$PKQU=EVOUH\MZ M,BE>O1+\/8D6>EO$:\+UAWUR-/.N@9X;*C2Q6PHEKIQG.MKD/"<37(2N`QIF M?72I1=Q/8]L$S0Z1]?8Z4W"R6<^\*D`(MT?^>'HW$5^_BH3\$^`H_^NJ5H?S MR]7E.0#VEQK.=B(Z$CRUH->&\WH2FX@7J-3.CFKU8VX&AJ7ZU9V9QQ\>8!M. M1JI7-30N?4B()5,V^I>%D6S>R>;2YIW"=QC8_NYCAB;I>^E*QF*3#5#]Q]36 M9`.K;%GT6NDHFP,ZTB(3"P+L&DU!LZOVB*&<]*TXC`2A45!#1`$;4'SK)':T MW(M7*P=BAZF=BS3[W59BAQU=^!B!BH*S8/"6UF!ZU\9;0\P"*;I[U]Z1`E(6 M)(AL/G#5N@3P,$=+@B\G%5I97)CN"LZK%T=7-7E34#FOER^Q5&R:GADGU@G. M96$]%4,3'$:,>/$B]'/[E3#(6\XCL*$3%3/'$3<#T:3H=6A%2S!T)_+V_`>B MCCQ01R%,'<\Y\L>0UO\);96*3LY-SV%"QH9LVX[/RD>G"[G(7*J)C(]=H`3C M>QJUY."PE?/R<_C.TF.9RP,6TL$S$,+:D61]G_1R@+12Z,%"GQ@(!U%L!1(2 M\F]7$L#I9;F<6""D$1.3_P_S.*E>7G)RF;";@*>`$9?1XM+9`E"L&,K"$LFE M#;GV^5$C*4D1-APY[OP4H`A?52R76=O)NU4XX\K!@B]\S8G">X.]/6 M'5\Q1@FU7=P,,(+9G]U)`"?[%LDZ>:]DIYDE`?A=EK.N]:#L8Q9O5%IW$VG`;'9$E+^73.R6=<"RTMZA#VQ#E=J@W0GA\7 M=!^"T8ZDO)-/NR:E(4L?#8;ZZ0RV/63P.)![7SY=8VA:C$BEU\2S;FR,W4P: ML!MB07\?I(]9Y78\@S!0"`L#QO28%!;AJ]OB$2*C(;Q(SD8Q90_F<2VHPNN] M`.N]$%[ORX)'5S`K<>C@K/?7M];OBO"VBUZQ1]1OO-MK!=2>IK;QQY?.]O[TFE!GW,>UUV$05_> M?]/OVZ'';;KE[=!S0G\P&4^'L,&&;\.;0_FZY>80Y+^;T7K5,NW,@ M+T$_@:ZO:2$5]/'2\#^M'T[ULXV;1S6TO"3!=;W+JUA+D=A+*[[,RU:B!DU9 MZ].\*HSO^/0V[XJT:\8>L*&T",NQ&/&'*TX:I#78J*/;,'ZA;$Q"^97J,Z%FBKUYV)IO83TJ:CVF+60OZ&WD51@NR.9>#DME28 M-U33Y?PQP&'7NFL`^*)ZQMGZ961U<*TZD)Y3T@O/!)M;)M`/*2N`F+,(:GQ& M,K'+68QAK,9O\RK`5Y.B>PC6J,;D+O!V'>"W^A!U@DZU`-PC$8(;"Z$6ARHP*A2?WIWAT$K)L:G`:RE MR6`R^>S03FOBV>$"^*8:5&#WD^$@W>@`<,>162\]Z3<2]^LF:I'PFQM']>5] M5`Y?\\8?;/@XO<\S>.MFGX9].N/%]Z;+D]\NF>J8E=@6.3_DVO8C64>]UDOE M5^XJMJL\I:M@442[LINNY)ULT8V]HYL$EZ!W6=:R-10K)2)(V,2A?IV3/4=?OX.Y7G^_Z^*V,G1C.)+CBKR6&UE."TZ6C>@T>@?>`@OA M@@L'D\@UF93<6J3EOML:*NT";9D::'T90BQI3>EX(#$)1W5DBM@/=F3J-"[7 MU;KF4@?+C$;/7'$^53.6&2W$9U27CLQI7COMLFK!P,:1SD0.54HQ,!4[[-[X MD[Y_WQD#=TQ`A["#:@.19(!HQK2>D.!X='U::YS6*B=4-YF:->_^[?Z'M>A( MG44"$SY]SP4&&FE$`5H1"JLVB(>178-'RRV`R>]27/D@HKL`(,GU0TI4R1Q& M?+QK=GL'@I_[L,[)<4V@FF9I'V/5[-LU?^F)[_W[]^(EJUEBH]TNAH3'R.R= MYB=?3/L4G$6^+6L%#=*6D@=X!;)Z;7P&D,WEMCK0:UN*0739>,#959>C;LBR M((N6!1DNKPXT:5B/!^D%;M-+6&.8:+6IW!=$,[94EFM%LL0.M98T9 MI:WH]K*^&]C-QFM]#I%[^*=NOS.@^T(\='#+8_)0`)OV'],NB')(IK"$.3IS MU)QNUMN?(08TV=GR&PI/\PL-002,-/,R7`)O*1_L*-Y*%`]R="PA9TTUVC68 MI,ZW_E/HWYLS[='OLU[/G_@C6Q9(R](51>!3O/;N(E0.C4Q!@-P?]X:R"2TW M_A"SOQX="PU4]>7>_N[1Y3]K5[7R";43 M:'XJU57@SE(34QOZA60I-DW7,WI!F3N7JQ7FU7KNZN%`OCMDT@!1$LGH:2(BN-0"T=I9Y&^=< MM^MBF;?Q"\!<>@'+O(VSS%QVH:_+P&&692WPU4V8$"D"!P8UY#_"5]".\D<9 M.+**D;PR+'A4LVN:-33J$H:!UVKSA"U8)BCNWH(*AF@F38BL*S4FH6H= M[EWW8VJ\EMD,.?P0,1<@*\QLJ)V'YS=\+N&SK3?HM<+!R=URKB6%")NV[_4P)/H<=[>U"V?W/GMY.\)"EB MG`R$2[&DS7"X.HH9A0>CP+A2.53NZ-?=EE]AZZ=9M]V<-!UA!L@UG_:V&A@N M\+IR7.8[US<-&60/3@+%\#/J6@>XY/%PWFE/'^O,C&F_.YZT8\4G;:1=/NII MB_0M'.QIY8R<=^PP>:6.JR`O5<]VI''EWJ.G82G\ZV!M@-,+=*[Q"[>GBG*Q MUUAE()JRS>G(UY'BX+A"KB+9P&T"%@N+>M&/@,$N6%(\/)L$HR,P@QAS&?.^U#QIXF&!V,MP?G) MOVLK)PSH0QS5Q(FB)JW;("8>9#ZH]E;\\HOP\FAHA59[S?$G<@ACP*.;A-%LT?=7J#,!3;U^C371 M_L5H+RGVJ/:@(\-5&Q^Z&(=;$Q+%W.NUM[Y">]1NM"&"[)#P-1C1KLM:/3`J M*J\L?NDU`-">PDD#Z,PX?_2=IPQR=H/)TYD\@9`9S*3,[B#2*"2[6AB.J#8N M3ZKG9Q\+@W2"H+0%K40!YC&.X:+L+L3E>[*E6 M^"O'#0?VM_'8N$F;M$F;M$F;M$F;M$F;M$F;M$F;M$F;M$F;M$F;M$F;M$F; 2M$F;M$F;9$__`TQ!`ZP`\``` ` end From owner-freebsd-hackers Sun Dec 7 18:59:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20006 for hackers-outgoing; Sun, 7 Dec 1997 18:59:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dominator.eecs.harvard.edu (dominator.eecs.harvard.edu [140.247.60.28]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA19991 for ; Sun, 7 Dec 1997 18:59:01 -0800 (PST) (envelope-from karp@eecs.harvard.edu) Received: (from karp@localhost) by dominator.eecs.harvard.edu (8.6.12/8.6.12) id VAA19022; Sun, 7 Dec 1997 21:58:59 -0500 Date: Sun, 7 Dec 1997 21:58:59 -0500 From: Brad Karp Message-Id: <199712080258.VAA19022@dominator.eecs.harvard.edu> To: pst@shockwave.com Subject: FreeBSD Metricom driver: I wrote one in September... Cc: freebsd-hackers@freebsd.org, karp@dominator.eecs.harvard.edu Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A friend forwarded me the thread from freebsd-hackers (to which I don't subscribe) about a Metricom radio driver for FreeBSD: specifically, that some are considering writing one, and that consensus was that one didn't already exist. Not true! I wrote a complete StarMode driver for IP over Metricom radios for FreeBSD in September, as part of a wireless routing research project I'm starting in Harvard's Computer Science department and at ISI. The driver is called HUMR, the Harvard User-level Metricom Radio driver. My driver is written over the IP tunnel (tun), and is completely portable (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios (with no centralized ARP server, despite the non-broadcast nature of Metricom's radios), and works very well, overall. I wanted to mention this so that others might not spend time duplicating effort I've already spent, and so that my work is known. I hadn't placed an emphasis on getting the code widely distributed so far because I'm more interested in getting routing research results that use my driver as a substrate. I can provide the code to interested parties, and would certainly be very happy to see it distributed as part of FreeBSD, if there is interest and someone with sufficient authority to fold it in invites me to contribute it. Again, as I don't subscribe to freebsd-hackers, please address comments, questions, and/or requests for the code to me by email. Regards, -Brad, karp@eecs.harvard.edu From owner-freebsd-hackers Sun Dec 7 19:22:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21889 for hackers-outgoing; Sun, 7 Dec 1997 19:22:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA21861; Sun, 7 Dec 1997 19:22:38 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras537.srv.net [205.180.127.37]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA10489; Sun, 7 Dec 1997 20:22:30 -0700 Date: Sun, 7 Dec 1997 20:21:56 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home Reply-To: Charles Mott To: Eivind Eklund cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) In-Reply-To: <8690twpu17.fsf@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems like one would have to force the tunnel device to have a fixed IP address and perform NAT to the true interface address. In this case the FreeBSD box would be exactly like all of other other machines behind a NAT gateway, which means that non-supported IP encoding protocols would automatically break. Charles Mott On 8 Dec 1997, Eivind Eklund wrote: > Brian Somers writes: > > > brian 1997/12/06 20:09:16 PST > > > > Modified files: > > usr.sbin/ppp command.c ppp.8 route.c > > Log: > > Only allow one arg to `delete' - the mask & gateway aren't necessary. > > Delete AF_LINK routes as well as AF_INET. > > Allow the word `default' as the arg to `delete' or in place of the > > first two args (dest & netmask) to `add'. > > Accept INTERFACE as the third arg to `add'. > > > > You can now say `add default interface' to create a default route > > through the tun interface. It's reported that subsequent bind()s > > will bind to a broadcast address and not to the address currently > > assigned to the tun device - this is the first step towards > > supporting that first connection that was around from before the > > dynamic IP negotiation.... > > I've been thinking a bit more about it, and now I consider this > binding a bug. With an interface route to an interface with no > assigned address, we're actually sending packets onto the network that > hasn't got a legit source address. > > This works for the single case where there is a NAT engine at the > other end of that link, but that is also the _only_ case it works for. > > I'm still a bit uncertain about what would be the best approach - > probably binding to another interface in the machine. That's weird > too, but probably less surprising never the less > > What do other people think? Is this feasible given the way routing is > implemented in the FreeBSD kernel? > > Eivind. > From owner-freebsd-hackers Sun Dec 7 19:40:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23374 for hackers-outgoing; Sun, 7 Dec 1997 19:40:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA23362 for ; Sun, 7 Dec 1997 19:40:46 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA19706; Sun, 7 Dec 1997 19:39:32 -0800 (PST) Message-ID: <19971207193932.61833@hydrogen.nike.efn.org> Date: Sun, 7 Dec 1997 19:39:32 -0800 From: John-Mark Gurney To: Brad Karp Cc: pst@shockwave.com, freebsd-hackers@FreeBSD.ORG, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... References: <199712080258.VAA19022@dominator.eecs.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712080258.VAA19022@dominator.eecs.harvard.edu>; from Brad Karp on Sun, Dec 07, 1997 at 09:58:59PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brad Karp scribbled this message on Dec 7: > A friend forwarded me the thread from freebsd-hackers (to which I > don't subscribe) about a Metricom radio driver for FreeBSD: specifically, > that some are considering writing one, and that consensus was that one > didn't already exist. Not true! I'm glad your friend forwarded the message... I'm greatly interested... > My driver is written over the IP tunnel (tun), and is completely portable > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > radios), and works very well, overall. hmmm... tun is nice for portability, but it still doesn't match the performance of a kernel land driver... the extra context switches do impact performance... a ping to a remote host has to traverse the kernel/userland boundary three times when pinging a remote host... (ping->kernel->tunnel->output to device/network)... I actually have the NetBSD kernel strip driver compiling... I just need to test the driver... > I wanted to mention this so that others might not spend time duplicating > effort I've already spent, and so that my work is known. I hadn't placed > an emphasis on getting the code widely distributed so far because I'm more > interested in getting routing research results that use my driver as a > substrate. personally, I think this goes along with the argument with the pppd/iij-ppp... each have their advantages (with a friend, I've gotten two EXTERNAL 28.8k modems down to 107ms rtt for 64byte ping using pppd on both ends... compared to external isdn ta's that I've heard get around 40ms, it's not bad.. :) > I can provide the code to interested parties, and would certainly be very happy > to see it distributed as part of FreeBSD, if there is interest and someone with > sufficient authority to fold it in invites me to contribute it. I'd be willing to test and commit the driver, assuming no other commiters object.. :) also, I assume that the license for the driver is similar to the BSD license? and not GPL'd? > Again, as I don't subscribe to freebsd-hackers, please address comments, > questions, and/or requests for the code to me by email. ok, I'm adding you to my aliases... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Sun Dec 7 19:45:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23727 for hackers-outgoing; Sun, 7 Dec 1997 19:45:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA23689 for ; Sun, 7 Dec 1997 19:44:49 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras537.srv.net [205.180.127.37]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA10510; Sun, 7 Dec 1997 20:44:40 -0700 Date: Sun, 7 Dec 1997 20:44:06 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Brad Karp cc: pst@shockwave.com, freebsd-hackers@FreeBSD.ORG, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... In-Reply-To: <199712080258.VAA19022@dominator.eecs.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 7 Dec 1997, Brad Karp wrote: > My driver is written over the IP tunnel (tun), and is completely portable > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > radios), and works very well, overall. I'd be curious to hear how your IP-MAC mapping works. Is it some sort of stochastic token passing between neighbors? To what size networks can it scale? Some obscure questions, since you've seriously worked with the metricom hardware: how intrinsically doppler tolerant is the communications waveform? What modulation scheme? What chip rate? Charles Mott From owner-freebsd-hackers Sun Dec 7 20:25:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA26519 for hackers-outgoing; Sun, 7 Dec 1997 20:25:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA26506 for ; Sun, 7 Dec 1997 20:24:53 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras704.srv.net [205.180.127.204]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id VAA10543; Sun, 7 Dec 1997 21:24:45 -0700 Date: Sun, 7 Dec 1997 21:24:10 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: John-Mark Gurney cc: Brad Karp , pst@shockwave.com, freebsd-hackers@FreeBSD.ORG, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... In-Reply-To: <19971207193932.61833@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > My driver is written over the IP tunnel (tun), and is completely portable > > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > > radios), and works very well, overall. > > hmmm... tun is nice for portability, but it still doesn't match the > performance of a kernel land driver... the extra context switches > do impact performance... a ping to a remote host has to traverse the > kernel/userland boundary three times when pinging a remote host... > (ping->kernel->tunnel->output to device/network)... On late model Pentiums, I think kernel-user context switch is down to about 5 microseconds (it's about 60 microseconds on my 386) for an individual system call. However, maybe one or two OS quantums (10 milliseconds) are added for hauling the packets around. Is this the problem you are talking about? (I don't know the answer and am trying ot understand system timing better). Charles Mott From owner-freebsd-hackers Sun Dec 7 21:21:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA00134 for hackers-outgoing; Sun, 7 Dec 1997 21:21:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA00124 for ; Sun, 7 Dec 1997 21:21:04 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id VAA17301; Sun, 7 Dec 1997 21:20:52 -0800 (PST) Message-ID: <19971207212051.48451@hydrogen.nike.efn.org> Date: Sun, 7 Dec 1997 21:20:51 -0800 From: John-Mark Gurney To: Charles Mott Cc: Brad Karp , pst@shockwave.com, freebsd-hackers@FreeBSD.ORG, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... References: <19971207193932.61833@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Charles Mott on Sun, Dec 07, 1997 at 09:24:10PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott scribbled this message on Dec 7: > > > My driver is written over the IP tunnel (tun), and is completely portable > > > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > > > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > > > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > > > radios), and works very well, overall. > > > > hmmm... tun is nice for portability, but it still doesn't match the > > performance of a kernel land driver... the extra context switches > > do impact performance... a ping to a remote host has to traverse the > > kernel/userland boundary three times when pinging a remote host... > > (ping->kernel->tunnel->output to device/network)... > > On late model Pentiums, I think kernel-user context switch is down to > about 5 microseconds (it's about 60 microseconds on my 386) for an > individual system call. However, maybe one or two OS quantums (10 > milliseconds) are added for hauling the packets around. Is this the > problem you are talking about? (I don't know the answer and am trying ot > understand system timing better). basicly the user/kernel context switch is just a minor part... it goes along with scheduling that may not happen immediately.. and then you hit problems where the process will be delayed because other users processes are scheduled before your (this is actually quite a bit better in FreeBSD than other OS's I've used) process... so then you could have up to LA * 10ms before your packet gets processed instead of immediately like in the kernel... one way would be to stick it on the real time prio queue... but then if the processes goes in an infinate loop, the machine dies... also, remeber, the data originally came from the kernel, then it goes through conversion by your user process... just to be deliever back to the hands of the kernel process... I've personally never traced the whole path by hand... but after working with the code, you have a pretty good idea of what the code path looks like.. :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Sun Dec 7 21:50:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA01852 for hackers-outgoing; Sun, 7 Dec 1997 21:50:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA01844 for ; Sun, 7 Dec 1997 21:50:11 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA02030; Sun, 7 Dec 1997 21:49:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd002028; Sun Dec 7 21:49:01 1997 Date: Sun, 7 Dec 1997 21:46:34 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org cc: Julian Elischer , mckusick@mckusick.com Subject: [hackers:] Architectural advice needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This starts out discussing a single problem and then goes on to discuss more general problems and ideas.. stick with it.. BDE pointed out a problem in the system that showed up when using my device filesystem. In spec_getpages() the size of the device's blocks is incorrectly deduced from the blocksize of the filesystem in which the device resided (e.g. if you are accessing sd2 with a blocksize of 1K, you will get 512 bytes because /dev/ is in / and THAT is on sd0 and has a blocksize of 512 bytes.) This so obvioously wrong that i'm not worried about whether it SHOULD be fixed, just HOW? The obvious place to store the blocksize is in the specinfo struct pointed to by the vnode for the device. It might be possible to make a request to the device to get this info, but it would require doing an ioctl to the device every time you wanted to do this and that would seem a very slow operation for retrieving a single int. Does anyone have a better place to stash this info? vn->v_blksize (as a macro) #define v_blksize v_specinfo->si_blksize would seem the correct scope and placement for this information. Now, Part 2.. How does this information GET to this location.? It needs to be put there at the time that either 1/ the vnode is allocated. (the same time it's put on the vnode alias list) 2/ the device is openned. In either case, the problem is that there is no easy call that can be made to the device to find out it's blocksize. The deveice drivers are only accessible through the devsw interface, and while there is a 'size' call, there is no 'blksize' call. This leaves the IOCTL interface. Should I just use the 'read disklabel' ioctl, or should there be a separate call of some sort. Open would be the right place except that the open call does not get a vnode as an argument, but, rather dev_t, so it can't fill in the field in the vnode. The lookup() that allocated the vnode cannot do the right thing because it is a vnop for the ufs (or devfs) that HOLDS the device rather than a representative of the device itself. So either the specfs open code should do an ioctl to get the blocksize, or the checkalias() code that is called when a device vnode is allocated, should do this ioctl. One worry is that within the kernel, it is possible to access the device without doing an open() on it, so the checkalias() (or nearby) position owuld be safer, but the open() would seem more correct. Question 3. One raised some time ago by PHK: When a device is 'upgraded' to read-write from read-only, the vnode is consulted, to see it it is permissable, but the device itself is not notified fo the change. If we (phk and myself) think about this and come up with a change for this, would it be considered a useful thing.. FINALLY: I have a long-term thought that eventually dev_t is going to be a rather silly thing. The devsw calls should all get a vnode pointer as the first argument. In this case they can always extract the minor number needed, but they have a way to interact more correctly with the vnode. This would eventually result in device driver implimented vnops. Is this a way to go? Overall it's about 3 months work and I'm really part of the way there already, but I've reached a point where the magnitude of the changes scares me. Not because of the technical problems, but rather because of the political repercussions. If dev_t is redefined as struct devref{ int dr_refs; /* this too is ref counted*/ struct vnode *dr_vn; u_long dr_v_id; /* the capabilty # of the vnode */ /* consumers should check this */ }; typedef struct devref *dev_t with strict reference counting, and a few MACRO's this could be used to transition from one system to the other. the VM system and others that hash on dev_t could hash on some of the contents of the struct above, and a whole lot of things would eventually become simpler. I think there would be a phase when things got a little 'hairy' but overall it makes a lot more sense than what we have at the moment. The big problem I see is how do I do this and keep in touch with the rest of freeBSD? I have DEVFS/SLICE working as a set of patches, and I'd like to have them commited if I can get someone to look them over. But the next stage cannot really be done as a set of patches. DEVFS/SLICE can be in the code and if you don't define DEVFS and SLICE, you don't get ANY changes to what you are running, but the changes I'd like to see are really to big to be feasible that way.. Is there a way in which such a large project can be approached? (and is there anyone else that thinks that this is the way to go?) I really an looking for advice from what I consider to be a very talented and experienced group of CS proffessionals here. SHOULD devices respond directly to VOPS? should dev_t continue to exist as a 'number' that needs to be interpreted? I wonder if there is a forum that we could use for a fuller discussion of this sort of thing? I've discussed this sort of thing with, (at various times) phk, peter, john, david, jkh, brian, terry, kirk, Bill(jolitz) Mike, cgd, theo, charles and others I forget. No-one has ever said "That's stupid", and most have agreed that it would simplify some aspects of how the kernel gets its work done. The question is, how do we get everybody to discuss this sort of thing at one time? How do we decide on an aproach for such a significant change? julian From owner-freebsd-hackers Sun Dec 7 23:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA07461 for hackers-outgoing; Sun, 7 Dec 1997 23:10:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA07450 for ; Sun, 7 Dec 1997 23:10:23 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA03325; Sun, 7 Dec 1997 23:09:57 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd003322; Sun Dec 7 23:09:51 1997 Date: Sun, 7 Dec 1997 23:07:24 -0800 (PST) From: Julian Elischer To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: Why FIONREAD has no dual for write ? In-Reply-To: <199712061054.LAA25661@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 6 Dec 1997, Luigi Rizzo wrote: > I think I already brought this out but recent discussion on mpegtv > suggests to bring this out again. > > FIONREAD tells you how many bytes you can read before blocking. > > There is no FIONWRITE call (how many bytes you can write before > blocking) which would be nice to have, instead of having to resort to > non-blocking writes. but it could change between the time you do that call and the time that doo the write (you could be sharing a file descriptor, or you could be sharing a device) so you may have to handle the blocking write anyhow. > > And there is no FIOWQUEUED call (or similar name) to tell how many > bytes are queued for I/O on a given descriptor. true do you really thing this is useful? > > The latter could be used e.g. in audio drivers to extract sync > information from the driver itself. Or on sockets/pipes, to decide > whether there is a risk that the pipe runs dry. possibly there might be a more DIRECT way of doing what you want with appropriate device driver. > > Are these only necessary for real-time purposes ? And even in that > case, since pseudo real-time apps are coming out (e.g. audio/video, > driving a CD writer, etc.) wouldn't it be worthwile adding them ? Well, I guess it wouldn't help any programs with aims of being portable. > > Implementation would be rather trivial in many cases (for audio they > are already there under a different name; for sockets it suffices to > check the socket buffer size, > If you can get iti past the censors then I guess it would be ok, but I can imagine a few screams from some quarters. From owner-freebsd-hackers Sun Dec 7 23:19:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08111 for hackers-outgoing; Sun, 7 Dec 1997 23:19:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA08100 for ; Sun, 7 Dec 1997 23:19:06 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id AAA18955; Mon, 8 Dec 1997 00:19:05 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id AAA10448; Mon, 8 Dec 1997 00:18:59 -0700 Date: Mon, 8 Dec 1997 00:18:59 -0700 Message-Id: <199712080718.AAA10448@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: hackers@freebsd.org, mckusick@mckusick.com Subject: Re: [hackers:] Architectural advice needed In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I wonder if there is a forum that we could use for a fuller discussion of > this sort of thing? Isn't this the purpose of freebsd-arch? Nate From owner-freebsd-hackers Sun Dec 7 23:24:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA08570 for hackers-outgoing; Sun, 7 Dec 1997 23:24:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA08559 for ; Sun, 7 Dec 1997 23:24:27 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id IAA01786; Mon, 8 Dec 1997 08:24:49 +0100 (MET) (envelope-from sos) Message-Id: <199712080724.IAA01786@sos.freebsd.dk> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: from Julian Elischer at "Dec 7, 97 09:46:34 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 8 Dec 1997 08:24:49 +0100 (MET) Cc: hackers@FreeBSD.ORG, julian@whistle.com, mckusick@mckusick.com From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > This starts out discussing a single problem and then goes on to discuss > more general problems and ideas.. stick with it.. > > BDE pointed out a problem in the system that showed up when using my > device filesystem. In spec_getpages() the size of the device's blocks is > incorrectly deduced from the blocksize of the filesystem in which the > device resided (e.g. if you are accessing sd2 with a blocksize of 1K, you > will get 512 bytes because /dev/ is in / and THAT is on sd0 and has a > blocksize of 512 bytes.) This so obvioously wrong that i'm not worried > about whether it SHOULD be fixed, just HOW? Wrong, if a filesystem is mounted, it uses the mnt_stat.f_bsize instead. This is endeed an ugly hack (I put it there to accomodate devices with != 512 byt sectors). Either we let it stay at all times at 512 bytes and let the device driver chain cope with that, or we use the actual size of the device throughout the system. The whole thing boils down to the question of who deals with the actual blocksize of the device. Either the entire system knows how to deal with it (as it sortof is now), or it is handled in the device/slice layer. I was newer able to favour one clearly above the other... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Mon Dec 8 00:10:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14777 for hackers-outgoing; Mon, 8 Dec 1997 00:10:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14758 for ; Mon, 8 Dec 1997 00:10:15 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA04242; Mon, 8 Dec 1997 00:03:12 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004239; Mon Dec 8 00:03:03 1997 Date: Mon, 8 Dec 1997 00:00:36 -0800 (PST) From: Julian Elischer To: S?ren Schmidt cc: hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712080724.IAA01786@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, S?ren Schmidt wrote: > > Wrong, if a filesystem is mounted, it uses the mnt_stat.f_bsize instead. Exactly.. this is the 100% wrong thing to do. This represents the blocksize of the filesystem on which the /dev directory resides. This is completely independent of the blocksize of the device you are trying to write to. DEVFS has a blocksize of 1 byte, though I SAY 128 for no real reason. So therefore I started getting writes that were made to be multiples of 128. You think this is correct? I am talking about doing the right thing, which is somehow asking the device what it's blocksize is. My system here is working because I removed that code and said bsize = 512; which won't help with cdroms and other devices but at least get's me up and going.. I could have made DEVFS report it's blocksize as 512, but that would just bury the problem. I want to FIX it which is what this email was about.. > This is endeed an ugly hack (I put it there to accomodate devices with > != 512 byt sectors) Which it totally fails to do because everything thinks that they are 512 byte devices, because /dev is on a 512 byte filesystem device. >. Either we let it stay at all times at 512 bytes and > let the device driver chain cope with that, or we use the actual size > of the device throughout the system. #1 is not an option in the long run. I'm talking about #2 why is that wrong? > The whole thing boils down to the question of who deals with the actual > blocksize of the device. Either the entire system knows how to deal > with it (as it sortof is now), or it is handled in the device/slice > layer. I was newer able to favour one clearly above the other... the trouble is that you chose the wrong value to key off. If it were the correct value, the rest of the system would behave a LOT better. (and I know I've done similar things so this is really nothing more than a very MINOR pointy hat in your direction..) Just banging the number to 512 would have been more correct as at least it would have been OBVIOUSLY wrong rather than obscurely wrong. (hat awarded by BDE not me, he found it) From owner-freebsd-hackers Mon Dec 8 00:20:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15801 for hackers-outgoing; Mon, 8 Dec 1997 00:20:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15778 for ; Mon, 8 Dec 1997 00:20:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA04423; Mon, 8 Dec 1997 00:12:54 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004421; Mon Dec 8 00:12:49 1997 Date: Mon, 8 Dec 1997 00:10:22 -0800 (PST) From: Julian Elischer To: Nate Williams cc: hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712080718.AAA10448@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ah this would be the CLOSED LIST to which I have not been admitted though I have asked to join several times, yes? On Mon, 8 Dec 1997, Nate Williams wrote: > > I wonder if there is a forum that we could use for a fuller discussion of > > this sort of thing? > > Isn't this the purpose of freebsd-arch? > > > Nate > From owner-freebsd-hackers Mon Dec 8 00:22:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16111 for hackers-outgoing; Mon, 8 Dec 1997 00:22:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16063; Mon, 8 Dec 1997 00:22:13 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA07582; Mon, 8 Dec 1997 09:22:10 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA28003; Mon, 8 Dec 1997 09:13:38 +0100 (MET) Message-ID: <19971208091338.59077@uriah.heep.sax.de> Date: Mon, 8 Dec 1997 09:13:38 +0100 From: J Wunsch To: cvs-committers@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/i386/include console.h mouse.h src/sys/i386/isa kbdio.h mse.c psm.c syscons.c Reply-To: Joerg Wunsch References: <199712080114.KAA00192@zodiac.mech.utsunomiya-u.ac.jp> <199712080131.XAA24122@gaia.coppe.ufrj.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712080131.XAA24122@gaia.coppe.ufrj.br>; from Joao Carlos Mendes Luis on Sun, Dec 07, 1997 at 11:31:12PM -0200 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Joao Carlos Mendes Luis wrote: > Unfortunatly, kernel swapping or kernel routines memory disposal is not > an easy thing to do. It could be easy with the availability of more sections in the executable once we change to ELF. ;-) (There's IMHO nothing preventing you from declaring parts of the kernel to be pageable, apart from that you need to make a distinction between pageable and non-pageable regions somehow. Three sections in a.out is apparently too few to remember this disctinction.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Dec 8 01:09:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA19985 for hackers-outgoing; Mon, 8 Dec 1997 01:09:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from beast.gu.net (beast.gu.net [194.93.190.196] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA19898 for ; Mon, 8 Dec 1997 01:08:50 -0800 (PST) (envelope-from stesin@gu.net) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by beast.gu.net (8.8.7/8.7.3) with SMTP id LAA14620; Mon, 8 Dec 1997 11:08:13 +0200 (EET) Date: Mon, 8 Dec 1997 11:08:12 +0200 (EET) From: Andrew Stesin Reply-To: stesin@gu.net To: John Fieber cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 7 Dec 1997, John Fieber wrote: > The patch in the updates directory on ftp.freebsd.org should be > updated. The errata says: > > o Intel "F00F bug" enables users to hang machines with Pentium > processors if they have access to the machine and can execute programs. > > Fix: Update to the 2.2-stable version of the kernel or apply the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Would you mind pointing out the breakpoint -STABLE snapshot date, please? Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Mon Dec 8 01:20:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA20845 for hackers-outgoing; Mon, 8 Dec 1997 01:20:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA20792 for ; Mon, 8 Dec 1997 01:19:48 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id KAA02179; Mon, 8 Dec 1997 10:20:12 +0100 (MET) (envelope-from sos) Message-Id: <199712080920.KAA02179@sos.freebsd.dk> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: from Julian Elischer at "Dec 8, 97 00:00:36 am" To: julian@whistle.com (Julian Elischer) Date: Mon, 8 Dec 1997 10:20:12 +0100 (MET) Cc: sos@FreeBSD.dk, hackers@FreeBSD.ORG, mckusick@mckusick.com From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > On Mon, 8 Dec 1997, S?ren Schmidt wrote: > > > > Wrong, if a filesystem is mounted, it uses the mnt_stat.f_bsize instead. > > Exactly.. this is the 100% wrong thing to do. No, not wxactly, depends on what you want to accomplish. > This represents the blocksize of the filesystem on which the > /dev directory resides. This is completely independent of the > blocksize of the device you are trying to write to. > DEVFS has a blocksize of 1 byte, though I SAY 128 for no real reason. Make devfs use 512 byte blocks then... > So therefore I started getting writes that were made to be multiples of > 128. You think this is correct? I am talking about doing the right thing, > which is somehow asking the device what it's blocksize is. Well, the system really does not handle sizes different from the size on the actual device modulo 512 bytes, that needs to change somehow. > My system here is working because I removed that code and said > > bsize = 512; > > which won't help with cdroms and other devices but at least get's me up > and going.. I could have made DEVFS report it's blocksize as 512, but that > would just bury the problem. I want to FIX it which is what this email was > about.. Well, it works on "normal" filesystems where mnt_stat.f_bsize is = 1024 in a default filesys, one can then change that to fit the device. Yes its ugly, but it came in with the != 512 byte sector stuff which somebody, i've long forgotten their names, did submit. > > This is endeed an ugly hack (I put it there to accomodate devices with > > != 512 byt sectors) > > Which it totally fails to do because everything thinks that they are 512 > byte devices, because /dev is on a 512 byte filesystem device. Well, as it is now the system can ONLY handle 512byte blocks, everything else i going to fail. UNLESS it is a true multiple of 512 and the mounted filesys has a blocksize that fits... Using less than 512 bytes will not work with the current system. > > The whole thing boils down to the question of who deals with the actual > > blocksize of the device. Either the entire system knows how to deal > > with it (as it sortof is now), or it is handled in the device/slice > > layer. I was newer able to favour one clearly above the other... > > the trouble is that you chose the wrong value to key off. > If it were the correct value, the rest of the system would behave a LOT > better. Well, depends on viewpoint I guess, for the purpose it was added it DTRT. Te real trouble is that userlevel things like fdisk newfs & disklabel need to know this too, go through the commits and locate the one where I put in the != 512 byte sector support. > (and I know I've done similar things so this is really nothing more than a > very MINOR pointy hat in your direction..) Just banging the number to 512 > would have been more correct as at least it would have been OBVIOUSLY > wrong rather than obscurely wrong. (hat awarded by BDE not me, he found > it) NO, that wouldn't work at all, that was how it was before, and it made spec_getpages fail on != 512 byte sector devices... And since there was NO easy way of getting the device block size, this hack was invented... Agreed this needs to change, but as the authors of the != 512byte sec code also found out, it has some rather serious impacts on the system. I think they worked further on getting this solved, but I've never heard from them again. Actually I think that the driver should pass on the native blocksize of the device, and the slice code should translate that into the system size be it 512 or whatever, change all the plases in the code where 512 byte size is used, well is a HUGE and errorprone job... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Mon Dec 8 01:36:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA21912 for hackers-outgoing; Mon, 8 Dec 1997 01:36:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA21901 for ; Mon, 8 Dec 1997 01:36:27 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA28372; Mon, 8 Dec 1997 09:35:07 +0100 From: Luigi Rizzo Message-Id: <199712080835.JAA28372@labinfo.iet.unipi.it> Subject: Re: Why FIONREAD has no dual for write ? To: julian@whistle.com (Julian Elischer) Date: Mon, 8 Dec 1997 09:35:06 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Dec 7, 97 11:07:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [first of all, thanks for answering...] > > FIONREAD tells you how many bytes you can read before blocking. > > > > There is no FIONWRITE call (how many bytes you can write before ... > but it could change between the time you do that call and the time that > doo the write (you could be sharing a file descriptor, or you could be > sharing a device) so you may have to handle the blocking write anyhow. same for FIONREAD, which is there. Many programs are written under the assumption that there is no sharing of descriptors and they will fail poorly when this happens. E.g. can you tell me how many device drivers implement mutual exclusion on blocking calls, rather than limiting to allow only a single open() and then hope that fork()ed processes synchronize in using the inherited device ? The discussion was on this forum some time ago and the conclusion was more or less 'if they are looking for trouble let them have them' > > And there is no FIOWQUEUED call (or similar name) to tell how many > > bytes are queued for I/O on a given descriptor. > > true > do you really thing this is useful? ... > possibly there might be a more DIRECT way of doing what you want with > appropriate device driver. ... > Well, I guess it wouldn't help any programs with aims of being > portable. there are direct ways in each driver, but each driver implements almost exactly the same function using a different name. This way you not only lose portability across different architectures, you also lose portability across different drivers. As an example, I implemented "FIONWRITE" and "FIOWQUEUED" in the audio driver, but decided to call them AIONWRITE and AIOSYNC to avoid name clashes with FIO* (and complaints from the censors). Hannu just implemented "FIOWQUEUED" in OSS, calling it SNDCTL_DSP_GETODELAY. I am sure there are equivalent calls with several other audio drivers, just that I have no idea what are they called. What do we gain from this ? We have a 20 years old interface (FIONREAD..) and I can understand that at that time some needs (e.g. synchronizing streams) were simply not there. Now we have new requirements and apps, and it would be appropriate to work on a common interface which is as device independent as possible. I don't think one has to worry too much about portability here since the alternative is the use of non-standardized functions anyways. > If you can get iti past the censors then I guess it would be ok, but > I can imagine a few screams from some quarters. Yes, but _who_ are the censors and whom should I ask ? This is not a FreeBSD only thing I imagine... 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 Mon Dec 8 02:17:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA24664 for hackers-outgoing; Mon, 8 Dec 1997 02:17:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA24644 for ; Mon, 8 Dec 1997 02:17:26 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id CAA18698; Mon, 8 Dec 1997 02:16:39 -0800 (PST) To: Julian Elischer cc: Nate Williams , hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: [hackers:] Architectural advice needed In-reply-to: Your message of "Mon, 08 Dec 1997 00:10:22 PST." Date: Mon, 08 Dec 1997 02:16:39 -0800 Message-ID: <18693.881576199@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Ah this would be the CLOSED LIST to which I have not been admitted though > I have asked to join several times, yes? Actually, that list hasn't been used for over a year and should probably be retired. I don't think it ever fulfilled its purpose. Jordan From owner-freebsd-hackers Mon Dec 8 02:27:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA25338 for hackers-outgoing; Mon, 8 Dec 1997 02:27:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA25325 for ; Mon, 8 Dec 1997 02:27:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id KAA13818 for ; Mon, 8 Dec 1997 10:27:38 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id LAA13318; Mon, 8 Dec 1997 11:27:07 +0100 (MET) X-To: Joerg Wunsch To: hackers@freebsd.org Subject: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> From: Eivind Eklund Date: 08 Dec 1997 11:27:06 +0100 In-Reply-To: J Wunsch's message of Mon, 8 Dec 1997 09:17:29 +0100 Message-ID: <863ek4p1tx.fsf_-_@bitbox.follo.net> Lines: 110 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [J Wunsch ] > As Sean Eric Fagan wrote: > > > sef 1997/12/07 10:16:45 PST > > > > Modified files: > > sys/kern kern_exit.c > > Log: > > Surround the call to procfs_exit() by #ifdef PROCFS/#endif -- much to my > > surprise, procfs actually is optional, and some people truly do generate > > kernels without it. Wow. I built a kernel without 'options PROCFS' and > > it compiled and linked. > > Without reviewing this patch, i'm fearing it might have broken the LKM > case for procfs now. sef did a later commit that fixed this - it should be OK now. > There should be no #ifdef FOOFS anywhere in the > code unless one is very careful to account for the LKM cases. All > these #ifdef FOOFS are the major showstopper to not switch the entire > kernel to the new option model (and once and for all get rid of the > "Removing old compile directory" hack in config(8) again). We should > move the entire kernel to the new option model before 3.0 ships. > (#ifdef INET etc. is the second class of showstoppers.) "New option model" refers to the opt_* header files, I guess? Are there anything more that should be done here than the following two steps? (1) weeding LINT against /sys/conf/options and /sys/i386/conf/options.i386 to find what options are not currently handled. (2) Add these options one by one to either /sys/conf/options or /sys/i386/conf/options.i386 as appropriate, at the same time going through the source and adding the correct option include to the files that use the symbol. The following is a result of running a weed against LINT and the options files - if each of these are taken care of, we shouldn't have to allow non-specified options anymore. If no other enterprising soul step forward, I might have a look at it - I think it might be possible to fix automatically with a perl script. (The ones listed in LINT and not options are the interesting ones). /sys/conf/options:ARP_PROXYALL opt_defunct.h /sys/conf/options:CHILD_MAX opt_defunct.h /sys/conf/options:EXTRAVNODES opt_defunct.h /sys/conf/options:OPEN_MAX opt_defunct.h /sys/i386/conf/LINT: BOOTP /sys/i386/conf/LINT: BOOTP_COMPAT /sys/i386/conf/LINT: BOOTP_NFSROOT /sys/i386/conf/LINT: BOOTP_NFSV3 /sys/i386/conf/LINT: CLUSTERDEBUG /sys/i386/conf/LINT: COMPAT_43 /sys/i386/conf/LINT: DEBUG /sys/i386/conf/LINT: DEVFS /sys/i386/conf/LINT: DIAGNOSTIC /sys/i386/conf/LINT: EXT2FS /sys/i386/conf/LINT: FAILSAFE /sys/i386/conf/LINT: FDSEEKWAIT /sys/i386/conf/LINT: FFS /sys/i386/conf/LINT: INET /sys/i386/conf/LINT: IPTUNNEL /sys/i386/conf/LINT: IPX /sys/i386/conf/LINT: IPXIP /sys/i386/conf/LINT: LFS /sys/i386/conf/LINT: LINT_PCCARD_HACK /sys/i386/conf/LINT: LOCKF_DEBUG /sys/i386/conf/LINT: MD5 /sys/i386/conf/LINT: MFS_AUTOLOAD /sys/i386/conf/LINT: MFS_ROOT /sys/i386/conf/LINT: MSDOSFS /sys/i386/conf/LINT: NATM /sys/i386/conf/LINT: NETATALK /sys/i386/conf/LINT: NFS /sys/i386/conf/LINT: NPX_DEBUG /sys/i386/conf/LINT: NQNFS /sys/i386/conf/LINT: NSWAPDEV /sys/i386/conf/LINT: POWERFAIL_NMI /sys/i386/conf/LINT: SCSI_2_DEF /sys/i386/conf/LINT: SIMPLELOCK_DEBUG /sys/i386/conf/LINT: SI_DEBUG /sys/i386/conf/LINT: SPX_HACK /sys/i386/conf/LINT: SUIDDIR /sys/i386/conf/LINT: TCP_COMPAT_42 /sys/i386/conf/options.i386:AHC_SHARE_SCBS opt_aic7xxx.h /sys/i386/conf/options.i386:AUTO_EOI_2 opt_auto_eoi.h /sys/i386/conf/options.i386:BOUNCEPAGES opt_bounce.h /sys/i386/conf/options.i386:COMCONSOLE opt_defunct.h /sys/i386/conf/options.i386:CONADDR opt_defunct.h /sys/i386/conf/options.i386:CONUNIT opt_defunct.h /sys/i386/conf/options.i386:PANIC_REBOOT_WAIT_TIME opt_panic.h /sys/i386/conf/options.i386:PCVT_24LINESDEF opt_pcvt.h /sys/i386/conf/options.i386:PCVT_CTRL_ALT_DEL opt_pcvt.h /sys/i386/conf/options.i386:PCVT_EMU_MOUSE opt_pcvt.h /sys/i386/conf/options.i386:PCVT_FREEBSD opt_pcvt.h /sys/i386/conf/options.i386:PCVT_META_ESC opt_pcvt.h /sys/i386/conf/options.i386:PCVT_NSCREENS opt_pcvt.h /sys/i386/conf/options.i386:PCVT_PRETTYSCRNS opt_pcvt.h /sys/i386/conf/options.i386:PCVT_SCREENSAVER opt_pcvt.h /sys/i386/conf/options.i386:PCVT_USEKBDSEC opt_pcvt.h /sys/i386/conf/options.i386:PCVT_VT220KEYB opt_pcvt.h /sys/i386/conf/options.i386:SC_SPLASH_SCREEN opt_syscons.h Eivind. From owner-freebsd-hackers Mon Dec 8 02:33:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA25800 for hackers-outgoing; Mon, 8 Dec 1997 02:33:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA25691 for ; Mon, 8 Dec 1997 02:31:45 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id FAA04256; Mon, 8 Dec 1997 05:22:46 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712081022.FAA04256@dyson.iquest.net> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712080920.KAA02179@sos.freebsd.dk> from =?ISO-8859-1?Q?S=F8ren_Schmidt?= at "Dec 8, 97 10:20:12 am" To: sos@FreeBSD.dk Date: Mon, 8 Dec 1997 05:22:46 -0500 (EST) Cc: julian@whistle.com, sos@FreeBSD.dk, hackers@freebsd.org, mckusick@mckusick.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt said: > > Actually I think that the driver should pass on the native blocksize of > the device, and the slice code should translate that into the system > size be it 512 or whatever, change all the plases in the code where > 512 byte size is used, well is a HUGE and errorprone job... > I am starting to believe that it needs to be done sooner rather than later. The question is: who is the one who is going to take the heat? :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Mon Dec 8 02:37:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA26052 for hackers-outgoing; Mon, 8 Dec 1997 02:37:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from stingray.ivision.co.uk (stingray.ivision.co.uk [195.50.91.40]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA26043 for ; Mon, 8 Dec 1997 02:37:17 -0800 (PST) (envelope-from manar@ivision.co.uk) Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #1) id 0xf0Yt-0006LL-00; Mon, 8 Dec 1997 10:37:15 +0000 Comments: Authenticated sender is From: "Manar Hussain" Organization: Internet Vision To: hackers@freebsd.org Date: Mon, 8 Dec 1997 10:34:57 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: hackers-digest V3 #456 Priority: normal In-reply-to: <199712080131.RAA12338@hub.freebsd.org> X-mailer: Pegasus Mail for Win32 (v2.54) Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ~~ Like it is illeagal to export ssh from the US? > ~~ Like there is no free ssh ~~client for windows? > ~~ What about ssh for Windows? > http://public.srce.hr/~cigaly/ssh > (or for a faster connection) > ftp://hotline.pvt.net/pub/win_utils/winsock > It's not very good, but it's free. As the man says - not brilliant, but it works and means you can possibly get rid of telnetd all together (as we have on all bar one machine now) So how about a free ssh client for the Mac :-> Manar -- Internet Vision Internet Consultancy Tel: 0171 589 4500 60 Albert Court & Web development Fax: 0171 589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk From owner-freebsd-hackers Mon Dec 8 02:44:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA26712 for hackers-outgoing; Mon, 8 Dec 1997 02:44:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA26658 for ; Mon, 8 Dec 1997 02:44:00 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id LAA02338; Mon, 8 Dec 1997 11:43:42 +0100 (MET) (envelope-from sos) Message-Id: <199712081043.LAA02338@sos.freebsd.dk> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712081022.FAA04256@dyson.iquest.net> from "John S. Dyson" at "Dec 8, 97 05:22:46 am" To: toor@dyson.iquest.net (John S. Dyson) Date: Mon, 8 Dec 1997 11:43:37 +0100 (MET) Cc: sos@FreeBSD.dk, julian@whistle.com, hackers@freebsd.org, mckusick@mckusick.com From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to John S. Dyson who wrote: > Søren Schmidt said: > > > > Actually I think that the driver should pass on the native blocksize of > > the device, and the slice code should translate that into the system > > size be it 512 or whatever, change all the plases in the code where > > 512 byte size is used, well is a HUGE and errorprone job... > > > I am starting to believe that it needs to be done sooner rather than later. > The question is: who is the one who is going to take the heat? :-). Yep, I've belived that for a long time :) I still think that device blocksize should be dealt with in a layer between the devicedriver and the slice (new or old) code. That will make the code cleaner int eh rest of the kernel, and it will reduce the number of errors introduced (hopefully). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Mon Dec 8 02:45:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA26880 for hackers-outgoing; Mon, 8 Dec 1997 02:45:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA26867; Mon, 8 Dec 1997 02:45:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id KAA14015; Mon, 8 Dec 1997 10:45:30 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id LAA13342; Mon, 8 Dec 1997 11:44:59 +0100 (MET) To: Julian Elischer Cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: Route behaviour (was Re: cvs commit: src/usr.sbin/ppp command.c ppp.8 route.c) References: From: Eivind Eklund Date: 08 Dec 1997 11:44:57 +0100 In-Reply-To: Julian Elischer's message of Sun, 7 Dec 1997 17:19:50 -0800 (PST) Message-ID: <86yb1wnmfq.fsf@bitbox.follo.net> Lines: 10 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer writes: > I had changes that made the outgoing packets take the first IP address of > the interface if there was no address already bound.. > don't know what happenned to them. They seem to still be there, but doesn't help much if the interface hasn't been assigned an address. Eivind. From owner-freebsd-hackers Mon Dec 8 04:00:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00924 for hackers-outgoing; Mon, 8 Dec 1997 04:00:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.cylink.net (gatekeeper.cylink.com.cy [194.42.128.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00915 for ; Mon, 8 Dec 1997 04:00:27 -0800 (PST) (envelope-from Andreas.Engel@cylink.net) Received: from andrease (verpissdic@andrease.cylink.net [194.42.134.67]) by gatekeeper.cylink.net (8.8.7/8.8.3) with SMTP id OAA06922 ; Mon, 8 Dec 1997 14:00:22 +0200 (EET) Message-ID: <01b801bd03d0$dc76dc60$43862ac2@andrease.cylink.net> From: "Andreas Engel" To: Subject: unnumbered interfaces Date: Mon, 8 Dec 1997 14:00:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2020.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2020.0 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hi there, is it possible to configure an interface unnumbered with FreeBSD ?-) this would solve some probs for me Thanx Andreas :)) From owner-freebsd-hackers Mon Dec 8 04:34:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA02595 for hackers-outgoing; Mon, 8 Dec 1997 04:34:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [194.93.177.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA02534 for ; Mon, 8 Dec 1997 04:32:28 -0800 (PST) (envelope-from ru@relay.ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.8.8/8.8.8) id OAA07525 for hackers@freebsd.org; Mon, 8 Dec 1997 14:31:33 +0200 (EET) (envelope-from ru) From: Ruslan Ermilov Message-Id: <199712081231.OAA07525@relay.ucb.crimea.ua> Subject: help: divert sockets question To: hackers@freebsd.org Date: Mon, 8 Dec 1997 14:31:33 +0200 (EET) X-My-Interests: Unix,Oracle,Networking X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Hackers! I'm in process of writing a small `iptunnel' program which lets me tunnel IP traffic thru UDP. My program uses two sockets: UDP and divert. It reads IP-packet from divert socket and sends it to the remote machine thru UDP. Remote machine then reads it from UDP and reinjects the IP-packet by writing it to the divert socket. And vice versa. It works greatly! Problem: I want to reinject received thru UDP IP-packet as incoming. `man ipdivert' says that I should use sendto() syscall with a destination address equal to IP address of some my local interface. I did it and it doesn't works. It seems to me like a kernel is just dropping such a packet. But no error returned from sendto(), no packets travel thru the firewall. Can anyone point me a way to write packet as incoming? Should I change some IP-packet fields? TIA, -- Ruslan A. Ermilov System Administrator ru@ucb.crimea.ua United Commercial Bank +380-652-247647 Simferopol, Crimea 2426679 ICQ Network, UIN From owner-freebsd-hackers Mon Dec 8 05:01:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA04265 for hackers-outgoing; Mon, 8 Dec 1997 05:01:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA04259 for ; Mon, 8 Dec 1997 05:01:31 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id IAA04659; Mon, 8 Dec 1997 08:01:16 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Mon, 8 Dec 1997 08:01:15 -0500 (EST) From: "David E. Cross" To: Julian Elischer cc: Luigi Rizzo , hackers@FreeBSD.ORG Subject: Re: Why FIONREAD has no dual for write ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 7 Dec 1997, Julian Elischer wrote: > On Sat, 6 Dec 1997, Luigi Rizzo wrote: > > > I think I already brought this out but recent discussion on mpegtv > > suggests to bring this out again. > > > > FIONREAD tells you how many bytes you can read before blocking. > > > > There is no FIONWRITE call (how many bytes you can write before > > blocking) which would be nice to have, instead of having to resort to > > non-blocking writes. > > but it could change between the time you do that call and the time that > doo the write (you could be sharing a file descriptor, or you could be > sharing a device) so you may have to handle the blocking write anyhow. This is true even for FIONREAD, you could be sharing a file descriptor, and another process could read that data before you do. -- David Cross ACS Consultant From owner-freebsd-hackers Mon Dec 8 06:21:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA09347 for hackers-outgoing; Mon, 8 Dec 1997 06:21:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA09340; Mon, 8 Dec 1997 06:21:03 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id JAA21823; Mon, 8 Dec 1997 09:20:56 -0500 (EST) Date: Mon, 8 Dec 1997 09:20:55 -0500 (EST) From: John Fieber To: "Jordan K. Hubbard" cc: Andrew Stesin , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, Andrew Stesin wrote: > On Sun, 7 Dec 1997, John Fieber wrote: > > > The patch in the updates directory on ftp.freebsd.org should be > > updated. The errata says: > > > > o Intel "F00F bug" enables users to hang machines with Pentium > > processors if they have access to the machine and can execute programs. > > > > Fix: Update to the 2.2-stable version of the kernel or apply the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Would you mind pointing out the breakpoint -STABLE snapshot date, > please? I don't have an answer, but checking back in the file I was rather stunned to notice that there is NO date information for any of the updates. If you are applying the supplied patches, that is probably okay, but a big problem for anyone being very conservative and/or selective about tracking stable. As has been brought up recently, blindly tracking a "stable" kernel without updating user-land utilities can bite you--I learned this from personal experience. A list of affected source files with version numbers would also be very helpful, but I'll grant that could be deduced from the diff---assuming there is one, which is not the case for the lpd update. Finally, a pointer to www.freebsd.org/handbook/stable.html would be good to mention whenever suggesting that people track stable. -john From owner-freebsd-hackers Mon Dec 8 06:34:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10088 for hackers-outgoing; Mon, 8 Dec 1997 06:34:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10081 for ; Mon, 8 Dec 1997 06:34:28 -0800 (PST) (envelope-from thompson@tgsoft.com) Received: from squirrel.tgsoft.com (cx20270-a.pwy1.sdca.home.com [24.0.169.3]) by freefall.freebsd.org (8.8.6/8.8.5) with SMTP id GAA03167 for ; Mon, 8 Dec 1997 06:32:55 -0800 (PST) Received: (qmail 2748 invoked by uid 128); 8 Dec 1997 14:34:23 -0000 Date: 8 Dec 1997 14:34:23 -0000 Message-ID: <19971208143423.2747.qmail@squirrel.tgsoft.com> From: mark thompson To: freebsd-hackers@freebsd.com Subject: linux emu. Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Trying to run executor, on FreeBSD 2.2.1-RELEASE (MARX) #1: . Tantalyzingly close to being useful. When i use the 'Check for floppy' function i get... LINUX: 'ioctl' fd=5, typ=0x53(S), num=0xb not implemented I am willing to bet that fd=5 is the floppy. Any idea what ioctl 0x53/0xb is supposed to do? -mark From owner-freebsd-hackers Mon Dec 8 06:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10900 for hackers-outgoing; Mon, 8 Dec 1997 06:47:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10895; Mon, 8 Dec 1997 06:47:03 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id JAA06684; Mon, 8 Dec 1997 09:46:52 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Mon, 8 Dec 1997 09:46:52 -0500 (EST) From: "David E. Cross" To: John Fieber cc: "Jordan K. Hubbard" , Andrew Stesin , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, John Fieber wrote: > I don't have an answer, but checking back in the file I was rather > stunned to notice that there is NO date information for any of the > updates. If you are applying the supplied patches, that is probably > okay, but a big problem for anyone being very conservative and/or > selective about tracking stable. As has been brought up recently, > blindly tracking a "stable" kernel without updating user-land utilities > can bite you--I learned this from personal experience. Yes, I would like to know how to see what the changelogs are for each version of a file... I know it is possible, I have seen excerpts posted from them here occasionally. Re: -stable kernel and userland conflicts... I always do a make world whenever I CVSUP-stable.... mostly to get possible security fixes to -stable in userland code. And with the ease that FreeBSD allows you to do make world, it is really a 'Good Idea'(tm) IMO. -- David Cross ACS Consultant From owner-freebsd-hackers Mon Dec 8 07:00:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12195 for hackers-outgoing; Mon, 8 Dec 1997 07:00:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from loki.csc.ncsu.edu (loki.csc.ncsu.edu [152.1.213.138]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA12174 for ; Mon, 8 Dec 1997 07:00:09 -0800 (PST) (envelope-from fwang2@unity.ncsu.edu) Received: from localhost (fwang2@localhost) by loki.csc.ncsu.edu (8.8.4/EC02Jan97) with SMTP id JAA17022; Mon, 8 Dec 1997 09:54:54 -0500 (EST) X-Authentication-Warning: loki.csc.ncsu.edu: fwang2 owned process doing -bs Date: Mon, 8 Dec 1997 09:54:53 -0500 (EST) From: Feiyi Wang X-Sender: fwang2@loki.csc.ncsu.edu To: Ruslan Ermilov cc: hackers@FreeBSD.ORG Subject: Re: help: divert sockets question In-Reply-To: <199712081231.OAA07525@relay.ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, It will work. Here is the way I did it -- snip -- /* this is readIncoming() */ inbytes = recvfrom( fd, inPacketBuf, sizeof inPacketBuf, 0, (struct sockaddr*) &inPacketAddr, &addrsize); /* this is writeIncoming() */ writeIncoming(int fd) { int wrote; wrote = sendto( fd, inPacketBuf, inPacketLen, 0, (struct sockaddr *) &inPacketAddr, sizeof inPacketAddr); if ( wrote != inPacketLen ) fprintf(stderr, "failed to write packet back\n"); else return wrote; } On Mon, 8 Dec 1997, Ruslan Ermilov wrote: > Hi, Hackers! > > I'm in process of writing a small `iptunnel' program > which lets me tunnel IP traffic thru UDP. > > My program uses two sockets: UDP and divert. > > It reads IP-packet from divert socket and > sends it to the remote machine thru UDP. > Remote machine then reads it from UDP and > reinjects the IP-packet by writing it to the > divert socket. > > And vice versa. > > It works greatly! > > Problem: > > I want to reinject received thru UDP IP-packet > as incoming. `man ipdivert' says that I should > use sendto() syscall with a destination address > equal to IP address of some my local interface. > > I did it and it doesn't works. > > It seems to me like a kernel is just dropping such a packet. > But no error returned from sendto(), no packets travel > thru the firewall. > > Can anyone point me a way to write packet as incoming? > Should I change some IP-packet fields? > > TIA, > -- > Ruslan A. Ermilov System Administrator > ru@ucb.crimea.ua United Commercial Bank > +380-652-247647 Simferopol, Crimea > 2426679 ICQ Network, UIN > From owner-freebsd-hackers Mon Dec 8 07:19:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA13416 for hackers-outgoing; Mon, 8 Dec 1997 07:19:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ghpc8.ihf.rwth-aachen.de (ghpc8.ihf.RWTH-Aachen.DE [134.130.90.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA13411; Mon, 8 Dec 1997 07:19:35 -0800 (PST) (envelope-from thomas@ghpc8.ihf.rwth-aachen.de) Received: from ghpc6.ihf.rwth-aachen.de (ghpc6.ihf.rwth-aachen.de [134.130.90.6]) by ghpc8.ihf.rwth-aachen.de (8.8.7/8.8.6) with ESMTP id QAA08100; Mon, 8 Dec 1997 16:18:48 +0100 (CET) Received: (from thomas@localhost) by ghpc6.ihf.rwth-aachen.de (8.8.7/8.8.5) id QAA25350; Mon, 8 Dec 1997 16:18:47 +0100 (CET) To: "David E. Cross" Cc: John Fieber , "Jordan K. Hubbard" , Andrew Stesin , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) References: From: Thomas Gellekum Date: 08 Dec 1997 16:18:46 +0100 In-Reply-To: "David E. Cross"'s message of Mon, 8 Dec 1997 09:46:52 -0500 (EST) Message-ID: <871zzn50dl.fsf@ghpc6.ihf.rwth-aachen.de> Lines: 11 X-Mailer: Gnus v5.4.37/XEmacs 19.16 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "David E. Cross" writes: > Yes, I would like to know how to see what the changelogs are for each > version of a file... I know it is possible, I have seen excerpts posted > from them here occasionally. http://www.freebsd.org/cgi/cvsweg.cgi If you have the CVS repository on your disk simply use `cvs log'. tg From owner-freebsd-hackers Mon Dec 8 07:23:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA13732 for hackers-outgoing; Mon, 8 Dec 1997 07:23:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA13724 for ; Mon, 8 Dec 1997 07:23:09 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id IAA21674; Mon, 8 Dec 1997 08:23:06 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA11391; Mon, 8 Dec 1997 08:23:04 -0700 Date: Mon, 8 Dec 1997 08:23:04 -0700 Message-Id: <199712081523.IAA11391@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: Julian Elischer , Nate Williams , hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <18693.881576199@time.cdrom.com> References: <18693.881576199@time.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ Removed Kirk from the list, he doesn't need to here about FreeBSD politics. ] > > Ah this would be the CLOSED LIST to which I have not been admitted though > > I have asked to join several times, yes? > > Actually, that list hasn't been used for over a year and should > probably be retired. I don't think it ever fulfilled its purpose. That's because no-one ever talks about architecture stuff anymore, and just 'implements' nowadays. I think it *could* fulfill its purpose if it was actually promoted/used. I would have used it in the past if I thought it would be monitored, although it wasn't. Could we consider it 'back in use' for questions such as Julians? Nate From owner-freebsd-hackers Mon Dec 8 07:33:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA14608 for hackers-outgoing; Mon, 8 Dec 1997 07:33:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14569; Mon, 8 Dec 1997 07:33:06 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id KAA21956; Mon, 8 Dec 1997 10:32:41 -0500 (EST) Date: Mon, 8 Dec 1997 10:32:40 -0500 (EST) From: John Fieber To: Thomas Gellekum cc: "David E. Cross" , "Jordan K. Hubbard" , Andrew Stesin , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: <871zzn50dl.fsf@ghpc6.ihf.rwth-aachen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 8 Dec 1997, Thomas Gellekum wrote: > "David E. Cross" writes: > > > Yes, I would like to know how to see what the changelogs are for each > > version of a file... I know it is possible, I have seen excerpts posted > > from them here occasionally. > > http://www.freebsd.org/cgi/cvsweg.cgi > > If you have the CVS repository on your disk simply use `cvs log'. This is great for individual files, but things like the "FOOF fix" are often not represented in a single file, or even in a single commit. Identifying the relevant changes for things like this can only be done by (a) the person who committs the changes or (b) very close observers of the commit logs. Jill or Joe Casual User running a RELEASE, but wanting to keep up on security related fixes must rely on (a) or (b) providing complete and accurate information; cvsweb doesn't quite cut it and blindly upgrading to a stable kernel can have unpleasant surprises. -john From owner-freebsd-hackers Mon Dec 8 08:00:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA16916 for hackers-outgoing; Mon, 8 Dec 1997 08:00:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from beast.gu.net (beast.gu.net [194.93.190.196] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA16895; Mon, 8 Dec 1997 08:00:25 -0800 (PST) (envelope-from stesin@gu.net) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by beast.gu.net (8.8.7/8.7.3) with SMTP id RAA16868; Mon, 8 Dec 1997 17:59:33 +0200 (EET) Date: Mon, 8 Dec 1997 17:59:33 +0200 (EET) From: Andrew Stesin Reply-To: stesin@gu.net To: John Fieber cc: "Jordan K. Hubbard" , freebsd-hackers@freefall.FreeBSD.org Subject: Re: F00F patch problems for 2.2.5-RELEASE (incomplete patch.) In-Reply-To: Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, John Fieber wrote: > > > Fix: Update to the 2.2-stable version of the kernel or apply the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Would you mind pointing out the breakpoint -STABLE snapshot date, > > please? > > I don't have an answer, but checking back in the file I was > rather stunned to notice that there is NO date information for > any of the updates. ?! > If you are applying the supplied patches, > that is probably okay, but a big problem for anyone being very > conservative and/or selective about tracking stable. That's exactly me myself :) > As has been > brought up recently, blindly tracking a "stable" kernel without > updating user-land utilities can bite you--I learned this from > personal experience. Same here. So I'm just grabbing the whole snapshot from time to time -- no time for extra experimentation. Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Mon Dec 8 08:14:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17775 for hackers-outgoing; Mon, 8 Dec 1997 08:14:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from praline.no.neosoft.com (praline.no.NeoSoft.COM [206.27.160.253]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA17758 for ; Mon, 8 Dec 1997 08:14:18 -0800 (PST) (envelope-from caj@praline.no.neosoft.com) Received: (qmail 22811 invoked by uid 65524); 8 Dec 1997 16:14:16 -0000 Date: Mon, 8 Dec 1997 10:14:15 -0600 (CST) From: Craig Johnston To: Andrew Atrens cc: hackers@FreeBSD.ORG Subject: Re: Should I buy a Cyrix processor? In-Reply-To: <199712052325.PAA22536@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 5 Dec 1997, Andrew Atrens wrote: > > My 2c, > > I've got a K6-200 and I'm sad to say this particular chip is not overclockable. > Even with the big fan, grease, and huge-mother-heat-sink it still locks up. Have you tried extra voltage? From owner-freebsd-hackers Mon Dec 8 08:16:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17940 for hackers-outgoing; Mon, 8 Dec 1997 08:16:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17924 for ; Mon, 8 Dec 1997 08:16:05 -0800 (PST) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id SAA31754 for ; Mon, 8 Dec 1997 18:53:44 +0100 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id RAA15393 for ; Mon, 8 Dec 1997 17:40:47 +0100 (CET) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id RAA24056; Mon, 8 Dec 1997 17:14:57 +0100 (CET) Message-ID: <19971208171457.56387@deepo.prosa.dk> Date: Mon, 8 Dec 1997 17:14:57 +0100 From: Philippe Regnauld To: hackers@freebsd.org Subject: Question about ccd and disk failure Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A recent discussion in -current regarding a failing wd0 disk makes me think about something: I have at least two machines (one of them a dedicated dialup box) that use ccd and mirroring (ccd 0x04) on two smallish junk harddisks (i.e.: I'll probably make a floppy out of it one day :-) My thought was: to hell with backups on this box, all the conf. files fit on a floppy, an and if I want to be up quick if/when one of the disks dies, I just remove the bad one, adjust ccd parameters (I've already tried this: using ccd for 'mirroring' on only one of the two remaining disks works great) and reboot. Now my idea is: how tolerant can we be if one of the two disks goes toast ? Meaning, how difficult (implications, 125-gotchas list, etc...) would it be to have ccd just stop writing to a disk after so many errors, and try to failover to the other one only ? Of course we have a problem with / :-( [not subscribed to -hackers] -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- "Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?" - S. Kelly Bootle, about Cerberus ["MYTHOLOGY", in Marutukku distrib] - From owner-freebsd-hackers Mon Dec 8 08:21:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18369 for hackers-outgoing; Mon, 8 Dec 1997 08:21:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [194.93.177.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18164 for ; Mon, 8 Dec 1997 08:19:10 -0800 (PST) (envelope-from ru@relay.ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.8.8/8.8.8) id SAA11172; Mon, 8 Dec 1997 18:12:49 +0200 (EET) (envelope-from ru) From: Ruslan Ermilov Message-Id: <199712081612.SAA11172@relay.ucb.crimea.ua> Subject: Re: help: divert sockets question In-Reply-To: from Feiyi Wang at "Dec 8, 97 09:54:53 am" To: fwang2@unity.ncsu.edu (Feiyi Wang) Date: Mon, 8 Dec 1997 18:12:49 +0200 (EET) Cc: hackers@freebsd.org X-My-Interests: Unix,Oracle,Networking X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I did it the same way. It doesn't work for me ;-( In general, I have a packet received trhu udp from remote machine, and I need to write it as incoming on a local machine. Usually, you read the packet from divert socket first using recvfrom(), then optionally modify it, and then write it back using sendto(). My case is differ, because I just need to write a packet as incoming, not reading it from divert socket first. Does it make sense? Once Feiyi Wang wrote: > Hi, > > It will work. Here is the way I did it > > -- snip -- > > > /* this is readIncoming() */ > > inbytes = recvfrom( fd, > inPacketBuf, > sizeof inPacketBuf, > 0, > (struct sockaddr*) &inPacketAddr, > &addrsize); > > > /* this is writeIncoming() */ > > writeIncoming(int fd) > { > int wrote; > wrote = sendto( fd, > inPacketBuf, > inPacketLen, > 0, > (struct sockaddr *) &inPacketAddr, > sizeof inPacketAddr); > > if ( wrote != inPacketLen ) > fprintf(stderr, "failed to write packet back\n"); > else > return wrote; > } > > > > On Mon, 8 Dec 1997, Ruslan Ermilov wrote: > > > Hi, Hackers! > > > > I'm in process of writing a small `iptunnel' program > > which lets me tunnel IP traffic thru UDP. > > > > My program uses two sockets: UDP and divert. > > > > It reads IP-packet from divert socket and > > sends it to the remote machine thru UDP. > > Remote machine then reads it from UDP and > > reinjects the IP-packet by writing it to the > > divert socket. > > > > And vice versa. > > > > It works greatly! > > > > Problem: > > > > I want to reinject received thru UDP IP-packet > > as incoming. `man ipdivert' says that I should > > use sendto() syscall with a destination address > > equal to IP address of some my local interface. > > > > I did it and it doesn't works. > > > > It seems to me like a kernel is just dropping such a packet. > > But no error returned from sendto(), no packets travel > > thru the firewall. > > > > Can anyone point me a way to write packet as incoming? > > Should I change some IP-packet fields? > > > > TIA, > > -- > > Ruslan A. Ermilov System Administrator > > ru@ucb.crimea.ua United Commercial Bank > > +380-652-247647 Simferopol, Crimea > > 2426679 ICQ Network, UIN > > > > -- Ruslan A. Ermilov System Administrator ru@ucb.crimea.ua United Commercial Bank +380-652-247647 Simferopol, Crimea 2426679 ICQ Network, UIN From owner-freebsd-hackers Mon Dec 8 08:27:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18814 for hackers-outgoing; Mon, 8 Dec 1997 08:27:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lily.ezo.net (root@lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18807 for ; Mon, 8 Dec 1997 08:27:12 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id LAA03000; Mon, 8 Dec 1997 11:26:27 -0500 (EST) Date: Mon, 8 Dec 1997 11:26:26 -0500 (EST) From: Jim Flowers To: Andreas Engel cc: hackers@freebsd.org Subject: Re: unnumbered interfaces In-Reply-To: <01b801bd03d0$dc76dc60$43862ac2@andrease.cylink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am running a user ppp connection between two FreeBSD boxes with the same ip number for both the tun0 and ed2 interfaces. It appears to operate as a numberless connection should. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Mon, 8 Dec 1997, Andreas Engel wrote: > hi there, > > is it possible to configure an interface unnumbered with FreeBSD ?-) > this would solve some probs for me > > Thanx Andreas :)) > > From owner-freebsd-hackers Mon Dec 8 08:44:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA19712 for hackers-outgoing; Mon, 8 Dec 1997 08:44:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19705 for ; Mon, 8 Dec 1997 08:44:08 -0800 (PST) (envelope-from teima@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id RAA16625 for ; Mon, 8 Dec 1997 17:43:59 +0100 (MET) Received: from kk660.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id RAA05855; Mon, 8 Dec 1997 17:43:54 +0100 From: teima@kk.etx.ericsson.se (Valter Mazzaro) Received: by kk660.kk.etx.ericsson.se (SMI-8.6/client-1.6) id RAA05250; Mon, 8 Dec 1997 17:43:55 +0100 Date: Mon, 8 Dec 1997 17:43:55 +0100 Message-Id: <199712081643.RAA05250@kk660.kk.etx.ericsson.se> To: hackers@FreeBSD.ORG Subject: natd settings problem X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I've some problems with the following configuration: _________ HOST1-----------------|de1 de3|-------------------ISP1 | | | | | AS | | | | HOST2---- |_________| HOST1 address: 192.168.104.10 HOST2 address: 192.168.104.11 de1 address: 192.168.104.1 de3 address: 193.10.15.156 ISP address: 193.10.15.157 My purpose is to run a video conference application (vic) between HOST1/2 and ISP. In AS a natd daemon is running. The problem is that, with the present settings, I've succeeded in running vic just between ISP and ONE host AT THE TIME!! The daemon is started with: natd -m -f natd.conf where natd.conf: use_sockets port 6668 interface de3 permanent_link udp 192.168.104.10:4444 193.10.15.157:0 4444 permanent_link udp 192.168.104.10:4445 193.10.15.157:0 4445 Vic uses 4444 and 4445 as known ports to establish the connession and to exchange data. With this conf file I don't have any problem in let HOST1 and ISP interact. If I try to connect also HOST2, adding in the natd.conf: permanent_link udp 192.168.104.11:4444 193.10.15.157:0 4444 permanent_link udp 192.168.104.11:4445 193.10.15.157:0 4445 of course natd doesn't discriminate the packets because the only difference in the packets entering AS on de3 is the source port, that is not known a priori, so I'm forced to left the wildcards "0" in natd.conf. How can I solve it? Should I run two different natd daemons, diverting packets to different ports? I'm quite new with these problems, it would be great if someone could give me an hint! Thanks Valter ------------- Valter Mazzaro Ericsson Switchlab From owner-freebsd-hackers Mon Dec 8 09:39:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22999 for hackers-outgoing; Mon, 8 Dec 1997 09:39:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22987 for ; Mon, 8 Dec 1997 09:38:59 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from gjallarhorn.ifi.uio.no (2602@gjallarhorn.ifi.uio.no [129.240.65.40]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id SAA20520 for ; Mon, 8 Dec 1997 18:38:53 +0100 (MET) Received: (from dag-erli@localhost) by gjallarhorn.ifi.uio.no ; Mon, 8 Dec 1997 18:38:53 +0100 (MET) To: hackers@freebsd.org Subject: isa.c Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 08 Dec 1997 18:38:52 +0100 Message-ID: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c from -current? -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep From owner-freebsd-hackers Mon Dec 8 09:39:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA23032 for hackers-outgoing; Mon, 8 Dec 1997 09:39:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA22986 for ; Mon, 8 Dec 1997 09:38:58 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras515.srv.net [205.180.127.15]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id KAA11495; Mon, 8 Dec 1997 10:38:25 -0700 Date: Mon, 8 Dec 1997 10:37:46 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home Reply-To: Charles Mott To: Valter Mazzaro cc: hackers@FreeBSD.ORG Subject: Re: natd settings problem In-Reply-To: <199712081643.RAA05250@kk660.kk.etx.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, Valter Mazzaro wrote: > My purpose is to run a video conference application (vic) between HOST1/2 and > ISP. > In AS a natd daemon is running. The problem is that, with the present settings, > I've succeeded in running vic just between ISP and ONE host AT THE TIME!! [snip] > permanent_link udp 192.168.104.10:4444 193.10.15.157:0 4444 > permanent_link udp 192.168.104.10:4445 193.10.15.157:0 4445 > > Vic uses 4444 and 4445 as known ports to establish the connession and to > exchange data. With this conf file I don't have any problem in let HOST1 > and ISP interact. > > If I try to connect also HOST2, adding in the natd.conf: > > permanent_link udp 192.168.104.11:4444 193.10.15.157:0 4444 > permanent_link udp 192.168.104.11:4445 193.10.15.157:0 4445 The problem is that you cannot simultaneously redirect a single port on the aliasing host to two distinct machines (192.168.104.10 and .11). Now, if you had two registered addresses for your natd box (perhaps 193.10.15.155 and .156), it would be possible to do something like redirect_port 192.168.104.10:4444 193.10.15.155:4444 193.10.15.157:0 redirect_port 192.168.104.10:4445 193.10.15.155:4445 193.10.15.157:0 redirect_port 192.168.104.11:4444 193.10.15.156:4444 193.10.15.157:0 redirect_port 192.168.104.11:4445 193.10.15.156:4445 193.10.15.157:0 I don't know that you can get two registered IP addresses, so this probably isn't too useful to you. The problem is that when you redirect the same address/port combination to more than one machine, only the last machine you designated gets the traffic. It might be possible to add a internal broadcast function to natd so that video conferencing would work. I seem to remember there is broadcast support in the UDP protocol, so may be the packet aliasing engine used by natd could take this into account. Charles Mott From owner-freebsd-hackers Mon Dec 8 10:23:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26528 for hackers-outgoing; Mon, 8 Dec 1997 10:23:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from onyx.atipa.com (user26223@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA26517 for ; Mon, 8 Dec 1997 10:22:57 -0800 (PST) (envelope-from freebsd@atipa.com) Received: (qmail-queue invoked by uid 1018); 8 Dec 1997 18:28:43 -0000 Date: Mon, 8 Dec 1997 11:28:43 -0700 (MST) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Paul Traina cc: hackers@FreeBSD.ORG Subject: Re: metricom & freebsd In-Reply-To: <199712051631.IAA16546@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Do you mean myricom / myrinet? Kevin On Fri, 5 Dec 1997, Paul Traina wrote: > Has anyone done a Metricom star mode driver for FreeBSD? > (Star mode is the higher speed packet-oriented mode, Linux has a driver). > From owner-freebsd-hackers Mon Dec 8 10:23:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA26584 for hackers-outgoing; Mon, 8 Dec 1997 10:23:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA26564 for ; Mon, 8 Dec 1997 10:23:22 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA06897; Mon, 8 Dec 1997 11:36:53 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd006847; Mon Dec 8 11:36:43 1997 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA23908; Mon, 8 Dec 1997 11:22:33 -0700 (MST) From: Terry Lambert Message-Id: <199712081822.LAA23908@usr01.primenet.com> Subject: Re: Why FIONREAD has no dual for write ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 8 Dec 1997 18:22:33 +0000 (GMT) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199712080835.JAA28372@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 8, 97 09:35:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What do we gain from this ? > > We have a 20 years old interface (FIONREAD..) and I can understand that > at that time some needs (e.g. synchronizing streams) were simply not > there. Now we have new requirements and apps, and it would be appropriate > to work on a common interface which is as device independent as > possible. IMO, the canonically "correct" thing to do would be to read and write using a non-blocking descriptor. This eliminates the multiple reader/ write buffer consumption races. It's short, it's elegant, and you can still use "select()" for the readability/writeability to avoid turning the program into a polling loop. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Dec 8 10:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27080 for hackers-outgoing; Mon, 8 Dec 1997 10:29:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA27072 for ; Mon, 8 Dec 1997 10:29:35 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA22833; Mon, 8 Dec 1997 11:29:34 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA12105; Mon, 8 Dec 1997 11:29:27 -0700 Date: Mon, 8 Dec 1997 11:29:27 -0700 Message-Id: <199712081829.LAA12105@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Cc: hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c > from -current? Almost certainly not, Why would you want to do that? Nate From owner-freebsd-hackers Mon Dec 8 10:33:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27416 for hackers-outgoing; Mon, 8 Dec 1997 10:33:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA27409 for ; Mon, 8 Dec 1997 10:33:29 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id NAA01034; Mon, 8 Dec 1997 13:33:20 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712081833.NAA01034@dyson.iquest.net> Subject: Re: isa.c In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Dec 8, 97 06:38:52 pm" To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: Mon, 8 Dec 1997 13:33:20 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dag-Erling Coidan Smørgrav said: > > Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c > from -current? > It would be a miracle if it would work. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Mon Dec 8 10:51:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28600 for hackers-outgoing; Mon, 8 Dec 1997 10:51:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay.kacst.edu.sa (ns1.kacst.edu.sa [198.77.88.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28558 for ; Mon, 8 Dec 1997 10:50:40 -0800 (PST) (envelope-from onur@dpc.kfupm.edu.sa) Received: from ns1.kfupm.edu.sa ([198.77.102.26]) by relay.kacst.edu.sa (8.7.5/8.7.3) with ESMTP id VAA08229 for ; Mon, 8 Dec 1997 21:45:47 -0300 (GMT) Received: from dpc107.dpc.kfupm.edu.sa ([196.15.32.8]) by ns1.kfupm.edu.sa (8.7.5/8.7.3) with ESMTP id VAA168786 for ; Mon, 8 Dec 1997 21:44:58 +0300 Received: (from onur@localhost) by dpc107.dpc.kfupm.edu.sa (8.7.5/8.7.3) id VAA81011 for freebsd-hackers@freebsd.org; Mon, 8 Dec 1997 21:48:21 +0300 Date: Mon, 8 Dec 1997 21:48:21 +0300 From: TOKER ONUR Message-Id: <199712081848.VAA81011@dpc107.dpc.kfupm.edu.sa> To: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe freebsd-hackers onur@ccse.kfupm.edu.sa From owner-freebsd-hackers Mon Dec 8 11:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03223 for hackers-outgoing; Mon, 8 Dec 1997 11:40:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03094 for ; Mon, 8 Dec 1997 11:40:00 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id UAA00889; Mon, 8 Dec 1997 20:39:56 +0100 (MET) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 8 Dec 1997 20:39:56 +0100 (MET) To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: isa.c References: <199712081829.LAA12105@mt.sri.com> Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 08 Dec 1997 20:39:55 +0100 In-Reply-To: Nate Williams's message of Mon, 8 Dec 1997 11:29:27 -0700 Message-ID: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c > > from -current? > Almost certainly not, Why would you want to do that? Because the patches distributed with Luigi's pnp audio drivers won't work on a 2.2.1R isa.c. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep From owner-freebsd-hackers Mon Dec 8 11:42:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03501 for hackers-outgoing; Mon, 8 Dec 1997 11:42:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03487 for ; Mon, 8 Dec 1997 11:42:38 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA23298; Mon, 8 Dec 1997 12:42:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA12478; Mon, 8 Dec 1997 12:42:34 -0700 Date: Mon, 8 Dec 1997 12:42:34 -0700 Message-Id: <199712081942.MAA12478@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: References: <199712081829.LAA12105@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c > > > from -current? > > Almost certainly not, Why would you want to do that? > > Because the patches distributed with Luigi's pnp audio drivers won't > work on a 2.2.1R isa.c. You'd be much better off upgrading to 2.2.5R, as I suspect his patches apply to that pretty cleanly. Nate From owner-freebsd-hackers Mon Dec 8 11:48:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04144 for hackers-outgoing; Mon, 8 Dec 1997 11:48:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04139 for ; Mon, 8 Dec 1997 11:48:40 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id UAA01637; Mon, 8 Dec 1997 20:48:38 +0100 (MET) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 8 Dec 1997 20:48:37 +0100 (MET) To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: isa.c References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 08 Dec 1997 20:48:36 +0100 In-Reply-To: Nate Williams's message of Mon, 8 Dec 1997 12:42:34 -0700 Message-ID: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > > Is it safe to replace i386/isa.c in a 2.2.1R kernel with i386/isa.c > > > > from -current? > > > Almost certainly not, Why would you want to do that? > > Because the patches distributed with Luigi's pnp audio drivers won't > > work on a 2.2.1R isa.c. > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > apply to that pretty cleanly. I have a list of good reasons for not upgrading to 2.2.2R, and a longer one for not upgrading to 2.2.5R. I also have a list of good reasons for upgrading, but it's shorter than the previous two lists. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep From owner-freebsd-hackers Mon Dec 8 11:51:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04390 for hackers-outgoing; Mon, 8 Dec 1997 11:51:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04381 for ; Mon, 8 Dec 1997 11:51:29 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA23383; Mon, 8 Dec 1997 12:51:25 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA12645; Mon, 8 Dec 1997 12:51:23 -0700 Date: Mon, 8 Dec 1997 12:51:23 -0700 Message-Id: <199712081951.MAA12645@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > apply to that pretty cleanly. > > I have a list of good reasons for not upgrading to 2.2.2R, and a > longer one for not upgrading to 2.2.5R. And those would be? > I also have a list of good > reasons for upgrading, but it's shorter than the previous two lists. It's not the size of the list, it's the seriousness of the items on the both lists. Nate From owner-freebsd-hackers Mon Dec 8 12:04:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05411 for hackers-outgoing; Mon, 8 Dec 1997 12:04:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05379; Mon, 8 Dec 1997 12:03:48 -0800 (PST) (envelope-from pallenby@zibbi.mikom.csir.co.za) Received: (from pallenby@localhost) by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id WAA14901; Mon, 8 Dec 1997 22:03:41 +0200 (SAT) From: Paul Allenby Message-Id: <199712082003.WAA14901@zibbi.mikom.csir.co.za> Subject: Make world broken on -stable To: freebsd-stable@freebsd.org Date: Mon, 8 Dec 1997 22:03:41 +0200 (SAT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all After cvsup'ing the latest RELENG_2_2 src about an hour ago, and a "make buildworld", I got: ===> libc install -c -o bin -g bin -m 444 libc.a /usr/obj/usr/src/tmp/usr/lib install -c -o bin -g bin -m 444 -fschg libc.so.3.0 /usr/obj/usr/src/tmp/usr/lib install -c -o bin -g bin -m 444 libc_pic.a /usr/obj/usr/src/tmp/usr/lib ld.so failed: Undefined symbol "___generic_syscall" in install:/usr/obj/usr/src/tmp/usr/lib/libc.so.3.0 *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Any ideas? Paul From owner-freebsd-hackers Mon Dec 8 12:24:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06993 for hackers-outgoing; Mon, 8 Dec 1997 12:24:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA06970 for ; Mon, 8 Dec 1997 12:24:46 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA26271; Mon, 8 Dec 1997 12:24:16 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma026269; Mon Dec 8 12:24:08 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id MAA11047; Mon, 8 Dec 1997 12:24:08 -0800 (PST) From: Archie Cobbs Message-Id: <199712082024.MAA11047@bubba.whistle.com> Subject: Re: help: divert sockets question In-Reply-To: <199712081612.SAA11172@relay.ucb.crimea.ua> from Ruslan Ermilov at "Dec 8, 97 06:12:49 pm" To: ru@ucb.crimea.ua (Ruslan Ermilov) Date: Mon, 8 Dec 1997 12:24:08 -0800 (PST) Cc: fwang2@unity.ncsu.edu, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ruslan Ermilov writes: > I did it the same way. It doesn't work for me ;-( > > In general, I have a packet received trhu udp from remote machine, > and I need to write it as incoming on a local machine. > > Usually, you read the packet from divert socket first using recvfrom(), > then optionally modify it, and then write it back using sendto(). > > My case is differ, because I just need to write a packet as incoming, > not reading it from divert socket first. Make sure you're recomputing the checksum properly, etc. You might also try to check the kernel statistics and the ipfw log (turn on ipfw logging on all rejected packets) to see why the packet is being dropped. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Dec 8 12:25:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA07061 for hackers-outgoing; Mon, 8 Dec 1997 12:25:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bcarsde4.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA07048 for ; Mon, 8 Dec 1997 12:25:31 -0800 (PST) (envelope-from atrens@nortel.ca) Message-Id: <199712082025.MAA07048@hub.freebsd.org> Received: from bcars520.ca.nortel.com by bcarsde4.localhost; Mon, 8 Dec 1997 13:38:52 -0500 Received: from bnr.ca by bcars520.bnr.ca id <29717-0@bcars520.bnr.ca>; Mon, 8 Dec 1997 13:37:28 -0500 Date: 08 Dec 1997 13:37 EST To: hackers@FreeBSD.ORG From: "Andrew Atrens" Subject: dealing with zombies Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi All, I'm eval'ing Wordperfect-7.0-for-Linux on `FreeBSD 3.0-971012-SNAP' and am seeing lots of zombies: 1446 ?? Z 0:00.00 (xwpthes) 1460 ?? Z 0:00.00 (xwpgmk5) 1461 ?? Z 0:00.00 (xwpspell) 1462 ?? Z 0:00.00 (xwpspell) 1467 ?? Z 0:00.00 (wpp7) 1471 ?? Z 0:00.00 (xwpspell) 1472 ?? Z 0:00.00 (xwpspell) 1473 ?? Z 0:00.00 (xwpspell) 1513 ?? Z 0:00.00 (xwpthes) 1514 ?? Z 0:00.00 (xwpthes) 1531 ?? Z 0:00.00 (xwpthes) 1532 ?? Z 0:00.00 (xwpthes) 1533 ?? Z 0:00.00 (xwpthes) 1543 ?? Z 0:00.00 (xwpthes) 1551 ?? Z 0:00.00 (xwpthes) As I understand, the root cause is that (xwp) is failing to reap dead children. However, the children *do* get reaped when I exit xwp... it seems that as long as xwp is running, no reaping is done, and the zombies accumulate...:( What I'm wondering is: i. Is this a fault/feature of the app (xwp), the linux emulation code, or the kernel (in a larger sense), and ii. are there any *good* workarounds. ( I seem to recall some discussion about a tunable kernel parm for auto-reap or some such thing? ) Cheers, Andrew. From owner-freebsd-hackers Mon Dec 8 12:37:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08280 for hackers-outgoing; Mon, 8 Dec 1997 12:37:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08264 for ; Mon, 8 Dec 1997 12:37:16 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id VAA05473; Mon, 8 Dec 1997 21:37:02 +0100 (MET) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 8 Dec 1997 21:37:01 +0100 (MET) To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: isa.c References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> <199712081951.MAA12645@mt.sri.com> Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 08 Dec 1997 21:37:01 +0100 In-Reply-To: Nate Williams's message of Mon, 8 Dec 1997 12:51:23 -0700 Message-ID: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > > apply to that pretty cleanly. > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > longer one for not upgrading to 2.2.5R. > And those would be? Amongst other items, lack of a suitable backup device, and reports of degraded performance in 2.2.5R. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep From owner-freebsd-hackers Mon Dec 8 12:37:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08302 for hackers-outgoing; Mon, 8 Dec 1997 12:37:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA08271; Mon, 8 Dec 1997 12:37:23 -0800 (PST) (envelope-from ip@albatross.mcc.ac.uk) Received: from albatross.mcc.ac.uk [130.88.202.16] by probity.mcc.ac.uk with esmtp (Exim 1.73 #3) id 0xf9va-0000ta-00; Mon, 8 Dec 1997 20:37:18 +0000 Received: (from ip@localhost) by albatross.mcc.ac.uk (8.8.8/8.8.4) id UAA01056; Mon, 8 Dec 1997 20:37:18 GMT From: Ian Pallfreeman Message-Id: <199712082037.UAA01056@albatross.mcc.ac.uk> Subject: Re: Make world broken on -stable In-Reply-To: <199712082003.WAA14901@zibbi.mikom.csir.co.za> from Paul Allenby at "Dec 8, 97 10:03:41 pm" To: pallenby@zibbi.mikom.csir.co.za (Paul Allenby) Date: Mon, 8 Dec 1997 20:37:17 +0000 (GMT) Cc: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Reply-To: ip@mcc.ac.uk X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > After cvsup'ing the latest RELENG_2_2 src about an hour ago, and > a "make buildworld", I got: Uh, "me too". So you know you're not the only one with the problem. I'll trash /usr/src and re-cvsup after the dump's finished, see if that cures it. It shouldn't, but it might. Ian. From owner-freebsd-hackers Mon Dec 8 12:42:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08861 for hackers-outgoing; Mon, 8 Dec 1997 12:42:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08845 for ; Mon, 8 Dec 1997 12:42:05 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA23714; Mon, 8 Dec 1997 13:42:03 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA12889; Mon, 8 Dec 1997 13:41:59 -0700 Date: Mon, 8 Dec 1997 13:41:59 -0700 Message-Id: <199712082041.NAA12889@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> <199712081951.MAA12645@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > > > apply to that pretty cleanly. > > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > > longer one for not upgrading to 2.2.5R. > > And those would be? > > Amongst other items, lack of a suitable backup device No need to backup. It's a piece of cake to upgrade w/out doing a backup/restore. Just download the sources, do a 'make world', re-config and install a new kernel, and reboot. A few hours work, but certainly not rocket science. > and reports of degraded performance in 2.2.5R. I haven't seen many of those reports, and I haven't experienced any personally. I'd be willing to bet that some of the 'degraded performance' reports may be due to bugfixes that cause the system to behave a little less 'agressively' that caused problems. You can always make things go faster, but not always safer. :) Nate From owner-freebsd-hackers Mon Dec 8 12:45:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09200 for hackers-outgoing; Mon, 8 Dec 1997 12:45:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09173 for ; Mon, 8 Dec 1997 12:44:50 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id MAA04993; Mon, 8 Dec 1997 12:44:26 -0800 (PST) (envelope-from jamil@acroal.com) Date: Mon, 8 Dec 1997 12:44:26 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Andrew Atrens cc: hackers@freebsd.org Subject: Re: dealing with zombies In-Reply-To: <199712082025.MAA07048@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As I recall under linux setting up a signal handler that excutes waitpid() is not necessary if you are set (by default) to ignore SIGCHLD. On 8 Dec 1997, Andrew Atrens wrote: > Hi All, > > I'm eval'ing Wordperfect-7.0-for-Linux on `FreeBSD 3.0-971012-SNAP' and am > seeing lots of zombies: > > 1446 ?? Z 0:00.00 (xwpthes) > 1460 ?? Z 0:00.00 (xwpgmk5) > 1461 ?? Z 0:00.00 (xwpspell) > 1462 ?? Z 0:00.00 (xwpspell) > 1467 ?? Z 0:00.00 (wpp7) > 1471 ?? Z 0:00.00 (xwpspell) > 1472 ?? Z 0:00.00 (xwpspell) > 1473 ?? Z 0:00.00 (xwpspell) > 1513 ?? Z 0:00.00 (xwpthes) > 1514 ?? Z 0:00.00 (xwpthes) > 1531 ?? Z 0:00.00 (xwpthes) > 1532 ?? Z 0:00.00 (xwpthes) > 1533 ?? Z 0:00.00 (xwpthes) > 1543 ?? Z 0:00.00 (xwpthes) > 1551 ?? Z 0:00.00 (xwpthes) > > As I understand, the root cause is that (xwp) is failing to reap dead children. > However, the children *do* get reaped when I exit xwp... it seems that > as long as xwp is running, no reaping is done, and the zombies accumulate...:( > > What I'm wondering is: > > i. Is this a fault/feature of the app (xwp), the linux emulation code, or > the kernel (in a larger sense), and > ii. are there any *good* workarounds. ( I seem to recall some discussion about > a tunable kernel parm for auto-reap or some such thing? ) > > > Cheers, > > Andrew. > > From owner-freebsd-hackers Mon Dec 8 12:46:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09298 for hackers-outgoing; Mon, 8 Dec 1997 12:46:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA09280 for ; Mon, 8 Dec 1997 12:46:18 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA29200; Mon, 8 Dec 1997 20:45:09 +0100 From: Luigi Rizzo Message-Id: <199712081945.UAA29200@labinfo.iet.unipi.it> Subject: Re: Why FIONREAD has no dual for write ? To: tlambert@primenet.com (Terry Lambert) Date: Mon, 8 Dec 1997 20:45:09 +0100 (MET) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199712081822.LAA23908@usr01.primenet.com> from "Terry Lambert" at Dec 8, 97 06:22:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > We have a 20 years old interface (FIONREAD..) and I can understand that > > at that time some needs (e.g. synchronizing streams) were simply not > > there. Now we have new requirements and apps, and it would be appropriate > > to work on a common interface which is as device independent as > > possible. > > IMO, the canonically "correct" thing to do would be to read and write > using a non-blocking descriptor. This eliminates the multiple reader/ > write buffer consumption races. so in practice FIONREAD should not be used either... that's a possibility. > It's short, it's elegant, and you can still use "select()" for the > readability/writeability to avoid turning the program into a polling > loop. I agree with the above, except that it does not work in all situations. E.g. I am not sure but does select() guarantee that you don't end up writing/reading one byte at a time ? I know in practice things are different, but there is no standard behaviour I think, so the risk is still there. In the audio driver I had to modify the behaviour of select() (block size) using a separate ioctl(). Plus there are apps which want only to check the status of the queue in a descriptor without actually doing the I/O, for whatever reason they like. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Dec 8 12:53:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA10035 for hackers-outgoing; Mon, 8 Dec 1997 12:53:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA10023 for ; Mon, 8 Dec 1997 12:53:24 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA29224; Mon, 8 Dec 1997 20:52:21 +0100 From: Luigi Rizzo Message-Id: <199712081952.UAA29224@labinfo.iet.unipi.it> Subject: Re: isa.c To: nate@mt.sri.com (Nate Williams) Date: Mon, 8 Dec 1997 20:52:20 +0100 (MET) Cc: dag-erli@ifi.uio.no, nate@mt.sri.com, hackers@FreeBSD.ORG In-Reply-To: <199712081951.MAA12645@mt.sri.com> from "Nate Williams" at Dec 8, 97 12:51:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > longer one for not upgrading to 2.2.5R. > > And those would be? I guess just one suffices: it works for me I am running 2.2.1 myself (and on one machine even 1.1.5... that machine is up and running since Jan 1994 -- only crashes when there is no power, which happens rarely enough not to bother: luigi# uptime 8:51pm up 59 days, 3:42, 2 users, load average: 0.00, 0.00, 0.00 Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Dec 8 13:18:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12062 for hackers-outgoing; Mon, 8 Dec 1997 13:18:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12056 for ; Mon, 8 Dec 1997 13:18:44 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id WAA08706; Mon, 8 Dec 1997 22:18:41 +0100 (MET) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 8 Dec 1997 22:18:41 +0100 (MET) To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: isa.c References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> <199712081951.MAA12645@mt.sri.com> <199712082041.NAA12889@mt.sri.com> Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 08 Dec 1997 22:18:40 +0100 In-Reply-To: Nate Williams's message of Mon, 8 Dec 1997 13:41:59 -0700 Message-ID: Lines: 49 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > > > > apply to that pretty cleanly. > > > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > > > longer one for not upgrading to 2.2.5R. > > > And those would be? > > Amongst other items, lack of a suitable backup device > No need to backup. It's a piece of cake to upgrade w/out doing a In my book, there is a difference between what is possible and what is actually advisable. For instance, it is quite possible to just switch your computer off when you're done, without thrashing your file systems; however, most people prefer to quit all applications, log out, and shut down properly, because they want to be *sure* not to thrash their file systems. Similarly, although it is possible to install 2.2.5 over 2.2.1 without any problems, most people will prefer to back up their data first. Some day, IMCFT, I'll try what you suggest, then 'accidentally' screw up, lose everything, and watch you trying very hard not to tell me I should have backed up. By the way, one of the other items on my list is that I need to repartition my hard drive. I'm sure you'll tell me I can do that without backing up, too. > backup/restore. Just download the sources, do a 'make world', re-config "Just download the sources" is easier said than done with a v34 modem. > and install a new kernel, and reboot. A few hours work, but certainly > not rocket science. What if my system is slightly "customized", and things stop working after the upgrade? Amongst other things, there is quite a bit of brain damage in 2.2.1 boot scripts, which I have tried to remedy by custom- izing said scripts. > > and reports of degraded performance in 2.2.5R. > I haven't seen many of those reports, and I haven't experienced any I know people (*not* FOAFs, but real people with names and faces) who have experienced quite serious problems, amongst other things with SCSI performance, after upgrading from 2.2.1R to 2.2.5R. -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep From owner-freebsd-hackers Mon Dec 8 13:21:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12303 for hackers-outgoing; Mon, 8 Dec 1997 13:21:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12280 for ; Mon, 8 Dec 1997 13:21:01 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA22860; Mon, 8 Dec 1997 13:14:47 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd022855; Mon Dec 8 13:14:37 1997 Message-ID: <348C62A9.64880EEB@whistle.com> Date: Mon, 08 Dec 1997 13:12:09 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Ruslan Ermilov CC: Feiyi Wang , hackers@freebsd.org Subject: Re: help: divert sockets question References: <199712081612.SAA11172@relay.ucb.crimea.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ruslan Ermilov wrote: > > Hi! > > I did it the same way. It doesn't work for me ;-( > > In general, I have a packet received trhu udp from remote machine, > and I need to write it as incoming on a local machine. > > Usually, you read the packet from divert socket first using recvfrom(), > then optionally modify it, and then write it back using sendto(). > > My case is differ, because I just need to write a packet as incoming, > not reading it from divert socket first. > > what versions are you using? From owner-freebsd-hackers Mon Dec 8 13:25:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12857 for hackers-outgoing; Mon, 8 Dec 1997 13:25:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12818 for ; Mon, 8 Dec 1997 13:24:55 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA23978; Mon, 8 Dec 1997 14:24:53 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA13032; Mon, 8 Dec 1997 14:24:50 -0700 Date: Mon, 8 Dec 1997 14:24:50 -0700 Message-Id: <199712082124.OAA13032@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: References: <199712081829.LAA12105@mt.sri.com> <199712081942.MAA12478@mt.sri.com> <199712081951.MAA12645@mt.sri.com> <199712082041.NAA12889@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > > > > > apply to that pretty cleanly. > > > > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > > > > longer one for not upgrading to 2.2.5R. > > > > And those would be? > > > Amongst other items, lack of a suitable backup device > > No need to backup. It's a piece of cake to upgrade w/out doing a > > In my book, there is a difference between what is possible and what is > actually advisable. For instance, it is quite possible to just switch > your computer off when you're done, without thrashing your file > systems; however, most people prefer to quit all applications, log out, > and shut down properly, because they want to be *sure* not to thrash > their file systems. Similarly, although it is possible to install > 2.2.5 over 2.2.1 without any problems, most people will prefer to back > up their data first. > > Some day, IMCFT, I'll try what you suggest, then 'accidentally' screw > up, lose everything, and watch you trying very hard not to tell me I > should have backed up. You can't screw up a make world, assuming the tree actually builds. (Which 2.2.5R is guaranteed to do.) > By the way, one of the other items on my list is that I need to > repartition my hard drive. I'm sure you'll tell me I can do that > without backing up, too. No, that one definitely needs a backup. But, if you need to repartition your hard-drive, then update at the same time. :) :) > > backup/restore. Just download the sources, do a 'make world', re-config > > "Just download the sources" is easier said than done with a v34 modem. Hey, that's what I'm using now. I'm not asking you to do anything I'm not willing to do myself. (My box is a 486/66 with 16MB of memory, how's that for speedy. :) > > and install a new kernel, and reboot. A few hours work, but certainly > > not rocket science. > > What if my system is slightly "customized", and things stop working > after the upgrade? Amongst other things, there is quite a bit of brain > damage in 2.2.1 boot scripts, which I have tried to remedy by custom- > izing said scripts. Assuming the programs are the same (which they should be), then the boot scripts should work fine, since the underlying programs didn't change in terms of their behavior. Nate From owner-freebsd-hackers Mon Dec 8 13:31:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA14464 for hackers-outgoing; Mon, 8 Dec 1997 13:31:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA14451 for ; Mon, 8 Dec 1997 13:30:57 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA23174; Mon, 8 Dec 1997 13:22:40 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023172; Mon Dec 8 13:22:37 1997 Message-ID: <348C6489.773C2448@whistle.com> Date: Mon, 08 Dec 1997 13:20:09 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Charles Mott CC: Valter Mazzaro , hackers@FreeBSD.ORG Subject: Re: natd settings problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott wrote: > > On Mon, 8 Dec 1997, Valter Mazzaro wrote: > > My purpose is to run a video conference application (vic) between HOST1/2 and > > ISP. > > In AS a natd daemon is running. The problem is that, with the present settings, > > I've succeeded in running vic just between ISP and ONE host AT THE TIME!! > [snip] you need to run mrouted on the gateway machine, so that it takes in a unicast IPstream from the supplier, and runs multicast out through the LAN. From owner-freebsd-hackers Mon Dec 8 14:02:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA18075 for hackers-outgoing; Mon, 8 Dec 1997 14:02:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA18067 for ; Mon, 8 Dec 1997 14:01:55 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id OAA23754; Mon, 8 Dec 1997 14:04:20 -0800 (PST) Message-Id: <199712082204.OAA23754@implode.root.com> To: Nate Williams cc: hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-reply-to: Your message of "Mon, 08 Dec 1997 08:23:04 MST." <199712081523.IAA11391@mt.sri.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 08 Dec 1997 14:04:20 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Actually, that list hasn't been used for over a year and should >> probably be retired. I don't think it ever fulfilled its purpose. > >That's because no-one ever talks about architecture stuff anymore, and >just 'implements' nowadays. I think it *could* fulfill its purpose if >it was actually promoted/used. I would have used it in the past if I >thought it would be monitored, although it wasn't. Could we consider it >'back in use' for questions such as Julians? That's silly. Of course we talk about architectural issues. It's just that these days it's easier for me and others to pick up the phone and call the interested parties or send directed email than it is to send to lists full of indifferent people. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Dec 8 14:02:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA18128 for hackers-outgoing; Mon, 8 Dec 1997 14:02:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA18121 for ; Mon, 8 Dec 1997 14:02:50 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712082202.OAA18121@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA066698516; Tue, 9 Dec 1997 09:01:57 +1100 From: Darren Reed Subject: Re: Why FIONREAD has no dual for write ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 9 Dec 1997 09:01:56 +1100 (EDT) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199712081945.UAA29200@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 8, 97 08:45:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Luigi Rizzo, sie said: [...] > > It's short, it's elegant, and you can still use "select()" for the > > readability/writeability to avoid turning the program into a polling > > loop. > > I agree with the above, except that it does not work in all situations. > E.g. I am not sure but does select() guarantee that you don't > end up writing/reading one byte at a time ? I know in practice things > are different, but there is no standard behaviour I think, so the risk > is still there. In the audio driver I had to modify the behaviour of > select() (block size) using a separate ioctl(). I don't know how select() works with drivers such as the audio drivers, but I've only encountered one OS which returned an fd as witeable when it wasn't and it hasn't been possible to buy that particular Unix for some years now. > Plus there are apps which want only to check the status of the queue in > a descriptor without actually doing the I/O, for whatever reason they > like. You can still use select for this. Darren From owner-freebsd-hackers Mon Dec 8 14:15:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19334 for hackers-outgoing; Mon, 8 Dec 1997 14:15:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tailspin.nas.nasa.gov (tailspin.nas.nasa.gov [129.99.33.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19304 for ; Mon, 8 Dec 1997 14:14:43 -0800 (PST) (envelope-from proett@nas.nasa.gov) Received: from tailspin.nas.nasa.gov (proett@localhost) by tailspin.nas.nasa.gov (8.8.7/NAS.6.1) with ESMTP id OAA01447 for ; Mon, 8 Dec 1997 14:14:42 -0800 (PST) Message-Id: <199712082214.OAA01447@tailspin.nas.nasa.gov> X-face: @FawM/C#2aqY7IL!YtmSlwIO/RwN)vvcz2j=jD5p$:uRj#b08|nyZ?t5F]Evz*2/AqIoI\X7@O0Tqyu|+,Zh(1p/W4LR)M{{h^j?Avy/Ssw)XqkQ[T-!Q.\SYY3'idKQYlE>W'UG< Reply-To: proett@nas.nasa.gov To: freebsd-hackers@freebsd.org Subject: ps Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 14:14:42 -0800 From: Tom Proett Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I noticed that the -j option for ps gives a column for SESS which contains the address of the session structure for each process. Is there some reason for this? A more common thing to find is the pid of the session leader. Tom Proett -- proett@nas.nasa.gov NASA Ames Research Center From owner-freebsd-hackers Mon Dec 8 14:16:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19539 for hackers-outgoing; Mon, 8 Dec 1997 14:16:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA19488 for ; Mon, 8 Dec 1997 14:16:07 -0800 (PST) (envelope-from k0zm0z@yahoo.com) Message-ID: <19971208221551.10168.rocketmail@send1b.yahoomail.com> Received: from [207.155.93.60] by send1b; Mon, 08 Dec 1997 14:15:51 PST Date: Mon, 8 Dec 1997 14:15:51 -0800 (PST) From: kozmo killah Subject: Freebsd works on laptops? To: mobile@freebsd.org Cc: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk h3ll0, does the freebsd works on laptop pc? i try the linux on thinkpad 701 and it blew up into much fire and smoke which maked big fire in room. i have now the thinkpad 560 and will the freebsd works much better and no break laptop? is the freebsd very much guarantee to not blow up? _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-freebsd-hackers Mon Dec 8 14:19:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20047 for hackers-outgoing; Mon, 8 Dec 1997 14:19:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20009 for ; Mon, 8 Dec 1997 14:19:37 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id UAA13229; Mon, 8 Dec 1997 20:19:32 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199712082219.UAA13229@gaia.coppe.ufrj.br> Subject: Process scheduling: nice does not work ??? To: freebsd-hackers@freebsd.org Date: Mon, 8 Dec 1997 20:19:31 -0200 (EDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I've been doing some test with cpu-intensive scheduling in FreeBSD 2.2-stable, when I found what seems to be an error in the scheduler. If I run two cpu intensive processes, one with niceness 0, and the other with niceness 20, the CPU is divided this way (using rc564 key crunsher just to give an example of cpu-intensive task): last pid: 17789; load averages: 2.02, 2.11, 2.08 20:06:38 63 processes: 3 running, 58 sleeping, 1 stopped, 1 zombie CPU states: 67.8% user, 31.8% nice, 0.0% system, 0.4% interrupt, 0.0% idle Mem: 72M Active, 14M Inact, 15M Wired, 8344K Buf, 23M Free Swap: 128M Total, 64K Used, 128M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 17676 jonny 105 0 872K 420K RUN 2:06 65.81% 65.80% rc564 303 jonny 105 20 824K 404K RUN 488:14 33.04% 33.04% rc564 17714 root 28 0 720K 940K RUN 0:00 0.00% 0.00% top But, if instead I give nicenesses 10 and 20, it's divided like this: last pid: 17796; load averages: 2.06, 2.05, 2.06 20:11:07 63 processes: 3 running, 58 sleeping, 1 stopped, 1 zombie CPU states: 0.0% user, 99.2% nice, 0.4% system, 0.4% interrupt, 0.0% idle Mem: 72M Active, 14M Inact, 15M Wired, 8344K Buf, 23M Free Swap: 128M Total, 64K Used, 128M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 303 jonny 105 20 824K 404K RUN 490:27 50.66% 50.66% rc564 17676 jonny 105 10 872K 420K RUN 4:21 48.07% 48.07% rc564 263 root 18 0 500K 860K pause 0:03 0.04% 0.04% httpd 17714 root 28 0 720K 940K RUN 0:00 0.00% 0.00% top So, why there's no difference between niceness 10 and 20 ? idprio is not a solution, because the idprio'd process will never run. I want it to run, but with a smaller priority than another one. I've also tested this behaviour for Linux 2.0.32 and Solaris 2.5, just for comparison purposes. In linux: 7:43pm up 9:25, 2 users, load average: 1.81, 1.19, 0.64 59 processes: 55 sleeping, 4 running, 0 zombie, 0 stopped CPU states: 96.8% user, 2.9% system, 97.3% nice, 0.7% idle Mem: 63232K av, 61864K used, 1368K free, 21504K shrd, 23612K buff Swap: 130748K av, 0K used, 130748K free 14168K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 5497 jonny 16 10 268 268 204 R N 0 80.4 0.4 1:12 rc564 5358 jonny 20 19 284 284 220 R N 0 16.2 0.4 11:26 rc564 5511 root 1 0 540 540 404 R 0 0.7 0.8 0:00 top And in Solaris: last pid: 2623; load averages: 2.00, 1.63, 1.32 19:59:15 64 processes: 58 sleeping, 4 running, 1 stopped, 1 on cpu Cpu states: 0.0% idle, 99.0% user, 1.0% kernel, 0.0% iowait, 0.0% swap Memory: 113M real, 22M free, 34M swap, 316M free swap PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 2617 jonny -25 10 1600K 1056K run 2:41 60.74% 61.62% rc564-sparc-no 261 jonny -25 19 1744K 1316K run 494:52 41.44% 41.01% rc564-sparc-no 3 root 35 -20 0K 0K sleep 2:07 0.43% 0.38% fsflush 2616 root 33 0 2160K 1604K cpu 0:01 0.36% 0.35% top 2567 root 33 0 1544K 1152K sleep 0:00 0.04% 0.08% sshd Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Mon Dec 8 14:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20182 for hackers-outgoing; Mon, 8 Dec 1997 14:20:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA20051 for ; Mon, 8 Dec 1997 14:19:56 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id XAA00434; Mon, 8 Dec 1997 23:28:38 +0100 (CET) From: Mikael Karpberg Message-Id: <199712082228.XAA00434@ocean.campus.luth.se> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712081523.IAA11391@mt.sri.com> from Nate Williams at "Dec 8, 97 08:23:04 am" To: nate@mt.sri.com (Nate Williams) Date: Mon, 8 Dec 1997 23:28:38 +0100 (CET) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Nate Williams: > > > Ah this would be the CLOSED LIST to which I have not been admitted though > > > I have asked to join several times, yes? > > > > Actually, that list hasn't been used for over a year and should > > probably be retired. I don't think it ever fulfilled its purpose. > > That's because no-one ever talks about architecture stuff anymore, and > just 'implements' nowadays. I think it *could* fulfill its purpose if > it was actually promoted/used. I would have used it in the past if I > thought it would be monitored, although it wasn't. Could we consider it > 'back in use' for questions such as Julians? It's still closed, though, no? And that's a lot less fun for people that are interested in, if not joining the debate, at least read it. If it's going to go back in use, could it at least be possible to join it "read only", if you are the "mere mortal" that most of us are? /Mikael From owner-freebsd-hackers Mon Dec 8 14:34:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22226 for hackers-outgoing; Mon, 8 Dec 1997 14:34:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22218 for ; Mon, 8 Dec 1997 14:34:45 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA24273; Mon, 8 Dec 1997 15:10:07 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA13213; Mon, 8 Dec 1997 15:10:05 -0700 Date: Mon, 8 Dec 1997 15:10:05 -0700 Message-Id: <199712082210.PAA13213@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dg@root.com Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712082204.OAA23754@implode.root.com> References: <199712081523.IAA11391@mt.sri.com> <199712082204.OAA23754@implode.root.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> Actually, that list hasn't been used for over a year and should > >> probably be retired. I don't think it ever fulfilled its purpose. > > > >That's because no-one ever talks about architecture stuff anymore, and > >just 'implements' nowadays. I think it *could* fulfill its purpose if > >it was actually promoted/used. I would have used it in the past if I > >thought it would be monitored, although it wasn't. Could we consider it > >'back in use' for questions such as Julians? > > That's silly. Of course we talk about architectural issues. It's just that > these days it's easier for me and others to pick up the phone and call the > interested parties or send directed email than it is to send to lists full > of indifferent people. I'm not indifferent to these things, but I've never been involved in any sort of discussions. Getting more than two or three people interested in a discussion is difficult at best, and it mainly involves certain parties who talk on the phone, and leaves others out of the loop. Also, some interested parties aren't able to talk on the phone for one reason or the other.... Nate From owner-freebsd-hackers Mon Dec 8 14:40:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22690 for hackers-outgoing; Mon, 8 Dec 1997 14:40:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22647 for ; Mon, 8 Dec 1997 14:39:51 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id WAA24197; Mon, 8 Dec 1997 22:39:03 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199712082239.WAA24197@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Andreas Engel" cc: hackers@freebsd.org Subject: Re: unnumbered interfaces In-reply-to: Your message of "Mon, 08 Dec 1997 14:00:21 +0200." <01b801bd03d0$dc76dc60$43862ac2@andrease.cylink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 22:39:03 +0000 From: Brian Somers Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > hi there, > > is it possible to configure an interface unnumbered with FreeBSD ?-) > this would solve some probs for me Check out the 'Route behaviour' thread - this is what it's about. > Thanx Andreas :)) > -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Mon Dec 8 14:44:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23033 for hackers-outgoing; Mon, 8 Dec 1997 14:44:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23016 for ; Mon, 8 Dec 1997 14:44:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id WAA22306; Mon, 8 Dec 1997 22:44:14 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id XAA15686; Mon, 8 Dec 1997 23:43:41 +0100 (MET) To: Nate Williams Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed References: <18693.881576199@time.cdrom.com> <199712081523.IAA11391@mt.sri.com> From: Eivind Eklund Date: 08 Dec 1997 23:43:39 +0100 In-Reply-To: Nate Williams's message of Mon, 8 Dec 1997 08:23:04 -0700 Message-ID: <86hg8jo3qc.fsf@bitbox.follo.net> Lines: 29 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > [ > Removed Kirk from the list, he doesn't need to here about FreeBSD > politics. > ] > > > > Ah this would be the CLOSED LIST to which I have not been admitted though > > > I have asked to join several times, yes? > > > > Actually, that list hasn't been used for over a year and should > > probably be retired. I don't think it ever fulfilled its purpose. > > That's because no-one ever talks about architecture stuff anymore, and > just 'implements' nowadays. I think it *could* fulfill its purpose if > it was actually promoted/used. I would have used it in the past if I > thought it would be monitored, although it wasn't. Could we consider it > 'back in use' for questions such as Julians? I'd guess that was a good idea - both -hackers and -current seems overloaded, and a not-so-public list might mean that key developers could both follow the 'high-level' discussions and have time to actually do development. OTOH: I didn't see how the list died, so I can't say that 'the time is ripe'. If the list goes active, I'd like to join if possible, though :-) Eivind. From owner-freebsd-hackers Mon Dec 8 14:50:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23485 for hackers-outgoing; Mon, 8 Dec 1997 14:50:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23474; Mon, 8 Dec 1997 14:50:25 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA27593; Mon, 8 Dec 1997 14:49:51 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma027579; Mon Dec 8 14:49:43 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA13317; Mon, 8 Dec 1997 14:49:42 -0800 (PST) From: Archie Cobbs Message-Id: <199712082249.OAA13317@bubba.whistle.com> Subject: FreeBSD port for SKIP 1.0 available To: skip-info@skip.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Date: Mon, 8 Dec 1997 14:49:41 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The first stab at a FreeBSD port for SKIP-1.0 is available at: ftp://ftp.whistle.com/pub/archie/skip-port.tgz As described in the DESCR... SKIP - Simple Key management for Internet Protocols IP-Level Cryptography Secure every application with one protocol SKIP secures the network at the IP packet level. Any networked application gains the benefits of encryption, without requiring modification. SKIP is unique in that an Internet host can send an encrypted packet to another host without requiring a prior message exchange to set up a secure channel. SKIP is particularly well-suited to IP networks, as both are stateless protocols. Some of the advantages of SKIP include: - No connection setup overhead - High availability - encryption gateways that fail can reboot and resume decrypting packets instantly, without having to renegotiate (potentially thousands) of existing connections - Allows uni-directional IP (e.g., IP broadcast via satellite or cable) - Scalable multicast key distribution - SKIP gateways can be configured in parallel to perform instant-failover I'd appreciate any feedback. This is my first port so be gentle :-) Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Dec 8 14:51:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23554 for hackers-outgoing; Mon, 8 Dec 1997 14:51:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23528 for ; Mon, 8 Dec 1997 14:51:15 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA26240; Mon, 8 Dec 1997 14:49:00 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd026238; Mon Dec 8 14:48:57 1997 Message-ID: <348C78C4.6F5992E1@whistle.com> Date: Mon, 08 Dec 1997 14:46:28 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: dg@root.com CC: Nate Williams , hackers@freebsd.org Subject: Re: [hackers:] Architectural advice needed References: <199712082204.OAA23754@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > > >> Actually, that list hasn't been used for over a year and should > >> probably be retired. I don't think it ever fulfilled its purpose. > > > >That's because no-one ever talks about architecture stuff anymore, and > >just 'implements' nowadays. I think it *could* fulfill its purpose if > >it was actually promoted/used. I would have used it in the past if I > >thought it would be monitored, although it wasn't. Could we consider it > >'back in use' for questions such as Julians? > > That's silly. Of course we talk about architectural issues. It's just that > these days it's easier for me and others to pick up the phone and call the > interested parties or send directed email than it is to send to lists full > of indifferent people. > which leaves those of us that ARE interested, but not being called, kinda 'out of the loop'. That was one of my questions.. "How can we get a critical mass together on architectural issues?" > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Dec 8 15:04:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24690 for hackers-outgoing; Mon, 8 Dec 1997 15:04:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24675; Mon, 8 Dec 1997 15:04:14 -0800 (PST) (envelope-from pallenby@zibbi.mikom.csir.co.za) Received: (from pallenby@localhost) by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id BAA19148; Tue, 9 Dec 1997 01:04:04 +0200 (SAT) From: Paul Allenby Message-Id: <199712082304.BAA19148@zibbi.mikom.csir.co.za> Subject: Re: Make world broken on -stable In-Reply-To: <199712082003.WAA14901@zibbi.mikom.csir.co.za> from Paul Allenby at "Dec 8, 97 10:03:41 pm" To: pallenby@zibbi.mikom.csir.co.za (Paul Allenby) Date: Tue, 9 Dec 1997 01:04:04 +0200 (SAT) Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi all > > After cvsup'ing the latest RELENG_2_2 src about an hour ago, and > a "make buildworld", I got: > > ===> libc > install -c -o bin -g bin -m 444 libc.a /usr/obj/usr/src/tmp/usr/lib > install -c -o bin -g bin -m 444 -fschg libc.so.3.0 /usr/obj/usr/src/tmp/usr/lib > install -c -o bin -g bin -m 444 libc_pic.a /usr/obj/usr/src/tmp/usr/lib > ld.so failed: Undefined symbol "___generic_syscall" in install:/usr/obj/usr/src/tmp/usr/lib/libc.so.3.0 > *** Error code 1 > > Stop. > *** Error code 1 > Replying to my own mail: replacing src/lib/libc/DEFS.h version 1.3.2.2 with 1.3.2.1 seems to fix this. The buildworld has not yet completed, however :-) Paul From owner-freebsd-hackers Mon Dec 8 15:06:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24905 for hackers-outgoing; Mon, 8 Dec 1997 15:06:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA24873 for ; Mon, 8 Dec 1997 15:06:33 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA29524; Mon, 8 Dec 1997 23:05:25 +0100 From: Luigi Rizzo Message-Id: <199712082205.XAA29524@labinfo.iet.unipi.it> Subject: Re: Why FIONREAD has no dual for write ? To: avalon@coombs.anu.edu.au (Darren Reed) Date: Mon, 8 Dec 1997 23:05:24 +0100 (MET) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199712082202.OAA18121@hub.freebsd.org> from "Darren Reed" at Dec 9, 97 09:01:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't know how select() works with drivers such as the audio drivers, > but I've only encountered one OS which returned an fd as witeable when > it wasn't and it hasn't been possible to buy that particular Unix for > some years now. i was not referring to broken select(). But i think a working select returns you an fd as soon as you can exchange one byte on it. What happens underneath is probably device-dependent, e.g. a tty with some special line discipline might make select return when full slip/ppp packets are ready, or when whole mouse frames (3/5 bytes) are ready... I have no idea if select on a tty really works like this. I hope so, but then... is there a PPP or MOUSE line discipline ? Audio drivers typically use DMA to transfer one block at a time, you can set the blocksize but in general you cannot tell 'wake me up when a whole block is ready'. This can be a problem when the allowed block sizes are not the same as your desired block size. E.g. in Voxware, you can have DMA blocksizes which are powers of two, but the audio frame is 160 samples... In my audio driver I explicitly modify the select() behaviour so that, when the user explicitly requests a blocksize (e.g. 160 bytes) then select() nonly returns when that many bytes can be read/written to the device. > > Plus there are apps which want only to check the status of the queue in > > a descriptor without actually doing the I/O, for whatever reason they > > like. > > You can still use select for this. again you cannot tell the difference between different levels of queue occupation, only empty/non-empty and full/non-full 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 Mon Dec 8 15:22:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27155 for hackers-outgoing; Mon, 8 Dec 1997 15:22:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA27110 for ; Mon, 8 Dec 1997 15:22:21 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.5/8.8.5) with ESMTP id XAA04617 for ; Mon, 8 Dec 1997 23:01:56 GMT Message-ID: <348C8223.4FF22185@tdx.co.uk> Date: Mon, 08 Dec 1997 23:26:27 +0000 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Writing Device drivers for 2.2.X etc' Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm trying to write a device driver for an ISA signal processor card - I've made sure there isn't one around at the moment (why re-invent the wheel? ) - and I could do with some help... I downloaded some shell scripts, which at the time looked like a good idea - they create a driver framework to work from (with all the code stubs written for probing, creating, attaching, doing IOCTL's etc.) - but the code refers to manually editing 'conf.c'... My 2.2.2-Release system doesn't have a conf.c ;-) The templates also don't seem to mention major / minor device numbers either - unless they 'were' taken care of in conf.c at some point in the past? Can anyone point the way to some up to date (i.e. 2.2.2+ etc.) info on the net about writing device drivers for BSD - i.e. up to date templates etc.? for nice simple ISA cards, or just code stubs? - Or are there any drivers in BSD which are nice and simple for using as templates allready? Thanks in advance, Karl Pielorz (mailto:kpielorz@tdx.co.uk) From owner-freebsd-hackers Mon Dec 8 15:29:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28178 for hackers-outgoing; Mon, 8 Dec 1997 15:29:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA28166 for ; Mon, 8 Dec 1997 15:28:58 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id PAA24811; Mon, 8 Dec 1997 15:31:18 -0800 (PST) Message-Id: <199712082331.PAA24811@implode.root.com> To: Mikael Karpberg cc: nate@mt.sri.com (Nate Williams), hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-reply-to: Your message of "Mon, 08 Dec 1997 23:28:38 +0100." <199712082228.XAA00434@ocean.campus.luth.se> From: David Greenman Reply-To: dg@root.com Date: Mon, 08 Dec 1997 15:31:18 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >According to Nate Williams: >> > > Ah this would be the CLOSED LIST to which I have not been admitted though >> > > I have asked to join several times, yes? >> > >> > Actually, that list hasn't been used for over a year and should >> > probably be retired. I don't think it ever fulfilled its purpose. >> >> That's because no-one ever talks about architecture stuff anymore, and >> just 'implements' nowadays. I think it *could* fulfill its purpose if >> it was actually promoted/used. I would have used it in the past if I >> thought it would be monitored, although it wasn't. Could we consider it >> 'back in use' for questions such as Julians? > >It's still closed, though, no? And that's a lot less fun for people that are >interested in, if not joining the debate, at least read it. If it's going >to go back in use, could it at least be possible to join it "read only", >if you are the "mere mortal" that most of us are? Thr original purpose of the list was for coordinating architectural direction between the BSD old guard and FreeBSD. This simply didn't work as intended so it should be deleted. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Dec 8 16:03:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01479 for hackers-outgoing; Mon, 8 Dec 1997 16:03:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01464; Mon, 8 Dec 1997 16:03:40 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by seidata.com (8.8.8/8.8.5) with SMTP id TAA09970; Mon, 8 Dec 1997 19:03:16 -0500 (EST) Date: Mon, 8 Dec 1997 19:03:15 -0500 (EST) From: Mike To: kozmo killah cc: mobile@freebsd.org, hackers@freebsd.org Subject: Re: Freebsd works on laptops? In-Reply-To: <19971208221551.10168.rocketmail@send1b.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, kozmo killah wrote: > does the freebsd works on laptop pc? Guess that'd depend on the laptop... ;) > i try the linux on thinkpad 701 and it blew up into > much fire and smoke which maked big fire in room. Ouch... sounds like bad luck. I have both the latest Slakware and Red Hat distributions running on an IBM Thinkpad 755 here with no problems... they even recognized all my PCMCIA devices on startup. > i have now the thinkpad 560 and will the freebsd > works much better and no break laptop? Some would argue that FreeBSD always works better than Linux. ;) > is the freebsd very much guarantee to not blow up? Surely you know by now that there's no guarantees in life. --- Mike Hoskins mike@seidata.com SEI Data Network Services, Inc. http://www.adept.org/apropos From owner-freebsd-hackers Mon Dec 8 16:04:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01630 for hackers-outgoing; Mon, 8 Dec 1997 16:04:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01607 for ; Mon, 8 Dec 1997 16:04:45 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA24982; Mon, 8 Dec 1997 16:45:10 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA13824; Mon, 8 Dec 1997 16:45:08 -0700 Date: Mon, 8 Dec 1997 16:45:08 -0700 Message-Id: <199712082345.QAA13824@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dg@root.com Cc: Mikael Karpberg , nate@mt.sri.com (Nate Williams), hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <199712082331.PAA24811@implode.root.com> References: <199712082228.XAA00434@ocean.campus.luth.se> <199712082331.PAA24811@implode.root.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> just 'implements' nowadays. I think it *could* fulfill its purpose if > >> it was actually promoted/used. I would have used it in the past if I > >> thought it would be monitored, although it wasn't. Could we consider it > >> 'back in use' for questions such as Julians? > > > >It's still closed, though, no? And that's a lot less fun for people that are > >interested in, if not joining the debate, at least read it. If it's going > >to go back in use, could it at least be possible to join it "read only", > >if you are the "mere mortal" that most of us are? > > Thr original purpose of the list was for coordinating architectural > direction between the BSD old guard and FreeBSD. This simply didn't work > as intended so it should be deleted. Just because it didn't work *then* for co-ordinating stuff with CSRG doesn't mean it couldn't work *now* for co-ordinating FreeBSD stuff that happens currently between just a couple folks. Nate From owner-freebsd-hackers Mon Dec 8 16:25:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03561 for hackers-outgoing; Mon, 8 Dec 1997 16:25:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA03543 for ; Mon, 8 Dec 1997 16:25:22 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin3.anlw.anl.gov [141.221.254.103]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id RAA12299; Mon, 8 Dec 1997 17:25:13 -0700 Date: Mon, 8 Dec 1997 17:24:40 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: natd settings problem In-Reply-To: <348C6489.773C2448@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, Julian Elischer wrote: > Charles Mott wrote: > > > > On Mon, 8 Dec 1997, Valter Mazzaro wrote: > > > My purpose is to run a video conference application (vic) between HOST1/2 and > > > ISP. > > > In AS a natd daemon is running. The problem is that, with the present settings, > > > I've succeeded in running vic just between ISP and ONE host AT THE TIME!! > > [snip] > > you need to run mrouted on the gateway machine, so that it takes in a > unicast IPstream from the supplier, > and runs multicast out through the LAN. > Would you care to post an example mrouted.conf file that does this? I can't actually test this, but I am interested to understand it better, especially if there are any interactions with natd. One user has told me he has had problems with multicast through ppp -alias and natd, but I am not sure whether this was MBONE traffic or UDP. Charles Mott From owner-freebsd-hackers Mon Dec 8 16:35:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04400 for hackers-outgoing; Mon, 8 Dec 1997 16:35:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04386 for ; Mon, 8 Dec 1997 16:35:21 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (ppp4.portal.net.au [202.12.71.104]) by freefall.freebsd.org (8.8.6/8.8.5) with ESMTP id QAA23848 for ; Mon, 8 Dec 1997 16:16:32 -0800 (PST) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id KAA04243; Tue, 9 Dec 1997 10:42:44 +1030 (CST) Message-Id: <199712090012.KAA04243@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: mark thompson cc: freebsd-hackers@freebsd.com Subject: Re: linux emu. In-reply-to: Your message of "08 Dec 1997 14:34:23 -0000." <19971208143423.2747.qmail@squirrel.tgsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 1997 10:42:42 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Trying to run executor, on FreeBSD 2.2.1-RELEASE (MARX) #1: . > Tantalyzingly close to being useful. > > When i use the 'Check for floppy' function i get... > LINUX: 'ioctl' fd=5, typ=0x53(S), num=0xb not implemented > > I am willing to bet that fd=5 is the floppy. Any idea what ioctl > 0x53/0xb is supposed to do? /* * CD-ROM IOCTL commands * For IOCTL calls, we will commandeer byte 0x53, or 'S'. */ ... #define CDROMSUBCHNL 0x530b /* (struct cdrom_subchnl) */ I can't see it preventing Executor from running usefully. mike From owner-freebsd-hackers Mon Dec 8 16:45:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05397 for hackers-outgoing; Mon, 8 Dec 1997 16:45:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from chai.torrentnet.com (chai.torrentnet.com [207.87.46.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05369 for ; Mon, 8 Dec 1997 16:45:12 -0800 (PST) (envelope-from bakul@chai.torrentnet.com) Received: from chai.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by chai.torrentnet.com (8.8.6/8.8.5) with ESMTP id TAA06826; Mon, 8 Dec 1997 19:45:05 -0500 (EST) Message-Id: <199712090045.TAA06826@chai.torrentnet.com> To: Luigi Rizzo Cc: hackers@freebsd.org Subject: Re: Why FIONREAD has no dual for write ? In-reply-to: Your message of "Mon, 08 Dec 1997 20:45:09 +0100." <199712081945.UAA29200@labinfo.iet.unipi.it> Date: Mon, 08 Dec 1997 19:45:05 -0500 From: Bakul Shah Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I agree with the above, except that it does not work in all situations. > E.g. I am not sure but does select() guarantee that you don't > end up writing/reading one byte at a time ? I know in practice things > are different, but there is no standard behaviour I think, so the risk > is still there. In the audio driver I had to modify the behaviour of > select() (block size) using a separate ioctl(). Perhaps one solution is to add an ioctl to set high/low watermarks on a device and add new event bits POLLIN_WM and POLLLOUT_WM for the poll() syscall. In pollfd->events you set these bits instead of (or in addition to) POLLIN/POLLOUT. On return the corresponding bit in pollfd->revents is set only if there are _greater than low watermark_ bytes on input and _less than high watermark_ bytes on output. This guarantees that you can transfer some minimum number of bytes on read/write (provided you use the O_EXCL mode). This is a more general solution that allows finer control over when to schedule IO and is useful in all sorts of situations. > Plus there are apps which want only to check the status of the queue in > a descriptor without actually doing the I/O, for whatever reason they > like. This can be handled by POLL{IN,OUT}_WM. Comments? -- bakul From owner-freebsd-hackers Mon Dec 8 16:49:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05616 for hackers-outgoing; Mon, 8 Dec 1997 16:49:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05597 for ; Mon, 8 Dec 1997 16:49:00 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA25170; Mon, 8 Dec 1997 11:22:08 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd025116; Mon Dec 8 11:21:57 1997 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA23471; Mon, 8 Dec 1997 17:48:16 -0700 (MST) From: Terry Lambert Message-Id: <199712090048.RAA23471@usr01.primenet.com> Subject: Re: dealing with zombies To: atrens@nortel.ca (Andrew Atrens) Date: Tue, 9 Dec 1997 00:48:16 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: <199712082025.MAA07048@hub.freebsd.org> from "Andrew Atrens" at Dec 8, 97 01:37:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi All, > > I'm eval'ing Wordperfect-7.0-for-Linux on `FreeBSD 3.0-971012-SNAP' and am > seeing lots of zombies: [ ... ] > What I'm wondering is: > > i. Is this a fault/feature of the app (xwp), the linux emulation code, or > the kernel (in a larger sense), and > ii. are there any *good* workarounds. ( I seem to recall some discussion > about a tunable kernel parm for auto-reap or some such thing? ) You should find out if this happens in Linux, too. If it does, then you need to live with it. If it doesn't, then the problem is in the default for SIGCHLD. If the parent ignores SIGCHLD (maybe the default on Linux?), then children should be automatically reaped instead of needing to have their status reaped by a parent. This would be a bug in the Linux emulation code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Dec 8 16:58:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06581 for hackers-outgoing; Mon, 8 Dec 1997 16:58:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06504 for ; Mon, 8 Dec 1997 16:57:22 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA27934; Mon, 8 Dec 1997 11:30:30 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd027863; Mon Dec 8 11:30:20 1997 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA24076; Mon, 8 Dec 1997 17:56:36 -0700 (MST) From: Terry Lambert Message-Id: <199712090056.RAA24076@usr01.primenet.com> Subject: Re: Why FIONREAD has no dual for write ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 9 Dec 1997 00:56:36 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199712081945.UAA29200@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 8, 97 08:45:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's short, it's elegant, and you can still use "select()" for the > > readability/writeability to avoid turning the program into a polling > > loop. > > I agree with the above, except that it does not work in all situations. > E.g. I am not sure but does select() guarantee that you don't > end up writing/reading one byte at a time ? I know in practice things > are different, but there is no standard behaviour I think, so the risk > is still there. In the audio driver I had to modify the behaviour of > select() (block size) using a separate ioctl(). Select just returns true when *any* buffer space is available. If the driver needs to be fed at a certain block size, then it should free up that much space at a time. In practice, this frequently means that you double-buffer in the driver using buffers owned by the driver, and rely on driver access policy to ensure against multiple writer problems (these should not be an issue in any case, if you maintain ordering guarantees between the writers -- something you have to do anyway with any order dependent data). For Select on read, it returns true when *any* data is available. In general, you would read with a vmin of one and a small vtime to allow streaming. Otherwise, you would read on a non-blocking descriptor, and expect some number of bytes less than or equal to the read amount to be returned. In practice, your process won't be scheduled until some interval after it is ready to run, and you should get good effective streaming of reads by virtue of this. > Plus there are apps which want only to check the status of the queue in > a descriptor without actually doing the I/O, for whatever reason they > like. Well, for these apps, you could designate them "real time priority" so they have "first dibs". But you are not guaranteed, without hard real time, that you will actually be scheduled in time. Multiple readers/writers could damage wakeup order, and you'd still have the race conditions. Probably your too-sensitive applications need to be written as drivers, not applications. 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 Dec 8 17:06:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07463 for hackers-outgoing; Mon, 8 Dec 1997 17:06:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07438 for ; Mon, 8 Dec 1997 17:06:45 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA23266; Mon, 8 Dec 1997 18:18:22 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd023234; Mon Dec 8 18:18:13 1997 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA24889; Mon, 8 Dec 1997 18:05:59 -0700 (MST) From: Terry Lambert Message-Id: <199712090105.SAA24889@usr01.primenet.com> Subject: Re: Process scheduling: nice does not work ??? To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Tue, 9 Dec 1997 01:05:59 +0000 (GMT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199712082219.UAA13229@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 8, 97 08:19:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've been doing some test with cpu-intensive scheduling in FreeBSD > 2.2-stable, when I found what seems to be an error in the scheduler. Standard UNIX priorities work like this: prio 20 19 18 17 ... ^ ^ ^ ^ IF something here run it ---------------' | | | ELSE IF something here run it ------------------' | | ELSE IF something here run it --------------------------' | ELSE IF something here run it ----------------------------------' ... Note: these are base priorities, which the system will adjust based on I/O vs. CPU utilization. Your processes must have both been I/O bound. FreeBSD is doing what it's supposed to. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Dec 8 17:08:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07738 for hackers-outgoing; Mon, 8 Dec 1997 17:08:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07709 for ; Mon, 8 Dec 1997 17:08:33 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA07171; Tue, 9 Dec 1997 11:33:11 +1030 (CST) Message-Id: <199712090103.LAA07171@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Karl Pielorz cc: hackers@freebsd.org Subject: Re: Writing Device drivers for 2.2.X etc' In-reply-to: Your message of "Mon, 08 Dec 1997 23:26:27 -0000." <348C8223.4FF22185@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 1997 11:33:07 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The templates also don't seem to mention major / minor device numbers either - > unless they 'were' taken care of in conf.c at some point in the past? Editing conf.c would have forced you to think about major numbers. Minor numbers have always been driver-specific. > Can anyone point the way to some up to date (i.e. 2.2.2+ etc.) info on the net > about writing device drivers for BSD - i.e. up to date templates etc.? for > nice simple ISA cards, or just code stubs? - Or are there any drivers in BSD > which are nice and simple for using as templates allready? Have a look at /usr/share/examples/drivers/make_device_driver.sh. Note that this defaults to major 20, which is for local testing. Once you're reasonably happy with your driver (and if you decide to give it away) we can arrange a new number for you... mike From owner-freebsd-hackers Mon Dec 8 17:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10119 for hackers-outgoing; Mon, 8 Dec 1997 17:40:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10105 for ; Mon, 8 Dec 1997 17:40:24 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id RAA12040; Mon, 8 Dec 1997 17:40:07 -0800 (PST) To: Nate Williams cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed In-reply-to: Your message of "Mon, 08 Dec 1997 08:23:04 MST." <199712081523.IAA11391@mt.sri.com> Date: Mon, 08 Dec 1997 17:40:07 -0800 Message-ID: <12036.881631607@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That's because no-one ever talks about architecture stuff anymore, and > just 'implements' nowadays. I think it *could* fulfill its purpose if > it was actually promoted/used. I would have used it in the past if I You can lead a horse to water... :) Jordan From owner-freebsd-hackers Mon Dec 8 17:50:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11891 for hackers-outgoing; Mon, 8 Dec 1997 17:50:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA11854 for ; Mon, 8 Dec 1997 17:50:23 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA03797; Mon, 8 Dec 1997 17:47:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd003792; Mon Dec 8 17:46:52 1997 Message-ID: <348CA278.5656AEC7@whistle.com> Date: Mon, 08 Dec 1997 17:44:24 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Charles Mott CC: hackers@FreeBSD.ORG Subject: Re: natd settings problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Charles Mott wrote: > > On Mon, 8 Dec 1997, Julian Elischer wrote: > > Charles Mott wrote: > > > > > > On Mon, 8 Dec 1997, Valter Mazzaro wrote: > > > > My purpose is to run a video conference application (vic) between HOST1/2 and > > > > ISP. > > > > In AS a natd daemon is running. The problem is that, with the present settings, > > > > I've succeeded in running vic just between ISP and ONE host AT THE TIME!! > > > [snip] > > > > you need to run mrouted on the gateway machine, so that it takes in a > > unicast IPstream from the supplier, > > and runs multicast out through the LAN. > > > > Would you care to post an example mrouted.conf file that does this? I > can't actually test this, but I am interested to understand it better, > especially if there are any interactions with natd. > > One user has told me he has had problems with multicast through ppp -alias > and natd, but I am not sure whether this was MBONE traffic or UDP. > > Charles Mott from my understanding of it... the local network would be running on the multicast IP address which would be independent of address translation. the IP tunnel to the mbone would be running out of the 'legal' address. I believe this should "just work" julian From owner-freebsd-hackers Mon Dec 8 17:59:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12884 for hackers-outgoing; Mon, 8 Dec 1997 17:59:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12874 for ; Mon, 8 Dec 1997 17:59:13 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id UAA05918; Mon, 8 Dec 1997 20:42:22 -0500 (EST) Message-ID: <19971208204221.23659@vmunix.com> Date: Mon, 8 Dec 1997 20:42:21 -0500 From: Mark Mayo To: Julian Elischer Cc: dg@root.com, Nate Williams , hackers@freebsd.org Subject: Re: [hackers:] Architectural advice needed References: <199712082204.OAA23754@implode.root.com> <348C78C4.6F5992E1@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <348C78C4.6F5992E1@whistle.com>; from Julian Elischer on Mon, Dec 08, 1997 at 02:46:28PM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Dec 08, 1997 at 02:46:28PM -0800, Julian Elischer wrote: > David Greenman wrote: > > > > >> Actually, that list hasn't been used for over a year and should > > >> probably be retired. I don't think it ever fulfilled its purpose. > > > > > >That's because no-one ever talks about architecture stuff anymore, and > > >just 'implements' nowadays. I think it *could* fulfill its purpose if > > >it was actually promoted/used. I would have used it in the past if I > > >thought it would be monitored, although it wasn't. Could we consider it > > >'back in use' for questions such as Julians? > > > > That's silly. Of course we talk about architectural issues. It's just that > > these days it's easier for me and others to pick up the phone and call the > > interested parties or send directed email than it is to send to lists full > > of indifferent people. > > > > which leaves those of us that ARE interested, but not being called, > kinda 'out of the loop'. That was one of my questions.. > "How can we get a critical mass together on architectural issues?" Well, I'm not even remotely involved with FreeBSD architectural issues, but I have faced a similar challenge with an atmospheric model that was probably at the same level of complexity (from a high-level piont-of-view) as you are currently facing. With the model project, we were running a tight budget (all the money went to supercomputer time.....) and the Net was the only way to "conference". We tried several methods, but it was very difficult to have a productive session through email with more than 2 people. Although mailing lists are somewhat pseudo-real-time, I found that you need a real "conversation" to hash out complex issues. In the end, we ended up using IRC. This was good and bad. The only way that we could keep it organized was by having a team-leader who would organize an agenda for the IRC meeting before hand, and forward it to everyone through the mailing list. Initial, brief feedback was requested about the agenda issues on the mailing list. A time was agreed upon and a chanel chosen (we just created one each time..). Overall, the IRC meetings were quite productive. There were minor annoyances like delays, and occasion channel "spam", but they were acceptable. There were still problems communicating ideas, mostly because on IRC you can't wave your arms around or grab people and shake them! :-) The other major problem, of course, was simply scheduling... our project, like the FreeBSD project, involved people located in Europe and North America. One thing that would have really helped us out that I now see in the win95/Mac netscape and mickeysoft conferencing tools is the "blackboard" thing - you can scribble and write on a blackboard that is shared by all members of the conference. I don't think this is present in the Unix version of Netscape 4.0 though... Bummer. One thing is for certain, conferencing tools will almost certainly represent a pretty big market in the years to come. Especially once we start getting ADSL and cable modem rollouts so you can have an audio/video link happening. The FreeBSD project, IMHO, is a shining example of what can be accomplished through the Net, and the success is remarkable given the relatively primitive tools used! If it doesn't already exist, an X conferencing tool certainly seems like a neat program "waiting to be created" by some spirited programmer out there! :-) cya, -Mark > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Mon Dec 8 18:00:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA13116 for hackers-outgoing; Mon, 8 Dec 1997 18:00:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA13103 for ; Mon, 8 Dec 1997 18:00:26 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA03949; Mon, 8 Dec 1997 17:51:43 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd003945; Mon Dec 8 17:51:35 1997 Message-ID: <348CA392.61133CF4@whistle.com> Date: Mon, 08 Dec 1997 17:49:06 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Karl Pielorz CC: hackers@freebsd.org Subject: Re: Writing Device drivers for 2.2.X etc' References: <348C8223.4FF22185@tdx.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Karl Pielorz wrote: > > Hi, > > I'm trying to write a device driver for an ISA signal processor card - I've > made sure there isn't one around at the moment (why re-invent the wheel? ) > - and I could do with some help... > > I downloaded some shell scripts, which at the time looked like a good idea - > they create a driver framework to work from (with all the code stubs written > for probing, creating, attaching, doing IOCTL's etc.) - but the code refers to > manually editing 'conf.c'... My 2.2.2-Release system doesn't have a conf.c ;-) you can ignore that that comment should be removed.. the driver you have (if you got a new one) should add itself into the array with the cdevsw_add() call. > > The templates also don't seem to mention major / minor device numbers either - > unless they 'were' taken care of in conf.c at some point in the past? major is in CDEV_MAJOR and the request to cdevsw_add(&dev, &${1}_cdevsw, NULL); does this. it's up to each routine (open, read, write, etc.) to interpret the minor number. the minor is available to each of these routines as: minor(dev) and in the sample I made an assumption that there was a 1:1 mapping between minor numbers and the unit number of the device If this is not true you should change the macro: #define UNIT(dev) minor(dev) /* assume one minor number per unit */ > > Can anyone point the way to some up to date (i.e. 2.2.2+ etc.) info on the net > about writing device drivers for BSD - i.e. up to date templates etc.? for > nice simple ISA cards, or just code stubs? - Or are there any drivers in BSD > which are nice and simple for using as templates allready? the templates ARE up to date (pretty much) but the comment at the end is wrong. > > Thanks in advance, send me mail ifthe templates don't help. the latest is: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/drivers/make_device_driver.sh?rev=1.1> (excuse the line-wrap) > Karl Pielorz > (mailto:kpielorz@tdx.co.uk) From owner-freebsd-hackers Mon Dec 8 18:16:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA14450 for hackers-outgoing; Mon, 8 Dec 1997 18:16:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA14444 for ; Mon, 8 Dec 1997 18:16:07 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA29531 for ; Mon, 8 Dec 1997 18:15:36 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma029529; Mon Dec 8 18:15:35 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id SAA26154 for freebsd-hackers@freebsd.org; Mon, 8 Dec 1997 18:15:35 -0800 (PST) From: Archie Cobbs Message-Id: <199712090215.SAA26154@bubba.whistle.com> Subject: Re: [hackers:] Architectural advice needed In-Reply-To: <12036.881631607@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 8, 97 05:40:07 pm" To: freebsd-hackers@freebsd.org Date: Mon, 8 Dec 1997 18:15:35 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think freebsd-hackers@freebsd.org is a fine place to talk about architectural issues. After all, if you're writing or modifying code (as hackers do) without proper awareness of the architectural issues that underly it, you're liable to make a mess. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Mon Dec 8 18:26:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15178 for hackers-outgoing; Mon, 8 Dec 1997 18:26:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dominator.eecs.harvard.edu (dominator.eecs.harvard.edu [140.247.60.28]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA15160 for ; Mon, 8 Dec 1997 18:26:19 -0800 (PST) (envelope-from karp@eecs.harvard.edu) Received: from localhost (localhost [127.0.0.1]) by dominator.eecs.harvard.edu (8.6.12/8.6.12) with SMTP id VAA05276; Mon, 8 Dec 1997 21:26:03 -0500 From: Brad Karp Message-Id: <199712090226.VAA05276@dominator.eecs.harvard.edu> X-Authentication-Warning: dominator.eecs.harvard.edu: Host localhost didn't use HELO protocol To: John-Mark Gurney Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, karp@dominator.eecs.harvard.edu, mankin@isi.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... In-reply-to: Your message of "Sun, 07 Dec 97 19:39:32 PST." <19971207193932.61833@hydrogen.nike.efn.org> Date: Mon, 08 Dec 97 21:26:03 -0500 X-Mts: smtp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My driver is written over the IP tunnel (tun), and is completely portable > > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > > radios), and works very well, overall. > > hmmm... tun is nice for portability, but it still doesn't match the > performance of a kernel land driver... the extra context switches > do impact performance... a ping to a remote host has to traverse the > kernel/userland boundary three times when pinging a remote host... > (ping->kernel->tunnel->output to device/network)... Throughput: Metricom radios max out at about 58 Kbps, in my experience (TCP, greedy sender with data always available). I have confirmed this figure with Metricom's engineers, who verify it. Reasons include the fact that Metricom radios are half-duplex (so ACKs require send/receive switching) and frequency configuration time (spread spectrum, remember) for jumping to the receiver's current frequency on the RF side (for each packet sent, both data and ACK). Even if the 100 Kbps throughput were realizable, though, I'd expect a very underpowered CPU (say, a 486/66) to keep up with packet forwarding at such a low data rate (and with tiny CPU utilization), as the CPU usage will be throttled by the very low bandwidth of the radio. Saturating the radio leaves > 99% idle time on a Pentium 150, as one (non-fully-conclusive, but non-contradictory) data point. Latency: I do believe I experience more latency than is fundamentally required by the hardware, yes. I don't believe that this has materially to do with tun and context switches and copyin/copyout, however--again, I'd expect them to be noise on modern processors. The 10 ms process scheduling quantum should not effect latency adversely if the user-level driver process is run at a negative nice value (in effect, emulating a kernel driver's giving strict priority to tx/rx complete interrupts). I think that the real culprit is the way sio batches characters, scheduling software interrupts (scheduled at 10 ms granularity, I believe) to pass characters, and buffering them in the tty driver in the interest of reducing the hardware serial interrupt handler's latency. This should add latency to the _kernel_ ppp driver, as well, as my reading is that the kernel ppp driver is built atop sio, and should thus see the same latency due to sio's character batching. Can anyone confirm this? i.e., does the kernel ppp driver tend to deliver packets on 10 ms boundaries, when sio's software interrupts complete? Also, you need to keep in mind that the latency of data transmission on a Metricom radio is grossly dominated by the path through the radio hardware, waiting to jump to the other radio's frequency in the right slot, and through the radio hardware on the other side. A useful datapoint to substantiate my latency argument: The next-hop rtt of the Stanford (Linux kernel) driver is on the order of 167 ms according to the driver's author, whereas my user-level driver on FreeBSD gets a next-hop rtt of 140 ms! > I actually have the NetBSD kernel strip driver compiling... I just need > to test the driver... Is this the driver from Randy Katz's group, perchance? Can you let me know what rtt it gives to the next hop? I strongly suspect you'll get a figure very close to the one I do (140 ms). How about for the kernel ppp driver, if you have that figure handy? > I'd be willing to test and commit the driver, assuming no other commiters > object.. :) also, I assume that the license for the driver is similar > to the BSD license? and not GPL'd? The license will be similar to that for BSD, yes; it will have Harvard's and USC/ISI's (my funders') copyrights, and will allow redistribution in source form and modification as long as the copyright notice is left intact. I need add the copyright to the code and write up a brief man page, I suppose. Will let you know when it's ready to pick up, and where. > > Again, as I don't subscribe to freebsd-hackers, please address comments, > > questions, and/or requests for the code to me by email. > > ok, I'm adding you to my aliases... ttyl.. Actually, while I wish I did, I don't really have time to peruse the traffic in -hackers. Could you cut me from your forwarding list? (Thanks for thoughtfully including me, though!) Regards, -Brad, karp@eecs.harvard.edu From owner-freebsd-hackers Mon Dec 8 18:54:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17380 for hackers-outgoing; Mon, 8 Dec 1997 18:54:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17340 for ; Mon, 8 Dec 1997 18:54:06 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id VAA05280; Mon, 8 Dec 1997 21:53:13 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Mon, 8 Dec 1997 21:53:07 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Terry Lambert cc: Joao Carlos Mendes Luis , freebsd-hackers@FreeBSD.ORG Subject: Re: Process scheduling: nice does not work ??? In-Reply-To: <199712090105.SAA24889@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Dec 1997, Terry Lambert wrote: > > I've been doing some test with cpu-intensive scheduling in FreeBSD > > 2.2-stable, when I found what seems to be an error in the scheduler. > > > Standard UNIX priorities work like this: > > prio 20 19 18 17 ... > ^ ^ ^ ^ > IF something here run it ---------------' | | | > ELSE IF something here run it ------------------' | | > ELSE IF something here run it --------------------------' | > ELSE IF something here run it ----------------------------------' I thought, Terry, that the effective priority slowly raised itself, with the length of time that it hadn't been run. The scheme you describe means that anything set to 19 never gets run at all, if there's a 20 (in fact I think the numbers are backwords, anyhow). Thats not the way I thought it was. > ... > > Note: these are base priorities, which the system will adjust based on > I/O vs. CPU utilization. > > > Your processes must have both been I/O bound. > > FreeBSD is doing what it's supposed to. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Mon Dec 8 18:55:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17520 for hackers-outgoing; Mon, 8 Dec 1997 18:55:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dominator.eecs.harvard.edu (dominator.eecs.harvard.edu [140.247.60.28]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA17503 for ; Mon, 8 Dec 1997 18:55:16 -0800 (PST) (envelope-from karp@eecs.harvard.edu) Received: from localhost (localhost [127.0.0.1]) by dominator.eecs.harvard.edu (8.6.12/8.6.12) with SMTP id VAA28659; Mon, 8 Dec 1997 21:55:13 -0500 From: Brad Karp Message-Id: <199712090255.VAA28659@dominator.eecs.harvard.edu> X-Authentication-Warning: dominator.eecs.harvard.edu: Host localhost didn't use HELO protocol To: Charles Mott Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... In-reply-to: Your message of "Sun, 07 Dec 97 20:44:06 MST." Date: Mon, 08 Dec 97 21:55:13 -0500 X-Mts: smtp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Charles. About your questions: > I'd be curious to hear how your IP-MAC mapping works. Is it some sort of > stochastic token passing between neighbors? To what size networks can it > scale? Metricom radios have unique hardware addresses, much as Ethernet cards do. But they don't let users broadcast packets. My driver receives neighbor acquisition reports from the radio (provided by the radio hardware, using a protocol done by the radios that you can't change and don't see), and uses them to query neighbors (via unicast) for their IP and MAC addresses (providing the remote node with its own mapping at the same time). Each node builds a table of the IP->MAC mappings in this way. This architecture scales well, as mapping entries can be cached for arbitrarily long periods (they're replaced by any newly arrived conflicting entries, just like ARP entries for Ethernet are). So the overall message rate for maintaining _one node's_ table is quite low--it is O(the rate of new neighbor acquisition events). Because reachability is a property of individual node pairs, and the Metricom medium doesn't support broadcast, I see no way to avoid per-neighbor request/response pairs for acquiring immediate neigbhors' IP->MAC mappings. A centralized ARP server (what Stanford's Metricom driver uses) reduces the total message cost when a network is densely connected (i.e., most nodes can directly reach most others as neighbors), but results in network partition when a network is sparsely connected (i.e., there's a multi-hop path between nodes not in direct, single-hop range of one another, such that no central ARP server can be in direct range of all mobile nodes). In this latter case, non-centralized neighbor discovery (with its message cost) is essential, so that a higher-layer (e.g., IP routing) mechanism can provide multi-hop reachability. Another fact: Metricom's hardware itself can only track 400 neighbors, and that limit of theirs (as well as the cost of the low-level hardware's neighbor acquisition protocol) would be limiting long before my ARP protocol would be. > Some obscure questions, since you've seriously worked with the metricom > hardware: how intrinsically doppler tolerant is the communications > waveform? What modulation scheme? What chip rate? Metricom is very close-chested about the low-level details of the radio hardware, I'm afraid. Beyond the facts that they're a crude form of spread spectrum (i.e., frequency hopping, but way simpler and less robust than CDMA), that the theoretical max rate is 100 Kbps (unidirectional, without overhead for switching direction for ACKs), that they're half-duplex, that they use the unlicensed 900 MHz band, and a bit about the slot times and band widths in their frequency hopping scheme, I know nothing. If by doppler-tolerant you mean robust in the face of motion, I have used their radios in a car moving at ~20 mph with no noticeable throughput reduction, so long as a I remained within range of my peer. Metricom's radios are pretty much bimodal in signal quality: you're in-range and doing well, or out-of-range and getting nothing, in my experience (which their engineers have commented on as typical). I hope these answers are useful; please let me know if you have further questions, or if I've not answered the question you intended to ask. :-) -Brad, karp@eecs.harvard.edu From owner-freebsd-hackers Mon Dec 8 18:56:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17748 for hackers-outgoing; Mon, 8 Dec 1997 18:56:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17726 for ; Mon, 8 Dec 1997 18:56:38 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA16081; Mon, 8 Dec 1997 18:56:10 -0800 (PST) Message-ID: <19971208185609.10013@hydrogen.nike.efn.org> Date: Mon, 8 Dec 1997 18:56:09 -0800 From: John-Mark Gurney To: Brad Karp Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, mankin@isi.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... References: <19971207193932.61833@hydrogen.nike.efn.org> <199712090226.VAA05276@dominator.eecs.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712090226.VAA05276@dominator.eecs.harvard.edu>; from Brad Karp on Mon, Dec 08, 1997 at 09:26:03PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brad Karp scribbled this message on Dec 8: > > > My driver is written over the IP tunnel (tun), and is completely portable > > > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > > > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > > > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > > > radios), and works very well, overall. > > > > hmmm... tun is nice for portability, but it still doesn't match the > > performance of a kernel land driver... the extra context switches > > do impact performance... a ping to a remote host has to traverse the > > kernel/userland boundary three times when pinging a remote host... > > (ping->kernel->tunnel->output to device/network)... > > Throughput: Metricom radios max out at about 58 Kbps, in my experience > (TCP, greedy sender with data always available). I have confirmed this > figure with Metricom's engineers, who verify it. Reasons include the > fact that Metricom radios are half-duplex (so ACKs require > send/receive switching) and frequency configuration time (spread > spectrum, remember) for jumping to the receiver's current frequency on > the RF side (for each packet sent, both data and ACK). > > Even if the 100 Kbps throughput were realizable, though, I'd expect a > very underpowered CPU (say, a 486/66) to keep up with packet > forwarding at such a low data rate (and with tiny CPU utilization), as > the CPU usage will be throttled by the very low bandwidth of the > radio. Saturating the radio leaves > 99% idle time on a Pentium 150, > as one (non-fully-conclusive, but non-contradictory) data point. true.. many of these do work on fast machines.. but right now my notebook is limited to a 486dx2/50... so it's quite slow... and then my fastest machine at home right now is a k5/90.. so I'm quite sensitive to the performance of code (heck, I still run a 386/25sx w/ 6megs too.. :) ) > Latency: I do believe I experience more latency than is fundamentally > required by the hardware, yes. I don't believe that this has > materially to do with tun and context switches and copyin/copyout, > however--again, I'd expect them to be noise on modern processors. yes... it probably is compared to the rest of the hardware that we have to deal with... I'll just have to use the driver to check it out... > Also, you need to keep in mind that the latency of data transmission > on a Metricom radio is grossly dominated by the path through the radio > hardware, waiting to jump to the other radio's frequency in the right > slot, and through the radio hardware on the other side. > > A useful datapoint to substantiate my latency argument: > > The next-hop rtt of the Stanford (Linux kernel) driver is on the order > of 167 ms according to the driver's author, whereas my user-level > driver on FreeBSD gets a next-hop rtt of 140 ms! interesting... so does that mean pings are 140ms?? I'd be VERY interested... right now I have to put up with about 350ms rtt on the modems to the university's network... and then you add in a 28.8k modem (that is about 200ms due to the way it's connected), and using your home machine is quite slow.. > > I actually have the NetBSD kernel strip driver compiling... I just need > > to test the driver... > > Is this the driver from Randy Katz's group, perchance? > > Can you let me know what rtt it gives to the next hop? I strongly > suspect you'll get a figure very close to the one I do (140 ms). > > How about for the kernel ppp driver, if you have that figure handy? nope... I just have it compiling.. I haven't been able to test it yet as there were some problems will building a -current world to install on my notebook... but I'm doing the install now... > > I'd be willing to test and commit the driver, assuming no other commiters > > object.. :) also, I assume that the license for the driver is similar > > to the BSD license? and not GPL'd? > > The license will be similar to that for BSD, yes; it will have > Harvard's and USC/ISI's (my funders') copyrights, and will allow > redistribution in source form and modification as long as the > copyright notice is left intact. > > I need add the copyright to the code and write up a brief man page, I > suppose. Will let you know when it's ready to pick up, and where. thanks... hopefully ricochet will start to give better support to the non-microsoft people... only releasing an updater for windows and macs is really a pain... last time software came out, I had to use a friends notebook, as none of my machines (at the time) had a microsoft os on it... > > > Again, as I don't subscribe to freebsd-hackers, please address comments, > > > questions, and/or requests for the code to me by email. > > > > ok, I'm adding you to my aliases... ttyl.. > > Actually, while I wish I did, I don't really have time to peruse the > traffic in -hackers. Could you cut me from your forwarding list? > (Thanks for thoughtfully including me, though!) this isn't a forwarding list.. this is just a way that makes it easier for me to send you mail in the future.. (and I personally HATE forwarding lists, they suck, I've gotten to much junk mail from people that way)... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Mon Dec 8 19:37:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21143 for hackers-outgoing; Mon, 8 Dec 1997 19:37:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21129 for ; Mon, 8 Dec 1997 19:37:07 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id TAA05134; Mon, 8 Dec 1997 19:36:46 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712090336.TAA05134@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: dag-erli@ifi.uio.no (Dag-Erling Coidan Sm rgrav) cc: Nate Williams , hackers@freebsd.org Subject: Re: isa.c In-reply-to: Your message of "08 Dec 1997 22:18:40 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Dec 1997 19:36:46 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Luigi's patches are very simply just simply grab /sys/i386/isa/isa.c from -current and re-apply the functionality to your /sys/i386/isa/isa.c That exercise should take a couple of hours if that. If you don't want to do that you are free to upgrate to 3.0 -current 8) Amancio From owner-freebsd-hackers Mon Dec 8 19:39:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21400 for hackers-outgoing; Mon, 8 Dec 1997 19:39:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21364 for ; Mon, 8 Dec 1997 19:39:35 -0800 (PST) (envelope-from ian@nmsu.edu) Received: from NMSU.Edu by bubba.NMSU.Edu (8.8.7/NMSU) id UAA05614; Mon, 8 Dec 1997 20:37:47 -0700 (MST) Received: from wilma by NMSU.Edu (8.8.4/NMSU-1.18) id UAA05489; Mon, 8 Dec 1997 20:33:57 -0700 (MST) Received: from nmsu.edu by wilma (SMI-8.6/NMSU) id UAA23221; Mon, 8 Dec 1997 20:37:13 -0700 Message-ID: <348CBD9E.9F851CC0@nmsu.edu> Date: Mon, 08 Dec 1997 20:40:14 -0700 From: Ian Logan Organization: Computing and Networking X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4m) MIME-Version: 1.0 To: Archie Cobbs CC: freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed References: <199712090215.SAA26154@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have to agree with Archie. I would find it very helpfull to know what architectural issues were coming down the pipe. I've been following things for a while, and its been very usefull in my efforts ;) Even if its not discussed on hackers, have the list open (at least read-only) would be great! Just my 2 cents, Ian -- Ian Logan Computing & Networking New Mexico State University Email: ian@nmsu.edu Phone: 505-646-6034 Fax: 505-646-5278 From owner-freebsd-hackers Mon Dec 8 19:42:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21831 for hackers-outgoing; Mon, 8 Dec 1997 19:42:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21825 for ; Mon, 8 Dec 1997 19:42:24 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA16246; Mon, 8 Dec 1997 19:42:10 -0800 (PST) Message-ID: <19971208194209.62841@hydrogen.nike.efn.org> Date: Mon, 8 Dec 1997 19:42:09 -0800 From: John-Mark Gurney To: Mark Mayo Cc: Julian Elischer , dg@root.com, Nate Williams , hackers@FreeBSD.ORG Subject: Re: [hackers:] Architectural advice needed References: <199712082204.OAA23754@implode.root.com> <348C78C4.6F5992E1@whistle.com> <19971208204221.23659@vmunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971208204221.23659@vmunix.com>; from Mark Mayo on Mon, Dec 08, 1997 at 08:42:21PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mark Mayo scribbled this message on Dec 8: > One thing that would have really helped us out that I now see in the > win95/Mac netscape and mickeysoft conferencing tools is the > "blackboard" thing - you can scribble and write on a blackboard > that is shared by all members of the conference. I don't think this is > present in the Unix version of Netscape 4.0 though... Bummer. why not use sdr, whiteboard, and vat?? I've recieved quite good resposne at home (over a 28.8k) from Luigi (in Europe) using GSM on vat (I could hear him type :) )... but the other way was to overloaded for me to chat with him... I'm looking at moving into the university dorms, and once I do, then I can have all the fun of multicast... > One thing is for certain, conferencing tools will almost certainly > represent a pretty big market in the years to come. Especially once we > start getting ADSL and cable modem rollouts so you can have an audio/video > link happening. The FreeBSD project, IMHO, is a shining example of what > can be accomplished through the Net, and the success is remarkable given > the relatively primitive tools used! yep... once the higher speed connections come out.. then we can use the Bt848 and a camera for video conferencing.. :) > If it doesn't already exist, an X conferencing tool certainly seems like > a neat program "waiting to be created" by some spirited programmer > out there! :-) yep, they all pretty much exist... the ones that don't exist are the ones that don't require X... :( -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Mon Dec 8 21:51:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA01556 for hackers-outgoing; Mon, 8 Dec 1997 21:51:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA01537; Mon, 8 Dec 1997 21:51:07 -0800 (PST) (envelope-from sprice@hiwaay.net) Received: from bonsai.hiwaay.net (max7-233.HiWAAY.net [208.147.145.233]) by fly.HiWAAY.net (8.8.7/8.8.6) with SMTP id XAA21778; Mon, 8 Dec 1997 23:50:45 -0600 (CST) Message-ID: <348CDCE5.ABD322C@hiwaay.net> Date: Mon, 08 Dec 1997 23:53:41 -0600 From: Steve Price X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Paul Allenby CC: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Make world broken on -stable References: <199712082003.WAA14901@zibbi.mikom.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Paul Allenby wrote: > > Hi all > > After cvsup'ing the latest RELENG_2_2 src about an hour ago, and > a "make buildworld", I got: > > ===> libc > install -c -o bin -g bin -m 444 libc.a /usr/obj/usr/src/tmp/usr/lib > install -c -o bin -g bin -m 444 -fschg libc.so.3.0 /usr/obj/usr/src/tmp/usr/lib > install -c -o bin -g bin -m 444 libc_pic.a /usr/obj/usr/src/tmp/usr/lib > ld.so failed: Undefined symbol "___generic_syscall" in install:/usr/obj/usr/src/tmp/usr/lib/libc.so.3.0 > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Any ideas? > cd /usr/src/lib/libc make cleandir obj depend all install Steve > Paul From owner-freebsd-hackers Mon Dec 8 21:58:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA02176 for hackers-outgoing; Mon, 8 Dec 1997 21:58:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA02157 for ; Mon, 8 Dec 1997 21:58:01 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA00305; Tue, 9 Dec 1997 05:57:12 +0100 From: Luigi Rizzo Message-Id: <199712090457.FAA00305@labinfo.iet.unipi.it> Subject: Re: Why FIONREAD has no dual for write ? To: bakul@torrentnet.com (Bakul Shah) Date: Tue, 9 Dec 1997 05:57:11 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199712090045.TAA06826@chai.torrentnet.com> from "Bakul Shah" at Dec 8, 97 07:44:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I agree with the above, except that it does not work in all situations. > > E.g. I am not sure but does select() guarantee that you don't > > end up writing/reading one byte at a time ? I know in practice things > > are different, but there is no standard behaviour I think, so the risk > > is still there. In the audio driver I had to modify the behaviour of > > select() (block size) using a separate ioctl(). > > Perhaps one solution is to add an ioctl to set high/low > watermarks on a device and add new event bits POLLIN_WM and > POLLLOUT_WM for the poll() syscall. Good idea, this could solve the blocksize problem rather elegantly (although with some portability problems...). > > Plus there are apps which want only to check the status of the queue in > > a descriptor without actually doing the I/O, for whatever reason they > > like. > > This can be handled by POLL{IN,OUT}_WM. not sure how... if i get it right your changes can tell a process when you can transfer x >= WM bytes, but gives no clue about the current status of the queue. Much like the difference between Q. Excuse me Sir, do you know what time is it ? A. Yes. and Q. Excuse me Sir, do you know what time is it ? A. 9:30 Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Dec 8 22:08:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA02819 for hackers-outgoing; Mon, 8 Dec 1997 22:08:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bcarsde4.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA02766 for ; Mon, 8 Dec 1997 22:07:56 -0800 (PST) (envelope-from atrens@nortel.ca) Message-Id: <199712090607.WAA02766@hub.freebsd.org> Received: from bcars520.ca.nortel.com by bcarsde4.nortel.ca; Mon, 8 Dec 1997 21:36:44 -0500 Received: from bnr.ca by bcars520.bnr.ca id <24112-0@bcars520.bnr.ca>; Mon, 8 Dec 1997 19:37:11 -0500 Date: 08 Dec 1997 19:36 EST To: hackers@FreeBSD.ORG From: "Andrew Atrens" Subject: possible linux emulation bug (was: dealing with zombies) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi again folks! Rummaging around my mailbox, I found a hackers thread from Sept 01 to Sept 07 on this topic. Specifically on Sep01, Greg Lehey writes: > The semantics of SIGC[H]LD differ greatly between System V and BSD. > Here's a quote from "Porting UNIX Software", page 213: > > System V treats the death of a child differently from other > implementations: The System V signal SIGCLD differs from the BSD and > POSIX.1 signal SIGCHLD and from all other signals by remaining active > until you call wait. This can cause infinite recursion in the signal > handler if you reinstate the signal via signal or sigset before > calling wait. If you use the POSIX.1 sigaction call, you don't have > to worry about this problem. > > When a child dies, it becomes a zombie. As all voodoo fans know, a > zombie is one of the Living Dead, neither alive nor dead. In UNIX > terminology, when a child process dies it becomes a zombie: the text > and data segments are freed, and the files are closed, but the > process table entry and some other information remain until it is > exorcized by the parent process, which is done by calling wait. By > default, System V ignores SIGCLD and SIGCHLD, but the system creates > zombies, so you can find out about child status by calling wait. If, > however, you change the default to explicitly ignore the signal, the > system ignores SIGCHLD and SIGCLD, but it also no longer creates > zombie processes. If you set the disposition of SIGCHLD and SIGCLD > to ignore, but you call wait anyway, it waits until all child > processes have terminated, and then returns -1 (error), with errno > set to ECHILD. You can achieve the same effect with sigaction by > specifying the SA_NOCLDWAIT flag in sa_flags. There is no way to > achieve this behaviour in other versions of UNIX: if you find your > ported program is collecting zombies (which you will see with the ps > program), it might be that the program uses this feature to avoid > having to call wait. If you experience this problem, you can solve > it by adding a signal handler for SIGCLD that just calls wait and > returns. > > The signal number for SIGCLD is the same as for SIGCHLD. The > semantics depend on how you enable it: if you enable it with signal, > you get SIGCLD semantics (and unreliable signals), and if you enable > it with sigaction you get SIGCHLD and reliable signals. Don't rely > on this, however. Some versions of System V have special coding to > ensure that a separate SIGCLD signal is delivered for each child that > dies. > > Greg --- Given that Linux is in many ways SysV'ish, would this imply that my Wordperfect zombies are the result of an implementation inconsistency in the Linux emulation code ? In message "dealing with zombies", I wrote: > Hi All, > > I'm eval'ing Wordperfect-7.0-for-Linux on `FreeBSD 3.0-971012-SNAP' and am > seeing lots of zombies: > > 1446 ?? Z 0:00.00 (xwpthes) > 1460 ?? Z 0:00.00 (xwpgmk5) > 1461 ?? Z 0:00.00 (xwpspell) > 1462 ?? Z 0:00.00 (xwpspell) > 1467 ?? Z 0:00.00 (wpp7) > 1471 ?? Z 0:00.00 (xwpspell) > 1472 ?? Z 0:00.00 (xwpspell) > 1473 ?? Z 0:00.00 (xwpspell) > 1513 ?? Z 0:00.00 (xwpthes) > 1514 ?? Z 0:00.00 (xwpthes) > 1531 ?? Z 0:00.00 (xwpthes) > 1532 ?? Z 0:00.00 (xwpthes) > 1533 ?? Z 0:00.00 (xwpthes) > 1543 ?? Z 0:00.00 (xwpthes) > 1551 ?? Z 0:00.00 (xwpthes) > > As I understand, the root cause is that (xwp) is failing to reap dead children. > However, the children *do* get reaped when I exit xwp... it seems that > as long as xwp is running, no reaping is done, and the zombies accumulate...:( > > What I'm wondering is: > > i. Is this a fault/feature of the app (xwp), the linux emulation code, or > the kernel (in a larger sense), and > ii. are there any *good* workarounds. ( I seem to recall some discussion about > a tunable kernel parm for auto-reap or some such thing? ) > > > Cheers, > > Andrew. > > From owner-freebsd-hackers Mon Dec 8 22:40:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04941 for hackers-outgoing; Mon, 8 Dec 1997 22:40:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04933 for ; Mon, 8 Dec 1997 22:40:11 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA10100 for ; Mon, 8 Dec 1997 22:34:21 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd010098; Mon Dec 8 22:34:14 1997 Date: Mon, 8 Dec 1997 22:31:46 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: Anyone seen this kernel (ethernet) bug? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The machine: 485DX4 with 2 SMC compatible ethernet cards. FreeBSD 2.2.2 (approx) the symptom: Ethernet header spammed over contents of kernel stack. It would seem that the ed driver (if_ed.c) or the ethernet generic code, has a bug, in which the contents of an incoming ethernet header are written into the wrong kernel stack. I've been seeing this occasionally, but this time I was able to possitively identify the memory corruption as a 14 byte ethernet header, from a received packet. The kernel is from July 1, but looking in the CVS logs shows no related bugs as having been fixed in the intervening 5 months. More info: The bug has been seen to occur when an interface isn ifconfig'd up while other machines are still trying to address it, after the machine was (violently) rebooted. My first guess is that the driver gets a packet before it's quite ready for it. Some other process gets it's kernel stack corrupted. I will be looking for this tonight, but if you have any insights, or feel the urge to beat me to it, feel free to send suggestions :) julian From owner-freebsd-hackers Mon Dec 8 22:59:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA06168 for hackers-outgoing; Mon, 8 Dec 1997 22:59:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA06143; Mon, 8 Dec 1997 22:59:10 -0800 (PST) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id IAA27732; Tue, 9 Dec 1997 08:58:42 +0200 (SAT) From: John Hay Message-Id: <199712090658.IAA27732@zibbi.mikom.csir.co.za> Subject: Re: Make world broken on -stable In-Reply-To: <348CDCE5.ABD322C@hiwaay.net> from Steve Price at "Dec 8, 97 11:53:41 pm" To: sprice@hiwaay.net (Steve Price) Date: Tue, 9 Dec 1997 08:58:41 +0200 (SAT) Cc: pallenby@zibbi.mikom.csir.co.za, freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > After cvsup'ing the latest RELENG_2_2 src about an hour ago, and > > a "make buildworld", I got: > > > > ===> libc > > install -c -o bin -g bin -m 444 libc.a /usr/obj/usr/src/tmp/usr/lib > > install -c -o bin -g bin -m 444 -fschg libc.so.3.0 /usr/obj/usr/src/tmp/usr/lib > > install -c -o bin -g bin -m 444 libc_pic.a /usr/obj/usr/src/tmp/usr/lib > > ld.so failed: Undefined symbol "___generic_syscall" in install:/usr/obj/usr/src/tmp/usr/lib/libc.so.3.0 > > *** Error code 1 > > > > ... > > > > Any ideas? > > > > cd /usr/src/lib/libc > make cleandir obj depend all install I thought "make buildworld" was supposed to do all of that? John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Tue Dec 9 00:40:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14110 for hackers-outgoing; Tue, 9 Dec 1997 00:40:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA13966 for ; Tue, 9 Dec 1997 00:38:32 -0800 (PST) (envelope-from proff@iq.org) Received: (qmail 20085 invoked by uid 110); 9 Dec 1997 08:36:45 -0000 To: freebsd-hackers@freebsd.org, pg95-dev@postgresql.org Subject: mars.. From: Julian Assange Date: 09 Dec 1997 19:36:44 +1100 Message-ID: Lines: 151 X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: Mike Jones The Mars Pathfinder mission was widely proclaimed as "flawless" in the early days after its July 4th, 1997 landing on the Martian surface. Successes included its unconventional "landing" -- bouncing onto the Martian surface surrounded by airbags, deploying the Sojourner rover, and gathering and transmitting voluminous data back to Earth, including the panoramic pictures that were such a hit on the Web. But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data. The press reported these failures in terms such as "software glitches" and "the computer was trying to do too many things at once". This week at the IEEE Real-Time Systems Symposium I heard a fascinating keynote address by David Wilner, Chief Technical Officer of Wind River Systems. Wind River makes VxWorks, the real-time embedded systems kernel that was used in the Mars Pathfinder mission. In his talk, he explained in detail the actual software problems that caused the total system resets of the Pathfinder spacecraft, how they were diagnosed, and how they were solved. I wanted to share his story with each of you. VxWorks provides preemptive priority scheduling of threads. Tasks on the Pathfinder spacecraft were executed as threads with priorities that were assigned in the usual manner reflecting the relative urgency of these tasks. Pathfinder contained an "information bus", which you can think of as a shared memory area used for passing information between different components of the spacecraft. A bus management task ran frequently with high priority to move certain kinds of data in and out of the information bus. Access to the bus was synchronized with mutual exclusion locks (mutexes). The meteorological data gathering task ran as an infrequent, low priority thread, and used the information bus to publish its data. When publishing its data, it would acquire a mutex, do writes to the bus, and release the mutex. If an interrupt caused the information bus thread to be scheduled while this mutex was held, and if the information bus thread then attempted to acquire this same mutex in order to retrieve published data, this would cause it to block on the mutex, waiting until the meteorological thread released the mutex before it could continue. The spacecraft also contained a communications task that ran with medium priority. Most of the time this combination worked fine. However, very infrequently it was possible for an interrupt to occur that caused the (medium priority) communications task to be scheduled during the short interval while the (high priority) information bus thread was blocked waiting for the (low priority) meteorological data thread. In this case, the long-running communications task, having higher priority than the meteorological task, would prevent it from running, consequently preventing the blocked information bus task from running. After some time had passed, a watchdog timer would go off, notice that the data bus task had not been executed for some time, conclude that something had gone drastically wrong, and initiate a total system reset. This scenario is a classic case of priority inversion. HOW WAS THIS DEBUGGED? VxWorks can be run in a mode where it records a total trace of all interesting system events, including context switches, uses of synchronization objects, and interrupts. After the failure, JPL engineers spent hours and hours running the system on the exact spacecraft replica in their lab with tracing turned on, attempting to replicate the precise conditions under which they believed that the reset occurred. Early in the morning, after all but one engineer had gone home, the engineer finally reproduced a system reset on the replica. Analysis of the trace revealed the priority inversion. HOW WAS THE PROBLEM CORRECTED? When created, a VxWorks mutex object accepts a boolean parameter that indicates whether priority inheritance should be performed by the mutex. The mutex in question had been initialized with the parameter off; had it been on, the low-priority meteorological thread would have inherited the priority of the high-priority data bus thread blocked on it while it held the mutex, causing it be scheduled with higher priority than the medium-priority communications task, thus preventing the priority inversion. Once diagnosed, it was clear to the JPL engineers that using priority inheritance would prevent the resets they were seeing. VxWorks contains a C language interpreter intended to allow developers to type in C expressions and functions to be executed on the fly during system debugging. The JPL engineers fortuitously decided to launch the spacecraft with this feature still enabled. By coding convention, the initialization parameter for the mutex in question (and those for two others which could have caused the same problem) were stored in global variables, whose addresses were in symbol tables also included in the launch software, and available to the C interpreter. A short C program was uploaded to the spacecraft, which when interpreted, changed the values of these variables from FALSE to TRUE. No more system resets occurred. ANALYSIS AND LESSONS First and foremost, diagnosing this problem as a black box would have been impossible. Only detailed traces of actual system behavior enabled the faulty execution sequence to be captured and identified. Secondly, leaving the "debugging" facilities in the system saved the day. Without the ability to modify the system in the field, the problem could not have been corrected. Finally, the engineer's initial analysis that "the data bus task executes very frequently and is time-critical -- we shouldn't spend the extra time in it to perform priority inheritance" was exactly wrong. It is precisely in such time critical and important situations where correctness is essential, even at some additional performance cost. HUMAN NATURE, DEADLINE PRESSURES David told us that the JPL engineers later confessed that one or two system resets had occurred in their months of pre-flight testing. They had never been reproducible or explainable, and so the engineers, in a very human-nature response of denial, decided that they probably weren't important, using the rationale "it was probably caused by a hardware glitch". Part of it too was the engineers' focus. They were extremely focused on ensuring the quality and flawless operation of the landing software. Should it have failed, the mission would have been lost. It is entirely understandable for the engineers to discount occasional glitches in the less-critical land-mission software, particularly given that a spacecraft reset was a viable recovery strategy at that phase of the mission. THE IMPORTANCE OF GOOD THEORY/ALGORITHMS David also said that some of the real heroes of the situation were some people from CMU who had published a paper he'd heard presented many years ago who first identified the priority inversion problem and proposed the solution. He apologized for not remembering the precise details of the paper or who wrote it. Bringing things full circle, it turns out that the three authors of this result were all in the room, and at the end of the talk were encouraged by the program chair to stand and be acknowledged. They were Lui Sha, John Lehoczky, and Raj Rajkumar. When was the last time you saw a room of people cheer a group of computer science theorists for their significant practical contribution to advancing human knowledge? :-) It was quite a moment. POSTLUDE For the record, the paper was: L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An Approach to Real-Time Synchronization. In IEEE Transactions on Computers, vol. 39, pp. 1175-1185, Sep. 1990. - Mike -- Prof. Julian Assange |"Don't worry about people stealing your ideas. If your | Ideas are any good, you'll have to ram them down proff@iq.org | people's throats." -- Stolen quote from Howard Aiken proff@gnu.ai.mit.edu | http://underground.org/book From owner-freebsd-hackers Tue Dec 9 00:41:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14306 for hackers-outgoing; Tue, 9 Dec 1997 00:41:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14298 for ; Tue, 9 Dec 1997 00:41:26 -0800 (PST) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by gamespot.com (8.8.7/8.8.7) with SMTP id AAA16015 for ; Tue, 9 Dec 1997 00:41:17 -0800 (PST) Date: Tue, 9 Dec 1997 00:41:17 -0800 (PST) From: Ian Kallen To: freebsd-hackers@freebsd.org Subject: San Francisco Bay Area FreeBSD Users Meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bring in an NT server and leave with a Real Unix system (ooohs and aaahs from the crowd), no charge ;) what: face to face FreeBSD enthusiasts when: Thursday December 11th, 1997 where: http://www.arachna.com/freebsd/reef_map.html -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Tue Dec 9 01:14:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA16184 for hackers-outgoing; Tue, 9 Dec 1997 01:14:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA16179 for ; Tue, 9 Dec 1997 01:14:39 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.5/8.8.5) with ESMTP id IAA05654 for ; Tue, 9 Dec 1997 08:54:53 GMT Message-ID: <348D0D1A.8D2531FE@tdx.co.uk> Date: Tue, 09 Dec 1997 09:19:22 +0000 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Writing Device drivers for 2.2.X etc' References: <199712090103.LAA07171@word.smith.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Smith wrote: > > Editing conf.c would have forced you to think about major numbers. > Minor numbers have always been driver-specific. > Yes, I can see that... > > Have a look at /usr/share/examples/drivers/make_device_driver.sh. Note > that this defaults to major 20, which is for local testing. Once you're > reasonably happy with your driver (and if you decide to give it away) > we can arrange a new number for you... Ok, I'll give that a go... My /usr/share/examples/drivers directory is kinda empty though - which distribution is the script in? One final question - If I write this under 2.2.2 - is it going to compile on 2.2.5 without any trouble? Thanks for your time, Karl From owner-freebsd-hackers Tue Dec 9 01:50:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA18635 for hackers-outgoing; Tue, 9 Dec 1997 01:50:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA18630 for ; Tue, 9 Dec 1997 01:50:12 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id BAA13352; Tue, 9 Dec 1997 01:43:05 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd013350; Tue Dec 9 01:42:57 1997 Date: Tue, 9 Dec 1997 01:40:29 -0800 (PST) From: Julian Elischer To: Karl Pielorz cc: hackers@freebsd.org Subject: Re: Writing Device drivers for 2.2.X etc' In-Reply-To: <348D0D1A.8D2531FE@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Ok, I'll give that a go... My /usr/share/examples/drivers directory is kinda > empty though - which distribution is the script in? get it from the website.. www.freebsd.org->support->CVS_Repository->src->share->examples->drivers does everything for you except drive your card. (ignore the comment about conf.c, it's no longer needed) > > One final question - If I write this under 2.2.2 - is it going to compile on > 2.2.5 without any trouble? yes and probably 3.0 as well > > > Thanks for your time, > > > Karl > From owner-freebsd-hackers Tue Dec 9 02:20:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA20761 for hackers-outgoing; Tue, 9 Dec 1997 02:20:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA20751 for ; Tue, 9 Dec 1997 02:20:07 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id CAA11350; Tue, 9 Dec 1997 02:19:44 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712091019.CAA11350@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Julian Elischer cc: Karl Pielorz , hackers@FreeBSD.ORG Subject: Re: Writing Device drivers for 2.2.X etc' In-reply-to: Your message of "Tue, 09 Dec 1997 01:40:29 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 1997 02:19:44 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, 3.0 drivers are slightly different than 2.x drivers. Cheers, Amancio > > > > Ok, I'll give that a go... My /usr/share/examples/drivers directory is kinda > > empty though - which distribution is the script in? > > get it from the website.. > www.freebsd.org->support->CVS_Repository->src->share->examples->drivers > > does everything for you except drive your card. > (ignore the comment about conf.c, it's no longer needed) > > > > One final question - If I write this under 2.2.2 - is it going to compile on > > 2.2.5 without any trouble? > yes and probably 3.0 as well > > > > > > > Thanks for your time, > > > > > > Karl > > > > From owner-freebsd-hackers Tue Dec 9 03:39:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA25206 for hackers-outgoing; Tue, 9 Dec 1997 03:39:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA25190 for ; Tue, 9 Dec 1997 03:38:57 -0800 (PST) (envelope-from abial@korin.warman.org.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with ESMTP id MAA09959; Tue, 9 Dec 1997 12:38:52 +0100 (CET) Date: Tue, 9 Dec 1997 12:38:51 +0100 (CET) From: Andrzej Bialecki To: =?ISO-8859-2?Q?Dag-Erling_Coidan_Sm=F8rgrav?= cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: isa.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 8 Dec 1997, Dag-Erling Coidan Smørgrav wrote: > Nate Williams writes: > > > > > > You'd be much better off upgrading to 2.2.5R, as I suspect his patches > > > > > > apply to that pretty cleanly. > > > > > I have a list of good reasons for not upgrading to 2.2.2R, and a > > > > > longer one for not upgrading to 2.2.5R. > > > > And those would be? > > > Amongst other items, lack of a suitable backup device > > No need to backup. It's a piece of cake to upgrade w/out doing a > > "Just download the sources" is easier said than done with a v34 modem. I have exactly such a modem, plus very noisy telephone line. What I did, though, was to install the sources from 2.2.1 CD-ROM and then run cvsup... It took me about an hour to catch up with -current, and it should take much less to catch up with -stable. So, I know this can be done quite easily :-) Andrzej Bialecki ---------------------+--------------------------------------------------------- abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. ---------------------+--------------------------------------------------------- From owner-freebsd-hackers Tue Dec 9 07:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA09144 for hackers-outgoing; Tue, 9 Dec 1997 07:20:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from chai.torrentnet.com (chai.torrentnet.com [207.87.46.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09132 for ; Tue, 9 Dec 1997 07:20:06 -0800 (PST) (envelope-from bakul@chai.torrentnet.com) Received: from chai.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by chai.torrentnet.com (8.8.6/8.8.5) with ESMTP id KAA09117; Tue, 9 Dec 1997 10:19:37 -0500 (EST) Message-Id: <199712091519.KAA09117@chai.torrentnet.com> To: Luigi Rizzo Cc: hackers@freebsd.org Subject: Re: Why FIONREAD has no dual for write ? In-reply-to: Your message of "Tue, 09 Dec 1997 05:57:11 +0100." <199712090457.FAA00305@labinfo.iet.unipi.it> Date: Tue, 09 Dec 1997 10:19:37 -0500 From: Bakul Shah Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Plus there are apps which want only to check the status of the queue in > > a descriptor without actually doing the I/O, for whatever reason they > > like. > > This can be handled by POLL{IN,OUT}_WM. > not sure how... if i get it right your changes can tell a process when > you can transfer x >= WM bytes, but gives no clue about the current status > of the queue. Much like the difference between Well, if you want to know _exactly_ how many bytes you can transfer without doing any IO, you are right that the changes I propose wouldn't help. But if you just want to know whether you can transfer atleast N bytes, they are fine. This is often good enough. Also note that FION{READ,WRITE} aren't precise either -- by the time you do actual IO more data may have been received/drained. [Just stating the obvious...] The idea behind high/low watermark is to introduce a _hysteresis_ effect. You want an advance notice about when buffers may get empty/full so that you can produce/consume sufficient data before they actually get empty/full. By choosing the watermarks judiciously you can *minimize* the overhead and still keep data flowing. This is something sorely missing from poll() and select(). -- bakul From owner-freebsd-hackers Tue Dec 9 07:41:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10875 for hackers-outgoing; Tue, 9 Dec 1997 07:41:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10859 for ; Tue, 9 Dec 1997 07:41:26 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id HAA00577; Tue, 9 Dec 1997 07:41:18 -0800 (PST) (envelope-from jdp) Message-Id: <199712091541.HAA00577@austin.polstra.com> To: shigio@wafu.netgate.net Subject: Re: [RFC] path converting functions. In-Reply-To: <199712032230.WAA28837@wafu.netgate.net> References: <199712032230.WAA28837@wafu.netgate.net> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Tue, 09 Dec 1997 07:41:18 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199712032230.WAA28837@wafu.netgate.net>, Shigio Yamaguchi wrote: > I've written a set of simple functions to perform conversions between > an absolute path name and a relative path name. > > Thoughts about this? > > o Are there any other functions that will do this? > o Is this useful? > o Is this the correct way to do it? > > ------------------------------------------------------------------------ > > abs2rel - make a relative path name from an absolute path name > > abs2rel(, , ); > > > /usr/src /etc ../usr/src Since your functions write into the user-supplied buffer "result", you should add an argument that specifies how big it is. See the gethostname() and snprintf() interfaces, for example. If you don't add a size argument to limit the number of characters written into the buffer, you're creating yet another potential security hole like gets(). An alternative would be to malloc the required amount of space within your new functions, and return a pointer to it. If you do that, be sure to document that the caller is responsible for freeing the space when he is done with it. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Tue Dec 9 08:06:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA12538 for hackers-outgoing; Tue, 9 Dec 1997 08:06:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mother.sneaker.net.au (akm@mother.sneaker.net.au [203.30.3.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA12513 for ; Tue, 9 Dec 1997 08:06:28 -0800 (PST) (envelope-from akm@mother.sneaker.net.au) Received: (from akm@localhost) by mother.sneaker.net.au (8.8.5/8.8.5) id DAA20863; Wed, 10 Dec 1997 03:16:04 +1100 (EST) From: Andrew Kenneth Milton Message-Id: <199712091616.DAA20863@mother.sneaker.net.au> Subject: Re: [RFC] path converting functions. To: jdp@polstra.com (John Polstra) Date: Wed, 10 Dec 1997 03:16:04 +1100 (EST) Cc: shigio@wafu.netgate.net, hackers@FreeBSD.ORG In-Reply-To: <199712091541.HAA00577@austin.polstra.com> from "John Polstra" at Dec 9, 97 07:41:18 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk +-----[ John Polstra ]------------------------------ | | In article <199712032230.WAA28837@wafu.netgate.net>, | Shigio Yamaguchi wrote: | | > | > abs2rel - make a relative path name from an absolute path name | > | > abs2rel(, , ); | > | > | > /usr/src /etc ../usr/src | | Since your functions write into the user-supplied buffer "result", | you should add an argument that specifies how big it is. And always return an error if they haven't allocated MAXPATHLEN :-) That'll teach 'em. -- ,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411 / \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233 \_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233 v NSW 2137 | Low cost Internet Solutions | From owner-freebsd-hackers Tue Dec 9 09:54:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA19438 for hackers-outgoing; Tue, 9 Dec 1997 09:54:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA19402; Tue, 9 Dec 1997 09:54:32 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA01192; Tue, 9 Dec 1997 17:53:48 +0100 From: Luigi Rizzo Message-Id: <199712091653.RAA01192@labinfo.iet.unipi.it> Subject: snd971209.tgz To: multimedia@freebsd.org Date: Tue, 9 Dec 1997 17:53:48 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk New snap of the code (snd971209.tgz) at http://www.iet.unipi.it/~luigi/FreeBSD.html While you are there, you might like to try the latest snapshot of my command-line telephone applications, tel971209.tgz SOUND DRIVER CHANGES: * the last two versions seemed to have problems with the SB16 when used in full duplex, or when switching between 8 and 16-bit operation. I have slightly modified the code in sb_dsp.c to try and fix problems. * I have made some enhancements to the vat module (audio-voxware.cc) for operation with the SB16 in full duplex, and to be able to send a pre-recorded file (ulaw only) instead of mic input. ABOUT TEL Tel is a command-line program which can be used as an internet telephone, or to listen to mbone multicasts. It does most things vat does, but with the convenience of use of a telephone (e.g. simple, one-keystroke commands for dial, answer, hangup, mute, input and volume setting...) and can be run from the command line. It can also be run as a daemon e.g. to set up live broadcasts without having to fire vat/rat on a graphic screen. Current version works with both my driver and Voxware driver; has support for PCM, DVI, GSM, LPC encoding; direct input and volume control with single-key commands; hightly improved playout queue adaptation algorithms; fixed operation with SB16 in full duplex; can use half-duplex cards for send-only or receive-only operation. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Dec 9 09:57:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA19720 for hackers-outgoing; Tue, 9 Dec 1997 09:57:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from chess.inetspace.com (chess.inetspace.com [206.50.163.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA19708 for ; Tue, 9 Dec 1997 09:57:17 -0800 (PST) (envelope-from kgor@chess.inetspace.com) Received: (from kgor@localhost) by chess.inetspace.com (8.8.5/8.8.5) id LAA01224; Tue, 9 Dec 1997 11:55:54 -0600 Date: Tue, 9 Dec 1997 11:55:54 -0600 Message-Id: <199712091755.LAA01224@chess.inetspace.com> From: "Kent S. Gordon" To: dag-erli@ifi.uio.no CC: nate@mt.sri.com, hackers@freebsd.org In-reply-to: (dag-erli@ifi.uio.no) Subject: Re: isa.c Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA19714 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "dag-erli" == Dag-Erling Coidan Smørgrav writes: > Nate Williams writes: >> > > > > You'd be much better off upgrading to 2.2.5R, as I >> suspect his patches > > > > apply to that pretty cleanly. > > >> > I have a list of good reasons for not upgrading to 2.2.2R, >> and a > > > longer one for not upgrading to 2.2.5R. > > And >> those would be? > Amongst other items, lack of a suitable >> backup device No need to backup. It's a piece of cake to >> upgrade w/out doing a > In my book, there is a difference between what is possible and > what is actually advisable. For instance, it is quite possible > to just switch your computer off when you're done, without > thrashing your file systems; however, most people prefer to quit > all applications, log out, and shut down properly, because they > want to be *sure* not to thrash their file systems. Similarly, > although it is possible to install 2.2.5 over 2.2.1 without any > problems, most people will prefer to back up their data first. > Some day, IMCFT, I'll try what you suggest, then 'accidentally' > screw up, lose everything, and watch you trying very hard not to > tell me I should have backed up. > By the way, one of the other items on my list is that I need to > repartition my hard drive. I'm sure you'll tell me I can do that > without backing up, too. >> backup/restore. Just download the sources, do a 'make world', >> re-config > "Just download the sources" is easier said than done with a v34 > modem. >> and install a new kernel, and reboot. A few hours work, but >> certainly not rocket science. > What if my system is slightly "customized", and things stop > working after the upgrade? Amongst other things, there is quite > a bit of brain damage in 2.2.1 boot scripts, which I have tried > to remedy by custom- izing said scripts. >> > and reports of degraded performance in 2.2.5R. I haven't >> seen many of those reports, and I haven't experienced any > I know people (*not* FOAFs, but real people with names and > faces) who have experienced quite serious problems, amongst > other things with SCSI performance, after upgrading from 2.2.1R > to 2.2.5R. Or worse, a machine that would no longer boot. This happened to me going from 2.2.2R to 2.2.5R. The machine in question now runs linux :(. This is documented in PR kern/4864. > -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * > cellular +47-92835919 * RFC1123: "Be liberal in what you accept, > and conservative in what you send" # unzip ; strip ; touch ; > finger ; mount ; fsck ; more ; yes ; umount ; sleep Kent S. Gordon Architect iNetSpace Co. voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com From owner-freebsd-hackers Tue Dec 9 13:20:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06488 for hackers-outgoing; Tue, 9 Dec 1997 13:20:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06480 for ; Tue, 9 Dec 1997 13:20:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA29367 for ; Tue, 9 Dec 1997 13:18:50 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd029360; Tue Dec 9 13:18:44 1997 Message-ID: <348DB51F.2D857063@whistle.com> Date: Tue, 09 Dec 1997 13:16:15 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: DEVFS/SLICE snapshot available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A tar file is available at: ftp://hub.freebsd.org/pub/scsi/slice3.tar.gz this shoudl be unpacked at /sys it will add a directry called 'slice' and a couple of other files. it will also unpack a diff file "slicedeffs" patch /dev/null 2>&1 this should just boot and run.... notes: 1/ I DO NOT YET SUPPORT DOS EXTENDED PARTITIONS.. 2/ IDE drives are less well tested than SCSI. please try.. I have been running under this code now for 2 weeks julian From owner-freebsd-hackers Tue Dec 9 14:13:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10842 for hackers-outgoing; Tue, 9 Dec 1997 14:13:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from home.gtcs.com (home.gtcs.com [206.54.69.238]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10825 for ; Tue, 9 Dec 1997 14:12:58 -0800 (PST) (envelope-from bruce@gtcs.com) Received: from gtcs.com (localhost.gtcs.com [127.0.0.1]) by home.gtcs.com (8.8.5/8.8.5) with ESMTP id PAA07923 for ; Tue, 9 Dec 1997 15:09:44 -0700 (MST) Disposition-Notification-To: bgingery@gtcs.com Message-Id: <199712092209.PAA07923@home.gtcs.com> Date: Tue, 9 Dec 1997 15:09:42 -0700 (MST) From: bgingery@gtcs.com Reply-To: bgingery@gtcs.com Subject: Re: blocksize on devfs entries (and related) To: hackers@FreeBSD.ORG In-Reply-To: <199712082322.PAA27177@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Elischer alerted: -> In spec_getpages() the size of the device's blocks is incorrectly -> deduced from the blocksize of the filesystem in which the device -> resided ... This so obvioously wrong that i'm not worried about -> whether it SHOULD be fixed, just HOW? [munch] -> How does this information GET to this location.? [munch] -> When a device is 'upgraded' to read-write from read-only, the vnode -> is consulted, to see it it is permissable, but the device itself is -> not notified fo the change. Theoretically, the physical layout of the device should be stored whether or not there's any filesystem on it. Besides, an optimizing filesystem may *not* match the parameters of the device. Slew, may be intrinsic on the device low-level formatting, or may be as high as the filesystem on it. Logical blocksize MAY or MAY NOT be a multiple or sub-multiple of the physical sector (or other block) size. With read-aheads and large device buffering, the optimal physical handling size for a device may be quite different from its basic blocksize, but constraints of a specific filesystem above that may cause it to need to store values that are NOT directly related to the device parameters. Yet, especially with slicing, each slice creation needs hardware info AND possibly enclosing slice info, both for the best slice arrangement and for passing through to a filesystem creation routine. I see this devfs as some departure from previous handling, and a move in the right direction. Yet, let's not loose anything that's there in the move, and let's try to take up anything that's been overlooked in the past. To me some answers to these ... 1. physical block/sector size needs to be stored by DEVICE this may or may not match the logical blocksize of any filesystem resident on the device. Optimal transfer blocksize for each of read and write ALSO need to be stored. 2. physical layout (sect/track, tracks/cyl) also needs to be stored for any DASD. Also any OTHER known info which may be used to optimize the filesystem building process for the device, such as rotational speed, seek timing .. If this is not stored with driver info in the devfs, then some pointer or common reference point should be made to the "file entry" that contains the info. 3. If at the controller level it is possible to concatinate or RAID join devices, that information needs to be stored for the device. If this is intrinsic to the device driver or the physical device - no matter. 4. If the device is "virtual", built on a vnode structure with variable-sized (or as is more common today, FIXED size) underlying file, this needs to be known. I don't think I've seen variable-sized-devices anyplace but on NeXT's old swapfile structure, yet. With various emulators, I can see this becoming a VERY useful thing. I've seen times recently when it would be handy to have a secondary swap in a variable-sized file, as primary swap is on my old NeXTcube! 5. Some kind of "relative timing" metric should be avaliable for the device, and separately for writing and reading. 6. When a device is opened ro, if the underlying hardware has ANY indication that it's a ro open, then if it is later upgraded there should at least be a hook for it to be notified that it has been upgraded. Current state (ro/rw) should be avaialable to user processes without "testing it by opening a write file" to a filesystem (or even raw device). Other thoughts. Especially WRT possible experimental work, and emulators, it will be QUITE convenient to have everything that can be used to optimize the construction of a filesystem (of any of many many kinds) or slice-out and construct a filesystem. As wine, dosemu and bochs (to just name three) expand the emulations supporting other OSs, being free with filesystems for those OSs, other than purely "native" becomes all the more important. SoftPC/SoftWindows and Bochs both create internally what amounts to a FAT filesystem within a file - a vnode filesystem, but not using system provisions for it. That pretty well eliminates "device" access to the filesystem and (e.g.) doing a mount_msdos on 'em for other processing and data exchange, without adapting the emulator's code to *parallel* what we've already got with FreeBSD. Ideally, wine, softpc, dosemu, bochs, mtools, and mount_msdos (etc) would have NO idea what the device is on where the FAT filesystem resides. That is not the business of that "layer". Similarly for a MINIX or OS/2 under bochs, etc, for the filesystem in use. These would not care if it's a whole drive somewhere, a slice of a drive, slice of a slice, or virtual filesystem that resides totally within a file in a UFS. Yet, why deny these the optimization information which will allow them to map (within the constraints of their architecture) a new filesystem for best throughput, if it's actually available. Now let me raise some additional questions -- Should a DASD be mappable ONLY with horizontal slices? With what we're all doing today, it seems that taking a certain number of cylinders for slices is best - but other access methods may find an underlying physical structure more convenient if a slice specifies a range of heads and cylinders that do NOT presume that all heads/cylinders from starting to ending according to physical layout are part of the same slice. It may be quite convenient to have a cluster of heads across physical devices forming a logical device or slice, without fully dedicating those physical devices to that use. And, I'll mention again, DISK formats are not the only random-access mass-storage formats on the horizon! I'm guessing that for speed of inclusion into product lines, all will emulate a disk drive - but that may not be the most efficient way of using them (in fact, probably not). They also can be expected to have "direct access" methods according to their physical architecture, with some form of tree-access the MOST efficient! Finally - one of the most powerful potentials of the devfs is handling non-DASD devices! The connecting or turning-on of a device (nic/fax/printer/external-modem/scanner/parallel-to-parallel conn- ection to another PC, even industrial controls of some kind) SHOULD cause it to "arrive". If its turn-on generates a signal that can be caught by a minimal driver, that may trigger a load of a full driver (arrival event) and its inclusion in the devfs listings. Similarly, killing such a device might trigger an immediate or delayed unloading of the same driver, and removal from the devfs. Bruce Gingery From owner-freebsd-hackers Tue Dec 9 14:30:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12588 for hackers-outgoing; Tue, 9 Dec 1997 14:30:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay2.smtp.psi.net (relay2.smtp.psi.net [38.8.188.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12544 for ; Tue, 9 Dec 1997 14:30:20 -0800 (PST) (envelope-from JHong@canoga.com) Received: from netmail.canoga.com by relay2.smtp.psi.net (8.8.5/SMI-5.4-PSI) id RAA29728; Tue, 9 Dec 1997 17:30:17 -0500 (EST) Received: by netmail.canoga.com with Internet Mail Service (5.0.1458.49) id ; Tue, 9 Dec 1997 14:20:34 -0800 Message-ID: <9A6665E753FAD011AF4C00A0C955B1070CEDF9@netmail.canoga.com> From: "Hong, Joo" To: "'freebsd-hackers@freebsd.org'" Subject: possible bug in sosend() function in uipc_soc.c Date: Tue, 9 Dec 1997 14:20:32 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I think this may be a bug in the following code. sosend() .............. ........................... mp = &m->m_next; if (resid <= 0) { if (flags & MSG_EOR) top->m_flags |= M_EOR; break; } } while (space > 0 && atomic); if (dontroute) so->so_options |= SO_DONTROUTE; s = splnet(); /* XXX */ error = (*so->so_proto->pr_usrreqs->pru_send)(so, (flags & MSG_OOB) ? PRUS_OOB : /* * If the user set MSG_EOF, the protocol * understands this flag and nothing left to * send then use PRU_SEND_EOF instead of PRU_SEND. */ ((flags & MSG_EOF) && (so->so_proto->pr_flags & PR_IMPLOPCL) && (resid <= 0)) ? PRUS_EOF : 0, top, addr, control, p); splx(s); if (dontroute) so->so_options &= ~SO_DONTROUTE; clen = 0; control = 0; top = 0; mp = ⊤ if (error) goto release; } while (resid && space > 0); } while (resid); release: sbunlock(&so->so_snd); out: if (top) m_freem(top); if (control) m_freem(control); return (error); } Let assume that there is a TCP connection. (*so->so_proto->pr_usrreqs->pru_send) will normally go to tcp_usr_send. Now if there is an error in the COMMON_START, tcp_usr_send will return with an error EINVAL. The above code check the error after the top and control variables have been set to zero. The m_freem(top) and m_freem(control) will not free any buffers and the buffers will be lost. From owner-freebsd-hackers Tue Dec 9 15:21:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16118 for hackers-outgoing; Tue, 9 Dec 1997 15:21:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16107 for ; Tue, 9 Dec 1997 15:21:33 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by seidata.com (8.8.8/8.8.5) with SMTP id SAA12109; Tue, 9 Dec 1997 18:21:18 -0500 (EST) Date: Tue, 9 Dec 1997 18:21:18 -0500 (EST) From: Mike To: kozmo killah cc: hackers@freebsd.org Subject: Re: Freebsd works on laptops? In-Reply-To: <19971209224818.11418.rocketmail@send1a.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Dec 1997, kozmo killah wrote: > if not linux company to sue, who? One term comes to mind here... procmail. --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com http://www.adept.org/apropos From owner-freebsd-hackers Tue Dec 9 15:43:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17998 for hackers-outgoing; Tue, 9 Dec 1997 15:43:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (root@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17977 for ; Tue, 9 Dec 1997 15:43:04 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id KAA00418; Tue, 9 Dec 1997 10:59:47 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Tue, 9 Dec 1997 10:59:10 -0500 (EST) From: "David E. Cross" To: "J. Weatherbee - Senior Systems Architect" cc: Andrew Atrens , hackers@FreeBSD.ORG Subject: Re: dealing with zombies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 8 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > > As I recall under linux setting up a signal handler that excutes waitpid() > is not necessary if you are set (by default) to ignore SIGCHLD. I believe that is true under POSIX. > On 8 Dec 1997, Andrew Atrens wrote: > > > Hi All, > > > > I'm eval'ing Wordperfect-7.0-for-Linux on `FreeBSD 3.0-971012-SNAP' and am > > seeing lots of zombies: > > > > 1446 ?? Z 0:00.00 (xwpthes) > > 1460 ?? Z 0:00.00 (xwpgmk5) > > 1461 ?? Z 0:00.00 (xwpspell) > > 1462 ?? Z 0:00.00 (xwpspell) > > 1467 ?? Z 0:00.00 (wpp7) > > 1471 ?? Z 0:00.00 (xwpspell) > > 1472 ?? Z 0:00.00 (xwpspell) > > 1473 ?? Z 0:00.00 (xwpspell) > > 1513 ?? Z 0:00.00 (xwpthes) > > 1514 ?? Z 0:00.00 (xwpthes) > > 1531 ?? Z 0:00.00 (xwpthes) > > 1532 ?? Z 0:00.00 (xwpthes) > > 1533 ?? Z 0:00.00 (xwpthes) > > 1543 ?? Z 0:00.00 (xwpthes) > > 1551 ?? Z 0:00.00 (xwpthes) > > > > As I understand, the root cause is that (xwp) is failing to reap dead children. > > However, the children *do* get reaped when I exit xwp... it seems that > > as long as xwp is running, no reaping is done, and the zombies accumulate...:( > > > > What I'm wondering is: > > > > i. Is this a fault/feature of the app (xwp), the linux emulation code, or > > the kernel (in a larger sense), and > > ii. are there any *good* workarounds. ( I seem to recall some discussion about > > a tunable kernel parm for auto-reap or some such thing? ) What actually happens is when xwp exists the 'parent' process dies, this causes the PPID of the children to be set to '1' (init). init is always in a loop that reaps the exit code of all of its children. Since the orphaned xwp processes have been 'adopted' by init, all those procs go away. (Sorry if this has already been said... my net connection has been down since 1:00am.) -- David Cross From owner-freebsd-hackers Tue Dec 9 15:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18860 for hackers-outgoing; Tue, 9 Dec 1997 15:50:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18802 for ; Tue, 9 Dec 1997 15:49:56 -0800 (PST) (envelope-from shigio@wafu.netgate.net) Received: from chiota.signet.or.jp (INS54.tama.dti.ne.jp [210.159.144.8]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id PAA11441; Tue, 9 Dec 1997 15:52:01 GMT Message-Id: <199712091552.PAA11441@wafu.netgate.net> Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id IAA00366; Wed, 10 Dec 1997 08:46:14 +0900 (JST) To: Andrew Kenneth Milton cc: shigio@wafu.netgate.net, hackers@FreeBSD.ORG Subject: Re: [RFC] path converting functions. In-reply-to: Message from Andrew Kenneth Milton Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk of "Wed, 10 Dec 1997 03:16:04 +1100." <199712091616.DAA20863@mother.sneaker.net.au> Date: Wed, 10 Dec 1997 08:46:14 +0900 From: Shigio Yamaguchi > +-----[ John Polstra ]------------------------------ > | > | In article <199712032230.WAA28837@wafu.netgate.net>, > | Shigio Yamaguchi wrote: > | > | > > | > abs2rel - make a relative path name from an absolute path name > | > > | > abs2rel(, , ); > | > > | > > | > /usr/src /etc ../usr/src > | > | Since your functions write into the user-supplied buffer "result", > | you should add an argument that specifies how big it is. > > And always return an error if they haven't allocated MAXPATHLEN :-) > That'll teach 'em. In realpath(3) style, it is user's responsibility to allocate a buffer capable of storing at least MAXPATHLEN characters. When generated path name is longer than MAXPATHLEN - 1, abs2rel and rel2abs returns -1 and set errno = ENAMETOOLONG. -- Shigio Yamaguchi (Freelance programmer) Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Tue Dec 9 15:50:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18878 for hackers-outgoing; Tue, 9 Dec 1997 15:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18808 for ; Tue, 9 Dec 1997 15:49:58 -0800 (PST) (envelope-from shigio@wafu.netgate.net) Received: from chiota.signet.or.jp (INS54.tama.dti.ne.jp [210.159.144.8]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id PAA11445; Tue, 9 Dec 1997 15:52:05 GMT Message-Id: <199712091552.PAA11445@wafu.netgate.net> Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id IAA00330; Wed, 10 Dec 1997 08:34:26 +0900 (JST) To: John Polstra cc: shigio@wafu.netgate.net, hackers@freebsd.org Subject: Re: [RFC] path converting functions. In-reply-to: Message from John Polstra of "Tue, 09 Dec 1997 07:41:18 PST." <199712091541.HAA00577@austin.polstra.com> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Date: Wed, 10 Dec 1997 08:34:25 +0900 From: Shigio Yamaguchi > Since your functions write into the user-supplied buffer "result", > you should add an argument that specifies how big it is. See the > gethostname() and snprintf() interfaces, for example. > The result argument must refer to a buffer capable of storing at least MAXPATHLEN characters. This is the way of realpath(3). SYNOPSIS #include char * abs2rel(const char *path, const char *base, char result[MAXPATHLEN]) If generated path name becomes longer than MAXPATHLEN - 1, abs2rel and rel2abs returns -1 and set errno = ENAMETOOLONG. -- Shigio Yamaguchi (Freelance programmer) Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Tue Dec 9 16:05:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20338 for hackers-outgoing; Tue, 9 Dec 1997 16:05:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20311 for ; Tue, 9 Dec 1997 16:04:59 -0800 (PST) (envelope-from shigio@wafu.netgate.net) Received: from chiota.signet.or.jp (INS65.tama.dti.ne.jp [210.159.144.19]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id QAA11648; Tue, 9 Dec 1997 16:05:29 GMT Message-Id: <199712091605.QAA11648@wafu.netgate.net> Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id JAA00509; Wed, 10 Dec 1997 09:02:57 +0900 (JST) To: hackers@freebsd.org Cc: shigio@wafu.netgate.net Subject: I have mistaken. ([RFC] path converting functions.) Date: Wed, 10 Dec 1997 09:02:56 +0900 From: Shigio Yamaguchi Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have mistaken about the URL of abs2rel and rel2abs. abs2rel and rel2abs (source code and online manual) are available on http://wafu.netgate.net/tama/unix/indexe.html#pathconvertc Followings are wrong. Message-Id: <199712032230.WAA28837@wafu.netgate.net> > >abs2rel and rel2abs (source code and online manual) are available on > > http://wafu.netgate.net/tama/indexe.html#pathconvertc > I'm sorry. -- Shigio Yamaguchi (Freelance programmer) Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Tue Dec 9 16:21:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA21682 for hackers-outgoing; Tue, 9 Dec 1997 16:21:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA21676 for ; Tue, 9 Dec 1997 16:21:20 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01809 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:21:14 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA04827; Wed, 10 Dec 1997 01:13:24 +0100 (MET) Date: Wed, 10 Dec 1997 01:13:24 +0100 (MET) Message-Id: <199712100013.BAA04827@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> <863ek4p1tx.fsf_-_@bitbox.follo.net> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund wrote: > "New option model" refers to the opt_* header files, I guess? Yep, so Makefile dependencies will work. > Are there anything more that should be done here than the following > two steps? > > (1) weeding LINT against /sys/conf/options and > /sys/i386/conf/options.i386 to find what options are not currently > handled. Hmm, as your example proves, LINT contains a lot of garbage. :) The most problematic thing about this are those options that you can currently still find as -DFOO -DBAR if you compile GENERIC (INET, FFS). You have to walk throughout the entire code, and fix wrong #ifdefs. Except for a few things like #ifdef _KERNEL (still misspelled as #ifdef KERNEL in FreeBSD), #ifdef's should be mostly banned from .h files. j@uriah 469% fgrep -h #ifdef /sys/sys/*.h | fgrep -v KERNEL | sort -u #ifdef DKTYPENAMES #ifdef SIGPROP #ifdef _BSD_CLOCKID_T_ #ifdef _BSD_CLOCK_T_ #ifdef _BSD_SIZE_T_ #ifdef _BSD_SSIZE_T_ #ifdef _BSD_TIMER_T_ #ifdef _BSD_TIME_T_ #ifdef _NOT_AVAILABLE #ifdef _THREAD_SAFE #ifdef __GNUC__ #ifdef COMPAT_43 #ifdef COMPAT_SUNOS #ifdef DEBUG_VFS_LOCKS #ifdef DIAGNOSTIC #ifdef DISKSORT_STATS #ifdef DKTYPENAMES #ifdef GPROF4 #ifdef KLD_DEBUG #ifdef LFS #ifdef LOCKF_DEBUG #ifdef MALLOC_DECLARE #ifdef MALLOC_INSTANTIATE #ifdef MAXPARTITIONS /* XXX don't depend on disklabel.h */ #ifdef MOD_DEBUG #ifdef PC98 #ifdef PGINPROF #ifdef PPS_SYNC #ifdef PRCOREQUESTS #ifdef PRCREQUESTS #ifdef PRUREQUESTS #ifdef PSEUDO_LKM #ifdef SIMPLELOCK_DEBUG #ifdef SMP #ifdef SYSLOG_NAMES #ifdef TTYDEFCHARS #ifdef USE_OLD_TTY #ifdef VFS_LKM #ifdef _NEW_VFSCONF #ifdef _POSIX_SOURCE #ifdef __FreeBSD__ #ifdef __GNUC__ #ifdef __STDC__ #ifdef __i386__ #ifdef notdef #ifdef notyet Without looking further, i would assume that at least one third of the above is wrong. Wrong #ifdefs in headers break LKM options. > /sys/i386/conf/LINT: COMPAT_43 Another sucker, but probably easier to fix. > /sys/i386/conf/LINT: DEBUG Should not be an option, it's got too many different meanings. ;) > /sys/i386/conf/LINT: FDSEEKWAIT Ick, that's in my area. I think this turned into a non-option over time... > /sys/i386/conf/LINT: SUIDDIR Another one that has recently been added, where the developer didn't bother to do it right from the beginning... -- 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 Dec 9 16:26:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22300 for hackers-outgoing; Tue, 9 Dec 1997 16:26:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22266 for ; Tue, 9 Dec 1997 16:25:58 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01861 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:25:44 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04738; Wed, 10 Dec 1997 00:36:02 +0100 (MET) Date: Wed, 10 Dec 1997 00:36:02 +0100 (MET) Message-Id: <199712092336.AAA04738@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: I seriously need some networking help X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jamil J. Weatherbee" wrote: > .., it is > possible for ed0 to have a different ip address than ed1 but router0 must > believe that it is on the windoze ethernet and the windoze ethernet must > believe that router0 is local to it. Nope, all IP interfaces on one machine must be in different IP networks. (The only exception: for p2p interfaces (SLIP, PPP), the IP address of the remote end counts, while the local one can be duplicated.) For me, it would seem to be best to use a 192.168.something net between router0 and the FreeBSD packet filter, but of course, this requires some minor reconfiguration on router0 (which turns into a major reconfiguration since router0 happens to be an Ascend P50, which has a rather confusing terminology and setup screens when it comes to something like this -- been there last week, done that). Note that the WAN-side IP address of router0 would remain unaffected by this, so there's not much visible about this reconfiguration from your ISP's point of view, except traceroute will trace one additional gateway with some 192.168 address. Failing this, maybe you could do some cute and clever tricks with divert sockets, natd, and explicit host routing out an Ethernet interface, but all this looks rather hacky compared to the above `transit network' solution. -- 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 Dec 9 16:27:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22495 for hackers-outgoing; Tue, 9 Dec 1997 16:27:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22451 for ; Tue, 9 Dec 1997 16:27:00 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01889 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:26:28 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04760; Wed, 10 Dec 1997 00:46:01 +0100 (MET) Date: Wed, 10 Dec 1997 00:46:01 +0100 (MET) Message-Id: <199712092346.AAA04760@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Anybody heard of fgetwpent() and putpwent()? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Mott wrote: > Just checked and I see these on Linux, Solaris and OSF. I once held a small paper about all these functions (and even posted the survey in the German Usenet, but that's been years ago). The outcome was that it's hard to find two systems offering a common set of functions, once you consider things like shadow password files, or 4.4BSD's .db files. (For read-only access, i still find 4.4BSD's solution the most elegant, where there's no additional set of functions to access the shadow database, but the selection is done automatically based upon the EUID of the process.) I think David Nugent's pw(8) is the better option in FreeBSD, and it's at least API-lookalike to Solaris. -- 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 Dec 9 16:27:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22535 for hackers-outgoing; Tue, 9 Dec 1997 16:27:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22510 for ; Tue, 9 Dec 1997 16:27:17 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01899 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:27:09 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04778; Wed, 10 Dec 1997 00:51:25 +0100 (MET) Date: Wed, 10 Dec 1997 00:51:25 +0100 (MET) Message-Id: <199712092351.AAA04778@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712051453.GAA24838@super.zippo.com> <19971205093805.56784@hydrogen.nike.efn.org> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Why so many steps to build new kernel? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John-Mark Gurney wrote: > why not simply use the && pipeline operator for this?? this is what > it is most commonly used for... We are Unix, you could even simply typeahead the next input, trusting that all the steps before would have worked. ;-) Recompiling an entire kernel also takes quite a few minutes on my machine, that's why i've nuked the entire code to remove the old compile directory out of /usr/src/usr.sbin/config/. j@uriah 463% config -n SOMETHING Warning: option -n is obsolete. :-) -- 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 Dec 9 16:28:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22694 for hackers-outgoing; Tue, 9 Dec 1997 16:28:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22664 for ; Tue, 9 Dec 1997 16:28:01 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01910 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:27:28 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04792; Wed, 10 Dec 1997 00:56:26 +0100 (MET) Date: Wed, 10 Dec 1997 00:56:26 +0100 (MET) Message-Id: <199712092356.AAA04792@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: The 'Stable' status of freeBSD-stable X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "David E. Cross" wrote: > On that note, has Intel's further nasty abomination^W^W^Wpatch be commited > to 2.2.5-stable yet... I looked for it in the LINT kernel, but could not > find it. That's because the original committer choose to not commit any hint to the LINT file. He only committed the code (including 2.2-stable). -- 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 Dec 9 16:28:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22751 for hackers-outgoing; Tue, 9 Dec 1997 16:28:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22705 for ; Tue, 9 Dec 1997 16:28:10 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01922 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:28:04 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04799; Wed, 10 Dec 1997 00:59:18 +0100 (MET) Date: Wed, 10 Dec 1997 00:59:18 +0100 (MET) Message-Id: <199712092359.AAA04799@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712061054.LAA25661@labinfo.iet.unipi.it> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Why FIONREAD has no dual for write ? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo wrote: > There is no FIONWRITE call (how many bytes you can write before > blocking) which would be nice to have, instead of having to resort to > non-blocking writes. I think estimating this number is much harder than FIONREAD: for the read case, you do already know how much you've got. For the write case, you can only estimate, but perhaps have to predict a lot of potential allocation policy (the implementation might chose to allocate more buffer space for some reason). I get your point though, the above is just guessing... -- 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 Dec 9 16:54:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA24744 for hackers-outgoing; Tue, 9 Dec 1997 16:54:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA24725 for ; Tue, 9 Dec 1997 16:54:19 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA02391 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:54:16 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA05177; Wed, 10 Dec 1997 01:49:03 +0100 (MET) Date: Wed, 10 Dec 1997 01:49:03 +0100 (MET) Message-Id: <199712100049.BAA05177@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: dealing with zombies X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "David E. Cross" wrote: >> As I recall under linux setting up a signal handler that excutes waitpid() >> is not necessary if you are set (by default) to ignore SIGCHLD. > I believe that is true under POSIX. Posix would never be that specific about a religious detail. ;-) Posix IMHO allows for this option, but it's of course not mandatory to be the default. If i'm not very mistaken, Linux is the only system where the default is to ignore dead children (and that's supposedly still Posix-compliant). SysV defaults to not ignore them, but can be turned to ignore them using Posix-style sigaction() with SA_NOCLDWAIT, or by using legacy signal() with SIG_IGN. FreeBSD (-current) can be turned to ignore them using Posix-style sigaction() with SA_NOCLDWAIT. Truely compliant software always needs to install a handler for SIGCHLD, unless it finds the definition of SA_NOCLDWAIT so it could set this. Everything else is `implementation-defined'. Of course, since the Linuxulator aims to emulate Linux behaviour, it would do best by changing its default signal behaviour. -- 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 Dec 9 17:05:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25635 for hackers-outgoing; Tue, 9 Dec 1997 17:05:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA25602 for ; Tue, 9 Dec 1997 17:05:14 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01819 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 01:21:28 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA04837; Wed, 10 Dec 1997 01:17:42 +0100 (MET) Date: Wed, 10 Dec 1997 01:17:42 +0100 (MET) Message-Id: <199712100017.BAA04837@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712082025.MAA07048@hub.freebsd.org> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: dealing with zombies X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "J. Weatherbee - Senior Systems Architect" wrote: > As I recall under linux setting up a signal handler that excutes waitpid() > is not necessary if you are set (by default) to ignore SIGCHLD. FreeBSD now also supports `automatic' reaping of zombies, but it's not the default. Linux is about the only system where this is default (on SysV, signal(SIGCLD, SIGDFL) != signal(SIGCLD, SIG_IGN)), so it's in the responsibility of the Linuxulator to emulate this default in the Linux environment. -- 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 Dec 9 17:05:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25726 for hackers-outgoing; Tue, 9 Dec 1997 17:05:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA25653 for ; Tue, 9 Dec 1997 17:05:28 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA01834; Wed, 10 Dec 1997 01:21:43 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA04725; Wed, 10 Dec 1997 00:28:38 +0100 (MET) Date: Wed, 10 Dec 1997 00:28:38 +0100 (MET) Message-Id: <199712092328.AAA04725@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <97Dec4.180459jst.51965@ns.isi.co.jp> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: HP 6020 CD-R Drive compatibility X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@FreeBSD.ORG Cc: john cooper Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk john cooper wrote: > 1. Any chance the CD-R SCSI command set for the 71*0 is compatible > with the 6020/4020? I'm only interested in CD-R at the moment. Unlikely, but you gotta ask HP for this. We've got a Plasmon 4801 offered today (on behalf of a customer), this one looks more in line with their previous drives... but i haven't seen the documentation yet, either. > 2. Any chance the FreeBSD driver/wormcontrol has been updated to > support the 71*0? Nope. > And while I have the floor.. Has anyone extended the worm > driver/wormcontrol to support other drives/vendors? Only very slowly. You could also have a look at Joerg Schilling's cdrecord tool, it's in the ports collection, and basically bypasses the kernel driver. -- 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 Dec 9 17:25:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27437 for hackers-outgoing; Tue, 9 Dec 1997 17:25:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA27418 for ; Tue, 9 Dec 1997 17:24:52 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt1-40.HiWAAY.net [208.147.147.40]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id TAA21362 for ; Tue, 9 Dec 1997 19:24:36 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id TAA26461 for ; Tue, 9 Dec 1997 19:24:12 -0600 (CST) Message-Id: <199712100124.TAA26461@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG From: David Kelly Subject: Re: Why so many steps to build new kernel? In-reply-to: Message from j@uriah.heep.sax.de (J Wunsch) of "Wed, 10 Dec 1997 00:51:25 +0100." <199712092351.AAA04778@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 1997 19:24:11 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > John-Mark Gurney wrote: > > > why not simply use the && pipeline operator for this?? this is what > > it is most commonly used for... > > We are Unix, you could even simply typeahead the next input, trusting > that all the steps before would have worked. ;-) Whats wrong with "make depend kernel install"? That's what I've been doing. It appears to make those targets in order specified and aborts once one fails. As for the config step, it could be worse, it could be Linux. :-) Actually its been so long since I built a Linux kernel that I forgot how it was done. Hasn't been long enough for me to forget that one *had* to build a custom Linux kernel in order to get a functional mix of the right device drivers for your system. Hopefully (for Linux) that has changed by now. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Tue Dec 9 17:32:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28240 for hackers-outgoing; Tue, 9 Dec 1997 17:32:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA28224 for ; Tue, 9 Dec 1997 17:32:23 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id RAA14658; Tue, 9 Dec 1997 17:32:14 -0800 (PST) (envelope-from jamil@acroal.com) Date: Tue, 9 Dec 1997 17:32:13 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Joerg Wunsch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help In-Reply-To: <199712092336.AAA04738@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I attempted making the firewall to router link a 192.168.x.x network, and using dual ip on it, unfortunately it interesting that the link gets published by traceroute for instance from the outside world. But 192.168.x.x is certainly not routable, anyway the lack of seemlessness bothered the hell out of me so I took it down (what I really wanted was what pppd does with the -alias option, but too the pipeline. Seems possible, just not supported since that ethernet is just a fast serial port for me (crossover)) anyway I got my isp to give me an 8 ip address network for the link, in my opinion a waste of yet another 8 ip addresses! I guess this is why people buy pipelines with the firewalling option, oh well. On Wed, 10 Dec 1997, J Wunsch wrote: > "Jamil J. Weatherbee" wrote: > > > .., it is > > possible for ed0 to have a different ip address than ed1 but router0 must > > believe that it is on the windoze ethernet and the windoze ethernet must > > believe that router0 is local to it. > > Nope, all IP interfaces on one machine must be in different IP > networks. (The only exception: for p2p interfaces (SLIP, PPP), the IP > address of the remote end counts, while the local one can be > duplicated.) > > For me, it would seem to be best to use a 192.168.something net > between router0 and the FreeBSD packet filter, but of course, this > requires some minor reconfiguration on router0 (which turns into a > major reconfiguration since router0 happens to be an Ascend P50, which > has a rather confusing terminology and setup screens when it comes to > something like this -- been there last week, done that). Note that > the WAN-side IP address of router0 would remain unaffected by this, so > there's not much visible about this reconfiguration from your ISP's > point of view, except traceroute will trace one additional gateway > with some 192.168 address. > > Failing this, maybe you could do some cute and clever tricks with > divert sockets, natd, and explicit host routing out an Ethernet > interface, but all this looks rather hacky compared to the above > `transit network' solution. > > -- > 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 Dec 9 17:37:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28903 for hackers-outgoing; Tue, 9 Dec 1997 17:37:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA28896 for ; Tue, 9 Dec 1997 17:37:48 -0800 (PST) (envelope-from k0zm0z@yahoo.com) Message-ID: <19971210013735.7488.rocketmail@send1b.yahoomail.com> Received: from [207.155.93.60] by send1b; Tue, 09 Dec 1997 17:37:35 PST Date: Tue, 9 Dec 1997 17:37:35 -0800 (PST) From: kozmo killah Subject: Re: Freebsd works on laptops? To: Mike Cc: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---Mike wrote: > > On Tue, 9 Dec 1997, kozmo killah wrote: > > > if not linux company to sue, who? > > One term comes to mind here... procmail. thx, will the procmail ppl help to work in legal defense to linux company my lawsuit? _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-freebsd-hackers Tue Dec 9 18:50:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04480 for hackers-outgoing; Tue, 9 Dec 1997 18:50:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04470 for ; Tue, 9 Dec 1997 18:50:47 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id SAA15133; Tue, 9 Dec 1997 18:48:04 -0800 (PST) (envelope-from jamil@acroal.com) Date: Tue, 9 Dec 1997 18:48:04 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: David Kelly cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-Reply-To: <199712100124.TAA26461@nospam.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On this topic. I don't care for Linux (Too Unreliable), but theyv'e had a curses based configuration tool as part of the sources since v 2.0. It is kind of nice since it lets you choose what hardware support you want to compile in and even some port variables etc. > As for the config step, it could be worse, it could be Linux. :-) > Actually its been so long since I built a Linux kernel that I forgot how > it was done. Hasn't been long enough for me to forget that one *had* to > build a custom Linux kernel in order to get a functional mix of the > right device drivers for your system. Hopefully (for Linux) that has > changed by now. From owner-freebsd-hackers Tue Dec 9 18:51:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04572 for hackers-outgoing; Tue, 9 Dec 1997 18:51:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04556 for ; Tue, 9 Dec 1997 18:51:52 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA10852; Tue, 9 Dec 1997 20:03:48 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd010725; Tue Dec 9 20:03:36 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA02468; Tue, 9 Dec 1997 19:51:06 -0700 (MST) From: Terry Lambert Message-Id: <199712100251.TAA02468@usr06.primenet.com> Subject: Re: [hackers:] Architectural advice needed To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 10 Dec 1997 02:51:06 +0000 (GMT) Cc: nate@mt.sri.com, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <12036.881631607@time.cdrom.com> from "Jordan K. Hubbard" at Dec 8, 97 05:40:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You can lead a horse to water... :) But if you can get him to float on his back, then you really have something. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Dec 9 18:58:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05146 for hackers-outgoing; Tue, 9 Dec 1997 18:58:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (seoul-194.ppp.hooked.net [206.169.228.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA05132 for ; Tue, 9 Dec 1997 18:58:01 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.8/8.8.7) with SMTP id SAA01047; Tue, 9 Dec 1997 18:58:46 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 9 Dec 1997 18:58:45 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Andrzej Bialecki cc: hackers@freebsd.org Subject: Re: isa.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Dec 1997, Andrzej Bialecki wrote: > > "Just download the sources" is easier said than done with a v34 modem. > > I have exactly such a modem, plus very noisy telephone line. What I did, > though, was to install the sources from 2.2.1 CD-ROM and then run cvsup... > It took me about an hour to catch up with -current, and it should take > much less to catch up with -stable. > > So, I know this can be done quite easily :-) It's not so bad, cvsup will easily resume everything if you for some reason get interrupted. Hell you could (if you really wanted) do about 3 minutes a day, and it'd still work. - alex From owner-freebsd-hackers Tue Dec 9 19:00:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05401 for hackers-outgoing; Tue, 9 Dec 1997 19:00:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA05370 for ; Tue, 9 Dec 1997 19:00:05 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA12711; Tue, 9 Dec 1997 20:11:59 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd012637; Tue Dec 9 20:11:41 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA02985; Tue, 9 Dec 1997 19:59:12 -0700 (MST) From: Terry Lambert Message-Id: <199712100259.TAA02985@usr06.primenet.com> Subject: Re: Process scheduling: nice does not work ??? To: chuckr@glue.umd.edu (Chuck Robey) Date: Wed, 10 Dec 1997 02:59:11 +0000 (GMT) Cc: tlambert@primenet.com, jonny@coppe.ufrj.br, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Dec 8, 97 09:53:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Standard UNIX priorities work like this: [ ... ] > I thought, Terry, that the effective priority slowly raised itself, with > the length of time that it hadn't been run. The scheme you describe means > that anything set to 19 never gets run at all, if there's a 20 (in fact I > think the numbers are backwords, anyhow). Thats not the way I thought it > was. The numbers are backwards, yes. > > Note: these are base priorities, which the system will adjust based on ********************************************************************** > > I/O vs. CPU utilization. *********************** Look at the PRI values in the original posting. The NI values are irrelevant, no mattery his intent. If he wanted to "lock" priorities, he need to use rtprio. Otherwise, the scheduler will drift them as it sees fit. IMO, Linux is implementing a "fairness" algorithm based on the NI value; this is not traditional UNIX behaviour. It may favor interactive over batch response. Note that he was running, effectively, batch processes; this was my understanding the last time I looked at the Linux scheduler. I think Linux is wrong, FWIW. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Dec 9 19:12:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06481 for hackers-outgoing; Tue, 9 Dec 1997 19:12:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA06460 for ; Tue, 9 Dec 1997 19:12:33 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id UAA21264; Tue, 9 Dec 1997 20:16:30 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd021248; Tue Dec 9 20:16:27 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id UAA04169; Tue, 9 Dec 1997 20:11:57 -0700 (MST) From: Terry Lambert Message-Id: <199712100311.UAA04169@usr06.primenet.com> Subject: Re: Why FIONREAD has no dual for write ? To: bakul@torrentnet.com (Bakul Shah) Date: Wed, 10 Dec 1997 03:11:57 +0000 (GMT) Cc: luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG In-Reply-To: <199712091519.KAA09117@chai.torrentnet.com> from "Bakul Shah" at Dec 9, 97 10:19:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [Just stating the obvious...] The idea behind high/low > watermark is to introduce a _hysteresis_ effect. You want an > advance notice about when buffers may get empty/full so that > you can produce/consume sufficient data before they actually > get empty/full. By choosing the watermarks judiciously you > can *minimize* the overhead and still keep data flowing. > This is something sorely missing from poll() and select(). The problem with doing this is that it should be up to the driver, not up to the user. The problem here is that what you are really describing is "pool retention time", and that varies based on the driver, and based on compute overhead per polling period. So once again, the user space code isn't portable. I suppose you could ask the driver what it preferred, but then why not make the driver act that way by default. I think all this attempt to move batching into the kernel only makes things too complicated. Even if the driver says "I can accept N bytes *now*", by the time you send the bytes, it may be well past "now". The driver *must* rely on private buffer resources in order to be able to make any guarantees. As far as how many bytes it can accept when it says it can accept bytes... dev_bsize seems to me to be the obvious answer. At worst, you should consider using readv/writev. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Dec 9 19:20:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07271 for hackers-outgoing; Tue, 9 Dec 1997 19:20:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07264 for ; Tue, 9 Dec 1997 19:20:43 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA14226; Tue, 9 Dec 1997 20:18:05 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd014183; Tue Dec 9 20:17:54 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id UAA03733; Tue, 9 Dec 1997 20:05:26 -0700 (MST) From: Terry Lambert Message-Id: <199712100305.UAA03733@usr06.primenet.com> Subject: Re: Why FIONREAD has no dual for write ? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 10 Dec 1997 03:05:26 +0000 (GMT) Cc: bakul@torrentnet.com, hackers@FreeBSD.ORG In-Reply-To: <199712090457.FAA00305@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 9, 97 05:57:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Perhaps one solution is to add an ioctl to set high/low > > watermarks on a device and add new event bits POLLIN_WM and > > POLLLOUT_WM for the poll() syscall. > > Good idea, this could solve the blocksize problem rather elegantly > (although with some portability problems...). I still believe that this is the responsibility of the driver. If the driver owns a double buffer instead of relying on system owned resources only "loaned" to it, then it will be able to be written in buffer size chunks, or not at all. This neatly resolves the portability issues, and places the onus for driver behaviour where it rightly belongs: with the driver. Screwing with these watermarks still puts the onus on the driver to allocate the system resources before it can answer your select() "yes, writeable". Since the onus is there anyway, why make the programatic interface both more complex (for no visible gain) and less portable (for no visible gain)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Dec 9 20:15:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA11368 for hackers-outgoing; Tue, 9 Dec 1997 20:15:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from send1a.yahoomail.com (send1a.yahoomail.com [205.180.60.22]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA11332 for ; Tue, 9 Dec 1997 20:15:16 -0800 (PST) (envelope-from k0zm0z@yahoo.com) Message-ID: <19971209224818.11418.rocketmail@send1a.yahoomail.com> Received: from [207.155.93.60] by send1a; Tue, 09 Dec 1997 14:48:18 PST Date: Tue, 9 Dec 1997 14:48:18 -0800 (PST) From: kozmo killah Subject: Re: Freebsd works on laptops? To: Mike Cc: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk but how to make amend for many damage cause me by linux company and malicious product which is very crappy to make laptop explode like that? if not linux company to sue, who? the freebsd would not make to explode the laptop no? i must works to warned other users how linux company makes to destroy computers and life of users. is anyone know how to sue linux company? ---Mike wrote: > > On Mon, 8 Dec 1997, kozmo killah wrote: > > > well i must know, i am plan to sue the linux company > > for breaking my laptop computer and to cause much grief > > and pain to me. > > Last time I checked, there were no guarantees on Linux... of course, last > time I checked, Linux couldn't cause the problems you spoke of... Unless > you tried to run X-Window (X11) and specificed incorrect video settings or > did some other sort of harmful probe... Regardless, "linux company" will > not reimburse anyone for anything. It's a "use at your own risk" world. > > --- > Mike Hoskins mike@seidata.com > SEI Data Network Services, Inc. http://www.adept.org/apropos > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-freebsd-hackers Tue Dec 9 20:17:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA11744 for hackers-outgoing; Tue, 9 Dec 1997 20:17:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA11737 for ; Tue, 9 Dec 1997 20:17:41 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id UAA19215; Tue, 9 Dec 1997 20:17:19 -0800 (PST) To: "J. Weatherbee - Senior Systems Architect" cc: David Kelly , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Tue, 09 Dec 1997 18:48:04 PST." Date: Tue, 09 Dec 1997 20:17:18 -0800 Message-ID: <19212.881727438@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On this topic. I don't care for Linux (Too Unreliable), but theyv'e had a > curses based configuration tool as part of the sources since v 2.0. > It is kind of nice since it lets you choose what hardware support you want > to compile in and even some port variables etc. We know, and have for a long time, about Linux's curses and X based kernel configurators. Who's going to do the work of implementing something similar? *That's* been the big mystery up until now. :) Jordan From owner-freebsd-hackers Tue Dec 9 21:15:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16287 for hackers-outgoing; Tue, 9 Dec 1997 21:15:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mailgate32 (mailgate32-hme0.a001.sprintmail.com [205.137.196.58]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA16281 for ; Tue, 9 Dec 1997 21:15:22 -0800 (PST) (envelope-from andreleclaire@sprintmail.com) Received: by mailgate32 (SMI-8.6/SMI-SVR4) id VAA21697; Tue, 9 Dec 1997 21:14:14 -0800 Received: from sdn-ts-011txfwo8p16.dialsprint.net(206.133.157.195) by mailfep2-hme1 via smap (KC5.24) id Q_10.1.1.6/Q_28877_1_348e2521; Tue Dec 9 21:14:09 1997 Date: Wed, 10 Dec 1997 00:14:01 -0500 (EST) From: Andre LeClaire X-Sender: andreleclaire@server.lostfork.net Reply-To: Andre LeClaire To: kozmo killah cc: Mike , hackers@freebsd.org Subject: Re: Freebsd works on laptops? In-Reply-To: <19971209224818.11418.rocketmail@send1a.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think you should write a letter to Ralph Nader :) > but how to make amend for many damage cause me by linux > company and malicious product which is very crappy to > make laptop explode like that? > > if not linux company to sue, who? > > the freebsd would not make to explode the laptop no? > > i must works to warned other users how linux company > makes to destroy computers and life of users. > > is anyone know how to sue linux company? From owner-freebsd-hackers Tue Dec 9 21:32:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA17411 for hackers-outgoing; Tue, 9 Dec 1997 21:32:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA17402 for ; Tue, 9 Dec 1997 21:32:18 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id VAA04572 for hackers@freebsd.org; Tue, 9 Dec 1997 21:33:07 -0800 (PST) Date: Tue, 9 Dec 1997 21:33:07 -0800 (PST) From: Jim Shankland Message-Id: <199712100533.VAA04572@biggusdiskus.flyingfox.com> To: hackers@freebsd.org Subject: Re: Freebsd works on laptops? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > but how to make amend for many damage cause me by linux > company and malicious product which is very crappy to > make laptop explode like that? > > if not linux company to sue, who? > > the freebsd would not make to explode the laptop no? > > i must works to warned other users how linux company > makes to destroy computers and life of users. > > is anyone know how to sue linux company? I sense a leg being pulled here. Jim Shankland Flying Fox Computers, Inc. From owner-freebsd-hackers Tue Dec 9 23:11:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23217 for hackers-outgoing; Tue, 9 Dec 1997 23:11:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23212 for ; Tue, 9 Dec 1997 23:11:31 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id XAA16811; Tue, 9 Dec 1997 23:11:10 -0800 (PST) (envelope-from jamil@acroal.com) Date: Tue, 9 Dec 1997 23:11:10 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Andre LeClaire cc: kozmo killah , Mike , hackers@FreeBSD.ORG Subject: Re: Freebsd works on laptops? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You would probably have a hard time suing any company on this basis, even Micro$oft, granted they might give you a complimentary copy of Microsoft Office, but in any case whose ever heard of a user winning a suit against an applications software company? That is what we need to do, start a class action suit against Microsoft for providing inherently damaging and faulty software. It is curious that this is probably the only industry where you can get away with making and distributing faulty products and still stay in business. On Wed, 10 Dec 1997, Andre LeClaire wrote: > > I think you should write a letter to Ralph Nader :) > > > but how to make amend for many damage cause me by linux > > company and malicious product which is very crappy to > > make laptop explode like that? > > > > if not linux company to sue, who? > > > > the freebsd would not make to explode the laptop no? > > > > i must works to warned other users how linux company > > makes to destroy computers and life of users. > > > > is anyone know how to sue linux company? > > > From owner-freebsd-hackers Tue Dec 9 23:16:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA23819 for hackers-outgoing; Tue, 9 Dec 1997 23:16:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marvin.cs.dis.qut.edu.au (dave@marvin.cs.dis.qut.edu.au [131.181.124.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23813 for ; Tue, 9 Dec 1997 23:16:07 -0800 (PST) (envelope-from dave@marvin.cs.dis.qut.edu.au) Received: from localhost (dave@localhost) by marvin.cs.dis.qut.edu.au (8.8.5/8.8.5) with SMTP id RAA28943 for ; Wed, 10 Dec 1997 17:15:33 +1000 Date: Wed, 10 Dec 1997 17:15:32 +1000 (EST) From: David Richards Reply-To: David Richards To: freebsd-hackers@FreeBSD.ORG Subject: IP Firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have a question concerning IP Firewall. The short answer to my question is either a yes or no. Q) Is there a C interface to ipfirewall? The long answer would be to tell me where I can find some info on it. I looked at "man 8 ipfirewall", but it does not seem appropriate, I hope :-) Thanks in advance, Dave. -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- David Richards Ph: +61 7 3864 4347 Network Programmer Fax: +61 7 3864 5272 Computing Services E-mail: dj.richards@qut.edu.au Queensland University of Technology Brisbane, Australia -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- From owner-freebsd-hackers Wed Dec 10 00:23:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27861 for hackers-outgoing; Wed, 10 Dec 1997 00:23:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA27850 for ; Wed, 10 Dec 1997 00:23:23 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA15967; Wed, 10 Dec 1997 00:16:31 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015965; Wed Dec 10 00:16:28 1997 Date: Wed, 10 Dec 1997 00:13:59 -0800 (PST) From: Julian Elischer To: David Richards cc: freebsd-hackers@freebsd.org Subject: Re: IP Firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk try: man 4 ipfw your original guess of: man 8 ipfw is the control program. On Wed, 10 Dec 1997, David Richards wrote: > I have a question concerning IP Firewall. > > The short answer to my question is either a yes or no. > > Q) Is there a C interface to ipfirewall? > > The long answer would be to tell me where I can find some info on it. > > I looked at "man 8 ipfirewall", but it does not seem appropriate, I > hope :-) > > Thanks in advance, > > Dave. > > -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- > David Richards Ph: +61 7 3864 4347 > Network Programmer Fax: +61 7 3864 5272 > Computing Services E-mail: dj.richards@qut.edu.au > Queensland University of Technology > Brisbane, Australia > -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- > > > From owner-freebsd-hackers Wed Dec 10 02:16:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02944 for hackers-outgoing; Wed, 10 Dec 1997 02:16:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02928 for ; Wed, 10 Dec 1997 02:15:47 -0800 (PST) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.8/8.8.5) id LAA14585; Wed, 10 Dec 1997 11:14:24 +0100 (MET) From: Wolfgang Helbig Message-Id: <199712101014.LAA14585@rvc1.informatik.ba-stuttgart.de> Subject: Re: Why so many steps to build new kernel? In-Reply-To: <199712100124.TAA26461@nospam.hiwaay.net> from David Kelly at "Dec 9, 97 07:24:11 pm" To: dkelly@hiwaay.net (David Kelly) Date: Wed, 10 Dec 1997 11:14:24 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Whats wrong with "make depend kernel install"? That's what I've been The "depend" target produces the file .depend, which will be read by make(1) on the *next* run. It doesn't use the carefully built dependency rules for the "kernel" and "install" targets in this run. So, if you build the kernel each time from a clean build directory, the "depend" target is superfluous. Wolfgang From owner-freebsd-hackers Wed Dec 10 02:16:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02959 for hackers-outgoing; Wed, 10 Dec 1997 02:16:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02936 for ; Wed, 10 Dec 1997 02:15:55 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id CAA20767; Wed, 10 Dec 1997 02:15:11 -0800 (PST) To: Wolfgang Helbig cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 11:02:12 +0100." <199712101002.LAA14559@rvc1.informatik.ba-stuttgart.de> Date: Wed, 10 Dec 1997 02:15:11 -0800 Message-ID: <20763.881748911@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hmm, I'm glad we are *not* imitating Linux in this respect. > I feel much more comfortable with the FreeBSD way, i. e. editing > the kernel configuration. It makes you think you know what you're > doing, you can easily change it and you know what you have to save > if you want to build a different kernel. > > I feel no need at all for a new kernel configuration UI, which > would make things more complicated and less transparent for > the user. Well, like so many things in the Unix world, I think that the closest we can come to any sort of "ideal" is a situation where the underlying configuration mechanisms are robust and allow for very fine-grained tuning of whatever behavior they're supposed to control. On top of that sits a system which allows the less interested or skillful user to make relatively coarse adjustments without having to worry about the actual details of the mechanism. To put it another way, if M$ represents one extreme (all flash and no substance) then Unix can probably be said to represent the other one - lots of substance but no flash. :) I'm also not a fan of occupying extreme positions since something is always needlessly lost in the process. f we could strive to occupy a more balanced position, I don't think we'd lose anything by it and could stand to gain significant ease-of-use. Jordan From owner-freebsd-hackers Wed Dec 10 02:30:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA04031 for hackers-outgoing; Wed, 10 Dec 1997 02:30:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rvc1.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA04022 for ; Wed, 10 Dec 1997 02:30:05 -0800 (PST) (envelope-from helbig@Informatik.BA-Stuttgart.DE) Received: (from helbig@localhost) by rvc1.informatik.ba-stuttgart.de (8.8.8/8.8.5) id LAA14559; Wed, 10 Dec 1997 11:02:13 +0100 (MET) From: Wolfgang Helbig Message-Id: <199712101002.LAA14559@rvc1.informatik.ba-stuttgart.de> Subject: Re: Why so many steps to build new kernel? In-Reply-To: <19212.881727438@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 9, 97 08:17:18 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 10 Dec 1997 11:02:12 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > We know, and have for a long time, about Linux's curses and X based > kernel configurators. Who's going to do the work of implementing > something similar? *That's* been the big mystery up until now. :) Hmm, I'm glad we are *not* imitating Linux in this respect. I feel much more comfortable with the FreeBSD way, i. e. editing the kernel configuration. It makes you think you know what you're doing, you can easily change it and you know what you have to save if you want to build a different kernel. I feel no need at all for a new kernel configuration UI, which would make things more complicated and less transparent for the user. Wolfgang From owner-freebsd-hackers Wed Dec 10 04:46:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA10476 for hackers-outgoing; Wed, 10 Dec 1997 04:46:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA10470 for ; Wed, 10 Dec 1997 04:46:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id MAA15851 for ; Wed, 10 Dec 1997 12:33:13 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id NAA04522; Wed, 10 Dec 1997 13:32:44 +0100 (MET) X-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: New option model (was Re: cvs commit: src/sys/kern kern_exit.c) References: <199712071816.KAA21840@freefall.freebsd.org> <19971208091729.40125@uriah.heep.sax.de> <863ek4p1tx.fsf_-_@bitbox.follo.net> <199712100013.BAA04827@uriah.heep.sax.de> From: Eivind Eklund Date: 10 Dec 1997 13:32:42 +0100 In-Reply-To: j@uriah.heep.sax.de's message of Wed, 10 Dec 1997 01:13:24 +0100 (MET) Message-ID: <863ek1xtsl.fsf@bitbox.follo.net> Lines: 37 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: [on converting to the opt_xxx.h option model] > > Are there anything more that should be done here than the following > > two steps? > > > > (1) weeding LINT against /sys/conf/options and > > /sys/i386/conf/options.i386 to find what options are not currently > > handled. > > Hmm, as your example proves, LINT contains a lot of garbage. :) > > The most problematic thing about this are those options that you can > currently still find as -DFOO -DBAR if you compile GENERIC (INET, > FFS). You have to walk throughout the entire code, and fix wrong > #ifdefs. I've got a side project for when I'm bored and feel slightly brain-dead (intiative-less) - making the kernel go through -Wall and flexelint. This means I'm already going trough large parts of the kernel. Should I add ifdef-conversion to my list of things to do? As far as I can see, the only correct #ifdef's in the kernel .c files are #ifdef KERNEL (should be _KERNEL) - everything else should be #if to allow #define XXX 1 or 0. Am I correct? Should I fix this as I do my walkthrough anyway? For any option that isn't mentioned in a header file, it should be fairly simple to move to the new model - a bit of work, but mostly just work, not thought. > Except for a few things like #ifdef _KERNEL (still > misspelled as #ifdef KERNEL in FreeBSD), #ifdef's should be mostly > banned from .h files. These look like a lot of non-trivial work to fix :-( Eivind. From owner-freebsd-hackers Wed Dec 10 04:58:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA11016 for hackers-outgoing; Wed, 10 Dec 1997 04:58:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA10998 for ; Wed, 10 Dec 1997 04:58:06 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712101258.EAA10998@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA118098245; Wed, 10 Dec 1997 23:50:45 +1100 From: Darren Reed Subject: Re: Why so many steps to build new kernel? To: helbig@Informatik.BA-Stuttgart.DE (Wolfgang Helbig) Date: Wed, 10 Dec 1997 23:50:45 +1100 (EDT) Cc: dkelly@hiwaay.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712101014.LAA14585@rvc1.informatik.ba-stuttgart.de> from "Wolfgang Helbig" at Dec 10, 97 11:14:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Wolfgang Helbig, sie said: > > > Whats wrong with "make depend kernel install"? That's what I've been > > The "depend" target produces the file .depend, which will be read > by make(1) on the *next* run. It doesn't use the carefully built > dependency rules for the "kernel" and "install" targets in this run. > > So, if you build the kernel each time from a clean build directory, > the "depend" target is superfluous. How about this: make depend && make kernel && make install Darren From owner-freebsd-hackers Wed Dec 10 06:04:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA14480 for hackers-outgoing; Wed, 10 Dec 1997 06:04:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA14458 for ; Wed, 10 Dec 1997 06:04:03 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199712101323.IAA11947@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Wed, 10 Dec 1997 08:28:58 -0500 (EST) From: Jamie Bowden To: "Jordan K. Hubbard" cc: freebsd-hackers@freebsd.org Subject: Re: Why so many steps to build new kernel? In-Reply-To: <19212.881727438@time.cdrom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Dec 1997, Jordan K. Hubbard wrote: > > On this topic. I don't care for Linux (Too Unreliable), but theyv'e had a > > curses based configuration tool as part of the sources since v 2.0. > > It is kind of nice since it lets you choose what hardware support you want > > to compile in and even some port variables etc. > > We know, and have for a long time, about Linux's curses and X based > kernel configurators. Who's going to do the work of implementing > something similar? *That's* been the big mystery up until now. :) > > Jordan > And more to the point, why would you want to? Linux's make config is an abomination. -- Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) From owner-freebsd-hackers Wed Dec 10 06:52:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA18532 for hackers-outgoing; Wed, 10 Dec 1997 06:52:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA18523 for ; Wed, 10 Dec 1997 06:52:13 -0800 (PST) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA15269; Wed, 10 Dec 1997 09:50:10 -0500 Date: Wed, 10 Dec 1997 09:50:10 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Jamie Bowden cc: "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-Reply-To: <199712101323.IAA11947@gatekeeper.itribe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jamie Bowden wrote: > On Tue, 9 Dec 1997, Jordan K. Hubbard wrote: > > We know, and have for a long time, about Linux's curses and X based > > kernel configurators. Who's going to do the work of implementing > > something similar? *That's* been the big mystery up until now. :) > And more to the point, why would you want to? Linux's make config is an > abomination. all you really want is a tk-style interface to build config files. You don't want any of the other linux hideousness. I think that's what jordan meant. I use both systems for kernels and believe me i prefer the bsd style, even lacking the cute graphical interface. Much better than the linux style. ron From owner-freebsd-hackers Wed Dec 10 07:11:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20037 for hackers-outgoing; Wed, 10 Dec 1997 07:11:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kalypso.cybercom.net (kalypso.cybercom.net [209.21.136.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20029 for ; Wed, 10 Dec 1997 07:10:58 -0800 (PST) (envelope-from ksmm@kalypso.cybercom.net) Received: from localhost (ksmm@localhost) by kalypso.cybercom.net (8.8.7/8.8.7) with SMTP id KAA00929 for ; Wed, 10 Dec 1997 10:09:52 -0500 (EST) Date: Wed, 10 Dec 1997 10:09:49 -0500 (EST) From: The Classiest Man Alive cc: freebsd-hackers@freebsd.org Subject: Re: Why so many steps to build new kernel? In-Reply-To: <199712101002.LAA14559@rvc1.informatik.ba-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why is it that every time somebody suggests making a script or GUI utility to automate some boring but necessary UNIX process, all you guys who went to school with Dennis Richie pop out and start complaining about how the GUI is the greatest affront to computer science since the invention of the transistor? Nobody's going to be any worse off if we *add* some new ways to do things. I sincerely think that some of you are actually opposed to the proliferation of FreeBSD to people who don't think Emacs is the greatest app ever written. I swear, you all are going to drive me to learn C. Whew, that felt good. :-) K.S. From owner-freebsd-hackers Wed Dec 10 07:59:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA23303 for hackers-outgoing; Wed, 10 Dec 1997 07:59:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA23280 for ; Wed, 10 Dec 1997 07:58:42 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id HAA21865; Wed, 10 Dec 1997 07:57:34 -0800 (PST) To: The Classiest Man Alive cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 10:09:49 EST." Date: Wed, 10 Dec 1997 07:57:34 -0800 Message-ID: <21861.881769454@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why is it that every time somebody suggests making a script or GUI utility > to automate some boring but necessary UNIX process, all you guys who went > to school with Dennis Richie pop out and start complaining about how the > GUI is the greatest affront to computer science since the invention of the > transistor? Nobody's going to be any worse off if we *add* some new ways What else would there be to do at 3am? :-) Seriously, I can certainly see how it might feel that way, but I think that if you honestly look at the situation you'll find that even the most vocal "punched cards were good enough in my day" types wouldn't actually mind it if somebody released a purely optional curses based kernel configurator (optional so they don't have to use it themselves) or something. What they mostly get tired of is simply the implication that one of them should go write such a thing, since the people who are usually the most likely to ask for features like this are also the least likely to be able to actually do the work themselves, resulting in yet another one of those "it sure would be nice if FreeBSD ..." postings which really translate to "it sure would be nice if *somebody else* would implement the following for FreeBSD" :-) I'm sure that if more of these suggestions started being accompanied by actual working code, they'd meet with a much different reception. I heard from one guy who was working on something called "kconfig", but at last update it had bogged down at the most critical stage, that being the part where all the kernel configuration options are presented in menu form. The copy I reviewed did everything *but* that rather important bit. :-) > I swear, you all are going to drive me to learn C. Hope so - maybe you'll then be the one to implement all this shit! :-) Jordan From owner-freebsd-hackers Wed Dec 10 08:29:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25059 for hackers-outgoing; Wed, 10 Dec 1997 08:29:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25050 for ; Wed, 10 Dec 1997 08:29:38 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id LAA00901; Wed, 10 Dec 1997 11:24:28 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712101624.LAA00901@dyson.iquest.net> Subject: Re: Why so many steps to build new kernel? In-Reply-To: from "Ron G. Minnich" at "Dec 10, 97 09:50:10 am" To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Wed, 10 Dec 1997 11:24:27 -0500 (EST) Cc: jamie@itribe.net, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ron G. Minnich said: > > On Wed, 10 Dec 1997, Jamie Bowden wrote: > > On Tue, 9 Dec 1997, Jordan K. Hubbard wrote: > > > We know, and have for a long time, about Linux's curses and X based > > > kernel configurators. Who's going to do the work of implementing > > > something similar? *That's* been the big mystery up until now. :) > > And more to the point, why would you want to? Linux's make config is an > > abomination. > > > all you really want is a tk-style interface to build config files. You > don't want any of the other linux hideousness. I think that's what jordan > meant. I use both systems for kernels and believe me i prefer the bsd > style, even lacking the cute graphical interface. Much better than the > linux style. > There are times that I get an inspired urge to get away from kernel hacking and do something neat with perl/tk or tcl/tk along the lines of kernel config, but then I wake up and realize what a terrible userland programmer I am :-). Every X-type application that I have ever written has turned into a spaghetti monstrosity. I know it is my fault, but it is so frustrating to know how, but have so little skill in the area. Maybe we should do it in Win32, then that would really speed up Wine development. :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Wed Dec 10 08:31:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA25293 for hackers-outgoing; Wed, 10 Dec 1997 08:31:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA25283 for ; Wed, 10 Dec 1997 08:31:10 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id QAA22656; Wed, 10 Dec 1997 16:31:04 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id RAA05240; Wed, 10 Dec 1997 17:31:02 +0100 (MET) To: "Jamil J. Weatherbee" Cc: hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help References: From: Eivind Eklund Date: 10 Dec 1997 17:30:55 +0100 In-Reply-To: "Jamil J. Weatherbee"'s message of Thu, 4 Dec 1997 01:22:39 -0800 (PST) Message-ID: <86ra7lw474.fsf@bitbox.follo.net> Lines: 97 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jamil J. Weatherbee" writes: > Here is a diagram of what I want to do (if this is possible): > I have not been able to get this configured: > > The ip addresses have been altered to protect innocent networks of > unprotected wincrap 95 machines. > > > service provider ------\ > | > | > Ascend Pipeline 50 > 123.123.62.161/27 (router0) > | > | <----- crossover cable > (ed1) > FreeBSD Firewall > 123.123.62.162/27 (core)---(ppp0)------modem(remote user) > (ed0) proxied to > | ethernet > | > | > Windoze ethernet 123.123.62.161-190/27 This one seems to be possible, but it will be somewhat hairy. Quick version: Proxy ARP in both directions, direct interface routes (you will probably not want to have any address assigned to the interfaces if you want this to be transparent) and a kernel mod to stop decreasing the TTL field. (1) Do an interface route for all traffic to the ascend by route add -host 123.123.62.161 -iface ed1 (2) Do an interface route for all traffic to the local network route add -net 123.123.62.160 -netmask 255.255.255.225 -iface ed0 This will not conflict with the route to the Ascend, as the kernel router select the most specific route available. (3) Set up proxy arp resolution for 123.123.62.161 on the ed0 interface. This will be something like arp -S 123.123.62.161 $(ifconfig ed0 | awk '/ether/ {print $2}') pub (4) Add proxy arp for all the windows machines on ed1. #!/bin/sh END_ARP=$(ifconfig ed0 | awk '/ether/ {print $2}') for ip in 163 164 165 166 167 168 169 170 171 172 173 174 \ 175 176 177 178 179 180 181 182 183 184 185 186 \ 187 188 189 190 do arp -S 123.123.62.$ip $END_ARP pub done (5) Set IPTTLDEC in /sys/netinet/ip.h to 0. This will stop your kernel from decreasing the Time To Live field. Thus, you won't show up in traceroutes etc. WARNING: TTL is a safety field to avoid routing loops. If you disable this, you'd better be damn sure you don't respect source routing and don't have anything else that can cause a routing loop. (6) If you're going to do this 'right' (hide the host and create a completely transparent firewalling bridge), don't set an IP address on ed0. This will, however, stop the firewall from both accepting and creating TCP connections. If you need acceptance only, you can do this by adding an alias of 123.123.62.162/32 to lo0, and proxy-arp'ing for that address on ed0. This will allow inbound but not outbound connections. (I'm not certain you'll be able to do connections with the machines even if you set up an interface address - you're proxy-arp'ing for them, anyway.) No guarantees is given for the correctness of the approach above (with the same constraint as below). ppp0 is left as an exercise for the reader (unless the reader is willing to pay me money to do the exercise, of course ;-) BTW: I've been thinking of firewalls and routing lately. A worthy project for Somebody would be to replace ipfw with a firewall integrated with the routing code - they seem to be doing a lot of duplicate work. It should also be possible to make the resulting trees compile to an easily parsable format that can be implemented as a mask/compare -> (change table position|route|deny|log) where the mask/compare is done against 'a complete set of data about the packet'. Extra tables should be possible to add input and output on each interface. If anybody suddenly feel an urge to do suchs a project, please contact me. I have done some work on how to optimize this; it is fairly simple to optimize spacewise, but not so easy to optimize for time (as this depend on the number of packets matched by each rule, and both negative and positive rules can be added). BTW2: How is the general and core view on making such changes? Is the routing code 'holy code', or are drastic changes possible? (The idea above would more-or-less replace the entire implementation with a more powerful scheme for the 'static routes' case; I guess it would be both easy and best to write so it was only enabled on request, though) Eivind. From owner-freebsd-hackers Wed Dec 10 08:56:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA27117 for hackers-outgoing; Wed, 10 Dec 1997 08:56:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA27102 for ; Wed, 10 Dec 1997 08:56:15 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id IAA17676 for ; Wed, 10 Dec 1997 08:56:25 -0800 Date: Wed, 10 Dec 1997 08:56:25 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio Reply-To: Jason Evans To: freebsd-hackers@freebsd.org Subject: Beginning SPARC port Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As has been alluded to in some of Jordan Hubbard's email, Sun Microelectronics (SME, the processor division of Sun) recently discussed paying FreeBSD core to officially support a port of FreeBSD to SPARC. These plans fell through in some way (I wasn't part of the discussion, so I don't know details), but SME is having me work on the port. I'm a full-time employee of SME, and estimate that I can spend 30-35 hours per week of my work week on the SPARC FreeBSD porting effort (plus whatever personal time I spend). This is a wonderful opportunity for me, as it is for the FreeBSD community in general. I'm getting paid real money to do this, so I have no problems with devoting time to the project. My additional duties here at SME include gathering technical information for RTOS vendors that are porting their OSes to SPARC, so I'm in a good position to get my hands on useful documentation necessary for the port. All code that comes from my efforts will be available to FreeBSD under the standard BSD license. As far as my background goes, I must say that I'm not a hardware god, or an OS god for that matter. However, I'm very proficient at coding and debugging, and learn very quickly. That said, I'll probably inadvertently ask a lot of questions that will make you think, "This guy's trying to port an OS?!" Feel free to point out if I'm asking dumb questions, but please be so kind as to also tell me why they're dumb questions so that I know how to find the answers. I'm working to serve the FreeBSD community in a very specific way, and I'm free, other than whatever time of yours I take up. Yes, I'm getting paid to do this, but the passion I feel for FreeBSD and for free software in general is very much my own. I want to run SPARC FreeBSD at home! I've already had one person mention to me that he is interested in helping with the port. Please let me know if you are also interested in helping. I can use the help, believe me, even if it's simply answering questions about hardware. My apologies if the following questions are answered somewhere in documentation. I've read the FreeBSD Handbook, but won't have a FreeBSD machine for another week or so. 1) Is it possible with cvsup to maintain my own source tree with my modifications, yet stay synched with current, so that once I have the kernel running, I can submit a single update to the current tree (or have someone with write access do it for me)? 2) Supposing that 1) is possible, does it make more sense to simply grab current once, port it to SPARC, then deal with merging it back into current? This would be one major effort, versus constant small efforts to stay current. 3) Again supposing that 1) is possible, is it additionally feasible to have multiple people working on my local tree with some sort of revision control? I haven't asked anyone about getting write access to the source tree. Perhaps that is better discussed in private email. I'm not yet sure whether I need access to get any work done. If so, is there a rite of passage? =) Thanks, Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Office phone: [(408) 774-8007] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 10:02:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03049 for hackers-outgoing; Wed, 10 Dec 1997 10:02:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03021 for ; Wed, 10 Dec 1997 10:02:37 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id TAA21574; Wed, 10 Dec 1997 19:02:24 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id TAA26366; Wed, 10 Dec 1997 19:02:23 +0100 (MET) Message-ID: <19971210190223.FD42136@mars.hsc.fr> Date: Wed, 10 Dec 1997 19:02:23 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: jasone@canonware.com (Jason Evans) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: ; from Jason Evans on Dec 10, 1997 08:56:25 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jason Evans: > I don't know details), but SME is having me work on the port. I'm a > full-time employee of SME, and estimate that I can spend 30-35 hours per > week of my work week on the SPARC FreeBSD porting effort (plus whatever > personal time I spend). That looks like a great idea to me, though I'm quite surprised that Sun supports this since they've been desperately trying to kill SunOS for years... > 1) Is it possible with cvsup to maintain my own source tree with my > modifications, yet stay synched with current, so that once I have the > kernel running, I can submit a single update to the current tree (or have > someone with write access do it for me)? Since NetBSD already runs quite fine on many SPARC models, maybe it would be a good idea to consider using their code as a starting point. On the other hand they would surely be pretty interested by information you might provide them with to write drivers for obscure Sun peripherals (I for one would be dying to replace old SunOS with any recent BSD on my Sparcbook... if only there was a X11 port with the required driver for the LCD screen). -- Pierre.Beyssac@hsc.fr From owner-freebsd-hackers Wed Dec 10 10:13:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04034 for hackers-outgoing; Wed, 10 Dec 1997 10:13:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from www.cep.yale.edu (www.cep.yale.edu [130.132.125.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03991 for ; Wed, 10 Dec 1997 10:12:35 -0800 (PST) (envelope-from mrami@www.cep.yale.edu) Received: from localhost (mrami@localhost) by www.cep.yale.edu (8.8.5/8.8.5) with SMTP id NAA20037; Wed, 10 Dec 1997 13:11:55 -0500 (EST) Date: Wed, 10 Dec 1997 13:11:55 -0500 (EST) From: Marc Ramirez To: The Classiest Man Alive cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, The Classiest Man Alive wrote: > > > Why is it that every time somebody suggests making a script or GUI utility > to automate some boring but necessary UNIX process, [...] > > I swear, you all are going to drive me to learn C. I don't think these people make up the majority of the FreeBSD camp by any stretch. I think most people would echo my sentiments (if not my standpoint). My first "programming project" was when I was a little kid. My dad wanted me to write a program to tally up the balance sheets for his plumbing company. I did, and he used it for a couple of months, and then one day he asked me, "I wonder if there's any way for me to go back to the last number I entered if I make a mistake." I was then hooked on UI's. :) I am a born applications programmer. I love hashing out the details, spending three weeks QA'ing a program it took two days to write. When I write a solid app, I strut around the city beating my chest. If I could, I would gladly sit down and bang out any configuration utility FreeBSD could use. However, between being a CS major and a sysadmin, anything I start would have, oh, a five to six month turnaround. :) Right now, I'm not sure that's an investment I'm prepared to make unless, say, Jordan would guarantee that my work would be used. And I certainly wouldn't put Jordan in that position, considering he's never seen my work. :) :) And here you run smack into the problem faced by all volunteer projects, causing users to gripe and programmers to be irritated. Marc. -- Quidem, D! Omnis bonus est! From owner-freebsd-hackers Wed Dec 10 10:22:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04830 for hackers-outgoing; Wed, 10 Dec 1997 10:22:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04820 for ; Wed, 10 Dec 1997 10:22:06 -0800 (PST) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.fokus.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with SMTP id TAA04201; Wed, 10 Dec 1997 19:21:55 +0100 (MET) Received: by sherwood.fokus.gmd.de (SMI-8.6/SMI-SVR4) id TAA06492; Wed, 10 Dec 1997 19:21:29 +0100 Date: Wed, 10 Dec 1997 19:21:29 +0100 From: schilling@fokus.gmd.de (Joerg Schilling) Message-Id: <199712101821.TAA06492@sherwood.fokus.gmd.de> To: freebsd-hackers@freebsd.org Cc: schilling@fokus.gmd.de Subject: Re: HP 6020 CD-R Drive compatibility Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am reading this via a news reflector... The HP-71* drives are SCSI-3/mmc compliant drives. They are totally different from all former drives! The only freeware, I know of that supports SCSI-3/mmc is cdrecord. Joerg http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From owner-freebsd-hackers Wed Dec 10 10:27:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05376 for hackers-outgoing; Wed, 10 Dec 1997 10:27:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05361 for ; Wed, 10 Dec 1997 10:27:37 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id KAA18089 for ; Wed, 10 Dec 1997 10:27:46 -0800 Date: Wed, 10 Dec 1997 10:27:46 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Pierre Beyssac wrote: > That looks like a great idea to me, though I'm quite surprised that > Sun supports this since they've been desperately trying to kill SunOS > for years... Sun is broken into separate business units. SME cares about selling CPUs. If FreeBSD helps them do that, then great, even if the other business units don't like it. An odd arrangement, but until they start losing money, I imagine things will stay that way... > Since NetBSD already runs quite fine on many SPARC models, maybe > it would be a good idea to consider using their code as a starting > point. On the other hand they would surely be pretty interested by > information you might provide them with to write drivers for obscure > Sun peripherals (I for one would be dying to replace old SunOS with > any recent BSD on my Sparcbook... if only there was a X11 port with > the required driver for the LCD screen). My boss is specifically interested in seeing FreeBSD run on SPARC. From a technical perspective, perhaps NetBSD would be a better starting point, but I'll take what I can get when it comes to being paid for free software development. =) Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 10:42:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06342 for hackers-outgoing; Wed, 10 Dec 1997 10:42:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (eLOWzgSlf/2qcIh2rWYNEUF3M9YNJuQA@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA06322 for ; Wed, 10 Dec 1997 10:42:01 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([Y6wSnX4odyfzUx+g1shbBMalqxbjQ6z7]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xfr4O-0005p4-00; Wed, 10 Dec 1997 18:41:16 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xfr3p-0004d5-00; Wed, 10 Dec 1997 18:40:41 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Wed, 10 Dec 1997 18:40:41 +0000 In-Reply-To: The Classiest Man Alive "Re: Why so many steps to build new kernel?" (Dec 10, 10:09am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: The Classiest Man Alive Subject: Re: Why so many steps to build new kernel? Cc: freebsd-hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 10, 10:09am, The Classiest Man Alive wrote: } Subject: Re: Why so many steps to build new kernel? > > > transistor? Nobody's going to be any worse off if we *add* some new ways > to do things. I don't think anyone on this list has said that GUI tools shouldn't be *added*, just that they should be built on top of a command line util. > I sincerely think that some of you are actually opposed to > the proliferation of FreeBSD to people who don't think Emacs is the > greatest app ever written. stdin: parse error Yes, I agree vi > emacs if thats what you're trying to say. > I swear, you all are going to drive me to learn C. "anything but perl" Niall From owner-freebsd-hackers Wed Dec 10 10:53:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07228 for hackers-outgoing; Wed, 10 Dec 1997 10:53:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07221 for ; Wed, 10 Dec 1997 10:53:10 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA12991; Wed, 10 Dec 1997 10:52:39 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma012987; Wed Dec 10 10:52:21 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id KAA18596; Wed, 10 Dec 1997 10:52:21 -0800 (PST) From: Archie Cobbs Message-Id: <199712101852.KAA18596@bubba.whistle.com> Subject: Re: Beginning SPARC port In-Reply-To: from Jason Evans at "Dec 10, 97 08:56:25 am" To: jasone@canonware.com Date: Wed, 10 Dec 1997 10:52:21 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 1) Is it possible with cvsup to maintain my own source tree with my > modifications, yet stay synched with current, so that once I have the > kernel running, I can submit a single update to the current tree (or have > someone with write access do it for me)? Yes, this is possible. You can have your own branches in the local copy of the FreeBSD source tree. This allows you to merge in -current changes into your branch, etc. I don't know the details of how to do it though.. I think you just do a checkin/branch or whatever, and it just works (ie, won't get overwritten).. can someone confirm this? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Dec 10 10:56:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07474 for hackers-outgoing; Wed, 10 Dec 1997 10:56:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07374 for ; Wed, 10 Dec 1997 10:55:40 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA13012; Wed, 10 Dec 1997 10:55:09 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013003; Wed Dec 10 10:54:56 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id KAA18602; Wed, 10 Dec 1997 10:54:56 -0800 (PST) From: Archie Cobbs Message-Id: <199712101854.KAA18602@bubba.whistle.com> Subject: Re: I seriously need some networking help In-Reply-To: <86ra7lw474.fsf@bitbox.follo.net> from Eivind Eklund at "Dec 10, 97 05:30:55 pm" To: perhaps@yes.no (Eivind Eklund) Date: Wed, 10 Dec 1997 10:54:56 -0800 (PST) Cc: jamil@trojanhorse.ml.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > BTW: I've been thinking of firewalls and routing lately. A worthy > project for Somebody would be to replace ipfw with a firewall > integrated with the routing code - they seem to be doing a lot of > duplicate work. It should also be possible to make the resulting > trees compile to an easily parsable format that can be implemented as > a mask/compare -> (change table position|route|deny|log) > where the mask/compare is done against 'a complete set of data about > the packet'. Extra tables should be possible to add input and output > on each interface. > > If anybody suddenly feel an urge to do suchs a project, please contact > me. I have done some work on how to optimize this; it is fairly > simple to optimize spacewise, but not so easy to optimize for time (as > this depend on the number of packets matched by each rule, and both > negative and positive rules can be added). > > BTW2: How is the general and core view on making such changes? Is the > routing code 'holy code', or are drastic changes possible? (The idea > above would more-or-less replace the entire implementation with a more > powerful scheme for the 'static routes' case; I guess it would be both > easy and best to write so it was only enabled on request, though) > > Eivind. In my opinion, the ARP/routing/interface code is about as hairy as it gets. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Dec 10 11:26:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA09763 for hackers-outgoing; Wed, 10 Dec 1997 11:26:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mongoose.cs.unm.edu (mongoose.cs.unm.edu [198.59.151.21]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA09744 for ; Wed, 10 Dec 1997 11:26:13 -0800 (PST) (envelope-from cfaehl@cs.unm.edu) Received: from enterprise.cs.unm.edu(really [198.59.151.20]) by mongoose.cs.unm.edu via smail with smtp id for ; Wed, 10 Dec 1997 12:26:03 -0700 (MST) (Smail-3.2 1996-Jul-4 #3 built 1997-Mar-7) Received: from avarice.cs.unm.edu(really [198.59.151.252]) by enterprise.cs.unm.edu via smail with esmtp id for ; Wed, 10 Dec 1997 12:26:03 -0700 (MST) (Smail-3.2 1996-Jul-4 #18 built 1997-Feb-28) Message-Id: X-Mailer: exmh version 2.0zeta 7/24/97 To: The Classiest Man Alive cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 10:09:49 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Dec 1997 12:24:48 -0700 From: "Chris Faehl" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Why is it that every time somebody suggests making a script or GUI utility > to automate some boring but necessary UNIX process, all you guys who went > to school with Dennis Richie pop out and start complaining about how the > GUI is the greatest affront to computer science since the invention of the > transistor? What I see being suggested isn't anything that will help automate kernel config, but rather to simply replace sections with a pointy-clicky interface. That's hardly automation. Anyway, the biggest reason I can come up with AGAINST GUIs for kernel configuration is the obscuration of the original, has-to-exist kernel config file. That is, the config file still has to exist, so why not just muck about with it directly? Regarding GUIs as an affront to computer science - there seems to be a sizable portion of folks who think that possession of a GUI makes a program great. I especially see this attitude wrt to NT - administration of these boxes is touted to be 'easier' because of the boatload of (poor) GUI chrome they've dumped on to it. Oh, please... all this does is encourage the 'reinstall the OS when something breaks' mode of operation, since the real guts of the damn thing are completely obscured. > > > > Whew, that felt good. :-) > > K.S. > ------------------------------------------------------------------------------- Chris Faehl | Email: cfaehl@cs.unm.edu The University of New Mexico | URL: http://www.cs.unm.edu/~cfaehl Computer Science Dept., Rm. FEC 313 | Phone: 505/277-3526 Albuquerque, NM 87131 USA | FAX: 505/277-6927 ------------------------------------------------------------------------------- From owner-freebsd-hackers Wed Dec 10 11:32:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10494 for hackers-outgoing; Wed, 10 Dec 1997 11:32:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10482 for ; Wed, 10 Dec 1997 11:32:11 -0800 (PST) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.fokus.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with SMTP id UAA06392; Wed, 10 Dec 1997 20:32:05 +0100 (MET) Received: by sherwood.fokus.gmd.de (SMI-8.6/SMI-SVR4) id UAA06880; Wed, 10 Dec 1997 20:31:39 +0100 Date: Wed, 10 Dec 1997 20:31:39 +0100 From: schilling@fokus.gmd.de (Joerg Schilling) Message-Id: <199712101931.UAA06880@sherwood.fokus.gmd.de> To: freebsd-hackers@freebsd.org Cc: schilling@fokus.gmd.de Subject: Cdrecord (was HP 6020 drive compatibility) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Joerg Wunsch writes: >Only very slowly. You could also have a look at Joerg Schilling's >cdrecord tool, it's in the ports collection, and basically bypasses >the kernel driver. Wrong: Cdrecord does not bypass the kernel driver! Cdrecord uses the SCSI kernel driver to send SCSI commands to the drive. The way cdrecord does this, is the only portable way across different UNIX platforms. Cdrecord currently runs on: SunOS Solaris Linux FreeBSD/NetBSD/OpenBSD SGI-IRIX HP-UX AIX NeXT Step Apple Rhapsody Joerg http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From owner-freebsd-hackers Wed Dec 10 11:59:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA12848 for hackers-outgoing; Wed, 10 Dec 1997 11:59:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA12784 for ; Wed, 10 Dec 1997 11:59:04 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id OAA12660; Wed, 10 Dec 1997 14:57:40 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Wed, 10 Dec 1997 14:57:35 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Jason Evans cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jason Evans wrote: > As has been alluded to in some of Jordan Hubbard's email, Sun > Microelectronics (SME, the processor division of Sun) recently discussed > paying FreeBSD core to officially support a port of FreeBSD to SPARC. > These plans fell through in some way (I wasn't part of the discussion, so > I don't know details), but SME is having me work on the port. I'm a > full-time employee of SME, and estimate that I can spend 30-35 hours per > week of my work week on the SPARC FreeBSD porting effort (plus whatever > personal time I spend). Wow, this sounds really neat. You probably want to ask the guys who were starting on the stalled alpha port what directory structure they had agreed on. Seeing as they probably had to answer exactly the kind of questions of source layout you're going to have to solve before you really get to coding, and their answers probably were run by some part of core to begin with, that's short circuit some things. I would also be a little curious about the availability of sparc hardware for hobbyist folk. Few of us can afford $10K servers, but what other kind of more modest setups might be available? I know you probably aren't a walking database of such things, but if you come up with occaisonal pointers to folks selling motherboards that might fit into pc cases, and maybe use PCI, and the location of sparc docs on the web, it'd be nice to post such things. I'd read them, and probably lots of others would too. It's likely (working where you do) that you'd be more likely to fall into that kind of info than I would. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Dec 10 12:11:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14124 for hackers-outgoing; Wed, 10 Dec 1997 12:11:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA14117 for ; Wed, 10 Dec 1997 12:11:27 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA13707; Wed, 10 Dec 1997 12:10:51 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma013703; Wed Dec 10 12:10:33 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id MAA19248; Wed, 10 Dec 1997 12:10:32 -0800 (PST) From: Archie Cobbs Message-Id: <199712102010.MAA19248@bubba.whistle.com> Subject: Re: Why so many steps to build new kernel? In-Reply-To: from Chris Faehl at "Dec 10, 97 12:24:48 pm" To: cfaehl@cs.unm.edu (Chris Faehl) Date: Wed, 10 Dec 1997 12:10:32 -0800 (PST) Cc: ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Faehl writes: > > > > > > Why is it that every time somebody suggests making a script or GUI utility > > to automate some boring but necessary UNIX process, all you guys who went > > to school with Dennis Richie pop out and start complaining about how the > > GUI is the greatest affront to computer science since the invention of the > > transistor? > > What I see being suggested isn't anything that will help automate > kernel config, but rather to simply replace sections with a pointy-clicky > interface. That's hardly automation. > > Anyway, the biggest reason I can come up with AGAINST GUIs for kernel > configuration is the obscuration of the original, has-to-exist kernel > config file. That is, the config file still has to exist, so why not > just muck about with it directly? So what's wrong with a GUI program that spits out kernel config files? That's kindof what I envisioned. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Dec 10 12:13:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14345 for hackers-outgoing; Wed, 10 Dec 1997 12:13:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA14339 for ; Wed, 10 Dec 1997 12:13:06 -0800 (PST) (envelope-from nash@Venus.mcs.net) Received: from Venus.mcs.net (nash@Venus.mcs.net [192.160.127.92]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id OAA03181; Wed, 10 Dec 1997 14:13:05 -0600 (CST) Received: from localhost (nash@localhost) by Venus.mcs.net (8.8.7/8.8.2) with SMTP id OAA22168; Wed, 10 Dec 1997 14:13:04 -0600 (CST) Date: Wed, 10 Dec 1997 14:13:04 -0600 (CST) From: Alex Nash To: Joerg Schilling cc: freebsd-hackers@freebsd.org Subject: Re: Cdrecord (was HP 6020 drive compatibility) In-Reply-To: <199712101931.UAA06880@sherwood.fokus.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Joerg Schilling wrote: > Joerg Wunsch writes: > > >Only very slowly. You could also have a look at Joerg Schilling's > >cdrecord tool, it's in the ports collection, and basically bypasses > >the kernel driver. > > Wrong: Cdrecord does not bypass the kernel driver! > > Cdrecord uses the SCSI kernel driver to send SCSI commands to the drive. > The way cdrecord does this, is the only portable way across different > UNIX platforms. I think what Joerg meant was that cdrecord bypasses the worm driver (as does cd-write), not the SCSI driver. Alex From owner-freebsd-hackers Wed Dec 10 12:13:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14436 for hackers-outgoing; Wed, 10 Dec 1997 12:13:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA14414 for ; Wed, 10 Dec 1997 12:13:38 -0800 (PST) (envelope-from handy@sag.space.lockheed.com) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA26392; Wed, 10 Dec 1997 12:13:11 -0800 Date: Wed, 10 Dec 1997 12:13:11 -0800 (PST) From: Brian Handy To: Chuck Robey Cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck writes: >I would also be a little curious about the availability of sparc hardware >for hobbyist folk. Few of us can afford $10K servers, but what other kind >of more modest setups might be available? Now, I know we have quite a few older Sparc 10's and such running around that seem like they're getting along in vintage. I'm not going to be able to liberate any of these, but it suggests to me there probably is a bunch of this sort of stuff out there for cheap. How different are the different Sparc's? If people want to start hunting for one, is this like the alpha fiasco -- you need "this" model in order to play? Also, from the viewpoint of us clueless user-types, can anybody wax on the advantages of buying a Sparc platform? My familiarity is mostly with x86's and Alphas...not many suns in-house. "Why will my next h/w be a sun?" :-) Wondering aloud, Brian From owner-freebsd-hackers Wed Dec 10 12:29:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15747 for hackers-outgoing; Wed, 10 Dec 1997 12:29:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15717 for ; Wed, 10 Dec 1997 12:28:50 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id MAA18590; Wed, 10 Dec 1997 12:28:49 -0800 Date: Wed, 10 Dec 1997 12:28:48 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: Chuck Robey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Chuck Robey wrote: > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind > of more modest setups might be available? I know you probably aren't a > walking database of such things, but if you come up with occaisonal > pointers to folks selling motherboards that might fit into pc cases, and > maybe use PCI, and the location of sparc docs on the web, it'd be nice to > post such things. I'd read them, and probably lots of others would too. > It's likely (working where you do) that you'd be more likely to fall into > that kind of info than I would. The machine I have available for development is probably the immediate precursor to the machine that will make UltraSPARCs available to to the general public. This machine is a bit expensive, but the next version will be substantially cheaper. As of 2 weeks ago this machine cost $2887.50 for the MB+CPU (UltraAX, 167MHz Ultra), $90/8MB SIMM (add in sets of 4), and $105 for the case. It has a built-in IDE controller and ethernet port. The forthcoming board will have SCSI instead of IDE on the board. Both boards have a PCI bus. At some point in the future, once FreeBSD runs on these, and I have some money, I plan to use one at home. (The money part could take a while. =) ) I bought (for Sun) machines from Bell Micro (http://www.bellmicro.com). Their web site is a bit sparse, but they do sell the parts. As for supporting older hardware, I'll do my best to make it possible, but I can only test on so many machines before it becomes impractical. Pre-Ultra machines are becoming more and more scarce at work. I'll have to try to hold onto my SPARC-10... Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 12:41:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA16840 for hackers-outgoing; Wed, 10 Dec 1997 12:41:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA16802 for ; Wed, 10 Dec 1997 12:40:41 -0800 (PST) (envelope-from rjs@fdy2.demon.co.uk) Received: from fdy2.demon.co.uk ([194.222.102.143]) by post.mail.demon.net id aa2022189; 10 Dec 97 20:29 GMT Received: (from rjs@localhost) by fdy2.demon.co.uk (8.8.7/8.6.12) id UAA00277; Wed, 10 Dec 1997 20:29:57 GMT Date: Wed, 10 Dec 1997 20:29:57 GMT From: Robert Swindells Message-Id: <199712102029.UAA00277@fdy2.demon.co.uk> To: chuckr@glue.umd.edu CC: jasone@canonware.com, freebsd-hackers@freebsd.org In-reply-to: (message from Chuck Robey on Wed, 10 Dec 1997 14:57:35 -0500 (EST)) Subject: Re: Beginning SPARC port Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: >I would also be a little curious about the availability of sparc hardware >for hobbyist folk. Few of us can afford $10K servers, but what other kind >of more modest setups might be available? I know you probably aren't a >walking database of such things, but if you come up with occaisonal >pointers to folks selling motherboards that might fit into pc cases, and >maybe use PCI, and the location of sparc docs on the web, it'd be nice to >post such things. I'd read them, and probably lots of others would too. >It's likely (working where you do) that you'd be more likely to fall into >that kind of info than I would. http://www.sun.com/microelectronics/SPARCengineUltraAX It needs an ATX case though. ------------------------------------- Robert Swindells - GenRad Ltd rjs@genrad.co.uk - Work rjs@fdy2.demon.co.uk - Home From owner-freebsd-hackers Wed Dec 10 12:48:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17311 for hackers-outgoing; Wed, 10 Dec 1997 12:48:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marlin.exis.net (root@marlin.exis.net [205.252.72.102]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17304 for ; Wed, 10 Dec 1997 12:48:33 -0800 (PST) (envelope-from stefan@exis.net) Received: from sailfish.exis.net (sailfish.exis.net [205.252.72.104]) by marlin.exis.net (8.8.4/8.8.5) with SMTP id PAA03533; Wed, 10 Dec 1997 15:48:06 -0500 Date: Wed, 10 Dec 1997 15:24:12 -0500 (EST) From: Stefan Molnar To: Chuck Robey cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind > of more modest setups might be available? I know you probably aren't a > walking database of such things, but if you come up with occaisonal > pointers to folks selling motherboards that might fit into pc cases, and > maybe use PCI, and the location of sparc docs on the web, it'd be nice to > post such things. I'd read them, and probably lots of others would too. > It's likely (working where you do) that you'd be more likely to fall into > that kind of info than I would. Do you not need to speand alot of money. I have 2 suns i currently use and i spent under 1k together. This is what you can do, look at the usenet forsale workstation or forsale.sun groups and buy one from there. I got a LX (sun4m) with 32MB ram, 1G HD, type5 keyboard+mouse with shipping for $650. And the ELC (sun4c) with 24MB RAM, type 4 keyboard+mouse for $150. I had a 1G external drive already for the ELC. It was notmuch in the way of cash. And for monitors the ELC is builtin and the LX for awaile ran a illyma (sp?) 17in with a 13w3->vga cable, and the monitor is on a switchbox so my other PC can use it. But then i picked up a 14in sun monitor for the trade of a 486dx2-80 chip motherboad and 12mb of ram. Usenet is your best bet, unless you can convince some cs dept of a college to give one to you. And just look for FAQs on the net. The best thing you can ever get is the Feild Enginers Handbook, it is the bible of sun hardware. That should give you a lil taste on the cheep and easy info you can get on a sun. Oh, I am volenteering help for testing the port for the sun4c, I can not give up my LX yet. Stefan Molnar Slightly Silly From owner-freebsd-hackers Wed Dec 10 13:03:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18230 for hackers-outgoing; Wed, 10 Dec 1997 13:03:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18224 for ; Wed, 10 Dec 1997 13:03:12 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA19604; Wed, 10 Dec 1997 14:02:38 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd019588; Wed Dec 10 14:02:36 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA23155; Wed, 10 Dec 1997 14:02:31 -0700 (MST) From: Terry Lambert Message-Id: <199712102102.OAA23155@usr09.primenet.com> Subject: Re: Why so many steps to build new kernel? To: cfaehl@cs.unm.edu (Chris Faehl) Date: Wed, 10 Dec 1997 21:02:31 +0000 (GMT) Cc: ksmm@cybercom.net, freebsd-hackers@freebsd.org In-Reply-To: from "Chris Faehl" at Dec 10, 97 12:24:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Anyway, the biggest reason I can come up with AGAINST GUIs for kernel > configuration is the obscuration of the original, has-to-exist kernel > config file. That is, the config file still has to exist, so why not > just muck about with it directly? I'd be happier with the config file not existing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Dec 10 13:07:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18565 for hackers-outgoing; Wed, 10 Dec 1997 13:07:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from superior.mooseriver.com (dynamic44.pm05.san-mateo.best.com [205.149.176.44]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18558 for ; Wed, 10 Dec 1997 13:07:30 -0800 (PST) (envelope-from jgrosch@superior.mooseriver.com) Received: (from jgrosch@localhost) by superior.mooseriver.com (8.8.7/8.8.5) id NAA17850; Wed, 10 Dec 1997 13:07:20 -0800 (PST) Message-ID: <19971210130720.53173@mooseriver.com> Date: Wed, 10 Dec 1997 13:07:20 -0800 From: Josef Grosch To: Brian Handy Cc: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port Reply-To: jgrosch@superior.mooseriver.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Brian Handy on Wed, Dec 10, 1997 at 12:13:11PM -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 12:13:11PM -0800, Brian Handy wrote: > Chuck writes: > > >I would also be a little curious about the availability of sparc hardware > >for hobbyist folk. Few of us can afford $10K servers, but what other kind > >of more modest setups might be available? > > Now, I know we have quite a few older Sparc 10's and such running around > that seem like they're getting along in vintage. I'm not going to be able > to liberate any of these, but it suggests to me there probably is a bunch > of this sort of stuff out there for cheap. How different are the > different Sparc's? If people want to start hunting for one, is this like > the alpha fiasco -- you need "this" model in order to play? > > Also, from the viewpoint of us clueless user-types, can anybody wax on the > advantages of buying a Sparc platform? My familiarity is mostly with > x86's and Alphas...not many suns in-house. "Why will my next h/w be a > sun?" :-) > My experance with SPARCs is limited but basicly they come in 3 flavors, sun4, sun4m, and sun4u. SPARC 1, 1+, 2, IPC, and IPX (i think) were sun4s. meaning that were uniprocessor machine and were not capable of supporting multiprocessor. SPARC 5, 10, and 20 are sun4m which means they do support multiprocessor. The ultra 1, ultra 2, and up are sun4u. Not really sure what the differance between the sun4m and the sun4u is. I'm doing this from memory so I sure I munged a few details. Josef -- Josef Grosch | Another day closer to a | FreeBSD 2.2.5 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses From owner-freebsd-hackers Wed Dec 10 13:09:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18825 for hackers-outgoing; Wed, 10 Dec 1997 13:09:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from superior.mooseriver.com (dynamic44.pm05.san-mateo.best.com [205.149.176.44]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18816 for ; Wed, 10 Dec 1997 13:08:54 -0800 (PST) (envelope-from jgrosch@superior.mooseriver.com) Received: (from jgrosch@localhost) by superior.mooseriver.com (8.8.7/8.8.5) id MAA17718; Wed, 10 Dec 1997 12:40:21 -0800 (PST) Message-ID: <19971210124021.52222@mooseriver.com> Date: Wed, 10 Dec 1997 12:40:21 -0800 From: Josef Grosch To: freebsd-hackers@freebsd.org Subject: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Reply-To: jgrosch@superior.mooseriver.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 02:57:35PM -0500, Chuck Robey wrote: > On Wed, 10 Dec 1997, Jason Evans wrote: > [ DELETED ] > > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind > of more modest setups might be available? I know you probably aren't a > walking database of such things, but if you come up with occaisonal > pointers to folks selling motherboards that might fit into pc cases, and > maybe use PCI, and the location of sparc docs on the web, it'd be nice to > post such things. I'd read them, and probably lots of others would too. > It's likely (working where you do) that you'd be more likely to fall into > that kind of info than I would. > I have been looking around for used SPARC equipment recently. I have been seeing SPARC 5 with a 1 or 2 gig drive, 64 meg of ram and no monitor going for between $900.00 and $1500.00. I have seen SPARC 2, IPC, and IPX going for in the $500.00 to $1000.00 range. This, of course, depends on how much memory and disk the system has and how much the owner thinks it worth. Sun monitors are _DAMED_ expensive. I have yet to see one for under $1500.00. I will most likely end up running mine headless. Josef -- Josef Grosch | Another day closer to a | FreeBSD 2.2.5 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses From owner-freebsd-hackers Wed Dec 10 13:11:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19100 for hackers-outgoing; Wed, 10 Dec 1997 13:11:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19074 for ; Wed, 10 Dec 1997 13:11:01 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id NAA21709 for ; Wed, 10 Dec 1997 13:11:00 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 13:11:00 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-Reply-To: <199712101002.LAA14559@rvc1.informatik.ba-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I was just thinking about this. I've been playing around with cgic lately and I think it would be hilarious to have the kernel configuration on the local web server (password protected of course). I saw an article the other day about windows 98 (not that I really care what MS is doing), but apparently they are going web browser-centric, certainly that is pushing it, but I was thinking how easy it might be set up something like this. I only considered it because I have decided to rewrite the interface for a particular software package I worked on last summer to have a significant portion of its interface web-able. This is less because I really want to a more because *I HATE* designing X interfaces and this way I can have someone else do it. Plus windows can be a client to the server process (if it was up to me people would just telnet into the server port and use it that way). On Wed, 10 Dec 1997, Wolfgang Helbig wrote: > > We know, and have for a long time, about Linux's curses and X based > > kernel configurators. Who's going to do the work of implementing > > something similar? *That's* been the big mystery up until now. :) > > Hmm, I'm glad we are *not* imitating Linux in this respect. > I feel much more comfortable with the FreeBSD way, i. e. editing > the kernel configuration. It makes you think you know what you're > doing, you can easily change it and you know what you have to save > if you want to build a different kernel. > > I feel no need at all for a new kernel configuration UI, which > would make things more complicated and less transparent for > the user. > > Wolfgang > From owner-freebsd-hackers Wed Dec 10 13:19:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19793 for hackers-outgoing; Wed, 10 Dec 1997 13:19:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA19781 for ; Wed, 10 Dec 1997 13:19:29 -0800 (PST) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.fokus.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with SMTP id WAA09087; Wed, 10 Dec 1997 22:19:25 +0100 (MET) Received: by sherwood.fokus.gmd.de (SMI-8.6/SMI-SVR4) id WAA06946; Wed, 10 Dec 1997 22:18:57 +0100 Date: Wed, 10 Dec 1997 22:18:57 +0100 From: schilling@fokus.gmd.de (Joerg Schilling) Message-Id: <199712102118.WAA06946@sherwood.fokus.gmd.de> To: freebsd-hackers@freebsd.org Cc: schilling@fokus.gmd.de Subject: Re: Cdrecord (was HP 6020 drive compatibility) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From tiago@eps.ufsc.br Wed Dec 10 21:17:40 1997 >> Joerg Wunsch writes: >> >> >Only very slowly. You could also have a look at Joerg Schilling's >> >cdrecord tool, it's in the ports collection, and basically bypasses >> >the kernel driver. >> >> Wrong: Cdrecord does not bypass the kernel driver! >> >> Cdrecord uses the SCSI kernel driver to send SCSI commands to the drive. >> The way cdrecord does this, is the only portable way across different >> UNIX platforms. >> >> FreeBSD/NetBSD/OpenBSD > ^^^^^^^ -> is there any plan for supporting ATAPI CD recorders >under FreeBSD? Cdrecord-1.6a7 already supports ATAPI devices. If the FreeBSD hackers provide me with a working ATAPI SCSI emulation. you will be able to use it instantely. Joerg http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix From owner-freebsd-hackers Wed Dec 10 13:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20260 for hackers-outgoing; Wed, 10 Dec 1997 13:26:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20225 for ; Wed, 10 Dec 1997 13:25:35 -0800 (PST) (envelope-from rkw@shrimp.dataplex.net) Received: (from root@localhost) by shrimp.dataplex.net (8.8.5/8.8.5) id PAA20498 for hackers@freebsd.org; Wed, 10 Dec 1997 15:25:33 -0600 (CST) Date: Wed, 10 Dec 1997 15:25:33 -0600 (CST) From: Richard Wackerbarth Message-Id: <199712102125.PAA20498@shrimp.dataplex.net> To: hackers@freebsd.org Subject: Using CTM and the 2.2.5 CD's Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am pleased to announce that the checkpoints taken in the CTM streams back in late October have now been confirmed to work with the 2.2.5 CD's. If you are interested in maintaining an up-to-date copy of the cvs tree or any of the source trees, I strongly recommend that you obtain this Release CD set to use as a starting point. The following script will allow you to extract the cvs tree from the CD and bring it up to date with the CTM deltas. You can then continue to update with additional deltas as they are generated. I will soon be publishing similar scripts for the ports tree and the src trees for 2.1, 2.2, and "current". It is my intention to continue to generate similar checkpoints every time that we generate a new CD set. I hope that you will find this useful. Richard Wackerbarth ctm@FreeBSD.ORG - - - - # 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: # # CTM_STARTUP.sh # echo x - CTM_STARTUP.sh sed 's/^X//' >CTM_STARTUP.sh << 'END-of-CTM_STARTUP.sh' X#!/bin/sh X X# This script initializes your local cvs tree X# from the 2.2.5 distribution CD X# and brings it up to date with CTM deltas X X# Initialization X# 1) Mount the #3 CD from the 2.2.5 release set X# For example: mount -t cd9660 /dev/cd0c /mnt X# 2) Define its location in the shell variable CD_2_2_5_3 X# For example: CD_2_2_5_3=/mnt X# 3) Create the directory for your master copy of the cvs tree X# For example: mkdir /pub/FreeBSD/FreeBSD-CVS X# 4) Define its location in the shell variable CVSROOT X# For example: CVSROOT=/pub/FreeBSD/FreeBSD-CVS X# 5) Create a directory for the CTM updates X# For example: mkdir /pub/FreeBSD/CTM/cvs-cur X# 6) Define its location in the shell variable CTMDIR X# For example: CTMDIR=/pub/FreeBSD/CTM/cvs-cur X# 7) Populate the CTMDIR with deltas beginning with cvs-cur.3754.gz X# 8) Execute this script X# For example: sh CTM_STARTUP.sh X Xcd ${CVSROOT} X X# The script will copy the tree from the CD. Xcp -R -p ${CD_2_2_5_3}/CVS-Repository/* ${CVSROOT} X X# Clean up some files that should not be there Xrm ${CVSROOT}/src/gnu/usr.bin/cc/cc1plus/#cvs.rfl.whisker.cdrom.com.9903 \ X ${CVSROOT}/src/share/man/man0/#cvs.rfl.whisker.cdrom.com.277 \ X ${CVSROOT}/src/sys/netatalk/#cvs.cvsup-3725.67 \ X ${CVSROOT}/src/usr.bin/sgmls/sgmls/#cvs.rfl.whisker.cdrom.com.684 \ X ${CVSROOT}/src/usr.bin/tip/libacu/#cvs.rfl.whisker.cdrom.com.7854 X X# And adds the .ctm_status file Xecho "cvs-cur 3753" >.ctm_status X X# And applies the pending deltas Xctm ${CTMDIR}/* END-of-CTM_STARTUP.sh exit From owner-freebsd-hackers Wed Dec 10 13:26:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20353 for hackers-outgoing; Wed, 10 Dec 1997 13:26:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20331 for ; Wed, 10 Dec 1997 13:26:37 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id NAA21818; Wed, 10 Dec 1997 13:26:31 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 13:26:31 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Jason Evans cc: hackers@freebsd.org Subject: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wouldn't porting -stable first be a better project, after all you want a quality product and that is what stable is. If it was me I would start there, cvsup to RELENG_22 and take a crack at it. I'd love to port to some architecture other that x86, but I first have to get a decent architecture to port to(not saying that sparc isn't I just haven't really looked into them). I'd actually like to design my own architecture by the time I get out of school, at which point I'll probably want to port some version of UNIX to it just for development purposes if nothing else. Something interesting to do would be to design a virtual machine on an x86 freebsd machine, obviously a C compiler also then port to that virtual machine. In fact I think I'll do this! From owner-freebsd-hackers Wed Dec 10 14:24:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25058 for hackers-outgoing; Wed, 10 Dec 1997 14:24:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25038 for ; Wed, 10 Dec 1997 14:23:58 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA04204; Wed, 10 Dec 1997 14:11:43 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004199; Wed Dec 10 14:11:41 1997 Message-ID: <348F1305.60E33853@whistle.com> Date: Wed, 10 Dec 1997 14:09:10 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Eivind Eklund CC: "Jamil J. Weatherbee" , hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help References: <86ra7lw474.fsf@bitbox.follo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund wrote: > > "Jamil J. Weatherbee" writes: > > > Here is a diagram of what I want to do (if this is possible): > > I have not been able to get this configured: > > > > The ip addresses have been altered to protect innocent networks of > > unprotected wincrap 95 machines. > > > > > > service provider ------\ > > | > > | > > Ascend Pipeline 50 > > 123.123.62.161/27 (router0) > > | > > | <----- crossover cable > > (ed1) > > FreeBSD Firewall > > 123.123.62.162/27 (core)--(ppp0-modem(remote user) > > (ed0) proxied to > > | ethernet > > | > > | > > Windoze ethernet 123.123.62.161-190/27 > > This one seems to be possible, but it will be somewest, though) > > Eivind. better answer.. use address translation between the ascend and the FBSD machine (using natd) allloceate 192.168.1.x to the mahines that dial in let the FBSD machien use normal routing.. From owner-freebsd-hackers Wed Dec 10 14:55:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27986 for hackers-outgoing; Wed, 10 Dec 1997 14:55:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net ([207.31.78.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27937 for ; Wed, 10 Dec 1997 14:54:52 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA05177; Wed, 10 Dec 1997 17:54:14 -0500 (EST) Date: Wed, 10 Dec 1997 17:54:14 -0500 (EST) From: "Matthew N. Dodd" To: Chuck Robey cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Chuck Robey wrote: > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind > of more modest setups might be available? Hopefully such a port would run on 4m/4c hardware as well as 4u. If that is the case then reasonablly priced systems are not hard to come by at all. In addition, the SMP Sparc 10/20 systems, whil aging are still quite nice. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Wed Dec 10 14:56:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28126 for hackers-outgoing; Wed, 10 Dec 1997 14:56:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28073 for ; Wed, 10 Dec 1997 14:55:54 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id OAA19342; Wed, 10 Dec 1997 14:55:42 -0800 Date: Wed, 10 Dec 1997 14:55:42 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: Stefan Molnar cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Stefan Molnar wrote: > Oh, I am volenteering help for testing the port for the sun4c, I can > not give up my LX yet. Great, I'll take you up on that offer at the appropriate time. Thanks, Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 14:57:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28446 for hackers-outgoing; Wed, 10 Dec 1997 14:57:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28424 for ; Wed, 10 Dec 1997 14:57:43 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA284 for ; Wed, 10 Dec 1997 17:59:44 -0500 Received: by smginc.com with Microsoft Mail id <348F48CE@smginc.com>; Wed, 10 Dec 97 17:58:38 PST From: Adam Turoff To: hackers Subject: RE: I seriously need some networking help Date: Wed, 10 Dec 97 17:57:00 PST Message-ID: <348F48CE@smginc.com> Encoding: 68 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Eivind Eklund wrote: > > > > "Jamil J. Weatherbee" writes: > > > > > Here is a diagram of what I want to do (if this is possible): > > > I have not been able to get this configured: > > > > > > The ip addresses have been altered to protect innocent networks of > > > unprotected wincrap 95 machines. > > > > > > > > > service provider ------\ > > > | > > > | > > > Ascend Pipeline 50 > > > 123.123.62.161/27 (router0) > > > | > > > | <----- crossover cable > > > (ed1) > > > FreeBSD Firewall > > > 123.123.62.162/27 (core)--(ppp0-modem(remote user) > > > (ed0) proxied to > > > | ethernet > > > | > > > | > > > Windoze ethernet 123.123.62.161-190/27 > > > > This one seems to be possible, but it will be somewest, though) > > > > Eivind. > > better answer.. > use address translation between the ascend and the FBSD machine > (using natd) > > allloceate 192.168.1.x to the mahines that dial in > let the FBSD machien use normal routing.. Just another datapoint. I have a similar network setup: FBSD box with two identical PCI Ethernet cards, Crossover cable to a Cicso router std. cable into an ethernet hub The box works fine on both networks. The only problem is that whenever the T1 goes down, the ethernet port on the router goes down. Apparently, when FBSD detects a dead network interface, it removes all the routes associated with that interface. Therefore, everytime I get a hiccup on the T1, I need to telnet in on the other interface and reboot the box in order for the box to straighten itself out. I looked into some docs and found a mention of RIP doing this and routed working with RIP to discover and fix problems like this. (I took the recommendation from the man page and reset the timeout to 45 seconds.) This has been happening a lot recently, and it caused the "stupid fast webserver" to be offline for a weekend. Any thoughts? Thanks in advance, -- Adam. adamt@smginc.com From owner-freebsd-hackers Wed Dec 10 14:57:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28464 for hackers-outgoing; Wed, 10 Dec 1997 14:57:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28430 for ; Wed, 10 Dec 1997 14:57:47 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA290 for ; Wed, 10 Dec 1997 17:59:49 -0500 Received: by smginc.com with Microsoft Mail id <348F48D3@smginc.com>; Wed, 10 Dec 97 17:58:43 PST From: Adam Turoff To: hackers Subject: FW: Why so many steps to build new kernel? Date: Wed, 10 Dec 97 17:58:00 PST Message-ID: <348F48D3@smginc.com> Encoding: 42 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was just thinking about this. I've been playing around with cgic lately > and I think it would be hilarious to have the kernel configuration on the > local web server (password protected of course). I saw an article the > other day about windows 98 (not that I really care what MS is doing), but > apparently they are going web browser-centric, certainly that is pushing > it, but I was thinking how easy it might be set up something like this. > I only considered it because I have decided to rewrite the interface for a > particular software package I worked on last summer to have a significant > portion of its interface web-able. This is less because I really want to > a more because *I HATE* designing X interfaces and this way I can have > someone else do it. Plus windows can be a client to the server process > (if it was up to me people would just telnet into the server port and use > it that way). I don't know about that. Sounds like a huge security hole. If you're interested in going town this path, I'd strongly recommend taking a page from Netscape. Their servers use an admin server to administer all instances of their httpd on a box. When installing the server package, the install program picks a random port > 1024 to use for running the admin server. The sysadmin can change this port to something useful, but the idea here is that the administration is not running on any "standard" port. I certainly wouldn't want anything like kernel configs or sysadmin type stuff happening over a standard port like 80 or 8080 with clear text passwords. If I could use SSL on some bizzaro port number, that would be really worth having. :-) -- Adam PS: Setting two servers to talk to each other so that they can replicate configurations is left as an exercise for the reader. From owner-freebsd-hackers Wed Dec 10 14:58:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28599 for hackers-outgoing; Wed, 10 Dec 1997 14:58:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28591 for ; Wed, 10 Dec 1997 14:58:30 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id OAA23429; Wed, 10 Dec 1997 14:58:26 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 14:58:26 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Jason Evans cc: hackers@freebsd.org Subject: Re: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The console would need to be implemented in X, but I am actually more interested in the virtual machine itself. On Wed, 10 Dec 1997, Jason Evans wrote: > On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > > Something interesting to do would be to design a virtual machine on an x86 > > freebsd machine, obviously a C compiler also then port to that virtual > > machine. In fact I think I'll do this! > > Now here's someone with some spare time! =) > > Jason > > Jason Evans > Email: [jasone@canonware.com] > Home phone: [(650) 856-8204] > Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] > > From owner-freebsd-hackers Wed Dec 10 15:00:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28889 for hackers-outgoing; Wed, 10 Dec 1997 15:00:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net ([207.31.78.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28788 for ; Wed, 10 Dec 1997 14:59:53 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA05241; Wed, 10 Dec 1997 17:59:28 -0500 (EST) Date: Wed, 10 Dec 1997 17:59:28 -0500 (EST) From: "Matthew N. Dodd" To: Brian Handy cc: Chuck Robey , Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Brian Handy wrote: > Also, from the viewpoint of us clueless user-types, can anybody wax on the > advantages of buying a Sparc platform? My familiarity is mostly with > x86's and Alphas...not many suns in-house. "Why will my next h/w be a > sun?" :-) Workstation hardware doesn't require as many dead-chickens. Its much more stable and well behaved. I buy x86 hardware because it is too cheap not to. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Wed Dec 10 15:00:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28897 for hackers-outgoing; Wed, 10 Dec 1997 15:00:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28783 for ; Wed, 10 Dec 1997 14:59:52 -0800 (PST) (envelope-from andrew@zeta.org.au) Received: from gurney.reilly.home (d14.syd2.zeta.org.au [203.26.11.14]) by godzilla.zeta.org.au (8.8.7/8.6.9) with ESMTP id JAA10342; Thu, 11 Dec 1997 09:54:59 +1100 Received: (from andrew@localhost) by gurney.reilly.home (8.8.7/8.8.5) id JAA00920; Thu, 11 Dec 1997 09:49:45 +1100 (EST) From: Andrew Reilly Message-Id: <199712102249.JAA00920@gurney.reilly.home> Date: Thu, 11 Dec 1997 09:49:44 +1100 (EST) Subject: Re: Why so many steps to build new kernel? To: cfaehl@cs.unm.edu cc: ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 10 Dec, Chris Faehl wrote: > Anyway, the biggest reason I can come up with AGAINST GUIs for kernel > configuration is the obscuration of the original, has-to-exist kernel > config file. That is, the config file still has to exist, so why not > just muck about with it directly? This thread has prompted me to think about UIs a bit, and I'd like to see if anyone else has come to a similar conclusion. Kernal configuration is an excellent example. The kernel config file is quite simple in concept, easy to edit, easy to run config and then make and install a kernel. Never the less it is extremely daunting to newcommers because this simplicity rides on the requirement for deep knowledge of what the options ARE, what they MEAN, and what the DEPENDANCIES between them are. At the moment, this information resides in the brains of gurus, and is otherwise scattered through the man pages, the LINT config file, and the source code itself. A user interface that just wraps this up in forms and dialogs is obviously pointless. But a user interface that /contains/ all of the (large amounts of) information described above would be a significant boon. It would probably also be a significant development and maintenance burdon, which is why those who know how complicated it would really need to be have not done it. Imaging scrolling through the options window, able to switch options on or off, or include them or not (as in sysinstall), and having immediate access to descriptions of the option in question, required or incompatible options. These dependancies could be enforced, to avoid building broken configurations. Keeping track of interrupt numbers, collision requirements, busses, etc is just more of the same, and hairier. > Regarding GUIs as an affront to computer science - there seems to be a > sizable portion of folks who think that possession of a GUI makes a > program great. I especially see this attitude wrt to NT - administration > of these boxes is touted to be 'easier' because of the boatload of > (poor) GUI chrome they've dumped on to it. Oh, please... all this does > is encourage the 'reinstall the OS when something breaks' mode of > operation, since the real guts of the damn thing are completely obscured. I agree that most of the GUIs I've seen on Windows are broken, but that's because they do (as you say) obscure the underlying mechanism. What I would like to see is an interface that /illuminates/ the mechanism. -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-hackers Wed Dec 10 15:08:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29940 for hackers-outgoing; Wed, 10 Dec 1997 15:08:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net ([207.31.78.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29915 for ; Wed, 10 Dec 1997 15:08:03 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id SAA05413; Wed, 10 Dec 1997 18:07:57 -0500 (EST) Date: Wed, 10 Dec 1997 18:07:56 -0500 (EST) From: "Matthew N. Dodd" To: Josef Grosch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-Reply-To: <19971210124021.52222@mooseriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Josef Grosch wrote: > Sun monitors are _DAMED_ expensive. I have yet to see one for under > $1500.00. I will most likely end up running mine headless. New ones may be rather expensive but I've seen no shortage of cheap used sun monitors. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Wed Dec 10 15:11:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA00452 for hackers-outgoing; Wed, 10 Dec 1997 15:11:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA00444 for ; Wed, 10 Dec 1997 15:11:51 -0800 (PST) (envelope-from root@acroal.com) Received: from localhost (root@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id PAA25424 for ; Wed, 10 Dec 1997 15:11:50 -0800 (PST) (envelope-from root@acroal.com) Date: Wed, 10 Dec 1997 15:11:50 -0800 (PST) From: 0000-Administrator To: hackers@freebsd.org Subject: Off topic on the freebsd vm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk the instruction set will be call PISS "Portable Instruction Set System" From owner-freebsd-hackers Wed Dec 10 15:13:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA00663 for hackers-outgoing; Wed, 10 Dec 1997 15:13:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marvin.cs.dis.qut.edu.au (dave@marvin.cs.dis.qut.edu.au [131.181.124.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA00629 for ; Wed, 10 Dec 1997 15:12:53 -0800 (PST) (envelope-from dave@marvin.cs.dis.qut.edu.au) Received: from localhost (dave@localhost) by marvin.cs.dis.qut.edu.au (8.8.5/8.8.5) with SMTP id JAA21334 for ; Thu, 11 Dec 1997 09:12:14 +1000 Date: Thu, 11 Dec 1997 09:12:13 +1000 (EST) From: David Richards To: BSD Hackers Subject: IP Firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, I did actually look at man 4 ipfirewall. But, I do not see how this is appropriate to an application that will set filters in place. Let me explain, The parameters are (in order): raw_socket, IPPROTO_IP, ipfw option, struct ipfw, size I am fine with them all, except raw_socket. Where did this socket come from?? Let's take an example from the ipfw.c when a flush is being done: setsockopt(s,IPPROTO_IP,IP_FW_FLUSH,NULL,0) Now, where does "s" come from?? I notice that it is a global variable, but i can't find where any initialisation occurs ... can someone please explain this concept to me? Thanks, Dave. -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- David Richards Ph: +61 7 3864 4347 Network Programmer Fax: +61 7 3864 5272 Computing Services E-mail: dj.richards@qut.edu.au Queensland University of Technology Brisbane, Australia -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- From owner-freebsd-hackers Wed Dec 10 15:16:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01162 for hackers-outgoing; Wed, 10 Dec 1997 15:16:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01147 for ; Wed, 10 Dec 1997 15:16:02 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id PAA19469; Wed, 10 Dec 1997 15:15:59 -0800 Date: Wed, 10 Dec 1997 15:15:58 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio Reply-To: Jason Evans To: Brian Handy cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Brian Handy wrote: > Now, I know we have quite a few older Sparc 10's and such running around > that seem like they're getting along in vintage. I'm not going to be able > to liberate any of these, but it suggests to me there probably is a bunch > of this sort of stuff out there for cheap. How different are the > different Sparc's? If people want to start hunting for one, is this like > the alpha fiasco -- you need "this" model in order to play? I don't think it will be as bad as having to have a particular model. However, whenever I or anyone else at some point says, "Such and such works," it's necessarily implicit that it works on the hardware it was tested on, and that if you have something else, you may not see the same results. Sun has several different lines of machines, and honestly I'm not too clear on how many differences there are between them, or even what all of the lines are. The first SPARC I ever sat at was a SPARC 20 running Solaris 2.5, followed shortly thereafter by an Ultra (before they were released). With enough input from people using older machines, I expect we'll be able to get it running on lots of different Sun hardware. > Also, from the viewpoint of us clueless user-types, can anybody wax on the > advantages of buying a Sparc platform? My familiarity is mostly with > x86's and Alphas...not many suns in-house. "Why will my next h/w be a > sun?" :-) The hardware is plain out better quality than what you normally find in the PC world. They always use parity RAM! When parts fail, you can usually tell which part failed, because the system is helpful in figuring it out. Sun hardware designers generally pay better attention to detail, so that there aren't silly bottlenecks in the final product. Traditionally, Suns have also been very spendy, though some of the newer PCI-based machines are dropping into the price range mere mortals can afford. On the down side, they sell a hardware/software bundle (you can buy them separately, but until recently there were no other notable OSes to run, so Solaris was it), which means you see some of the same proprietary attitudes as Apple (Open Boot PROM, for example, is a major stumbling block for an OS port), though Sun seems to mostly sell proprietary implementations of open specifications. Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 15:20:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01587 for hackers-outgoing; Wed, 10 Dec 1997 15:20:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01533 for ; Wed, 10 Dec 1997 15:20:25 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA15418 for ; Wed, 10 Dec 1997 15:19:54 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma015416; Wed Dec 10 15:19:46 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id PAA22111 for freebsd-hackers@freebsd.org; Wed, 10 Dec 1997 15:19:45 -0800 (PST) From: Archie Cobbs Message-Id: <199712102319.PAA22111@bubba.whistle.com> Subject: memcmp() and memcpy() To: freebsd-hackers@freebsd.org Date: Wed, 10 Dec 1997 15:19:45 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to the gcc info page, gcc will automatically inline the memcpy() and memcmp() functions. The kernel header files define memcpy() but not memcmp() for some reason. How come memcmp() is not defined? This is in reference to 2.2.5... haven't looked at -current. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Dec 10 15:23:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01896 for hackers-outgoing; Wed, 10 Dec 1997 15:23:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from onyx.atipa.com (user6868@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA01874 for ; Wed, 10 Dec 1997 15:22:47 -0800 (PST) (envelope-from freebsd@atipa.com) Received: (qmail-queue invoked by uid 1018); 10 Dec 1997 23:01:45 -0000 Date: Wed, 10 Dec 1997 16:01:45 -0700 (MST) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Josef Grosch cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: <19971210124021.52222@mooseriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have a Sparc to sell if anyone wants to start playing around. Sparc 20 Model 51, 128MB, 20" Trinitron, 6.4GB SCSI, ethernet, Solaris 2.5 CD & Manuals, Informix Online Workgroup Server w/ 10 client licenses and web license), 2X SCSI CD-ROM, PC-layout and Sun-layout KBs, etc. Email privately of interested. Not "cheap" per se, but it is collecting dust over here. I am trying to get rid of it before the end of the year. Kevin On Wed, 10 Dec 1997, Josef Grosch wrote: > On Wed, Dec 10, 1997 at 02:57:35PM -0500, Chuck Robey wrote: > > On Wed, 10 Dec 1997, Jason Evans wrote: > > > > [ DELETED ] > > > > > I would also be a little curious about the availability of sparc hardware > > for hobbyist folk. Few of us can afford $10K servers, but what other kind > > of more modest setups might be available? I know you probably aren't a > > walking database of such things, but if you come up with occaisonal > > pointers to folks selling motherboards that might fit into pc cases, and > > maybe use PCI, and the location of sparc docs on the web, it'd be nice to > > post such things. I'd read them, and probably lots of others would too. > > It's likely (working where you do) that you'd be more likely to fall into > > that kind of info than I would. > > > > I have been looking around for used SPARC equipment recently. I have been > seeing SPARC 5 with a 1 or 2 gig drive, 64 meg of ram and no monitor going > for between $900.00 and $1500.00. I have seen SPARC 2, IPC, and IPX going > for in the $500.00 to $1000.00 range. This, of course, depends on how much > memory and disk the system has and how much the owner thinks it worth. Sun > monitors are _DAMED_ expensive. I have yet to see one for under $1500.00. I > will most likely end up running mine headless. > > > Josef > > -- > Josef Grosch | Another day closer to a | FreeBSD 2.2.5 > jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses > From owner-freebsd-hackers Wed Dec 10 15:24:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02026 for hackers-outgoing; Wed, 10 Dec 1997 15:24:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marvin.cs.dis.qut.edu.au (dave@marvin.cs.dis.qut.edu.au [131.181.124.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02000 for ; Wed, 10 Dec 1997 15:23:56 -0800 (PST) (envelope-from dave@marvin.cs.dis.qut.edu.au) Received: from localhost (dave@localhost) by marvin.cs.dis.qut.edu.au (8.8.5/8.8.5) with SMTP id JAA21612 for ; Thu, 11 Dec 1997 09:23:20 +1000 Date: Thu, 11 Dec 1997 09:23:20 +1000 (EST) From: David Richards To: BSD Hackers Subject: IP Firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, I found the initialisation, please ignore my last e-mail! Sorry, Dave. -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- David Richards Ph: +61 7 3864 4347 Network Programmer Fax: +61 7 3864 5272 Computing Services E-mail: dj.richards@qut.edu.au Queensland University of Technology Brisbane, Australia -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#- From owner-freebsd-hackers Wed Dec 10 15:25:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02196 for hackers-outgoing; Wed, 10 Dec 1997 15:25:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02168 for ; Wed, 10 Dec 1997 15:25:09 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id PAA25591; Wed, 10 Dec 1997 15:25:07 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 15:25:07 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Adam Turoff cc: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: <348F48D3@smginc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This makes no damn difference, obscurity is NOT security. See /usr/ports/net/strobe. > If you're interested in going town this path, I'd strongly recommend > taking a page from Netscape. Their servers use an admin server > to administer all instances of their httpd on a box. When installing > the server package, the install program picks a random port > 1024 > to use for running the admin server. The sysadmin can change > this port to something useful, but the idea here is that the > administration is not running on any "standard" port. > I certainly wouldn't want anything like kernel configs or sysadmin > type stuff happening over a standard port like 80 or 8080 with > clear text passwords. If I could use SSL on some bizzaro > port number, that would be really worth having. :-) > > -- Adam > > PS: Setting two servers to talk to each other so that they can > replicate configurations is left as an exercise for the reader. > From owner-freebsd-hackers Wed Dec 10 15:27:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02496 for hackers-outgoing; Wed, 10 Dec 1997 15:27:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02458 for ; Wed, 10 Dec 1997 15:27:30 -0800 (PST) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.7/8.8.5) with SMTP id SAA00331; Wed, 10 Dec 1997 18:27:12 -0500 (EST) Date: Wed, 10 Dec 1997 18:27:11 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Chuck Robey cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Chuck Robey wrote: > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind How's $750 for an IPX w/17" B&W monitor, 32MB, 2G disk sound? The Sparc 5's aren't that bad either... Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB From owner-freebsd-hackers Wed Dec 10 15:31:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02896 for hackers-outgoing; Wed, 10 Dec 1997 15:31:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02859 for ; Wed, 10 Dec 1997 15:30:33 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id PAA19546; Wed, 10 Dec 1997 15:30:32 -0800 Date: Wed, 10 Dec 1997 15:30:32 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: "J. Weatherbee - Senior Systems Architect" cc: hackers@freebsd.org Subject: Re: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > Wouldn't porting -stable first be a better project, after all you want a > quality product and that is what stable is. If it was me I would start > there, cvsup to RELENG_22 and take a crack at it. Well, it would be easier, but then comes the problem of moving the port to current once it works. That would probably be as bad a doing the port in the first place. From what I understand, FreeBSD 1.1 was ported to SPARC way back, but it never got merged back in to the development tree. I'm guessing it was because of something like this. I don't want to pour blood, sweat, and tears into this port, and then never have it integrated into current. That would almost be worse than never starting in the first place. I've still got a question about maintaining a separate tree that I haven't found a reasonable answer to: Say I grab current, and stay synched with it, but I start making changes to my local tree. As time goes on, I make more and more changes, while my tree still tracks current. At some point, aren't my changes going to cause conflicts that make it a losing battle to keep my own tree? Say in file foo.c George changes lines 10-20 in the main tree, and I change lines 15-20. When I sync my tree with freebsd.org, there will be a conflict. If I manually resolve this conflict, will I have to deal with it repeatedly every time I sync with the main tree? Even if I only have to resolve the conflict once, tracking current can't be automatic, can it? It seems to me that I'd have to manually resolve conflicts. Jason P.S. Please excuse what is likely incorrect terminology for tree synchronization and conflict resolution. What are the proper terms? Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 15:33:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA03201 for hackers-outgoing; Wed, 10 Dec 1997 15:33:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03190 for ; Wed, 10 Dec 1997 15:33:22 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA04719; Wed, 10 Dec 1997 16:32:46 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd004669; Wed Dec 10 16:32:40 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA27170; Wed, 10 Dec 1997 16:32:34 -0700 (MST) From: Terry Lambert Message-Id: <199712102332.QAA27170@usr02.primenet.com> Subject: Re: OS Ports To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Wed, 10 Dec 1997 23:32:34 +0000 (GMT) Cc: jasone@canonware.com, hackers@freebsd.org In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at Dec 10, 97 01:26:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Wouldn't porting -stable first be a better project, after all you want a > quality product and that is what stable is. If it was me I would start > there, cvsup to RELENG_22 and take a crack at it. I'd love to port to > some architecture other that x86, but I first have to get a decent > architecture to port to(not saying that sparc isn't I just haven't really > looked into them). I'd actually like to design my own architecture > by the time I get out of school, at which point I'll probably want to port > some version of UNIX to it just for development purposes if nothing else. You'd have to be crazy to do this instead of using -current. You really want to have to do two ports instead of one? That's what you'd effectively be doing. > Something interesting to do would be to design a virtual machine on an x86 > freebsd machine, obviously a C compiler also then port to that virtual > machine. In fact I think I'll do this! There is a project under way to do something like this for MIPS, PPC, and SPARC (it's much less ambitious; the idea is to let you run MIPS, PPC, or SPARC binaries on other architectures using processor emulation; the same goes for x86, using PCEMU, on non-x86 machines). If you are turly insane, a good project for the insane would be porting PCEMU to JAVA. 8-) 8-). There aren't any good, freely available 68030/68040 processor emulators, nor any good, freely available Alpha emulators, from what I've been able to determine. If you are just into writing an emulator, you may want to tackle one of those. Of the two, the 68040 would be *much* easier to do (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 Wed Dec 10 15:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05474 for hackers-outgoing; Wed, 10 Dec 1997 15:55:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA05468 for ; Wed, 10 Dec 1997 15:55:24 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id PAA25845 for ; Wed, 10 Dec 1997 15:55:24 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 15:55:23 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: hackers@freebsd.org Subject: Proposed code merge, objections? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been told there is no official policy on this, so I want some feedback. I am considering currently a merge of the alog driver (Industrial Computer Source AIO8-P) into -stable. Fortunately it is really not a merge since the driver itself was developed and tested on -stable in the first place and had to be altered for -current. For any of you who don't know what alog is, it is a driver for a Low-Cost ($195) 12 bit analog data-acqusition board with optional externally daisy chained signal conditioners/multiplexers. I am trying to promote this product since I have had very good experience with it. The best thing by far is the capability of attachment of up to 128 channels, at approximately $26/channel (including interface board and multiplexers). Whoa, that means you can actually own one without taking out a second mortgage on you house. I have had this software running on a 48 channel system running -stable for about 3 months, without a problem. In summary, this probably won't effect much of anyone, however I want to make the driver available in RELENG_2_2 since people running data acquisition thingys in a commercial environment like me are running -stable. So next time you go to buy that overpriced Low cost ($700 for 8 channels, no mux w/o external expensive SCXI stuff) National Instruments board, take a look first at Industrial Computer Source. Who I might mention have repaired some digital I/O boards at no cost 3 times in a year that were connected to some faulty equipment that blew them after a few months repeatedly (no more with that crap). I'm not knocking on National Instruments, but their stuff is really Laboratory Quality (which sometimes is not what you want for industrial applications). I plan on (in the future) expanding alog to drive different models of analog boards (anything I can get my hands on). So anyone wanting to permanently donate :) any analog board (in a reasonably unridiculous manner) I will support. I am also considering discussing a general interface to digital I/O boards (as a class), of course only those having some reasonable method of autodetection. From owner-freebsd-hackers Wed Dec 10 16:02:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06186 for hackers-outgoing; Wed, 10 Dec 1997 16:02:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06173 for ; Wed, 10 Dec 1997 16:02:18 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id RAA05456 for hackers@freebsd.org; Wed, 10 Dec 1997 17:02:10 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id RAA01602 for ; Wed, 10 Dec 1997 17:02:13 -0700 (MST) Date: Wed, 10 Dec 1997 17:02:13 -0700 (MST) From: Marc Slemko To: hackers@freebsd.org Subject: tail -f makes my news server reboot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2.2-stable as of late August. 96 megs RAM, lots of IO. I am logged in remotely via ssh. I do a tail -f on my news.notice file. (~14 megs/day) It is actually a: tail -f /cnfs/log/news.notice | egrep -v rejecting\\[perl I put it in the background with ^Z for a while. Perhaps 15 or 20 minutes. I then do a fg. As expected, I get a bunch of data scrolling quickly. What is not expected is that after a bit of it, the machine hangs dead and reboots. No kernel messages logged. I'm guessing it is a panic, but I have never been around to put a console on it and look. (erm... not that I ever think "oh, I am going to crash this machine" before I do it...) This has happened twice. Ideas? I'll try to setup a test system and see if I can reproduce it sometime, but don't have time right now. From owner-freebsd-hackers Wed Dec 10 16:04:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06399 for hackers-outgoing; Wed, 10 Dec 1997 16:04:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06334 for ; Wed, 10 Dec 1997 16:03:56 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id QAA16450; Wed, 10 Dec 1997 16:00:17 -0800 (PST) Message-ID: <19971210160015.21473@micron.mini.net> Date: Wed, 10 Dec 1997 16:00:15 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <21861.881769454@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <21861.881769454@time.cdrom.com>; from Jordan K. Hubbard on Wed, Dec 10, 1997 at 07:57:34AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm sure that if more of these suggestions started being accompanied > by actual working code, they'd meet with a much different reception. > I heard from one guy who was working on something called "kconfig", > but at last update it had bogged down at the most critical stage, that > being the part where all the kernel configuration options are > presented in menu form. The copy I reviewed did everything *but* that > rather important bit. :-) If nobody else steps up an volunteers to within the next few days, I'll do it. What I have in mind is rather simple, but it requires the following : 1) a file, which is MAINTAINED, which contains all of the possible options, their classes, and a simple comment for each one. 2) another file, or part of the file above, which contains all of the possible DEVICES, including pseudo-devices, a few "common" possible conifgurations for each device, and a short comment explaining what each does. Please do not point me at LINT, this does not provide the needed info in a machine-readable format. Also realise that this means that someone will need to keep this file (or files) maintained, so that the "pretty" kernel config system can actually be used to make kernels with new devices. (I wouldn't mind maintaining those files, by watching the incoming CVS messages and then committing the appropriate modifications to the "directory" (that would, of course, require commit priviledges)) Once this "pretty" interface was used to select a set of devices, options, etc, you would have three options : 1) spit this config out to a config(8) input file. I'm assuming I'd be able to read a config(8) file back in (shouldn't be hard, a little work with lex for a few hours) 2) do 1, and autoamtically run config(8). 3) do 2, and run make all (possibly after running make depend) 4) possibly do 3, and run make install I think you get the idea. The input file would allow me to collect data like this on a device or option : device sio desc "Serial Port Driver" bus isa? spl tty vector siointr conf port "IO_COM1" irq 4 conf port "IO_COM2" irq 3 conf port "IO_COM3" irq 5 conf port "IO_COM4" irq 9 option COMCONSOLE "Prefer serial console to video console" option COM_ESP "enable code for Hayes ESP" option COM_MULTIPORT "enable code for some cards with shared IRQS" option DSI_SOFT_MODEM "enable code for DSI Softmodem" option BREAK_TO_DEBUGGER "enable a BREAK from the comconsole to drop to DDB" manpage 4 sio endd This, which I rolled off the top of my head, (so don't bind me to the format) basically has information I gleaned from LINT about the sio device. It says that the short name for it is "Serieal Port Driver", it's available for any of the isa buses, it sits in the tty spl, uses siointr for it's vector function, had the four above common configurations, (which the user could select from as well as defining a "custom" one. This allows for idiot users to say "oh! "COM1".. I know that..") has the above options, whith the short descriptions sitting next to them, and for further information, point the user to the man page sio(4). (In realisty, it would probably be "select here to see the man page" or something) That is the type of info that FreeBSD will need to keep in a machine-readable format in order to be able to generate kernels in a pretty way. ... Note that a utility like this would be very useful as a front end to a dynamically-loadable module system, since the utility could as easily modify a set of loaded modules as anything else. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Wed Dec 10 16:05:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA06639 for hackers-outgoing; Wed, 10 Dec 1997 16:05:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA06629 for ; Wed, 10 Dec 1997 16:05:48 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id QAA25918; Wed, 10 Dec 1997 16:05:40 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 16:05:40 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Terry Lambert cc: jasone@canonware.com, hackers@freebsd.org Subject: Re: OS Ports In-Reply-To: <199712102332.QAA27170@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > There aren't any good, freely available 68030/68040 processor emulators, > nor any good, freely available Alpha emulators, from what I've been able > to determine. If you are just into writing an emulator, you may want > to tackle one of those. Of the two, the 68040 would be *much* easier to > do (IMO). I've actually been getting pretty serious about maybye doing a M68300 emulator, I.E. 68330, 68331, 68332, 68F33, 68334, 68336, 68340, 68341, 68349, or 68360 emulator. Simply because I have some very good familiarity with the 68hc11 series. And the 68300's are actually still being made all of the above for embedded systems (running up to 25Mhz). This makes it a little more testable. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Wed Dec 10 16:08:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07038 for hackers-outgoing; Wed, 10 Dec 1997 16:08:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07022 for ; Wed, 10 Dec 1997 16:08:05 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA20250; Wed, 10 Dec 1997 17:20:58 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd020175; Wed Dec 10 17:20:47 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA28820; Wed, 10 Dec 1997 17:07:12 -0700 (MST) From: Terry Lambert Message-Id: <199712110007.RAA28820@usr02.primenet.com> Subject: Re: Beginning SPARC port To: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu, 11 Dec 1997 00:07:12 +0000 (GMT) Cc: chuckr@glue.umd.edu, jasone@canonware.com, freebsd-hackers@freebsd.org In-Reply-To: <199712102029.UAA00277@fdy2.demon.co.uk> from "Robert Swindells" at Dec 10, 97 08:29:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > http://www.sun.com/microelectronics/SPARCengineUltraAX > > It needs an ATX case though. And about $13,000 it seems, though the refuse to put the price for it on their buy-on-the-web site, apparently. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Dec 10 16:12:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07501 for hackers-outgoing; Wed, 10 Dec 1997 16:12:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07486 for ; Wed, 10 Dec 1997 16:12:23 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id OAA19349; Wed, 10 Dec 1997 14:56:39 -0800 Date: Wed, 10 Dec 1997 14:56:38 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: "J. Weatherbee - Senior Systems Architect" cc: hackers@freebsd.org Subject: Re: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > Something interesting to do would be to design a virtual machine on an x86 > freebsd machine, obviously a C compiler also then port to that virtual > machine. In fact I think I'll do this! Now here's someone with some spare time! =) Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 16:18:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08075 for hackers-outgoing; Wed, 10 Dec 1997 16:18:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08066 for ; Wed, 10 Dec 1997 16:18:30 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA23428; Wed, 10 Dec 1997 17:31:25 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd023403; Wed Dec 10 17:31:20 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA29759; Wed, 10 Dec 1997 17:17:49 -0700 (MST) From: Terry Lambert Message-Id: <199712110017.RAA29759@usr02.primenet.com> Subject: Re: OS Ports To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Thu, 11 Dec 1997 00:17:49 +0000 (GMT) Cc: tlambert@primenet.com, jasone@canonware.com, hackers@freebsd.org In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at Dec 10, 97 04:05:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've actually been getting pretty serious about maybye doing a M68300 > emulator, I.E. 68330, 68331, 68332, 68F33, 68334, 68336, 68340, 68341, > 68349, or 68360 emulator. Simply because I have some very good > familiarity with the 68hc11 series. And the 68300's are actually still > being made all of the above for embedded systems (running up to 25Mhz). > This makes it a little more testable. I'm more interested in the standard processors used in Macintosh, Amiga, and HP/Apollo systems, as far as Motorolla goes. The PPC is mildly interesting (it used to be very interesting until Steve Jobs basically murdered Apple out of nostalgia). The MMU/FPU versions of the chips (030/040) are more interesting because BSD requires paged memory management and (to some extent, and for no good reason) an FPU. The reason this is interesting is that there are already BSD's that run on them with which the emulator can attempt to be binary compatible. AFAIK, there's no NetBSD (for example) for the processors you list. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Dec 10 16:20:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08233 for hackers-outgoing; Wed, 10 Dec 1997 16:20:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08163 for ; Wed, 10 Dec 1997 16:19:57 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id QAA19826; Wed, 10 Dec 1997 16:19:47 -0800 Date: Wed, 10 Dec 1997 16:19:47 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: Terry Lambert cc: Robert Swindells , chuckr@glue.umd.edu, freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: <199712110007.RAA28820@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Terry Lambert wrote: > > http://www.sun.com/microelectronics/SPARCengineUltraAX > > > > It needs an ATX case though. > > And about $13,000 it seems, though the refuse to put the price for > it on their buy-on-the-web site, apparently. It's a bit over-priced, but you'd have an incredibly stacked machine if you put $13,000 into it. The MB/CPU costs about $2900. Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 16:42:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10358 for hackers-outgoing; Wed, 10 Dec 1997 16:42:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10337 for ; Wed, 10 Dec 1997 16:42:30 -0800 (PST) (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.7/8.8.7) id SAA17230; Wed, 10 Dec 1997 18:40:53 -0600 (CST) (envelope-from alex) Message-Id: <199712110040.SAA17230@nash.pr.mcs.net> Date: Wed, 10 Dec 1997 18:40:52 -0600 (CST) From: Alex Nash Reply-To: nash@mcs.com Subject: Re: OS Ports To: tlambert@primenet.com cc: jamil@acroal.com, jasone@canonware.com, hackers@freebsd.org In-Reply-To: <199712102332.QAA27170@usr02.primenet.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 10 Dec, Terry Lambert wrote: > If you are turly insane, a good project for the insane would be porting > PCEMU to JAVA. 8-) 8-). Don't laugh, there's an effort underway to port the 386 emulator, bochs, to Java. Alex From owner-freebsd-hackers Wed Dec 10 16:46:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10869 for hackers-outgoing; Wed, 10 Dec 1997 16:46:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10823 for ; Wed, 10 Dec 1997 16:46:22 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA17658; Wed, 10 Dec 1997 16:46:20 -0800 (PST) Message-ID: <19971210164619.03585@hydrogen.nike.efn.org> Date: Wed, 10 Dec 1997 16:46:19 -0800 From: John-Mark Gurney To: FreeBSD Hackers Subject: merge bpfattach into if_attach... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was just working on the strip star mode driver from NetBSD (it works!) and noticed this really stupid piece of code that I KNOW is in every interface driver: #if NBPFILTER > 0 bpfattach(&sc->sc_if, DLT_SLIP, SLIP_HDRLEN); #endif and just before that code is a call to if_attach... is there any problem by merging these two together? and then in if_attach if NBPFILTER is > 0, call the proper bpfattach routine? it seems really stupid to touch ever driver, when a small modification can improve the code... and yes, I know that it will break the interface that made it so easy to get NetBSD's star mode driver up and running... :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Wed Dec 10 16:50:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11308 for hackers-outgoing; Wed, 10 Dec 1997 16:50:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11289 for ; Wed, 10 Dec 1997 16:50:17 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA01175; Wed, 10 Dec 1997 19:50:03 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712110050.TAA01175@dyson.iquest.net> Subject: Re: OS Ports In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at "Dec 10, 97 01:26:31 pm" To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Wed, 10 Dec 1997 19:50:03 -0500 (EST) Cc: jasone@canonware.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J. Weatherbee - Senior Systems Architect said: > > Wouldn't porting -stable first be a better project, after all you want a > quality product and that is what stable is. > Respectfully, it probably would not be a good idea, but it would be better to start from a recent, stable -current. It is *much* easier to get support from the developers on -current. -stable is approaching a year old now. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Wed Dec 10 16:52:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11565 for hackers-outgoing; Wed, 10 Dec 1997 16:52:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11471 for ; Wed, 10 Dec 1997 16:52:05 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA16110 for freebsd-hackers@freebsd.org; Thu, 11 Dec 1997 01:51:58 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA09610; Thu, 11 Dec 1997 01:48:12 +0100 (MET) Date: Thu, 11 Dec 1997 01:48:12 +0100 (MET) Message-Id: <199712110048.BAA09610@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712092336.AAA04738@uriah.heep.sax.de> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: I seriously need some networking help X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "J. Weatherbee - Senior Systems Architect" wrote: > I attempted making the firewall to router link a 192.168.x.x network, and > using dual ip on it, unfortunately it interesting that the link gets > published by traceroute for instance from the outside world. Sure, but that's only a cosmetical problem. I've seen 10.* intermediate network addressess even on major Internet relays when tracerouting. It should be totally acceptable for an endpoint transient network. Nobody has any need to access the interfaces on this network. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Dec 10 16:52:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11580 for hackers-outgoing; Wed, 10 Dec 1997 16:52:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11534 for ; Wed, 10 Dec 1997 16:52:15 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA16112 for freebsd-hackers@freebsd.org; Thu, 11 Dec 1997 01:52:10 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA09651; Thu, 11 Dec 1997 01:50:35 +0100 (MET) Date: Thu, 11 Dec 1997 01:50:35 +0100 (MET) Message-Id: <199712110050.BAA09651@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712101002.LAA14559@rvc1.informatik.ba-stuttgart.de> In-Reply-To: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Why so many steps to build new kernel? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The Classiest Man Alive wrote: > Why is it that every time somebody suggests making a script or GUI utility > to automate some boring but necessary UNIX process, all you guys who went > to school with Dennis Richie pop out ... I seriously doubt Wolfgang Helbig went to school with Dennis Ritchie. ;-) He approached to us from a non-Unix world at all. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Dec 10 16:54:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA11899 for hackers-outgoing; Wed, 10 Dec 1997 16:54:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA11862 for ; Wed, 10 Dec 1997 16:54:23 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id QAA26350; Wed, 10 Dec 1997 16:54:20 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 16:54:20 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: Terry Lambert cc: hackers@freebsd.org Subject: Re: OS Ports (The Terry Lambert Challenge, Part II) In-Reply-To: <199712110017.RAA29759@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok, terry I'll make you a deal. Show me some processor that has virtual memory constructs that are not ridiculous (like intels), and if you write the code for real<->virtual hardware (i.e. console, disk, etc.) I will code the virtual instruction set. A motorola product would be prefferred because getting detailed manuals from them is painless (and usually free). From owner-freebsd-hackers Wed Dec 10 17:00:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12527 for hackers-outgoing; Wed, 10 Dec 1997 17:00:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from golden.net (golden.net [199.166.210.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA12336 for ; Wed, 10 Dec 1997 16:59:10 -0800 (PST) (envelope-from dchapes@ddm.on.ca) Received: from ymris.ddm.on.ca (cisco1-38.cas.golden.net [207.6.168.38]) by golden.net (8.8.5/8.6.12) with ESMTP id TAA20048 for ; Wed, 10 Dec 1997 19:27:47 -0500 (EST) Received: from squigy.ddm.on.ca (squigy.ddm.on.ca [209.47.139.138]) by ymris.ddm.on.ca (8.8.7/8.8.8) with ESMTP id TAA01788; Wed, 10 Dec 1997 19:26:53 -0500 (EST) (envelope-from dchapes@ymris.ddm.on.ca) Received: (from dchapes@localhost) by squigy.ddm.on.ca (8.8.7/8.8.7) id TAA07700; Wed, 10 Dec 1997 19:26:52 -0500 (EST) Message-ID: <19971210192651.12352@ddm.on.ca> Date: Wed, 10 Dec 1997 19:26:51 -0500 From: Dave Chapeskie To: hackers@freebsd.org Cc: Jason Evans Subject: Re: OS Ports References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Jason Evans on Wed, Dec 10, 1997 at 03:30:32PM -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 03:30:32PM -0800, Jason Evans wrote: > Say I grab current, and stay synched with it, but I start making changes > to my local tree. As time goes on, I make more and more changes, while my > tree still tracks current. At some point, aren't my changes going to > cause conflicts that make it a losing battle to keep my own tree? Say in > file foo.c George changes lines 10-20 in the main tree, and I change lines > 15-20. When I sync my tree with freebsd.org, there will be a conflict. If > I manually resolve this conflict, will I have to deal with it repeatedly > every time I sync with the main tree? > > Even if I only have to resolve the conflict once, tracking current can't > be automatic, can it? It seems to me that I'd have to manually resolve > conflicts. You would only resolve the conflict once (by merging the change with yours). Conflicts like the one you mention aren't too bad. CVS does a good job of marking these out so that they are easy to find and resolve. The real nasty will be logical conflicts (ie you add a call to function foo then someone changes the syntax of calls to foo. Since the changes don't overlap in the files CVS will not catch this) > Jason > > P.S. Please excuse what is likely incorrect terminology for tree > synchronization and conflict resolution. What are the proper terms? Merging and conflict resolution. > Jason Evans > Email: [jasone@canonware.com] > Home phone: [(650) 856-8204] > Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] One thing you have to watch for is that CVSup will overwrite revisions with the same number (last I saw). For example if foo.c is at revision 1.42 and you commit 1.43 to your local tree. When 1.43 is committed to the real tree, CVSup will blow away your change. The same thing applies to tag names. Although this may not directly help you here is what I've done in the past. I create a branch from a release point (ie RELENG_2_2_RELEASE) and put all changes in there. Then when I want to sync up with a new release I do a CVS merge. For example, if I called my local branch LOCAL_2_2 then I'd merge the changes from revision RELENG_2_2_RELEASE to revision LOCAL_2_2 and apply this to a new branch from RELENG_2_5_RELEASE called LOCAL_2_5 (via a single CVS command). This works well for the kind of changes I make since it limits how often I need to fix conflicts and because I need to run stable. (Note with local branches it's still possibly to get your changes overwritten if someone else makes a branch on the real tree at the same point. One way to avoid this is to modify your local CVS to be able to use a branch number other than 0). Following current would seem to be a little more problematic unless you only periodicly do cvs merges. Perhaps you can do something with the vendor branch stuff. You'll have to find a good solution from a CVS guru. -- Dave Chapeskie, DDM Consulting E-Mail: dchapes@ddm.on.ca From owner-freebsd-hackers Wed Dec 10 17:20:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13736 for hackers-outgoing; Wed, 10 Dec 1997 17:20:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13655 for ; Wed, 10 Dec 1997 17:19:54 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id UAA01319; Wed, 10 Dec 1997 20:19:39 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712110119.UAA01319@dyson.iquest.net> Subject: Re: OS Ports In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at "Dec 10, 97 05:05:53 pm" To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Wed, 10 Dec 1997 20:19:39 -0500 (EST) Cc: toor@dyson.iquest.net, jasone@canonware.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J. Weatherbee - Senior Systems Architect said: > > Boy I got flamed for that remark, my point was that if he is going to do a > port of FreeBSD and it is going to be meaningful it needs to be stable > (Theyv'e already got a Linux port for SPARCS). I'm not saying that > -current is not stable, maybye what I am trying to say is that he needs > both. Anyway do you want everyone using SPARC FreeBSD to be running > -current? > Anyway your in for a big project. > I am definitely not flaming you, but -current is stable enough as a base. There will be improvements and enhancements along the way. If we started with -stable, it is unlikely that the Sparc port would ever catch up to the X86 port. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Wed Dec 10 17:21:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13923 for hackers-outgoing; Wed, 10 Dec 1997 17:21:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13890 for ; Wed, 10 Dec 1997 17:20:59 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id RAA26457; Wed, 10 Dec 1997 17:05:53 -0800 (PST) (envelope-from jamil@acroal.com) Date: Wed, 10 Dec 1997 17:05:53 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: "John S. Dyson" cc: jasone@canonware.com, hackers@FreeBSD.ORG Subject: Re: OS Ports In-Reply-To: <199712110050.TAA01175@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Boy I got flamed for that remark, my point was that if he is going to do a port of FreeBSD and it is going to be meaningful it needs to be stable (Theyv'e already got a Linux port for SPARCS). I'm not saying that -current is not stable, maybye what I am trying to say is that he needs both. Anyway do you want everyone using SPARC FreeBSD to be running -current? Anyway your in for a big project. On Wed, 10 Dec 1997, John S. Dyson wrote: > J. Weatherbee - Senior Systems Architect said: > > > > Wouldn't porting -stable first be a better project, after all you want a > > quality product and that is what stable is. > > > Respectfully, it probably would not be a good idea, but it would be better to > start from a recent, stable -current. It is *much* easier to get support from > the developers on -current. -stable is approaching a year old now. > > -- > John > dyson@freebsd.org > jdyson@nc.com > From owner-freebsd-hackers Wed Dec 10 17:28:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14590 for hackers-outgoing; Wed, 10 Dec 1997 17:28:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14517 for ; Wed, 10 Dec 1997 17:28:02 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id UAA13299; Wed, 10 Dec 1997 20:13:53 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Wed, 10 Dec 1997 20:13:50 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Jason Evans cc: "J. Weatherbee - Senior Systems Architect" , hackers@FreeBSD.ORG Subject: Re: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jason Evans wrote: > On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > > Wouldn't porting -stable first be a better project, after all you want a > > quality product and that is what stable is. If it was me I would start > > there, cvsup to RELENG_22 and take a crack at it. > > Well, it would be easier, but then comes the problem of moving the port to > current once it works. That would probably be as bad a doing the port in > the first place. From what I understand, FreeBSD 1.1 was ported to SPARC > way back, but it never got merged back in to the development tree. I'm > guessing it was because of something like this. I don't want to pour > blood, sweat, and tears into this port, and then never have it integrated > into current. That would almost be worse than never starting in the first > place. > > I've still got a question about maintaining a separate tree that I haven't > found a reasonable answer to: > > Say I grab current, and stay synched with it, but I start making changes > to my local tree. As time goes on, I make more and more changes, while my > tree still tracks current. At some point, aren't my changes going to > cause conflicts that make it a losing battle to keep my own tree? Say in > file foo.c George changes lines 10-20 in the main tree, and I change lines > 15-20. When I sync my tree with freebsd.org, there will be a conflict. If > I manually resolve this conflict, will I have to deal with it repeatedly > every time I sync with the main tree? > > Even if I only have to resolve the conflict once, tracking current can't > be automatic, can it? It seems to me that I'd have to manually resolve > conflicts. Well, cvs isn't as braindead as all that ... if the differences detected during a merge don't conflict, then the merge is automatic (although cvs warns you it's merging). I agree on one point, tho, you want current as a target, not stable. Your first effort is going to be unstable, no matter if you were the guru-god coder of all time (no one's that good, except in their dreams). Basing it on an older, more stable version of FreeBSD just means that your first effort will be based upon an older version, and won't have too much effect on it's stability. Your own alpha/beta/gamma testing will really determine that, and the efforts of all who follow the work you lead. > > Jason > > P.S. Please excuse what is likely incorrect terminology for tree > synchronization and conflict resolution. What are the proper terms? > > Jason Evans > Email: [jasone@canonware.com] > Home phone: [(650) 856-8204] > Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Dec 10 18:01:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17319 for hackers-outgoing; Wed, 10 Dec 1997 18:01:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17310 for ; Wed, 10 Dec 1997 18:01:32 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id TAA09529; Wed, 10 Dec 1997 19:01:20 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id TAA02272; Wed, 10 Dec 1997 19:01:39 -0700 (MST) Date: Wed, 10 Dec 1997 19:01:38 -0700 (MST) From: Marc Slemko To: Joerg Wunsch cc: freebsd-hackers@freebsd.org Subject: Re: I seriously need some networking help In-Reply-To: <199712110048.BAA09610@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, J Wunsch wrote: > "J. Weatherbee - Senior Systems Architect" wrote: > > > I attempted making the firewall to router link a 192.168.x.x network, and > > using dual ip on it, unfortunately it interesting that the link gets > > published by traceroute for instance from the outside world. > > Sure, but that's only a cosmetical problem. I've seen 10.* > intermediate network addressess even on major Internet relays when > tracerouting. It should be totally acceptable for an endpoint > transient network. Nobody has any need to access the interfaces on > this network. So tell me what happens when the box that interface is on needs to send an ICMP message like can't fragment? What IP does it use? If it uses the private one, you lose. This does break things like PMTU-D. From owner-freebsd-hackers Wed Dec 10 18:08:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17959 for hackers-outgoing; Wed, 10 Dec 1997 18:08:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17938 for ; Wed, 10 Dec 1997 18:08:27 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id TAA09632; Wed, 10 Dec 1997 19:08:21 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id TAA02293; Wed, 10 Dec 1997 19:06:36 -0700 (MST) Date: Wed, 10 Dec 1997 19:06:36 -0700 (MST) From: Marc Slemko To: Adam Turoff cc: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: <348F48D3@smginc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Adam Turoff wrote: > > > I was just thinking about this. I've been playing around with cgic > lately > > and I think it would be hilarious to have the kernel configuration on > the > > local web server (password protected of course). I saw an article the > > other day about windows 98 (not that I really care what MS is doing), > but > > apparently they are going web browser-centric, certainly that is > pushing > > it, but I was thinking how easy it might be set up something like this. > > I only considered it because I have decided to rewrite the interface > for a > > particular software package I worked on last summer to have a > significant > > portion of its interface web-able. This is less because I really want > to > > a more because *I HATE* designing X interfaces and this way I can have > > someone else do it. Plus windows can be a client to the server process > > (if it was up to me people would just telnet into the server port and > use > > it that way). > > I don't know about that. Sounds like a huge security hole. > > If you're interested in going town this path, I'd strongly recommend > taking a page from Netscape. Their servers use an admin server > to administer all instances of their httpd on a box. When installing > the server package, the install program picks a random port > 1024 > to use for running the admin server. The sysadmin can change > this port to something useful, but the idea here is that the > administration is not running on any "standard" port. That is not done for security, but for the oops factor and to let you mess with one server without having it bring down the admin server that (some people) need to fix it. > > I certainly wouldn't want anything like kernel configs or sysadmin > type stuff happening over a standard port like 80 or 8080 with > clear text passwords. If I could use SSL on some bizzaro > port number, that would be really worth having. :-) SSL is troublesome because the fascist US gov't patents basic math and is afraid that allowing people to export technology that the whole world already has will be a security risk. The sad truth is that the Internet would be far more secure if the US gov't wasn't so obtuse. From owner-freebsd-hackers Wed Dec 10 18:18:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA18718 for hackers-outgoing; Wed, 10 Dec 1997 18:18:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18705 for ; Wed, 10 Dec 1997 18:17:56 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA14152; Wed, 10 Dec 1997 18:20:54 -0800 (PST) Message-Id: <199712110220.SAA14152@implode.root.com> To: Jason Evans cc: "J. Weatherbee - Senior Systems Architect" , hackers@FreeBSD.ORG Subject: Re: OS Ports In-reply-to: Your message of "Wed, 10 Dec 1997 15:30:32 PST." From: David Greenman Reply-To: dg@root.com Date: Wed, 10 Dec 1997 18:20:54 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: >> Wouldn't porting -stable first be a better project, after all you want a >> quality product and that is what stable is. If it was me I would start >> there, cvsup to RELENG_22 and take a crack at it. > >Well, it would be easier, but then comes the problem of moving the port to >current once it works. That would probably be as bad a doing the port in >the first place. From what I understand, FreeBSD 1.1 was ported to SPARC >way back, but it never got merged back in to the development tree. I'm >guessing it was because of something like this. I don't want to pour Saying that FreeBSD 1.x was "ported" to the Sparc would be more than a little bit of a stretch. The kernel, which was a weird kludge of NetBSD and FreeBSD got to single user, but I think that is less than 10% of the way there. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 10 18:25:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19275 for hackers-outgoing; Wed, 10 Dec 1997 18:25:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA19261 for ; Wed, 10 Dec 1997 18:24:57 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA14235; Wed, 10 Dec 1997 18:28:09 -0800 (PST) Message-Id: <199712110228.SAA14235@implode.root.com> To: John-Mark Gurney cc: FreeBSD Hackers Subject: Re: merge bpfattach into if_attach... In-reply-to: Your message of "Wed, 10 Dec 1997 16:46:19 PST." <19971210164619.03585@hydrogen.nike.efn.org> From: David Greenman Reply-To: dg@root.com Date: Wed, 10 Dec 1997 18:28:09 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I was just working on the strip star mode driver from NetBSD (it works!) >and noticed this really stupid piece of code that I KNOW is in every >interface driver: >#if NBPFILTER > 0 > bpfattach(&sc->sc_if, DLT_SLIP, SLIP_HDRLEN); >#endif > >and just before that code is a call to if_attach... is there any >problem by merging these two together? and then in if_attach if >NBPFILTER is > 0, call the proper bpfattach routine? it seems really >stupid to touch ever driver, when a small modification can improve the >code... > >and yes, I know that it will break the interface that made it so easy >to get NetBSD's star mode driver up and running... :) If we did that, then we would require that all network drivers have BPF support. While this might be true at the moment, it hasn't always been true in the past nor can we assume it will be in the future. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 10 18:28:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19551 for hackers-outgoing; Wed, 10 Dec 1997 18:28:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA19539 for ; Wed, 10 Dec 1997 18:28:19 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA14274; Wed, 10 Dec 1997 18:31:34 -0800 (PST) Message-Id: <199712110231.SAA14274@implode.root.com> To: John-Mark Gurney cc: FreeBSD Hackers Subject: Re: merge bpfattach into if_attach... In-reply-to: Your message of "Wed, 10 Dec 1997 16:46:19 PST." <19971210164619.03585@hydrogen.nike.efn.org> From: David Greenman Reply-To: dg@root.com Date: Wed, 10 Dec 1997 18:31:34 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >#if NBPFILTER > 0 > bpfattach(&sc->sc_if, DLT_SLIP, SLIP_HDRLEN); >#endif > >and just before that code is a call to if_attach... is there any >problem by merging these two together? and then in if_attach if Oh, and one more comment, doing the above would require an internal change to the way if_attach is called in all of the device drivers so that the information about the link layer header size and interface speed/type can be passed in. I think that is a bad idea - for one thing, it breaks compatibility with third party drivers. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Dec 10 18:29:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19739 for hackers-outgoing; Wed, 10 Dec 1997 18:29:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19720 for hackers; Wed, 10 Dec 1997 18:29:46 -0800 (PST) (envelope-from jkh@time.cdrom.com) Message-Id: <199712110229.SAA19720@hub.freebsd.org> Subject: Freenix: The Freely Distributable Software Technical Conference Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Dec 97 16:52:36 -0500 From: "Jon 'maddog' Hall, USG Senior Leader" X-Mts: smtp Reply-To: "Jon 'maddog' Hall, USG Senior Leader" Resent-To: hackers@freebsd.org Resent-Date: Thu, 04 Dec 1997 18:55:11 -0800 Resent-Message-ID: <28536.881290511@time.cdrom.com> Resent-From: "Jordan K. Hubbard" To: undisclosed-recipients:; Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk For those of you who participated in "USELINUX" last year, you know that from the Linux perspective it was a "success". However, from the perspective of the *BSD folks, who also do a lot of good work in the freely distributable operating system space, it was a disaster. They felt left out, and some of them felt it was done on purpose, even though (from my vantage point) it was one of those "oh sh_t" issues. In any case, the USENIX Board has chartered me to chair what has become known as the "Freenix" track of the New Orleans USENIX Technical Conference. I am committed to create a balanced conference, and to that end I have put together a multi-operating system organizing committee. The concept of this track is technical excellence, and the goal is the sharing of technical ideas between the operating systems and applications, so that all may benefit. We have been fortunate to have members of the FreeBSD and OpenBSD groups join us. At this point both netBSD and the FSF have declined for reasons of their own. The call for papers has just been posted, and the timeframe is short. I would appreciate it if all of you would: o put a pointer to the URL below on the web page for your company o send a brief message to any mailing lists you keep for your or group http://www.usenix.org/events/no98/index.html Later on, we will send a URL of the program that has been defined. Please help us find good presentations, whether they be about freely distributable operating systems or freely distributable applications. Thank you. Jon "maddog" Hall Digital Equipment Corporation For the Freenix Committee: Alan Cox, CymruNet Ltd. Theo De Raadt, The OpenBSD Project Chris Farris, Atlanta Linux Enthusiasts Greg Hankins, Georgia Institute of Technology Jordan Hubbard, The FreeBSD Project Poul-Henning Kamp, The FreeBSD Project Angelos Keromytis, University of Pennsylvania Dan Shearer, LAN Magazine Theodore Ts'o, Massachusetts Institute of Technology -- ============================================================================= Jon "maddog" Hall Internet: maddog@zk3.dec.com Senior Leader, UNIX Software Group Executive Director, Linux International Digital Equipment Corporation Linux International Mailstop ZK03-2/U15 80 Amherst St. 110 Spit Brook Rd. Amherst, N.H. 03031-3032 U.S.A. Nashua, N.H. 03062-2698 U.S.A. WWW: http://www.unix.digital.com WWW: http://www.li.org Voice: +1.603.884.1341 Voice: +1.603.672.4557 FAX: +1.603.884.6424 Office: ZK03-2/V15 Board Member: Uniforum Association From owner-freebsd-hackers Wed Dec 10 18:33:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20155 for hackers-outgoing; Wed, 10 Dec 1997 18:33:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA20139 for ; Wed, 10 Dec 1997 18:33:11 -0800 (PST) (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id LAA27624; Thu, 11 Dec 1997 11:32:34 +0900 (JST) To: Jason Evans cc: freebsd-hackers@freebsd.org In-reply-to: jasone's message of Wed, 10 Dec 1997 08:56:25 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Beginning SPARC port From: Jun-ichiro itojun Itoh Date: Thu, 11 Dec 1997 11:32:34 +0900 Message-ID: <27620.881807554@coconut.itojun.org> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk a bit delayed response: >As has been alluded to in some of Jordan Hubbard's email, Sun >Microelectronics (SME, the processor division of Sun) recently discussed >paying FreeBSD core to officially support a port of FreeBSD to SPARC. >These plans fell through in some way (I wasn't part of the discussion, so >I don't know details), but SME is having me work on the port. I'm a >full-time employee of SME, and estimate that I can spend 30-35 hours per >week of my work week on the SPARC FreeBSD porting effort (plus whatever >personal time I spend). Great! >1) Is it possible with cvsup to maintain my own source tree with my >modifications, yet stay synched with current, so that once I have the >kernel running, I can submit a single update to the current tree (or have >someone with write access do it for me)? By performing simple grep for `outb', the following files seem to include i386-specific function calls. pccard/pcic.c pci/aic7870.c pci/if_de.c pci/ncr.c pci/tek390.c pci/wd82371.c I think there need to be big change to directory structure, and we should add some wrapper function for pci bus accesses, as NetBSD does.... /sys/pci -> /sys/pci(generic) + /sys/i386/pci ? /sys/pccard -> /sys/pccard(generic) + /sys/i386/pccard ? /sys/pc98 -> /sys/i386/pc98 ? (possible?) or, /sys/arch/i386 and /sys/arch/sparc ? itojun From owner-freebsd-hackers Wed Dec 10 18:39:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA20710 for hackers-outgoing; Wed, 10 Dec 1997 18:39:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA20694 for ; Wed, 10 Dec 1997 18:39:26 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA24043; Wed, 10 Dec 1997 18:39:09 -0800 (PST) To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) cc: jasone@canonware.com (Jason Evans), freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Wed, 10 Dec 1997 19:02:23 +0100." <19971210190223.FD42136@mars.hsc.fr> Date: Wed, 10 Dec 1997 18:39:09 -0800 Message-ID: <24040.881807949@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That looks like a great idea to me, though I'm quite surprised that > Sun supports this since they've been desperately trying to kill SunOS > for years... You need to read the posting more carefully - this is SME, who has nothing to do with SunOS or OS decisions in general. Sun is a large company made up of many smaller companies. :) > Since NetBSD already runs quite fine on many SPARC models, maybe > it would be a good idea to consider using their code as a starting Unfortunately, not on the new Ultra AFAIK. The Ultra, being 64 bit, is going to be a rather special challenge. I've a longer reply in progress to Jason, once I've managed to wade through all the other replies first so that I don't get needlessly redundant. :) Jordan From owner-freebsd-hackers Wed Dec 10 18:42:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA21111 for hackers-outgoing; Wed, 10 Dec 1997 18:42:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21091 for ; Wed, 10 Dec 1997 18:42:01 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA24090; Wed, 10 Dec 1997 18:41:32 -0800 (PST) To: Marc Ramirez cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 13:11:55 EST." Date: Wed, 10 Dec 1997 18:41:32 -0800 Message-ID: <24086.881808092@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am a born applications programmer. I love hashing out the details, > spending three weeks QA'ing a program it took two days to write. When I > write a solid app, I strut around the city beating my chest. If I > could, I would gladly sit down and bang out any configuration utility > FreeBSD could use. We want you. :) > However, between being a CS major and a sysadmin, anything I start would > have, oh, a five to six month turnaround. :) Right now, I'm not sure > that's an investment I'm prepared to make unless, say, Jordan would > guarantee that my work would be used. And I certainly wouldn't put Jordan > in that position, considering he's never seen my work. :) :) Hmmmm. How many hours do you spend being a system admin? And how much are you paid for this? Perhaps something can be arranged. :-) Jordan From owner-freebsd-hackers Wed Dec 10 18:52:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA22027 for hackers-outgoing; Wed, 10 Dec 1997 18:52:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21973 for ; Wed, 10 Dec 1997 18:51:48 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA24198; Wed, 10 Dec 1997 18:51:25 -0800 (PST) To: Chuck Robey cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Wed, 10 Dec 1997 14:57:35 EST." Date: Wed, 10 Dec 1997 18:51:25 -0800 Message-ID: <24194.881808685@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Wow, this sounds really neat. You probably want to ask the guys who were > starting on the stalled alpha port what directory structure they had > agreed on. Seeing as they probably had to answer exactly the kind of It stalled before we got that far, sorry. :) > I would also be a little curious about the availability of sparc hardware > for hobbyist folk. Few of us can afford $10K servers, but what other kind This is probably a bit premature - why not wait until the port is actually close to being finished and then check the prices? You know how volatile things are in this industry, and they may well be half the current price by then. :-) Jordan From owner-freebsd-hackers Wed Dec 10 19:03:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22890 for hackers-outgoing; Wed, 10 Dec 1997 19:03:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22882 for ; Wed, 10 Dec 1997 19:03:06 -0800 (PST) (envelope-from nectar@kai.communique.net) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id VAA02689 for ; Wed, 10 Dec 1997 21:06:49 -0600 (CST) Message-Id: <199712110306.VAA02689@kai.communique.net> X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma002686; Wed, 10 Dec 97 21:06:45 -0600 From: Jacques Vidrine To: freebsd-hackers@freebsd.org Subject: Whence DEC Alpha port? (was Re: Beginning SPARC port) In-reply-to: References: Date: Wed, 10 Dec 1997 21:06:45 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Speaking of ports of FreeBSD ... ... Is there currently a DEC Alpha port under development anywhere? I recently acquired a DEC Alpha, and I am hoping to spend some of its cycles and mine next year working with the port, and hopefully furthering it. But I guess I oughta find out if it exists first :-) Jacques Vidrine From owner-freebsd-hackers Wed Dec 10 19:04:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23070 for hackers-outgoing; Wed, 10 Dec 1997 19:04:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22876 for ; Wed, 10 Dec 1997 19:02:58 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA24343; Wed, 10 Dec 1997 19:02:48 -0800 (PST) To: "J. Weatherbee - Senior Systems Architect" cc: Jason Evans , hackers@FreeBSD.ORG Subject: Re: OS Ports In-reply-to: Your message of "Wed, 10 Dec 1997 13:26:31 PST." Date: Wed, 10 Dec 1997 19:02:48 -0800 Message-ID: <24340.881809368@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Wouldn't porting -stable first be a better project, after all you want a > quality product and that is what stable is. If it was me I would start Yes, but that would be a guarantee for rapid obsolescence, too, and only defer a significant headache for the future when "trade up" time came. I think -current is absolutely the correct place to do something like this. Jordan From owner-freebsd-hackers Wed Dec 10 19:04:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23159 for hackers-outgoing; Wed, 10 Dec 1997 19:04:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA23100 for ; Wed, 10 Dec 1997 19:04:22 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id WAA13591; Wed, 10 Dec 1997 22:02:17 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Wed, 10 Dec 1997 22:02:16 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: "Jordan K. Hubbard" cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: <24194.881808685@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jordan K. Hubbard wrote: > > Wow, this sounds really neat. You probably want to ask the guys who were > > starting on the stalled alpha port what directory structure they had > > agreed on. Seeing as they probably had to answer exactly the kind of > > It stalled before we got that far, sorry. :) > > > I would also be a little curious about the availability of sparc hardware > > for hobbyist folk. Few of us can afford $10K servers, but what other kind > > This is probably a bit premature - why not wait until the port is actually > close to being finished and then check the prices? You know how volatile > things are in this industry, and they may well be half the current price > by then. :-) Actually, used Sparc stuff seems to be readily, and cheaply available. I have a Mips-equipped DEC 5000 running NetBSD here, which I brought up for a class that was going to go into the Mips architecture. Cost? $50, plus $175 for the big 19" color monitor. Stuff like that is really available, and I know for sure I didn't get the best deal! I'm going to make a real effort not to take so many classes next semester, and maybe start hobby coding again. Then this'll be something nice to think about. > > Jordan > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Dec 10 19:18:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA24388 for hackers-outgoing; Wed, 10 Dec 1997 19:18:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA24373 for ; Wed, 10 Dec 1997 19:17:55 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id TAA20807; Wed, 10 Dec 1997 19:17:50 -0800 Date: Wed, 10 Dec 1997 19:17:50 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio To: "Jordan K. Hubbard" cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: <24194.881808685@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jordan K. Hubbard wrote: > This is probably a bit premature - why not wait until the port is actually > close to being finished and then check the prices? You know how volatile > things are in this industry, and they may well be half the current price > by then. :-) ^^^^^^^^^^^^^^^^^^^^^^ A true optimist. =) Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Wed Dec 10 19:26:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25073 for hackers-outgoing; Wed, 10 Dec 1997 19:26:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA25060 for ; Wed, 10 Dec 1997 19:26:10 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras630.srv.net [205.180.127.130]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id UAA16297 for ; Wed, 10 Dec 1997 20:26:07 -0700 Date: Wed, 10 Dec 1997 20:25:32 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I certainly wouldn't want anything like kernel configs or sysadmin > > type stuff happening over a standard port like 80 or 8080 with > > clear text passwords. If I could use SSL on some bizzaro > > port number, that would be really worth having. :-) > > SSL is troublesome because the fascist US gov't patents basic math and is > afraid that allowing people to export technology that the whole world > already has will be a security risk. > > The sad truth is that the Internet would be far more secure if the US > gov't wasn't so obtuse. My understanding is that only commercial web servers support SSL, which I am guessing is the name for standard secure link used by MSIE and Netscape. Is it possible that Apache supports SSL?? In a more perfect world, we would be using source code available browsers that had evolved to use a free, ssh derivative encryption. Instead we let Netscape and Microsoft take over the market and set standards. It may be impossible to ever go back. Still, I think there is a chance for ssh to conquer the world. The F-secure products based on it are apparently becoming very popular. Charles Mott From owner-freebsd-hackers Wed Dec 10 20:40:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA00944 for hackers-outgoing; Wed, 10 Dec 1997 20:40:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA00935 for ; Wed, 10 Dec 1997 20:40:29 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xg0Ga-0002sj-00; Wed, 10 Dec 1997 20:30:28 -0800 Date: Wed, 10 Dec 1997 20:30:23 -0800 (PST) From: Tom To: Charles Mott cc: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Charles Mott wrote: > My understanding is that only commercial web servers support SSL, which I > am guessing is the name for standard secure link used by MSIE and > Netscape. Is it possible that Apache supports SSL?? > Netscape and Microsoft take over the market and set standards. It may be > impossible to ever go back. No, ssl is an open standard. There is an freely available ssl library (ssleay?). You can get Apache-SSL, which is just Apache plus the ssl library. ssl uses RSA encryption which is protected by a US patent. This makes it illegal to use the ssl lib in the US. You can get stronghold, which is Apache plus a properly licensed ssl library for use in the US. Tom From owner-freebsd-hackers Wed Dec 10 20:48:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01489 for hackers-outgoing; Wed, 10 Dec 1997 20:48:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01471 for ; Wed, 10 Dec 1997 20:48:32 -0800 (PST) (envelope-from grog@lemis.com) Received: from papillon.lemis.com ([168.87.69.104]) by Tandem.com (8.8.8/2.0.1) with ESMTP id UAA01746; Wed, 10 Dec 1997 20:48:21 -0800 (PST) Received: (grog@localhost) by papillon.lemis.com (8.8.8/8.6.12) id LAA07265; Thu, 11 Dec 1997 11:07:20 +0800 (CST) Message-ID: <19971211110717.02078@lemis.com> Date: Thu, 11 Dec 1997 11:07:17 +0800 From: Greg Lehey To: "Matthew N. Dodd" Cc: Josef Grosch , freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] References: <19971210124021.52222@mooseriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Matthew N. Dodd on Wed, Dec 10, 1997 at 06:07:56PM -0500 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 06:07:56PM -0500, Matthew N. Dodd wrote: > On Wed, 10 Dec 1997, Josef Grosch wrote: >> Sun monitors are _DAMED_ expensive. I have yet to see one for under >> $1500.00. I will most likely end up running mine headless. > > New ones may be rather expensive but I've seen no shortage of cheap > used sun > monitors. In any case, you can use most good multisync monitors. I have a 17" monochrome Sun monitor, but I connect my SS2 to the same monitor I connect my PC to (a 21" iiyama, but that's not important). Greg From owner-freebsd-hackers Wed Dec 10 21:19:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03221 for hackers-outgoing; Wed, 10 Dec 1997 21:19:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03202 for ; Wed, 10 Dec 1997 21:18:32 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id PAA01053; Thu, 11 Dec 1997 15:42:24 +1030 (CST) Message-Id: <199712110512.PAA01053@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: "Matthew N. Dodd" , Josef Grosch , freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-reply-to: Your message of "Thu, 11 Dec 1997 11:07:17 +0800." <19971211110717.02078@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 1997 15:42:24 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Wed, Dec 10, 1997 at 06:07:56PM -0500, Matthew N. Dodd wrote: > > On Wed, 10 Dec 1997, Josef Grosch wrote: > >> Sun monitors are _DAMED_ expensive. I have yet to see one for under > >> $1500.00. I will most likely end up running mine headless. > > > > New ones may be rather expensive but I've seen no shortage of cheap > > used sun > > monitors. > > In any case, you can use most good multisync monitors. I have a 17" > monochrome Sun monitor, but I connect my SS2 to the same monitor I > connect my PC to (a 21" iiyama, but that's not important). Spot on. With an appropriate cable, any halfway-decent PC monitor will handle all of the standard Sun video modes. mike From owner-freebsd-hackers Wed Dec 10 21:20:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA03408 for hackers-outgoing; Wed, 10 Dec 1997 21:20:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03401 for ; Wed, 10 Dec 1997 21:20:50 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA15982; Wed, 10 Dec 1997 21:13:14 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015980; Wed Dec 10 21:13:09 1997 Message-ID: <348F75CE.7A5F06AF@whistle.com> Date: Wed, 10 Dec 1997 21:10:38 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Adam Turoff CC: hackers Subject: Re: I seriously need some networking help References: <348F48CE@smginc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Adam Turoff wrote: > ks. The only problem > is that whenever the T1 goes down, the ethernet port > on the router goes down. Apparently, when FBSD detects > a dead network interface, it removes all the routes associated > with that interface. > That's routed doing that.. why do you need routed running? use static routes and yuo won't ha vehte problems. From owner-freebsd-hackers Wed Dec 10 21:33:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA04050 for hackers-outgoing; Wed, 10 Dec 1997 21:33:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA03789 for ; Wed, 10 Dec 1997 21:28:05 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id VAA24691; Wed, 10 Dec 1997 21:27:58 -0800 (PST) (envelope-from jdp) Message-Id: <199712110527.VAA24691@austin.polstra.com> To: Shigio Yamaguchi cc: hackers@freebsd.org Subject: Re: [RFC] path converting functions. In-reply-to: Your message of "Wed, 10 Dec 1997 08:34:25 +0900." <199712091552.PAA11445@wafu.netgate.net> Date: Wed, 10 Dec 1997 21:27:58 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Since your functions write into the user-supplied buffer "result", > > you should add an argument that specifies how big it is. See the > > gethostname() and snprintf() interfaces, for example. > > The result argument must refer to a buffer capable of storing at > least MAXPATHLEN characters. This is the way of realpath(3). Well, in my opinion the example set by realpath(3) is bad and it shouldn't be copied in new code. I say again, if a function writes into a caller-supplied buffer then the caller should also specify how large the buffer is. Using a compiled in assumption such as MAXPATHLEN is risky at best. What if you build your program on one machine and then run it on a machine where MAXPATHLEN has a different value? Or, for that matter, on the same machine after some wiz has decided to change the value of MAXPATHLEN? Anyway, that's all the arguing I want to do. You asked for opinions and I gave you mine. :-) John From owner-freebsd-hackers Wed Dec 10 21:56:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05537 for hackers-outgoing; Wed, 10 Dec 1997 21:56:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05506 for ; Wed, 10 Dec 1997 21:56:20 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id VAA24908; Wed, 10 Dec 1997 21:54:58 -0800 (PST) To: Jonathan Mini cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 16:00:15 PST." <19971210160015.21473@micron.mini.net> Date: Wed, 10 Dec 1997 21:54:58 -0800 Message-ID: <24904.881819698@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What I have in mind is rather simple, but it requires the following : > > 1) a file, which is MAINTAINED, which contains all of the possible > options, their classes, and a simple comment for each one. Woog. It's that "maintained" bit which is the hard part, and frankly I'm more than somewhat skeptical of this for the long-term unless it's taken to the next level of functionality which will properly encourage its upkeep. What I'm thinking of here, namely, is the total replacement of config by a new utility which tries for a different configuration file format, one "rich" enough to support a GUI interface. This has always been a shortcoming of the current one, and the need to keep GENERIC and LINT files around just to "document" it is rather significant proof of its shortcomings. If you're really this ambitious then tou won't get anywhere by simply trying to paper over config, you need to replace it. Jordan From owner-freebsd-hackers Wed Dec 10 22:02:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05900 for hackers-outgoing; Wed, 10 Dec 1997 22:02:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05440 for ; Wed, 10 Dec 1997 21:55:37 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id FAA13701; Thu, 11 Dec 1997 05:54:59 GMT Date: Thu, 11 Dec 1997 14:54:58 +0900 (JST) From: Michael Hancock To: "J. Weatherbee - Senior Systems Architect" cc: FreeBSD Hackers Subject: Re: OS Ports In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John didn't flame you, he gave you a very diplomatic answer. Don't worry about being flamed, it's easier to react strongly in email. What you suggested was pretty masochistic. You really want to be closer to where your going than where you are now. Also, you don't want to destablise stable! Regards, Mike Hancock On Wed, 10 Dec 1997, J. Weatherbee - Senior Systems Architect wrote: > > Boy I got flamed for that remark, my point was that if he is going to do > a port of FreeBSD and it is going to be meaningful it needs to be stable > (Theyv'e already got a Linux port for SPARCS). I'm not saying that > -current is not stable, maybye what I am trying to say is that he needs > both. Anyway do you want everyone using SPARC FreeBSD to be running > -current? Anyway your in for a big project. > > > On Wed, 10 Dec 1997, John S. Dyson wrote: > > > J. Weatherbee - Senior Systems Architect said: > > > > > > Wouldn't porting -stable first be a better project, after all you want a > > > quality product and that is what stable is. > > > > > Respectfully, it probably would not be a good idea, but it would be better to > > start from a recent, stable -current. It is *much* easier to get support from > > the developers on -current. -stable is approaching a year old now. > > > > -- > > John > > dyson@freebsd.org > > jdyson@nc.com > > > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 From owner-freebsd-hackers Wed Dec 10 22:03:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA05956 for hackers-outgoing; Wed, 10 Dec 1997 22:03:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05521 for ; Wed, 10 Dec 1997 21:56:41 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712110556.VAA05521@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA249029705; Thu, 11 Dec 1997 16:55:05 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 11 Dec 1997 16:55:05 +1100 (EDT) Cc: Pierre.Beyssac@hsc.fr, jasone@canonware.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <24040.881807949@time.cdrom.com> from "Jordan K. Hubbard" at Dec 10, 97 06:39:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Jordan K. Hubbard, sie said: > > > Since NetBSD already runs quite fine on many SPARC models, maybe > > it would be a good idea to consider using their code as a starting > > Unfortunately, not on the new Ultra AFAIK. The Ultra, being 64 bit, > is going to be a rather special challenge. > > I've a longer reply in progress to Jason, once I've managed to > wade through all the other replies first so that I don't get > needlessly redundant. :) NetBSD/sparc boots single user on sun4u, last I heard. Further than that, I'm not sure, but it would *definately* be worthwhile talking to the NetBSD/sparc people. However, I think the 64bit issue is around the wrong way. The issue now is what does having a 64bit "long type" mean for FreeBSD ? How much code still relies on sizeof(long) == sizeof(int) == sizeof(void*) and only 32 bits ? If you're serious about wanting a FreeBSD port running on the sun4u (and eventually DEC alpha), then FreeBSD needs to be sure it can deal with 64bit longs and 64bit pointers - which I think can be started on now even if sun4u/alpha work is some time away. Darren From owner-freebsd-hackers Wed Dec 10 22:18:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07249 for hackers-outgoing; Wed, 10 Dec 1997 22:18:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.systemresc.com (dave@[207.198.60.196]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA07244 for ; Wed, 10 Dec 1997 22:18:38 -0800 (PST) (envelope-from dave@ns.systemresc.com) From: dave@ns.systemresc.com Received: from localhost (dave@localhost) by ns.systemresc.com (8.8.5/8.8.5) with SMTP id BAA00832; Thu, 11 Dec 1997 01:16:38 -0500 (EST) Date: Thu, 11 Dec 1997 01:16:37 -0500 (EST) To: dave@ns.systemresc.com cc: freebsd-hackers@freebsd.org Subject: cy driver silo overflows Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Would someone be so kind as up upload the message with the fix for the cy (cyclades)driver silo overflow problem...I have the Cyclades SM16 and had saved the message only to findout it was a reply and not the code that needed to be changed... dave... System Resource Internet Provider Buffalo, Niagara Falls NY From owner-freebsd-hackers Wed Dec 10 22:48:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA09755 for hackers-outgoing; Wed, 10 Dec 1997 22:48:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marlin.exis.net (root@marlin.exis.net [205.252.72.102]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA09742 for ; Wed, 10 Dec 1997 22:48:23 -0800 (PST) (envelope-from stefan@exis.net) Received: from sailfish.exis.net (sailfish.exis.net [205.252.72.104]) by marlin.exis.net (8.8.4/8.8.5) with SMTP id BAA00620; Thu, 11 Dec 1997 01:17:40 -0500 Date: Thu, 11 Dec 1997 00:53:33 -0500 (EST) From: Stefan Molnar To: Mike Smith cc: Greg Lehey , "Matthew N. Dodd" , Josef Grosch , freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-Reply-To: <199712110512.PAA01053@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Spot on. With an appropriate cable, any halfway-decent PC monitor will > handle all of the standard Sun video modes. Not all of them. I have a few 14'in that will not handle the sync. They were decent for their time. Stefan From owner-freebsd-hackers Wed Dec 10 23:16:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11753 for hackers-outgoing; Wed, 10 Dec 1997 23:16:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA11747 for ; Wed, 10 Dec 1997 23:16:28 -0800 (PST) (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id BAA07173 for ; Thu, 11 Dec 1997 01:29:42 -0500 (EST) Date: Thu, 11 Dec 1997 01:30:13 -0500 (EST) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: freebsd-hackers@freebsd.org Subject: TCP problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There seem's to be a problem with FreeBSD machines on ppp dialup accessing certain web servers running so FreeBSD on the web server. Myself and a person in the UK have noticed the same thing. The only thing i can see in common is that both of us having this problem are dialing into a xylogics annex terminal server. 2 example sites that seem to give this problem connecting to are: resnet.uoregon.edu (Where Doug White's pages are) and www.netcraft.co.uk. Going and using lynx on the ISP's shell box works just fine to these sites. It's something between us and them. Which is the term server, and our os. I am running FreeBSD-current FreeBSD opsys 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sun Dec 7 19:05:12 CST 1997 I have included output of tcpdump below of a request to www.netcraft.co.uk: # tcpdump -vv -i tun0 port 80 tcpdump: listening on tun0 00:24:46.459429 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: S 374134 3599:3741343599(0) win 16384 (DF) (ttl 64, id 49789) 00:24:46.984205 www.netcraft.co.uk.http > port4.idtswe2.idir.net.1307: S 698923 250:698923250(0) ack 3741343600 win 16512 (DF) (ttl 48, id 57682) 00:24:46.984353 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: . ack 1 win 16512 (DF) (ttl 64, id 4 9792) 00:24:46.987660 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: P 1:274( 273) ack 1 win 16512 (DF) (ttl 64, id 49793) If more output is needed just ask. From owner-freebsd-hackers Wed Dec 10 23:45:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13673 for hackers-outgoing; Wed, 10 Dec 1997 23:45:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13655 for ; Wed, 10 Dec 1997 23:44:53 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA19129; Wed, 10 Dec 1997 23:44:22 -0800 (PST) Message-ID: <19971210234421.24902@hydrogen.nike.efn.org> Date: Wed, 10 Dec 1997 23:44:21 -0800 From: John-Mark Gurney To: Open Systems Networking Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: TCP problem References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Open Systems Networking on Thu, Dec 11, 1997 at 01:30:13AM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Open Systems Networking scribbled this message on Dec 11: > There seem's to be a problem with FreeBSD machines on ppp dialup accessing > certain web servers running so FreeBSD on the web server. have you tried disabling some of the extended tcp options: net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 try setting 'em both to zero and see what you get... I have to disable one of 'em, or else my slirp link won't work properly... :) [...] > The only thing i can see in common is that both of us having this problem > are dialing into a xylogics annex terminal server. IRC, these term servers are known to throw fits with some of the extended tcp options... hope the above helps... ttyl. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Wed Dec 10 23:48:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14012 for hackers-outgoing; Wed, 10 Dec 1997 23:48:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA13998 for ; Wed, 10 Dec 1997 23:48:47 -0800 (PST) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id XAA28172; Wed, 10 Dec 1997 23:48:41 -0800 (PST) Date: Wed, 10 Dec 1997 23:48:41 -0800 (PST) From: Jaye Mathisen To: Open Systems Networking cc: freebsd-hackers@freebsd.org Subject: Re: TCP problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Seems to me I remember somebody saying something about a similar situation, and it was fixed by changing the MTU to something else... But I'm a bit fuzzy on it. Might try searching the hackers archive, seems to me it was Jordan that sent the original messages. On Thu, 11 Dec 1997, Open Systems Networking wrote: > > There seem's to be a problem with FreeBSD machines on ppp dialup accessing > certain web servers running so FreeBSD on the web server. > > Myself and a person in the UK have noticed the same thing. > > The only thing i can see in common is that both of us having this problem > are dialing into a xylogics annex terminal server. > > 2 example sites that seem to give this problem connecting to are: > resnet.uoregon.edu (Where Doug White's pages are) > and www.netcraft.co.uk. > > Going and using lynx on the ISP's shell box works just fine to these > sites. > It's something between us and them. > Which is the term server, and our os. > > I am running FreeBSD-current > FreeBSD opsys 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sun Dec 7 19:05:12 CST 1997 > > I have included output of tcpdump below of a request to www.netcraft.co.uk: > > # tcpdump -vv -i tun0 port 80 > tcpdump: listening on tun0 > 00:24:46.459429 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: S > 374134 > 3599:3741343599(0) win 16384 395833 0,n > op,nop,cc[|tcp]> (DF) (ttl 64, id 49789) > 00:24:46.984205 www.netcraft.co.uk.http > port4.idtswe2.idir.net.1307: S > 698923 > 250:698923250(0) ack 3741343600 win 16512 0,nop,nop,timest > amp 2733943 395833,nop,nop,cc[|tcp]> (DF) (ttl 48, id 57682) > 00:24:46.984353 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: . > ack 1 > win 16512 (DF) (ttl 64, > id 4 > 9792) > 00:24:46.987660 port4.idtswe2.idir.net.1307 > www.netcraft.co.uk.http: P > 1:274( > 273) ack 1 win 16512 > (DF) (ttl 64, id 49793) > > If more output is needed just ask. > From owner-freebsd-hackers Wed Dec 10 23:49:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14144 for hackers-outgoing; Wed, 10 Dec 1997 23:49:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA14136 for ; Wed, 10 Dec 1997 23:49:47 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id XAA17102; Wed, 10 Dec 1997 23:49:10 -0800 (PST) Message-ID: <19971210234909.29178@micron.mini.net> Date: Wed, 10 Dec 1997 23:49:09 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971210160015.21473@micron.mini.net> <24904.881819698@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <24904.881819698@time.cdrom.com>; from Jordan K. Hubbard on Wed, Dec 10, 1997 at 09:54:58PM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > What I have in mind is rather simple, but it requires the following : > > > > 1) a file, which is MAINTAINED, which contains all of the possible > > options, their classes, and a simple comment for each one. > > Woog. It's that "maintained" bit which is the hard part, and frankly > I'm more than somewhat skeptical of this for the long-term unless it's > taken to the next level of functionality which will properly encourage > its upkeep. Yes. That is the reason I capitalized it. > What I'm thinking of here, namely, is the total replacement of config > by a new utility which tries for a different configuration file > format, one "rich" enough to support a GUI interface. This has always > been a shortcoming of the current one, and the need to keep GENERIC > and LINT files around just to "document" it is rather significant > proof of its shortcomings. If you're really this ambitious then tou > won't get anywhere by simply trying to paper over config, you need to > replace it. Ok. I was shooting for a 'minumum work' approach, and then once I got people used to the GUI I was going to be radical and start talking about replacing it with the new config junk. But, you're one step ahead of me. We need to do this in three stages then : 1) decide what types of "configurability" we want to allow the config utility to handle. compile-time options, compiled-in device, managing LKMs (for now, I hope to see the kld code replace it) and other types of kernel behavior would be a good idea too. Plausably, we could extend this to cover any sort of system configuration, but whether we want to do that is what we'd talk about in this stage. 2) Once we have what we want to classify in our database defined, we should decide on a database method to store it. Most likely, due to extendability, a relational database will be the product of this stage. The exact format would be the issue under debate here. 3) Then I get to actually write the database-handling code, and the GUI to deal with it. If you don't mind, I indent to not use libdialog. :) 4) (I know I said three stages, but..) Then we get to maintain the configuration database. This should be "easier" than maintaining LINT, since you basically won't be able to compile a device in without "documenting" it in the database. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Wed Dec 10 23:55:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14619 for hackers-outgoing; Wed, 10 Dec 1997 23:55:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA14598 for ; Wed, 10 Dec 1997 23:55:37 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xg3JZ-0003Uo-00; Wed, 10 Dec 1997 23:45:45 -0800 Date: Wed, 10 Dec 1997 23:45:40 -0800 (PST) From: Tom To: Open Systems Networking cc: freebsd-hackers@freebsd.org Subject: Re: TCP problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Open Systems Networking wrote: > are dialing into a xylogics annex terminal server. Check the archives. This is an OLD issue. Old Annex software doesn't process the TCP extensions properly. If you turn them off in FreeBSD, everything should work ok. Get the software on the Annex upgraded. Or better yet, throw the Annex out and get a Portmaster instead. At least TCP has never been broken on these things. Tom From owner-freebsd-hackers Thu Dec 11 00:07:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15393 for hackers-outgoing; Thu, 11 Dec 1997 00:07:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15388 for ; Thu, 11 Dec 1997 00:07:16 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id AAA17514; Thu, 11 Dec 1997 00:10:29 -0800 (PST) Message-Id: <199712110810.AAA17514@implode.root.com> To: Open Systems Networking cc: freebsd-hackers@FreeBSD.ORG Subject: Re: TCP problem In-reply-to: Your message of "Thu, 11 Dec 1997 01:30:13 EST." From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Dec 1997 00:10:29 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >There seem's to be a problem with FreeBSD machines on ppp dialup accessing >certain web servers running so FreeBSD on the web server. > >Myself and a person in the UK have noticed the same thing. > >The only thing i can see in common is that both of us having this problem >are dialing into a xylogics annex terminal server. This is caused by a bug in the annex terminal server - it doesn't properly handle TCP options. To work around this, set 'tcp_extensions" to "NO" in /etc/rc.conf. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Dec 11 00:21:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16312 for hackers-outgoing; Thu, 11 Dec 1997 00:21:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16305 for ; Thu, 11 Dec 1997 00:21:07 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA25335; Thu, 11 Dec 1997 00:21:05 -0800 (PST) To: 0000-Administrator cc: hackers@FreeBSD.ORG Subject: Re: Off topic on the freebsd vm In-reply-to: Your message of "Wed, 10 Dec 1997 15:11:50 PST." Date: Thu, 11 Dec 1997 00:21:05 -0800 Message-ID: <25331.881828465@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Uh huh. Folks, the signal-to-noise ratio in -hackers is bad enough; can we try to stay on-topic with purely FreeBSD related stuff? I'm sure that machine emulators are interesting to some segment of the population, just as one could say about 3D graphics, Artificial Intelligence or industrial process control. However, all of them also have their own forums on USENET where such discussion is more appropriate and I'd like to ask that folks take it there. Jamil seems to have an innate talent for straying off-topic and I would appreciate it if he could somehow address that shortcoming within himself before we all drown under a flood of email. :-} Jordan > > the instruction set will be call PISS > "Portable Instruction Set System" > > From owner-freebsd-hackers Thu Dec 11 00:22:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16435 for hackers-outgoing; Thu, 11 Dec 1997 00:22:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from home.gtcs.com (home.gtcs.com [206.54.69.238]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16397 for ; Thu, 11 Dec 1997 00:21:52 -0800 (PST) (envelope-from bruce@gtcs.com) Received: from gtcs.com (localhost.gtcs.com [127.0.0.1]) by home.gtcs.com (8.8.5/8.8.5) with ESMTP id BAA18546 for ; Thu, 11 Dec 1997 01:18:21 -0700 (MST) Disposition-Notification-To: bgingery@gtcs.com X-Comment1: in most cases both the Return-Receipt and Delivery-Notification X-Comment2: requests are part of an ongoing poll to determine what clients X-Comment3: and MTAs respond to the headers. Message-Id: <199712110818.BAA18546@home.gtcs.com> Date: Thu, 11 Dec 1997 01:18:19 -0700 (MST) From: bgingery@gtcs.com Reply-To: bgingery@gtcs.com Subject: Re: Why so many steps to build new kernel? To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="0-1681692777-881828304=:1749" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --0-1681692777-881828304=:1749 Content-Type: TEXT/plain; CHARSET=US-ASCII The attached is far from perfect, but it's what *I* built for 2.1.0 and have modified only slightly since for building a new kernel. One step that it DOESN'T have that I think it should is to look for the latest-modified file in /usr/src/sys//conf and default *that* as the kernel to build. What it *does* do, is ... Well, about 12-13 steps, including logging what's being done, archiving a copy of the kernel setup that's about to be built and logging ... Please take it if it's useful and modify it at will. It presumes a log at /usr/local/etc/changelog[.html] (I don't think I've ever converted this one to output HTML instead of just the original text changelog notations) and a mirror directory of from the filesystem starting at root for storage of the archived files at /usr/local/etc/syschanges/* At first, I just sent it to Archie who I thought might want to include it in what it appears he's going to do for actually setting up a config file, but then decided that others might want to comment on it, too. Bruce Gingery Advanced Integrators, LC --0-1681692777-881828304=:1749 Content-Type: APPLICATION/x-sh Content-Description: newkernel.sh #!/bin/sh # # I got tired of looking up the kernel recompile in the manual, so # have placed it here in a shell script! 2 Jan 1997 5:48 AM [bg] # AWK=/usr/bin/awk CP=/bin/cp DATE=/bin/date GREP=/usr/bin/grep LOGGER=/usr/bin/logger LN=/bin/ln MAKE=/usr/bin/make MV=/bin/mv RM=/bin/rm SED=/usr/bin/sed TEE=/usr/bin/tee TTYCMD=/usr/bin/tty UNAME=/usr/bin/uname WHO=/usr/bin/who LOGFILE=/usr/local/etc/changelog LOGTTY="`${TTYCMD} | ${SED} 's/\/dev\///'`"; REBUILDER="`/usr/bin/who am i | /usr/bin/awk '{print $1;}'`"; CONFIGPATH=usr/src/sys/i386/conf BACKUPPATH=/usr/local/etc/syschanges/${CONFIGPATH} CONFIGPATH=/${CONFIGPATH} KERNSTAMP="`${DATE} +'%Y.%m.%d-%H.%M.%S-%Z'`"; LOGFORMAT="+%a, %d %b %Y %H:%M:%S %Z"; LOGSTAMP=`${DATE} "${LOGFORMAT}"`; WHICHKERN="`${UNAME} -s`-`${UNAME} -r`"; if [ -z $1 ]; then NEWKERN="LDTENABLED"; else NEWKERN=$1; fi if [ ! -r ${CONFIGPATH}/${NEWKERN} ]; then echo Cannot find ${CONFIGPATH}/${NEWKERN} echo command format... echo " $0 [configname [clean]]" exit 1; fi MAKELOG=${CONFIGPATH}/makelog.${NEWKERN}-${KERNSTAMP} if [ -z $2 ]; then CLEAN=; elif [ X"$2" = X"clean" ]; then CLEAN="clean"; elif [ X"$2" = X"clean" ]; then CLEAN="CLEAN"; elif [ X"$2" = X"clean" ]; then CLEAN="Clean"; else echo command format... echo " $0 [configname [clean]]" exit 1; fi KERNNAME="`${GREP} '^ident' ${CONFIGPATH}/${NEWKERN} | ${AWK} '{print $2;}'`" echo Starting ${WHICHKERN} rebuild of \"${NEWKERN}\" as \"${KERNNAME}\" by ${REBUILDER} on ${LOGTTY} at ${LOGSTAMP} echo Copying current config file to ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} echo "" >> ${LOGFILE} echo "Starting ${WHICHKERN} rebuild of \"${NEWKERN}\" as \"${KERNNAME}\"" >> ${LOGFILE} echo " by ${REBUILDER} on ${LOGTTY} at ${LOGSTAMP}" >> ${LOGFILE} echo " invoked as $0 $*" >> ${LOGFILE} ${CP} -p ${CONFIGPATH}/${NEWKERN} ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} echo " conf stowed as ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP}" >> ${LOGFILE} NOWSTAMP=`${DATE} "${LOGFORMAT}"`; if [ -n ${CLEAN} ]; then /usr/sbin/config ${NEWKERN} EXITVAL=$? echo " /usr/sbin/config ${NEWKERN} at ${NOWSTAMP}" >> ${LOGFILE} else /usr/sbin/config -n ${NEWKERN} EXITVAL=$? echo " /usr/sbin/config -n ${NEWKERN} at ${NOWSTAMP}" >> ${LOGFILE} fi if [ ${EXITVAL} -gt 0 ]; then echo " exited at ${EXITVAL} (failed)" >> ${LOGFILE} echo " deleting archived ${NEWKERN} file" >> ${LOGFILE} ${RM} -f ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} exit ${EXITVAL}; fi cd ../../compile/${NEWKERN} NOWSTAMP=`${DATE} "${LOGFORMAT}"`; ${MAKE} depend EXITVAL=$? echo " ${MAKE} depend at ${NOWSTAMP}" >> ${LOGFILE} if [ ${EXITVAL} -gt 0 ]; then echo " exited at ${EXITVAL} (failed)" >> ${LOGFILE} echo " deleting archived ${NEWKERN} file" >> ${LOGFILE} ${RM} -f ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} exit ${EXITVAL}; fi if [ -n ${CLEAN} ]; then NOWSTAMP=`${DATE} "${LOGFORMAT}"`; ${MAKE} clean EXITVAL=$? echo " ${MAKE} clean at ${NOWSTAMP}" >> ${LOGFILE} if [ ${EXITVAL} -gt 0 ]; then echo " exited at ${EXITVAL} (failed)" >> ${LOGFILE} echo " deleting archived ${NEWKERN} file" >> ${LOGFILE} ${RM} -f ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} exit ${EXITVAL}; fi fi NOWSTAMP=`${DATE} "${LOGFORMAT}"`; ${MAKE} 2>&1 | ${TEE} ${MAKELOG} EXITVAL=$? echo " ${MAKE} at ${NOWSTAMP}" >> ${LOGFILE} ${LOGGER} -p auth.alert "Kernel rebuild of \"${NEWKERN}\" in progress" if [ ${EXITVAL} -gt 0 ]; then echo " exited at ${EXITVAL} (failed)" >> ${LOGFILE} echo " deleting archived ${NEWKERN} file" >> ${LOGFILE} ${RM} -f ${BACKUPPATH}/${NEWKERN}-${KERNSTAMP} ${GREP} '^error' ${MAKELOG} > ${CONFIGPATH}/obvous-errors.${NEWKERN}-${LOGSTAMP} exit ${EXITVAL}; fi for sv in /${KERNNAME}.old~~~~ /${KERNNAME}.old~~~ /${KERNNAME}.old~~ /${KERNNAME}.old~ /${KERNNAME}.old; do if [ -x ${sv}~ ]; then if [ -x ${sv} ]; then ${MV} ${sv} ${sv}~; echo " ${sv} saved as ${sv}~" >> ${LOGFILE} fi fi done NOWSTAMP=`${DATE} "${LOGFORMAT}"`; ${MAKE} install EXITVAL=$? echo " ${MAKE} install at ${NOWSTAMP}" >> ${LOGFILE} if [ ${EXITVAL} -gt 0 ]; then echo " exited at ${EXITVAL} (failed)" >> ${LOGFILE} exit ${EXITVAL}; fi logger -p crit.emerg "New \"${NEWKERN}\" kernel installed as /${KERNNAME}" if [ X"${KERNNAME}" != X"${NEWKERN}" ]; then ${LN} -f /${KERNNAME} /${KERNNAME}.${NEWKERN} echo " /${KERNNAME} hard-linked to /${KERNNAME}.${NEWKERN}" echo " /${KERNNAME} hard-linked to /${KERNNAME}.${NEWKERN}" >> ${LOGFILE} fi --0-1681692777-881828304=:1749-- From owner-freebsd-hackers Thu Dec 11 00:38:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19337 for hackers-outgoing; Thu, 11 Dec 1997 00:38:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19332 for ; Thu, 11 Dec 1997 00:38:00 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA25497; Thu, 11 Dec 1997 00:37:52 -0800 (PST) To: Chuck Robey cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Wed, 10 Dec 1997 22:02:16 EST." Date: Thu, 11 Dec 1997 00:37:52 -0800 Message-ID: <25493.881829472@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Actually, used Sparc stuff seems to be readily, and cheaply available. I Yes, but not the 64-bit UltraSPARC, and that's what this port is initially (and perhaps forever) going to be targetted at. The cheap hardware is only likely to be good for running NetBSD in the short-to-medium term, but if that's what you're into then go for it. :-) For the record, I doubt that adding support for the earlier SPARCs is going to be as trivial as everyone expects, and I don't expect Jason Evans' bosses to put too much effort into this either considering that the already-sold hardware is not very important to their bottom line. :) Remember that we *had* a SPARC port at one stage but it died for lack of attention (I don't even think anyone even has the bits around anymore), so if something's not done directly by Jason then I'm a bit skeptical about it happening at all. Jordan From owner-freebsd-hackers Thu Dec 11 00:39:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19516 for hackers-outgoing; Thu, 11 Dec 1997 00:39:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19510 for ; Thu, 11 Dec 1997 00:39:37 -0800 (PST) (envelope-from spork@super-g.com) Received: from ns2.inch.com by relay7.UU.NET with ESMTP (peer crosschecked as: ns2.inch.com [207.240.140.102]) id QQdtkp09933; Thu, 11 Dec 1997 00:54:35 -0500 (EST) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by ns2.inch.com (8.8.6/8.8.5) with ESMTP id AAA22108 for ; Thu, 11 Dec 1997 00:59:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.7/8.8.5) with SMTP id AAA14915; Thu, 11 Dec 1997 00:49:09 -0500 (EST) Date: Thu, 11 Dec 1997 00:49:05 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Adam Turoff cc: hackers Subject: RE: I seriously need some networking help In-Reply-To: <348F48CE@smginc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Adam Turoff wrote: > Just another datapoint. I have a similar network setup: > FBSD box with two identical PCI Ethernet cards, > Crossover cable to a Cicso router Throw one of those $30 hubs here, and the problem should go away... > whenever the T1 goes down, the ethernet port > on the router goes down. Apparently, when FBSD detects Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB From owner-freebsd-hackers Thu Dec 11 00:41:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19766 for hackers-outgoing; Thu, 11 Dec 1997 00:41:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA19758 for ; Thu, 11 Dec 1997 00:40:56 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA25529; Thu, 11 Dec 1997 00:40:48 -0800 (PST) To: Jason Evans cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Wed, 10 Dec 1997 19:17:50 PST." Date: Thu, 11 Dec 1997 00:40:48 -0800 Message-ID: <25525.881829648@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Wed, 10 Dec 1997, Jordan K. Hubbard wrote: > > This is probably a bit premature - why not wait until the port is actually > > close to being finished and then check the prices? You know how volatile > > things are in this industry, and they may well be half the current price > > by then. :-) ^^^^^^^^^^^^^^^^^^^^^^ > > A true optimist. =) No, a true pessimist - that's how long I expect it to take you to do this port. :-) :-) Jordan From owner-freebsd-hackers Thu Dec 11 00:43:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20015 for hackers-outgoing; Thu, 11 Dec 1997 00:43:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20005 for ; Thu, 11 Dec 1997 00:43:40 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA25552; Thu, 11 Dec 1997 00:43:38 -0800 (PST) To: Jacques Vidrine cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Whence DEC Alpha port? (was Re: Beginning SPARC port) In-reply-to: Your message of "Wed, 10 Dec 1997 21:06:45 CST." <199712110306.VAA02689@kai.communique.net> Date: Thu, 11 Dec 1997 00:43:38 -0800 Message-ID: <25548.881829818@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Speaking of ports of FreeBSD ... > > ... Is there currently a DEC Alpha port under development anywhere? I "Under development" may be a bit overstated, but it's certainly something that a lot of folks are thinking about, just as soon as they have themselves cloned and have the necessary time. :) Join the alpha@freebsd.org mailing list if you'd like to try and help jump-start this effort. Jordan > recently acquired a DEC Alpha, and I am hoping to spend some of its > cycles and mine next year working with the port, and hopefully > furthering it. But I guess I oughta find out if it exists first :-) > > Jacques Vidrine From owner-freebsd-hackers Thu Dec 11 00:51:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA20644 for hackers-outgoing; Thu, 11 Dec 1997 00:51:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from acroal.com (firewall0.acroal.com [209.24.61.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20637 for ; Thu, 11 Dec 1997 00:51:02 -0800 (PST) (envelope-from jamil@acroal.com) Received: from localhost (jamil@localhost) by acroal.com (8.8.8/8.8.7) with SMTP id AAA29874 for ; Thu, 11 Dec 1997 00:41:09 -0800 (PST) (envelope-from jamil@acroal.com) Date: Thu, 11 Dec 1997 00:41:09 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" To: hackers@freebsd.org Subject: This IS relevant, you'll realize why later. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have any numbers for the sum total amount of information existing in the universe? I would guess the appropriate way to tablulate this would be to take the total ammount of matter in the form of subatomic particles, and energy is photons and account for their position in three coordinates and velocity vector. I'm certainly no physicist, but from what I've read there are *NO* numbers for the ammount of matter in the universe just percentage approximations. My guess is that you could account for this all in less than 2^1000 bits = 10^300, what this essentially means to me is that it would be impractical to build a machine with a word size expressed with more that 1024 bits (the expression of the word size, not the wordsize itself). From owner-freebsd-hackers Thu Dec 11 00:58:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21174 for hackers-outgoing; Thu, 11 Dec 1997 00:58:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21169 for ; Thu, 11 Dec 1997 00:58:36 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id AAA25638; Thu, 11 Dec 1997 00:58:28 -0800 (PST) To: Michael Hancock cc: "J. Weatherbee - Senior Systems Architect" , FreeBSD Hackers Subject: Re: OS Ports In-reply-to: Your message of "Thu, 11 Dec 1997 14:54:58 +0900." Date: Thu, 11 Dec 1997 00:58:28 -0800 Message-ID: <25634.881830708@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What you suggested was pretty masochistic. You really want to be closer > to where your going than where you are now. Also, you don't want to > destablise stable! That latter point is also one I should have made. Doing it in -stable would, of course, mean that the Sun support would *never* get merged into FreeBSD since that would be antiethical to the purpose of -stable. We don't even bring things like x86 SMP support across from 3.0 to 2.2 (and never will), you think we're going to totally break character and plop an entirely different architecture into it? :-) No. Jordan From owner-freebsd-hackers Thu Dec 11 01:13:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22143 for hackers-outgoing; Thu, 11 Dec 1997 01:13:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA22127 for ; Thu, 11 Dec 1997 01:13:27 -0800 (PST) (envelope-from shigio@wafu.netgate.net) Received: from chiota.signet.or.jp (INS62.tama.dti.ne.jp [210.159.144.16]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id BAA10321; Thu, 11 Dec 1997 01:15:38 GMT Message-Id: <199712110115.BAA10321@wafu.netgate.net> Received: from chiota.signet.or.jp (localhost.signet.or.jp [127.0.0.1]) by chiota.signet.or.jp (8.8.5/) with ESMTP id SAA04060; Thu, 11 Dec 1997 18:13:12 +0900 (JST) To: John Polstra cc: shigio@wafu.netgate.net, hackers@freebsd.org Subject: Re: [RFC] path converting functions. Date: Thu, 11 Dec 1997 18:13:11 +0900 From: Shigio Yamaguchi Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199712110527.VAA24691@austin.polstra.com>, John Polstra wrote: > Well, in my opinion the example set by realpath(3) is bad and it > shouldn't be copied in new code. I say again, if a function writes > into a caller-supplied buffer then the caller should also specify > how large the buffer is. Using a compiled in assumption such as > MAXPATHLEN is risky at best. What if you build your program on one > machine and then run it on a machine where MAXPATHLEN has a different > value? Or, for that matter, on the same machine after some wiz has > decided to change the value of MAXPATHLEN? You are right. It seems your style is better and I understood getcwd(3) which is the new interface of getwd(3) uses your style. I'll change the interface like this. SYNOPSIS #include char * abs2rel(const char *path, const char *base, char result[MAXPATHLEN]) | v SYNOPSIS char * abs2rel(const char *path, const char *base, char *result, size_t size) ~~~~~~~~~~~~ ~~~~~~~~~~~ buffer address, buffer size > > Anyway, that's all the arguing I want to do. You asked for opinions > and I gave you mine. :-) It's precious to me. Thank you. :) -- Shigio Yamaguchi (Freelance programmer) Mail: shigio@wafu.netgate.net, WWW: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Thu Dec 11 01:34:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24055 for hackers-outgoing; Thu, 11 Dec 1997 01:34:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA24026 for ; Thu, 11 Dec 1997 01:34:22 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA25823; Thu, 11 Dec 1997 01:34:08 -0800 (PST) To: Jonathan Mini cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Wed, 10 Dec 1997 23:49:09 PST." <19971210234909.29178@micron.mini.net> Date: Thu, 11 Dec 1997 01:34:07 -0800 Message-ID: <25819.881832847@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Ok. I was shooting for a 'minumum work' approach, and then once I got people >used to the GUI I was going to be radical and start talking about replacing it >with the new config junk. But, you're one step ahead of me. Bite all of the bullet at once on this issue, I say! :-) > We need to do this in three stages then : > 1) decide what types of "configurability" we want to allow the config > utility to handle. compile-time options, compiled-in device, managing > LKMs (for now, I hope to see the kld code replace it) and other types > of kernel behavior would be a good idea too. > Plausably, we could extend this to cover any sort of system > configuration, but whether we want to do that is what we'd talk about > in this stage. I think the above has actually been covered in some detail in this mailing list over the last 3 or 4 other times this topic has come up, but my own memory is faint on the details. Perhaps those previously involved in raising this issue (was one of them Mike Smith, my memory seems to tell me? And Terry?) would be willing to provide a summary of the state of affairs last we left it, but from what I recall it was basically agreed that: o You should be able to specify just about any parameter with one orthgonal scheme for picking defaults, specific values or allowable ranges of values. o You should be able to specify whether a device is optional, mandatory, present-but-disabled, etc. o Proper device sub-configuration support should replace the bit-twiddling of flags. o It should be possible to group devices by class so that if the user selects "ahc0" as an option in some GUI, for example, the interface can know to ask for the appropriate sd0/cd0/st0 device sub-configuration information. Dependencies would also be handled similarly ("can't have *that* without *this*"). o It should be possible to associate documentation strings and/or URLs with device entries so that they can actually be described to the user. o The new configuration format should still be ASCII and editable by Mere Humans(tm), just in a format which is much more easily machine-parsed. And that's about all I can remember. I'm sure this will jog the memories of others, though. :) > 2) Once we have what we want to classify in our database defined, we > should decide on a database method to store it. Most likely, due to > extendability, a relational database will be the product of this stage. > The exact format would be the issue under debate here. Eek! See my comments about the ASCII part. I do remember people being fairly adamant about this part, so you might want to capitulate early and save valuable time. :-) > 3) Then I get to actually write the database-handling code, and the > GUI to deal with it. If you don't mind, I indent to not use > libdialog. :) If you'd said that you were, I'd have felt it my duty to recommend strongly against it. :-) Jordan From owner-freebsd-hackers Thu Dec 11 01:38:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24491 for hackers-outgoing; Thu, 11 Dec 1997 01:38:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA24486 for ; Thu, 11 Dec 1997 01:38:15 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id BAA17394; Thu, 11 Dec 1997 01:37:35 -0800 (PST) Message-ID: <19971211013734.16942@micron.mini.net> Date: Thu, 11 Dec 1997 01:37:34 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971210234909.29178@micron.mini.net> <25819.881832847@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <25819.881832847@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 01:34:07AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > Bite all of the bullet at once on this issue, I say! :-) Very cool. Much deleted in this repsonse, others forthcoming to touch the other relevant issues. > > 3) Then I get to actually write the database-handling code, and the > > GUI to deal with it. If you don't mind, I indent to not use > > libdialog. :) > > If you'd said that you were, I'd have felt it my duty to recommend > strongly against it. :-) Excellent that we are of the same opinion. I have heard you complain before about libdialog. If I were to write another (smaller, and more acceptable) CUI would you be interested in using it in sysinstall also? I ask this because I'd like to see the same UI look-and-feel between those two applications. Perhaps a new line of 'system configuration' applications is somewhere in the future... -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Thu Dec 11 01:38:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA24558 for hackers-outgoing; Thu, 11 Dec 1997 01:38:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA24547 for ; Thu, 11 Dec 1997 01:38:35 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA25889; Thu, 11 Dec 1997 01:38:28 -0800 (PST) To: Jaye Mathisen cc: Open Systems Networking , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP problem In-reply-to: Your message of "Wed, 10 Dec 1997 23:48:41 PST." Date: Thu, 11 Dec 1997 01:38:28 -0800 Message-ID: <25886.881833108@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Seems to me I remember somebody saying something about a similar > situation, and it was fixed by changing the MTU to something else... That was me, over my ISDN line (which goes ed0<->sl0<->ed0<->outside), and I "fixed" it by setting the MTU on the sl0 device to 1500. Before that, I couldn't look at places like www.sunlabs.com. David and I talked about it for quite awhile and looked at some tcpdump output, but we never could figure it out. Jordan From owner-freebsd-hackers Thu Dec 11 01:51:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA26473 for hackers-outgoing; Thu, 11 Dec 1997 01:51:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA26446 for ; Thu, 11 Dec 1997 01:51:45 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id KAA02539; Thu, 11 Dec 1997 10:50:08 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id KAA28589; Thu, 11 Dec 1997 10:50:04 +0100 (MET) Message-ID: <19971211105003.AB51394@mars.hsc.fr> Date: Thu, 11 Dec 1997 10:50:03 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: tlambert@primenet.com (Terry Lambert) Cc: jamil@acroal.com (J. Weatherbee - Senior Systems Architect), jasone@canonware.com, hackers@FreeBSD.ORG Subject: Re: OS Ports References: <199712110017.RAA29759@usr02.primenet.com> X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: <199712110017.RAA29759@usr02.primenet.com>; from Terry Lambert on Dec 11, 1997 00:17:49 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > > emulator, I.E. 68330, 68331, 68332, 68F33, 68334, 68336, 68340, 68341, > > 68349, or 68360 emulator. Simply because I have some very good > > familiarity with the 68hc11 series. And the 68300's are actually still > > AFAIK, there's no NetBSD (for example) for the processors you list. There probably never will: the 68hc11 series are just souped-up 6800-based microcontrollers with extended instruction set. Very easy to find in France because they're used in a popular, uh, video converter. I've seen a port of gcc for these but have never actually tried it. There are also several assemblers and emulators running under Unix, some of them are even in the -ports collection I seem to recall. On the other hand, there are at least two 68K emulators that I know of: one of them in MAME, the other in the Amiga emulator I forgot the name of. Maybe they're based on the same code. They're written in portable C and though AFAIK they don't emulate the 68030/68040 they're probably a good starting point for this. -- Pierre.Beyssac@hsc.fr From owner-freebsd-hackers Thu Dec 11 02:00:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27578 for hackers-outgoing; Thu, 11 Dec 1997 02:00:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27544 for ; Thu, 11 Dec 1997 02:00:13 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id CAA26110; Thu, 11 Dec 1997 02:00:08 -0800 (PST) To: Jonathan Mini cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Thu, 11 Dec 1997 01:37:34 PST." <19971211013734.16942@micron.mini.net> Date: Thu, 11 Dec 1997 02:00:08 -0800 Message-ID: <26106.881834408@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If I were to write another (smaller, and more acceptable) CUI > would you be interested in using it in sysinstall also? YES! YES! Or, to put it another way, YES! :-) The alternative is TurboVision and, as much as I rather like it as a CUI toolkit and find its look-and-feel to be second to none in the CUI domain (in fact, I think I can say without fear of hyperbole that it goes about as far as it's possible to go with a CUI, period), there's just this big huge problem with it. It's in C++. I hate C++ and so do just about all of the other installation hackers, so we have something of an impasse in the interface group right now (heck, for the last 8 months even). Give me something that's written in straight C and easy to wrap into TCL (which should be possible unless you decide to pass all kinds of nasty structures around and expose that in the C API) and I'll be your friend for life. OK, so maybe that doesn't sound like such a treat, so let me just say that I'd really really appreciate it and so would many others. :) We basically just need: o Buttons - pushbutton, radio, checkbox. o Scrolling list menus (or scrolling arrays of buttons, however you want to conceptualize it) o Entry fields with reasonably emacs-like character editing support. o Scrolling text boxes and simple text fields. o Checkbox / Radio o Gauges. o Compound dialogs. o Simple forms entry. And we could do everything that sysinstall does messily with libdialog today. Support for color and the mouse would be optional niceties, but not strictly necessary. Would have to look reasonably decent in at least syscons and xterm (vt100) display modes and that's about it. What do you think? Jordan From owner-freebsd-hackers Thu Dec 11 02:06:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA28779 for hackers-outgoing; Thu, 11 Dec 1997 02:06:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA28774 for ; Thu, 11 Dec 1997 02:06:03 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA17519; Thu, 11 Dec 1997 02:05:57 -0800 (PST) Message-ID: <19971211020555.60627@micron.mini.net> Date: Thu, 11 Dec 1997 02:05:55 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971210234909.29178@micron.mini.net> <25819.881832847@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <25819.881832847@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 01:34:07AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > We need to do this in three stages then : > > 1) decide what types of "configurability" we want to allow the config > > utility to handle. compile-time options, compiled-in device, managing > > LKMs (for now, I hope to see the kld code replace it) and other types > > of kernel behavior would be a good idea too. > > Plausably, we could extend this to cover any sort of system > > configuration, but whether we want to do that is what we'd talk about > > in this stage. > > I think the above has actually been covered in some detail in this > mailing list over the last 3 or 4 other times this topic has come up, > but my own memory is faint on the details. Perhaps those previously > involved in raising this issue (was one of them Mike Smith, my memory > seems to tell me? And Terry?) would be willing to provide a summary > of the state of affairs last we left it, but from what I recall it > was basically agreed that: Somehow I'm not surprised. I'll assume that Terry'll comment somewhere along the line, whether or not he was originally noisy about it. :) (I know several jokes that start with "Terry walked into a bar with a Rabbi and a Priest..", but that's not the point here... ) > o You should be able to specify just about any parameter with > one orthgonal scheme for picking defaults, specific values or > allowable ranges of values. Noted : + option classes of several types should be supported. An option would be defined as anytihng that is settable during compile-time. This would mean that items such as compiled-in devices, pseudo-devices, filesystems, etc, as well as what we currenly call an "option" would be optionable. + each option class would have a series of named entires in a "template." This template would define the kind of settings are allowed, required, obsolete, etc. There would be multiple setting types, one for each kind of C data type : one to represent a struct, an array, an integer, a valid subrange of an integer or string, a string itself, a boolean, and a a construct for flags comes to mind and wouldn't be hard to implement. (A recursive data definition is implied here, thus easily attacking structs, arrays, and subranges) + series of "database templates" would be possible, or built-in. Meaning that two things are possible : 1) default settings can be noted in the same database as defines an option, as well as a series of "common" (or possible) sets of settings. As an example, see what I showed about the "settings" for COM1, COM2, etc with sio. 2) The equivalent of a kernel configuration file can also act as a tmeplate. merging several kernel config files would be fairly easy, providing that conflicts can be resolved by a general rule. For example, consider a site creating a "template" config file for their system, and then applying "local" files to that template for each machine's kernel. With this method, several custom kernels could be compile in one batch, with simple generalization among them. > o You should be able to specify whether a device is optional, > mandatory, present-but-disabled, etc. Noted : + all option classes can be tagged as requiring a certain set of options, something like a boolean evaluation would be best (only ok when (added(this) && added(that)) || added(theotherthing)) Obviously, the classification of each option's settings would be a per-option-class, but I would assume that things like the device option class would contain a "present but disable" setting. > o Proper device sub-configuration support should replace the > bit-twiddling of flags. Noted : + all options can contain more information than a simple #define, although having an option _create_ a #define would certainly be possible. (it would have to, otherwise detecting features enabled would be hell, and it would break current code) Obviously, creation of a "setting" struct for that device would be extremely possible. This would most likely require rewriting user-config from scratch. > o It should be possible to group devices by class so that if > the user selects "ahc0" as an option in some GUI, for example, > the interface can know to ask for the appropriate sd0/cd0/st0 > device sub-configuration information. Dependencies would also > be handled similarly ("can't have *that* without *this*"). + dependancies I talked about above, but having an option require a certain logical expression to be true would handle this well. + Not only that, but the RESOURCES used by a device would be classified and managed as well, so that the kernel config would know about possible conflicts before compling the kernel. This would be handled by creating classes of resources, in which a range or set of ranges could be allocated. This same method would allow the handling of scsi disk hardwiring. > o It should be possible to associate documentation strings and/or URLs > with device entries so that they can actually be described to the > user. + I was assuming that there would be two calssifications of documentation avialable about a specific option or option class : 1) internal documentation. This would be a string or set of strings that is displayed under various contexts for an option. This provides things like names, short one-line descriptions, etc. 2) external docuimentation. Something like a URL pointing to a web-page or document handbook as well as a reference to a man-page would be possible. I'm assuming that the CUI would be able to fire off the appropriate reader to view this "on the fly." > o The new configuration format should still be ASCII and editable > by Mere Humans(tm), just in a format which is much more easily > machine-parsed. Of course. I would shoot anybody who said otherwise, and then bill the travel costs to thier next-of-kin. > And that's about all I can remember. I'm sure this will jog the > memories of others, though. :) > > > 2) Once we have what we want to classify in our database defined, we > > should decide on a database method to store it. Most likely, due to > > extendability, a relational database will be the product of this stage. > > The exact format would be the issue under debate here. > > Eek! See my comments about the ASCII part. I do remember people > being fairly adamant about this part, so you might want to capitulate > early and save valuable time. :-) I meant the specific layout of the ASCII file that contains the classification. I was assuming a relational database (contained in a text file) because of it's flexibility, extendability, and the ability to "survive" across multiple versions without modification. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Thu Dec 11 02:16:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00515 for hackers-outgoing; Thu, 11 Dec 1997 02:16:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00490 for ; Thu, 11 Dec 1997 02:16:27 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712111016.CAA00490@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA276245353; Thu, 11 Dec 1997 21:15:53 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 11 Dec 1997 21:15:52 +1100 (EDT) Cc: chuckr@glue.umd.edu, jasone@canonware.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <25493.881829472@time.cdrom.com> from "Jordan K. Hubbard" at Dec 11, 97 00:37:52 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Jordan K. Hubbard, sie said: > > > Actually, used Sparc stuff seems to be readily, and cheaply available. I > > Yes, but not the 64-bit UltraSPARC, and that's what this port is > initially (and perhaps forever) going to be targetted at. The cheap > hardware is only likely to be good for running NetBSD in the > short-to-medium term, but if that's what you're into then go for > it. :-) Dare I mention L**** too ? > For the record, I doubt that adding support for the earlier SPARCs is > going to be as trivial as everyone expects, and I don't expect Jason > Evans' bosses to put too much effort into this either considering that > the already-sold hardware is not very important to their bottom > line. :) [...] Sun do re-sell sun4c and sun4m machines themselves (I guess it took them a while to work out there was a 2nd hand market for some of the gear), so there is some (if little) incentive to do it. Oh, the SS5 (sun4m) was still on the pricelist around the middle of this year...and I've not heard anyone say they're going to EOL it yet (if you've got an E10000, the SS5's make a good console) either. Darren p.s. I don't think that adding sun4m will be any easier/harder than sun4u. The hard part is going to be adding a non-x86 architecture to an OS which appears very much to be machine-dependant. From owner-freebsd-hackers Thu Dec 11 02:19:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00854 for hackers-outgoing; Thu, 11 Dec 1997 02:19:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00845 for ; Thu, 11 Dec 1997 02:19:03 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA17538; Thu, 11 Dec 1997 02:18:57 -0800 (PST) Message-ID: <19971211021856.61158@micron.mini.net> Date: Thu, 11 Dec 1997 02:18:56 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > If I were to write another (smaller, and more acceptable) CUI > > would you be interested in using it in sysinstall also? > > YES! YES! Or, to put it another way, YES! :-) I thought so, but wanted to make ABOSLUTELY sure. :) > The alternative is TurboVision and, as much as I rather like it as a > CUI toolkit and find its look-and-feel to be second to none in the CUI > domain (in fact, I think I can say without fear of hyperbole that it > goes about as far as it's possible to go with a CUI, period), there's You and I are on the same bandwidth. I was brought into the event-driving UI world with Turbo Pascal's version of Turbo Vision 2.0 (which, btw, is _much_ better than the C++ version by far. It is cleaner, smaller, and more ellegant in implementation) Ever since then, I have been unimpressed with other GUI's, as my impression is always that they are bloated, half-functional, and ugly. :) > just this big huge problem with it. It's in C++. I hate C++ and so > do just about all of the other installation hackers, so we have > something of an impasse in the interface group right now (heck, for > the last 8 months even). I HATE C++. It has four problems that I consider unacceptable : 1) It's syntax does not remain constant. For example, a '<<' does not always mean "binary shift left." 2) It had a large number of puns, (Bison would call them Reduce/Reduce conflicts) that is situations where one construct can mean multiple things. This is made most annoying when it combines with #1, in that an operator can have several paths to reach it's goal, and the compiler picks among them implicitly. 3) C++ does not implement data hiding. Sure, you have opaque structs, but you cannoy make an opaque class. That is, you cannot have a class defined where you know how to interface with the functions, but not the details of the internal data. Because you have to define the private data within the same scope as the public interface, private datatypes aren't possible. 4) C++ does things without you knowing it, whether or not you are using classes at all. This goes along with the collision of #1 and #2. A good example is if you define a new data-type, say a fixed real. This fixed real is represented in memory by an integer, which causes problems with the automatic implcit casting code, especially in conjunction with 'overloading' (see #2) where a functino with the same name can handle multiple data types. When it is possible so implicitly cast a foreign data type to more than one function, the compiler gets to (basically) blow up, and the casting has to happen explicitly. But, implcit casting is supposed to be a big deal. :) There are my gripes with C++. > Give me something that's written in straight C and easy to wrap into > TCL (which should be possible unless you decide to pass all kinds of > nasty structures around and expose that in the C API) and I'll be your > friend for life. OK, so maybe that doesn't sound like such a treat, > so let me just say that I'd really really appreciate it and so would > many others. :) > > We basically just need: > > o Buttons - pushbutton, radio, checkbox. > > o Scrolling list menus (or scrolling arrays of buttons, > however you want to conceptualize it) > > o Entry fields with reasonably emacs-like character editing > support. ( ewww, emacs ) > > o Scrolling text boxes and simple text fields. > > o Checkbox / Radio > o Gauges. > > o Compound dialogs. > > o Simple forms entry. > > And we could do everything that sysinstall does messily with libdialog > today. Support for color and the mouse would be optional niceties, > but not strictly necessary. Would have to look reasonably decent in > at least syscons and xterm (vt100) display modes and that's about it. > > What do you think? I have another project which requires a nearly-exactly-identical system. I will spend a few days creating an API and then send you an overview for comments. Do you want me to send it to you personally, post it to hackers, or make the documents available via the web? (My system will be expandable to graphics modes, just FYI) -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Thu Dec 11 02:35:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02271 for hackers-outgoing; Thu, 11 Dec 1997 02:35:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02260 for ; Thu, 11 Dec 1997 02:35:19 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712111035.CAA02260@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA278566494; Thu, 11 Dec 1997 21:34:54 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: jgrosch@superior.mooseriver.com Date: Thu, 11 Dec 1997 21:34:54 +1100 (EDT) Cc: handy@sag.space.lockheed.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971210130720.53173@mooseriver.com> from "Josef Grosch" at Dec 10, 97 01:07:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [...] > My experance with SPARCs is limited but basicly they come in 3 flavors, > sun4, sun4m, and sun4u. SPARC 1, 1+, 2, IPC, and IPX (i think) were > sun4s. meaning that were uniprocessor machine and were not capable of > supporting multiprocessor. SPARC 5, 10, and 20 are sun4m which means they > do support multiprocessor. The ultra 1, ultra 2, and up are sun4u. Not > really sure what the differance between the sun4m and the sun4u is. I'm > doing this from memory so I sure I munged a few details. sun4 is reprsents the architecture, not just CPU. There's sun4, sun4c, sun4d, sun4m, sun4u (hmmm, I wonder if sun4u applies to the E10000). The 4/xxx series were all sun4 except the 4/150. 4/150, SS1, SS1+, SS2, IPC, IPX, SLC, ELC are all sun4c. SS 6xxMP/yy, LC, LX, voyager, SS10, SS5, SS20, SS4 are all sun4m. SS 1000, SS 2000 are both sun4d. The SS10, SS20, SS6xxMP/yy, SS1000 and SS2000 are the only non-ultra multi-cpu Sparc configurations from Sun. From owner-freebsd-hackers Thu Dec 11 02:41:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02909 for hackers-outgoing; Thu, 11 Dec 1997 02:41:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02892 for ; Thu, 11 Dec 1997 02:41:25 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA18888; Thu, 11 Dec 1997 02:44:27 -0800 (PST) Message-Id: <199712111044.CAA18888@implode.root.com> To: "Jordan K. Hubbard" cc: Jaye Mathisen , Open Systems Networking , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP problem In-reply-to: Your message of "Thu, 11 Dec 1997 01:38:28 PST." <25886.881833108@time.cdrom.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Dec 1997 02:44:27 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Seems to me I remember somebody saying something about a similar >> situation, and it was fixed by changing the MTU to something else... > >That was me, over my ISDN line (which goes ed0<->sl0<->ed0<->outside), >and I "fixed" it by setting the MTU on the sl0 device to 1500. Before >that, I couldn't look at places like www.sunlabs.com. David and I >talked about it for quite awhile and looked at some tcpdump output, >but we never could figure it out. We didn't? I thought we determined that this was caused by the remote machine not getting the ICMP would-fragment messages that your router was returning? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Dec 11 04:04:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA07322 for hackers-outgoing; Thu, 11 Dec 1997 04:04:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA07315 for ; Thu, 11 Dec 1997 04:04:11 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id EAA26651; Thu, 11 Dec 1997 04:04:06 -0800 (PST) To: Jonathan Mini cc: The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Thu, 11 Dec 1997 02:18:56 PST." <19971211021856.61158@micron.mini.net> Date: Thu, 11 Dec 1997 04:04:06 -0800 Message-ID: <26647.881841846@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I HATE C++. It has four problems that I consider unacceptable : Woogod, not a language war right now please, I just ate. :-) Needless to say, it sounds like we're in violent agreement on C++. Next topic! :) > > o Entry fields with reasonably emacs-like character editing > > support. > > ( ewww, emacs ) Nonetheless, it's what people are used to from libdialog. Keep it, please, or my fingers will hate you. :) > I have another project which requires a nearly-exactly-identical system. > I will spend a few days creating an API and then send you an overview for > comments. Do you want me to send it to you personally, post it to hackers, or > make the documents available via the web? However makes you happiest! :) > (My system will be expandable to graphics modes, just FYI) Cool - check out /usr/src/lib/libvgl too, in that case, just so you've some advance idea of one additional "drawing layer" might eventually look like and hopefully thus prevent painting yourself into any ncurses-colored corners. :-) Jordan From owner-freebsd-hackers Thu Dec 11 04:05:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA07470 for hackers-outgoing; Thu, 11 Dec 1997 04:05:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA07463 for ; Thu, 11 Dec 1997 04:05:28 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id EAA26669; Thu, 11 Dec 1997 04:05:15 -0800 (PST) To: dg@root.com cc: Jaye Mathisen , Open Systems Networking , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP problem In-reply-to: Your message of "Thu, 11 Dec 1997 02:44:27 PST." <199712111044.CAA18888@implode.root.com> Date: Thu, 11 Dec 1997 04:05:15 -0800 Message-ID: <26666.881841915@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > We didn't? I thought we determined that this was caused by the remote > machine not getting the ICMP would-fragment messages that your router was > returning? I seem to recall that this was one of the theories, but didn't we collect some trace data right at the end which shot that one down? Jordan From owner-freebsd-hackers Thu Dec 11 04:37:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA08891 for hackers-outgoing; Thu, 11 Dec 1997 04:37:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA08882 for ; Thu, 11 Dec 1997 04:36:49 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id EAA26803; Thu, 11 Dec 1997 04:36:40 -0800 (PST) To: Jason Evans cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Wed, 10 Dec 1997 08:56:25 PST." Date: Thu, 11 Dec 1997 04:36:40 -0800 Message-ID: <26799.881843800@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As has been alluded to in some of Jordan Hubbard's email, Sun > Microelectronics (SME, the processor division of Sun) recently discussed > paying FreeBSD core to officially support a port of FreeBSD to SPARC. Great! I'd almost concluded that this had just faded away again, and it's good to hear that SME didn't just give up when we were unable to find any available personnel here. We'll certainly do our best to support your efforts as various issues come up! > full-time employee of SME, and estimate that I can spend 30-35 hours per > week of my work week on the SPARC FreeBSD porting effort (plus whatever > personal time I spend). Ah, so that really means you're good for at least 60 hours a week then! Good man! Real dedication! ;-) > This is a wonderful opportunity for me, as it is for the FreeBSD community > in general. I'm getting paid real money to do this, so I have no problems > with devoting time to the project. My additional duties here at SME Sounds like a winning formula to me. I guess you're probably going to want to start with the compiler issues first then, eh? Peter? Soren? John Polstra? You might wish to step forward and shake hands with Jason here, guys, because he's probably going to be the principal motive force behind your toolchain upgrade in -current! :-) > That said, I'll probably inadvertently ask a lot of questions that will > make you think, "This guy's trying to port an OS?!" Feel free to point Don't worry, we'd be thinking that no matter *who* you were. It's a big job. :-) Seriously, ask away. Like I said, we'll do our best. > 1) Is it possible with cvsup to maintain my own source tree with my > modifications, yet stay synched with current, so that once I have the > kernel running, I can submit a single update to the current tree (or have > someone with write access do it for me)? Yes, you can, but it's not immediately trivial since you need to make sure that your own changes are checked in along a branch that won't have its RCS ID collide with anything coming up behind you, so to speak, in the main tree. There is some early support for this in both CVS and CVSup, but I can't remember the full procedures involved. Didn't somebody document the procedure in a message to -hackers once, perhaps Peter? Help me out here, guys! :-) > 2) Supposing that 1) is possible, does it make more sense to simply grab > current once, port it to SPARC, then deal with merging it back into > current? This would be one major effort, versus constant small efforts to > stay current. I think your idea of trying to actively track -current, as occasionally rocky a road as that might sometimes be, is the superior option. Like I said, there will be a lot of up-front toolchain issues to deal with and it's quite possible that an updated toolchain could become both SPARC and x86 aware (and hence a default part of current) long before you ever actually run FreeBSD on a SPARC. By tracking -current, you could fight that battle once and then stop worrying about it since it would be integrated into your working sources automatically. > 3) Again supposing that 1) is possible, is it additionally feasible to > have multiple people working on my local tree with some sort of revision > control? Absolutely. Assuming that you've done all that's required to prevent collision (and again, it's going to take Peter or John P to more fully answer that question) you can use the full CVS command set to manage your tree there. You could even set up a local cvsupd and offer it to others via cvsup, allowing your repository to be replicated in the same manner as ours is. > I haven't asked anyone about getting write access to the source tree. > Perhaps that is better discussed in private email. I'm not yet sure > whether I need access to get any work done. If so, is there a rite of > passage? =) Well, I don't think you'll need it for awhile so it's probably premature to discuss it in any case, but the only "rite of passage" we really have is simply the process of getting to know one another and seeing that the "commit bit" is merited. That just takes a little time. I'll be following this whole sub-project with some interest, myself! Jordan From owner-freebsd-hackers Thu Dec 11 04:44:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA09314 for hackers-outgoing; Thu, 11 Dec 1997 04:44:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA09308 for ; Thu, 11 Dec 1997 04:44:21 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id HAA03778; Thu, 11 Dec 1997 07:44:13 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712111244.HAA03778@dyson.iquest.net> Subject: Re: This IS relevant, you'll realize why later. In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at "Dec 11, 97 00:41:09 am" To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Thu, 11 Dec 1997 07:44:13 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J. Weatherbee - Senior Systems Architect said: > > > Does anyone have any numbers for the sum total amount of information > existing in the universe? I would guess the appropriate way to tablulate > this would be to take the total ammount of matter in the form of subatomic > particles, and energy is photons and account for their position in three > coordinates and velocity vector. I'm certainly no physicist, but from > what I've read there are *NO* numbers for the ammount of matter in the > universe just percentage approximations. My guess is that you could > account for > this all in less than 2^1000 bits = 10^300, what this essentially means to > me is that it would be impractical to build a machine with a word size > expressed with more that 1024 bits (the expression of the word size, not > the wordsize itself). > I don't think that is big enough. :-). -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Thu Dec 11 05:02:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA10226 for hackers-outgoing; Thu, 11 Dec 1997 05:02:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA10220 for ; Thu, 11 Dec 1997 05:02:00 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199712111256.HAA17281@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Thu, 11 Dec 1997 08:00:41 -0500 (EST) From: Jamie Bowden To: Jason Evans cc: Stefan Molnar , Chuck Robey , freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Jason Evans wrote: > On Wed, 10 Dec 1997, Stefan Molnar wrote: > > Oh, I am volenteering help for testing the port for the sun4c, I can > > not give up my LX yet. > > Great, I'll take you up on that offer at the appropriate time. > > Thanks, > Jason I have two LXs, and a 2+ that I would love to run freebsd on. -- Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) From owner-freebsd-hackers Thu Dec 11 05:04:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA10389 for hackers-outgoing; Thu, 11 Dec 1997 05:04:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA10348 for ; Thu, 11 Dec 1997 05:03:54 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199712111258.HAA17286@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Thu, 11 Dec 1997 08:02:57 -0500 (EST) From: Jamie Bowden To: spork cc: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, spork wrote: > > On Wed, 10 Dec 1997, Chuck Robey wrote: > > > I would also be a little curious about the availability of sparc hardware > > for hobbyist folk. Few of us can afford $10K servers, but what other kind > > How's $750 for an IPX w/17" B&W monitor, 32MB, 2G disk sound? > > The Sparc 5's aren't that bad either... > > Charles Sprickman > spork@super-g.com That's pricey for an IPX, especially mono. You can buy new SS5 175mhz machines for around 4k. Not much more than a new PII based PC. I would rather have the Sun personally. -- Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) From owner-freebsd-hackers Thu Dec 11 06:04:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA14300 for hackers-outgoing; Thu, 11 Dec 1997 06:04:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA14238 for ; Thu, 11 Dec 1997 06:04:10 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712111404.GAA14238@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA297689007; Fri, 12 Dec 1997 01:03:27 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: jamie@itribe.net (Jamie Bowden) Date: Fri, 12 Dec 1997 01:03:26 +1100 (EDT) Cc: spork@super-g.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712111258.HAA17286@gatekeeper.itribe.net> from "Jamie Bowden" at Dec 11, 97 08:02:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Jamie Bowden, sie said: > > On Wed, 10 Dec 1997, spork wrote: > > > > > On Wed, 10 Dec 1997, Chuck Robey wrote: > > > > > I would also be a little curious about the availability of sparc hardware > > > for hobbyist folk. Few of us can afford $10K servers, but what other kind > > > > How's $750 for an IPX w/17" B&W monitor, 32MB, 2G disk sound? > > > > The Sparc 5's aren't that bad either... > > > > Charles Sprickman > > spork@super-g.com > > That's pricey for an IPX, especially mono. You can buy new SS5 175mhz > machines for around 4k. Not much more than a new PII based PC. I would > rather have the Sun personally. I assume you mean the SS5-TurboSPARC with the 170MHz CPU ? SunOS Release 5.5.1 Version Generic_103640-08 [UNIX(R) System V Release 4.0] Copyright (c) 1983-1996, Sun Microsystems, Inc. vac: enabled in writeback mode cpu0: FMI,MB86907 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) esp0: type 3 (FAS100/100A) speed 40MHz esp0: sd3,0 tgt 3 lun 0: Synchronous(10.0MB/sec) Clean CanReconnect Non-removable Disk: IBM DCAS32160SUN2.1G S60B mmmm, they make a very nice box :-) Darren From owner-freebsd-hackers Thu Dec 11 07:05:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA18258 for hackers-outgoing; Thu, 11 Dec 1997 07:05:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA18246 for ; Thu, 11 Dec 1997 07:05:47 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id JAA16491; Thu, 11 Dec 1997 09:05:42 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id JAA01917; Thu, 11 Dec 1997 09:05:11 -0600 Message-ID: <19971211090510.50776@right.PCS> Date: Thu, 11 Dec 1997 09:05:10 -0600 From: Jonathan Lemon To: "John S. Dyson" Cc: "J. Weatherbee - Senior Systems Architect" , hackers@FreeBSD.ORG Subject: Re: This IS relevant, you'll realize why later. References: <199712111244.HAA03778@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199712111244.HAA03778@dyson.iquest.net>; from John S. Dyson on Dec 12, 1997 at 07:44:13AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Dec 12, 1997 at 07:44:13AM -0500, John S. Dyson wrote: > J. Weatherbee - Senior Systems Architect said: > > > > Does anyone have any numbers for the sum total amount of information > > existing in the universe? I would guess the appropriate way to tablulate > > this would be to take the total ammount of matter in the form of subatomic > > particles, and energy is photons and account for their position in three > > coordinates and velocity vector. I'm certainly no physicist, but from > > what I've read there are *NO* numbers for the ammount of matter in the > > universe just percentage approximations. My guess is that you could > > account for > > this all in less than 2^1000 bits = 10^300, what this essentially means to > > me is that it would be impractical to build a machine with a word size > > expressed with more that 1024 bits (the expression of the word size, not > > the wordsize itself). > > > I don't think that is big enough. :-). Hmm. One of my professors was claiming that with 128 bits, you would have an address space of 2^128, which would be large enough that you could do away with virtual memory altogether. Just give each piece of data it's own unique address, (ala Multics) and then never relocate it for the lifetime of the system. She pointed out that even the human genome database project is smaller than this. Somehow, I don't quite buy the argument. -- Jonathan From owner-freebsd-hackers Thu Dec 11 07:17:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA19013 for hackers-outgoing; Thu, 11 Dec 1997 07:17:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA18996 for ; Thu, 11 Dec 1997 07:16:32 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199712111512.KAA18127@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Date: Thu, 11 Dec 1997 10:16:23 -0500 (EST) From: Jamie Bowden To: Darren Reed cc: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: <199712111403.JAA11401@marsellus.itribe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, Darren Reed wrote: > > That's pricey for an IPX, especially mono. You can buy new SS5 175mhz > > machines for around 4k. Not much more than a new PII based PC. I would > > rather have the Sun personally. > > I assume you mean the SS5-TurboSPARC with the 170MHz CPU ? > > SunOS Release 5.5.1 Version Generic_103640-08 [UNIX(R) System V Release 4.0] > Copyright (c) 1983-1996, Sun Microsystems, Inc. > vac: enabled in writeback mode > cpu0: FMI,MB86907 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) > > esp0: type 3 (FAS100/100A) speed 40MHz > esp0: sd3,0 tgt 3 lun 0: > Synchronous(10.0MB/sec) Clean CanReconnect > Non-removable Disk: IBM DCAS32160SUN2.1G S60B > > mmmm, they make a very nice box :-) > > Darren > Yep, that's the very one. The MicroSparc II's are nice chips too, but I don't think Sun is still shipping them. -- Jamie Bowden Systems Administrator, iTRiBE.net If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) From owner-freebsd-hackers Thu Dec 11 07:32:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20168 for hackers-outgoing; Thu, 11 Dec 1997 07:32:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20158 for ; Thu, 11 Dec 1997 07:32:16 -0800 (PST) (envelope-from ian@nmsu.edu) Received: from NMSU.Edu by bubba.NMSU.Edu (8.8.7/NMSU) id IAA24472; Thu, 11 Dec 1997 08:28:43 -0700 (MST) Received: from wilma by NMSU.Edu (8.8.4/NMSU-1.18) id IAA21124; Thu, 11 Dec 1997 08:29:55 -0700 (MST) Received: from nmsu.edu by wilma (SMI-8.6/NMSU) id IAA04777; Thu, 11 Dec 1997 08:29:50 -0700 Message-ID: <34900741.34CA72EE@nmsu.edu> Date: Thu, 11 Dec 1997 08:31:13 -0700 From: Ian Logan Organization: Computing and Networking X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4m) MIME-Version: 1.0 To: Jason Evans CC: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jason Evans wrote: > > On Wed, 10 Dec 1997, Chuck Robey wrote: > As for supporting older hardware, I'll do my best to make it possible, but > I can only test on so many machines before it becomes impractical. > Pre-Ultra machines are becoming more and more scarce at work. I'll have > to try to hold onto my SPARC-10... The fact that Sun is supporting this is terrific news. I've been wanting to see this happen for a long time and will do whatever I can to help :) I have access to several SS4's,5's and 10's here at my work so we shouldn't have any problems testing on older 4m type machines. I can also get access to some older IPC's and other 4c style boxes if need be. Ian -- Ian Logan Computing & Networking New Mexico State University Email: ian@nmsu.edu Phone: 505-646-6034 Fax: 505-646-5278 From owner-freebsd-hackers Thu Dec 11 07:42:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA21016 for hackers-outgoing; Thu, 11 Dec 1997 07:42:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20999 for ; Thu, 11 Dec 1997 07:42:50 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712111542.HAA20999@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA005794951; Fri, 12 Dec 1997 02:42:31 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: jamie@itribe.net (Jamie Bowden) Date: Fri, 12 Dec 1997 02:42:30 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org In-Reply-To: <199712111512.KAA18127@gatekeeper.itribe.net> from "Jamie Bowden" at Dec 11, 97 10:16:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Jamie Bowden, sie said: > > Yep, that's the very one. The MicroSparc II's are nice chips too, but I > don't think Sun is still shipping them. Sure are! Well, they're still listed on the pruducts web pages at www.sun.com! Darren From owner-freebsd-hackers Thu Dec 11 08:42:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24756 for hackers-outgoing; Thu, 11 Dec 1997 08:42:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mother.sneaker.net.au (akm@mother.sneaker.net.au [203.30.3.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24727 for ; Thu, 11 Dec 1997 08:42:25 -0800 (PST) (envelope-from akm@mother.sneaker.net.au) Received: (from akm@localhost) by mother.sneaker.net.au (8.8.5/8.8.5) id DAA01409; Fri, 12 Dec 1997 03:45:47 +1100 (EST) From: Andrew Kenneth Milton Message-Id: <199712111645.DAA01409@mother.sneaker.net.au> Subject: Re: This IS relevant, you'll realize why later. To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 12 Dec 1997 03:45:46 +1100 (EST) Cc: toor@dyson.iquest.net, jamil@acroal.com, hackers@FreeBSD.ORG In-Reply-To: <19971211090510.50776@right.PCS> from "Jonathan Lemon" at Dec 11, 97 09:05:10 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk +-----[ Jonathan Lemon ]------------------------------ | | Hmm. One of my professors was claiming that with 128 bits, you would have | an address space of 2^128, which would be large enough that you could do | away with virtual memory altogether. ... | Somehow, I don't quite buy the argument. Perhaps because the amount of bloat in software grows exponentially until it consumes all available resources. Or maybe you've just used Microsloth products too long. -- ,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411 / \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233 \_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233 v NSW 2137 | Low cost Internet Solutions | From owner-freebsd-hackers Thu Dec 11 10:12:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01577 for hackers-outgoing; Thu, 11 Dec 1997 10:12:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01567 for ; Thu, 11 Dec 1997 10:12:40 -0800 (PST) (envelope-from bartol@salk.edu) Received: from dale.salk.edu (dale [198.202.70.112]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id KAA12926; Thu, 11 Dec 1997 10:12:12 -0800 (PST) Date: Thu, 11 Dec 1997 10:12:12 -0800 (PST) From: Tom Bartol To: Jonathan Lemon cc: "John S. Dyson" , "J. Weatherbee - Senior Systems Architect" , hackers@FreeBSD.ORG Subject: Re: This IS relevant, you'll realize why later. In-Reply-To: <19971211090510.50776@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Jonathan Lemon wrote: > Hmm. One of my professors was claiming that with 128 bits, you would have > an address space of 2^128, which would be large enough that you could do > away with virtual memory altogether. > > Just give each piece of data it's own unique address, (ala Multics) and > then never relocate it for the lifetime of the system. She pointed out > that even the human genome database project is smaller than this. > > Somehow, I don't quite buy the argument. > -- > Jonathan > I'd buy it for $5.00 -- If the logic for each bit fit in a cube 0.14 picometer on a side you could fit 2^128 bits in 1 cubic meter. Never mind that 0.14 picometer is ~1/700th the diameter of a hydrogen atom and is only about 100 times bigger than an atomic nucleus! So if we could fit the logic for one bit in the space of a hydrogen atom, 2^128 bits would fill a cube ~700 meters on a side! Or if one bit fit in a cube 0.25 microns on a side then 2^128 bits would fill a cube ~1750 kilometers on a side (i.e. about 1/4th the volume of the Moon)!!!! Memories like this should be available in our life-time, cost about $5 each, and you'll need a whole bunch of them to run the latest version of MS Word available at the time. :-0 Tom From owner-freebsd-hackers Thu Dec 11 10:59:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05127 for hackers-outgoing; Thu, 11 Dec 1997 10:59:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA05095 for ; Thu, 11 Dec 1997 10:59:06 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xgDfd-0004av-00; Thu, 11 Dec 1997 10:49:13 -0800 Date: Thu, 11 Dec 1997 10:49:12 -0800 (PST) From: Tom To: Tom Bartol cc: hackers@freebsd.org Subject: Re: This IS relevant, you'll realize why later. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Tom Bartol wrote: > On Thu, 11 Dec 1997, Jonathan Lemon wrote: > > > Hmm. One of my professors was claiming that with 128 bits, you would have > > an address space of 2^128, which would be large enough that you could do > > away with virtual memory altogether. > > > > Just give each piece of data it's own unique address, (ala Multics) and > > then never relocate it for the lifetime of the system. She pointed out > > that even the human genome database project is smaller than this. > > > > Somehow, I don't quite buy the argument. > > -- > > Jonathan > > > > I'd buy it for $5.00 -- > If the logic for each bit fit in a cube 0.14 picometer on a side you could > fit 2^128 bits in 1 cubic meter. Never mind that 0.14 picometer is > ~1/700th the diameter of a hydrogen atom and is only about 100 times > bigger than an atomic nucleus! So if we could fit the logic for one bit > in the space of a hydrogen atom, 2^128 bits would fill a cube ~700 meters > on a side! Or if one bit fit in a cube 0.25 microns on a side then 2^128 > bits would fill a cube ~1750 kilometers on a side (i.e. about 1/4th the > volume of the Moon)!!!! I think you are missing the point. The point is about address space, not physical RAM. The mapping of address space to physical RAM is flexible. Many current CPUs have a 4GB address space, but most systems have less than 4GB of RAM. Tom From owner-freebsd-hackers Thu Dec 11 11:05:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05806 for hackers-outgoing; Thu, 11 Dec 1997 11:05:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05785 for ; Thu, 11 Dec 1997 11:05:35 -0800 (PST) (envelope-from erakupa@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id RAA08911 for ; Thu, 11 Dec 1997 17:44:54 +0100 (MET) Received: from kk662.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id RAA00918; Thu, 11 Dec 1997 17:44:49 +0100 From: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Received: by kk662.kk.etx.ericsson.se (SMI-8.6/client-1.6) id RAA00495; Thu, 11 Dec 1997 17:44:51 +0100 Date: Thu, 11 Dec 1997 17:44:51 +0100 Message-Id: <199712111644.RAA00495@kk662.kk.etx.ericsson.se> To: freebsd-hackers@FreeBSD.ORG Subject: panic: npxintr from nowhere X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What does this message mean, i.e. what's this npxintr thing? I have a Weighted Fair Queue packet scheduler (as LKM) and I sometimes (=randomly) see this message. Let say I have a code fragment printf("Position 1\n"); function(); ... and the function is int function() { printf("function\n"); ... } When this error occurs, I can see Position 1 npxintr: npxproc = 0x0, curproc = 0x0, npx_exists = 1 panic: npxintr from nowhere Why does it crash when/before executing the function? Memory leak somewhere? ``netstat -m'' does not show any leak during execution. Corrupted instruction pointer? Why does it "find" the first printf line? /Martti From owner-freebsd-hackers Thu Dec 11 11:42:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA08671 for hackers-outgoing; Thu, 11 Dec 1997 11:42:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bigpuppy.newell.arlington.va.us (bigpuppy.newell.arlington.va.us [209.31.147.242]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA08629 for ; Thu, 11 Dec 1997 11:41:58 -0800 (PST) (envelope-from mnewell@newell.arlington.va.us) Received: from localhost (mnewell@localhost) by bigpuppy.newell.arlington.va.us (8.8.5/8.8.5) with SMTP id OAA11730; Thu, 11 Dec 1997 14:42:00 -0500 (EST) Date: Thu, 11 Dec 1997 14:42:00 -0500 (EST) From: Mike Newell To: Jim Shankland cc: hackers@FreeBSD.ORG Subject: Re: Freebsd works on laptops? In-Reply-To: <199712100533.VAA04572@biggusdiskus.flyingfox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 9 Dec 1997, Jim Shankland wrote: jas> > but how to make amend for many damage cause me by linux jas> > company and malicious product which is very crappy to jas> > make laptop explode like that? jas> > jas> > if not linux company to sue, who? jas> > jas> > the freebsd would not make to explode the laptop no? jas> > jas> > i must works to warned other users how linux company jas> > makes to destroy computers and life of users. jas> > jas> > is anyone know how to sue linux company? jas> jas> I sense a leg being pulled here. Well, the original message started out "H3ll0", and note the return address... :-) But we got a good chuckle out of it!! :-)!! Much obliged, Mike +--------------------------------------+------------------------------------+ | Mike Newell | The opinions expressed herein | | Affiliation: | are mine. You can take them or | | Address: | leave them. Flames to /dev/null. | +--------------------------------------+------------------------------------+ | Mike@Newell.arlington.va.us | http://www.newell.arlington.va.us | +--------------------------------------+------------------------------------+ | "Peace. It's wonderful!" Father Divine. | +---------------------------------------------------------------------------+ From owner-freebsd-hackers Thu Dec 11 11:42:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA08773 for hackers-outgoing; Thu, 11 Dec 1997 11:42:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA08761 for ; Thu, 11 Dec 1997 11:42:39 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id MAA13588; Thu, 11 Dec 1997 12:42:35 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA07993; Thu, 11 Dec 1997 12:41:43 -0700 (MST) Date: Thu, 11 Dec 1997 12:41:43 -0700 (MST) From: Marc Slemko To: Charles Mott cc: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 10 Dec 1997, Charles Mott wrote: > > > I certainly wouldn't want anything like kernel configs or sysadmin > > > type stuff happening over a standard port like 80 or 8080 with > > > clear text passwords. If I could use SSL on some bizzaro > > > port number, that would be really worth having. :-) > > > > SSL is troublesome because the fascist US gov't patents basic math and is > > afraid that allowing people to export technology that the whole world > > already has will be a security risk. > > > > The sad truth is that the Internet would be far more secure if the US > > gov't wasn't so obtuse. > > My understanding is that only commercial web servers support SSL, which I > am guessing is the name for standard secure link used by MSIE and > Netscape. Is it possible that Apache supports SSL?? Apache doesn't support it in the base distribution because of export issues. http://www.apache-ssl.org/ for patches to make it work with SSLeay; this is legal to use in the US only for non-commercial purposes. It can not be done in FreeBSD even if you get around export issues because of RSA patents. SSL can be implemented without any other problems. Well, Netscape is claiming a patent on it but... The above talks about SSLv2; SSLv3 can be implemented without using any algorithms patented within the US. You still have horrible export issues though. > In a more perfect world, we would be using source code available browsers > that had evolved to use a free, ssh derivative encryption. Instead we let Huh? "ssh derivative encryption" makes no sense. From owner-freebsd-hackers Thu Dec 11 12:14:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11018 for hackers-outgoing; Thu, 11 Dec 1997 12:14:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11003 for ; Thu, 11 Dec 1997 12:14:23 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id SAA00694; Thu, 11 Dec 1997 18:13:19 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199712112013.SAA00694@gaia.coppe.ufrj.br> Subject: Re: Process scheduling: nice does not work ??? In-Reply-To: <199712100259.TAA02985@usr06.primenet.com> from Terry Lambert at "Dec 10, 97 02:59:11 am" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 11 Dec 1997 18:13:19 -0200 (EDT) Cc: chuckr@glue.umd.edu, tlambert@primenet.com, jonny@coppe.ufrj.br, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Terry Lambert) // > > Note: these are base priorities, which the system will adjust based on // ********************************************************************** // > > I/O vs. CPU utilization. // *********************** // // Look at the PRI values in the original posting. The NI values are // irrelevant, no mattery his intent. The NI values should have been used to determine the new PRI values, as have always been in Unix. Maybe the effect of NI differences in FreeBSD is smaller in FreeBSD than in Solaris and Linux ? Is this the right thing ? // If he wanted to "lock" priorities, he need to use rtprio. Otherwise, // the scheduler will drift them as it sees fit. I don't want to lock priorities. I want both processes to run, one with more time ticks than the other. Also, if I put a cpu-intensive process in rtprio, the whole system will starve on CPU. I'll never forget the mess I have done once in Slowlaris when I put the bytebench to run with realtime priority: Nothing else worked: keyboard, ping, etc. Fully frozen. :) Also, never start a rtprio'd file copy over paralell zip drives, as a friend of mine did. :) // IMO, Linux is implementing a "fairness" algorithm based on the NI value; Isn't it what NI for ? If not, what is it for ? // this is not traditional UNIX behaviour. It may favor interactive over // batch response. Note that he was running, effectively, batch processes; // this was my understanding the last time I looked at the Linux scheduler. // // I think Linux is wrong, FWIW. And Solaris also, by peeking at my measures on the first post. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Thu Dec 11 12:15:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11089 for hackers-outgoing; Thu, 11 Dec 1997 12:15:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA11067 for ; Thu, 11 Dec 1997 12:14:59 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (ras575.srv.net [205.180.127.75]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id NAA17394; Thu, 11 Dec 1997 13:14:54 -0700 Date: Thu, 11 Dec 1997 13:14:20 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Marc Slemko cc: hackers Subject: Re: FW: Why so many steps to build new kernel? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > In a more perfect world, we would be using source code available browsers > > that had evolved to use a free, ssh derivative encryption. Instead we let > > Huh? "ssh derivative encryption" makes no sense. > I guess I was thinking that ssh could be used to make a proxy connection to the web servers (the -L option) which would also be running sshd. Communications would be over the secure port 22, and packets would be locally shipped to port 80 on the web server. Does this make any sense? Charles Mott From owner-freebsd-hackers Thu Dec 11 12:46:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13470 for hackers-outgoing; Thu, 11 Dec 1997 12:46:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA13449 for ; Thu, 11 Dec 1997 12:45:56 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id VAA03424 for freebsd-hackers@FreeBSD.ORG; Thu, 11 Dec 1997 21:45:46 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id VAA03275; Thu, 11 Dec 1997 21:16:21 +0100 (CET) (envelope-from roberto) Message-ID: <19971211211621.19547@keltia.freenix.fr> Date: Thu, 11 Dec 1997 21:16:21 +0100 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: <26799.881843800@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <26799.881843800@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 04:36:40AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3883 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jordan K. Hubbard: > want to start with the compiler issues first then, eh? Peter? Soren? > John Polstra? You might wish to step forward and shake hands with > Jason here, guys, because he's probably going to be the principal > motive force behind your toolchain upgrade in -current! :-) Speaking of toolchain, it would be better IMO to use ELF for the SPARC port (which may speed up the X86 ELF too :-)). I don't think anyone wants to port our a.out hacks for shared libs to SPARC... :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #19: Tue Dec 9 20:17:10 CET 1997 From owner-freebsd-hackers Thu Dec 11 14:52:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21916 for hackers-outgoing; Thu, 11 Dec 1997 14:52:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp4.portal.net.au [202.12.71.104]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21900 for ; Thu, 11 Dec 1997 14:52:28 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id JAA01956; Fri, 12 Dec 1997 09:17:07 +1030 (CST) Message-Id: <199712112247.JAA01956@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere In-reply-to: Your message of "Thu, 11 Dec 1997 17:44:51 BST." <199712111644.RAA00495@kk662.kk.etx.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Dec 1997 09:17:07 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What does this message mean, i.e. what's this npxintr thing? It's the interrupt handler for interrupts from the FPU. > Position 1 > npxintr: npxproc = 0x0, curproc = 0x0, npx_exists = 1 > panic: npxintr from nowhere > > Why does it crash when/before executing the function? Memory leak > somewhere? ``netstat -m'' does not show any leak during execution. > > Corrupted instruction pointer? Why does it "find" the first > printf line? npxintr() is being called without a valid NPX interrupt status. Are you calling any functions indirectly? mike From owner-freebsd-hackers Thu Dec 11 15:48:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25194 for hackers-outgoing; Thu, 11 Dec 1997 15:48:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lily.ezo.net (root@lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25166 for ; Thu, 11 Dec 1997 15:48:30 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id SAA16914; Thu, 11 Dec 1997 18:48:09 -0500 (EST) Date: Thu, 11 Dec 1997 18:48:09 -0500 (EST) From: Jim Flowers To: Richard Wackerbarth cc: hackers@freebsd.org Subject: Re: Using CTM and the 2.2.5 CD's In-Reply-To: <199712102125.PAA20498@shrimp.dataplex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tried to do this with my 2.2.5 CD and was fine up to cvs-cur.3878.gz when FS freebsd01.gif,v failed with a permission denied error and the process stopped. freebsd01.gif,v permissions were r--r--r--. I assumed src.cur.3800xEmpty.gz (95358150!B) is not required and did not download it, right? Recovery for 3879 and later looks fairly straight-forward but how do I apply 3878 (ctm says it's already done). Can someone point me in the right direction. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Wed, 10 Dec 1997, Richard Wackerbarth wrote: > I am pleased to announce that the checkpoints taken in the CTM streams > back in late October have now been confirmed to work with the 2.2.5 > CD's. If you are interested in maintaining an up-to-date copy of the > cvs tree or any of the source trees, I strongly recommend that you > obtain this Release CD set to use as a starting point. From owner-freebsd-hackers Thu Dec 11 17:09:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00762 for hackers-outgoing; Thu, 11 Dec 1997 17:09:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.feral.com (mjacob@feral.mauswerks.net [204.152.96.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00747 for ; Thu, 11 Dec 1997 17:08:58 -0800 (PST) (envelope-from mjacob@ns.feral.com) Received: (from mjacob@localhost) by ns.feral.com (8.8.6/8.8.6) id RAA30858 for freebsd-hackers@freebsd.org; Thu, 11 Dec 1997 17:08:25 -0800 Date: Thu, 11 Dec 1997 17:08:25 -0800 From: Matthew Jacob Message-Id: <199712120108.RAA30858@ns.feral.com> To: freebsd-hackers@freebsd.org Subject: Announce && Call for Testers: NetWorker (Legato) client for FreeBSD Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ this is intended for those who already know what Legato's NetWorker backup sofware is ] I've just ported Legato's NetWorker client to FreeBSD 2.2.2- I'm looking for alpha testers (who already have NetWorker servers in their networks). See ftp.feral.com:~ftp/pub/networker/freebsd for more details or email mjacob@feral.com or networker-freebsd@feral.com. -matt From owner-freebsd-hackers Thu Dec 11 17:28:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01815 for hackers-outgoing; Thu, 11 Dec 1997 17:28:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dog.farm.org (gw-hssi-2.farm.org [209.66.103.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01808 for ; Thu, 11 Dec 1997 17:28:13 -0800 (PST) (envelope-from dog.farm.org!dk) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id RAA27193; Thu, 11 Dec 1997 17:31:17 -0800 (PST) Date: Thu, 11 Dec 1997 17:31:17 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199712120131.RAA27193@dog.farm.org> To: jgrosch@superior.mooseriver.com Cc: freebsd-hackers@freebsd.org Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19971210124021.52222@mooseriver.com> you wrote: > I have been looking around for used SPARC equipment recently. I have been > seeing SPARC 5 with a 1 or 2 gig drive, 64 meg of ram and no monitor going > for between $900.00 and $1500.00. I have seen SPARC 2, IPC, and IPX going > for in the $500.00 to $1000.00 range. This, of course, depends on how much > memory and disk the system has and how much the owner thinks it worth. Sun > monitors are _DAMED_ expensive. I have yet to see one for under $1500.00. I > will most likely end up running mine headless. I bought mine (19" color used) for ~$200. used sparcs (ss5, ss1, ipx, ...) usually sell under $1000 as well with everything, but you can buy disks and CD drives separately. -- The steady state of disks is full. -- Ken Thompson From owner-freebsd-hackers Thu Dec 11 17:31:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA01992 for hackers-outgoing; Thu, 11 Dec 1997 17:31:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA01975 for ; Thu, 11 Dec 1997 17:31:02 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id RAA25144; Thu, 11 Dec 1997 17:30:46 -0800 (PST) Message-ID: <19971211173046.63648@hydrogen.nike.efn.org> Date: Thu, 11 Dec 1997 17:30:46 -0800 From: John-Mark Gurney To: Mike Smith Cc: ETX-B-SL Martti Kuparinen , freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere References: <199712111644.RAA00495@kk662.kk.etx.ericsson.se> <199712112247.JAA01956@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712112247.JAA01956@word.smith.net.au>; from Mike Smith on Fri, Dec 12, 1997 at 09:17:07AM +1030 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Dec 12: > > What does this message mean, i.e. what's this npxintr thing? > > It's the interrupt handler for interrupts from the FPU. > > > Position 1 > > npxintr: npxproc = 0x0, curproc = 0x0, npx_exists = 1 > > panic: npxintr from nowhere > > > > Why does it crash when/before executing the function? Memory leak > > somewhere? ``netstat -m'' does not show any leak during execution. > > > > Corrupted instruction pointer? Why does it "find" the first > > printf line? > > npxintr() is being called without a valid NPX interrupt status. Are > you calling any functions indirectly? actually, now that someone else brought it up, any good way to call floating point routins from the kernel? if you do, and don't have any processes that have used floating point, will will get the above mentioned panic... quite easy to reproduce... boot kernel, run floating point code in kernel, see it panic... now boot same kernel, run systat, run floating point code in kernel, see it run normally.. :) this was from a current kernel as of a few weeks ago... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Thu Dec 11 17:59:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04188 for hackers-outgoing; Thu, 11 Dec 1997 17:59:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04181 for ; Thu, 11 Dec 1997 17:59:48 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id RAA25268; Thu, 11 Dec 1997 17:59:39 -0800 (PST) Message-ID: <19971211175938.41550@hydrogen.nike.efn.org> Date: Thu, 11 Dec 1997 17:59:38 -0800 From: John-Mark Gurney To: Mike Smith Cc: ETX-B-SL Martti Kuparinen , freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere References: <19971211173046.63648@hydrogen.nike.efn.org> <199712120143.MAA00288@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712120143.MAA00288@word.smith.net.au>; from Mike Smith on Fri, Dec 12, 1997 at 12:13:18PM +1030 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Dec 12: > > actually, now that someone else brought it up, any good way to call > > floating point routins from the kernel? if you do, and don't have > > any processes that have used floating point, will will get the above > > mentioned panic... > > Hmm, interesting. I would guess that this means that you shouldn't run > floating point code in the kernel. :) yeh... well, I was going to improve the fade screen saver so that it wouldn't turn everything to a dull grey... also, if I remeber correctly, there are only two places in the kernel that use floating point... one of them is in the Bt848 driver... > Think about it for a moment; to whom would you deliver a floating-point > exception? > > It probably fails because the FPU initialisation is lazy, and if you > haven't initialised it before you use it, you'll die screaming. is there a routine for the kernel code to use to initalize it? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Thu Dec 11 18:02:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04384 for hackers-outgoing; Thu, 11 Dec 1997 18:02:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from per.plex.nl (SPARCserver.plex.nl [193.67.154.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA04374 for ; Thu, 11 Dec 1997 18:02:04 -0800 (PST) (envelope-from jbackus@plex.nl) Received: from jos.mp-c.com (isdn-114.plex.nl [194.229.212.36]) by per.plex.nl (SMI-8.6/SMI-SVR4) id CAA28341; Fri, 12 Dec 1997 02:57:16 +0100 X-Disclaimer: Plex is a public access Internet provider Received: (qmail 3441 invoked by uid 1000); 12 Dec 1997 01:58:21 -0000 Message-ID: <19971212015821.3440.qmail@jos.mp-c.com> To: freebsd-hackers@freebsd.org Reply-To: jbackus@plex.nl Subject: /sys/pci/pci.c: NOTYET finished? Date: Fri, 12 Dec 1997 02:58:21 +0100 From: Jos Backus Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On my -current system: jos:/sys/pci# pciconf -l pciconf: ioctl(PCIOCGETCONF): Operation not supported by device probably because pci.c,v 1.80 contains: switch(cmd) { case PCIOCGETCONF: #ifdef NOTYET static struct pci_conf *pci_dev_list; ... Hm... Groetjes, -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ jbackus@plex.nl _/_/ _/_/_/ #include From owner-freebsd-hackers Thu Dec 11 18:03:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04536 for hackers-outgoing; Thu, 11 Dec 1997 18:03:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04509 for ; Thu, 11 Dec 1997 18:03:17 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00288; Fri, 12 Dec 1997 12:13:18 +1030 (CST) Message-Id: <199712120143.MAA00288@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: Mike Smith , ETX-B-SL Martti Kuparinen , freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere In-reply-to: Your message of "Thu, 11 Dec 1997 17:30:46 -0800." <19971211173046.63648@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Dec 1997 12:13:18 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > actually, now that someone else brought it up, any good way to call > floating point routins from the kernel? if you do, and don't have > any processes that have used floating point, will will get the above > mentioned panic... Hmm, interesting. I would guess that this means that you shouldn't run floating point code in the kernel. Think about it for a moment; to whom would you deliver a floating-point exception? It probably fails because the FPU initialisation is lazy, and if you haven't initialised it before you use it, you'll die screaming. mike From owner-freebsd-hackers Thu Dec 11 18:04:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04658 for hackers-outgoing; Thu, 11 Dec 1997 18:04:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04649 for ; Thu, 11 Dec 1997 18:04:28 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA06237; Thu, 11 Dec 1997 19:04:12 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd006125; Thu Dec 11 19:03:59 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA05412; Thu, 11 Dec 1997 19:03:40 -0700 (MST) From: Terry Lambert Message-Id: <199712120203.TAA05412@usr02.primenet.com> Subject: Re: OS Ports (The Terry Lambert Challenge, Part II) To: jamil@acroal.com (J. Weatherbee - Senior Systems Architect) Date: Fri, 12 Dec 1997 02:03:40 +0000 (GMT) Cc: tlambert@primenet.com, hackers@freebsd.org In-Reply-To: from "J. Weatherbee - Senior Systems Architect" at Dec 10, 97 04:54:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ok, terry I'll make you a deal. Show me some processor that has virtual > memory constructs that are not ridiculous (like intels), and if you write > the code for real<->virtual hardware (i.e. console, disk, etc.) > I will code the virtual instruction set. A motorola product would be > prefferred because getting detailed manuals from them is painless (and > usually free). I'm more interested in running Sun3, HP345 (I have one), and Amiga SunOS/HPUX/SVR4/NetBSD/OpenBSD binaries under x86 FreeBSD. There is currently someone working on being able to run MIPS R3000 MIPS OS and NetBSD binaries on FreeBSD. I think it's much less interesting to try and build a virtual machine in it's entirety. The current approach being taken is to emulate the processor to run native instructions, and convert the traps into native system calls in and out. For example, MIPS code to do a statically linked: main() { write( 1, "hello world!\n", 13); } is built on a NetBSD/MIPS box, and the code is mapped into a virtual address data space in a SPIM binary. When the SPIM binary is asked to execute the trap call after pushing the stack, it enulates the trap call by converting it into a NetBSD native system call (this saves converting the call arguments in user space in each emulator, vs. in kernel space using the existing NetBSD execution class glue code). This is what I was talking about. The "deal" you have is interesting, but it's tantamount to you wanting to write the 68k processor from Executor while I write all of the Apple Mac hardware and Quickdraw stuff (8-)), so it's not a deal I'm willing to commit to. I will work with you if you want to help me make HP345 binaries from NetBSD run on x86 FreeBSD. The HP345 binaries for NetBSD are the same ones for the Amiga, Sun, and Macintosh NetBSD, so this would cover a*lot* of binary compatability. Besides, they are easy for me to come by. 8-). I'd be willing to help you with Sun3/SunOS, HP345/HPUX, and Mac2/AUX binary emulation as well, but I have less ability to compile for any but the HP345, since that's the only one I own (I have an Amiga, but it only has a 68010 and an old SVR3.2 port without PMMU; it can run NCR Tower 16 binaries, but that's not a growth industry). So we probably are not talking about solving the same problems. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Dec 11 18:16:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05474 for hackers-outgoing; Thu, 11 Dec 1997 18:16:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA05457 for ; Thu, 11 Dec 1997 18:16:13 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00359; Fri, 12 Dec 1997 12:40:41 +1030 (CST) Message-Id: <199712120210.MAA00359@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: Mike Smith , ETX-B-SL Martti Kuparinen , freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere In-reply-to: Your message of "Thu, 11 Dec 1997 17:59:38 -0800." <19971211175938.41550@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Dec 1997 12:40:41 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hmm, interesting. I would guess that this means that you shouldn't run > > floating point code in the kernel. > > :) yeh... well, I was going to improve the fade screen saver so that > it wouldn't turn everything to a dull grey... Fixed point. Faster too. > also, if I remeber correctly, there are only two places in the kernel > that use floating point... one of them is in the Bt848 driver... I just looked; where? > > It probably fails because the FPU initialisation is lazy, and if you > > haven't initialised it before you use it, you'll die screaming. > > is there a routine for the kernel code to use to initalize it? You'd have to ask Bruce about that. mike From owner-freebsd-hackers Thu Dec 11 18:33:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06546 for hackers-outgoing; Thu, 11 Dec 1997 18:33:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06536 for ; Thu, 11 Dec 1997 18:33:10 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA25479; Thu, 11 Dec 1997 18:33:02 -0800 (PST) Message-ID: <19971211183302.28799@hydrogen.nike.efn.org> Date: Thu, 11 Dec 1997 18:33:02 -0800 From: John-Mark Gurney To: Mike Smith Cc: ETX-B-SL Martti Kuparinen , freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere References: <19971211175938.41550@hydrogen.nike.efn.org> <199712120210.MAA00359@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712120210.MAA00359@word.smith.net.au>; from Mike Smith on Fri, Dec 12, 1997 at 12:40:41PM +1030 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Dec 12: > > > Hmm, interesting. I would guess that this means that you shouldn't run > > > floating point code in the kernel. > > > > :) yeh... well, I was going to improve the fade screen saver so that > > it wouldn't turn everything to a dull grey... > > Fixed point. Faster too. so we have a fixpoint lib in the kernel now?? :) I could rewrite it to used fix point, but it's that much extra code... would a simple fixpoint lib be useful in the kernel? > > also, if I remeber correctly, there are only two places in the kernel > > that use floating point... one of them is in the Bt848 driver... > > I just looked; where? I looked too, but couldn't find it... must of been an older version of the driver... > > > It probably fails because the FPU initialisation is lazy, and if you > > > haven't initialised it before you use it, you'll die screaming. > > > > is there a routine for the kernel code to use to initalize it? > > You'd have to ask Bruce about that. ok... will do.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Thu Dec 11 18:43:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07200 for hackers-outgoing; Thu, 11 Dec 1997 18:43:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07195 for ; Thu, 11 Dec 1997 18:42:57 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA17185; Thu, 11 Dec 1997 19:42:16 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd017158; Thu Dec 11 19:42:13 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA07290; Thu, 11 Dec 1997 19:42:08 -0700 (MST) From: Terry Lambert Message-Id: <199712120242.TAA07290@usr02.primenet.com> Subject: Re: Why so many steps to build new kernel? To: j_mini@efn.org Date: Fri, 12 Dec 1997 02:42:07 +0000 (GMT) Cc: jkh@time.cdrom.com, ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971211021856.61158@micron.mini.net> from "Jonathan Mini" at Dec 11, 97 02:18:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 3) C++ does not implement data hiding. Sure, you have opaque structs, > but you cannoy make an opaque class. That is, you cannot have a class > defined where you know how to interface with the functions, but not > the details of the internal data. Because you have to define the > private data within the same scope as the public interface, private > datatypes aren't possible. This is incorrect. global.h: #define interface struct /* no virtual destructor needed*/ myOpaqueClass.h: interface myOpaqueClass { virtual int function1( int arg1, char *arg2) = 0; virtual int function2( char *arg1) = 0; }; extern myOpaqueClass *createOpaqueClassObject(); myImplementationClass.cc #include "global.h" #include "myOpaqueClass.h" class myImplementationClass : public myOpaqueClass { private: /* * Private data not defined in the scope of the * public interface. */ int somedata; public: myImplementationClass(); /* constructor*/ ~myImplementationClass(); /* destructor*/ int function1( int arg1, char *arg2); int function2( char *arg1); }; /* * Public interface; use shared object technology to select * between implementation class instances for a given opaque * class... */ myOpaqueClass * createOpaqueClassObject() { myImplementationClass *instance; intstance = new myImplementationClass; return( (myOpaqueClass *)instance; } /* * constructor */ myImplementationClass::myImplementationClass() { } /* * destructor */ myImplementationClass::myImplementationClass() { } /* * implementation class specific implementation of pure * virtual base class interface "function1"... */ int myImplementationClass::function1( int arg1, char *arg2)) { ... } /* * implementation class specific implementation of pure * virtual base class interface "function2"... */ int myImplementationClass::function2( char *arg1) { ... } Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Dec 11 18:53:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA07972 for hackers-outgoing; Thu, 11 Dec 1997 18:53:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA07960 for ; Thu, 11 Dec 1997 18:53:19 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA24699; Thu, 11 Dec 1997 19:59:36 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd024609; Thu Dec 11 19:59:14 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA07810; Thu, 11 Dec 1997 19:52:18 -0700 (MST) From: Terry Lambert Message-Id: <199712120252.TAA07810@usr02.primenet.com> Subject: Re: Process scheduling: nice does not work ??? To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Fri, 12 Dec 1997 02:52:18 +0000 (GMT) Cc: tlambert@primenet.com, chuckr@glue.umd.edu, jonny@coppe.ufrj.br, freebsd-hackers@freebsd.org In-Reply-To: <199712112013.SAA00694@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 11, 97 06:13:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > // If he wanted to "lock" priorities, he need to use rtprio. Otherwise, > // the scheduler will drift them as it sees fit. > > I don't want to lock priorities. I want both processes to run, one > with more time ticks than the other. The way you do this in Solaris/SVR4 is to used "fixed" as your scheduling class when you prioctl the thing... > // IMO, Linux is implementing a "fairness" algorithm based on the NI value; > > Isn't it what NI for ? If not, what is it for ? It's for setting your priority to less than the default of 0 so that you don't bother interactive users with your compute intensive tasks (in fact, there used to be code in the BSD scheduler to whomp your priority way down when it determined that your process was non-interactive; I have no idea when it went away, but it did). > // I think Linux is wrong, FWIW. > > And Solaris also, by peeking at my measures on the first post. I didn't gather that from the Solaris numbers. The thing is that the process percentages are instantaneous. The only thing that means anything, really, is the PRI at the next time the thing is in the ready-to-run-queue with other processes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Dec 11 19:55:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA11996 for hackers-outgoing; Thu, 11 Dec 1997 19:55:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11986 for ; Thu, 11 Dec 1997 19:55:27 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id TAA18725; Thu, 11 Dec 1997 19:54:48 -0800 (PST) Message-ID: <19971211195447.15294@micron.mini.net> Date: Thu, 11 Dec 1997 19:54:47 -0800 From: Jonathan Mini To: Terry Lambert Cc: j_mini@efn.org, jkh@time.cdrom.com, ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971211021856.61158@micron.mini.net> <199712120242.TAA07290@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199712120242.TAA07290@usr02.primenet.com>; from Terry Lambert on Fri, Dec 12, 1997 at 02:42:07AM +0000 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > 3) C++ does not implement data hiding. Sure, you have opaque structs, > > but you cannoy make an opaque class. That is, you cannot have a class > > defined where you know how to interface with the functions, but not > > the details of the internal data. Because you have to define the > > private data within the same scope as the public interface, private > > datatypes aren't possible. > > This is incorrect. > Terry's counter-example works, but you can't create an object of OpaqueClass and have it work, you _HAVE_ to call a function to create an object of myImplementationClass that returns a pointer to it as OpaqueClass. This is not different than in C. The same implementation could be implemented in C via type-casting or opaque structs. Moot point. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Thu Dec 11 19:57:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA12123 for hackers-outgoing; Thu, 11 Dec 1997 19:57:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA12109 for ; Thu, 11 Dec 1997 19:57:14 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199712120357.TAA12109@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA116329008; Fri, 12 Dec 1997 14:56:49 +1100 From: Darren Reed Subject: Re: Beginning SPARC port To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 12 Dec 1997 14:56:48 +1100 (EDT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971211211621.19547@keltia.freenix.fr> from "Ollivier Robert" at Dec 11, 97 09:16:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Ollivier Robert, sie said: > > According to Jordan K. Hubbard: > > want to start with the compiler issues first then, eh? Peter? Soren? > > John Polstra? You might wish to step forward and shake hands with > > Jason here, guys, because he's probably going to be the principal > > motive force behind your toolchain upgrade in -current! :-) > > Speaking of toolchain, it would be better IMO to use ELF for the SPARC port > (which may speed up the X86 ELF too :-)). > > I don't think anyone wants to port our a.out hacks for shared libs to > SPARC... :-) But what about SunOS 4 compatibility ? From owner-freebsd-hackers Thu Dec 11 20:01:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA13027 for hackers-outgoing; Thu, 11 Dec 1997 20:01:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA12880 for ; Thu, 11 Dec 1997 20:00:56 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id WAA01862; Thu, 11 Dec 1997 22:55:45 -0500 (EST) (envelope-from toor) Message-Id: <199712120355.WAA01862@dyson.iquest.net> Subject: Re: Process scheduling: nice does not work ??? In-Reply-To: <199712120252.TAA07810@usr02.primenet.com> from Terry Lambert at "Dec 12, 97 02:52:18 am" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 11 Dec 1997 22:55:45 -0500 (EST) Cc: jonny@coppe.ufrj.br, tlambert@primenet.com, chuckr@glue.umd.edu, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > It's for setting your priority to less than the default of 0 so that you > don't bother interactive users with your compute intensive tasks (in > fact, there used to be code in the BSD scheduler to whomp your priority > way down when it determined that your process was non-interactive; I > have no idea when it went away, but it did). > That "whomp" code was explicitly removed. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Thu Dec 11 21:20:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18857 for hackers-outgoing; Thu, 11 Dec 1997 21:20:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18845 for ; Thu, 11 Dec 1997 21:20:06 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-46.cetlink.net [209.54.58.46]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id XAA29951 for ; Thu, 11 Dec 1997 23:47:31 -0500 (EST) From: jak@cetlink.net (John Kelly) To: hackers@FreeBSD.org Subject: (fwd) Re: F00F bug *fixed* in 2.0.x kernels Date: Fri, 12 Dec 1997 05:48:30 GMT Message-ID: <3491cfe3.6774010@mail.cetlink.net> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id VAA18849 Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On 8 Dec 1997 23:11:24 GMT, in comp.os.linux.development.system torvalds@transmeta.com (Linus Torvalds) wrote: In article , Albert D. Cahalan wrote: >Jerry Hicks writes: > >> Wrong again Albert... > >Nope, you are wrong. This method is a _third_ solution. > >>>> My ``fix'' is to have the IDT descriptor reference a segemnt >>>> which has a length of 0. This has the effect of mapping SIGILL >>>> into SIGBUS, so that the `cmpxchg8' crash now generates a Bus >>>> error. (I didn't bother returning the correct signal; it can >>>> probably be added if it is important) This is indeed the "FreeBSD fix". The so-called "fix" doesn't work (it appears to, for simple exploits, but it doesn't), and I _told_ some FreeBSD people so: I even sent people a test-program that will still lock up a FreeBSD system with the "fix". If they are indeed still using that fix, they are a sorry lot of incompetent idiots. Linus From owner-freebsd-hackers Thu Dec 11 22:10:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA22125 for hackers-outgoing; Thu, 11 Dec 1997 22:10:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA22114 for ; Thu, 11 Dec 1997 22:10:46 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA01136; Thu, 11 Dec 1997 22:08:42 -0800 (PST) Message-Id: <199712120608.WAA01136@implode.root.com> To: jak@cetlink.net (John Kelly) cc: hackers@FreeBSD.ORG, torvalds@transmeta.com (Linus Torvalds) Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-reply-to: Your message of "Fri, 12 Dec 1997 05:48:30 GMT." <3491cfe3.6774010@mail.cetlink.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Dec 1997 22:08:42 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On 8 Dec 1997 23:11:24 GMT, in comp.os.linux.development.system >torvalds@transmeta.com (Linus Torvalds) wrote: ... >>>>> My ``fix'' is to have the IDT descriptor reference a segemnt >>>>> which has a length of 0. This has the effect of mapping SIGILL >>>>> into SIGBUS, so that the `cmpxchg8' crash now generates a Bus >>>>> error. (I didn't bother returning the correct signal; it can >>>>> probably be added if it is important) > >This is indeed the "FreeBSD fix". > >The so-called "fix" doesn't work (it appears to, for simple exploits, >but it doesn't), and I _told_ some FreeBSD people so: I even sent >people a test-program that will still lock up a FreeBSD system with >the "fix". > >If they are indeed still using that fix, they are a sorry lot of >incompetent idiots. The fix that Linus is refering to is one of several that were evaluated and rejected. The fix that we finally adopted in FreeBSD is the one that involves making the IDT to read-only and catching the write fault that occurs. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Dec 11 23:04:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25614 for hackers-outgoing; Thu, 11 Dec 1997 23:04:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA25598 for ; Thu, 11 Dec 1997 23:04:07 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA14245; Thu, 11 Dec 1997 23:04:00 -0800 (PST) To: jak@cetlink.net (John Kelly) cc: hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-reply-to: Your message of "Fri, 12 Dec 1997 05:48:30 GMT." <3491cfe3.6774010@mail.cetlink.net> Date: Thu, 11 Dec 1997 23:04:00 -0800 Message-ID: <14241.881910240@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yeah, I think everyone's seen this Torvalds flame by now. The sad thing was, that was *not* the FreeBSD fix. It was a fix that had been floated earlier by someone on the mailing lists and was never committed to the tree - the eventual fix which made it in was the Intel fix. Intel, in fact, even commented on that first proposed fix even earlier than Linus did and told us why it wouldn't work. There was never any intention of using the fix that Linus cites, it was just one of many fixes under evaluation, and all he's done here is gone off half-cocked again with accompanying language which simply made the mistake far worse than it needed to be. People will often forgive one even the most blatant suppositions if one is polite about them. Make even a minor error with the tagline "(you fucking idiot!)" embeded, however, and you can count on being embroiled in flames for at least a month. I think Miss Manners may be on to something here. :-) Jordan From owner-freebsd-hackers Thu Dec 11 23:25:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA27166 for hackers-outgoing; Thu, 11 Dec 1997 23:25:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA27144 for ; Thu, 11 Dec 1997 23:25:34 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id IAA21249 for freebsd-hackers@FreeBSD.ORG; Fri, 12 Dec 1997 08:25:31 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id HAA01881; Fri, 12 Dec 1997 07:54:37 +0100 (CET) (envelope-from roberto) Message-ID: <19971212075437.35049@keltia.freenix.fr> Date: Fri, 12 Dec 1997 07:54:37 +0100 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: <19971211211621.19547@keltia.freenix.fr> <199712120356.EAA25673@frmug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712120356.EAA25673@frmug.org>; from Darren Reed on Fri, Dec 12, 1997 at 02:56:48PM +1100 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3883 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Darren Reed: > But what about SunOS 4 compatibility ? GNU as, even modern versions, are already able to generate SUN's a.out code and SunOS's shared libraries. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #19: Tue Dec 9 20:17:10 CET 1997 From owner-freebsd-hackers Fri Dec 12 00:02:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29868 for hackers-outgoing; Fri, 12 Dec 1997 00:02:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA29689 for ; Thu, 11 Dec 1997 23:59:40 -0800 (PST) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.7/8.8.5) id JAA21399 for freebsd-hackers@freebsd.org; Fri, 12 Dec 1997 09:58:51 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199712120758.JAA21399@oskar.nanoteq.co.za> Subject: Mail problem ? To: freebsd-hackers@freebsd.org Date: Fri, 12 Dec 1997 09:58:51 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ... For the past +/- 7 hours I haven't received any mail from any of the FreeBSD list I'm subscribed to ... I also mailed Majordomo and has as of yet not received any replies ... Now for the ever popular "HELP" :) Thanx From owner-freebsd-hackers Fri Dec 12 00:30:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02283 for hackers-outgoing; Fri, 12 Dec 1997 00:30:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dcn.soongsil.ac.kr ([203.253.2.104]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA02245 for ; Fri, 12 Dec 1997 00:29:53 -0800 (PST) (envelope-from skylee@dcn.soongsil.ac.kr) Received: from seer.soongsil.ac.kr ([203.253.3.88]) by dcn.soongsil.ac.kr (8.6.9H1/8.9.11h) with SMTP id RAA26442 for ; Fri, 12 Dec 1997 17:33:47 +0900 Message-Id: <3.0.1.32.19971212173327.00798bd0@dcn.soongsil.ac.kr> X-Sender: skylee@dcn.soongsil.ac.kr (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 12 Dec 1997 17:33:27 +0900 To: freebsd-hackers@freebsd.org From: SangKyo LEE Subject: How to install.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello. My name is skylee. I'm a graduated student in soongsil univ , seoul , Korea. I have a question to you. I am testing rsvp using Connectix QuickCam under FreeBSD. My problem is that my freebsd dispaly only black screen.(using vic 2.8) If you know, pls tell me why doesn't dispaly well. thank you.... From owner-freebsd-hackers Fri Dec 12 00:45:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA03466 for hackers-outgoing; Fri, 12 Dec 1997 00:45:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA03450 for ; Fri, 12 Dec 1997 00:45:36 -0800 (PST) (envelope-from erakupa@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id JAA29861 for ; Fri, 12 Dec 1997 09:45:28 +0100 (MET) Received: from kk662.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id JAA08488; Fri, 12 Dec 1997 09:45:23 +0100 From: erakupa@kk.etx.ericsson.se (ETX-B-SL Martti Kuparinen) Received: by kk662.kk.etx.ericsson.se (SMI-8.6/client-1.6) id JAA00910; Fri, 12 Dec 1997 09:45:24 +0100 Date: Fri, 12 Dec 1997 09:45:24 +0100 Message-Id: <199712120845.JAA00910@kk662.kk.etx.ericsson.se> To: freebsd-hackers@freebsd.org Subject: Re: panic: npxintr from nowhere X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ok, so either I shouldn't use floats or I must initialize the FPU somehow. But why the crashes occur randomly, i.e. sometimes it takes several hours and sometimes only 10 seconds to crash the system? /Martti From owner-freebsd-hackers Fri Dec 12 02:51:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA10307 for hackers-outgoing; Fri, 12 Dec 1997 02:51:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA10296 for ; Fri, 12 Dec 1997 02:51:24 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id CAA00845; Fri, 12 Dec 1997 02:51:16 -0800 (PST) Message-ID: <19971212025116.40266@hydrogen.nike.efn.org> Date: Fri, 12 Dec 1997 02:51:16 -0800 From: John-Mark Gurney To: ETX-B-SL Martti Kuparinen Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: panic: npxintr from nowhere References: <199712120845.JAA00910@kk662.kk.etx.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712120845.JAA00910@kk662.kk.etx.ericsson.se>; from ETX-B-SL Martti Kuparinen on Fri, Dec 12, 1997 at 09:45:24AM +0100 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ETX-B-SL Martti Kuparinen scribbled this message on Dec 12: > Ok, so either I shouldn't use floats or I must initialize the FPU > somehow. > > But why the crashes occur randomly, i.e. sometimes it takes > several hours and sometimes only 10 seconds to crash the system? basicly it happens that the times it crashes there isn't a process that is using the floating point processor at the time... when the process isn't running, the npx is unitalized... sometime try this, boot machine, run floating point code, machine will crash (assuming single user boot or VERY little running on machine).. next run systat, and then run your code... no crash... now quit systat, and run your code again... crash... it just happens that it isn't being initalized at the time... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Fri Dec 12 03:50:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA13694 for hackers-outgoing; Fri, 12 Dec 1997 03:50:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA13686 for ; Fri, 12 Dec 1997 03:50:21 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id DAA30745; Fri, 12 Dec 1997 03:50:10 -0800 Date: Fri, 12 Dec 1997 03:50:09 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio Reply-To: Jason Evans To: "Jordan K. Hubbard" cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-Reply-To: <25493.881829472@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Jordan K. Hubbard wrote: > For the record, I doubt that adding support for the earlier SPARCs is > going to be as trivial as everyone expects, and I don't expect Jason > Evans' bosses to put too much effort into this either considering that > the already-sold hardware is not very important to their bottom > line. :) You're right. The Ultra is first and foremost in importance. As an onlooker, given a choice between one port or the other, I'd choose the Ultra port, because it will push the limits of what FreeBSD can do, whereas supporting older machines will simply make those machines useful for a while longer, which NetBSD apparently already does. > Remember that we *had* a SPARC port at one stage but it died > for lack of attention (I don't even think anyone even has the bits > around anymore), so if something's not done directly by Jason then I'm > a bit skeptical about it happening at all. If left completely on my own, the UltraAX and UltraAXi based systems are the only systems that will be targeted for the port. However, it seems that there are a number of people who are interested in seeing older hardware work. If these people draft off my efforts, I will be more than happy to help in any way that I can (which includes integrating support into the port, finding info, etc.), so long as it doesn't conflict with my primary goals, and doesn't take up huge amounts of my time. My limited personal scope still leaves a huge project at hand. To try to tackle all of the SPARC processors would be very difficult. To make matters worse, it seems that Sun's various MMUs are targets in and of themselves. Here's a light of hope for all of you wanting to run this port someday: Sun's boards are rapidly descending into the price range of upper-end Pentium II boards. The system I'm targeting for the port is just beyond the range of what I consider a reasonable price for personal purchase. The next board they release (coming relatively soon now) will be completely reasonable, as compared to the price/performance of Pentium II boards/cpus. These boards have integrated SCSI, PCI, and ethernet. The memory bandwidth is almost 3x that of P6 machines. They're really, really cool. When this port is done, my Intel boxes are going bye bye. =) Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Fri Dec 12 03:51:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA13805 for hackers-outgoing; Fri, 12 Dec 1997 03:51:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from paladio.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA13796 for ; Fri, 12 Dec 1997 03:51:06 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by paladio.canonware.com (8.8.5/8.8.5) with SMTP id DAA30760; Fri, 12 Dec 1997 03:51:01 -0800 Date: Fri, 12 Dec 1997 03:51:00 -0800 (PST) From: Jason Evans X-Sender: jasone@paladio Reply-To: Jason Evans To: "Jordan K. Hubbard" cc: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-Reply-To: <26799.881843800@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Jordan K. Hubbard wrote: > Great! I'd almost concluded that this had just faded away again, and > it's good to hear that SME didn't just give up when we were unable to > find any available personnel here. My boss mentioned talking with you the first week that I was at Sun, and I latched on. =) It wouldn't have happened if I hadn't shown extreme interest in working on it. > Ah, so that really means you're good for at least 60 hours a week > then! Good man! Real dedication! ;-) Yeah, something like that. Uh huh. =) Maybe not every week, but yes, I expect to spend those kinds of hours on the project. > I guess you're probably going to want to start with the compiler > issues first then, eh? Peter? Soren? John Polstra? You might wish to > step forward and shake hands with Jason here, guys, because he's > probably going to be the principal motive force behind your toolchain > upgrade in -current! :-) Compiler issues... gcc already supports the target platform. Standard gcc supports SPARC, and Cygnus has a patch to support the Ultra (V8+). What are the issues you refer to? Since FreeBSD is supported in the release version of gcc, don't you guys just copy it into your tree and call it good? Since the Ultra compiler won't be self-hosted until well after the kernel is up and running, why is this important as a first step? Even linker/loader issues seem like a longer term goal, because the kernel itelf is bootstrapped (unless there's shared code there - I haven't looked yet). It seems to me that the first major steps are: 1) Get the kernel to boot (and more or less work). 2) Probe hardware devices. 3) Create minimal number of device drivers for a minimal complete system. 4) Move to self hosting. > Absolutely. Assuming that you've done all that's required to prevent > collision (and again, it's going to take Peter or John P to more fully > answer that question) you can use the full CVS command set to manage > your tree there. You could even set up a local cvsupd and offer it to > others via cvsup, allowing your repository to be replicated in the > same manner as ours is. Great. This is exactly what I wanted to hear. I'll start messing with it asap. The parts for my (x86) FreeBSD box should be here tomorrow (fingers crossed). Jason Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison] From owner-freebsd-hackers Fri Dec 12 04:22:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA15515 for hackers-outgoing; Fri, 12 Dec 1997 04:22:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA15502 for ; Fri, 12 Dec 1997 04:22:03 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.8/8.8.7) with SMTP id HAA00383; Fri, 12 Dec 1997 07:21:58 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Fri, 12 Dec 1997 07:21:58 -0500 (EST) From: "David E. Cross" To: John Kelly cc: hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-Reply-To: <3491cfe3.6774010@mail.cetlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, John Kelly wrote: > On 8 Dec 1997 23:11:24 GMT, in comp.os.linux.development.system > torvalds@transmeta.com (Linus Torvalds) wrote: > > In article , > Albert D. Cahalan wrote: > >Jerry Hicks writes: > > > >> Wrong again Albert... > > > >Nope, you are wrong. This method is a _third_ solution. > > > >>>> My ``fix'' is to have the IDT descriptor reference a segemnt > >>>> which has a length of 0. This has the effect of mapping SIGILL > >>>> into SIGBUS, so that the `cmpxchg8' crash now generates a Bus > >>>> error. (I didn't bother returning the correct signal; it can > >>>> probably be added if it is important) > > This is indeed the "FreeBSD fix". > > The so-called "fix" doesn't work (it appears to, for simple exploits, > but it doesn't), and I _told_ some FreeBSD people so: I even sent > people a test-program that will still lock up a FreeBSD system with > the "fix". > > If they are indeed still using that fix, they are a sorry lot of > incompetent idiots. > > Linus Hmm, by my reading of /usr/src/sys/i386/i386/trap.c, we are trapping a page-fault, for the F00F workarround (Line 608, Version 1.83.2.2). I think Linus should a: Check his facts. b: not be so high and mighty all the time, it really turns people off. -- David Cross ACS Consultant From owner-freebsd-hackers Fri Dec 12 04:55:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA17216 for hackers-outgoing; Fri, 12 Dec 1997 04:55:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA17205 for ; Fri, 12 Dec 1997 04:55:36 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id PAA00364; Fri, 12 Dec 1997 15:55:10 +0300 (MSK) (envelope-from ache) Date: Fri, 12 Dec 1997 15:55:09 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "David E. Cross" cc: John Kelly , hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > but it doesn't), and I _told_ some FreeBSD people so: I even sent > > people a test-program that will still lock up a FreeBSD system with > > the "fix". It seems I miss beginning of discussion... Where is test-program he talk about? -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Fri Dec 12 05:03:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA17711 for hackers-outgoing; Fri, 12 Dec 1997 05:03:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA17698 for ; Fri, 12 Dec 1997 05:03:04 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id FAA15907; Fri, 12 Dec 1997 05:02:58 -0800 (PST) To: Jason Evans cc: Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Fri, 12 Dec 1997 03:50:09 PST." Date: Fri, 12 Dec 1997 05:02:58 -0800 Message-ID: <15903.881931778@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > boards/cpus. These boards have integrated SCSI, PCI, and ethernet. The > memory bandwidth is almost 3x that of P6 machines. They're really, really > cool. When this port is done, my Intel boxes are going bye bye. =) Yes, I've talked to a few Sun folks about the up-and-coming stuff. I agree that it looks definitely cool and is certainly the #1 porting target of choice. Depending on how this port goes, I could easily see myself getting one of these too. ;) I'd also argue that the legacy stuff should just generally be left alone until after the majority of the SPARC architecture support is rolled into the toolchain and your UltraSPARC port is at least booting single-user. :-) Unless someone's got a serious jones on for running FreeBSD on their SPARCStation II right this very minute, waiting until you've made more progress is only in their best interest if they want maximum leverage for their own port. Jordan From owner-freebsd-hackers Fri Dec 12 06:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA22724 for hackers-outgoing; Fri, 12 Dec 1997 06:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22690 for ; Fri, 12 Dec 1997 06:32:23 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id GAA16191; Fri, 12 Dec 1997 06:32:24 -0800 (PST) To: Jason Evans cc: freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port In-reply-to: Your message of "Fri, 12 Dec 1997 03:51:00 PST." Date: Fri, 12 Dec 1997 06:32:24 -0800 Message-ID: <16187.881937144@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > My boss mentioned talking with you the first week that I was at Sun, and I > latched on. =) It wouldn't have happened if I hadn't shown extreme > interest in working on it. And I'm sure that a lot of SPARC enthusiasts out there are really happy that you took the extra effort! :) > Compiler issues... gcc already supports the target platform. Standard > gcc supports SPARC, and Cygnus has a patch to support the Ultra (V8+). > What are the issues you refer to? Since FreeBSD is supported in the > release version of gcc, don't you guys just copy it into your tree and > call it good? Since the Ultra compiler won't be self-hosted until well > after the kernel is up and running, why is this important as a first step? Well, I had originally thought that you'd want to support easier cross-compilation from the x86, but now that I really think about it I guess I can see as how you'd have more SPARC hardware lying around to bootstrap from than you would x86 hardware. :-) However, for the medium term, it still might be a good idea to to see how NetBSD handles the problem of a single compiler source tree which can be built for different architectures. If you want an account on my NetBSD/ALPHA box, just let me know. :) [Might not be a bad idea in any case since you could see how they've addressed many of the 64 bit issues there]/ Jordan From owner-freebsd-hackers Fri Dec 12 08:17:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00922 for hackers-outgoing; Fri, 12 Dec 1997 08:17:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA00915 for ; Fri, 12 Dec 1997 08:17:06 -0800 (PST) (envelope-from lists@tar.com) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.8.7/8.8.7) with SMTP id KAA06873 for ; Fri, 12 Dec 1997 10:17:03 -0600 (CST) Message-Id: <199712121617.KAA06873@ns.tar.com> From: "Richard Seaman, Jr." To: "freebsd-hackers@freebsd.org" Date: Fri, 12 Dec 97 10:17:02 -0500 Reply-To: "Richard Seaman, Jr." Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Virtual Memory Question Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If I allocate memory using either malloc or mmap, how do I know if the address handle I get back can be mapped to physical backing of some sort (RAM or swap)? For example, I have a machine with 16MB RAM and 64MB swap. Using malloc, I can malloc just about 128MB. Obviously, thats more than I can get physical backing for. Trying to access it all terminates the process, as would be expected. For mmap (MAP_ANON with fd -1), I can "allocate" virtual memory totalling over 3GB. Same problem. Or, am I just supposed to be smart enough to not grab too much memory? Thanks. From owner-freebsd-hackers Fri Dec 12 08:22:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA01438 for hackers-outgoing; Fri, 12 Dec 1997 08:22:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA01413 for ; Fri, 12 Dec 1997 08:22:35 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA279; Fri, 12 Dec 1997 11:24:33 -0500 Received: by smginc.com with Microsoft Mail id <34918F3E@smginc.com>; Fri, 12 Dec 97 11:23:42 PST From: Adam Turoff To: "'jkh@time.cdrom.com'" , "'j_mini@efn.org'" Cc: "'freebsd-hackers@FreeBSD.ORG'" Subject: Kernel Config datafile... Date: Fri, 12 Dec 97 11:22:00 PST Message-ID: <34918F3E@smginc.com> Encoding: 12 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I don't want to start a flame war here, but I've heard the topic of a configuration file that needed to be both ASCII and vi/emacs editable as well as store relational data as well. Allow me to spread the evangelism a wee tad and mention SGML/XML. This would give the advantage of encoding multiple aspects of the kernel config data in a single ASCII (technically, Unicode) file. -- Adam. From owner-freebsd-hackers Fri Dec 12 09:14:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05019 for hackers-outgoing; Fri, 12 Dec 1997 09:14:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05007 for ; Fri, 12 Dec 1997 09:14:24 -0800 (PST) (envelope-from torvalds@transmeta.com) Received: from gold-1.transmeta.com (mailhost.transmeta.com [10.1.1.79]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA06623; Fri, 12 Dec 1997 09:06:17 -0800 Received: from penguin.transmeta.com (torvalds@penguin.transmeta.com [10.1.2.202]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id JAA17190; Fri, 12 Dec 1997 09:12:41 -0800 (PST) Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.8.5/8.7.3) with SMTP id JAA11384; Fri, 12 Dec 1997 09:12:40 -0800 X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs Date: Fri, 12 Dec 1997 09:12:40 -0800 (PST) From: Linus Torvalds To: David Greenman cc: John Kelly , hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-Reply-To: <199712120608.WAA01136@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, David Greenman wrote: > On 8 Dec 1997 23:11:24 GMT, in comp.os.linux.development.system > torvalds@transmeta.com (Linus Torvalds) wrote: > > > >If they are indeed still using that fix, they are a sorry lot of > >incompetent idiots. > > The fix that Linus is refering to is one of several that were evaluated > and rejected. The fix that we finally adopted in FreeBSD is the one that > involves making the IDT to read-only and catching the write fault that > occurs. Good. And I think I should clarify my position a bit - people did obviously not find my statement about "sorry lot of incompetent idiots" to go over well in some circles. Strange ;) Anyway, first I'd like to point out the "if .. indeed" clause of that part, just in case somebody missed it. I was personally involved with that particular fix, primarily as the one who de-bunked it. I was possibly not the only one, but I was at least one of the ones who spent time chasing down intel people and actually writing a test program that conclusively showed that the fix was bogus. I suspect that I was the first one to show it to be bogus. So imagine _my_ reaction when I am told by a third party that FreeBSD is still using the fix that I spent time _proving_ was wrong. In that context, "sorry lot of incompetent idiots" probably sounds a lot more understandable. Because a sorry lot you would have been. I'm happy that the third party was confused, but he had enough knowledge of the fix existing in the first place that I just assumed that he was right. Sorry for any ruffled feathers, and I guess I should have checked, but I don't think my reaction was completely unreasonable. Linus From owner-freebsd-hackers Fri Dec 12 09:22:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05565 for hackers-outgoing; Fri, 12 Dec 1997 09:22:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05530 for ; Fri, 12 Dec 1997 09:21:38 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id OAA10120 for ; Fri, 12 Dec 1997 14:21:29 -0300 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325656B.005F5840 ; Fri, 12 Dec 1997 14:21:25 -0300 X-Lotus-FromDomain: VOGA To: hackers@freebsd.org Message-ID: <8325656B.005F3DB8.00@papagaio.voga.com.br> Date: Fri, 12 Dec 1997 14:21:20 -0300 Subject: Re: Why so many steps to build new kernel? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't think name/class/description is enough. We ought to identify prerequisites and mutual exclusions (see syscon and vt drivers for an example of both situations). From owner-freebsd-hackers Fri Dec 12 10:29:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11994 for hackers-outgoing; Fri, 12 Dec 1997 10:29:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11980 for ; Fri, 12 Dec 1997 10:28:57 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id MAA19382; Fri, 12 Dec 1997 12:28:24 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id MAA17321; Fri, 12 Dec 1997 12:27:53 -0600 Message-ID: <19971212122752.36696@right.PCS> Date: Fri, 12 Dec 1997 12:27:52 -0600 From: Jonathan Lemon To: Linus Torvalds Cc: David Greenman , John Kelly , hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels References: <199712120608.WAA01136@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Linus Torvalds on Dec 12, 1997 at 09:12:40AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Dec 12, 1997 at 09:12:40AM -0800, Linus Torvalds wrote: > On Thu, 11 Dec 1997, David Greenman wrote: > > > On 8 Dec 1997 23:11:24 GMT, in comp.os.linux.development.system > > torvalds@transmeta.com (Linus Torvalds) wrote: > > > > > >If they are indeed still using that fix, they are a sorry lot of > > >incompetent idiots. > > > > The fix that Linus is refering to is one of several that were evaluated > > and rejected. The fix that we finally adopted in FreeBSD is the one that > > involves making the IDT to read-only and catching the write fault that > > occurs. > > Good. > > And I think I should clarify my position a bit - people did obviously not > find my statement about "sorry lot of incompetent idiots" to go over well > in some circles. Strange ;) > > Anyway, first I'd like to point out the "if .. indeed" clause of that > part, just in case somebody missed it. I don't think anyone missed it. However, the phrasing was same as the question ``Have you stopped beating your wife yet?'' EG: it presupposes circumstances that are not true. In this case, the assumption is that the fix was actually used by FBSD in the first place. I did propose the fix as a possible solution, and within the same day, I received reports of it not working for everyone. Within a few days, I heard secondhand that it didn't work for you. Later, I received conclusive proof from Intel that it would not work in all cases. In no case did the ``fix'' ever come close to going into FBSD. I would posit that the people working on the FBSD codebase are competent enough to not commit a fix until it is proven to work, and that it works in all cases. Thus, derogatory statements like the one above, which assume the opposite, are uncalled for. -- Jonathan From owner-freebsd-hackers Fri Dec 12 11:36:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17781 for hackers-outgoing; Fri, 12 Dec 1997 11:36:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17763 for ; Fri, 12 Dec 1997 11:36:03 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA263; Fri, 12 Dec 1997 14:38:04 -0500 Received: by smginc.com with Microsoft Mail id <3491BC98@smginc.com>; Fri, 12 Dec 97 14:37:12 PST From: Adam Turoff To: hackers Cc: "'daniel_sobral@voga.com.br'" Subject: RE: Why so many steps to build new kernel? Date: Fri, 12 Dec 97 14:35:00 PST Message-ID: <3491BC98@smginc.com> Encoding: 18 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I don't think name/class/description is enough. We ought to identify > prerequisites and mutual exclusions (see syscon and vt drivers for an > example of both situations). Sure, but (no offense) the prerequisites and mutual exclusions should be handled better than the ports collection is (for example). I seem to remember that RPM had a good idea of what a 'core' product is and what an 'upgrade' is so that when you upgrade, your dependencies are migrated to the new version of the product. Or am I getting ahead of myself WRT kernel configs? -- Adam. From owner-freebsd-hackers Fri Dec 12 11:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18982 for hackers-outgoing; Fri, 12 Dec 1997 11:50:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA18921 for ; Fri, 12 Dec 1997 11:49:55 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA10731 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Fri, 12 Dec 1997 20:50:07 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id SAA01127; Fri, 12 Dec 1997 18:45:08 +0100 (MET) From: Wilko Bulte Message-Id: <199712121745.SAA01127@yedi.iaf.nl> Subject: Re: Beginning SPARC port To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 12 Dec 1997 18:45:08 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19971212075437.35049@keltia.freenix.fr> from "Ollivier Robert" at Dec 12, 97 07:54:37 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just a thought: Maybe it's time to add an freebsd-sparc mailing list to majordomo? Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Fri Dec 12 11:52:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA19238 for hackers-outgoing; Fri, 12 Dec 1997 11:52:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA19172 for ; Fri, 12 Dec 1997 11:51:50 -0800 (PST) (envelope-from ian@nmsu.edu) Received: from NMSU.Edu by bubba.NMSU.Edu (8.8.7/NMSU) id MAA17584; Fri, 12 Dec 1997 12:48:44 -0700 (MST) Received: from wilma by NMSU.Edu (8.8.4/NMSU-1.18) id MAA20316; Fri, 12 Dec 1997 12:50:05 -0700 (MST) Received: from nmsu.edu by wilma (SMI-8.6/NMSU) id MAA18340; Fri, 12 Dec 1997 12:49:50 -0700 Message-ID: <349195B3.9C3EEE2D@nmsu.edu> Date: Fri, 12 Dec 1997 12:51:15 -0700 From: Ian Logan Organization: Computing and Networking X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 5.6 sun4m) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Jason Evans , Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port References: <15903.881931778@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > I'd also argue that the legacy stuff should just generally be left > alone until after the majority of the SPARC architecture support is > rolled into the toolchain and your UltraSPARC port is at least booting > single-user. :-) Unless someone's got a serious jones on for running > FreeBSD on their SPARCStation II right this very minute, waiting until > you've made more progress is only in their best interest if they want > maximum leverage for their own port. > > Jordan I guess I'm a little confused about what you're suggesting to leave out. A SS2 is indeed a very old box, and getting the code work right for a 4c seems to be a lot of work. However, from everything I've read upto now the newer 4m's (ie SparcStaion (4|5|10|20)) aren't that far off from the Ultra's, in other words they'll share alot of the same code. I don't see any reason why 4m & 4u support couldn't happen in parallel :-) Ian aka the guy wanting to write the 4m code. -- Ian Logan Computing & Networking New Mexico State University Email: ian@nmsu.edu Phone: 505-646-6034 Fax: 505-646-5278 From owner-freebsd-hackers Fri Dec 12 12:00:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19977 for hackers-outgoing; Fri, 12 Dec 1997 12:00:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19971 for ; Fri, 12 Dec 1997 12:00:31 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA02194; Fri, 12 Dec 1997 11:59:01 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma002188; Fri Dec 12 11:58:47 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id LAA26187; Fri, 12 Dec 1997 11:58:47 -0800 (PST) From: Archie Cobbs Message-Id: <199712121958.LAA26187@bubba.whistle.com> Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-Reply-To: <19971212122752.36696@right.PCS> from Jonathan Lemon at "Dec 12, 97 12:27:52 pm" To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 12 Dec 1997 11:58:47 -0800 (PST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Lemon writes: > On Dec 12, 1997 at 09:12:40AM -0800, Linus Torvalds wrote: > > > torvalds@transmeta.com (Linus Torvalds) wrote: > > > > > > > >If they are indeed still using that fix, they are a sorry lot of > > > >incompetent idiots. > > > > > > The fix that Linus is refering to is one of several that were evaluated > > > and rejected. The fix that we finally adopted in FreeBSD is the one that > > > involves making the IDT to read-only and catching the write fault that > > > occurs. > > > > Good. > > > > And I think I should clarify my position a bit - people did obviously not > > find my statement about "sorry lot of incompetent idiots" to go over well > > in some circles. Strange ;) > > > > Anyway, first I'd like to point out the "if .. indeed" clause of that > > part, just in case somebody missed it. > > I don't think anyone missed it. However, the phrasing was same as the > question ``Have you stopped beating your wife yet?'' EG: it presupposes > circumstances that are not true. In this case, the assumption is that the > fix was actually used by FBSD in the first place. Oh come on everyone. No need to make a big deal out of it. Linus is a friendly guy and meant no harm. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Fri Dec 12 12:05:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20300 for hackers-outgoing; Fri, 12 Dec 1997 12:05:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA20225 for ; Fri, 12 Dec 1997 12:04:39 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA02243 for ; Fri, 12 Dec 1997 12:04:01 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma002239; Fri Dec 12 12:03:51 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id MAA26205 for freebsd-hackers@FreeBSD.ORG; Fri, 12 Dec 1997 12:03:51 -0800 (PST) From: Archie Cobbs Message-Id: <199712122003.MAA26205@bubba.whistle.com> Subject: Re: memcmp() and memcpy() In-Reply-To: <199712102319.PAA22111@bubba.whistle.com> from Archie Cobbs at "Dec 10, 97 03:19:45 pm" To: freebsd-hackers@FreeBSD.ORG Date: Fri, 12 Dec 1997 12:03:51 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > According to the gcc info page, gcc will automatically inline > the memcpy() and memcmp() functions. > > The kernel header files define memcpy() but not memcmp() for > some reason. How come memcmp() is not defined? > > This is in reference to 2.2.5... haven't looked at -current. Since no one replied, I guess nobody knows the real reason... So what do you think about the suggestion that memcmp() be added to ? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Fri Dec 12 13:12:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24868 for hackers-outgoing; Fri, 12 Dec 1997 13:12:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24814 for ; Fri, 12 Dec 1997 13:11:49 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA02732; Fri, 12 Dec 1997 16:11:38 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712122111.QAA02732@dyson.iquest.net> Subject: Re: Virtual Memory Question In-Reply-To: <199712121617.KAA06873@ns.tar.com> from "Richard Seaman, Jr." at "Dec 12, 97 10:17:02 am" To: lists@tar.com Date: Fri, 12 Dec 1997 16:11:38 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Seaman, Jr. said: > If I allocate memory using either malloc or mmap, how do I know if the > address handle I get back can be mapped to physical backing of some > sort (RAM or swap)? > > For example, I have a machine with 16MB RAM and 64MB swap. Using > malloc, I can malloc just about 128MB. Obviously, thats more than I > can get physical backing for. Trying to access it all terminates > the process, as would be expected. > > For mmap (MAP_ANON with fd -1), I can "allocate" virtual memory totalling > over 3GB. Same problem. > > Or, am I just supposed to be smart enough to not grab too much memory? > FreeBSD allocates a VM object for large chunks of data, but does not reserve swap. The allocation is done to avoid internal deadlocks, but does not eliminate the possiblility of the ultimate one of running out of swap. I have an idea for a limited swap reservation system, that is not complex, and could be turned on by a sysctl. We might have something by 3.0. (The reason that it is not in there yet, is because alot of desktop systems run with swap space overcommitted, due to conservative (low) estimation of swap requirements. Those who really need the additional "security" of space reservation are usually also aware of swap space needs.) -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Dec 12 13:51:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA28198 for hackers-outgoing; Fri, 12 Dec 1997 13:51:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ppp6426.on.bellglobal.com (ppp6426.on.bellglobal.com [206.172.208.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA27964 for ; Fri, 12 Dec 1997 13:48:22 -0800 (PST) (envelope-from hoek@FreeBSD.ORG) Received: from localhost (tim@localhost) by ppp6426.on.bellglobal.com (8.8.7/8.8.7) with SMTP id QAA00252; Fri, 12 Dec 1997 16:46:14 -0500 (EST) (envelope-from hoek@FreeBSD.ORG) X-Authentication-Warning: ppp6426.on.bellglobal.com: tim owned process doing -bs Date: Fri, 12 Dec 1997 16:46:14 -0500 (EST) From: Tim Vanderhoek X-Sender: tim@localhost Reply-To: Tim Vanderhoek To: Linus Torvalds cc: David Greenman , John Kelly , hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, Linus Torvalds wrote: > So imagine _my_ reaction when I am told by a third party that FreeBSD is > still using the fix that I spent time _proving_ was wrong. In that > context, "sorry lot of incompetent idiots" probably sounds a lot more > understandable. Because a sorry lot you would have been. Fortunately, you knew that we were not a sorry lot and would not have implemented a known broken fix. The comment was only to be on the safe side, merely reflecting a lack of confidence in your own ability to make such judgements. :-) -- tIM...HOEk OPTIMIZATION: the process of using many one-letter variables names hoping that the resultant code will run faster. From owner-freebsd-hackers Fri Dec 12 13:58:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA28690 for hackers-outgoing; Fri, 12 Dec 1997 13:58:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA28678 for ; Fri, 12 Dec 1997 13:58:38 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-49.cetlink.net [209.54.58.49]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id QAA28979; Fri, 12 Dec 1997 16:58:22 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Archie Cobbs Cc: hackers@FreeBSD.ORG, torvalds@transmeta.com Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels Date: Fri, 12 Dec 1997 22:59:20 GMT Message-ID: <3495bef7.24080273@mail.cetlink.net> References: <199712121958.LAA26187@bubba.whistle.com> In-Reply-To: <199712121958.LAA26187@bubba.whistle.com> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id NAA28683 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997 11:58:47 -0800 (PST), Archie Cobbs wrote: >> > Anyway, first I'd like to point out the "if .. indeed" clause of that >> > part, just in case somebody missed it. >> >> I don't think anyone missed it. However, the phrasing was same as the >> question ``Have you stopped beating your wife yet?'' EG: it presupposes >> circumstances that are not true. In this case, the assumption is that the >> fix was actually used by FBSD in the first place. > >Oh come on everyone. No need to make a big deal out of it. Most people skim read email just to keep up. When reading that fast, you rarely take time to carefully analyze each sentence to notice the "if ... indeed" that Linus uses as his defense. What sticks in the minds of readers is the "sorry lot of incompetent idiots" that Linus applies to FreeBSD users and developers. His statement was posted publicly, in a place not frequented by FreeBSD users who might challenge it. It was read by thousands of people who take his word as truth. If he wanted to criticize FreeBSD in such a blatant manner, he should *not* have done it in a Linux newsgroup. That makes his remarks utterly irresponsible. >Linus is a friendly guy and meant no harm. Drunks who kill people on the highways may be friendly and mean no harm too. Alcohol is not the only way to become intoxicated. Power, imagined or real, can intoxicate too. John From owner-freebsd-hackers Fri Dec 12 14:08:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29468 for hackers-outgoing; Fri, 12 Dec 1997 14:08:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from xena.mindspring.com (xena.mindspring.com [207.69.142.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29454 for ; Fri, 12 Dec 1997 14:08:36 -0800 (PST) (envelope-from rsanders@xena.mindspring.com) Received: (from rsanders@localhost) by xena.mindspring.com (8.8.5/8.8.5) id RAA11154; Fri, 12 Dec 1997 17:08:34 -0500 (EST) From: Robert Sanders To: hackers@freebsd.org Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels References: <19971212122752.36696@right.PCS> <199712121958.LAA26187@bubba.whistle.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 12 Dec 1997 17:08:34 -0500 In-Reply-To: Archie Cobbs's message of "Fri, 12 Dec 1997 11:58:47 -0800 (PST)" Message-ID: Lines: 19 X-Mailer: Quassia Gnus v0.18/XEmacs 20.3(beta19) - "Kiev" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Archie Cobbs writes: > > On Dec 12, 1997 at 09:12:40AM -0800, Linus Torvalds wrote: > > > > torvalds@transmeta.com (Linus Torvalds) wrote: > > > > > > > > > >If they are indeed still using that fix, they are a sorry lot of > > > > >incompetent idiots. > > > Anyway, first I'd like to point out the "if .. indeed" clause of that > > > part, just in case somebody missed it. > Oh come on everyone. No need to make a big deal out of it. > Linus is a friendly guy and meant no harm. But if he did indeed mean to imply what many have inferred, then he is an egomaniacal, conceited, rude bastard. regards, -- Robert From owner-freebsd-hackers Fri Dec 12 14:35:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA01213 for hackers-outgoing; Fri, 12 Dec 1997 14:35:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA01196 for ; Fri, 12 Dec 1997 14:34:58 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id OAA19833; Fri, 12 Dec 1997 14:15:39 -0800 (PST) Message-ID: <19971212141538.57181@micron.mini.net> Date: Fri, 12 Dec 1997 14:15:38 -0800 From: Jonathan Mini To: Adam Turoff Cc: "'jkh@time.cdrom.com'" , "'j_mini@efn.org'" , "'freebsd-hackers@FreeBSD.ORG'" Subject: Re: Kernel Config datafile... Reply-To: Jonathan Mini References: <34918F3E@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <34918F3E@smginc.com>; from Adam Turoff on Fri, Dec 12, 1997 at 11:22:00AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hmmm. No flames about SGML (read below), but I will yell azt you for using a mailer that doesn't generate In-Reply-To headers. These headers allow mailers like mutt to keep all incoming messages sotrted by threads, and without them the threads get all mixed up. Most mailers generate them, except for a few. PLEASE PLEASE PLEASE upgrade to a mailer that will generate In-Reply-To headers. Adam Turoff stands accused of saying: > > I don't want to start a flame war here, but I've heard the > topic of a configuration file that needed to be both > ASCII and vi/emacs editable as well as store relational > data as well. > > Allow me to spread the evangelism a wee tad and mention > SGML/XML. This would give the advantage of encoding > multiple aspects of the kernel config data in a single > ASCII (technically, Unicode) file. I was thinking about using SGML actually, but I hadn't got that far. We'll see about whether or not it turns out to be the easiest format to deal with. I think it might. For example : You get the idea. We'll see. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Fri Dec 12 14:49:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02048 for hackers-outgoing; Fri, 12 Dec 1997 14:49:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA02032 for ; Fri, 12 Dec 1997 14:49:24 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id XAA13636; Fri, 12 Dec 1997 23:47:45 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id XAA05489; Fri, 12 Dec 1997 23:37:15 +0100 (CET) (envelope-from roberto) Message-ID: <19971212233715.08718@keltia.freenix.fr> Date: Fri, 12 Dec 1997 23:37:15 +0100 From: Ollivier Robert To: hackers@FreeBSD.ORG, torvalds@transmeta.com Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels References: <199712121958.LAA26187@bubba.whistle.com> <3495bef7.24080273@mail.cetlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <3495bef7.24080273@mail.cetlink.net>; from John Kelly on Fri, Dec 12, 1997 at 10:59:20PM +0000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3883 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to John Kelly: [something not really quotable] Uh ? Could we all kill this flame^Wdiscussion NOW ? Useless on all counts. For both Linus and us. Code is useful. Flames are not. Please help us with coding. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #19: Tue Dec 9 20:17:10 CET 1997 From owner-freebsd-hackers Fri Dec 12 15:10:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04032 for hackers-outgoing; Fri, 12 Dec 1997 15:10:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA03976 for ; Fri, 12 Dec 1997 15:09:53 -0800 (PST) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id SAA00472; Fri, 12 Dec 1997 18:08:53 -0500 (EST) Date: Fri, 12 Dec 1997 18:08:53 -0500 (EST) From: John Fieber To: Jonathan Mini cc: Adam Turoff , "'jkh@time.cdrom.com'" , "'freebsd-hackers@FreeBSD.ORG'" Subject: Re: Kernel Config datafile... In-Reply-To: <19971212141538.57181@micron.mini.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, Jonathan Mini wrote: > I was thinking about using SGML actually, but I hadn't got that far. We'll > see about whether or not it turns out to be the easiest format to deal with. XML would probably be the better choice--it is a hell of a lot easier to parse than SGML, despite the fact that they look so similar on the surface. Hm... maybe we should have a handy little XML parser in a library to encourage this sort of thing. :) -john From owner-freebsd-hackers Fri Dec 12 15:22:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05030 for hackers-outgoing; Fri, 12 Dec 1997 15:22:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dan.emsphone.com (dan@dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA05017 for ; Fri, 12 Dec 1997 15:22:08 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.8.6/8.8.6) id RAA18626; Fri, 12 Dec 1997 17:21:41 -0600 (CST) Message-ID: <19971212172140.57212@emsphone.com> Date: Fri, 12 Dec 1997 17:21:40 -0600 From: Dan Nelson To: Jonathan Mini Cc: Adam Turoff , jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Kernel Config datafile... References: <34918F3E@smginc.com> <19971212141538.57181@micron.mini.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.4e In-Reply-To: <19971212141538.57181@micron.mini.net>; from "Jonathan Mini" on Fri Dec 12 14:15:38 GMT 1997 X-OS: FreeBSD 2.2-970701-RELENG Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the last episode (Dec 12), Jonathan Mini said: > > I was thinking about using SGML actually, but I hadn't got that far. We'll > see about whether or not it turns out to be the easiest format to deal with. > I think it might. For example : > > The web server Roxen uses a similar format for its configuration files. I don't know if it's truly SGML, or just easy for the web server to parse.. For example, here's a snippet from the part of the file that enables user directories: /public_html/ 0 /~ root daemon bin sys Every tag has an open and a close tag, defines a variable name, and the data inside defines its type. is an array container. -Dan Nelson dnelson@emsphone.com From owner-freebsd-hackers Fri Dec 12 15:45:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06505 for hackers-outgoing; Fri, 12 Dec 1997 15:45:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06480 for ; Fri, 12 Dec 1997 15:44:49 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA22204; Fri, 12 Dec 1997 16:47:45 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd021956; Fri Dec 12 16:47:01 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA16748; Fri, 12 Dec 1997 16:42:35 -0700 (MST) From: Terry Lambert Message-Id: <199712122342.QAA16748@usr04.primenet.com> Subject: Re: Why so many steps to build new kernel? To: AdamT@smginc.com (Adam Turoff) Date: Fri, 12 Dec 1997 23:42:35 +0000 (GMT) Cc: hackers@FreeBSD.ORG, daniel_sobral@voga.com.br In-Reply-To: <3491BC98@smginc.com> from "Adam Turoff" at Dec 12, 97 02:35:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I don't think name/class/description is enough. We ought to identify > > prerequisites and mutual exclusions (see syscon and vt drivers for an > > example of both situations). > > Sure, but (no offense) the prerequisites and mutual exclusions should > be handled better than the ports collection is (for example). > > I seem to remember that RPM had a good idea of what a > 'core' product is and what an 'upgrade' is so that when > you upgrade, your dependencies are migrated to the > new version of the product. > > Or am I getting ahead of myself WRT kernel configs? I think everyone is getting ahead of themselves. The idea that there needs to be a mechanism for handling mutual exclusions presupposes (incorrectly, IMO), that some drivers are mutually exclusive. If this is the case, the thing to fix is the drivers, not to add the ability to do mutual exclusion into a kernel configurator. Similarly, prerequisite identification is well and good, but can be done symbolically, without reference to a kernel configurator. So what's left for a kernel configurator to do? Basically, it's to let a human do device probes on its behalf. This seems buggered to me. It seems to me that the driver should be able to do its own probes without "calling a procedure embedded in a human" to do the job. In other words, it's an issue of writing the appropriate driver probe code. So what's left for a kernel configurator to do? The only thing I can think of is to draw a distinction between "boot critical" and "non-boot critical" devices. But you can know that already, if you know the kernel design well enough. Certainly, the Makefile's whould know the kernel design well enough. That's what they are there for. So the distinction between "boot critical" and "non-boot critical" can be made at the "is linked into the kernel" and "is dynamically loaded into the kernel after boot is complete". In other words, the liker targets in the default Makefile. So what's left for a kernel configurator to do? ...Nothing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Dec 12 16:03:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA07973 for hackers-outgoing; Fri, 12 Dec 1997 16:03:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07966 for ; Fri, 12 Dec 1997 16:02:55 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA20790; Fri, 12 Dec 1997 17:03:40 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd020778; Fri Dec 12 17:03:35 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA17704; Fri, 12 Dec 1997 17:02:18 -0700 (MST) From: Terry Lambert Message-Id: <199712130002.RAA17704@usr04.primenet.com> Subject: Re: Beginning SPARC port To: jasone@canonware.com Date: Sat, 13 Dec 1997 00:02:15 +0000 (GMT) Cc: jkh@time.cdrom.com, freebsd-hackers@freebsd.org In-Reply-To: from "Jason Evans" at Dec 12, 97 03:51:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Compiler issues... gcc already supports the target platform. Standard > gcc supports SPARC, and Cygnus has a patch to support the Ultra (V8+). > What are the issues you refer to? Since FreeBSD is supported in the > release version of gcc, don't you guys just copy it into your tree and > call it good? Since the Ultra compiler won't be self-hosted until well > after the kernel is up and running, why is this important as a first step? There are GAS hacks for weak symbol support in an a.out environment, and there are binutils hacks for BSD shared library technology, which is not identical to SunOS 4.x shared library technology (BSD shared libraries have a single file instead of needing seperate files for linker stubs and data vs. library text, as in SunOs 4.x). Because of this, FreeBSD currently uses a very old version of binutils that has been hacked up. Specifically, FreeBSD has its own "ld" and "ld.so". The general feeling seems to be that we need to go to ELF. This sort of implies that the FreeBSD SPARC port should discard the FreeBSD a.out format entirely, and use an actively maintained toolchain so that you won't have to duplicate the local hacks for SPARC. > Even linker/loader issues seem like a longer term goal, because the kernel > itelf is bootstrapped (unless there's shared code there - I haven't looked > yet). It seems to me that the first major steps are: > > 1) Get the kernel to boot (and more or less work). You can do this with only a console (serial port or real console) driver. To do this requires using DEVFS and MFS. This lets you load an image with whatever loader technology, and bring the kernel up without a local media file system. Without using DEVFS, you will need a net driver for NFS, or a local media driver for a local media file system (probably FFS). Part of getting the kernel working is in doing a lot of hardware specific things. These need to be abstracted (this is my opinion) to make ports easier. I think these should be encapsulated via a C interface, so that for a new port, you can write a C stub that provides the hardware specific information as hardcoded values for the porting hardware you are using. Memory size, etc.. All the things you would get from PPCBug, M68kBug, OpenBoot, PC BIOS, etc.. I would be happy to help with this code. Another part of getting the kernel working is to convert all of the assembly code over. I think a lot of this code could be written to have C equivalents, and interfaces that expect assembly should be changed if the same functionality can be achieved, however more slowly, with C code. I would be very happy to work on this as well; it won't even require that people buy a SPARC machine to contribute to this process. The biggest challenge I think you will face in this phase is in getting the VM running, and then keeping it in sync (this is where I had problems in a PPC port I've since shelved). You will need to get a commitment from John Dyson on working with you on this, either to act as an information source and to get notification of changes, or to "freeze" the VM for everything but bug fixes for the duration of the porting process (this is what finally made me shelve the PPC port -- I was running PPCBug firmware, so I couldn't even leverage the NetBSD code). > 2) Probe hardware devices. > 3) Create minimal number of device drivers for a minimal complete system. > 4) Move to self hosting. All logical steps. #'s 2 & 3 are doozies. 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 Dec 12 16:06:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08232 for hackers-outgoing; Fri, 12 Dec 1997 16:06:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08225 for ; Fri, 12 Dec 1997 16:06:06 -0800 (PST) (envelope-from nectar@kai.communique.net) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id SAA00398; Fri, 12 Dec 1997 18:06:06 -0600 (CST) Message-Id: <199712130006.SAA00398@kai.communique.net> X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma000391; Fri, 12 Dec 97 18:06:00 -0600 From: Jacques Vidrine To: Dan Nelson cc: Jonathan Mini , Adam Turoff , jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Config datafile... In-reply-to: <19971212172140.57212@emsphone.com> References: <34918F3E@smginc.com> <19971212141538.57181@micron.mini.net> <19971212172140.57212@emsphone.com> Date: Fri, 12 Dec 1997 18:06:00 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Boy, I'd hate to have to deal with that mess. There's was recently a debate on one of the Python mailing lists on whether to use XML for "doc strings" (structured comments that become part of the actual code). It was pretty much rejected because it was too much typing. :-) I want human readable, human writable, and easy to parse. What was wrong with the current config file format, again? :-) Just kidding, I know the answer. Perhaps something more like structured text, such as an example someone gave earlier. Or maybe a bit like XF86Config, or like the stanzas seen in some AIX system files or Windows 3.x INI files. A template: sio: parent = isa? port = 0x3f8 "COM1", 0x2f8 "COM2", 0x3e8 "COM3", 0x2e8 "COM4", \ integer "OTHER" tty = true flags = 0x00001 "Shared IRQs", 0x00002 "Disable FIFO", ... irq = 3 "COM2 or COM4", 4 "COM1 or COM3", any "OTHER" vector = siointr A specific instance: sio0: description = "Standard Serial Port" parent = isa port = 0x3f8 flags = 0x00001 irq = 4 I dunno, just thinking. I want something easy for ME to parse too :-) Jacques Vidrine On 12 December 1997 at 17:21, Dan Nelson wrote: > The web server Roxen uses a similar format for its configuration files. > I don't know if it's truly SGML, or just easy for the web server to > parse.. For example, here's a snippet from the part of the file that > enables user directories: > > > /public_html/ > 0 > /~ > > > root > daemon > bin > sys > > > > > Every tag has an open and a close tag, defines a variable > name, and the data inside defines its type. is an array > container. > > -Dan Nelson > dnelson@emsphone.com From owner-freebsd-hackers Fri Dec 12 16:42:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10777 for hackers-outgoing; Fri, 12 Dec 1997 16:42:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10754 for ; Fri, 12 Dec 1997 16:42:02 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA08583; Fri, 12 Dec 1997 17:41:32 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd008561; Fri Dec 12 17:41:28 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA19766; Fri, 12 Dec 1997 17:41:12 -0700 (MST) From: Terry Lambert Message-Id: <199712130041.RAA19766@usr04.primenet.com> Subject: Re: Kernel Config datafile... To: n@nectar.com (Jacques Vidrine) Date: Sat, 13 Dec 1997 00:41:12 +0000 (GMT) Cc: dnelson@emsphone.com, j_mini@efn.org, AdamT@smginc.com, jkh@time.cdrom.com, freebsd-hackers@freebsd.org In-Reply-To: <199712130006.SAA00398@kai.communique.net> from "Jacques Vidrine" at Dec 12, 97 06:06:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > sio: > parent = isa? > port = 0x3f8 "COM1", 0x2f8 "COM2", 0x3e8 "COM3", 0x2e8 "COM4", \ > integer "OTHER" > tty = true > flags = 0x00001 "Shared IRQs", 0x00002 "Disable FIFO", ... > irq = 3 "COM2 or COM4", 4 "COM1 or COM3", any "OTHER" > vector = siointr Instead of reinventing Windows 3.1 .INI files, why down't we just jump straight to reinventing the the Windows 95 registry? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Dec 12 16:44:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10988 for hackers-outgoing; Fri, 12 Dec 1997 16:44:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10934 for ; Fri, 12 Dec 1997 16:43:46 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA03452; Fri, 12 Dec 1997 19:43:11 -0500 (EST) (envelope-from toor) Message-Id: <199712130043.TAA03452@dyson.iquest.net> Subject: Re: Beginning SPARC port In-Reply-To: <199712130002.RAA17704@usr04.primenet.com> from Terry Lambert at "Dec 13, 97 00:02:15 am" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 12 Dec 1997 19:43:11 -0500 (EST) Cc: jasone@canonware.com, jkh@time.cdrom.com, freebsd-hackers@freebsd.org From: "John S. Dyson" Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > The biggest challenge I think you will face in this phase is in > getting the VM running, and then keeping it in sync (this is where > I had problems in a PPC port I've since shelved). You will need > to get a commitment from John Dyson on working with you on this, > either to act as an information source and to get notification of > changes, or to "freeze" the VM for everything but bug fixes for > the duration of the porting process (this is what finally made me > shelve the PPC port -- I was running PPCBug firmware, so I couldn't > even leverage the NetBSD code). > You have my commitment for support, I cannot suggest to freeze the VM code due to SMP though. From the VM side, one approach might be to start with the X86 pmap. As a very rough first pass, emulate something similar to the X86 pt structure. You can do the walk of the pagetable structure when TLB exceptions occur. I don't have a Sparc manual yet, but it is likely that if you want a referenced bit, you have to emulate it. If you don't want to emulate it, I can add about 20 or so lines of code to the upper level VM so that it isn't needed for now. (Actually, it is likely that the referenced bit managment isn't needed, for a 1st pass -- get it working -- port.) I wouldn't try to make the port "perfect" in the first pass, but once it is sort-of running, it will be easier for more people to work on it. If I can get a box for a coupla K or so, I might be able to eventually help with more active coding. In any event, I'll try to be quickly available to describe code and answer questions. -- John dyson@freebsd.org jdyson@nc.com From owner-freebsd-hackers Fri Dec 12 17:07:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12258 for hackers-outgoing; Fri, 12 Dec 1997 17:07:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebsd1.cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12252 for ; Fri, 12 Dec 1997 17:07:47 -0800 (PST) (envelope-from jb@freebsd1.cimlogic.com.au) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id MAA04088; Sat, 13 Dec 1997 12:10:29 +1100 (EST) From: John Birrell Message-Id: <199712130110.MAA04088@freebsd1.cimlogic.com.au> Subject: Re: Kernel Config datafile... In-Reply-To: <199712130041.RAA19766@usr04.primenet.com> from Terry Lambert at "Dec 13, 97 00:41:12 am" To: tlambert@primenet.com (Terry Lambert) Date: Sat, 13 Dec 1997 12:10:29 +1100 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > Instead of reinventing Windows 3.1 .INI files, why down't we just > jump straight to reinventing the the Windows 95 registry? Oh yeah, then we can say: WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall FreeBSD to correct them. FreeBSD cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk. 8-) > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-hackers Fri Dec 12 17:27:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA13629 for hackers-outgoing; Fri, 12 Dec 1997 17:27:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA13614 for ; Fri, 12 Dec 1997 17:26:57 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00751; Sat, 13 Dec 1997 11:51:07 +1030 (CST) Message-Id: <199712130121.LAA00751@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? In-reply-to: Your message of "Thu, 11 Dec 1997 01:34:07 -0800." <25819.881832847@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 11:51:07 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > We need to do this in three stages then : > > 1) decide what types of "configurability" we want to allow the config > > utility to handle. compile-time options, compiled-in device, managing > > LKMs (for now, I hope to see the kld code replace it) and other types > > of kernel behavior would be a good idea too. > > Plausably, we could extend this to cover any sort of system > > configuration, but whether we want to do that is what we'd talk about > > in this stage. > > I think the above has actually been covered in some detail in this > mailing list over the last 3 or 4 other times this topic has come up, > but my own memory is faint on the details. Perhaps those previously > involved in raising this issue (was one of them Mike Smith, my memory Guilty. Search the archives for anything with my name and "metaconfiguration" in it, and you've got a pretty good chance of coming up with my previous proposal. (All of Jordan's points are spot-on) > o The new configuration format should still be ASCII and editable > by Mere Humans(tm), just in a format which is much more easily > machine-parsed. Exactly. The issue is not in the format of the generated configuration (which can easily remain *exactly* as it is right now), but in the metaconfiguration information used by the config-generation tool. Once you have established the basic classes of configuration entities, and the rules that link them together, you can codify these in just about any format you like; text is good because CVS, emacs and vi all like it. mike From owner-freebsd-hackers Fri Dec 12 17:41:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14349 for hackers-outgoing; Fri, 12 Dec 1997 17:41:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14339 for ; Fri, 12 Dec 1997 17:40:51 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00829; Sat, 13 Dec 1997 12:05:13 +1030 (CST) Message-Id: <199712130135.MAA00829@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: John Birrell cc: tlambert@primenet.com (Terry Lambert), hackers@freebsd.org Subject: Re: Kernel Config datafile... In-reply-to: Your message of "Sat, 13 Dec 1997 12:10:29 +1100." <199712130110.MAA04088@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 12:05:13 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Terry Lambert wrote: > > Instead of reinventing Windows 3.1 .INI files, why down't we just > > jump straight to reinventing the the Windows 95 registry? > > Oh yeah, then we can say: > > > WARNING: Using Registry Editor incorrectly can cause serious, system-wide > problems that may require you to reinstall FreeBSD to correct them. > FreeBSD cannot guarantee that any problems resulting from the use of > Registry Editor can be solved. Use this tool at your own risk. > > > 8-) *chuckle* Actually, every time someone mentions the Windows Registry my hackles come up at the suggestion that Microsoft somehow invented the concept, or even got the bloody thing halfway *right*. Apollo did it *much* better, and it's beginning to sound like LDAP will inherit the mantle. mike From owner-freebsd-hackers Fri Dec 12 17:41:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14386 for hackers-outgoing; Fri, 12 Dec 1997 17:41:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14345 for ; Fri, 12 Dec 1997 17:41:03 -0800 (PST) (envelope-from nectar@kai.communique.net) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id TAA00563; Fri, 12 Dec 1997 19:41:08 -0600 (CST) Message-Id: <199712130141.TAA00563@kai.communique.net> X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma000554; Fri, 12 Dec 97 19:40:48 -0600 From: Jacques Vidrine To: Terry Lambert cc: n@nectar.com (Jacques Vidrine), dnelson@emsphone.com, j_mini@efn.org, AdamT@smginc.com, jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Kernel Config datafile... In-reply-to: <199712130041.RAA19766@usr04.primenet.com> References: <199712130041.RAA19766@usr04.primenet.com> Date: Fri, 12 Dec 1997 19:40:48 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tee hee. Your later suggestion (by later I mean the one I read after I wrote the message below), if I read it right, sounds like the way to go long term. I understood it to mean something to the effect that at kernel build time, device drivers should probe the hardware to decide for themselves whether they should be included in the linked kernel. Or perhaps you meant that the kernel should be finalized at system load time via dynamic loading, rather than during kernel build time. I knew I should have read it twice before deleting, maybe you can privately resend? I guess the question it also brings up is, Do we want to spend time on an intermediate solution that _does_ involve a configuration file? Or do we want to skip reinventing the "Windows registry" and go for reinventing "Plug-n-Play" :-) Jacques Vidrine On 13 December 1997 at 0:41, Terry Lambert wrote: > > sio: > > parent = isa? > > port = 0x3f8 "COM1", 0x2f8 "COM2", 0x3e8 "COM3", 0x2e8 "COM4", \ > > integer "OTHER" > > tty = true > > flags = 0x00001 "Shared IRQs", 0x00002 "Disable FIFO", ... > > irq = 3 "COM2 or COM4", 4 "COM1 or COM3", any "OTHER" > > vector = siointr > > Instead of reinventing Windows 3.1 .INI files, why down't we just > jump straight to reinventing the the Windows 95 registry? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. From owner-freebsd-hackers Fri Dec 12 17:41:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA14509 for hackers-outgoing; Fri, 12 Dec 1997 17:41:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA14491 for ; Fri, 12 Dec 1997 17:41:36 -0800 (PST) (envelope-from nectar@kai.communique.net) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id TAA00579; Fri, 12 Dec 1997 19:41:38 -0600 (CST) Message-Id: <199712130141.TAA00579@kai.communique.net> X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma000571; Fri, 12 Dec 97 19:41:21 -0600 From: Jacques Vidrine To: John Birrell cc: tlambert@primenet.com (Terry Lambert), hackers@freebsd.org Subject: Re: Kernel Config datafile... In-reply-to: <199712130110.MAA04088@freebsd1.cimlogic.com.au> References: <199712130110.MAA04088@freebsd1.cimlogic.com.au> Date: Fri, 12 Dec 1997 19:41:21 -0600 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My copy of EMACS says that ... Jacques Vidrine On 13 December 1997 at 12:10, John Birrell wrote: > Terry Lambert wrote: > > Instead of reinventing Windows 3.1 .INI files, why down't we just > > jump straight to reinventing the the Windows 95 registry? > > Oh yeah, then we can say: > > > WARNING: Using Registry Editor incorrectly can cause serious, system-wide > problems that may require you to reinstall FreeBSD to correct them. > FreeBSD cannot guarantee that any problems resulting from the use of > Registry Editor can be solved. Use this tool at your own risk. > > > 8-) > > > Terry Lambert > > terry@lambert.org > > --- > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > > > Regards, > > -- > John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org > CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 From owner-freebsd-hackers Fri Dec 12 18:14:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15914 for hackers-outgoing; Fri, 12 Dec 1997 18:14:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15908 for ; Fri, 12 Dec 1997 18:14:34 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA18496; Fri, 12 Dec 1997 18:13:19 -0800 (PST) To: Ian Logan cc: Jason Evans , Chuck Robey , freebsd-hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Fri, 12 Dec 1997 12:51:15 MST." <349195B3.9C3EEE2D@nmsu.edu> Date: Fri, 12 Dec 1997 18:13:19 -0800 Message-ID: <18492.881979199@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > from the Ultra's, in other words they'll share alot of the same code. I > don't see any reason why 4m & 4u support couldn't happen in parallel :-) > Ian aka the guy wanting to write the 4m code. I'm not trying to actively discourage such efforts, and if you're really wanting to hack support for the 4m then by all means, please do so. I was simply trying to stem the tide of "Cool! When's this all going to work on my SS5 clone!" sorts of questions before Jason's even gotten started on the principal objective. :) Jordan From owner-freebsd-hackers Fri Dec 12 19:22:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA19618 for hackers-outgoing; Fri, 12 Dec 1997 19:22:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA19608 for ; Fri, 12 Dec 1997 19:22:43 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA05229; Fri, 12 Dec 1997 20:26:00 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd005211; Fri Dec 12 20:25:47 1997 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id UAA27603; Fri, 12 Dec 1997 20:21:54 -0700 (MST) From: Terry Lambert Message-Id: <199712130321.UAA27603@usr04.primenet.com> Subject: Re: Kernel Config datafile... To: mike@smith.net.au (Mike Smith) Date: Sat, 13 Dec 1997 03:21:54 +0000 (GMT) Cc: jb@freebsd1.cimlogic.com.au, tlambert@primenet.com, hackers@freebsd.org In-Reply-To: <199712130135.MAA00829@word.smith.net.au> from "Mike Smith" at Dec 13, 97 12:05:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Actually, every time someone mentions the Windows Registry my hackles > come up at the suggestion that Microsoft somehow invented the concept, > or even got the bloody thing halfway *right*. > > Apollo did it *much* better, and it's beginning to sound like LDAP will > inherit the mantle. Not if it can't do transactions. For example, I want to change the local machines network configuration. The network configuration has to be atomically updated" you either update all of the fields, or none of them. The typical way you would implement this in LDAP (and in the Windows 95 registry) is to use an encapsulation object. Specifically, say I have an entry named 0x000000001. Inferior to this entry, I have: 0x000000001 hostname S myhostname domainname S domain.com ip_forwarding I 0x00000000 ... I should not refer to this directly. I should use a container object: hostdata current I 0x00000001 To atomically rewrite these key/value pairs as one transaction, I create a replacement record (which I update non-atomically): 0x0002713A5 hostname S newhostname domainname S newmain.com ip_forwarding I 0x00000001 ... Then I update the hostdata to point to the new container, like so: hostdata current I 0x0002713A5 The problem with this is that you must require that the application have the knowledge of the transaction. This is a bad thing, since it means you have to duplicate the transaction code in every application that accesses your directory (a registry is a directory). For LDAP, you can not be guaranteed that the back end code has properly committed the data from the new record before you rewrite hostdata/current with the new record's address. This means that an LDAP server is not very reliable in a "kill -9 everything" situation (the topological equivalent of a power failure or a kernel panic). For high-availability services, such as a directory *must* be, by definition, this is not acceptable. The Windows 95 Registry "brute forces" this by rolling the data files over on each transaction. This is (effectively) a two stage commit, and is reliable because the defeat file caching (there are flags to the write command to get this behaviour from VFAT; Windoes 95 must use these flags itself to do swapping). So for right now, the Windows 95 Registry beats LDAP. You *could* do a specific back-end implementation of your own, and use container records. This would guarantee transactions would be committed. Better to add a "unsigned long transaction_id" to each LDAP command; if you pass a 0, then the commit is a single datum commit, and not transacted; however, if you pass a value obtained from a call to id = ldap_begin_transaction(); (guaranteed to not be the special placeholder 0), and then when you are done, call: ldap_commit_transaction( id); or ldap_abort_transaction( id); and pass this "sync" event to the back end, then you could encapsulate the two stage commit such that container objects were not necessary. Really, LDAP is not mature enough at this point, except for embedded systems where you can guarantee the behaviour of the back end, and the back end is either not write-cached, or understands the significance of container objects implicit by hierarchy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Dec 12 20:00:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA21416 for hackers-outgoing; Fri, 12 Dec 1997 20:00:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA21409 for ; Fri, 12 Dec 1997 20:00:21 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id OAA04361; Sat, 13 Dec 1997 14:30:03 +1030 (CST) (envelope-from grog) Message-ID: <19971213143003.28447@lemis.com> Date: Sat, 13 Dec 1997 14:30:03 +1030 From: Greg Lehey To: Robert Sanders Cc: hackers@FreeBSD.ORG Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels References: <19971212122752.36696@right.PCS> <199712121958.LAA26187@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Robert Sanders on Fri, Dec 12, 1997 at 05:08:34PM -0500 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Dec 12, 1997 at 05:08:34PM -0500, Robert Sanders wrote: > Archie Cobbs writes: > >>> On Dec 12, 1997 at 09:12:40AM -0800, Linus Torvalds wrote: >>>>> torvalds@transmeta.com (Linus Torvalds) wrote: >>>>>> >>>>>> If they are indeed still using that fix, they are a sorry lot of >>>>>> incompetent idiots. > >>>> Anyway, first I'd like to point out the "if .. indeed" clause of that >>>> part, just in case somebody missed it. > >> Oh come on everyone. No need to make a big deal out of it. >> Linus is a friendly guy and meant no harm. > > But if he did indeed mean to imply what many have inferred, then he is > an egomaniacal, conceited, rude bastard. And if that were the case, where would that put you? I think we've had enough nasty language and conditional insults already. Greg From owner-freebsd-hackers Fri Dec 12 20:03:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA21585 for hackers-outgoing; Fri, 12 Dec 1997 20:03:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA21580 for ; Fri, 12 Dec 1997 20:03:33 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id UAA20137; Fri, 12 Dec 1997 20:03:01 -0800 (PST) Message-ID: <19971212200300.57580@micron.mini.net> Date: Fri, 12 Dec 1997 20:03:00 -0800 From: Jonathan Mini To: Terry Lambert Cc: Jacques Vidrine , dnelson@emsphone.com, j_mini@efn.org, AdamT@smginc.com, jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Kernel Config datafile... Reply-To: Jonathan Mini References: <199712130006.SAA00398@kai.communique.net> <199712130041.RAA19766@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199712130041.RAA19766@usr04.primenet.com>; from Terry Lambert on Sat, Dec 13, 1997 at 12:41:12AM +0000 X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > Instead of reinventing Windows 3.1 .INI files, why down't we just > jump straight to reinventing the the Windows 95 registry? I'm looking for a long-term solution here. Once I write this, I don't want to have to touch it again forever. Perhaps we should follow what I said before and start talking about the STRUCTURE we want rather than the way we write it down in a file. Terry? I'd like one of those ten page documents about what we need here. :) > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Fri Dec 12 20:20:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22581 for hackers-outgoing; Fri, 12 Dec 1997 20:20:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22541 for ; Fri, 12 Dec 1997 20:19:55 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id UAA20160; Fri, 12 Dec 1997 20:19:20 -0800 (PST) Message-ID: <19971212201919.62962@micron.mini.net> Date: Fri, 12 Dec 1997 20:19:19 -0800 From: Jonathan Mini To: Mike Smith Cc: "Jordan K. Hubbard" , Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <25819.881832847@time.cdrom.com> <199712130121.LAA00751@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199712130121.LAA00751@word.smith.net.au>; from Mike Smith on Sat, Dec 13, 1997 at 11:51:07AM +1030 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith stands accused of saying: [ .. snip .. ] > > o The new configuration format should still be ASCII and editable > > by Mere Humans(tm), just in a format which is much more easily > > machine-parsed. > > Exactly. The issue is not in the format of the generated configuration > (which can easily remain *exactly* as it is right now), but in the > metaconfiguration information used by the config-generation tool. Yup. This could be generated from the 'metaconfiguration' database from any method, even a batch command. (important due to "make release") The GUI system is just for people who want it. :) > Once you have established the basic classes of configuration entities, > and the rules that link them together, you can codify these in just > about any format you like; text is good because CVS, emacs and vi all > like it. Yup. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five." From owner-freebsd-hackers Fri Dec 12 22:23:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA28981 for hackers-outgoing; Fri, 12 Dec 1997 22:23:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from baloon.mimi.com (sjx-ca124-26.ix.netcom.com [207.223.162.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA28969 for ; Fri, 12 Dec 1997 22:22:55 -0800 (PST) (envelope-from asami@sunrise.cs.berkeley.edu) Received: (from asami@localhost) by baloon.mimi.com (8.8.8/8.8.8) id WAA01218; Fri, 12 Dec 1997 22:22:39 -0800 (PST) (envelope-from asami) Date: Fri, 12 Dec 1997 22:22:39 -0800 (PST) Message-Id: <199712130622.WAA01218@baloon.mimi.com> To: rsanders@mindspring.net CC: hackers@freebsd.org In-reply-to: (message from Robert Sanders on 12 Dec 1997 17:08:34 -0500) Subject: Re: (fwd) Re: F00F bug *fixed* in 2.0.x kernels From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * From: Robert Sanders * > > On Dec 12, 1997 at 09:12:40AM -0800, Linus Torvalds wrote: * > > > Anyway, first I'd like to point out the "if .. indeed" clause of that * > > > part, just in case somebody missed it. * But if he did indeed mean to imply what many have inferred, then he is * an egomaniacal, conceited, rude bastard. (*ROTFL*) Satoshi From owner-freebsd-hackers Sat Dec 13 00:29:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA04657 for hackers-outgoing; Sat, 13 Dec 1997 00:29:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA04651 for ; Sat, 13 Dec 1997 00:28:53 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id SAA01759; Sat, 13 Dec 1997 18:53:18 +1030 (CST) Message-Id: <199712130823.SAA01759@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), jb@freebsd1.cimlogic.com.au, hackers@freebsd.org Subject: Re: Kernel Config datafile... In-reply-to: Your message of "Sat, 13 Dec 1997 03:21:54 -0000." <199712130321.UAA27603@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 18:53:17 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Apollo did it *much* better, and it's beginning to sound like LDAP will > > inherit the mantle. > > Not if it can't do transactions. ... > Really, LDAP is not mature enough at this point, except for embedded > systems where you can guarantee the behaviour of the back end, and > the back end is either not write-cached, or understands the > significance of container objects implicit by hierarchy. What you appear to be saying is that you cannot perform complex atomic transactions, nor are transactions guaranteed to be serialised. There, I did it in two lines. 8) mike From owner-freebsd-hackers Sat Dec 13 00:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05913 for hackers-outgoing; Sat, 13 Dec 1997 00:48:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05889 for ; Sat, 13 Dec 1997 00:48:02 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id CAA03544; Sat, 13 Dec 1997 02:00:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd003534; Sat Dec 13 02:00:19 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id BAA26476; Sat, 13 Dec 1997 01:47:23 -0700 (MST) From: Terry Lambert Message-Id: <199712130847.BAA26476@usr08.primenet.com> Subject: Re: Kernel Config datafile... To: mike@smith.net.au (Mike Smith) Date: Sat, 13 Dec 1997 08:47:23 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, jb@freebsd1.cimlogic.com.au, hackers@freebsd.org In-Reply-To: <199712130823.SAA01759@word.smith.net.au> from "Mike Smith" at Dec 13, 97 06:53:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Not if it can't do transactions. > ... > > Really, LDAP is not mature enough at this point, except for embedded > > systems where you can guarantee the behaviour of the back end, and > > the back end is either not write-cached, or understands the > > significance of container objects implicit by hierarchy. > > What you appear to be saying is that you cannot perform complex atomic > transactions, nor are transactions guaranteed to be serialised. > > There, I did it in two lines. 8) You miss the subtleties, though. You *can* do it, you just can't do it with all backend's for LDAP, nor can you do it without imposing overhead on the applications. You also left out that probably LDAP should have transactioning, but that even without it it, it's a good mechanism for name value pairs, better than FreeBSD flat file databases. And FreeBSD should probably go to LDAP for all native databases after taking the indicated precautions with the back end. 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 Sat Dec 13 00:54:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA06387 for hackers-outgoing; Sat, 13 Dec 1997 00:54:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA06375 for ; Sat, 13 Dec 1997 00:54:02 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA01888; Sat, 13 Dec 1997 19:18:37 +1030 (CST) Message-Id: <199712130848.TAA01888@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: bgingery@gtcs.com cc: hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Tue, 09 Dec 1997 15:09:42 PDT." <199712092209.PAA07923@home.gtcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 19:18:36 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I haven't noticed any commentary on this, Brian, so I thought I should raise a few points that you appear to have missed. > Theoretically, the physical layout of the device should be stored > whether or not there's any filesystem on it. This is a fundamentally flawed approach, and I am glad that Julian's new SLICE model (at this stage) completely ignores any incidental parametric information associated with an extent. > To me some answers to these ... > > 1. physical block/sector size needs to be stored by DEVICE > this may or may not match the logical blocksize of any > filesystem resident on the device. Optimal transfer blocksize > for each of read and write ALSO need to be stored. Physical blocksize vs. logical blocksize is a problematic issue. On one hand, there is the desire to maintain simplicity by mandating a single blocksize across all boundaries and forcing translation at the lowest practical level. The downside with this is dealing with legal logical block operations that result in partial block operations at the lowest level. One approach with plenty of historical precedent is to use a blocksize "sufficiently large" that it is a multiple of the likely device blocksizes, and make that the 'uniform standard'. Another is to cascade blocksizes upwards, where the blocksize at a given point in the tree is the lowest common multiple of that of all points below. This obviously requires some extra smarts in each layer that consumes multiple lower layers. > 2. physical layout (sect/track, tracks/cyl) also needs to > be stored for any DASD. Also any OTHER known info which > may be used to optimize the filesystem building process for > the device, such as rotational speed, seek timing .. If > this is not stored with driver info in the devfs, then > some pointer or common reference point should be made to > the "file entry" that contains the info. Physical layout is a joke, and has been for many years. This suggestion costs you a lot of credibility. Qualitative parametric information may be useful, eg. "this disk is slow", presuming that a set of usefully general metrics can be established. Unfortunately, obtaining measurements such as this can be slow, and the results are often nondeterministic. > 3. If at the controller level it is possible to concatinate > or RAID join devices, that information needs to be stored > for the device. If this is intrinsic to the device driver > or the physical device - no matter. This is not useful. An upper layer should not care whether the extent it is consuming is a concatenation of extents. This is an issue for management tools, which should have an OOB technique for recovering structure information. > 6. When a device is opened ro, if the underlying hardware has > ANY indication that it's a ro open, then if it is later upgraded > there should at least be a hook for it to be notified that it > has been upgraded. Current state (ro/rw) should be avaialable > to user processes without "testing it by opening a write file" > to a filesystem (or even raw device). The RO->RW upgrade notification is a contentious issue, but one that definitely needs thinking through. How would you suggest it be handled? Should the standard be to reopen the device, or pass a special ioctl, or add a new device entrypoint? > Other thoughts. Especially WRT possible experimental work, and > emulators, it will be QUITE convenient to have everything that can > be used to optimize the construction of a filesystem (of any of many > many kinds) or slice-out and construct a filesystem. As wine, dosemu > and bochs (to just name three) expand the emulations supporting other > OSs, being free with filesystems for those OSs, other than purely > "native" becomes all the more important. I can't actually parse this; I'm not sure if you're actually trying to say anything at all. > SoftPC/SoftWindows and Bochs both create internally what amounts to a > FAT filesystem within a file - a vnode filesystem, but not using > system provisions for it. That pretty well eliminates "device" access > to the filesystem and (e.g.) doing a mount_msdos on 'em for other > processing and data exchange, without adapting the emulator's code > to *parallel* what we've already got with FreeBSD. Incorrect. It is relatively straightforward to create a vnode disk, slice it, build a FAT filesystem in one slice and then pass that slice to your favorite PC emulator. > Yet, why deny these the optimization information which will allow > them to map (within the constraints of their architecture) a new > filesystem for best throughput, if it's actually available. Because any "optimisation information" that you could pass them would be wrong. Any optimisation attempting to operate based on incorrect parameters can only be a pessimisation. > Now let me raise some additional questions -- > > > Should a DASD be mappable ONLY with horizontal slices? > With what we're all doing today, it seems that taking a certain > number of cylinders for slices is best - but other access methods > may find an underlying physical structure more convenient if > a slice specifies a range of heads and cylinders that do NOT > presume that all heads/cylinders from starting to ending according > to physical layout are part of the same slice. It may be quite > convenient to have a cluster of heads across physical devices > forming a logical device or slice, without fully dedicating those > physical devices to that use. This is a nonsense question in the context of ZBR and "logical extent" devices (eg. SCSI, ATAPI, most ATA devices). > And, I'll mention again, DISK formats are not the only > random-access mass-storage formats on the horizon! I'm guessing > that for speed of inclusion into product lines, all will emulate > a disk drive - but that may not be the most efficient way of using > them (in fact, probably not). They also can be expected to have > "direct access" methods according to their physical architecture, > with some form of tree-access the MOST efficient! In most cases, the internal architecture of the device will be optimised for two basic operations; retrieval of large contiguous extents, and read/write of small randomly scattered regions. Data access patterns are unlikely to change radically, particularly given the momentum that modern systems have. I'll let you work out what the two above are, and why they are so common. But trust me, they are. > Finally - one of the most powerful potentials of the devfs is > handling non-DASD devices! The connecting or turning-on of a device > (nic/fax/printer/external-modem/scanner/parallel-to-parallel conn- > ection to another PC, even industrial controls of some kind) SHOULD > cause it to "arrive". If its turn-on generates a signal that can be > caught by a minimal driver, that may trigger a load of a full driver > (arrival event) and its inclusion in the devfs listings. Similarly, > killing such a device might trigger an immediate or delayed unloading > of the same driver, and removal from the devfs. This is trivially obvious, and forms the basic argument for the use of DEVFS. You fail to draw the parallel between system startup and the conceptual "massive arrival of devices" which is still the major argument for such a system. mike From owner-freebsd-hackers Sat Dec 13 01:10:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA07332 for hackers-outgoing; Sat, 13 Dec 1997 01:10:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA07320 for ; Sat, 13 Dec 1997 01:10:31 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA01918; Sat, 13 Dec 1997 19:25:20 +1030 (CST) Message-Id: <199712130855.TAA01918@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: damian@cablenet.net, jb@freebsd1.cimlogic.com.au, hackers@freebsd.org Subject: Distributed configuration management (was Re: Kernel Config datafile... ) In-reply-to: Your message of "Sat, 13 Dec 1997 08:47:23 -0000." <199712130847.BAA26476@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 19:25:20 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Damian, if you are not subscribed to -hackers, please forgive me for pulling you into this. Jordan forwarded your libdefaults/libconfig proposal and I have been thinking long and hard about the matter (it being one of considerable interest to me). I'd really like to hear your thoughts about taking your model one level further and using a distributed database (eg. LDAP or perhaps NDS if Novell are still being "free" with it) for the backend parameter store... > > > Really, LDAP is not mature enough at this point, except for embedded > > > systems where you can guarantee the behaviour of the back end, and > > > the back end is either not write-cached, or understands the > > > significance of container objects implicit by hierarchy. > > > > What you appear to be saying is that you cannot perform complex atomic > > transactions, nor are transactions guaranteed to be serialised. > > > > There, I did it in two lines. 8) > > You miss the subtleties, though. > > You *can* do it, you just can't do it with all backend's for LDAP, > nor can you do it without imposing overhead on the applications. If it can't be done universally, or isn't part of the protocol, I'd buy "it can't be done" as a fair generalisation. > You also left out that probably LDAP should have transactioning, > but that even without it it, it's a good mechanism for name value > pairs, better than FreeBSD flat file databases. Sure. At the moment we have no serialisation nor complex atomic transactions. > And FreeBSD should probably go to LDAP for all native databases after > taking the indicated precautions with the back end. If I read you correctly, this could be buried in a library of LDAP-using configuration functions. The other issue at that point becomes maintaining the "legacy" configuration files in order to avoid violation of POLA. mike From owner-freebsd-hackers Sat Dec 13 01:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08604 for hackers-outgoing; Sat, 13 Dec 1997 01:34:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08580 for ; Sat, 13 Dec 1997 01:34:39 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id TAA02140; Sat, 13 Dec 1997 19:59:18 +1030 (CST) Message-Id: <199712130929.TAA02140@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Smith cc: bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Sat, 13 Dec 1997 19:18:36 +1030." <199712130848.TAA01888@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 19:59:17 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Replying to myself. *sigh* It's the hair on my palms, I swear. > > 3. If at the controller level it is possible to concatinate > > or RAID join devices, that information needs to be stored > > for the device. If this is intrinsic to the device driver > > or the physical device - no matter. > > This is not useful. An upper layer should not care whether the extent > it is consuming is a concatenation of extents. This is an issue for > management tools, which should have an OOB technique for recovering > structure information. Of course, this is not true in anything other than the naive case. An upper layer may well want to take advantage of, or precautions in light of, the construction of the extent(s) with which it is presented. Sorry about that. mike From owner-freebsd-hackers Sat Dec 13 01:49:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09298 for hackers-outgoing; Sat, 13 Dec 1997 01:49:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dcn.soongsil.ac.kr ([203.253.2.104]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA09291 for ; Sat, 13 Dec 1997 01:49:45 -0800 (PST) (envelope-from skylee@dcn.soongsil.ac.kr) Received: from DCN2.soongsil.ac.kr ([203.253.3.89]) by dcn.soongsil.ac.kr (8.6.9H1/8.9.11h) with SMTP id SAA27051 for ; Sat, 13 Dec 1997 18:53:41 +0900 Message-Id: <3.0.1.32.19971213185000.00797e20@dcn.soongsil.ac.kr> X-Sender: skylee@dcn.soongsil.ac.kr (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 13 Dec 1997 18:50:00 +0900 To: freebsd-hackers@freebsd.org From: SangKyo LEE Subject: question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello I'm a testing fot sending video streams via rsvp. But I have some problem. I run vic-2.8 on freebsd and run into the problem with vic not able to work When make the makefile, it has error. after run sdr, sdr's monitor displays only black. If you know why happen, pls tell me. Thank you... From owner-freebsd-hackers Sat Dec 13 03:06:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA13978 for hackers-outgoing; Sat, 13 Dec 1997 03:06:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from home.gtcs.com (home.gtcs.com [206.54.69.238]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA13964 for ; Sat, 13 Dec 1997 03:06:11 -0800 (PST) (envelope-from bruce@gtcs.com) Received: from gtcs.com (localhost.gtcs.com [127.0.0.1]) by home.gtcs.com (8.8.5/8.8.5) with ESMTP id EAA20340; Sat, 13 Dec 1997 04:02:11 -0700 (MST) Disposition-Notification-To: bgingery@gtcs.com X-Comment1: in most cases both the Return-Receipt and Delivery-Notification X-Comment2: requests are part of an ongoing poll to determine what clients X-Comment3: and MTAs respond to the headers. Message-Id: <199712131102.EAA20340@home.gtcs.com> Date: Sat, 13 Dec 1997 04:02:08 -0700 (MST) From: bgingery@gtcs.com Reply-To: bgingery@gtcs.com Subject: Re: blocksize on devfs entries (and related) To: mike@smith.net.au cc: hackers@FreeBSD.ORG In-Reply-To: <199712130848.TAA01888@word.smith.net.au> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 13 Dec, Mike Smith wrote: [munch] -} > 2. physical layout (sect/track, tracks/cyl) also needs to -} > be stored for any DASD. Also any OTHER known info which -} > may be used to optimize the filesystem building process for -} > the device, such as rotational speed, seek timing .. If -} > this is not stored with driver info in the devfs, then -} > some pointer or common reference point should be made to -} > the "file entry" that contains the info. -} -} Physical layout is a joke, and has been for many years. This -} suggestion costs you a lot of credibility. Physical layout *is* a joke for devices that do their own controller mapping. Yet I have yet to see anything cast in silicon that never needs any rework nor possibility of innovation. Whenever we throw away information, it's gone - PERIOD, unless it's stored *somewhere*. Now, the physical layout is (at least theoretically) pollable for some devices. What I'm saying is don't throw away the POSSIBILITY of storing and using this information in an orderly way. Call it "cost of credibility" if you will, and point to me as an anachronism if you wish to flame. The "Maintenance Free" automotive battery and the "never-LLF IDE drive" still have a lot in common - and both could have been produced by a certain company I'd choose not to mention by name, as it's marketing hype consistently does NOT match reality. I've already suffered some drivers that PRESUME the rotational speed and then optimize a filesystem for that supposed rotational vs bus speed, with a resulting significant decrease in performance from a bad interleave. I don't have any problem whatsoever in extrapolating that to a loss of traditional disktab ns,nt,nc,sc,su, sk, cs, hs, and il values for even POTENTIAL use. To me it's no wiser than ignoring (or eliminating) the rm value. NO DISKTAB INTEGRATION WITH DEVFS? Perhaps they don't belong in devfs stored values. Yet these values are DEVICE dependent, not filesystem dependent, hence I raised the question. When re-inventing device handling, it's wise, perhaps, to not ignore portions of it, even if the answer is "leave that part alone". [munch] -} > 3. If at the controller level it is possible to concatinate -} > or RAID join devices, that information needs to be stored -} > for the device. If this is intrinsic to the device driver -} > or the physical device - no matter. [followed up with] -} An upper layer may well want to take advantage of, or precautions in -} light of, the construction of the extent(s) with which it is presented. -} > 6. When a device is opened ro, if the underlying hardware has -} > ANY indication that it's a ro open, then if it is later upgraded -} > there should at least be a hook for it to be notified that it -} > has been upgraded. Current state (ro/rw) should be avaialable -} > to user processes without "testing it by opening a write file" -} > to a filesystem (or even raw device). -} -} The RO->RW upgrade notification is a contentious issue, but one that -} definitely needs thinking through. How would you suggest it be -} handled? Should the standard be to reopen the device, or pass a -} special ioctl, or add a new device entrypoint? To me, an IOCTL and flag would be tighter than different entry points for ro vs rw. Not necessarily tighter code, but tighter management. [munch poorly stated description and accurate answer Re: vnode fs] -} > Yet, why deny these the optimization information which will allow -} > them to map (within the constraints of their architecture) a new -} > filesystem for best throughput, if it's actually available. -} -} Because any "optimisation information" that you could pass them would -} be wrong. Any optimisation attempting to operate based on incorrect -} parameters can only be a pessimisation. Why must it be wrong? -} > Now let me raise some additional questions -- -} > -} > -} > Should a DASD be mappable ONLY with horizontal slices? -} > With what we're all doing today, it seems that taking a certain -} > number of cylinders for slices is best - but other access methods -} > may find an underlying physical structure more convenient if -} > a slice specifies a range of heads and cylinders that do NOT -} > presume that all heads/cylinders from starting to ending according -} > to physical layout are part of the same slice. It may be quite -} > convenient to have a cluster of heads across physical devices -} > forming a logical device or slice, without fully dedicating those -} > physical devices to that use. -} -} This is a nonsense question in the context of ZBR and "logical extent" -} devices (eg. SCSI, ATAPI, most ATA devices). Okay, but not those which expose that info and allow direct control. Across the Free *n?x lines we're seeing more and more antique resurrections - even if that's the ONLY place this could be used accurately. -} -} > And, I'll mention again, DISK formats are not the only -} > random-access mass-storage formats on the horizon! I'm guessing -} > that for speed of inclusion into product lines, all will emulate -} > a disk drive - but that may not be the most efficient way of using -} > them (in fact, probably not). They also can be expected to have -} > "direct access" methods according to their physical architecture, -} > with some form of tree-access the MOST efficient! -} -} In most cases, the internal architecture of the device will be -} optimised for two basic operations; retrieval of large contiguous -} extents, and read/write of small randomly scattered regions. -} -} Data access patterns are unlikely to change radically, particularly -} given the momentum that modern systems have. I'll let you work out -} what the two above are, and why they are so common. But trust me, they -} are. Oh, you needn't point out the obvious. I'm not talking about that. I'm talking about handling more and more-varied informational content and relationships, AND the potential of non-magnetic, optical DASD devices, whether they're raw stabilized gel or impregnated porous glass - both of which are on the horizon; the former in the US, and (I understand, partially by reading between the lines), the latter in Israel. Raw storage capacity with approximately chip density (speaking of 3-d space taken) is too big a leap to stay out of the reach of "Free *n?x using users". Except for "delay lines", silicon-based domain-migration technology hasn't proven very useful, yet it set some thinking going which SHOULD prove useful in optical solid state memories. Just because you see "Data access patterns .. unlikely to change radically" doesn't mean that we won't see it happening. Of course we're going to keep those two traditional data transfer modes. I'm pointing out that just those TWO such modes aren't the all-to-end- all, especially when we start eliminating rotational and seek delays from devices used for the same purpose. Bruce Gingery From owner-freebsd-hackers Sat Dec 13 03:10:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA14266 for hackers-outgoing; Sat, 13 Dec 1997 03:10:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA14260 for ; Sat, 13 Dec 1997 03:10:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id DAA25872; Sat, 13 Dec 1997 03:08:10 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd025868; Sat Dec 13 03:08:05 1997 Date: Sat, 13 Dec 1997 03:05:27 -0800 (PST) From: Julian Elischer To: Mike Smith cc: bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-Reply-To: <199712130848.TAA01888@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Dec 1997, Mike Smith wrote: > > I haven't noticed any commentary on this, Brian, so I thought I should > raise a few points that you appear to have missed. > > > Theoretically, the physical layout of the device should be stored > > whether or not there's any filesystem on it. The problem is that on all new devices the layout is both hidden and not easily describable. Nor can we describe the layouts of media that have not yet been invented. Track/cyl/sector geometry descriptions can not be used to describe modern disks and the picture is muddied by track buffers and reverse block write order (for example). > > This is a fundamentally flawed approach, and I am glad that Julian's > new SLICE model (at this stage) completely ignores any incidental > parametric information associated with an extent. > > > To me some answers to these ... > > > > 1. physical block/sector size needs to be stored by DEVICE > > this may or may not match the logical blocksize of any > > filesystem resident on the device. Optimal transfer blocksize > > for each of read and write ALSO need to be stored. > > Physical blocksize vs. logical blocksize is a problematic issue. On > one hand, there is the desire to maintain simplicity by mandating a > single blocksize across all boundaries and forcing translation at the > lowest practical level. The downside with this is dealing with legal > logical block operations that result in partial block operations at the > lowest level. > In my slice code I propogate blocksize up. Each layer can make the decision as to what blocksize it wishes to export further up. A disk array would probably export a blocksize equal to the largest blocksize of it's component parts. I might also propogate up a maximum acceptible chunk, and an optimal one, but how to interpolate these at higher layers becomes non-solvable without breaking layering. (or by preceding every IO call with a callthat asks "If I were to do IO to location X how big would you like it to be?") This is not an answer. > One approach with plenty of historical precedent is to use a blocksize > "sufficiently large" that it is a multiple of the likely device > blocksizes, and make that the 'uniform standard'. Another is to > cascade blocksizes upwards, where the blocksize at a given point in the > tree is the lowest common multiple of that of all points below. This > obviously requires some extra smarts in each layer that consumes > multiple lower layers. That's what I'm expecting to do (but have not yet done as I have not yet written a multiplexing handler) > > > 2. physical layout (sect/track, tracks/cyl) also needs to > > be stored for any DASD. Also any OTHER known info which > > may be used to optimize the filesystem building process for > > the device, such as rotational speed, seek timing .. If > > this is not stored with driver info in the devfs, then > > some pointer or common reference point should be made to > > the "file entry" that contains the info. > > Physical layout is a joke, and has been for many years. This > suggestion costs you a lot of credibility. Some of this information will be available by asking for a disklabel struct from any slice. fields such as RPM will be propogated up from the device(s) if possible where fields such as drive size are reflections of that particular slice. > > Qualitative parametric information may be useful, eg. "this disk is > slow", presuming that a set of usefully general metrics can be > established. Unfortunately, obtaining measurements such as this can be > slow, and the results are often nondeterministic. In the face of confusion, do nothing.. I will probably punt on must of the complicated issues, believing that the drive manufacturers will just do the best they can :) > > > 3. If at the controller level it is possible to concatinate > > or RAID join devices, that information needs to be stored > > for the device. If this is intrinsic to the device driver > > or the physical device - no matter. > > This is not useful. An upper layer should not care whether the extent > it is consuming is a concatenation of extents. This is an issue for > management tools, which should have an OOB technique for recovering > structure information. As Mike says, The whole aim of the slice layers and related things is to HIDE this.. In earlier email you indicated that you thought I should make nodes in the devfs, in parallel to the device nodes, that DESCRIBED the devices.. e.g. /dev/raid0.description migh appear to be a file that says "An array of 5 drives, each of 12.5GB" I'm not sure if I understood this correctly, but I think that when you say 'stored with' I believe this may be what you mean. If so then my answer is "nice but no dice". device information will probably not be retrieved in this manner, however I have not thought it through fully either. > > > 6. When a device is opened ro, if the underlying hardware has > > ANY indication that it's a ro open, then if it is later upgraded > > there should at least be a hook for it to be notified that it > > has been upgraded. Current state (ro/rw) should be avaialable > > to user processes without "testing it by opening a write file" > > to a filesystem (or even raw device). > > The RO->RW upgrade notification is a contentious issue, but one that > definitely needs thinking through. How would you suggest it be > handled? Should the standard be to reopen the device, or pass a > special ioctl, or add a new device entrypoint? r/w 'openness' is and should be propogated up and down. I've already started work on this. The difficult bit is not in the SLICE code, but rather in teh existing system code that doesn't notify the slice code when this happens. > > > Other thoughts. Especially WRT possible experimental work, and > > emulators, it will be QUITE convenient to have everything that can > > be used to optimize the construction of a filesystem (of any of many > > many kinds) or slice-out and construct a filesystem. As wine, dosemu > > and bochs (to just name three) expand the emulations supporting other > > OSs, being free with filesystems for those OSs, other than purely > > "native" becomes all the more important. > > I can't actually parse this; I'm not sure if you're actually trying to > say anything at all. I THINK he is saying he wants to be able to partition files as devices. We can already do this with vn devices. And my SLICE code supports them fully. > > > SoftPC/SoftWindows and Bochs both create internally what amounts to a > > FAT filesystem within a file - a vnode filesystem, but not using > > system provisions for it. That pretty well eliminates "device" access > > to the filesystem and (e.g.) doing a mount_msdos on 'em for other > > processing and data exchange, without adapting the emulator's code > > to *parallel* what we've already got with FreeBSD. > > Incorrect. It is relatively straightforward to create a vnode disk, > slice it, build a FAT filesystem in one slice and then pass that slice > to your favorite PC emulator. > > > Yet, why deny these the optimization information which will allow > > them to map (within the constraints of their architecture) a new > > filesystem for best throughput, if it's actually available. > > Because any "optimisation information" that you could pass them would > be wrong. Any optimisation attempting to operate based on incorrect > parameters can only be a pessimisation. > A file being exported as a device to an emulator would have acces charateristics that are dependant on it's stored allocations. This wold be almost impossible to pass back to an emulator. > > Now let me raise some additional questions -- > > > > > > Should a DASD be mappable ONLY with horizontal slices? > > With what we're all doing today, it seems that taking a certain > > number of cylinders for slices is best - but other access methods > > may find an underlying physical structure more convenient if > > a slice specifies a range of heads and cylinders that do NOT > > presume that all heads/cylinders from starting to ending according > > to physical layout are part of the same slice. It may be quite > > convenient to have a cluster of heads across physical devices > > forming a logical device or slice, without fully dedicating those > > physical devices to that use. > what you are describing is possible, but would behave badly with respect to locality of reference. > This is a nonsense question in the context of ZBR and "logical extent" > devices (eg. SCSI, ATAPI, most ATA devices). The language is a bit harsh, but the idea is correct.. We cannot try outguess how the manufacturers have layed out the disk. It's not easily describable, an in the case of block reallocation, possibly not even constant with time. > > > And, I'll mention again, DISK formats are not the only > > random-access mass-storage formats on the horizon! I'm guessing > > that for speed of inclusion into product lines, all will emulate > > a disk drive - but that may not be the most efficient way of using > > them (in fact, probably not). They also can be expected to have > > "direct access" methods according to their physical architecture, > > with some form of tree-access the MOST efficient! > Most new access methods will either: 1/ be totally random access .... (we get no gain from using geometry) 2/ emulate a disk, (using the apparent geometry may be wrong pessimal in the face of teh underlying REAL geometry) 3/ have a differnt geometry charateristic that we cannot try guess ahead of time. > In most cases, the internal architecture of the device will be > optimised for two basic operations; retrieval of large contiguous > extents, and read/write of small randomly scattered regions. > > Data access patterns are unlikely to change radically, particularly > given the momentum that modern systems have. I'll let you work out > what the two above are, and why they are so common. But trust me, they > are. Manufacturers will be making devices to be optimised to do what we want to do. so for us to try do something different may even slow things down. B> > > Finally - one of the most powerful potentials of the devfs is > > handling non-DASD devices! The connecting or turning-on of a device > > (nic/fax/printer/external-modem/scanner/parallel-to-parallel conn- > > ection to another PC, even industrial controls of some kind) SHOULD > > cause it to "arrive". If its turn-on generates a signal that can be > > caught by a minimal driver, that may trigger a load of a full driver > > (arrival event) and its inclusion in the devfs listings. Similarly, > > killing such a device might trigger an immediate or delayed unloading > > of the same driver, and removal from the devfs. > DEVFS is PRIMARILY for non DASD devices.. I have only added the DASD support in the last month. > This is trivially obvious, and forms the basic argument for the use of > DEVFS. You fail to draw the parallel between system startup and the > conceptual "massive arrival of devices" which is still the major > argument for such a system. > > mike > Startup is as Mike says, just a special case of the more general "A device has appeared" case. If we can get this to be true for all teh drivers, then a truely dynamic FreeBSD will be a lot closer.. so far I have participated in the following steps towards this: [A] making devsw[] and array of pointers and making each driver add it's own entry at the time that it is initialised. [B] Adding an initialisation routine to every driver called by SYSINIT (eventually this same routine should be also called by the LKM init code, which is why some drivers have init routines even though they strictly don't need them. This is thinking ahead.. eventually the LKM code will do: call init, for each possible such device call probe call attach OR call init ask all busses (e.g. pci) if they have any of these, and if found, call the attach routine by structuring the device drivers this way now we are trying to make the transition easier. [C] adding DEVFS so that arriving devices become visible to the user [D] adding SLICE code to cope with arriving DASD partitions. [E] writing a generic SCSI system to allow scsi devices to be attached indepedently of the adapter type [F] getting the BIOS boot code going so that booting is independent of device types [G] added at_fork(), at_shutdown() at_exit() facilities to allow kernel LKM modules to be notified of these events I'm sure I've forgotten some, but you must see a pattern here. Over the last 5 years I've been constantly working towards a more modular and dynamic freeBSD. Many of the things I have added are not really fully appreciated yet, but will become so as soon as more pieces of the jigsaw are completed. AS for teh SLICE an dDEVFS code.. most of the comments so far are "so, what's differnt" the system seems to be exactly as before.. (Which of course is exactly what I want) The outwards appearance of no change, but an internal complete rebuild to be more modular. future goals include: complete removal of major numbers complete removal of the dev_t type from FreeBSD At least as we know it. it may be replaced by a "device reference" of another type. julian > > From owner-freebsd-hackers Sat Dec 13 03:26:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA14825 for hackers-outgoing; Sat, 13 Dec 1997 03:26:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA14818 for ; Sat, 13 Dec 1997 03:26:45 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id VAA02610; Sat, 13 Dec 1997 21:51:26 +1030 (CST) Message-Id: <199712131121.VAA02610@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: bgingery@gtcs.com cc: hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Sat, 13 Dec 1997 04:02:08 PDT." <199712131102.EAA20340@home.gtcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 21:51:26 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Now, the physical layout is (at least theoretically) pollable for > some devices. What I'm saying is don't throw away the POSSIBILITY > of storing and using this information in an orderly way. I'm quite happy with the concept of passing some information up, but very cagey about what is actually useful. Physical layout is almost useless in that there is no useful standard for its presentation, and no easy method for making it consistently available. Consider an example; we have a filesystem that wants to optimise its on-disk layout to take advantage of the physical parameters of the disk on which its filesystem lives. How will it lose, let me count the ways... - You can't extract meaningful disk geometry data from a ZBR disk. - You can't devise a measurement process to determine various basic timing parameters of a modern disk as these are nondeterministic. - If the filesystem is presented with a synthetic extent spanning several different disk devices, which set of nonexistent parameters would you be supplying to the filesystem? Just three off the top of my head. There are probably more. As I said, there are some basic qualitative parameters that you could attach to an extent. You would have to supply a "combination" function that would produce a single value out given a set of values in (for producing a summary value for a synthetic extent), and possibly a "separation" function (for producing a single value for a region of an extent). This sounds like a great deal of work for what currently appears to be a pretty mythical benefit. 8) > -} The RO->RW upgrade notification is a contentious issue, but one that > -} definitely needs thinking through. How would you suggest it be > -} handled? Should the standard be to reopen the device, or pass a > -} special ioctl, or add a new device entrypoint? > > To me, an IOCTL and flag would be tighter than different entry > points for ro vs rw. Not necessarily tighter code, but tighter > management. How would you reject the ioctl? (FWIW, I am inclined to agree that overloading the ioctl interface is the "best" approach here, if not the most architecturally clean.) Bear in mind that an unknown ioctl will usually return ENOTTY or similar; you would have to specify an explicit return value for rejected upgrades. > -} > Yet, why deny these the optimization information which will allow > -} > them to map (within the constraints of their architecture) a new > -} > filesystem for best throughput, if it's actually available. > -} > -} Because any "optimisation information" that you could pass them would > -} be wrong. Any optimisation attempting to operate based on incorrect > -} parameters can only be a pessimisation. > > Why must it be wrong? Because it cannot be guaranteed to be correct if it is present. I tell you that one glass contains deadly iocaine powder, and the other does not, and you drink from the latter. Then I tell you that both are poisoned. Your optimisation for life has failed, despite making the correct choice based on the available facts. > -} > Now let me raise some additional questions -- > -} > > -} > > -} > Should a DASD be mappable ONLY with horizontal slices? ... > -} This is a nonsense question in the context of ZBR and "logical extent" > -} devices (eg. SCSI, ATAPI, most ATA devices). > > Okay, but not those which expose that info and allow direct > control. Across the Free *n?x lines we're seeing more and more > antique resurrections - even if that's the ONLY place this could > be used accurately. As the owner of a not inconsiderable number of such antiques, I can tell you that non-ZBR devices are in an extreme minority, and those that haven't yet bitten the dust are well on their way. In the case of a new model design, attempting support for a microscopically small and ever-shrinking portion of the potential platform base given the relative costs involved is just not practical. mike From owner-freebsd-hackers Sat Dec 13 03:40:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA17270 for hackers-outgoing; Sat, 13 Dec 1997 03:40:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from home.gtcs.com (home.gtcs.com [206.54.69.238]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA17265 for ; Sat, 13 Dec 1997 03:40:32 -0800 (PST) (envelope-from bruce@gtcs.com) Received: from gtcs.com (localhost.gtcs.com [127.0.0.1]) by home.gtcs.com (8.8.5/8.8.5) with ESMTP id EAA20537; Sat, 13 Dec 1997 04:36:27 -0700 (MST) Disposition-Notification-To: bgingery@gtcs.com X-Comment1: in most cases both the Return-Receipt and Delivery-Notification X-Comment2: requests are part of an ongoing poll to determine what clients X-Comment3: and MTAs respond to the headers. Message-Id: <199712131136.EAA20537@home.gtcs.com> Date: Sat, 13 Dec 1997 04:36:24 -0700 (MST) From: bgingery@gtcs.com Reply-To: bgingery@gtcs.com Subject: Re: blocksize on devfs entries (and related) To: julian@whistle.com cc: mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 13 Dec, Julian Elischer wrote: -} On Sat, 13 Dec 1997, Mike Smith wrote: [mucho muncho] -} Most new access methods will either: -} 1/ be totally random access .... (we get no gain from using geometry) -} 2/ emulate a disk, (using the apparent geometry may be wrong pessimal -} in the face of teh underlying REAL geometry) -} 3/ have a differnt geometry charateristic that we cannot try guess ahead -} of time. Yes. I may be mentioning things that have no immediate effect here. Yet, I mention it just in case it MIGHT affect designs in such a way that it reduces the work for future adaptation. The last I heard about gel memory was well over a year ago, and I also have seen no updates on the impregnated porous glass. BOTH would seem to be optical and involve 3-d addressing at the substrate level. What controllers are placed above that - most likely a "disk emulation" as the LEAST efficient, but quickest to use. If an XYZ coordinate system *could* be stored for maxvalues as if it were blk/trk trk/cyl and ncyl, then if those storage positions are available, they could be overloaded. [munch history] -} -} I'm sure I've forgotten some, but you must see a pattern here. Over the -} last 5 years I've been constantly working towards a more modular and -} dynamic freeBSD. Many of the things I have added are not really fully -} appreciated yet, but will become so as soon as more pieces of the jigsaw -} are completed. If you're using "appreciated" in terms of people's attitudes, you've got my vote! At Sat, 13 Dec 1997 21:51:26 +1030 (CST) Mike Smith followed up (in part): [Re: using IOCTL to notify drivers of change between ro/rw] -} How would you reject the ioctl? (FWIW, I am inclined to agree that -} overloading the ioctl interface is the "best" approach here, if not the -} most architecturally clean.) Bear in mind that an unknown ioctl will -} usually return ENOTTY or similar; you would have to specify an explicit -} return value for rejected upgrades. Yes, ENOTTY or similar if it doesn't apply, and EINVAL if the an underlying device refuses it. That would agree with at least three uses of EINVAL. Bruce Gingery From owner-freebsd-hackers Sat Dec 13 03:44:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA17479 for hackers-outgoing; Sat, 13 Dec 1997 03:44:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA17466 for ; Sat, 13 Dec 1997 03:44:14 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id WAA02658; Sat, 13 Dec 1997 22:08:42 +1030 (CST) Message-Id: <199712131138.WAA02658@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: Mike Smith , bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Sat, 13 Dec 1997 03:05:27 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 22:08:40 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > In my slice code I propogate blocksize up. Each layer can make the > decision as to what blocksize it wishes to export further up. A disk array > would probably export a blocksize equal to the largest blocksize of it's > component parts. Just checking the obvious; the blocksize of potential components is available to the layer(s) above at attach time, so that they can reject them at that point? > I might also propogate up a maximum acceptible chunk, and an optimal one, > but how to interpolate these at higher layers becomes non-solvable without > breaking layering. (or by preceding every IO call with a callthat asks > "If I were to do IO to location X how big would you like it to be?") > This is not an answer. No. I was considering a proposal whereby a layer could not propagate upwards a blocksize less than the largest of its inferiors, but that's clearly pointless. The idea of passing a "recommended chunk size" up would be good though; a multiplexing layer could use that to break requests from above up into optimal chunks for layers below. Likewise the maximal chunk number. > > > 2. physical layout (sect/track, tracks/cyl) also needs to > > > be stored for any DASD. Also any OTHER known info which > > > may be used to optimize the filesystem building process for > > > the device, such as rotational speed, seek timing .. If > > > this is not stored with driver info in the devfs, then > > > some pointer or common reference point should be made to > > > the "file entry" that contains the info. > > > > Physical layout is a joke, and has been for many years. This > > suggestion costs you a lot of credibility. > > Some of this information will be available by asking for a disklabel > struct from any slice. > fields such as RPM will be propogated up from the device(s) if possible > where fields such as drive size are reflections of that particular slice. Can I perhaps argue for the rapid death of the disklabel structure (other than in a hypothetical compatability layer)? It's an obscenity that's long overdue for death. I've fought the "fake a disklabel that's acceptable to all consumers" battle several times (losing more often than winning), and seeing it go forever would be Very Pleasant. Yes, I realise that it's cast in domains on disk, and perhaps unlikely to change there, I just ask that it be abandoned as a means of describing the characteristics of a disk (extent) and the (conceptually indirectly related) set of partitions contained in that extent. > > This is not useful. An upper layer should not care whether the extent > > it is consuming is a concatenation of extents. This is an issue for > > management tools, which should have an OOB technique for recovering > > structure information. > As Mike says, The whole aim of the slice layers and related things is to > HIDE this.. In earlier email you indicated that you thought I should make > nodes in the devfs, in parallel to the device nodes, that DESCRIBED > the devices.. Are you referring to me or Brian? We discussed this at one stage, but I think the consensus was that the correct approach was for anything that was interested in the construction of an extent to traverse the extent's inferiors working it out for itself. I'm aggro; my test box is at work, and I'm waiting for a call to go to a party. I wanna be playing with this stuff now the IDE code should be working. 8) Now, if someone could write an NCR driver for the CAM code... mike From owner-freebsd-hackers Sat Dec 13 04:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA21332 for hackers-outgoing; Sat, 13 Dec 1997 04:54:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [194.93.177.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA21288; Sat, 13 Dec 1997 04:53:26 -0800 (PST) (envelope-from ru@relay.ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.8.8/8.8.8) id OAA28958; Sat, 13 Dec 1997 14:52:56 +0200 (EET) (envelope-from ru) From: Ruslan Ermilov Message-Id: <199712131252.OAA28958@relay.ucb.crimea.ua> Subject: IP Tunneling for FreeBSD is available To: hackers@FreeBSD.ORG, announce@FreeBSD.ORG Date: Sat, 13 Dec 1997 14:52:56 +0200 (EET) X-My-Interests: Unix,Oracle,Networking X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! http://www.ucb.crimea.ua/~ru/FreeBSD/iptunnel This program provides IP tunneling facility for use with divert sockets under FreeBSD. It is passed raw IP packets as they travel into and out of the machine, and will send these to the remote host through UDP where they re-injected back into the IP packet stream. -- Ruslan A. Ermilov System Administrator ru@ucb.crimea.ua United Commercial Bank +380-652-247647 Simferopol, Crimea 2426679 ICQ Network, UIN From owner-freebsd-hackers Sat Dec 13 05:47:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA23860 for hackers-outgoing; Sat, 13 Dec 1997 05:47:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA23848 for ; Sat, 13 Dec 1997 05:47:02 -0800 (PST) (envelope-from rmoose@gateway.mitre.org) Received: from poisson.mitre.org (poisson.mitre.org [128.29.31.188]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id IAA07724; Sat, 13 Dec 1997 08:46:26 -0500 (EST) Received: (from rmoose@localhost) by poisson.mitre.org (8.7.2/8.7.2) id IAA17755; Sat, 13 Dec 1997 08:47:35 -0500 (EST) Date: Sat, 13 Dec 1997 08:47:34 -0500 (EST) From: Robert Moose Reply-To: rmoose@gateway.mitre.org To: SangKyo LEE cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question In-Reply-To: <3.0.1.32.19971213185000.00797e20@dcn.soongsil.ac.kr> Message-ID: X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm a testing fot sending video streams via rsvp. But I have some problem. > > I run vic-2.8 on freebsd and run into the problem with vic not able to work > When make the makefile, it has error. > after run sdr, sdr's monitor displays only black. > > If you know why happen, pls tell me. Yes, we're running it + sdr + vat. I do recall having a problem compiling the rsvp-enabled vic that came with the rsvp distribution (rel4.2a1) from ISI. I believe we found the fix on one of the FreeBSD mailing list archives. It was (I apologize for not being able to acknowledge the person who originally posted this): After you do your ./config, in the Makefile change STATIC = -static to STATIC = -lc (or some equivalent change). I believe this problem + fix originally arose in the context of the non-rsvp vic-2.8. I assume you already have tk4.1 and tcl7.5 installed. Bob MITRE Washington Networking Center From owner-freebsd-hackers Sat Dec 13 06:51:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA26669 for hackers-outgoing; Sat, 13 Dec 1997 06:51:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA26660 for ; Sat, 13 Dec 1997 06:51:36 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id PAA25323 for freebsd-hackers@freebsd.org; Sat, 13 Dec 1997 15:51:32 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id PAA22262; Sat, 13 Dec 1997 15:37:55 +0100 (MET) Date: Sat, 13 Dec 1997 15:37:55 +0100 (MET) Message-Id: <199712131437.PAA22262@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <199712110048.BAA09610@uriah.heep.sax.de> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: I seriously need some networking help X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc Slemko wrote: >> Sure, but that's only a cosmetical problem. I've seen 10.* >> intermediate network addressess even on major Internet relays when >> tracerouting. > So tell me what happens when the box that interface is on needs to send an > ICMP message like can't fragment? > > What IP does it use? If it uses the private one, you lose. This does > break things like PMTU-D. It doesn't, even if the IP source address is 10.*. As long as the ICMP packet has the correct recipient address, it will arrive, and the (original) sender takes the appropriate actions -- it couldn't verify the validity of the ICMP packet's sender address anyway, be it 10.* or anything else. Besides, you could setup the configuration in a way so PMTU-D happens at the inbound interface, but not between the various routers that are linked by 10.* addresses. Likewise, ensure the routability of the packets is already checked at the inbound interface, so ICMP dst unreach packets will be sent from there. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Dec 13 06:51:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA26687 for hackers-outgoing; Sat, 13 Dec 1997 06:51:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA26664 for ; Sat, 13 Dec 1997 06:51:40 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id PAA25326 for freebsd-hackers@freebsd.org; Sat, 13 Dec 1997 15:51:38 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id PAA22275; Sat, 13 Dec 1997 15:43:33 +0100 (MET) Date: Sat, 13 Dec 1997 15:43:33 +0100 (MET) Message-Id: <199712131443.PAA22275@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com> In-Reply-To: <26106.881834408@time.cdrom.com> From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Why so many steps to build new kernel? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: [TurboVision] > ..., there's > just this big huge problem with it. It's in C++. I hate C++ and so > do just about all of the other installation hackers, so we have > something of an impasse in the interface group right now (heck, for > the last 8 months even). That's at least not true for me. I could live with C++ (or anything else that is learnable, be it C, C++, M3, Perl, Tcl), but i'm fearing there's too few space on the bootfloppy for such a monster. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Dec 13 07:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA28041 for hackers-outgoing; Sat, 13 Dec 1997 07:21:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA28036 for ; Sat, 13 Dec 1997 07:21:43 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id QAA25532 for freebsd-hackers@freebsd.org; Sat, 13 Dec 1997 16:21:40 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id QAA22341; Sat, 13 Dec 1997 16:04:18 +0100 (MET) Date: Sat, 13 Dec 1997 16:04:18 +0100 (MET) Message-Id: <199712131504.QAA22341@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: Proposed code merge, objections? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "J. Weatherbee - Senior Systems Architect" wrote: > I've been told there is no official policy on this, so I want some > feedback. I am considering currently a merge of the alog driver > (Industrial Computer Source AIO8-P) into -stable. -stable is not meant to accumulate new features from -current. Unless there are strong reasons, new drivers should not migrate there. This _is_ official policy. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Dec 13 08:08:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA29900 for hackers-outgoing; Sat, 13 Dec 1997 08:08:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (LWOUSgPrs+68V+9qhoNjtdSBQK/kxEkq@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA29891 for ; Sat, 13 Dec 1997 08:08:26 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([B/2webcSSHzWbpkhfVgUNe+X7d7LUg//]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xgu7p-00062d-00; Sat, 13 Dec 1997 16:09:09 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xgu71-0000CE-00; Sat, 13 Dec 1997 16:08:19 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Sat, 13 Dec 1997 16:08:19 +0000 In-Reply-To: j@uriah.heep.sax.de (J Wunsch) "Re: Proposed code merge, objections?" (Dec 13, 4:04pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: Re: Proposed code merge, objections? Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 13, 4:04pm, J Wunsch wrote: } Subject: Re: Proposed code merge, objections? > > I've been told there is no official policy on this, so I want some > > feedback. I am considering currently a merge of the alog driver > > (Industrial Computer Source AIO8-P) into -stable. > > -stable is not meant to accumulate new features from -current. Unless > there are strong reasons, new drivers should not migrate there. This > _is_ official policy. Does this include drivers for common peripherals such as network cards and SCSI controllers? Why wouldn't you want to back-port a driver in -current to -stable if it has proved reliable? Has the driver/rest of kernel interface changed significantly in -current? Niall @h From owner-freebsd-hackers Sat Dec 13 08:21:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00566 for hackers-outgoing; Sat, 13 Dec 1997 08:21:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA00531 for ; Sat, 13 Dec 1997 08:21:46 -0800 (PST) (envelope-from imp@village.org) Received: from pencil-box.village.org [10.0.0.22] by rover.village.org with esmtp (Exim 1.71 #1) id 0xguJy-0006VF-00; Sat, 13 Dec 1997 09:21:42 -0700 Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.8/8.8.3) with ESMTP id WAA00388; Fri, 12 Dec 1997 22:29:42 -0700 (MST) Message-Id: <199712130529.WAA00388@pencil-box.village.org> To: Mike Smith Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Cc: Greg Lehey , "Matthew N. Dodd" , Josef Grosch , freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 11 Dec 1997 15:42:24 +1030." <199712110512.PAA01053@word.smith.net.au> References: <199712110512.PAA01053@word.smith.net.au> Date: Fri, 12 Dec 1997 22:29:42 -0700 From: "M. Warner Losh" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199712110512.PAA01053@word.smith.net.au> Mike Smith writes: : Spot on. With an appropriate cable, any halfway-decent PC monitor will : handle all of the standard Sun video modes. And with the right xf86 config file, you can use a sun monitor on a pc :-) Warner From owner-freebsd-hackers Sat Dec 13 08:21:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00574 for hackers-outgoing; Sat, 13 Dec 1997 08:21:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA00545 for ; Sat, 13 Dec 1997 08:21:49 -0800 (PST) (envelope-from imp@village.org) Received: from pencil-box.village.org [10.0.0.22] by rover.village.org with esmtp (Exim 1.71 #1) id 0xguJx-0006VF-00; Sat, 13 Dec 1997 09:21:41 -0700 Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.8/8.8.3) with ESMTP id WAA00361; Fri, 12 Dec 1997 22:23:13 -0700 (MST) Message-Id: <199712130523.WAA00361@pencil-box.village.org> To: "John S. Dyson" Subject: Re: OS Ports Cc: jamil@acroal.com (J. Weatherbee - Senior Systems Architect), jasone@canonware.com, hackers@freebsd.org In-reply-to: Your message of "Wed, 10 Dec 1997 20:19:39 EST." <199712110119.UAA01319@dyson.iquest.net> References: <199712110119.UAA01319@dyson.iquest.net> Date: Fri, 12 Dec 1997 22:23:12 -0700 From: "M. Warner Losh" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199712110119.UAA01319@dyson.iquest.net> "John S. Dyson" writes: : I am definitely not flaming you, but -current is stable enough as a : base. There will be improvements and enhancements along the way. : If we started with -stable, it is unlikely that the Sparc port would : ever catch up to the X86 port. It is much more likely that you can get deltas integrated into -current for something this "radical" than for -stable. -stable is supposed to not change much, and doing a port to a new h/w platform will likely require a lot of change. -current can cope with code reorgs and the like, but -stable can not. Warner From owner-freebsd-hackers Sat Dec 13 08:22:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00581 for hackers-outgoing; Sat, 13 Dec 1997 08:22:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA00542 for ; Sat, 13 Dec 1997 08:21:49 -0800 (PST) (envelope-from imp@village.org) Received: from pencil-box.village.org [10.0.0.22] by rover.village.org with esmtp (Exim 1.71 #1) id 0xguK2-0006VF-00; Sat, 13 Dec 1997 09:21:46 -0700 Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.8/8.8.3) with ESMTP id VAA01319; Fri, 12 Dec 1997 21:06:02 GMT Message-Id: <199712122106.VAA01319@pencil-box.village.org> To: Luigi Rizzo Subject: Re: isa.c Cc: hackers@freebsd.org In-reply-to: Your message of "Mon, 08 Dec 1997 20:52:20 +0100." <199712081952.UAA29224@labinfo.iet.unipi.it> References: <199712081952.UAA29224@labinfo.iet.unipi.it> Date: Fri, 12 Dec 1997 14:06:01 -0700 From: "M. Warner Losh" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199712081952.UAA29224@labinfo.iet.unipi.it> Luigi Rizzo writes: : I am running 2.2.1 myself (and on one machine even 1.1.5... that : machine is up and running since Jan 1994 -- only crashes when there : is no power, which happens rarely enough not to bother: the only reason that we upgraded our 1.1.5.1R box was that we were no longer able to build kernels/binaries for it. we have boatloads of 2.2 and newer boxes around and it finally became too painful to cope with trying to build in a chroot'd environment :-(. Warner From owner-freebsd-hackers Sat Dec 13 09:40:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA04686 for hackers-outgoing; Sat, 13 Dec 1997 09:40:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA04672 for ; Sat, 13 Dec 1997 09:40:21 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 21444 invoked by uid 1001); 13 Dec 1997 17:40:10 +0000 (GMT) To: imp@village.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-Reply-To: Your message of "Fri, 12 Dec 1997 22:29:42 -0700" References: <199712130529.WAA00388@pencil-box.village.org> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 13 Dec 1997 18:40:10 +0100 Message-ID: <21442.882034810@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : Spot on. With an appropriate cable, any halfway-decent PC monitor will > : handle all of the standard Sun video modes. > > And with the right xf86 config file, you can use a sun monitor on a pc As far as I know that's not true of *all* Sun monitors, because not all Sun monitors are multisync. I believe all *recent* Sun monitors are multisync, though. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sat Dec 13 10:01:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05814 for hackers-outgoing; Sat, 13 Dec 1997 10:01:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05806 for ; Sat, 13 Dec 1997 10:01:30 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id LAA13238 for freebsd-hackers@FreeBSD.ORG; Sat, 13 Dec 1997 11:01:28 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA26532 for ; Sat, 13 Dec 1997 11:01:54 -0700 (MST) Date: Sat, 13 Dec 1997 11:01:54 -0700 (MST) From: Marc Slemko To: freebsd-hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help In-Reply-To: <199712131437.PAA22262@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Dec 1997, J Wunsch wrote: > Marc Slemko wrote: > > >> Sure, but that's only a cosmetical problem. I've seen 10.* > >> intermediate network addressess even on major Internet relays when > >> tracerouting. > > > So tell me what happens when the box that interface is on needs to send an > > ICMP message like can't fragment? > > > > What IP does it use? If it uses the private one, you lose. This does > > break things like PMTU-D. > > It doesn't, even if the IP source address is 10.*. As long as the > ICMP packet has the correct recipient address, it will arrive, and the > (original) sender takes the appropriate actions -- it couldn't verify > the validity of the ICMP packet's sender address anyway, be it 10.* or > anything else. Incorrect. No packets with reserved addresses make it into my network, and there are many other networks that operate in a similar fashion, especially those that use internal addresses themself. > Besides, you could setup the configuration in a way so PMTU-D happens > at the inbound interface, but not between the various routers that are You can do many things. However the fact remains that, in general, it is a bad idea to use internal addresses for numbering interfaces that can be seen by the world in any way. I have been around networks where it is done. It does cause problems. No, most people can't recognize the cause and just put it down to "oh, the Internet is just like that". > linked by 10.* addresses. Likewise, ensure the routability of the > packets is already checked at the inbound interface, so ICMP dst > unreach packets will be sent from there. From owner-freebsd-hackers Sat Dec 13 10:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA05872 for hackers-outgoing; Sat, 13 Dec 1997 10:02:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA05862 for ; Sat, 13 Dec 1997 10:01:53 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 21539 invoked by uid 1001); 13 Dec 1997 18:01:49 +0000 (GMT) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help In-Reply-To: Your message of "Sat, 13 Dec 1997 15:37:55 +0100 (MET)" References: <199712131437.PAA22262@uriah.heep.sax.de> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 13 Dec 1997 19:01:49 +0100 Message-ID: <21537.882036109@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What IP does it use? If it uses the private one, you lose. This does > > break things like PMTU-D. > > It doesn't, even if the IP source address is 10.*. As long as the > ICMP packet has the correct recipient address, it will arrive, and the > (original) sender takes the appropriate actions -- it couldn't verify > the validity of the ICMP packet's sender address anyway, be it 10.* or > anything else. No, in many cases packets with RFC 1918 source addresses will *not* arrive - because they are blocked by packet filters meant to prevent IP address forgery. I know for a fact that UNINETT (AS 224) blocks such packets at its border routers. Using RFC 1918 addresses for router links on the Internet is *not* a good idea. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sat Dec 13 11:54:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10714 for hackers-outgoing; Sat, 13 Dec 1997 11:54:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ymris.ddm.on.ca (cisco2-119.cas.golden.net [207.6.168.119]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10688 for ; Sat, 13 Dec 1997 11:54:24 -0800 (PST) (envelope-from dchapes@ddm.on.ca) Received: from squigy.ddm.on.ca (squigy.ddm.on.ca [209.47.139.138]) by ymris.ddm.on.ca (8.8.7/8.8.8) with ESMTP id OAA10087; Sat, 13 Dec 1997 14:54:04 -0500 (EST) (envelope-from dchapes@ymris.ddm.on.ca) Received: (from dchapes@localhost) by squigy.ddm.on.ca (8.8.7/8.8.7) id OAA10731; Sat, 13 Dec 1997 14:54:03 -0500 (EST) Message-ID: <19971213145402.25283@ddm.on.ca> Date: Sat, 13 Dec 1997 14:54:02 -0500 From: Dave Chapeskie To: freebsd-hackers@FreeBSD.ORG Cc: J Wunsch Subject: Re: I seriously need some networking help References: <199712110048.BAA09610@uriah.heep.sax.de> <199712131437.PAA22262@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199712131437.PAA22262@uriah.heep.sax.de>; from J Wunsch on Sat, Dec 13, 1997 at 03:37:55PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Dec 13, 1997 at 03:37:55PM +0100, J Wunsch wrote: > >> Sure, but that's only a cosmetical problem. I've seen 10.* > >> intermediate network addressess even on major Internet relays when > >> tracerouting. > > > So tell me what happens when the box that interface is on needs to send an > > ICMP message like can't fragment? > > > > What IP does it use? If it uses the private one, you lose. This does > > break things like PMTU-D. > > It doesn't, even if the IP source address is 10.*. As long as the > ICMP packet has the correct recipient address, it will arrive, and the > (original) sender takes the appropriate actions -- it couldn't verify > the validity of the ICMP packet's sender address anyway, be it 10.* or > anything else. But don't the RFCs prohibit any packets with reserved IP numbers from being routed onto the internet? Or doesn't the source address count? I know my firewall drops anything to or from a reserved IP number. -- Dave Chapeskie, DDM Consulting E-Mail: dchapes@ddm.on.ca From owner-freebsd-hackers Sat Dec 13 12:45:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA13617 for hackers-outgoing; Sat, 13 Dec 1997 12:45:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA13602 for ; Sat, 13 Dec 1997 12:45:18 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 22195 invoked by uid 1001); 13 Dec 1997 20:45:13 +0000 (GMT) To: dchapes@ddm.on.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help In-Reply-To: Your message of "Sat, 13 Dec 1997 14:54:02 -0500" References: <19971213145402.25283@ddm.on.ca> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 13 Dec 1997 21:45:12 +0100 Message-ID: <22193.882045912@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But don't the RFCs prohibit any packets with reserved IP numbers from > being routed onto the internet? Or doesn't the source address count? Routing is done based on destination address. Some ISPs filter packets with RFC 1918 addresses as source, some don't. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sat Dec 13 12:56:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA14459 for hackers-outgoing; Sat, 13 Dec 1997 12:56:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA14454 for ; Sat, 13 Dec 1997 12:56:05 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id NAA15376; Sat, 13 Dec 1997 13:55:35 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd015362; Sat Dec 13 13:55:30 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA29304; Sat, 13 Dec 1997 13:55:27 -0700 (MST) From: Terry Lambert Message-Id: <199712132055.NAA29304@usr06.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: mike@smith.net.au (Mike Smith) Date: Sat, 13 Dec 1997 20:55:27 +0000 (GMT) Cc: bgingery@gtcs.com, hackers@FreeBSD.ORG In-Reply-To: <199712130848.TAA01888@word.smith.net.au> from "Mike Smith" at Dec 13, 97 07:18:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Theoretically, the physical layout of the device should be stored > > whether or not there's any filesystem on it. > > This is a fundamentally flawed approach, and I am glad that Julian's > new SLICE model (at this stage) completely ignores any incidental > parametric information associated with an extent. One "incidental" piece of parametric information I am interested in seeing is the physical block size. Consider the FFS directory management code. It has knowledge of physical blocks. In fact, it can not easily handle a directory block that is not exactly a physical block size. The current code can not be broken across block I/O's, nor can it handle partial block I/O's well (there are a number of failure modes). This becomes *very* important if you ever want to support Unicode, which takes 2 characters per character, or EUC encoded "Big 5", which may take up to 5 characters per character (one of the reasons I am "for" Unicode and "against" EUC/ISO2022). For you to be able to fit a maximally-sized file name in a single directory block means your directory block must be over 512 bytes in length. > Physical blocksize vs. logical blocksize is a problematic issue. On > one hand, there is the desire to maintain simplicity by mandating a > single blocksize across all boundaries and forcing translation at the > lowest practical level. The downside with this is dealing with legal > logical block operations that result in partial block operations at the > lowest level. > > One approach with plenty of historical precedent is to use a blocksize > "sufficiently large" that it is a multiple of the likely device > blocksizes, and make that the 'uniform standard'. Another is to > cascade blocksizes upwards, where the blocksize at a given point in the > tree is the lowest common multiple of that of all points below. This > obviously requires some extra smarts in each layer that consumes > multiple lower layers. Both of these are addressable using a logical block size, and hiding the block boundries, as necessary, for the upper level code. Consider a putative "audio read/write CD FS", where the block size is not an integer factor of the page size. How does one MMAP files from such a beast? > Incorrect. It is relatively straightforward to create a vnode disk, > slice it, build a FAT filesystem in one slice and then pass that slice > to your favorite PC emulator. I believe there should be an INT 21 redirector in the PC emulators to allow them to use any VFS disk to which the process they are running in has legitimate access. > > Yet, why deny these the optimization information which will allow > > them to map (within the constraints of their architecture) a new > > filesystem for best throughput, if it's actually available. > > Because any "optimisation information" that you could pass them would > be wrong. Any optimisation attempting to operate based on incorrect > parameters can only be a pessimisation. This is not strictly true. I have been arguing for a long time for the use of the 8 "partial page bits" within the kernel. Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks are not constrained to start at an even offset from the start of the disk, only from an even cylinder boundry. This means that 512b of the 1k block can be at the end of one page, and the 512b for the rest of the block can be at the beginning of another. It makes a hell of a lot of sense to be able to read only 1k of data from the disk instead of 16k. Especially in light of your arguments about not saving optimization information, such as cylinder boundries. A 16k read is 16 times more likely to result in a "hidden" seek in your model. > > With what we're all doing today, it seems that taking a certain > > number of cylinders for slices is best - but other access methods > > may find an underlying physical structure more convenient if > > a slice specifies a range of heads and cylinders that do NOT > > presume that all heads/cylinders from starting to ending according > > to physical layout are part of the same slice. It may be quite > > convenient to have a cluster of heads across physical devices > > forming a logical device or slice, without fully dedicating those > > physical devices to that use. > > This is a nonsense question in the context of ZBR and "logical extent" > devices (eg. SCSI, ATAPI, most ATA devices). There are a number of SCSI devices that support independent head seeks per platter (not nearly as many as the non-SCSI big iron IBM/DEC drives, but they do exist). Similarly, for single seek controlling multiple heads, any block which crosses a platter * sector_size boundry could result in another seek. Admittedly, the clustering wins are much larger than the geometry wins, but the geometry wins are non-zero. In addition, even ZBR SCSI II disks can return the actual breakdown of sector counts within each zone (in the extended mode page). So the data *is* available on newer disks; it's the older SCSI I disks that lack this information. > > And, I'll mention again, DISK formats are not the only > > random-access mass-storage formats on the horizon! I'm guessing > > that for speed of inclusion into product lines, all will emulate > > a disk drive - but that may not be the most efficient way of using > > them (in fact, probably not). They also can be expected to have > > "direct access" methods according to their physical architecture, > > with some form of tree-access the MOST efficient! > > In most cases, the internal architecture of the device will be > optimised for two basic operations; retrieval of large contiguous > extents, and read/write of small randomly scattered regions. Consider the use of static column DRAM for the implementation of such a device. Column access after single element access is many times faster. IBM, Sanyo-ICON, and several others used this technique (a former supervisor of mine holds the patent for a zero cycle latency L2 cache used in the Sanyo-ICON machines using these devices). [ ... device arrival/departure events ... ] > This is trivially obvious, and forms the basic argument for the use of > DEVFS. You fail to draw the parallel between system startup and the > conceptual "massive arrival of devices" which is still the major > argument for such a system. The events should, ideally, be propagated out of the devfs framework, IMO. I'm not sure Julian agrees with me on this. This would mean that after you ask the slice handlers if they want the device, and they all say "no", it's a terminal device. But the event should keep going. I think that file system mounts should result from arrival events. This is actually the basis of my argument that the mounting of a device should be seperate from the mapping of the device into the FS hierarchy. If all devices could be mounted, even though you don't know their mapping into the hierarchy, then an event could result from a successful mount, and be propagated to a hierarchy mapping agent. At this point, fstab is a means of dictating mapping. To a large extent it is unnecessary to have an fstab: one could use the "last mounted on" field for this data, and ignore the "/mnt" FS's (leaving them unmapped), or even modify the newfs to stuff the mountpoint into the "last mounted on" field. Ah, brave new world, that has such thing in't. 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 Sat Dec 13 13:29:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16447 for hackers-outgoing; Sat, 13 Dec 1997 13:29:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16439 for ; Sat, 13 Dec 1997 13:29:20 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA29868; Sat, 13 Dec 1997 14:30:23 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd029819; Sat Dec 13 14:30:02 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA02173; Sat, 13 Dec 1997 14:28:25 -0700 (MST) From: Terry Lambert Message-Id: <199712132128.OAA02173@usr06.primenet.com> Subject: Re: blocksize on devfs entries (and related) To: julian@whistle.com (Julian Elischer) Date: Sat, 13 Dec 1997 21:28:25 +0000 (GMT) Cc: mike@smith.net.au, bgingery@gtcs.com, hackers@freebsd.org In-Reply-To: from "Julian Elischer" at Dec 13, 97 03:05:27 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Theoretically, the physical layout of the device should be stored > > > whether or not there's any filesystem on it. > > The problem is that on all new devices the layout is both hidden and > not easily describable. Nor can we describe the layouts of media that have > not yet been invented. Track/cyl/sector geometry descriptions can not be > used to describe modern disks and the picture is muddied by track buffers > and reverse block write order (for example). SCSI I geometries are not directly accessable. But SCSI II geometries are. I think track buffers and reverse block write order are attributes that could be communicated (actually, the second implies the first. 8-)). [ ... ] > In the face of confusion, do nothing.. > I will probably punt on must of the complicated issues, believing that > the drive manufacturers will just do the best they can :) This is a good approach. The cylinder seek optimizations in the face of no knowledge of the disk layout are actually pessimizations. But if you *do* have knowledge of the disk layout... > r/w 'openness' is and should be propogated up and down. I've already > started work on this. The difficult bit is not in the SLICE code, but > rather in teh existing system code that doesn't notify the slice code when > this happens. This is where Poul's suggestions about needing explicit events on open/close come into play. It's so blatantly obvious (after Poul pointed it out, of course ;-)), that it's strange that we are still talking about it. > Manufacturers will be making devices to be optimised to do what we want > to do. so for us to try do something different may even slow things down. This is signaturable, Julian. 8-). I can imagine my static column DRAM from my other post arranging access to a large number of columns simultaneously. Going outside this locality to another column would be a large penalty, on the order of a seek delay (given the relative speed of SRAM vis-a-vis disk transfer rate relative to disk seek time). > DEVFS is PRIMARILY for non DASD devices.. I have only added the DASD > support in the last month. Another example of what someone might want is clonable devices; tunnel devices, BPF devices, etc.. Pty's are just the most obvious type of clonable device, not the only ones of interest. I can see a definite need for device-as-directy-containing-devices. This speaks once again in favor of Poul's discrete reference notifications. > The outwards appearance of no change, but an internal complete rebuild to > be more modular. Sounds exactly like some FS changes someone was pushing for a while back. }B-). One aspect of devfs that no one has been pushing to hard, but which I think should be mentioned is the fact that, currently, it is impossible to netboot a FreeBSD machine off of some types of host systems that are unable to represent FreeBSD's devices. DEC UNIX is one example. By making the devices intrinsic to the kernel instead of represented externally by type+major+minor, the devices are not dependent on any external storage for their existance, so external storage limitations no longer apply (like this one; there are others). This also makes it easier to get an initial port going, since there is no need for an NFS -or- local media FS in order to get a minimal single user shell... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Dec 13 13:30:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16548 for hackers-outgoing; Sat, 13 Dec 1997 13:30:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from precipice.shockwave.com (precipice.shockwave.com [207.105.15.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16526 for ; Sat, 13 Dec 1997 13:30:07 -0800 (PST) (envelope-from pst@Shockwave.COM) Received: (from pst@localhost) by precipice.shockwave.com (8.8.8/8.8.8) id NAA09316 for hackers@freebsd.org; Sat, 13 Dec 1997 13:29:44 -0800 (PST) (envelope-from pst) Date: Sat, 13 Dec 1997 13:29:44 -0800 (PST) From: Paul Traina Message-Id: <199712132129.NAA09316@precipice.shockwave.com> To: hackers@freebsd.org Subject: 3Com 3C575 10/100 PCCARD driver? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anyone playing with the new 3COM 10/100 card? From owner-freebsd-hackers Sat Dec 13 13:38:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA17171 for hackers-outgoing; Sat, 13 Dec 1997 13:38:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (pm3-p11.tfs.net [206.154.183.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17162 for ; Sat, 13 Dec 1997 13:37:56 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id PAA00841 for freebsd-hackers@freebsd.org; Sat, 13 Dec 1997 15:37:48 -0600 (CST) From: Jim Bryant Message-Id: <199712132137.PAA00841@unix.tfs.net> Subject: motherboard for alpha port? To: freebsd-hackers@freebsd.org Date: Sat, 13 Dec 1997 15:37:47 -0600 (CST) Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 3.0-CURRENT #0: Mon Dec 1 15:51:40 CST 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk what motherboard is currently being supported for the alpha port, where can i see it [web page], and how much does it cost? i've been looking at dec's offerings, and am not sure which it is... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-hackers Sat Dec 13 15:06:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22185 for hackers-outgoing; Sat, 13 Dec 1997 15:06:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22166 for ; Sat, 13 Dec 1997 15:06:09 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id JAA01880; Sun, 14 Dec 1997 09:35:14 +1030 (CST) (envelope-from grog) Message-ID: <19971214093514.22194@lemis.com> Date: Sun, 14 Dec 1997 09:35:14 +1030 From: Greg Lehey To: sthaug@nethelp.no Cc: imp@village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] References: <199712130529.WAA00388@pencil-box.village.org> <21442.882034810@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <21442.882034810@verdi.nethelp.no>; from sthaug@nethelp.no on Sat, Dec 13, 1997 at 06:40:10PM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Dec 13, 1997 at 06:40:10PM +0100, sthaug@nethelp.no wrote: >>> Spot on. With an appropriate cable, any halfway-decent PC monitor will >>> handle all of the standard Sun video modes. >> >> And with the right xf86 config file, you can use a sun monitor on a pc > > As far as I know that's not true of *all* Sun monitors, because not all > Sun monitors are multisync. I believe all *recent* Sun monitors are > multisync, though. A multisync monitor isn't a prerequisite for XFree86. Many (most?) newer display boards have programmable clocks, so you can set up a mode line to generate the correct frequencies for a specific Sun monitor. Greg From owner-freebsd-hackers Sat Dec 13 15:12:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22550 for hackers-outgoing; Sat, 13 Dec 1997 15:12:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA22542 for ; Sat, 13 Dec 1997 15:12:30 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xh0jU-0006cv-00; Sat, 13 Dec 1997 16:12:28 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id QAA01129; Sat, 13 Dec 1997 16:13:30 -0700 (MST) Message-Id: <199712132313.QAA01129@harmony.village.org> To: sthaug@nethelp.no Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Cc: freebsd-hackers@freebsd.org In-reply-to: Your message of "Sat, 13 Dec 1997 18:40:10 +0100." <21442.882034810@verdi.nethelp.no> References: <21442.882034810@verdi.nethelp.no> <199712130529.WAA00388@pencil-box.village.org> Date: Sat, 13 Dec 1997 16:13:30 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <21442.882034810@verdi.nethelp.no> sthaug@nethelp.no writes: : As far as I know that's not true of *all* Sun monitors, because not all : Sun monitors are multisync. I believe all *recent* Sun monitors are : multisync, though. No, it is true of *ALL* sun monitors. You don't need multisync to run in X. I've been running on a very old Sun monitor for the past 4 years, so I know what I'm talking about :-) Warner From owner-freebsd-hackers Sat Dec 13 15:15:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22723 for hackers-outgoing; Sat, 13 Dec 1997 15:15:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA22713 for ; Sat, 13 Dec 1997 15:15:42 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xh0mU-0006d7-00; Sat, 13 Dec 1997 16:15:34 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id QAA01164; Sat, 13 Dec 1997 16:16:37 -0700 (MST) Message-Id: <199712132316.QAA01164@harmony.village.org> To: Greg Lehey Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Cc: sthaug@nethelp.no, freebsd-hackers@freebsd.org In-reply-to: Your message of "Sun, 14 Dec 1997 09:35:14 +1030." <19971214093514.22194@lemis.com> References: <19971214093514.22194@lemis.com> <199712130529.WAA00388@pencil-box.village.org> <21442.882034810@verdi.nethelp.no> Date: Sat, 13 Dec 1997 16:16:37 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19971214093514.22194@lemis.com> Greg Lehey writes: : A multisync monitor isn't a prerequisite for XFree86. Many (most?) : newer display boards have programmable clocks, so you can set up a : mode line to generate the correct frequencies for a specific Sun : monitor. I've been using one since 1993 or so. An S3 board with a programable clock chip was the first board (#9 Level 3 or some such VLB). It works great, so long as you know which which fixed frequency you have. There are also patches to syscons to allow it to do text mode as well on these beasts, leaving just the boot sequence itself as a problem. I've not used them myself... Warner From owner-freebsd-hackers Sat Dec 13 16:22:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26940 for hackers-outgoing; Sat, 13 Dec 1997 16:22:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26899 for ; Sat, 13 Dec 1997 16:22:10 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id TAA01232; Sat, 13 Dec 1997 19:20:29 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Sat, 13 Dec 1997 19:20:23 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Greg Lehey cc: sthaug@nethelp.no, imp@village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-Reply-To: <19971214093514.22194@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Dec 1997, Greg Lehey wrote: > On Sat, Dec 13, 1997 at 06:40:10PM +0100, sthaug@nethelp.no wrote: > >>> Spot on. With an appropriate cable, any halfway-decent PC monitor will > >>> handle all of the standard Sun video modes. > >> > >> And with the right xf86 config file, you can use a sun monitor on a pc > > > > As far as I know that's not true of *all* Sun monitors, because not all > > Sun monitors are multisync. I believe all *recent* Sun monitors are > > multisync, though. > > A multisync monitor isn't a prerequisite for XFree86. Many (most?) > newer display boards have programmable clocks, so you can set up a > mode line to generate the correct frequencies for a specific Sun > monitor. Dangerous to give out that advice, Greg. Many older Sun monitors were single frequency monitors, and while Xfree86 could be prpogrammed to work with them, during boot, when the monitors are in 640X400, they just can't handle that at all, and will just burn out while tring to get to X11 mode. It requires a specially programmed video card that, when the bios tells it to go to 640X400, ignores that and stays where it's hardware optioned to be. > > Greg > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sat Dec 13 16:24:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27218 for hackers-outgoing; Sat, 13 Dec 1997 16:24:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27186 for ; Sat, 13 Dec 1997 16:24:01 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA08363; Sat, 13 Dec 1997 17:23:59 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA00752; Sat, 13 Dec 1997 17:23:58 -0700 Date: Sat, 13 Dec 1997 17:23:58 -0700 Message-Id: <199712140023.RAA00752@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Traina Cc: hackers@FreeBSD.ORG Subject: Re: 3Com 3C575 10/100 PCCARD driver? In-Reply-To: <199712132129.NAA09316@precipice.shockwave.com> References: <199712132129.NAA09316@precipice.shockwave.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is anyone playing with the new 3COM 10/100 card? As I understand things, it's a CardBus card (vs. a PCMCIA card). FreeBSD only has support for the PCMCIA card (16-bit), and I don't even know what it will take to get CardBus support. It took M$ 3 years to get support added, and they helped write the spec. :( Nate From owner-freebsd-hackers Sat Dec 13 16:26:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27387 for hackers-outgoing; Sat, 13 Dec 1997 16:26:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27357 for ; Sat, 13 Dec 1997 16:25:46 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA01323; Sun, 14 Dec 1997 10:55:33 +1030 (CST) (envelope-from grog) Message-ID: <19971214105532.35984@lemis.com> Date: Sun, 14 Dec 1997 10:55:32 +1030 From: Greg Lehey To: Chuck Robey Cc: sthaug@nethelp.no, imp@village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] References: <19971214093514.22194@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Chuck Robey on Sat, Dec 13, 1997 at 07:20:23PM -0500 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Dec 13, 1997 at 07:20:23PM -0500, Chuck Robey wrote: > On Sun, 14 Dec 1997, Greg Lehey wrote: > >> On Sat, Dec 13, 1997 at 06:40:10PM +0100, sthaug@nethelp.no wrote: >>>>> Spot on. With an appropriate cable, any halfway-decent PC monitor will >>>>> handle all of the standard Sun video modes. >>>> >>>> And with the right xf86 config file, you can use a sun monitor on a pc >>> >>> As far as I know that's not true of *all* Sun monitors, because not all >>> Sun monitors are multisync. I believe all *recent* Sun monitors are >>> multisync, though. >> >> A multisync monitor isn't a prerequisite for XFree86. Many (most?) >> newer display boards have programmable clocks, so you can set up a >> mode line to generate the correct frequencies for a specific Sun >> monitor. > > Dangerous to give out that advice, Greg. Many older Sun monitors were > single frequency monitors, and while Xfree86 could be prpogrammed to work > with them, during boot, when the monitors are in 640X400, they just can't > handle that at all, and will just burn out while tring to get to X11 mode. Well, the advice didn't suggest to use them during boot. As Warner points out, it works. As I point out in "The Complete FreeBSD", bad settings can burn out your monitor. > It requires a specially programmed video card that, when the bios > tells it to go to 640X400, ignores that and stays where it's > hardware optioned to be. If I were to do this (and I might--I have a 17" Sun monitor out in the shed), I'd put it on a second display board. There are numerous ways to handle this problem, for example turning the monitor off during boot and until you can start xdm. I probably wouldn't have sent this message to -questions without a few more caveats, but I think -hackers people can think for themselves. Greg From owner-freebsd-hackers Sat Dec 13 16:30:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27907 for hackers-outgoing; Sat, 13 Dec 1997 16:30:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA27889 for ; Sat, 13 Dec 1997 16:30:17 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xh1wk-0006eV-00; Sat, 13 Dec 1997 17:30:14 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id RAA01362; Sat, 13 Dec 1997 17:31:17 -0700 (MST) Message-Id: <199712140031.RAA01362@harmony.village.org> To: Chuck Robey Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Cc: Greg Lehey , sthaug@nethelp.no, freebsd-hackers@freebsd.org In-reply-to: Your message of "Sat, 13 Dec 1997 19:20:23 EST." References: Date: Sat, 13 Dec 1997 17:31:17 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Chuck Robey writes: : Dangerous to give out that advice, Greg. Many older Sun monitors were : single frequency monitors, and while Xfree86 could be prpogrammed to work : with them, during boot, when the monitors are in 640X400, they just can't : handle that at all, and will just burn out while tring to get to X11 mode. That's one reason that I always tell people in my "Howto" page to turn off the monitor while not in use and during reboot.... The Sony monitor that I've been using for years didn't seem to care much about being in text mode for periods of time up to 3 days (long weekend, power hit at the start...). Your milage may vary, however. Warner From owner-freebsd-hackers Sat Dec 13 16:32:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28367 for hackers-outgoing; Sat, 13 Dec 1997 16:32:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA28331 for ; Sat, 13 Dec 1997 16:32:39 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xh1z3-0006ed-00; Sat, 13 Dec 1997 17:32:37 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id RAA01395; Sat, 13 Dec 1997 17:33:40 -0700 (MST) Message-Id: <199712140033.RAA01395@harmony.village.org> To: Greg Lehey Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] Cc: Chuck Robey , sthaug@nethelp.no, freebsd-hackers@freebsd.org In-reply-to: Your message of "Sun, 14 Dec 1997 10:55:32 +1030." <19971214105532.35984@lemis.com> References: <19971214105532.35984@lemis.com> <19971214093514.22194@lemis.com> Date: Sat, 13 Dec 1997 17:33:40 -0700 From: Warner Losh Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19971214105532.35984@lemis.com> Greg Lehey writes: : If I were to do this (and I might--I have a 17" Sun monitor out in the : shed), I'd put it on a second display board. I'd be curious to see if this works. I've never had enough hardware to give it a try, since the mono boards were before my time and none of the cards I've tried support multiple VGA cards in one system... : There are numerous ways to handle this problem, for example turning : the monitor off during boot and until you can start xdm. I probably : wouldn't have sent this message to -questions without a few more : caveats, but I think -hackers people can think for themselves. Yes. Too bad you have to fsck /usr before you can start X, or have a huge / partition in order to make it work well in the boot process. Warner From owner-freebsd-hackers Sat Dec 13 16:35:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28865 for hackers-outgoing; Sat, 13 Dec 1997 16:35:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from milkyway.org (lta-r-1.usit.net [205.241.194.17] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28802; Sat, 13 Dec 1997 16:35:21 -0800 (PST) (envelope-from toby@milkyway.org) Received: (from toby@localhost) by milkyway.org (8.8.5/8.8.3) id TAA01751; Sat, 13 Dec 1997 19:34:47 -0500 (EST) Date: Sat, 13 Dec 1997 19:34:47 -0500 (EST) From: Toby Swanson To: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: NIS login problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have set up an NIS master server and a client, both running 2.1.7. Ypserv is running on the master, ypbind on both (server bound to itself), yppasswdd on both. Running ypwhich on both shows both bound to the master. Running ypcat passwd.byname on both shows the passwd file. The client is mapping user names on the master to uids on the server. Changes to the group file on the master affect the client. Fingering a user on the client retrieves correct info from the server. Running yppasswd on the client changes the master.passwd file on the server. Everything seems to work except logging in. The des and kerberos libraries have been installed. /var/yp/ypupdate.log says nothing other that the maps have been updated. If I run ypserv in debug mode I see the query for a user name and a succesful answer (I think). It seems the client is not authenticating or decrypting the password properly. I installed a 2.1.7 client in a Solaris 2.5.1 domain and everything went smoothly. The only error I see on either system is when su'ing to root I get the message "su: kerberos: not in root's ACL." If anyone has any ideas about what may be wrong or what else to check I would appreciate your feedback. Thanks in advance. Toby home: toby@milkyway.org work: tjswanson@tva.gov From owner-freebsd-hackers Sat Dec 13 16:50:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01495 for hackers-outgoing; Sat, 13 Dec 1997 16:50:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01445 for ; Sat, 13 Dec 1997 16:50:04 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA04493; Sun, 14 Dec 1997 11:13:50 +1030 (CST) Message-Id: <199712140043.LAA04493@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: sthaug@nethelp.no cc: imp@village.org, freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-reply-to: Your message of "Sat, 13 Dec 1997 18:40:10 BST." <21442.882034810@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 11:13:49 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > : Spot on. With an appropriate cable, any halfway-decent PC monitor will > > : handle all of the standard Sun video modes. > > > > And with the right xf86 config file, you can use a sun monitor on a pc > > As far as I know that's not true of *all* Sun monitors, because not all > Sun monitors are multisync. I believe all *recent* Sun monitors are > multisync, though. You don't need a multisync Sun monitor to use it on a PC. As Warner said, all you need is the right X configuration. Why have the monitor sync to you when you can sync to it? mike (And before you ask, yes, I have done this with Sun, HP/Apollo and other fixed-scan monitors. It works.) From owner-freebsd-hackers Sat Dec 13 17:11:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04267 for hackers-outgoing; Sat, 13 Dec 1997 17:11:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04248 for ; Sat, 13 Dec 1997 17:11:08 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id UAA03592; Sat, 13 Dec 1997 20:07:24 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Sat, 13 Dec 1997 20:07:23 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: Warner Losh cc: Greg Lehey , sthaug@nethelp.no, freebsd-hackers@FreeBSD.ORG Subject: Re: [jgrosch@mooseriver.com: Re: Beginning SPARC port] In-Reply-To: <199712140031.RAA01362@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Dec 1997, Warner Losh wrote: > In message Chuck Robey writes: > : Dangerous to give out that advice, Greg. Many older Sun monitors were > : single frequency monitors, and while Xfree86 could be prpogrammed to work > : with them, during boot, when the monitors are in 640X400, they just can't > : handle that at all, and will just burn out while tring to get to X11 mode. > > That's one reason that I always tell people in my "Howto" page to turn > off the monitor while not in use and during reboot.... > > The Sony monitor that I've been using for years didn't seem to care > much about being in text mode for periods of time up to 3 days (long > weekend, power hit at the start...). Your milage may vary, however. Fair enough, and Greg's note about most folks on this list is fairly true, too. Gotta admit, the FreeBSD lists are one of the best behaved and literate ones (on average) I've ever heard of, so they probably know enough to read the howto's. > > Warner > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sat Dec 13 17:21:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06056 for hackers-outgoing; Sat, 13 Dec 1997 17:21:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from precipice.shockwave.com (precipice.shockwave.com [207.105.15.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06038 for ; Sat, 13 Dec 1997 17:21:27 -0800 (PST) (envelope-from pst@shockwave.com) Received: from shockwave.com (localhost [127.0.0.1]) by precipice.shockwave.com (8.8.8/8.8.8) with ESMTP id RAA09951; Sat, 13 Dec 1997 17:20:32 -0800 (PST) (envelope-from pst@shockwave.com) Message-Id: <199712140120.RAA09951@precipice.shockwave.com> To: Nate Williams cc: hackers@FreeBSD.ORG Subject: Re: 3Com 3C575 10/100 PCCARD driver? In-reply-to: Your message of "Sat, 13 Dec 1997 17:23:58 MST." <199712140023.RAA00752@mt.sri.com> Date: Sat, 13 Dec 1997 17:20:32 -0800 From: Paul Traina Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yow! Damn. Time to call up Gateway and trade cards with them. :-( From: Nate Williams Subject: Re: 3Com 3C575 10/100 PCCARD driver? > Is anyone playing with the new 3COM 10/100 card? As I understand things, it's a CardBus card (vs. a PCMCIA card). FreeBSD only has support for the PCMCIA card (16-bit), and I don't even know what it will take to get CardBus support. It took M$ 3 years to get support added, and they helped write the spec. :( Nate From owner-freebsd-hackers Sat Dec 13 18:14:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA13035 for hackers-outgoing; Sat, 13 Dec 1997 18:14:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA13022 for ; Sat, 13 Dec 1997 18:14:28 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA04740; Sun, 14 Dec 1997 12:38:57 +1030 (CST) Message-Id: <199712140208.MAA04740@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: hackers@freebsd.org Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Sat, 13 Dec 1997 21:28:25 -0000." <199712132128.OAA02173@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 12:38:57 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The problem is that on all new devices the layout is both hidden and > > not easily describable. Nor can we describe the layouts of media that have > > not yet been invented. Track/cyl/sector geometry descriptions can not be > > used to describe modern disks and the picture is muddied by track buffers > > and reverse block write order (for example). > > SCSI I geometries are not directly accessable. But SCSI II geometries > are. Er, in what fashion? I don't recall any mandatory pages for zone description tables, or provision for self-describing geometry pages for new geometry techniques. > I think track buffers and reverse block write order are attributes > that could be communicated (actually, the second implies the first. 8-)). There is no standard for this, however, nor for describing the control policies that are applied to them, all of which relate to the effect that they may have on a consumer. mike From owner-freebsd-hackers Sat Dec 13 18:27:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16227 for hackers-outgoing; Sat, 13 Dec 1997 18:27:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16179 for ; Sat, 13 Dec 1997 18:27:45 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA04796; Sun, 14 Dec 1997 12:52:07 +1030 (CST) Message-Id: <199712140222.MAA04796@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Sat, 13 Dec 1997 20:55:27 -0000." <199712132055.NAA29304@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 12:52:07 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Theoretically, the physical layout of the device should be stored > > > whether or not there's any filesystem on it. > > > > This is a fundamentally flawed approach, and I am glad that Julian's > > new SLICE model (at this stage) completely ignores any incidental > > parametric information associated with an extent. > > One "incidental" piece of parametric information I am interested in > seeing is the physical block size. I wouldn't want to call the physical block size "incidental"; in combination with the block count it is a fundamental parameter of any extent. > Consider the FFS directory management code. It has knowledge of > physical blocks. In fact, it can not easily handle a directory > block that is not exactly a physical block size. The current code > can not be broken across block I/O's, nor can it handle partial > block I/O's well (there are a number of failure modes). This sounds like a fault in the FFS design. Do you know of any work that deals with this? > For you to be able to fit a maximally-sized file name in a single > directory block means your directory block must be over 512 bytes > in length. Would you suggest upping the "fundamental" system blocksize? How would FFS cope in the face of 2k blocks? > > Incorrect. It is relatively straightforward to create a vnode disk, > > slice it, build a FAT filesystem in one slice and then pass that slice > > to your favorite PC emulator. > > I believe there should be an INT 21 redirector in the PC emulators to > allow them to use any VFS disk to which the process they are running > in has legitimate access. Yes, yes yes. Doscmd and PCEmu do this already. Bochs is rather more primitive in that regard, but now that we have a fulltime FreeBSD-Bochs liaison there is a chance that some of the work in those tools will be absorbed there as well. > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > are not constrained to start at an even offset from the start of the > disk, only from an even cylinder boundry. In the light of the nonexistence of "cylinders" in the proposed model, it strikes me that this becomes an issue of synthesising a conforming pseudo-geometry at filesystem creation time, and little more. Compatability is likely an issue there. > > This is trivially obvious, and forms the basic argument for the use of > > DEVFS. You fail to draw the parallel between system startup and the > > conceptual "massive arrival of devices" which is still the major > > argument for such a system. > > The events should, ideally, be propagated out of the devfs framework, > IMO. I'm not sure Julian agrees with me on this. This would mean that > after you ask the slice handlers if they want the device, and they all > say "no", it's a terminal device. But the event should keep going. Hmm. I've been wondering about the issues involved in an "event dispatcher" of sorts. There's already something along these lines in the network code, as I understand it, where you can sit on a socket listening for routing events. A similar facility would be useful for listening for other interesting events. The issues that I've been puzzling over are to do with queueing events (eg. consumer is not actually listening right now; do you keep a single list of events and discard at the point where the event has been heard by all listeners, or do you create a separate queue for each listener and copy events per the listener's "interest mask"?) and passing events to in-kernel consumers... > Ah, brave new world, that has such thing in't. 8-). Yeah. I bet the old farts are saying "good thing it's them windbags discussin' this, if'n it were someone prone to doin' stuff we'd be in serious shit, eh boys"? 8) mike From owner-freebsd-hackers Sat Dec 13 18:37:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19576 for hackers-outgoing; Sat, 13 Dec 1997 18:37:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from w3.fearme.com (root@fearme.com [206.14.225.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA19506 for ; Sat, 13 Dec 1997 18:36:52 -0800 (PST) (envelope-from rox@fearme.com) Received: (from root@localhost) by w3.fearme.com (8.8.8/8.8.7) id SAA06718; Sat, 13 Dec 1997 18:36:52 -0800 (PST) (envelope-from rox) Date: Sat, 13 Dec 1997 18:36:52 -0800 (PST) From: Aaron Message-Id: <199712140236.SAA06718@w3.fearme.com> To: mike@smith.net.au, tlambert@primenet.com Subject: Re: blocksize on devfs entries (and related) Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-hackers Sat Dec 13 20:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA07266 for hackers-outgoing; Sat, 13 Dec 1997 20:34:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mutara.noc.erols.net (gjp@mutara.noc.erols.net [207.172.25.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA07252 for ; Sat, 13 Dec 1997 20:34:16 -0800 (PST) (envelope-from gjp@mutara.noc.erols.net) Received: (from gjp@localhost) by mutara.noc.erols.net (8.8.8/8.8.7) id XAA17136; Sat, 13 Dec 1997 23:33:49 -0500 (EST) Date: Sat, 13 Dec 1997 23:33:49 -0500 (EST) Message-Id: <199712140433.XAA17136@mutara.noc.erols.net> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <27620.881807554@coconut.itojun.org> From: gjp@erols.net (Gary Palmer) Subject: Re: Beginning SPARC port X-Original-Newsgroups: lists.freebsd.hackers To: itojun@itojun.org CC: hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article <27620.881807554@coconut.itojun.org>, itojun@itojun.org (Jun-ichiro itojun Itoh) writes: > By performing simple grep for `outb', the following files seem to > include i386-specific function calls. > pccard/pcic.c > pci/aic7870.c > pci/if_de.c > pci/ncr.c > pci/tek390.c > pci/wd82371.c What makes you think outb is i386 specific? Surely since it is defined in a machine header to some asm fn, what it really means is that it is GNU C specific? If you think about it, if a platform needed a bit of complexity to do inb/outb, you #define them to funciton calls. Yes, there is `cruft' in the main (non /sys/i386) tree which needs to be dealt with, and there is even more in the main userland tree I bet, but one of the reasons we on the core team have long wanted a port to another platform is to clean up the source tree. Its generally felt that another port will highlight shortcomings and bugs in our i386 port faster than bashing on it with ddb will... Gary From owner-freebsd-hackers Sat Dec 13 20:41:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA07644 for hackers-outgoing; Sat, 13 Dec 1997 20:41:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA07625 for ; Sat, 13 Dec 1997 20:41:04 -0800 (PST) (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id NAA16089; Sun, 14 Dec 1997 13:40:45 +0900 (JST) To: gjp@erols.net (Gary Palmer) cc: hackers@FreeBSD.ORG In-reply-to: gjp's message of Sat, 13 Dec 1997 23:33:49 EST. <199712140433.XAA17136@mutara.noc.erols.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Beginning SPARC port From: Jun-ichiro itojun Itoh Date: Sun, 14 Dec 1997 13:40:45 +0900 Message-ID: <16085.882074445@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> pccard/pcic.c >> pci/aic7870.c >> pci/if_de.c >> pci/ncr.c >> pci/tek390.c >> pci/wd82371.c >What makes you think outb is i386 specific? Surely since it is defined >in a machine header to some asm fn, what it really means is that >it is GNU C specific? If you think about it, if a platform needed >a bit of complexity to do inb/outb, you #define them to funciton >calls. hardware I/O model is CPU specific. There are architectures that do not have inb/outb instruction, and maps I/O device control registers onto memory. I dunno how Sparc-with-PCI motherboard access pci registers, but I'm sure there has to be bunch of changes. itojun From owner-freebsd-hackers Sat Dec 13 21:07:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA09561 for hackers-outgoing; Sat, 13 Dec 1997 21:07:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mutara.noc.erols.net (gjp@mutara.noc.erols.net [207.172.25.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09548 for ; Sat, 13 Dec 1997 21:07:09 -0800 (PST) (envelope-from gjp@mutara.noc.erols.net) Received: (from gjp@localhost) by mutara.noc.erols.net (8.8.8/8.8.7) id AAA17194; Sun, 14 Dec 1997 00:06:53 -0500 (EST) Date: Sun, 14 Dec 1997 00:06:53 -0500 (EST) Message-Id: <199712140506.AAA17194@mutara.noc.erols.net> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712140433.XAA17136@mutara.noc.erols.net> <16085.882074445@coconut.itojun.org> From: gjp@erols.net (Gary Palmer) Subject: Re: Beginning SPARC port X-Original-Newsgroups: lists.freebsd.hackers To: itojun@itojun.org CC: hackers@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article <16085.882074445@coconut.itojun.org>, itojun@itojun.org (Jun-ichiro itojun Itoh) writes: > hardware I/O model is CPU specific. There are architectures > that do not have inb/outb instruction, and maps I/O device control > registers onto memory. I dunno how Sparc-with-PCI motherboard > access pci registers, but I'm sure there has to be bunch of changes. Right, but in that case you #define the inb/outb macros to be the appropriate load/store instructions for the processor. What I am trying to say is that while it may not be the Politically Correct(TM) solution, it is not totally i386 bound either. Being #defines, its a bit more flexible than you were making out. Gary From owner-freebsd-hackers Sat Dec 13 21:18:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA10283 for hackers-outgoing; Sat, 13 Dec 1997 21:18:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10276 for ; Sat, 13 Dec 1997 21:18:44 -0800 (PST) (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id OAA16612; Sun, 14 Dec 1997 14:18:39 +0900 (JST) To: gjp@erols.net (Gary Palmer) cc: hackers@FreeBSD.ORG In-reply-to: gjp's message of Sun, 14 Dec 1997 00:06:53 EST. <199712140506.AAA17194@mutara.noc.erols.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Beginning SPARC port From: Jun-ichiro itojun Itoh Date: Sun, 14 Dec 1997 14:18:39 +0900 Message-ID: <16608.882076719@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> hardware I/O model is CPU specific. There are architectures >> that do not have inb/outb instruction, and maps I/O device control >> registers onto memory. I dunno how Sparc-with-PCI motherboard >> access pci registers, but I'm sure there has to be bunch of changes. >Right, but in that case you #define the inb/outb macros to be the >appropriate load/store instructions for the processor. >What I am trying to say is that while it may not be the Politically >Correct(TM) solution, it is not totally i386 bound either. Being >#defines, its a bit more flexible than you were making out. Yes, I agree with your idea, as the first step. In the future we should introduce some function like, pci_reg_write_byte(), for more platform-independency. Not all the implementers know about i386:-) itojun From owner-freebsd-hackers Sat Dec 13 21:32:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11049 for hackers-outgoing; Sat, 13 Dec 1997 21:32:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA11036 for ; Sat, 13 Dec 1997 21:32:21 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA09592; Sat, 13 Dec 1997 21:32:01 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712140532.VAA09592@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Jun-ichiro itojun Itoh cc: gjp@erols.net (Gary Palmer), hackers@freebsd.org Subject: Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 13:40:45 +0900." <16085.882074445@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 21:32:00 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is not really a problem since we also support i/o memory mapped registers for PCI devices. The thing to do is to get hold of a sparc architecture book and find out how they do i/o and then formulate a mapping. Cheers, Amancio > > >> pccard/pcic.c > >> pci/aic7870.c > >> pci/if_de.c > >> pci/ncr.c > >> pci/tek390.c > >> pci/wd82371.c > >What makes you think outb is i386 specific? Surely since it is defined > >in a machine header to some asm fn, what it really means is that > >it is GNU C specific? If you think about it, if a platform needed > >a bit of complexity to do inb/outb, you #define them to funciton > >calls. > > hardware I/O model is CPU specific. There are architectures > that do not have inb/outb instruction, and maps I/O device control > registers onto memory. I dunno how Sparc-with-PCI motherboard > access pci registers, but I'm sure there has to be bunch of changes. > > itojun > From owner-freebsd-hackers Sat Dec 13 21:51:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12169 for hackers-outgoing; Sat, 13 Dec 1997 21:51:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12163 for ; Sat, 13 Dec 1997 21:51:20 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA09724; Sat, 13 Dec 1997 21:51:11 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712140551.VAA09724@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Jun-ichiro itojun Itoh cc: gjp@erols.net (Gary Palmer), hackers@freebsd.org Subject: Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 14:18:39 +0900." <16608.882076719@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 21:51:10 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The functions is already there: old_irq = pci_conf_read(tag, PCI_INTERRUPT_REG); pci_conf_write(tag, PCI_INTERRUPT_REG, BROOKTREE_IRQ); And usually PCI devices have i/o mapped registers. Amancio > > >> hardware I/O model is CPU specific. There are architectures > >> that do not have inb/outb instruction, and maps I/O device control > >> registers onto memory. I dunno how Sparc-with-PCI motherboard > >> access pci registers, but I'm sure there has to be bunch of changes. > >Right, but in that case you #define the inb/outb macros to be the > >appropriate load/store instructions for the processor. > >What I am trying to say is that while it may not be the Politically > >Correct(TM) solution, it is not totally i386 bound either. Being > >#defines, its a bit more flexible than you were making out. > > Yes, I agree with your idea, as the first step. > In the future we should introduce some function like, > pci_reg_write_byte(), for more platform-independency. > Not all the implementers know about i386:-) > > itojun > From owner-freebsd-hackers Sat Dec 13 22:16:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13123 for hackers-outgoing; Sat, 13 Dec 1997 22:16:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13115 for ; Sat, 13 Dec 1997 22:16:13 -0800 (PST) (envelope-from wakkym@juno.com) Received: (from wakkym@juno.com) by m16.boston.juno.com (queuemail) id B}W21229; Sun, 14 Dec 1997 01:15:27 EST To: hackers@freebsd.org Subject: Re: Beginning SPARC port Message-ID: <19971214.011331.5303.2.wakkym@juno.com> References: <16085.882074445@coconut.itojun.org> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0,2-23,35 From: wakkym@juno.com (Lee Cremeans) Date: Sun, 14 Dec 1997 01:15:27 EST Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 14 Dec 1997 13:40:45 +0900 Jun-ichiro itojun Itoh writes: > >>> pccard/pcic.c >>> pci/aic7870.c >>> pci/if_de.c >>> pci/ncr.c >>> pci/tek390.c >>> pci/wd82371.c >>What makes you think outb is i386 specific? Surely since it is >defined >>in a machine header to some asm fn, what it really means is that >>it is GNU C specific? If you think about it, if a platform needed >>a bit of complexity to do inb/outb, you #define them to funciton >>calls. > > hardware I/O model is CPU specific. There are architectures > that do not have inb/outb instruction, and maps I/O device >control > registers onto memory. I dunno how Sparc-with-PCI motherboard > access pci registers, but I'm sure there has to be bunch of >changes. Why not make it so that the PCI chip stuff is accessed through a standard API, i.e. make something like a pci_machdep.c and put the architecture-specific details in there (each architecture that we have PCI support for would have its own version; in fact, it could be named something more orthogonal, like pci_sparc.c or pci_alpha.c or pci_i386.c), then make it so that the drivers operate through that? I'm operating on just a basic understanding of PCI programming, tho; I'm assuming, for example, that all PCI host-to-bus bridges have at least somewhat similar register interfaces, which may not be the case (I don't have any manuals here, and can't get them since I don't have a real Internet feed here anymore...). Of course, I guess that all that needs to be managed is the I/O details; it doesn't have to be very high-level. From owner-freebsd-hackers Sat Dec 13 22:17:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA13194 for hackers-outgoing; Sat, 13 Dec 1997 22:17:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from imo19.mx.aol.com (imo19.mx.aol.com [198.81.19.176]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13188 for ; Sat, 13 Dec 1997 22:17:29 -0800 (PST) (envelope-from StevenR362@aol.com) From: StevenR362 Message-ID: <7bb17179.3493790a@aol.com> Date: Sun, 14 Dec 1997 01:13:27 EST To: hackers@freebsd.org Subject: Unix Network Programming. Second Edition. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Organization: AOL (http://www.aol.com) X-Mailer: Inet_Mail_Out (IMOv11) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ISBN 0-13-490012-X is out now. I just picked up a copy today at the local Borders for $59.00 It is almost twice as thick as the first edition and only covers tcp/ip and XTI. There's also an acknowledgement for Freebsd's own Bill Fenner on page xix and a grammatical error on the bottom of page xv. ;) Steve From owner-freebsd-hackers Sat Dec 13 22:32:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14144 for hackers-outgoing; Sat, 13 Dec 1997 22:32:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14139 for ; Sat, 13 Dec 1997 22:32:26 -0800 (PST) (envelope-from wakkym@juno.com) Received: (from wakkym@juno.com) by m16.boston.juno.com (queuemail) id BCP21229; Sun, 14 Dec 1997 01:31:56 EST To: hackers@freebsd.org Subject: Re: Beginning SPARC port Message-ID: <19971214.012956.5303.3.wakkym@juno.com> References: <199712140551.VAA09724@rah.star-gate.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0,2-9,14 From: wakkym@juno.com (Lee Cremeans) Date: Sun, 14 Dec 1997 01:31:56 EST Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Dec 1997 21:51:10 -0800 Amancio Hasty writes: >The functions is already there: > > old_irq = pci_conf_read(tag, PCI_INTERRUPT_REG); > pci_conf_write(tag, PCI_INTERRUPT_REG, BROOKTREE_IRQ); > >And usually PCI devices have i/o mapped registers. On the i386, this is true, but (as has been said before, but I guess not as clearly) there are architectures out there that don't have an Intel-style I/O vs. memory addressing distinction (the 680x0s are like this, and I think the SPARC and PowerPC are also; not sure about Alpha), so they map all the device registers into physical memory space. From owner-freebsd-hackers Sat Dec 13 22:58:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15732 for hackers-outgoing; Sat, 13 Dec 1997 22:58:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15719 for ; Sat, 13 Dec 1997 22:58:44 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id WAA09916; Sat, 13 Dec 1997 22:58:35 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712140658.WAA09916@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: wakkym@juno.com (Lee Cremeans) cc: hackers@FreeBSD.ORG Subject: Re: Beginning SPARC port In-reply-to: Your message of "Sun, 14 Dec 1997 01:31:56 EST." <19971214.012956.5303.3.wakkym@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 22:58:35 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Which is fine for most PCI devices that I have at least programmed the registers are i/o mapped registers. pci_conf_read/pci_conf_write is a high level interface to the PCI registers now if you are looking for a higher abstraction please elaborate. Amancio > > On Sat, 13 Dec 1997 21:51:10 -0800 Amancio Hasty > writes: > >The functions is already there: > > > > old_irq = pci_conf_read(tag, PCI_INTERRUPT_REG); > > pci_conf_write(tag, PCI_INTERRUPT_REG, BROOKTREE_IRQ); > > > >And usually PCI devices have i/o mapped registers. > > On the i386, this is true, but (as has been said before, but I guess not > as clearly) there are architectures out there that don't have an > Intel-style I/O vs. memory addressing distinction (the 680x0s are like > this, and I think the SPARC and PowerPC are also; not sure about Alpha), > so they map all the device registers into physical memory space. > From owner-freebsd-hackers Sat Dec 13 23:19:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16845 for hackers-outgoing; Sat, 13 Dec 1997 23:19:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA16839 for ; Sat, 13 Dec 1997 23:19:17 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA01161; Sun, 14 Dec 1997 06:53:01 +0100 From: Luigi Rizzo Message-Id: <199712140553.GAA01161@labinfo.iet.unipi.it> Subject: Re: Proposed code merge, objections? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Dec 1997 06:53:01 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712131504.QAA22341@uriah.heep.sax.de> from "J Wunsch" at Dec 13, 97 04:03:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've been told there is no official policy on this, so I want some > > feedback. I am considering currently a merge of the alog driver > > (Industrial Computer Source AIO8-P) into -stable. > > -stable is not meant to accumulate new features from -current. Unless > there are strong reasons, new drivers should not migrate there. This > _is_ official policy. So to put things differently, what is the policy to move features from -current to -stable ? Unfortunately we don't have a port category for kernel enhancements, maybe we should add one. Lot of people prefer to run one version of the OS across different systems, and this is generally a RELEASE or -stable, and it is a bit too much to ask people to upgrade to -current to try out some (for them) interesting feature. For things like drivers etc we can gain a lot from testing on different hardware. I have had a lot of useful feedback from 2.2. users on the sound driver, infinitely more than what I got from -current users when the driver was integrated there. I think the same happened for the Bt848 driver. While it is ok to leave individuals (like me) put up a set of patches for a kernel enhancement, it is annoying for end users to follow the announcements on the list and hunt for such patches. It would be much more convenient to get them through the standard means (cvsup etc.) Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sat Dec 13 23:44:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18053 for hackers-outgoing; Sat, 13 Dec 1997 23:44:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp3.portal.net.au [202.12.71.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18048 for ; Sat, 13 Dec 1997 23:44:03 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id SAA05671; Sun, 14 Dec 1997 18:06:45 +1030 (CST) Message-Id: <199712140736.SAA05671@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed code merge, objections? In-reply-to: Your message of "Sun, 14 Dec 1997 06:53:01 BST." <199712140553.GAA01161@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Dec 1997 18:06:45 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I've been told there is no official policy on this, so I want some > > > feedback. I am considering currently a merge of the alog driver > > > (Industrial Computer Source AIO8-P) into -stable. > > > > -stable is not meant to accumulate new features from -current. Unless > > there are strong reasons, new drivers should not migrate there. This > > _is_ official policy. Particularly in the case of Jamil's driver, which is unlikely to be particularly useful to anyone other than Jamil as anything other than a sample. > So to put things differently, what is the policy to move features > from -current to -stable ? Unfortunately we don't have a port > category for kernel enhancements, maybe we should add one. If a feature is nonintrusive and subject to popular demand, migration after a vetting period in -current is worth considering. Also bear in mind that often things would make it back to -stable if there was someone that was a) using the feature and b) had the time and resources (eg. a -stable system) to do the backport with. mike From owner-freebsd-hackers Sat Dec 13 23:50:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18347 for hackers-outgoing; Sat, 13 Dec 1997 23:50:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA18338 for ; Sat, 13 Dec 1997 23:50:13 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA01235; Sun, 14 Dec 1997 07:23:43 +0100 From: Luigi Rizzo Message-Id: <199712140623.HAA01235@labinfo.iet.unipi.it> Subject: Re: Proposed code merge, objections? To: mike@smith.net.au (Mike Smith) Date: Sun, 14 Dec 1997 07:23:43 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712140736.SAA05671@word.smith.net.au> from "Mike Smith" at Dec 14, 97 06:06:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > -stable is not meant to accumulate new features from -current. Unless > > > there are strong reasons, new drivers should not migrate there. This > > > _is_ official policy. > > Particularly in the case of Jamil's driver, which is unlikely to be > particularly useful to anyone other than Jamil as anything other than a > sample. Still, it has a purpose. When I have a new piece of hardware I often have to go to Linux to find a driver (i.e. some source code documenting how to use it). > If a feature is nonintrusive and subject to popular demand, migration > after a vetting period in -current is worth considering. Also bear in > mind that often things would make it back to -stable if there was > someone that was a) using the feature and b) had the time and resources > (eg. a -stable system) to do the backport with. Jamil is doing a) and b), but I concede that in this case there might not be popular demand. Cheers Luigi From owner-freebsd-hackers Sat Dec 13 23:50:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18380 for hackers-outgoing; Sat, 13 Dec 1997 23:50:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18374 for ; Sat, 13 Dec 1997 23:50:35 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA15093; Sat, 13 Dec 1997 23:49:59 -0800 (PST) To: Luigi Rizzo cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed code merge, objections? In-reply-to: Your message of "Sun, 14 Dec 1997 06:53:01 +0100." <199712140553.GAA01161@labinfo.iet.unipi.it> Date: Sat, 13 Dec 1997 23:49:59 -0800 Message-ID: <15089.882085799@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So to put things differently, what is the policy to move features > from -current to -stable ? Unfortunately we don't have a port > category for kernel enhancements, maybe we should add one. After they've been well-tested, both in -current and in the committer's private 2.2 sources, they can go across just so long as they do not also constitute a signficant risk to functionality in other areas of the system. In the specific case of audio support, this means that it can migrate across no problem just so long as you don't break anything else in the 2.2 kernel in the process. :) Jordan From owner-freebsd-hackers Sun Dec 14 00:00:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA18931 for hackers-outgoing; Sun, 14 Dec 1997 00:00:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA18859 for ; Sun, 14 Dec 1997 00:00:12 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id XAA10171; Sat, 13 Dec 1997 23:59:57 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199712140759.XAA10171@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Proposed code merge, objections? In-reply-to: Your message of "Sun, 14 Dec 1997 06:53:01 +0100." <199712140553.GAA01161@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 23:59:57 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is an old problem that we are currently stuck with -- that is the need to have a 3.0 release which aint' going to happen anytime soon well at least according to the last thread that addressed such issue. New kernel features should go in -current. If we open the floodgate to 2.2-stable we may risk de-stabilizing that release;additionally, I don't enjoy too much "#if FreeBSD xxxx " or "#ifdef on the kernel. The Bt848 driver was entirely developed on -current the main bugs found across the board where specific to PCI chipsets --- natoma vs triton . Granted the test population was greater because the driver compiles on both 2.x systems and 3.0 -current systems. One issue that I see is that many are probably scare of 3.0 -current and are not willing upgrading to it. Perhaps we should try to generate a 3.0-release without SMP support or rather make it obviouse that is not yet ready and a little difficult to enable. Amancio > > > I've been told there is no official policy on this, so I want some > > > feedback. I am considering currently a merge of the alog driver > > > (Industrial Computer Source AIO8-P) into -stable. > > > > -stable is not meant to accumulate new features from -current. Unless > > there are strong reasons, new drivers should not migrate there. This > > _is_ official policy. > > So to put things differently, what is the policy to move features > from -current to -stable ? Unfortunately we don't have a port > category for kernel enhancements, maybe we should add one. > > Lot of people prefer to run one version of the OS across different > systems, and this is generally a RELEASE or -stable, and it is a > bit too much to ask people to upgrade to -current to try out some > (for them) interesting feature. > > For things like drivers etc we can gain a lot from testing on different > hardware. I have had a lot of useful feedback from 2.2. users on the sound > driver, infinitely more than what I got from -current users when the > driver was integrated there. I think the same happened for the Bt848 > driver. > > While it is ok to leave individuals (like me) put up a set of patches > for a kernel enhancement, it is annoying for end users to follow the > announcements on the list and hunt for such patches. It would be much > more convenient to get them through the standard means (cvsup etc.) > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > From owner-freebsd-hackers Sun Dec 14 00:00:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA19026 for hackers-outgoing; Sun, 14 Dec 1997 00:00:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA18970 for ; Sun, 14 Dec 1997 00:00:21 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA01277; Sun, 14 Dec 1997 07:33:58 +0100 From: Luigi Rizzo Message-Id: <199712140633.HAA01277@labinfo.iet.unipi.it> Subject: Re: Proposed code merge, objections? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 14 Dec 1997 07:33:58 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <15089.882085799@time.cdrom.com> from "Jordan K. Hubbard" at Dec 13, 97 11:49:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > After they've been well-tested, both in -current and in the > committer's private 2.2 sources, they can go across just so long as > they do not also constitute a signficant risk to functionality in > other areas of the system. In the specific case of audio support, > this means that it can migrate across no problem just so long as you > don't break anything else in the 2.2 kernel in the process. :) I was referring to the aio driver or other potentially interesting device drivers/kernel modules in -current (I have no current examples, but in the past it took some time to integrate the Bt848 and the kernel bootp support). I thought for audio I already got your blessing, I am just waiting for John Mark to do the dirty work :) Cheers Luigi