From owner-freebsd-hackers Sun Jun 28 09:49:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11320 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 09:49:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA11310 for ; Sun, 28 Jun 1998 09:49:13 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from (ragnet.demon.co.uk) [158.152.46.40] by post.mail.demon.net with smtp (Exim 1.82 #2) id 0yqKdV-0005XK-00; Sun, 28 Jun 1998 16:49:06 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 0yqFQh-0005zk-00; Sun, 28 Jun 1998 12:15:31 +0100 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 28 Jun 1998 12:15:31 +0100 (BST) From: Duncan Barclay To: freebsd-hackers@FreeBSD.ORG Subject: Old NE2000 card Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I have just dug out an old NE2000 NIC and plugged it into a -current box. The marked as SC+C. Does the iomem configuration setting actually matter, the driver seems to probe for it? I am getting "ed0: deive timeout" errors. Now I know that this means it didn't transmit anything, but why? This happenes when the card is unplugged from an ether net or when connected to a 3c509 in -stable box. Cable and terminators are fine. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 12:29:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29344 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 12:29:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from duey.hs.wolves.k12.mo.us (root@duey.hs.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29338 for ; Sun, 28 Jun 1998 12:29:29 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.hs.wolves.k12.mo.us (cdillon@duey.hs.wolves.k12.mo.us [207.160.214.9]) by duey.hs.wolves.k12.mo.us (8.8.7/8.8.7) with SMTP id OAA22942; Sun, 28 Jun 1998 14:29:29 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Sun, 28 Jun 1998 14:29:28 -0500 (CDT) From: Chris Dillon X-Sender: cdillon@duey.hs.wolves.k12.mo.us Reply-To: Chris Dillon To: Mike Tancsa cc: hackers@FreeBSD.ORG Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? In-Reply-To: <3595e10d.1180692826@mail.sentex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 28 Jun 1998, Mike Tancsa wrote: > On Thu, 25 Jun 1998 23:32:35 -0500 (CDT), in sentex.lists.freebsd.misc > you wrote: > >Within the next few months, i will be needing to set up a router for our > >internal network, tying together 7 networks, with some room to grow. I > >plan on buying a rather expensive chassis from Industrial Computer source. > > You could probably buy 3 plain-jane pentiums for the price of the > fancy one you are talking about and not have to worry about cramming > so many cards into one box and overloading the PCI bus. If the boxes > are going to act as routers and NAT machines, you really dont need > that much horse power/RAM/HD space. Where did I mention how much RAM and HD space I was going to use? :-) I do know that those are not something you need an excess of for a router (RAM, sometimes). I only planned on putting 64MB ECC SDRAM in it. It could probably do with 16 or 32, but RAM is cheap these days. I would even do without an HD (without moving parts, that is), if I could. I'm thinking about using these flash based drives I've been seeing lately, if the price is right. Even PicoBSD on a floppy (or bootable ZIP disk?) might be an option. As for the horsepower, the more the better, since it would increase my peak bandwidth capacity (assuming the bus isn't already saturated, which it shouldn't be) and reduce latency. It is true that going with something ultra-fast means a lot of heat, and reduced reliability and life. I do agree that multiple cheaper boxes might be better for removing a single point of failure (i.e., if one box failed, the networks on that box would be separated, but the rest would be communicating), but that would require a few more NICs total (not a big deal cost-wise), a switch to interconnect all of them (now we're talking money, and if not a switch, then a hub, or then even more NICs are required for point-to-point links between boxes). I'd be shoving each of these machines totally full of NICs for interconnection along with the NICs required to service the our networks, filling up their relatively small PCI busses. The total cost is back up to where it was with the single high-capacity high-reliability machine, and complexity is increased by several orders of magnitude. I'm going to take a quick guess at how I could use multiple boxes, just to see if it would work for me. Assuming I used common motherboards with 4 PCI slots, I would need one NIC for interconnection, leaving three slots free for our internal networks. So, I'd need three of these boxes and a switch for the interconnection. Four boxes if I want to grow. The switch just became a single point of failure, not to mention a 100Mbit/sec bottleneck between any two boxes. So, instead, I put two NICs in each machine for interconnection, creating some kind of simple star or ring. This still creates a sort of bottleneck between boxes, but increases availability significantly. With two slots free, I'd now need four boxes to meet my needs, five for growth. Using boards with 5 PCI slots would change this scenario a little bit, but would still pretty much stick me in the same boat, especially if I grow. Basically, I'm just buying a box with 9 PCI slots. If I grow past 8 networks (which I seriously doubt), I'll buy another and I'll have "multiple" boxes to share the job. :-) I do believe in splitting up work between multiple boxes when possible, but in _this particular scenario_, it just doesn't seem ultimately feasable. I do appreciate all of the comments people are giving me. That was the secondary reason why I posted the question to the list (first being wether what I had originally planned would actually work), rather than go blindly. :-) All of the responses to this point have made me think twice about one thing or another, or altered my direction slightly. Your response, Mike, along with Kevin's from Atipa, made me think about how I actually _could_ use multiple boxes, which I basically just laid out above. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) (http://www.freebsd.org) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 16:20:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA24041 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 16:20:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA24020 for ; Sun, 28 Jun 1998 16:20:37 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA20233; Sun, 28 Jun 1998 16:20:32 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd020200; Sun Jun 28 16:20:28 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA14794; Sun, 28 Jun 1998 16:20:11 -0700 (MST) From: Terry Lambert Message-Id: <199806282320.QAA14794@usr07.primenet.com> Subject: Re: Adding a new user interface to FreeBSD administration To: mike@smith.net.au (Mike Smith) Date: Sun, 28 Jun 1998 23:20:11 +0000 (GMT) Cc: njs3@doc.ic.ac.uk, jkh@time.cdrom.com, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199806271900.MAA15753@antipodes.cdrom.com> from "Mike Smith" at Jun 27, 98 12:00:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What do you mean Jordan? A windows style registry? LDAP? > > Why do people insist on calling it "windows style"? We *definitely* > need to dig up old Apollo machines and hand them around; preferably > bouncing them off peoples' toes as we do. Heh. Actually, I almost have code for reading and writing the Windows 95 registry under FreeBSD. I decided to do it after someone who didn't know what they were talking about told me it wasn't possible. I figured it's be useful for Windows 95 emulation anyway, so I figured "what the heck?". So if you *really* want a "Windows style Registry"... > If you want to play more with LDAP, Netscape have released their client > API sources under the NPL; see http://www.mozilla.org. It builds > shiny-clean under FreeBSD (which is a supported platform); this in > conjunction with the UMich server gives us lots of infrastructure. So do the UMich API's, and the JavaSoft JNDI API's. > If you're looking for a topic worth some serious discussion and perhaps > debate, how about considering a naming scheme suitable for storing > parametric attributes including, but not limited to: > > - system configuration data, both per-system and per-system-group (eg. > netgroup) > - application configuration, where the identifying tokens may include > user, user-group, application, application-group, system, > system-group. > - user parametric information, per-user and per-user-group. > > Note that there are probably already RFCs covering some or all of these > topics, with their own pros and cons. I'm inclined to hand the torch > to Terry here, as this is more his domain than mine. Heh. Yes, there are RFC's that cover all of this. Specifically, the RFC's covering SNMP have established an IANA registry for schema information. Pretty much anything you'd ever want to store in the way of system configuration information has been spec'ed out already, and has a published standard. If nothing else, it would be truly worthwhile to sit down with the schema information from Cisco, Ascend, Livingston, and others, and just go through FreeBSD to see if it can do everything and keeps all the relevent statistics, etc., that the schema's claim the other boxes can do. It would be a heck of an easy process, and it would yield a list of places in FreeBSD where statistics should be kept and aren't being kept, as well as more than a handful of new features that probably wouldn't be that hard to implement. 8-). If you want my interpretation of Netscape's schema, I can send you my netscape.at.conf and netscape.oc.conf. I also have oc's for: RFC 2248: Network Services Monitoring MIB RFC 2307: An Approach for Using LDAP as a Network Information Service RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 1838: Using X.500 for mapping Internet mail RFC 2249: Mail Monitoring MIB Which taken together cover most of the stuff in /etc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 16:50:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28610 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 16:50:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA28548; Sun, 28 Jun 1998 16:50:13 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: by outmail.utsunomiya-u.ac.jp id AA11052; Mon, 29 Jun 1998 08:48:53 +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 IAA21811; Mon, 29 Jun 1998 08:58:02 +0900 (JST) Message-Id: <199806282358.IAA21811@zodiac.mech.utsunomiya-u.ac.jp> To: Brian McGovern Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: PS/2 problem In-Reply-To: Your message of "Fri, 26 Jun 1998 14:46:44 -0400." <199806261846.OAA00230@bmcgover-pc.cisco.com> References: <199806261846.OAA00230@bmcgover-pc.cisco.com> Date: Mon, 29 Jun 1998 08:58:01 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Thats what I get for fancy fingers.... Hit Save/Send too soon. Here is the -v ~~~~~~~~~~~~~~~~~~~~~~~ What does this mean? Kazu >output of my screwy PS/2 port... > >psm0: current command byte:0047 >kbdio: TEST_AUX_PORT status:00fa >kbdio: DIAGNOSE status:0055 >kbdio: TEST_KBD_PORT status:00fa >psm: keyboard port failed. >psm0: the aux port is not functioning (250). >psm0 not found at 0x60 > > -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 18:54:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15254 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 18:54:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15216 for ; Sun, 28 Jun 1998 18:53:52 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id LAA05389; Mon, 29 Jun 1998 11:21:51 +0930 (CST) Message-Id: <199806290151.LAA05389@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joao Carlos Mendes Luis cc: jkh@time.cdrom.com (Jordan K. Hubbard), fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Wed, 24 Jun 1998 04:04:43 -0300." <199806240704.EAA23043@roma.coe.ufrj.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 11:21:51 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > // If we're going to do something now, let's stick with 90's techniques > // at least. :-) > Could you please elaborate on this ? My preferred technique for > system configuration is vi. Are there any others ? :))) I use vi too, but I don't like having to change about 5 files to change my hostname or IP :) --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 19:05:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA16495 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 19:05:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-04.waterford.indigo.ie [194.125.139.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA16489 for ; Sun, 28 Jun 1998 19:05:04 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id DAA02262 for hackers@freebsd.org; Mon, 29 Jun 1998 03:01:12 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199806290201.DAA02262@indigo.ie> Date: Mon, 29 Jun 1998 03:01:12 +0000 Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: hackers@FreeBSD.ORG Subject: writing to ppp interfaces using bpf Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, bpf(4) say: "Currently, only writes to Ethernets and SLIP links are supported." It looks like it would only take a few lines of code to fix this, does anyone know otherwise? As the ppp driver prepends the header surely a case statement can simply be added in bpf_movein... Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 20:22:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27192 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 20:22:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27183; Sun, 28 Jun 1998 20:22:12 -0700 (PDT) (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.8/8.8.8) with ESMTP id UAA01191; Sun, 28 Jun 1998 20:21:40 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: postmaster@FreeBSD.ORG cc: hackers@FreeBSD.ORG Subject: Too much spam from uu.net Date: Sun, 28 Jun 1998 20:21:40 -0700 Message-ID: <1186.899090500@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for the -hackers posting here, but this will reach the people most likely to be affected. Despite their frequent protests to the contrary, uu.net remains the single largest origin of spam abuse for our mailing lists and their policy of apparently re-selling dialup access to secondary ISPs who do *not* necessarily have to have stringent anti-spam policies of their own only makes this even worse. After the most recent spamming from one of "uu.net's" dialups (and god only knows which affiliate is actually responsible for it), I've taken it upon myself to add them to freebsd.org's spammer list. This is a purely provisional move until we figure out how extensive the side-effects of this will be, it perhaps becoming a permanant block if the problem does not abate and not too terribly many folks are inconvenienced by it. From those who will get much less spam as a result of this move, I also doubt that too many tears will be shed for uu.net. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 20:48:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29759 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 20:48:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29754 for ; Sun, 28 Jun 1998 20:48:28 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id NAA01415; Mon, 29 Jun 1998 13:18:15 +0930 (CST) Message-ID: <19980629131815.M897@freebie.lemis.com> Date: Mon, 29 Jun 1998 13:18:15 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net References: <1186.899090500@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <1186.899090500@time.cdrom.com>; from Jordan K. Hubbard on Sun, Jun 28, 1998 at 08:21:40PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 28 June 1998 at 20:21:40 -0700, Jordan K. Hubbard wrote: > Sorry for the -hackers posting here, but this will reach the people > most likely to be affected. > > Despite their frequent protests to the contrary, uu.net remains the > single largest origin of spam abuse for our mailing lists and their > policy of apparently re-selling dialup access to secondary ISPs who do > *not* necessarily have to have stringent anti-spam policies of their > own only makes this even worse. After the most recent spamming from > one of "uu.net's" dialups (and god only knows which affiliate is > actually responsible for it), I've taken it upon myself to add them to > freebsd.org's spammer list. This is a purely provisional move until > we figure out how extensive the side-effects of this will be, it > perhaps becoming a permanant block if the problem does not abate and > not too terribly many folks are inconvenienced by it. From those who > will get much less spam as a result of this move, I also doubt that > too many tears will be shed for uu.net. How many mailing list users will this affect? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 21:05:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01627 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 21:05:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01615 for ; Sun, 28 Jun 1998 21:05:07 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id BAA00702; Mon, 29 Jun 1998 01:03:59 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806290403.BAA00702@roma.coe.ufrj.br> Subject: Re: Adding a new user interface to FreeBSD administration In-Reply-To: <199806290151.LAA05389@cain.gsoft.com.au> from Daniel O'Connor at "Jun 29, 98 11:21:51 am" To: doconnor@gsoft.com.au (Daniel O'Connor) Date: Mon, 29 Jun 1998 01:03:59 -0300 (EST) Cc: jonny@jonny.eng.br, jkh@time.cdrom.com, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG #define quoting(Daniel O'Connor) // > // If we're going to do something now, let's stick with 90's techniques // > // at least. :-) // > Could you please elaborate on this ? My preferred technique for // > system configuration is vi. Are there any others ? :))) // I use vi too, but I don't like having to change about 5 files to change my // hostname or IP :) Where do you have to edit other than /etc/rc.local ? If you have a firewall you'll have to edit anyway, or do you trust your firewall to a script ? :) Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 21:05:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01647 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 21:05:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01622 for ; Sun, 28 Jun 1998 21:05:10 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id NAA06987; Mon, 29 Jun 1998 13:34:35 +0930 (CST) Message-Id: <199806290404.NAA06987@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stephen Hocking-Senior Programmer PGS Tensor Perth cc: hackers@FreeBSD.ORG Subject: Re: Extracting RPM archives In-reply-to: Your message of "Sat, 27 Jun 1998 17:08:07 +0800." <199806270908.RAA15353@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 13:34:35 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yeah I know it's from that other Unix, but does anyone have a tool to do this > (I'm trying to extract the sources to the 3dfx device drivers and all the > latest Linux Glide libs). Install rpm /usr/ports/misc/rpm and then you can use rpm2cpio to get the archive out of it.. --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 22:01:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06043 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 22:01:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles338.castles.com [208.214.167.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06038 for ; Sun, 28 Jun 1998 22:01:49 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA22579; Sun, 28 Jun 1998 22:02:17 -0700 (PDT) Message-Id: <199806290502.WAA22579@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Darren Reed cc: hackers@FreeBSD.ORG Subject: Re: 2940UW boot w/ JAZ on 2.2.5 In-reply-to: Your message of "Sat, 27 Jun 1998 18:07:56 +1000." <199806270808.BAA04309@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Jun 1998 22:02:17 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On bootup with a JAZ drive, I ejected the cartridge and FreeBSD failed to > boot up. > > Heaps of messages about SCB's timing out, ahc0 not responding, unknowns, > etc. > > Curiously it is scanning all the targets and all their LUNs. Will have > to wait longer to see if it actually boots, it's quite slow this :) Sounds like you really confused something. My recommendation would be "don't do that again". 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 22:08:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06692 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 22:08:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles338.castles.com [208.214.167.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06661; Sun, 28 Jun 1998 22:08:31 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA22615; Sun, 28 Jun 1998 22:09:17 -0700 (PDT) Message-Id: <199806290509.WAA22615@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: fewtch@serv.net cc: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Syquest SparQ Parallel Port driver... In-reply-to: Your message of "Sat, 27 Jun 1998 13:23:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Jun 1998 22:09:15 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Greetings, > > Anyone know if anybody is working on a FreeBSD driver for the Syquest SparQ > parallel port drive, or if such a driver exists already in a beta stage? I've > contacted ShuttleTech as well (probably useless) about this requesting any info. > they can provide. Thanks for any info (plz Email me direct), The SparQ parallel-port drive is unlikely to be supported unless you can obtain programming documentation for the interface they are using. And I might add that I would *not* be recommending that you purchase one of thes revolting units. The IDE model, for example, is held together with sticky tape, and the rest of the unit continues this fine standard of design and manufacture. In addition to this, the unit doesn't appear to honour any of the standard protocols for removable ATA devices, so you can, eg. remove the disk while the drive is actuve. My advice: buy a Jaz and a Jaz Traveller (both of which we support). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jun 28 22:34:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09716 for freebsd-hackers-outgoing; Sun, 28 Jun 1998 22:34:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09706 for ; Sun, 28 Jun 1998 22:34:09 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ("port 2950"@[139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IYT81B5DA8004MVJ@gatekeeper.alcatel.com.au> for hackers@FreeBSD.ORG; Mon, 29 Jun 1998 14:10:35 +1000 Received: from gsms01.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IYT7YS54QOB2B64L@cim.alcatel.com.au> for hackers@FreeBSD.ORG; Mon, 29 Jun 1998 14:09:20 +1000 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id OAA02425 for hackers@FreeBSD.ORG; Mon, 29 Jun 1998 14:09:22 +1000 (EST) Date: Mon, 29 Jun 1998 14:09:22 +1000 (EST) From: Peter Jeremy Subject: Re: FreeBSD faster than light? To: hackers@FreeBSD.ORG Message-id: <199806290409.OAA02425@gsms01.alcatel.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jun 1998 13:58:47 +0200 (MET DST), Rudolf wrote: >Greg Lehey writes: >> === grog@freebie (/dev/ttyp1) ~ 9 -> time l -rt Mail|wc >> 3460 31133 192864 >> >> real 0m0.517s >> user 0m1.230s >> sys 0m0.270s > >Hmm. It looks like as bash and its bug (I think). It may not be related to Greg's problem, but zsh's automatic timing feature (controlled via $REPORTTIME) tends to get confused by the time taken by background processes. It seems that if a background process terminates, the user/sys times taken by that process will be added to the user/sys times for the next foreground process - leading to some spectacularly wrong values when you exit from a background emacs or netscape. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 02:37:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA10075 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 02:37:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from albert.osu.cz (albert.osu.cz [195.113.106.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA10059 for ; Mon, 29 Jun 1998 02:36:55 -0700 (PDT) (envelope-from belkovic@albert.osu.cz) Received: from localhost (belkovic@localhost) by albert.osu.cz (8.8.5/8.6.12) with SMTP id LAA01116 for ; Mon, 29 Jun 1998 11:38:07 +0200 (MET DST) Date: Mon, 29 Jun 1998 11:38:06 +0200 (MET DST) From: Josef Belkovics To: freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My home pc (Cyrix 486DX4) does not a CPU reset via the keyboard controller > > or via invltbl() (/sys/i386/i386/vm_machdep.c). Is somebody able to say me > > patch which will reset through bios. Or in some other way. (Don't write - > > throw it out.) > > Write your own, if it matters that much to you. Look at how the VM86 > stuff calls the BIOS, find a suitable BIOS vector, and try it. > And if you manage to do it, please contribute the code! When I was a > FreeBSD newbie, I was stuck with such a motherboard. I switched to > FreeBSD from Linux, and I could reboot it with "reboot=bios" in Linux. > A friend of mine, and more experienced FreeBSD hacker, made a valiant > effort to port the code, but we never did get it to work. I've ditched > that motherboard (and the next one), but enough people still ask about > this problem that I would like to be able to point to a fix. > Does it have a PCI or EISA bus? There are PCI and EISA resets... Only ISA bus. > I would recommend disassembling the keyboard portion of the BIOS to > see what it's doing so you can duplicate it... Keyboard comes from xt (and has switch for xt/at). Probably its controller does not know about 'cpu reset' command. And 'cyrix 486dx4' certainly does not understand idea in invltbl(). I will try in asembler only following: a) i change cpu mode from protected to 'normal' b) i change appropriate segment registers c) i change appropriate bios constant to enable warm post d) i will call appropritae bios function (int 19h ?) Code will be on place of invltbl() in vm_machdep.c. This is only cca 10 instructions. Maybe it would try more experienced FreeBSD hacker. (Good example I saw in /sys/boot/biosboot. (I did hier quick hack to change vga palette register for white and green - the change in ?.h file for syscons.c left _white_ cursor - terrible.)) Josef Belkovics To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 03:34:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA19359 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 03:34:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA19350 for ; Mon, 29 Jun 1998 03:34:03 -0700 (PDT) (envelope-from fullermd@shell.futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) id FAA24889; Mon, 29 Jun 1998 05:33:38 -0500 (CDT) Message-ID: <19980629053338.28271@futuresouth.com> Date: Mon, 29 Jun 1998 05:33:38 -0500 From: "Matthew D. Fuller" To: Duncan Barclay Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Old NE2000 card References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Duncan Barclay on Sun, Jun 28, 1998 at 12:15:31PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 28, 1998 at 12:15:31PM +0100, Duncan Barclay woke me up to tell me: > Hi > > I have just dug out an old NE2000 NIC and plugged it into a -current box. > The marked as SC+C. Does the iomem configuration setting actually matter, > the driver seems to probe for it? > > I am getting "ed0: deive timeout" errors. Now I know that this means > it didn't transmit anything, but why? This happenes when the card is > unplugged from an ether net or when connected to a 3c509 in -stable box. > > Cable and terminators are fine. Well, when it's not connected, that's kinda expected. I get this all the time when I disconnect a system from a hub, etc. And for connecting to the other box, I assume you DID use a crossover cable, right? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 03:48:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA20873 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 03:48:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA20860 for ; Mon, 29 Jun 1998 03:48:31 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id MAA17491 for ; Mon, 29 Jun 1998 12:47:59 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id MAA07403; Mon, 29 Jun 1998 12:47:57 +0200 To: hackers@FreeBSD.ORG Subject: mmap() with stdin/stdout Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 29 Jun 1998 12:47:56 +0200 Message-ID: Lines: 10 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is it possible to mmap() STD{IN,OUT,ERR}_FILENO? If so, what are the semantics of a read past EOF? BTW, 'advice' (the noun) is misspelt as 'advise' in the mincore(2) and madvise(2) man pages. The spelling of madvise() may also be construed as a bug unless one argues that 'advise' (the verb) is intended. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 04:15:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA25714 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 04:15:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA25684 for ; Mon, 29 Jun 1998 04:15:27 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id NAA18978 ; Mon, 29 Jun 1998 13:14:50 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id NAA07444; Mon, 29 Jun 1998 13:14:49 +0200 To: Josef Belkovics Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 29 Jun 1998 13:14:49 +0200 In-Reply-To: Josef Belkovics's message of Mon, 29 Jun 1998 11:38:06 +0200 (MET DST) Message-ID: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Josef Belkovics writes: > I will try in asembler only following: > a) i change cpu mode from protected to 'normal' > b) i change appropriate segment registers > c) i change appropriate bios constant to enable warm post > d) i will call appropritae bios function (int 19h ?) No, jo do a long jump to FFFF:0 IIRC. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 04:20:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA26708 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 04:20:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yoda.pi.musin.de (yoda.pi.musin.de [194.246.250.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA26618 for ; Mon, 29 Jun 1998 04:20:06 -0700 (PDT) (envelope-from sec@yoda.pi.musin.de) Received: (from sec@localhost) by yoda.pi.musin.de (8.8.8/8.8.8) id NAA14685 for freebsd-hackers@freebsd.org; Mon, 29 Jun 1998 13:20:03 +0200 (CEST) (envelope-from sec) Message-ID: <19980629132002.A13667@yoda.pi.musin.de> Date: Mon, 29 Jun 1998 13:20:02 +0200 From: Stefan Zehl To: freebsd-hackers@FreeBSD.ORG Subject: Staroffice 4.0 sp3 running Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.6i I-love-doing-this: really X-URL: http://sec.42.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I just managed to install Staroffice 4.0sp3. It requires the file /proc//cmdline to run. Fortunately due to the linux emulation layer, you can guess the PID the running process will have, and touch /compat/linux/proc//cmdline - this will suffice for it to run. I have just added (an dummy-version of) cmdline in my local copy of procfs, but I remember that there was some talk, not to 'bloat' procfs with such things. I'm basdically asking now, which route do we want to take ? an addition to our procfs ? an seperate linux-procfs ? CU, Sec -- Komme wieder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 05:03:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03200 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 05:03:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from main.sgca.com ([209.210.33.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03194 for ; Mon, 29 Jun 1998 05:03:47 -0700 (PDT) (envelope-from freebsd@main.sgca.com) Received: (from freebsd@localhost) by main.sgca.com (8.8.8/8.8.8) id FAA03690 for freebsd-hackers@freebsd.org; Mon, 29 Jun 1998 05:03:37 -0700 (PDT) (envelope-from freebsd) From: Java dev Message-Id: <199806291203.FAA03690@main.sgca.com> Subject: Re: Old NE2000 card To: freebsd-hackers@FreeBSD.ORG Date: Mon, 29 Jun 1998 05:03:37 -0700 (PDT) In-Reply-To: <19980629053338.28271@futuresouth.com> from "Matthew D. Fuller" at "Jun 29, 98 05:33:38 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, Jun 28, 1998 at 12:15:31PM +0100, Duncan Barclay woke me up to tell me: > > Hi > > > > I have just dug out an old NE2000 NIC and plugged it into a -current box. > > The marked as SC+C. Does the iomem configuration setting actually matter, > > the driver seems to probe for it? > > > > I am getting "ed0: deive timeout" errors. Now I know that this means > > it didn't transmit anything, but why? This happenes when the card is > > unplugged from an ether net or when connected to a 3c509 in -stable box. > > > > Cable and terminators are fine. > > Well, when it's not connected, that's kinda expected. I get this all the > time when I disconnect a system from a hub, etc. > And for connecting to the other box, I assume you DID use a crossover > cable, right? I would say a wrong interupt(sp). Also, I do not think a crossover could be a problem here (10Base-T does not use terminators...:)). GB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 05:06:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03716 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 05:06:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03710 for ; Mon, 29 Jun 1998 05:06:49 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id OAA22112 ; Mon, 29 Jun 1998 14:06:13 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id OAA07491; Mon, 29 Jun 1998 14:06:13 +0200 To: Josef Belkovics Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 29 Jun 1998 14:06:13 +0200 In-Reply-To: smoergrd@oslo.geco-prakla.slb.com's message of 29 Jun 1998 13:14:49 +0200 Message-ID: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) writes: > Josef Belkovics writes: > > I will try in asembler only following: > > a) i change cpu mode from protected to 'normal' > > b) i change appropriate segment registers > > c) i change appropriate bios constant to enable warm post > > d) i will call appropritae bios function (int 19h ?) > No, jo do a long jump to FFFF:0 IIRC. -- Now what's going on in my mind? s/jo/just/ Anyway, I have a BIOS reference somewhere at home, so just nag me and I'll give you the address for the warm boot flag and the jump target. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 06:17:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11857 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 06:17:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from albert.osu.cz (albert.osu.cz [195.113.106.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA11841 for ; Mon, 29 Jun 1998 06:17:31 -0700 (PDT) (envelope-from belkovic@albert.osu.cz) Received: from localhost (belkovic@localhost) by albert.osu.cz (8.8.5/8.6.12) with SMTP id PAA01866; Mon, 29 Jun 1998 15:18:46 +0200 (MET DST) Date: Mon, 29 Jun 1998 15:18:46 +0200 (MET DST) From: Josef Belkovics To: Dag-Erling Coidan Smørgrav cc: freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id GAA11843 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29 Jun 1998, Dag-Erling Coidan Smørgrav wrote: > smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) writes: > > Josef Belkovics writes: > > > I will try in asembler only following: > > > a) i change cpu mode from protected to 'normal' > > > b) i change appropriate segment registers > > > c) i change appropriate bios constant to enable warm post > > > d) i will call appropritae bios function (int 19h ?) > > No, jo do a long jump to FFFF:0 IIRC. (I don't use x11 or emacs to read mail. So my answers take long.) > Now what's going on in my mind? s/jo/just/ I don't understand well 'you do a long jump to ffff:0' (+ what means iirc?). I suppose that if i am in real (or 'normal') cpu mode, then i can do 'int ?h'. I am not interesting what 'int ?h' really does - maybe long jump to ffff:0 etc. (Probably long jump to ffff:0 is one from more ways how to call bios function 'reset'.) I look at problem from my knowledge database about FreeBSD asembler (nothing) and about c+asm+bios under dos (good). I wrote mail, because i don't know FreeBSD-asembler syntax for a) and b) points - so I must look for it under /sys with undecided result. > Anyway, I have a BIOS reference somewhere at home, so just nag me and > I'll give you the address for the warm boot flag and the jump target. I don't need bios reference (I have it at home). To be continued next day... Josef Belkovics To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 06:31:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14627 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 06:31:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14602 for ; Mon, 29 Jun 1998 06:31:04 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id PAA27108 ; Mon, 29 Jun 1998 15:30:23 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id PAA07596; Mon, 29 Jun 1998 15:30:22 +0200 To: Josef Belkovics Cc: Dag-Erling Coidan Smørgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 29 Jun 1998 15:30:22 +0200 In-Reply-To: Josef Belkovics's message of Mon, 29 Jun 1998 15:18:46 +0200 (MET DST) Message-ID: Lines: 47 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Josef Belkovics writes: > On 29 Jun 1998, Dag-Erling Coidan Sm=F8rgrav wrote: > > smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Sm=F8rgrav) writes: > > > Josef Belkovics writes: > > > > d) i will call appropritae bios function (int 19h ?) > > > No, jo do a long jump to FFFF:0 IIRC. > I don't understand well 'you do a long jump to ffff:0' (+ what means > iirc?). I suppose that if i am in real (or 'normal') cpu mode, then i can IIRC = If I Recall Correctly > do 'int ?h'. I am not interesting what 'int ?h' really does - maybe long No. int 19h is supposed to "reboot the disk system", but as often as not it's not properly implemented. Even when it is, it does not reboot the system, but simply tries to load the MBR from whatever floppy or hard disk is first in the boot sequence. This is not what you want to do, because you have no guarantee that FreeBSD has left the system in a state that is usable for the next OS. You want to perform a complete reboot, either cold or warm (the only difference I know of is that the BIOS will skip the RAM test during a warm reboot). The only way to do a warm reboot is to write 1234h to a specific address which I do not recall at this moment, and do a far jump to FFFF:0. The code at that address is usually just a trampoline which jumps to the correct (but system-specific) point in BIOS ROM. Trust me, I *know* that stuff. I grew up with DEBUG.COM and Ralf's interrupt list as my two closest friends. > jump to ffff:0 etc. (Probably long jump to ffff:0 is one from more ways > how to call bios function 'reset'.) I look at problem from my knowledge Not one of several ways, but the only way. > database about FreeBSD asembler (nothing) and about c+asm+bios under dos > (good). Apparently not complete. > I wrote mail, because i don't know FreeBSD-asembler syntax for a)= It's not 'FreeBSD-assembler syntax", but AT&T assembler syntax, upon which gas (the GNU assembler), which FreeBSD uses, is based. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 06:33:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14936 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 06:33:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA14923 for ; Mon, 29 Jun 1998 06:33:27 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA07423; Mon, 29 Jun 1998 09:32:47 -0400 Date: Mon, 29 Jun 1998 09:32:46 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: I2O Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG at usenix last week the question of I2O came up. Don't worry about I2O. Look around: how many I2O motherboards do you see, as compared to non-I2O motherboards? Look at it this way: you think microsoft is that interested in requiring a second operating system (vxworks) to make NT go? I2O will be a footnote in a year or so. After that, it will be forgotten and in 10 years someone else will reinvent the idea and learn the hard way why it is a bad one (as I2O is itself a reinvention of old, bad ideas). ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 06:47:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17555 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 06:47:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA17550; Mon, 29 Jun 1998 06:47:52 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA07546; Mon, 29 Jun 1998 09:47:22 -0400 Date: Mon, 29 Jun 1998 09:47:22 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: looking for ram file system (NOT MFS) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm looking for something like a ram file system for some work i'm doing. It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be BSD or GPL copyright, and run under current. Any pointers appreciated. thanks ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 06:57:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19245 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 06:57:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from main.fiscodata.com.br (main.fiscodata.com.br [200.250.227.210]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA19191 for ; Mon, 29 Jun 1998 06:57:18 -0700 (PDT) (envelope-from paulo@main.fiscodata.com.br) Received: (from paulo@localhost) by main.fiscodata.com.br (8.8.8/8.8.5) id KAA23032; Mon, 29 Jun 1998 10:34:28 -0300 (EST) Date: Mon, 29 Jun 1998 10:34:28 -0300 (EST) Message-Id: <199806291334.KAA23032@main.fiscodata.com.br> From: Paulo Cesar Pereira de Andrade To: joelh@gnu.org CC: rssh@grad.kiev.ua, J.Hogeveen@twiddle.com, freebsd-hackers@FreeBSD.ORG In-reply-to: "joelh@gnu.org"'s message of Sat, 27 Jun 1998 00:28:18 -0500 (CDT) Subject: Re: Signal-11 References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG |> Date: Sat, 27 Jun 1998 00:28:18 -0500 (CDT) |> From: Joel Ray Holveck What I was saying is that it is possible to get the same error again and again if the vm is corrupted somewhere. |> Sounds like a problem with your RAM, cache ram, MB, or uP, with RAM |> being the most likely. You're not overclocking, are you? (If you |> are, just set it to spec and try again, and *don't* mention it to the |> list right now; I don't want to have to delete the ensuing rubbish.) Yes, I do overclock it. I even run -CURRENT on it. Since it does not have a floppy drive, last time I did a full reload, I installed the 2.1.6 bindist loading sysinstall with fbsdboot.exe, installed 2.2.5 over it by hand from a CheapBytes CDROM, cvsupped -CURRENT and built world. To get it to recognize whatever is in the secondary ide, I need to compile a kernel with: options DISABLE_PCI_IDE. One of these days I will try Linux on it. Statistically, it crashes more frequently if running under spec (and crashes the same way under 2.2.5 and 3.0). When it is in a good mood, it will build world several times in a row (6-8 hours every one). I never experienced a crash when running Windows on it (mostly for games, but survived very well a 60min session trying to stress it to the maximum, while compiling some large programs with BC 4.5). The crashes have become more commom after adding a new 2GB IDE to it. I have noticed that enabling APM in the BIOS reduced the crashes. It is test machine. The machine I do my serious work runs -STABLE and has a 46 days uptime record (was down for a kernel upgrade). |> Happy hacking, |> joelh |> |> -- |> Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan |> Fourth law of programming: |> Anything that can go wrong wi |> sendmail: segmentation violation - core dumped You can press 'd' now :) Paulo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 07:27:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24572 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 07:27:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA24565 for ; Mon, 29 Jun 1998 07:27:37 -0700 (PDT) (envelope-from Mailer-Daemon@East.Sun.COM) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA13317 for ; Mon, 29 Jun 1998 07:27:04 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id KAA21118; Mon, 29 Jun 1998 10:27:01 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id KAA13680; Mon, 29 Jun 1998 10:27:01 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.8/8.7.3) id JAA02711; Mon, 29 Jun 1998 09:26:47 -0500 (CDT) From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 Jun 1998 09:26:36 -0500 (CDT) X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Reply-To: alk@pobox.com To: hackers@FreeBSD.ORG Subject: Re: Draft manpages available for review X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13719.41931.325896.490475@compound.east> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do we have any convention in our manpages for which dialect of English > spelling to use? I suggest Chaucerian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 07:40:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26693 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 07:40:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26685 for ; Mon, 29 Jun 1998 07:40:23 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-92.camalott.com [208.229.74.92]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id JAA15094; Mon, 29 Jun 1998 09:39:56 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id JAA02540; Mon, 29 Jun 1998 09:40:15 -0500 (CDT) (envelope-from joelh) Date: Mon, 29 Jun 1998 09:40:15 -0500 (CDT) Message-Id: <199806291440.JAA02540@detlev.UUCP> To: smoergrd@oslo.geco-prakla.slb.com CC: belkovic@albert.osu.cz, freebsd-hackers@FreeBSD.ORG In-reply-to: (smoergrd@oslo.geco-prakla.slb.com) Subject: Re: BROKEN_KEYBOARD_RESET From: Joel Ray Holveck Reply-to: joelh@gnu.org References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I will try in asembler only following: >> a) i change cpu mode from protected to 'normal' >> b) i change appropriate segment registers >> c) i change appropriate bios constant to enable warm post >> d) i will call appropritae bios function (int 19h ?) > No, jo do a long jump to FFFF:0 IIRC. I thought it was F000:0... You may want to consult the pink shirt book. (Mine's 90 miles away right now, sorry.) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 08:25:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04281 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 08:25:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.ny.otec.com (bright.ny.otec.com [209.3.16.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04232; Mon, 29 Jun 1998 08:25:06 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.ny.otec.com (8.8.8/8.8.8) with SMTP id LAA00305; Mon, 29 Jun 1998 11:21:08 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.ny.otec.com: bright owned process doing -bs Date: Mon, 29 Jun 1998 11:21:08 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.ny.otec.com To: Richard Goh cc: "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG try: device ed0 at pci? in your kernel config, worked for me, but i don't rember my chipset. or whatever isa card it is kinda like. it might just work. -Alfred On Sat, 27 Jun 1998, Richard Goh wrote: > HI, > Has anyone got the driver to work yet? > Just bought an Advantech panel pc thinking that "NE2000 compatible" was > all i needed. > Needless to say, countless rebuilds later ..... > > Thanks for any tips. > Rgds > Richard > > > > On Tue, 17 Mar 1998, Eivind Eklund wrote: > > > On Tue, Mar 17, 1998 at 08:04:15AM -0500, Timothy M. Hughes wrote: > > > Has anyone got one of these things to work yet?? I mailed > > > questions@freebsd.org and got a response that it was "probably" a > > > proprietary driver. If you have a driver or have gotten it to work, > > > please email me directly (I dont subscibe). > > > > RealTek is fairly good at supporting free OSes (even sometimes writing > > drivers themselves). > > > > I don't think you should have a problem getting info from them, but it > > is probably correct that it is a properitary chip (probably with an > > almost complete clone of the interface of a popular chipset, so making > > drivers work should be easy). > > Unlike the 8019/8029 (which are NE2000 clones), the 8129/8139 appear to > be their own design and not compatible with anything else. However, > datasheets that look complete enough to write a driver are available on > their website (www.realtek.com.tw), and there also exists a Linux driver > to crib from (see http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html ) > > [Sorry if you see two copies of this - I think I killed the one with an > incorrect URL, but it may have escaped] > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > > > > > www@freebsd.org > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 09:06:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11682 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 09:06:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11677 for ; Mon, 29 Jun 1998 09:06:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id JAA00334; Mon, 29 Jun 1998 09:05:37 -0700 (PDT) Message-Id: <199806291605.JAA00334@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Josef Belkovics cc: freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET In-reply-to: Your message of "Mon, 29 Jun 1998 11:38:06 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 09:05:37 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > My home pc (Cyrix 486DX4) does not a CPU reset via the keyboard controller > > > or via invltbl() (/sys/i386/i386/vm_machdep.c). Is somebody able to say me > > > patch which will reset through bios. Or in some other way. (Don't write - > > > throw it out.) > > > > Write your own, if it matters that much to you. Look at how the VM86 > > stuff calls the BIOS, find a suitable BIOS vector, and try it. > > > And if you manage to do it, please contribute the code! When I was a > > FreeBSD newbie, I was stuck with such a motherboard. I switched to > > FreeBSD from Linux, and I could reboot it with "reboot=bios" in Linux. > > > A friend of mine, and more experienced FreeBSD hacker, made a valiant > > effort to port the code, but we never did get it to work. I've ditched > > that motherboard (and the next one), but enough people still ask about > > this problem that I would like to be able to point to a fix. > > > Does it have a PCI or EISA bus? There are PCI and EISA resets... > > Only ISA bus. > > > I would recommend disassembling the keyboard portion of the BIOS to > > see what it's doing so you can duplicate it... > > Keyboard comes from xt (and has switch for xt/at). Probably its controller > does not know about 'cpu reset' command. And 'cyrix 486dx4' certainly does > not understand idea in invltbl(). The cpu reset command is normally performed by the keyboard controller, not the keyboard itself. > I will try in asembler only following: > a) i change cpu mode from protected to 'normal' > b) i change appropriate segment registers > c) i change appropriate bios constant to enable warm post > d) i will call appropritae bios function (int 19h ?) Sounds pretty good; you may have some fun going back to real mode though - you will have to copy your code down below the 1M mark. Have a look at the way the APM stuff does it, as it has to do basically the same thing (although it saves a lot of state that you can safely discard). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 09:11:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12300 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 09:11:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12293 for ; Mon, 29 Jun 1998 09:10:59 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id JAA00380; Mon, 29 Jun 1998 09:10:36 -0700 (PDT) Message-Id: <199806291610.JAA00380@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stefan Zehl cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running In-reply-to: Your message of "Mon, 29 Jun 1998 13:20:02 +0200." <19980629132002.A13667@yoda.pi.musin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 09:10:36 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > I just managed to install Staroffice 4.0sp3. > > It requires the file /proc//cmdline to run. Amazingly enough, it seems that Linux doesn't actually have /proc/curproc, which would have made this a lot simpler. > I have just added (an dummy-version of) cmdline in my local copy of > procfs, but I remember that there was some talk, not to 'bloat' procfs > with such things. The real issue is that the Linux and FreeBSD procfs' have different semantics. > I'm basdically asking now, which route do we want to take ? > an addition to our procfs ? an seperate linux-procfs ? We need a separate linux-procfs as part of the linux emulator; it should mount itself on /compat/linux/procfs. If you're interested in taking this on (please!), I'm sure we can arrange any support that you might need. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 09:29:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15270 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 09:29:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from horton.iaces.com (horton.iaces.com [204.147.87.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15251; Mon, 29 Jun 1998 09:29:42 -0700 (PDT) (envelope-from proot@horton.iaces.com) Received: (from proot@localhost) by horton.iaces.com (8.8.7/8.8.7) id LAA10456; Mon, 29 Jun 1998 11:28:12 -0500 (CDT) From: "Paul T. Root" Message-Id: <199806291628.LAA10456@horton.iaces.com> Subject: Re: looking for ram file system (NOT MFS) In-Reply-To: from "Ron G. Minnich" at "Jun 29, 1998 9:47:22 am" To: rminnich@sarnoff.com (Ron G. Minnich) Date: Mon, 29 Jun 1998 11:28:11 -0500 (CDT) Cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG X-Organization: USWEST !nterprise Networking - ACES X-Phone: (612) 664-3385 X-Fax: (612) 664-4779 X-Page: (800) SKY-PAGE PIN: 537-7270 X-Address: 600 Stinson Blvd, Fl 1S X-Address: Minneapolis, MN 55413 X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In a previous message, Ron G. Minnich said: > I'm looking for something like a ram file system for some work i'm doing. > It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be > BSD or GPL copyright, and run under current. Any pointers appreciated. mfs -- You men out there probably think you already know how to dress for success. You know, for example, that you should not wear leisure suits or white plastic belts and shoes, unless you are going to a costume party disguised as a pig farmer vacationing at Disney World. -- Dave Barry, "How to Dress for Real Success" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 10:08:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21794 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 10:08:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21720; Mon, 29 Jun 1998 10:08:26 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199806291708.KAA21720@hub.freebsd.org> Subject: Re: Too much spam from uu.net In-Reply-To: <19980629131815.M897@freebie.lemis.com> from Greg Lehey at "Jun 29, 98 01:18:15 pm" To: grog@lemis.com (Greg Lehey) Date: Mon, 29 Jun 1998 10:08:21 -0700 (PDT) Cc: jkh@time.cdrom.com, 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 Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > On Sunday, 28 June 1998 at 20:21:40 -0700, Jordan K. Hubbard wrote: > > Sorry for the -hackers posting here, but this will reach the people > > most likely to be affected. > > > > Despite their frequent protests to the contrary, uu.net remains the > > single largest origin of spam abuse for our mailing lists and their > > policy of apparently re-selling dialup access to secondary ISPs who do > > *not* necessarily have to have stringent anti-spam policies of their > > own only makes this even worse. After the most recent spamming from > > one of "uu.net's" dialups (and god only knows which affiliate is > > actually responsible for it), I've taken it upon myself to add them to > > freebsd.org's spammer list. This is a purely provisional move until > > we figure out how extensive the side-effects of this will be, it > > perhaps becoming a permanant block if the problem does not abate and > > not too terribly many folks are inconvenienced by it. From those who > > will get much less spam as a result of this move, I also doubt that > > too many tears will be shed for uu.net. > > How many mailing list users will this affect? there are only three mailing lists subscribers from uu.net. surprising but true. so far no one has sent mail to the lists from uu.net in today's /var/log/maillog. hmm.... jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 10:27:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25064 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 10:27:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25052 for ; Mon, 29 Jun 1998 10:27:32 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id NAA28340; Mon, 29 Jun 1998 13:24:39 -0400 (EDT) Date: Mon, 29 Jun 1998 13:24:38 -0400 (EDT) From: "Larry S. Lile" To: hackers@FreeBSD.ORG Subject: Blocked interrupts? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am still working on a token-ring driver but I am now having a problem with interrupt blocking. The card inserts into the ring and interrupts the driver, but after that I get no more interrupts from the card until I reset the interrupt circuit on the card. The source for the Mach and AIX drivers I have looked at do not appear to have this problem. I was hoping someone could show me the error of my ways and help me get moving again. In one of the interrupt status registers of the card (isrp_h) before the interrupt it is 0x0, then when I enable interrupts on the card it becomes 0x40, it then interrupts the driver and goes to 0x42. This is the problem the 0x2 (in 0x42) says that all interrupts from the card are being blocked and no matter what I do (short of a reset on the interrupt circuit on the card) I cannot get the card unblocked. Any ideas or help? Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 10:32:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26236 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 10:32:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA26231; Mon, 29 Jun 1998 10:32:38 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id NAA08991; Mon, 29 Jun 1998 13:31:36 -0400 Date: Mon, 29 Jun 1998 13:31:36 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: "Paul T. Root" cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: looking for ram file system (NOT MFS) In-Reply-To: <199806291628.LAA10456@horton.iaces.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Paul T. Root wrote: > In a previous message, Ron G. Minnich said: > > I'm looking for something like a ram file system for some work i'm doing. > > It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be > > BSD or GPL copyright, and run under current. Any pointers appreciated. > mfs like i said, mfs won't do. It's neat, but it won't do. I have to be able to take control at lookup(), etc. I can write this, but it will save me time if there's one out there I can start from. thanks ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 11:14:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05037 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 11:14:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mushi.colo.neosoft.com (qmailr@mushi.colo.neosoft.com [206.109.6.82]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA04968 for ; Mon, 29 Jun 1998 11:13:47 -0700 (PDT) (envelope-from peter@taronga.com) Received: (qmail 4410 invoked from network); 29 Jun 1998 18:13:37 -0000 Received: from bonkers.neosoft.com (HELO bonkers.taronga.com) (root@206.109.2.48) by mushi.colo.neosoft.com with SMTP; 29 Jun 1998 18:13:37 -0000 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id NAA17351; Mon, 29 Jun 1998 13:13:34 -0500 Date: Mon, 29 Jun 1998 13:13:34 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199806291813.NAA17351@bonkers.taronga.com> To: hackers@FreeBSD.ORG, tlambert@primenet.com Newsgroups: taronga.freebsd.hackers Subject: Re: Adding a new user interface to FreeBSD administration References: <199806271900.MAA15753@antipodes.cdrom.com> <199806282320.QAA14794@usr07.primenet.com> Organization: none Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199806282320.QAA14794@usr07.primenet.com>, Terry Lambert wrote: >Heh. Actually, I almost have code for reading and writing the >Windows 95 registry under FreeBSD. I decided to do it after >someone who didn't know what they were talking about told me it >wasn't possible. I figured it's be useful for Windows 95 emulation >anyway, so I figured "what the heck?". > >So if you *really* want a "Windows style Registry"... Actually, you know, a registry implemented as Windows-style INI files would be pretty easy to hand-edit OR machine-edit. It's one of the few things that Microsoft came up with (if they did, I wouldn't be surprised to learn that they just appropriated something some app was using) that's actually reasonably well designed. And it'd make it REALLY easy to slip Samba in... -- This is The Reverend Peter da Silva's Boring Sig File - there are no references to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 11:42:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11387 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 11:42:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11256 for ; Mon, 29 Jun 1998 11:42:03 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA21196; Mon, 29 Jun 1998 11:42:00 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd021125; Mon Jun 29 11:41:51 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA21198; Mon, 29 Jun 1998 11:41:46 -0700 (MST) From: Terry Lambert Message-Id: <199806291841.LAA21198@usr01.primenet.com> Subject: Re: mmap() with stdin/stdout To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Sm?rgrav) Date: Mon, 29 Jun 1998 18:41:45 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Sm?rgrav" at Jun 29, 98 12:47:56 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > BTW, 'advice' (the noun) is misspelt as 'advise' in the mincore(2) and > madvise(2) man pages. The spelling of madvise() may also be construed > as a bug unless one argues that 'advise' (the verb) is intended. The verb is intended. The "madvise(2)" call _advises_ the kernel about your intended use of the memory. The first misspelling noted, however, is indeed an error... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 11:43:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11546 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 11:43:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun1 (bingsun1.cc.binghamton.edu [128.226.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA11416 for ; Mon, 29 Jun 1998 11:42:52 -0700 (PDT) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun1 (SMI-8.6/8.6.9) with SMTP id OAA19468 for ; Mon, 29 Jun 1998 14:42:26 -0400 Date: Mon, 29 Jun 1998 14:42:25 -0400 (EDT) From: zhihuizhang X-Sender: bf20761@bingsun1 Reply-To: zhihuizhang To: hackers Subject: Interrupt Handling and inline assembly Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got two questions: (1) I read in the MailingList Archive that the interrupt blocking in FreeBSD is software-based, we do not communicate with 8259 (which I think is slower) What is the advantage of doing this besides being faster? If we mask interrupts off (by cli or setting the IMR register in 8259), will interrupts be simply discarded (the device has to request interrupt again) or postponed by 8259? (2) I am reading the source code in cpufunc.h: static __inline void setbits(volatile unsigned * addr, u_int bits) { __asm __volatile("orl %1, %0" : "=m" (*addr): "ir"(bits)); } I have read a text on inline assembly at: http://www.rt66.com/~brennan/djgpp/djgpp_asm.html But I still do not understand the meaining of "m" and "ir". Thanks a lot. ------------------------------------------------- Zhihui Zhang Department of Computer Science State University of New York at Binghamton Web Site: http://cs.binghamton.edu/~zzhang ------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 11:53:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13875 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 11:53:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.ny.otec.com (bright.ny.otec.com [209.3.16.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA13754 for ; Mon, 29 Jun 1998 11:52:53 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.ny.otec.com (8.8.8/8.8.8) with SMTP id OAA00890 for ; Mon, 29 Jun 1998 14:52:55 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.ny.otec.com: bright owned process doing -bs Date: Mon, 29 Jun 1998 14:52:55 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.ny.otec.com To: hackers@FreeBSD.ORG Subject: Re: looking for ram file system (NOT MFS) In-Reply-To: <199806291628.LAA10456@horton.iaces.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG well if someone would re-do mfs it would be cool :) from what the 4.4 book says it's not exaclty the model of efficiency something about redundant memory to memory copies and the fact that it's a FFS in memory which makes sense from a certain elegancy point of code reuse, but not optimization for the media type (ie. virtual cylinders in memory :) ) of course i'm speaking from my ass as i haven't really looked if it has been rehauled. :) -Alfred On Mon, 29 Jun 1998, Paul T. Root wrote: > In a previous message, Ron G. Minnich said: > > I'm looking for something like a ram file system for some work i'm doing. > > It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be > > BSD or GPL copyright, and run under current. Any pointers appreciated. > > mfs > > > -- > You men out there probably think you already know how to dress for > success. You know, for example, that you should not wear leisure suits > or white plastic belts and shoes, unless you are going to a costume > party disguised as a pig farmer vacationing at Disney World. > -- Dave Barry, "How to Dress for Real Success" > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 11:57:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14721 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 11:57:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA14637 for ; Mon, 29 Jun 1998 11:57:03 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA27583; Mon, 29 Jun 1998 11:56:53 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd027558; Mon Jun 29 11:56:47 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA22133; Mon, 29 Jun 1998 11:56:41 -0700 (MST) From: Terry Lambert Message-Id: <199806291856.LAA22133@usr01.primenet.com> Subject: Re: Draft manpages available for review To: alk@pobox.com Date: Mon, 29 Jun 1998 18:56:41 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <13719.41931.325896.490475@compound.east> from "Tony Kimball" at Jun 29, 98 09:26:36 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 Precedence: bulk X-Loop: FreeBSD.ORG > > Do we have any convention in our manpages for which dialect of English > > spelling to use? > > I suggest Chaucerian. I do thync thast dielactic "ispell" hast its head o' rein. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:00:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15604 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:00:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from thor.afnetinc.com ([207.179.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15192; Mon, 29 Jun 1998 11:59:27 -0700 (PDT) (envelope-from efinley@castlenet.com) Received: from di-r1.afnetinc.com (di-r1.afnetinc.com [207.179.61.196]) by thor.afnetinc.com (8.8.8/8.8.7) with SMTP id MAA05204; Mon, 29 Jun 1998 12:56:34 -0600 (MDT) (envelope-from efinley@castlenet.com) From: efinley@castlenet.com (Elliot Finley) To: Richard Goh Cc: "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card Date: Mon, 29 Jun 1998 18:56:37 GMT Organization: Hiawatha Coal Company Reply-To: efinley@castlenet.com Message-ID: <359ae341.2257050@afnetinc.com> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 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 LAA15215 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Jun 1998 14:37:03 +0800, you wrote: I was unable to get my 8129 to work... Had to go back to the 8029.. >HI, >Has anyone got the driver to work yet? >Just bought an Advantech panel pc thinking that "NE2000 compatible" was >all i needed. >Needless to say, countless rebuilds later ..... > >Thanks for any tips. >Rgds >Richard > > > >On Tue, 17 Mar 1998, Eivind Eklund wrote: > >> On Tue, Mar 17, 1998 at 08:04:15AM -0500, Timothy M. Hughes wrote: >> > Has anyone got one of these things to work yet?? I mailed >> > questions@freebsd.org and got a response that it was "probably" a >> > proprietary driver. If you have a driver or have gotten it to work, >> > please email me directly (I dont subscibe). >> >> RealTek is fairly good at supporting free OSes (even sometimes writing >> drivers themselves). >> >> I don't think you should have a problem getting info from them, but it >> is probably correct that it is a properitary chip (probably with an >> almost complete clone of the interface of a popular chipset, so making >> drivers work should be easy). > >Unlike the 8019/8029 (which are NE2000 clones), the 8129/8139 appear to >be their own design and not compatible with anything else. However, >datasheets that look complete enough to write a driver are available on >their website (www.realtek.com.tw), and there also exists a Linux driver >to crib from (see http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html ) > >[Sorry if you see two copies of this - I think I killed the one with an >incorrect URL, but it may have escaped] > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" in the body of the message > > > > >www@freebsd.org > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" in the body of the message > -- Later Science (efinley@castlenet.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:19:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA19692 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:19:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from animaniacs.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA19676 for ; Mon, 29 Jun 1998 12:18:54 -0700 (PDT) (envelope-from jamie@itribe.net) Received: from localhost (jamie@localhost) by animaniacs.itribe.net (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA02592; Mon, 29 Jun 1998 15:18:17 -0400 Date: Mon, 29 Jun 1998 15:18:17 -0400 (EDT) From: Jamie Bowden To: "Ron G. Minnich" cc: hackers@FreeBSD.ORG Subject: Re: I2O In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Ron G. Minnich wrote: > at usenix last week the question of I2O came up. > > Don't worry about I2O. Look around: how many I2O motherboards do you see, > as compared to non-I2O motherboards? > > Look at it this way: you think microsoft is that interested in requiring > a second operating system (vxworks) to make NT go? > > I2O will be a footnote in a year or so. After that, it will be forgotten > and in 10 years someone else will reinvent the idea and learn the hard > way why it is a bad one (as I2O is itself a reinvention of old, bad ideas). Why is offloading IO a bad idea? Offloading video and 3D rendering work well, it's what drives 3dfx and it's competitors. Or am I missing something? My basic understanding of I2O is using a subprocessor to handle all IO, thus freeing up the main processor from doing things like waiting on interrupts and the like. -- 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) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:29:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15456 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:00:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15298 for ; Mon, 29 Jun 1998 11:59:50 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.0/8.9.0) with ESMTP id UAA19951 for ; Mon, 29 Jun 1998 20:58:44 +0200 (MET DST) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.8/8.8.5) with ESMTP id UAA07423 for ; Mon, 29 Jun 1998 20:59:16 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id UAA28313 for ; Mon, 29 Jun 1998 20:59:43 +0200 (CEST) From: Andre Albsmeier Message-Id: <199806291859.UAA28827@internal> Subject: Re: Staroffice 4.0 sp3 running In-Reply-To: <199806291610.JAA00380@dingo.cdrom.com> from Mike Smith at "Jun 29, 98 09:10:36 am" To: mike@smith.net.au (Mike Smith) Date: Mon, 29 Jun 1998 20:59:40 +0200 (CEST) Cc: sec@yoda.pi.musin.de, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hi, > > > > I just managed to install Staroffice 4.0sp3. > > > > It requires the file /proc//cmdline to run. > > Amazingly enough, it seems that Linux doesn't actually have /proc/curproc, > which would have made this a lot simpler. > > > I have just added (an dummy-version of) cmdline in my local copy of > > procfs, but I remember that there was some talk, not to 'bloat' procfs > > with such things. Well, this is what I have done: 1. Unpack the sp3 distribution 2. cd into the Install directory (where setup.bin is) 3. sed -e 's,/proc/%u/cmdline,/tmp/so40cmdline,' < setup.bin > setup.new 4. mv setup.new setup.bin 5. chmod 755 setup.bin 6. touch /tmp/so40cmdline 7. ./setup Maybe I missed some step but this is closely what I have done. However, the installed thing doesn't run properly and consumes only cpu time but I hadn't had time to investigate this yet... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:34:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21803 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:34:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA21784 for ; Mon, 29 Jun 1998 12:33:55 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA09752; Mon, 29 Jun 1998 15:31:57 -0400 Date: Mon, 29 Jun 1998 15:31:57 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Jamie Bowden cc: hackers@FreeBSD.ORG Subject: Re: I2O In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Jamie Bowden wrote: > Why is offloading IO a bad idea? Offloading video and 3D rendering work > well, it's what drives 3dfx and it's competitors. Or am I missing > something? My basic understanding of I2O is using a subprocessor to > handle all IO, thus freeing up the main processor from doing things like > waiting on interrupts and the like. 3dfx is not offloading io. It's offloading computation to a special-purpose processor. Offloading IO can be a good thing in some circumstances if done properly. I2O was not. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:36:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22379 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:36:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22354 for ; Mon, 29 Jun 1998 12:36:43 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id MAA16138; Mon, 29 Jun 1998 12:36:10 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id MAA12996; Mon, 29 Jun 1998 12:36:08 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id MAA26508; Mon, 29 Jun 1998 12:35:49 -0700 (PDT) From: Don Lewis Message-Id: <199806291935.MAA26508@salsa.gv.tsc.tdk.com> Date: Mon, 29 Jun 1998 12:35:48 -0700 In-Reply-To: Chris Dillon "Re: Will 8 Intel EtherExpress PRO 10/100's be a problem?" (Jun 26, 5:47pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Chris Dillon , Ulf Zimmermann Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? Cc: Atipa , hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jun 26, 5:47pm, Chris Dillon wrote: } Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? } On Fri, 26 Jun 1998, Ulf Zimmermann wrote: } } > On Fri, Jun 26, 1998 at 11:03:01AM -0500, Chris Dillon wrote: } > > On Thu, 25 Jun 1998, Atipa wrote: } > > I'm rather hoping that three 133MB/sec PCI busses won't have any trouble } > > passing at max about 30MB/sec worth of data (10MB/sec per card, three } > > cards per bus). Theoretically even one PCI bus could handle all 8 of } > > those cards.. _theoretically_... :-) } > } > Double that number, Full Duplex is what you usual now use in routers. } > I also wouldn't say the single bus is the problem, but the main PCI bus and } > the CPU will be a bottleneck. You will definatly not be able to run 8 } > cards at full speed (8 x 10Mbyte/sec x 2 (FullDuplex) = 160 MByte/sec) You can only use Full Duplex if the port is connected directly to another host or to a switch. From the initial description it sounded like each port would be connected to a number of other hosts through a hub, which would require Half Duplex to be used. } Doh.. I knew that, but didn't put that in my calculation. Anyway, I'm not } needing full wire-speed from these things. I think I'd be happy with } 1/5th that. :-) I'm expecting that if ftp.freebsd.org can do about, } 5MB/sec on average, along with thousands of FTP clients, without breaking } a sweat on a PPro200, then a PII-350 or 400 should be able to do } line-speed at least between two networks at a time. If and when I do } this, expect me to perform some benchmarks. :-) With FTP clients, a sizeable percentage of the packets will be large and will account for most of the bandwidth. You may find yourself running out of CPU if much of your bandwidth is used by small packets, since there is a fixed amount of per-packet CPU overhead. We found out that while our Cisco 4000 can run at wire speed (10 Mb/s) while forwarding our normal traffic mix which contains many large packets, it runs out of CPU if it gets blasted with tinygrams. } As for the "main PCI bus" being the bottleneck, I'm really hoping they } used three host-to-PCI bridges, and not a single host-to-PCI bridge and } two PCI-to-PCI bridges. Even if not, I could push about 100MB/sec across } the bus (assuming the CPU could push that), and thats more than enough } for me. I suspect that it only has one host-to-PCI bridge, since the silicon is pretty common for that. Supporting multiple host-to-PCI bridges would either require a custom chipset with multiple bridges built in (which would require a *lot* of pins), or would require bridge chips that can arbitrate for access on the host side. The latter would be difficult to get to work because of the high speeds on the host side of the bridge. } I imagine a Cisco of _equal price_ wouldn't even come close to the } throughput I'm going to do. I could be wrong, of course. When I was looking a for a router to support a handful of 100 Mb/s ports, I came to the conclusion that it would be a lot cheaper to build it with a PC rather than buying a Cisco with enough grunt. On the low end, a Cisco solution is more reasonably priced and has fewer pieces to break, and the PC solution runs out of gas on the high end. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:36:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22397 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:36:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA22378 for ; Mon, 29 Jun 1998 12:36:53 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA29543 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Mon, 29 Jun 1998 21:11:04 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA03545 for FreeBSD-hackers@freebsd.org; Mon, 29 Jun 1998 21:03:33 +0200 (CEST) From: Wilko Bulte Message-Id: <199806291903.VAA03545@yedi.iaf.nl> Subject: FreeBSD-proven DLT2000 drive FS To: FreeBSD-hackers@FreeBSD.ORG (FreeBSD hackers list) Date: Mon, 29 Jun 1998 21:03:33 +0200 (CEST) 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.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for the commercial, but as backup devices have been subject of heated debate here: FS one DLT2000, incl one data and one cleaning cartridge. US$ 700, buyer pays shipping. Works like a charm on FreeBSD, but I now have a DLT4000. Please reply to me directly and *NOT* to the list. W/ _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:53:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25386 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:53:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.atipa.com (altrox.atipa.com [208.128.22.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA25273 for ; Mon, 29 Jun 1998 12:52:49 -0700 (PDT) (envelope-from freebsd@atipa.com) Received: (qmail 7922 invoked by uid 1017); 29 Jun 1998 18:49:45 -0000 Date: Mon, 29 Jun 1998 12:49:45 -0600 (MDT) From: Atipa To: Don Lewis cc: Chris Dillon , Ulf Zimmermann , hackers@FreeBSD.ORG Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? In-Reply-To: <199806291935.MAA26508@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > } Doh.. I knew that, but didn't put that in my calculation. Anyway, I'm not > } needing full wire-speed from these things. I think I'd be happy with > } 1/5th that. :-) I'm expecting that if ftp.freebsd.org can do about, > } 5MB/sec on average, along with thousands of FTP clients, without breaking > } a sweat on a PPro200, then a PII-350 or 400 should be able to do > } line-speed at least between two networks at a time. If and when I do > } this, expect me to perform some benchmarks. :-) > > With FTP clients, a sizeable percentage of the packets will be large > and will account for most of the bandwidth. You may find yourself > running out of CPU if much of your bandwidth is used by small packets, > since there is a fixed amount of per-packet CPU overhead. We found out > that while our Cisco 4000 can run at wire speed (10 Mb/s) while forwarding > our normal traffic mix which contains many large packets, it runs out of > CPU if it gets blasted with tinygrams. I think a P2 would keep up... > } As for the "main PCI bus" being the bottleneck, I'm really hoping they > } used three host-to-PCI bridges, and not a single host-to-PCI bridge and > } two PCI-to-PCI bridges. Even if not, I could push about 100MB/sec across > } the bus (assuming the CPU could push that), and thats more than enough > } for me. > > I suspect that it only has one host-to-PCI bridge, since the silicon is > pretty common for that. Supporting multiple host-to-PCI bridges would > either require a custom chipset with multiple bridges built in (which > would require a *lot* of pins), or would require bridge chips that can > arbitrate for access on the host side. The latter would be difficult > to get to work because of the high speeds on the host side of the bridge. It would almost certainly be a single bridge chip at 133MB/sec access to CPU and RAM, and 133MB/sec for all inter-PCI transport. > } I imagine a Cisco of _equal price_ wouldn't even come close to the > } throughput I'm going to do. I could be wrong, of course. > > When I was looking a for a router to support a handful of 100 Mb/s ports, > I came to the conclusion that it would be a lot cheaper to build it with > a PC rather than buying a Cisco with enough grunt. On the low end, a > Cisco solution is more reasonably priced and has fewer pieces to break, > and the PC solution runs out of gas on the high end. That's why I receommended mulitple PC's, for redundancy and scalability. Any time you buy weird stuff (like the mobo he wants), you pay a high price, and run the risk of obscurity on the support side. Unless he wants to buy one of those boards for each of the core arch developers, he'd not have a lot of luck w/ patches, etc. Mainstream stuff is well tested, easy to replace, and cheap to acquire. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 12:59:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26266 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 12:59:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26242 for ; Mon, 29 Jun 1998 12:59:08 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA25013; Mon, 29 Jun 1998 12:58:59 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd024981; Mon Jun 29 12:58:54 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA04488; Mon, 29 Jun 1998 12:58:47 -0700 (MST) From: Terry Lambert Message-Id: <199806291958.MAA04488@usr08.primenet.com> Subject: Re: Adding a new user interface to FreeBSD administration To: peter@taronga.com (Peter da Silva) Date: Mon, 29 Jun 1998 19:58:47 +0000 (GMT) Cc: hackers@FreeBSD.ORG, tlambert@primenet.com In-Reply-To: <199806291813.NAA17351@bonkers.taronga.com> from "Peter da Silva" at Jun 29, 98 01:13:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, you know, a registry implemented as Windows-style INI files > would be pretty easy to hand-edit OR machine-edit. It's one of the few > things that Microsoft came up with (if they did, I wouldn't be surprised > to learn that they just appropriated something some app was using) that's > actually reasonably well designed. And it'd make it REALLY easy to slip > Samba in... ??? Samba implements a .INI file manipulation library. But it is evil. The reason for the Windows 95 registry implementation was the explosive proliferation of .INI files. I would hate for FreeBSD to go down that road; it's already partly there, and that's what FreeBSD has been moving *away* from. Consider an installation of a tool that requires a shared library; the shared library is reference counted in the Windows 95 Registry so that (1) it can be deleted when it is no longer referenced, and (2) so that it is not delete prematurely as part of a deinstall. The ability to reuse shared objects without damaging the ability to deinstall them is precisely the reason for a *central* information repository. Granted, that's less of an issue for FreeBSD, since there is so very little commercial software available. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 13:01:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26572 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 13:01:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA26515 for ; Mon, 29 Jun 1998 13:00:55 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d84.syd2.zeta.org.au [203.26.11.84]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id GAA16251 for ; Tue, 30 Jun 1998 06:00:44 +1000 Received: (qmail 20730 invoked by uid 1000); 29 Jun 1998 06:24:34 -0000 Message-ID: <19980629162434.A20703@reilly.home> Date: Mon, 29 Jun 1998 16:24:34 +1000 From: Andrew Reilly To: Terry Lambert , Mike Smith Cc: njs3@doc.ic.ac.uk, jkh@time.cdrom.com, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration References: <199806271900.MAA15753@antipodes.cdrom.com> <199806282320.QAA14794@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806282320.QAA14794@usr07.primenet.com>; from Terry Lambert on Sun, Jun 28, 1998 at 11:20:11PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 28, 1998 at 11:20:11PM +0000, Terry Lambert wrote: > > > What do you mean Jordan? A windows style registry? LDAP? > > If nothing else, it would be truly worthwhile to sit down with the > schema information from Cisco, Ascend, Livingston, and others, and > just go through FreeBSD to see if it can do everything and keeps all > the relevent statistics, etc., that the schema's claim the other > boxes can do. It would be a heck of an easy process, and it would > yield a list of places in FreeBSD where statistics should be kept > and aren't being kept, as well as more than a handful of new features > that probably wouldn't be that hard to implement. 8-). Sorry for leaping into this late, (and consequently getting the wrong people on the To: line), but what's the "90's" way of handling the genuinely script-like things in /etc? I can see how a unified parameter/value store would be a great advance for most things, but how do you do: /etc/ppp/ppp.linkup.foo, the script that is executed by the !bg line at the bottom of your ppp.linkup file. /etc/{daily,weekly,monthly} ? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 13:30:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA02627 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 13:30:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tarsier.ca.sandia.gov (tarsier.ca.sandia.gov [146.246.246.124]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA02495 for ; Mon, 29 Jun 1998 13:30:04 -0700 (PDT) (envelope-from cc@tarsier.ca.sandia.gov) Received: from tarsier.ca.sandia.gov (localhost [127.0.0.1]) by tarsier.ca.sandia.gov (8.8.8/8.8.8) with ESMTP id NAA07249; Mon, 29 Jun 1998 13:28:16 -0700 (PDT) (envelope-from cc@tarsier.ca.sandia.gov) Message-Id: <199806292028.NAA07249@tarsier.ca.sandia.gov> X-Mailer: exmh version 2.0.2 2/24/98 To: zhihuizhang cc: hackers Subject: Re: Interrupt Handling and inline assembly In-reply-to: Your message of "Mon, 29 Jun 1998 14:42:25 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 13:28:16 -0700 From: "Chris Csanady" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I got two questions: > >(1) I read in the MailingList Archive that the interrupt blocking in >FreeBSD is software-based, we do not communicate with 8259 (which I think >is slower) What is the advantage of doing this besides being faster? If >we mask interrupts off (by cli or setting the IMR register in 8259), will >interrupts be simply discarded (the device has to request interrupt >again) or postponed by 8259? > >(2) I am reading the source code in cpufunc.h: > > static __inline void > setbits(volatile unsigned * addr, u_int bits) > { > __asm __volatile("orl %1, %0" : "=m" (*addr): "ir"(bits)); > } > >I have read a text on inline assembly at: > > http://www.rt66.com/~brennan/djgpp/djgpp_asm.html > >But I still do not understand the meaining of "m" and "ir". Take a look at at the gcc info files. These are register constraints, and are described in detail in gcc / C Extensions / Extended Asm. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 13:57:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07959 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 13:57:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@[208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07931 for ; Mon, 29 Jun 1998 13:57:31 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-152.camalott.com [208.229.74.152]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id PAA04096; Mon, 29 Jun 1998 15:57:10 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id PAA28923; Mon, 29 Jun 1998 15:57:02 -0500 (CDT) (envelope-from joelh) Date: Mon, 29 Jun 1998 15:57:02 -0500 (CDT) Message-Id: <199806292057.PAA28923@detlev.UUCP> To: smoergrd@oslo.geco-prakla.slb.com CC: belkovic@albert.osu.cz, smoergrd@oslo.geco-prakla.slb.com, freebsd-hackers@FreeBSD.ORG In-reply-to: (smoergrd@oslo.geco-prakla.slb.com) Subject: Re: BROKEN_KEYBOARD_RESET From: Joel Ray Holveck Reply-to: joelh@gnu.org References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I wrote mail, because i don't know FreeBSD-asembler syntax > It's not 'FreeBSD-assembler syntax", but AT&T assembler syntax, upon > which gas (the GNU assembler), which FreeBSD uses, is based. So, here's a real quick bit on the differences between what you know and what you need to. Most of it was taken from the 'as' info pages (which you should read). I am giving you information here which mostly pertains to a.out without debugging information. I'll probably be putting this online soon, so anybody's suggestions are welcome. * Name your source file with a .S if it needs to be preprocessed with cpp, or .s if it doesn't. Invoke gcc to assemble, as if it were a C file. * Registers are prefixed by '%'. Immediate operands (including labels) are prefixed by '$'. Absolute jump/call operands are prefixed by '*'. (Relative jump/call operands have no prefix.) EXAMPLE: INTEL / MASM AT&T / GAS push 4 pushl $4 push eax pushl %eax jmp A200 jmp *A200 * Intel and MASM use 'opcode dest, source' (eg 'add eax, 4'). AT&T Unix uses 'opcode source, dest'. (eg 'addl $4, %eax'). * Opcodes need to have their operand sizes specified with suffixes of 'b', 'w', and 'l' for 8, 16, and 32 bits. This replaces Intel/MASM's 'byte ptr', 'word ptr', and 'dword ptr', respectively. For example, 'mov eax, dword ptr IDENT' becomes 'movl IDENT, %eax'. (Note that some other Unix assemblers assume an 'l' suffix.) * The sign extend and zero extend opcodes (which are changed from 'movsx' and 'movzx' to 'movs' and 'movz') take two operand size suffixes, first from source, second for destination. (eg: 'movsbl %al, %edx') * Some sign-extend mnemonics have aliases. (The Intel forms are also accepted, but the AT&T forms are preferred.) INTEL / MASM AT&T / GAS cbw cbtw cwde cwtl cwd cwtd cdq cltd * Long jumps and calls are 'ljmp $SEGMENT,$OFFSET' instead of 'jmp far SEGMENT:OFFSET'. Also, far return is 'lret' instead of 'ret far'. * The segment prefixes 'cs:', 'ds:' still work fine (don't forget the %). If they are given on the line before the instruction (like debug's `u' command shows, as opposed to as part of the memory operand, as is traditionally written), the colon is omitted. If a segment prefix specifies the default segment, then it is omitted from the emitted code. * Indirection is written differently. Intel writes [BASE + INDEX*SCALE + DISP] (where BASE and INDEX are the base and index registers, DISP is the optional diplacement, and SCALE is a data width for INDEX). AT&T writes DISP(BASE, INDEX, SCALE) instead. * I don't believe that the 'repz' aliases for the 'repe' opcodes are supported. * Packed BCD is not supported. (If you're doing kernel work, then floating-point operations are a no-no anyway, IIRC.) * The 16-, 32-, and 64-bit expanding multiplies can be output only in the one operand form. Thus, `imul %ebx, %eax' does *not* select the expanding multiply; the expanding multiply would clobber the `%edx' register, and this would confuse `gcc' output. Use `imul %ebx' to get the 64-bit product in `%edx:%eax'. A two operand form of `imul' has been added, where the first operand is an immediate mode expression and the second operand is a register. This is just a shorthand, so that, multiplying `%eax' by 69, for example, can be done with `imul $69, %eax' rather than `imul $69, %eax, %eax'. * The following section pseudo-ops are used. They affect the code up to the next section pseudo-op. .data For read-write memory (global variables, etc) .text For program code or other read-only memory * Symbols are created in the following ways: SYMBOL: What you're used to. SYM = EXPR Used as SYMBOL EQU nn. (May be used as .set SYM, EXPR or .equ SYM, EXPR) . Refers to the current address, as with MASM. .comm SYM, LEN Declares an exported zero-initialized symbol LEN bytes long that is allocated at load-time. This may be in several source files and will result in only one symbol. (These are placed in the 'bss' section.) .lcomm SYM, LEN Same as .comm, but is not exported. * The following pseudo-ops insert literals. Except fill and space, each can have several listed. .ascii, .asciz (adds a \0), .byte (8-bit), .hword (16-bit), .int (32-bit) (aliases: .int, .short, .long), .octa (16-byte bignums), .quad (8-byte bignums), .single (alias: .float), .double, .fill (see below), .space (see see below) * The following various pseudo-ops are availible: .abort Stops assembly. .if / .else / .endif Figure it out. .ifdef SYM / .ifndef SYM Assembles if SYM is defined. .include "FILE" Figure it out. .global SYM Exports a symbol. (Alias: .globl) .extern Clue to a human that a symbol is external. (This is assumed if a symbol is not found in the source.) .lsym SYM, EXP Creates a local symbol that cannot be referenced by the assembler. .align EXP, PAD Pads with PAD (default 0) to a location divisable by 2^EXP. .fill CNT,LEN,VAL Inserts a repeated expression LEN bytes long. .space CNT,VAL Same as .fill CNT,1,VAL .org LC, FILL Fills with FILL until the location LC. * The following pseudo-ops control assembly listings: .list Turn on listings. .nolist Turn off listings. .eject Emit a page break. .psize LINES, COLS Declare a page size. .title "TEXT" Declare a title. .sbttl "TEXT" Declare a subtitle. * When calling C functions, push the first arguments last, the last arguments first. Don't forget the leading _. Return values are in %eax. If your function takes arguments, remember that the return address is 4 bytes at %esp when you start. This means that your int arguments start at 8(%esp) then 12(%esp) then 16(%esp) and so on. (Normally, you will be using %ebp instead, of course.) When you return, have the stack pointer where you found it when you started. * You can see how gcc will generate the assembly code for your C sources by running gcc -S, eg 'gcc -S hello.c' will create hello.s as an assembly code file. Recommended reading includes: "Using as: The GNU Assembler" (the as texinfo page), ld(1), a.out(5), Intel Architecture Software Developer's Manual, Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 14:40:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15214 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 14:40:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TELOS.ODYSSEY.CS.CMU.EDU (TELOS.ODYSSEY.CS.CMU.EDU [128.2.185.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15163 for ; Mon, 29 Jun 1998 14:40:09 -0700 (PDT) (envelope-from jaharkes@TELOS.ODYSSEY.CS.CMU.EDU) Received: from TELOS.ODYSSEY.CS.CMU.EDU (localhost [127.0.0.1]) by TELOS.ODYSSEY.CS.CMU.EDU (8.8.7/8.8.7) with ESMTP id RAA01627; Mon, 29 Jun 1998 17:39:43 -0400 Message-Id: <199806292139.RAA01627@TELOS.ODYSSEY.CS.CMU.EDU> X-Mailer: exmh version 2.0zeta 7/24/97 To: coda-announce@TELEMANN.coda.cs.cmu.edu, linux-coda@TELEMANN.coda.cs.cmu.edu, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers, freebsd-hackers@FreeBSD.ORG, freebsd-afs@freebds.org Subject: Coda version 4.6.0 available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 17:39:41 -0300 From: jaharkes@cs.cmu.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Coda distributed file system version 4.6.0 now available http://www.coda.cs.cmu.edu Coda is an advanced experimental distributed file system with features such as server replication and disconnected operation for laptops (see the WWW site). Release 4.6.0 is mainly a bug fix release with changes since 4.4.4 detailed in the ChangeLog file available on the WWW site and in the root of the sources. The major improvements in this release are: - no more server hangs on first time startup of a server - RPC2 packet buffers are now checked for sanity and should not cause segfaults when bad - many thread stack overflows fixed - linux 2.1 kernel code is now MUCH more stable (many changes) - a coda-linux kernel package for easy module building - Linux Debian compilation fixed - major improvements in debugging features - preliminary support for NT & 95 Coda servers - very preliminary support for Win 95 clients (see below) - initial support for NetBSD packages Stability: we believe this release is a major improvement over the previous one. Coda 4.6.0 on Linux, FreeBSD and NetBSD is very usable as an experimental file system. The development of Coda is largely done within /coda and many of us keep email and other vital files in /coda. We have confusing situations, but have not lost any files. Platforms: Linux (i86 and sparc): Kernel 2.0 -- kernel code included in coda-linux package; this code is not much changed from 4.4.4: it is stable in the sense of not crashing your system, but is known to have odd bugs due to an incomplete implementation of the Coda semantics Kernel 2.1 -- kernel code is included in the Linux kernel, HOWEVER, that code lags our current version, so you should use the kernel code provided in the 4.6.0 coda-kernel package instead (we are holding off submitting patches to avoid overloading Linus). This code closely follows the Coda semantics and is in constant use by most of us, but is less extensively exercised than the 2.0 code and may still, rarely, crash systems. User-level issues: we no longer support libc5; it may still work just fine. The Coda tarball compiles under Debian and there will be a Debian maintainer for Coda at some point (details to be announced). Packages for Red Hat 5.0 are available and appear to work fine on Red Hat 5.1. NetBSD 1.3: NetBSD benefits from the general bugfixes and is working very well both as a server and as a client. NetBSD 1.3 packages are available. FreeBSD: FreeBSD mostly works very well; however, there is a bug which occasionally crashes the client cache manager. Tarballs for 2.2.5 are available and packages will be available. We apologize that for project reasons we will not be able to adequately test 2.2.6 versions until August although 4.4.4 was known to work just as well on 2.2.5 and 2.2.6. Win32: Preliminary support for running Coda servers on Windows NT and Windows 95. In this release, the Win32 port is only suitable for developers to experiment with. No kernel-mode code is needed for the Coda server. All building is done with cross-compilation using Cygwin32 from Red Hat Linux (cross-build RPMs are available); see README.nt in the root of the source tree for details. Windows 95: Very preliminary support for a client on Windows 95 is included in 4.6.0. To use this, you need to have the entire Microsoft toolchain necessary to build VxDs for the kernel-level components of Coda. In addition, you need a special cross-compilation environment for the user-level components which is available for Red Hat Linux from our website. Note on Windows ports: we hope that by making this code available we will encourage developers to explore it and perhaps join in development. It is not usable as a filesystem yet. We thank many net contributors for patches, but above all Michael Callahan for developing and contributing the Windows 95 port as well as continuing to be an invaluable resource for our group. Please join our bazaar! Signed: The CMU Coda team Peter J. Braam development leader Shafeeq Sinnamohideen extensive networking code improvements Jan Harkes improvements to the client and RVM Bob Baron BSD support Henry Pierce release engineering Satya head of the group vital for past, present and future To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 15:13:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19964 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 15:13:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19744; Mon, 29 Jun 1998 15:12:13 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id GAA03588; Tue, 30 Jun 1998 06:11:29 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806292211.GAA03588@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Paul T. Root" cc: rminnich@Sarnoff.COM (Ron G. Minnich), hackers@FreeBSD.ORG, questions@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: looking for ram file system (NOT MFS) In-reply-to: Your message of "Mon, 29 Jun 1998 11:28:11 EST." <199806291628.LAA10456@horton.iaces.com> Date: Tue, 30 Jun 1998 06:11:28 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Paul T. Root" wrote: > In a previous message, Ron G. Minnich said: > > I'm looking for something like a ram file system for some work i'm doing. > > It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be > > BSD or GPL copyright, and run under current. Any pointers appreciated. > > mfs Recheck the subject line: "looking for ram file system (NOT MFS)" ^^^^^^^^^ I believe Poul-Henning Kamp was working on a mallocfs at some point.. MFS is bad in that it doesn't allocate and release swap. It'd be seriously great to have something that could allocate and free pageable memory as files were written and deleted. MFS never releases swap space once the mount_mfs process faults in an anon page. Doing it seperately from UFS would be a good start since it wouldn't be wasting time emulating a disk structure. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 15:35:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24392 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 15:35:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24328 for ; Mon, 29 Jun 1998 15:34:46 -0700 (PDT) (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.8/8.8.8) with ESMTP id PAA04936; Mon, 29 Jun 1998 15:33:15 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Ron G. Minnich" cc: hackers@FreeBSD.ORG Subject: Re: I2O In-reply-to: Your message of "Mon, 29 Jun 1998 09:32:46 EDT." Date: Mon, 29 Jun 1998 15:33:15 -0700 Message-ID: <4931.899159595@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I2O will be a footnote in a year or so. After that, it will be forgotten That about sums up my view of it as well. Thanks for the reality-check here, Ron. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 16:31:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03299 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 16:31:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03279 for ; Mon, 29 Jun 1998 16:30:53 -0700 (PDT) (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.8/8.8.8) with ESMTP id QAA05259; Mon, 29 Jun 1998 16:29:31 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Andrew Reilly cc: Terry Lambert , Mike Smith , njs3@doc.ic.ac.uk, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Mon, 29 Jun 1998 16:24:34 +1000." <19980629162434.A20703@reilly.home> Date: Mon, 29 Jun 1998 16:29:31 -0700 Message-ID: <5256.899162971@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sorry for leaping into this late, (and consequently getting the > wrong people on the To: line), but what's the "90's" way of handling > the genuinely script-like things in /etc? I can see how a unified > parameter/value store would be a great advance for most things, > but how do you do: > > /etc/ppp/ppp.linkup.foo, the script that is executed by the !bg > line at the bottom of your ppp.linkup file. > > /etc/{daily,weekly,monthly} In some cases, you probably do nothing more than treat ancillary scripts as one big property, e.g. bring up a text edit box and just let the user edit the script. That should be workable within the proposed framework since nothing "higher up" needs to know or care that /etc/ppp/ppp.linkup.foo is an indivisable property all on its own and you'd just export it as ``net.ppp.foo.linkup_script'' or some such. In others, especially things like /etc/daily or even the /etc/rc.conf and /etc/rc.network pair (where one file sets hints on behalf of another file, which then does various hidden and arcane actions based on their values), it all comes down to how much you want to advance the state of the art in exchange for leaving the previous paradigm (and all those who were used to it), behind. To clarify what I mean, let's take the following real-life example from rc.conf: linux_enable="YES" # Linux emulation loaded at startup (or NO). which also has the corresponding code in rc.i386: # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi It doesn't take you long to realize "hey, waitaminute, this is pretty crude - if I want to add another variable to this scheme, I've got to go to rc.conf and add it there, then add it to the man page for rc.conf, then go figure out which of the rc.foo scripts has the code which is associated with that action and add another clause to it." Contrast this with a slightly different model, where you have one variable called "linux" in your ``registery'' with the following properties: linux(enabled) = YES linux(doc) = { This variable controls whether linux emulation support will be automatically loaded at startup. You can also do it manually with the /usr/bin/linux command. } linux(exec-command) = "linux > /dev/null 2>&1" This is far more concise and is missing only the information which tells us when we want to execute the relevant system command (it could, after all, have ordering prerequisites like so many of the network startup foo), and for that one could simply add another properties like "exec-order" and "exec-group" which would enable the system to group actions together and set their overall execution order within that group. Anyway, assuming that you could ever get the /etc/rc* proponents to stop screaming about such a gross violation of POLA in FreeBSD's startup code, and you were willing to suffer through all the emotional war stories about how *%$#$@! difficult it is to find and debug abberant startup behavior on SVR4 boxes and this was just a step in that direction, people would probably ultimately praise such a scheme as being far more concise, easy to extend and better documented (assuming that you adhered to some decent conventions on doc properties). But you're also not going to catch ME trying to hold up that particular lightning rod. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 16:35:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03924 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 16:35:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from midget.dons.net.au (root@daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03777 for ; Mon, 29 Jun 1998 16:34:19 -0700 (PDT) (envelope-from darius@midget.dons.net.au) Received: from midget.dons.net.au (darius@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.8.8/8.8.5) with ESMTP id JAA02683 for ; Tue, 30 Jun 1998 09:04:58 +0930 (CST) Message-Id: <199806292334.JAA02683@midget.dons.net.au> To: hackers@FreeBSD.ORG Subject: Another M/B with serial port problems Date: Tue, 30 Jun 1998 09:04:56 +0930 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I just recently bought a Jet 5TXC motherboard, and I had to apply the serial port patch to get the sio driver to detect my serial ports OK. They work fine now (I had a mouse and modem connected witn no problems) Any chance of the patch being applied as an option to -current? :) --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 17:16:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10990 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 17:16:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10873 for ; Mon, 29 Jun 1998 17:15:22 -0700 (PDT) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id RAA12124 for ; Mon, 29 Jun 1998 17:14:58 -0700 (PDT) Date: Mon, 29 Jun 1998 17:14:57 -0700 (PDT) From: Ian Kallen To: freebsd-hackers@FreeBSD.ORG Subject: ccd configuration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So I've got these two identical SCSI disks, I newfs'd them and, with the requisite driver in the kernel, then put them together by saying cd /dev ; sh MAKEDEV ccd0 ccdconfig ccd0 32 0 /dev/sd1s1e /dev/sd2s1e newfs -b 8192 -f 1024 /dev/ccd0c mount /dev/ccd0c /mnt Great. That works. I'm just curious why I needed to newfs the disks individually prior to ccd'ing them? Or did I? Is there any documentation beyond the man pages on the ins & outs of ccd? I guess I'm not clear on the boot time mounting... what do I put in my fstab? /dev/ccd0c /mnt ufs rw 2 2 and then at mount time, /etc/ccd.conf will be referred to to figure out wtf ccd0c is? Thanks, -Ian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 17:26:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12694 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 17:26:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from unix.tfs.net (as1-p62.tfs.net [139.146.210.62]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12636 for ; Mon, 29 Jun 1998 17:26:26 -0700 (PDT) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id TAA01679; Mon, 29 Jun 1998 19:24:30 -0500 (CDT) From: Jim Bryant Message-Id: <199806300024.TAA01679@unix.tfs.net> Subject: Re: I2O In-Reply-To: from Jamie Bowden at "Jun 29, 98 03:18:17 pm" To: jamie@itribe.net (Jamie Bowden) Date: Mon, 29 Jun 1998 19:24:28 -0500 (CDT) Cc: freebsd-hackers@FreeBSD.ORG Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 3.0-CURRENT #0: Sat Jun 20 11:57:05 CDT 1998 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 Precedence: bulk X-Loop: FreeBSD.ORG In reply: > On Mon, 29 Jun 1998, Ron G. Minnich wrote: > > > at usenix last week the question of I2O came up. > > > > Don't worry about I2O. Look around: how many I2O motherboards do you see, > > as compared to non-I2O motherboards? > > > > Look at it this way: you think microsoft is that interested in requiring > > a second operating system (vxworks) to make NT go? > > > > I2O will be a footnote in a year or so. After that, it will be forgotten > > and in 10 years someone else will reinvent the idea and learn the hard > > way why it is a bad one (as I2O is itself a reinvention of old, bad ideas). > > Why is offloading IO a bad idea? Offloading video and 3D rendering work > well, it's what drives 3dfx and it's competitors. Or am I missing > something? My basic understanding of I2O is using a subprocessor to > handle all IO, thus freeing up the main processor from doing things like > waiting on interrupts and the like. ever hear of scsi? how about bus-mastering? 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+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 17:47:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16032 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 17:47:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15873 for ; Mon, 29 Jun 1998 17:46:55 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id KAA04284; Tue, 30 Jun 1998 10:16:25 +0930 (CST) Message-ID: <19980630101625.Y1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 10:16:25 +0930 From: Greg Lehey To: Ian Kallen , freebsd-hackers@FreeBSD.ORG Subject: Re: ccd configuration References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Ian Kallen on Mon, Jun 29, 1998 at 05:14:57PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 29 June 1998 at 17:14:57 -0700, Ian Kallen wrote: > > So I've got these two identical SCSI disks, I newfs'd them and, with the > requisite driver in the kernel, then put them together by saying > cd /dev ; sh MAKEDEV ccd0 > ccdconfig ccd0 32 0 /dev/sd1s1e /dev/sd2s1e > newfs -b 8192 -f 1024 /dev/ccd0c > mount /dev/ccd0c /mnt > > Great. That works. I'm just curious why I needed to newfs the disks > individually prior to ccd'ing them? Or did I? No. > Is there any documentation beyond the man pages on the ins & outs of > ccd? Not that I know of. It's pretty bare-bones. > I guess I'm not clear on the boot time mounting... what do I put in > my fstab? > > /dev/ccd0c /mnt ufs rw 2 2 I'd choose a better mount point if I were you. /mnt is really intended for temporary mounts. > and then at mount time, /etc/ccd.conf will be referred to to figure out > wtf ccd0c is? Right. If you look at /etc/rc, you'll see that just about the first thing that the system does is to start ccd, even before mounting. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 18:02:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19191 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 18:02:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19029 for ; Mon, 29 Jun 1998 18:01:50 -0700 (PDT) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id SAA13675 for ; Mon, 29 Jun 1998 18:01:28 -0700 (PDT) Date: Mon, 29 Jun 1998 18:01:28 -0700 (PDT) From: Ian Kallen Reply-To: Ian Kallen To: freebsd-hackers@FreeBSD.ORG Subject: Re: ccd configuration In-Reply-To: <19980630101625.Y1880@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Greg Lehey wrote: :> Great. That works. I'm just curious why I needed to newfs the disks :> individually prior to ccd'ing them? Or did I? :No. Hmm I did because the example in the ccdconfig man page was not using the raw devices, when I try running it on a raw device ccdconfig complains that it wants a blockdevice and if it's not newfs'd, it complains like ccdconfig: ioctl (CCDIOCSET): /dev/ccd1c: Invalid argument :> /dev/ccd0c /mnt ufs rw 2 2 : :I'd choose a better mount point if I were you. /mnt is really :intended for temporary mounts. Just for illustrative purposes :) :Right. If you look at /etc/rc, you'll see that just about the first :thing that the system does is to start ccd, even before mounting. Great, thanks! -Ian -- I play the harmonica. the only way I can play is if I get my car going really fast, and stick it out the window. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 18:03:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19340 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 18:03:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from duey.hs.wolves.k12.mo.us (root@duey.hs.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19207 for ; Mon, 29 Jun 1998 18:02:39 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.hs.wolves.k12.mo.us (cdillon@duey.hs.wolves.k12.mo.us [207.160.214.9]) by duey.hs.wolves.k12.mo.us (8.8.7/8.8.7) with SMTP id UAA01615; Mon, 29 Jun 1998 20:02:21 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 29 Jun 1998 20:02:20 -0500 (CDT) From: Chris Dillon X-Sender: cdillon@duey.hs.wolves.k12.mo.us To: Don Lewis cc: Ulf Zimmermann , Atipa , hackers@FreeBSD.ORG Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? In-Reply-To: <199806291935.MAA26508@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Don Lewis wrote: > On Jun 26, 5:47pm, Chris Dillon wrote: > } Subject: Re: Will 8 Intel EtherExpress PRO 10/100's be a problem? > } On Fri, 26 Jun 1998, Ulf Zimmermann wrote: > } > } > On Fri, Jun 26, 1998 at 11:03:01AM -0500, Chris Dillon wrote: > } > > On Thu, 25 Jun 1998, Atipa wrote: > > } > > I'm rather hoping that three 133MB/sec PCI busses won't have any trouble > } > > passing at max about 30MB/sec worth of data (10MB/sec per card, three > } > > cards per bus). Theoretically even one PCI bus could handle all 8 of > } > > those cards.. _theoretically_... :-) > } > > } > Double that number, Full Duplex is what you usual now use in routers. > } > I also wouldn't say the single bus is the problem, but the main PCI bus and > } > the CPU will be a bottleneck. You will definatly not be able to run 8 > } > cards at full speed (8 x 10Mbyte/sec x 2 (FullDuplex) = 160 MByte/sec) > > You can only use Full Duplex if the port is connected directly to another > host or to a switch. From the initial description it sounded like each > port would be connected to a number of other hosts through a hub, which > would require Half Duplex to be used. Actually, I AM connecting these to a switch. After travelling through several kilometers of fiber in a couple of instances. :-) Fact is, good 100Mbit cards are cheaper than most good 10Mbit cards I have seen, and our switches all have at least one 100Mbit port on them. I'd be happy with 10Mbit, but 100Mbit is costing me so little more for at least double the bandwidth, up to a theoretical 10x the bandwidth. The only extra expense will be the Fast Ethernet media converters for the fiber runs, since they are definately more expensive than 10Mbit versions. We are having a guy get us some prices on some converters that will let us do two 100Mbit Ethernet channels and four(?) T1's across one pair of fiber. Considering our fiber has been donated and we have a rather limited number of pairs to work with between some of our buildings (and more than we'll ever need between others), I like this idea. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) (http://www.freebsd.org) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 18:12:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA21419 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 18:12:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA21368; Mon, 29 Jun 1998 18:12:16 -0700 (PDT) (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.8/8.8.8) with ESMTP id SAA05780; Mon, 29 Jun 1998 18:11:26 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Louis A. Mamakos" cc: "Jonathan M. Bresler" , grog@lemis.com (Greg Lehey), hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net In-reply-to: Your message of "Mon, 29 Jun 1998 20:45:08 EDT." <199806300045.UAA04359@whizzo.transsys.com> Date: Mon, 29 Jun 1998 18:11:25 -0700 Message-ID: <5776.899169085@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's very unlikely that the spam originates from anyone with a mailbox on > a UU.NET system. You're probably seeing it from addresses which are in the > foo.DA.UU.NET or bar.MS.UU.NET which are PPP pool addresses used by resellers > of the dial network infrastructure. These would include MSN, AOL, Earthlink, > the Well, WebTV and many others. Right, and I think I made this point in my original email. Since they're clearly reselling to a lot of folks with no scruples WRT UCE at all, the easiest thing to do is simply block *.uu.net since I certainly don't want the job of having to track down every foo.uu.net subdomain resold to a spammer-friendly ISP. As Jon has also already noted, the folks directly affected by this seem quite small and I've gotten *far* less spam in my mailbox today as a result, so as far as I'm concerned the exercise is an unqualified success. > If you tried to report this to abuse@uu.net and that didn't yield > satisfactory results, please let me know. While "god ... knows > which .. is repsonsible Heh. I reported it so many times and so frequently that Paul Vixie finally asked me to cc him on all the reports, someting which I did for a couple of months until we both got tired of the exercise. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 18:17:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22258 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 18:17:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22201 for ; Mon, 29 Jun 1998 18:17:06 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.8/8.8.7) id PAA01467; Mon, 29 Jun 1998 15:30:35 -0700 (PDT) Message-ID: <19980629153033.08439@hydrogen.nike.efn.org> Date: Mon, 29 Jun 1998 15:30:33 -0700 From: John-Mark Gurney To: Greg Moncreaff Cc: FreeBSD Hackers Subject: Re: no driver assigned References: <358AB49D.1DDCAF5A@ma.ultranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <358AB49D.1DDCAF5A@ma.ultranet.com>; from Greg Moncreaff on Fri, Jun 19, 1998 at 01:57:33PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.6-STABLE 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 Precedence: bulk X-Loop: FreeBSD.ORG Greg Moncreaff scribbled this message on Jun 19: > Is there someone working on a driver for this? > > pci0:16: vendor=0x10cd, device=0x1300, class=storage (scsi) int a irq > 11 [no driver assigned] yep, there is a driver for it... you just have to use CAM to use it... I'm using one right now... it hosts a tape drive, three scsi1 hard disks, and two cdroms... adv0 rev 2 int a irq 10 on pci0:11:0 #define PCI_DEVICE_ID_ADVANSYS_ULTRA 0x130010CD the CAM now supports both -stable, and -current... check out ftp://ftp.cdrom.com/pub/FreeBSD/cam for more info... -- John-Mark Gurney Voice: +1 541 683 7109 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 18:33:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24714 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 18:33:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24684 for ; Mon, 29 Jun 1998 18:33:07 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id LAA04394; Tue, 30 Jun 1998 11:03:04 +0930 (CST) Message-ID: <19980630110259.A1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 11:02:59 +0930 From: Greg Lehey To: Ian Kallen , freebsd-hackers@FreeBSD.ORG Subject: Re: ccd configuration References: <19980630101625.Y1880@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Ian Kallen on Mon, Jun 29, 1998 at 06:01:28PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 29 June 1998 at 18:01:28 -0700, Ian Kallen wrote: > On Tue, 30 Jun 1998, Greg Lehey wrote: > :> Great. That works. I'm just curious why I needed to newfs the disks > :> individually prior to ccd'ing them? Or did I? > :No. > > Hmm I did because the example in the ccdconfig man page was not using > the raw devices, when I try running it on a raw device ccdconfig complains > that it wants a blockdevice and if it's not newfs'd, it complains like > ccdconfig: ioctl (CCDIOCSET): /dev/ccd1c: Invalid argument Hmm. Interesting. This shouldn't be necessary, and I can't remember having done this when I tried it, but I don't have time to try it out again. Have you looked at vinum? http://www.lemis.com/vinum.html Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 19:03:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15850 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 17:46:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15668; Mon, 29 Jun 1998 17:45:40 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.8/8.7.3) with ESMTP id UAA04359; Mon, 29 Jun 1998 20:45:09 -0400 (EDT) Message-Id: <199806300045.UAA04359@whizzo.transsys.com> X-Mailer: exmh version 2.0.1 12/23/97 To: "Jonathan M. Bresler" cc: grog@lemis.com (Greg Lehey), jkh@time.cdrom.com, hackers@freebsd.org From: "Louis A. Mamakos" Subject: Re: Too much spam from uu.net References: <199806291708.KAA21720@hub.freebsd.org> In-reply-to: Your message of "Mon, 29 Jun 1998 10:08:21 PDT." <199806291708.KAA21720@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jun 1998 20:45:08 -0400 Sender: owner-freebsd-hackers@freebsd.org Precedence: bulk X-Loop: FreeBSD.ORG > Greg Lehey wrote: > > On Sunday, 28 June 1998 at 20:21:40 -0700, Jordan K. Hubbard wrote: > > > Sorry for the -hackers posting here, but this will reach the people > > > most likely to be affected. > > > > > > Despite their frequent protests to the contrary, uu.net remains the > > > single largest origin of spam abuse for our mailing lists and their > > > policy of apparently re-selling dialup access to secondary ISPs who do > > > *not* necessarily have to have stringent anti-spam policies of their > > > own only makes this even worse. After the most recent spamming from > > > one of "uu.net's" dialups (and god only knows which affiliate is > > > actually responsible for it), I've taken it upon myself to add them to > > > freebsd.org's spammer list. This is a purely provisional move until > > > we figure out how extensive the side-effects of this will be, it > > > perhaps becoming a permanant block if the problem does not abate and > > > not too terribly many folks are inconvenienced by it. From those who > > > will get much less spam as a result of this move, I also doubt that > > > too many tears will be shed for uu.net. > > > > How many mailing list users will this affect? > > there are only three mailing lists subscribers from uu.net. > surprising but true. > > so far no one has sent mail to the lists from uu.net in today's > /var/log/maillog. > > hmm.... It's very unlikely that the spam originates from anyone with a mailbox on a UU.NET system. You're probably seeing it from addresses which are in the foo.DA.UU.NET or bar.MS.UU.NET which are PPP pool addresses used by resellers of the dial network infrastructure. These would include MSN, AOL, Earthlink, the Well, WebTV and many others. If you tried to report this to abuse@uu.net and that didn't yield satisfactory results, please let me know. While "god ... knows which .. is repsonsible for it", there also a database and associated tools which can cough up the answer in short order and result in the requisite transitive pain/suffering. louie (also louie@UU.NET) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 19:07:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA01166 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 19:07:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA01161 for ; Mon, 29 Jun 1998 19:07:47 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id LAA22625 for ; Tue, 30 Jun 1998 11:37:28 +0930 (CST) Message-Id: <199806300207.LAA22625@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@FreeBSD.ORG Subject: Serial port problems fixed with patch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 11:37:28 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I just recently got a new Jet-TX motherboard, and lo and behold the serial ports would not detect, so I tried out the patch for IWill M/B's that was floating around, and it fixed it! :) I can give more info on the board if needed (ie what chips are on it for) --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 19:40:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA08188 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 19:40:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shivam.eecs.umich.edu (shivam.eecs.umich.edu [141.213.10.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA08173 for ; Mon, 29 Jun 1998 19:40:36 -0700 (PDT) (envelope-from ymc@eecs.umich.edu) Received: from localhost by shivam.eecs.umich.edu (8.9.0/8.9.0) with SMTP id WAA01467 for ; Mon, 29 Jun 1998 22:40:20 -0400 (EDT) Date: Mon, 29 Jun 1998 22:40:20 -0400 (EDT) From: Yee Man Chan Reply-To: Yee Man Chan To: freebsd-hackers@FreeBSD.ORG Subject: client-server problem Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-899173587=:1437" Content-ID: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-899173587=:1437 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, I wrote a simple client-server program (attached). What it does is: 1. Client sends a string of n (n is a parameter) bytes 2. Server receives the string and sends the bytes it received back to the client. Usage: Run server -n 100 in one shell and client -n 100 in the other shell. Then the n mentioned above will be set to 100. The program assumes both client and server are on the same machine, so nothing should go to the network. Here is how the program performs under FreeBSD 3.0-CURRENT with different n: 1-100 Very fast 101-207 Very Slow (This range is the strangest I've ever seen) 208-1024 Very fast (just like 1-100) >1024 strange errors like unknown host or connection timedout Any clue? Yee Man ---559023410-851401618-899173587=:1437 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="client.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5j bHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8bmV0ZGIuaD4NCiNpbmNsdWRl IDxlcnJuby5oPg0KI2luY2x1ZGUgPHN5cy90aW1lLmg+DQojaW5jbHVkZSA8 c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2luY2x1 ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPg0K DQoNCiNpZm5kZWYgQlVGU0laDQojZGVmaW5lIEJVRlNJWiA0MDk2DQojZW5k aWYNCg0KI2lmbmRlZiBUUlVFIA0KI2RlZmluZSBUUlVFIDENCiNlbmRpZg0K DQojaWZuZGVmIEZBTFNFDQojZGVmaW5lIEZBTFNFIDANCiNlbmRpZg0KDQoj ZGVmaW5lIFNNQUxMQlVGIDgwDQoNCiNkZWZpbmUgREVGQVVMVF9QT1JUIDQ4 OTgNCiNkZWZpbmUgTkFTQV9GT1JNQVQgIiVbXiBdIC0gLSBcWyVbXl1dXSBc IiVzICVzICVbXlwiXVwiICVkICVkIiANCiNkZWZpbmUgTkFTQV9USU1FX0ZP Uk1BVCAiJVteL10vJVteL10vJVteOl06JVteOl06JVteOl06JVteIF0gJXMi IA0KY29uc3QgY2hhciAqIFR3ZWx2ZU1vbnRoW10gPSANCnsNCiAgIkphbiIs DQogICJGZWIiLA0KICAiTWFyIiwNCiAgIkFwciIsDQogICJNYXkiLA0KICAi SnVuIiwNCiAgIkp1bCIsDQogICJBdWciLA0KICAiU2VwIiwNCiAgIk9jdCIs DQogICJOb3YiLA0KICAiRGVjIg0KfTsNCg0KaW50IGVycm5vOw0KDQovKiBM b2NhbCBmdW5jdGlvbnMgKi8NCnN0YXRpYyBpbnQgY2xpZW50X2NvbW1fY29u bmVjdChpbnQgc29jaywgY2hhciAqZGVzdF9ob3N0LCB1X3Nob3J0IGRlc3Rf cG9ydCk7DQpzdGF0aWMgaW50IHR2U3ViVXNlYyhzdHJ1Y3QgdGltZXZhbCB0 MSwgc3RydWN0IHRpbWV2YWwgdDIpOw0Kc3RhdGljIHZvaWQgdXNhZ2UoY29u c3QgY2hhciAqcHJvZ25hbWUpOw0KDQpzdGF0aWMgdm9pZA0KdXNhZ2UoY29u c3QgY2hhciAqcHJvZ25hbWUpDQp7DQogIGZwcmludGYoc3RkZXJyLA0KCSAg IlVzYWdlOiAlcyBbLWVkXSBbLWkgSXRlcl0gWy1oIGhvc3RdIFstcCBwb3J0 XVxuIg0KCSAgIk9wdGlvbnM6XG4iDQoJICAiICAgIC1lICAgICAgICAgcHJp bnQgcmVwbGllcyBmcm9tIHNlcnZlciAoZGVmYXVsdD1vbikuXG4iDQoJICAi ICAgIC1kICAgICAgICAgc2V0c29ja29wdCguLi4sIFRDUF9OT0RFTEFZICwu Li4pLlxuIg0KCSAgIiAgICAtaSBJdGVyICAgICMgb2YgcmVxdWVzdHMgaXNz dWVkIChkZWZhdWx0ID0gMTAwMCkuXG4iDQoJICAiICAgIC1oIGhvc3QgICAg UmV0cmlldmUgVVJMIGZyb20gY2FjaGUgb24gaG9zdG5hbWUuICBEZWZhdWx0 IGlzIGxvY2FsaG9zdC5cbiINCgkgICIgICAgLXAgcG9ydCAgICBQb3J0IG51 bWJlciBvZiBjYWNoZS4gIERlZmF1bHQgaXMgJWQuXG4iLA0KCSAgcHJvZ25h bWUsIERFRkFVTFRfUE9SVCk7DQogIGV4aXQoMSk7DQp9DQoNCmludA0KbWFp bihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0Kew0KICBjaGFyIGhvc3RuYW1l W1NNQUxMQlVGXSA9ICJsb2NhbGhvc3QiOyANCiAgY2hhciBidWZbQlVGU0la XTsNCiAgY2hhciBtc2dbMl09ImEiOyAvKiBtc2dbMF0gPSBjUmVxdWVzdHMg JSAyNTYgaXMgdGhlIGNoYXJhY3RlciB0byBiZSBzZW50ICovDQogIGNoYXIg YzsNCg0KICBpbnQgcG9ydCA9IERFRkFVTFRfUE9SVDsNCiAgaW50IGl0ciA9 IDEwMDA7IC8qICMgb2YgcmVxdWVzdHMgcGVyIHRyaWFsICovDQogIGludCBj b25uOyAvKiBjbGllbnQgc29ja2V0IGlkICovDQogIGludCB0b19zdGRvdXQg PSAxOyAvKiBwcmludCByZXBsaWVzIGZyb20gc2VydmVyICovDQogIGludCBp LGo7DQogIGludCBjUmVxdWVzdHM7DQogIGludCB1c1RvdGFsUmVzcG9uc2VU aW1lOw0KICBzdHJ1Y3QgdGltZXZhbCB0dlJlcXVlc3RUaW1lLCB0dlJlcGx5 VGltZTsNCiAgaW50IGJ5dGVzV3JpdHRlbjsNCiAgaW50IGNjaDsNCiAgaW50 IHRjcF9ub2RlbGF5ID0gMDsgLyogZW5hYmxlIE5hZ2xlJ3MgYWxnb3JpdGht IGJ5IGRlZmF1bHQgKi8NCiAgaW50IGJ5dGVzVG9TZW5kOw0KDQogIC8qIHBh cnNlIGFsbCBvcHRpb25zICovDQogIHdoaWxlICgoYyA9IGdldG9wdChhcmdj LCBhcmd2LCAiZGk6aDpuOnAiKSkgIT0gLTEpDQogICAgc3dpdGNoIChjKSB7 DQogICAgY2FzZSAnaCc6CQkvKiBob3N0OmFyZyAqLw0KICAgICAgaWYgKG9w dGFyZyAhPSBOVUxMKQ0KCXN0cmNweShob3N0bmFtZSwgb3B0YXJnKTsNCiAg ICAgIGJyZWFrOw0KICAgIGNhc2UgJ2QnOiAgICAvKiBkaXNhYmxlIE5hZ2xl J3MgYWxnb3JpdGhtICovDQogICAgICB0Y3Bfbm9kZWxheSA9IDE7DQogICAg ICBicmVhazsNCiAgICBjYXNlICduJzoNCiAgICAgIGJ5dGVzVG9TZW5kID0g YXRvaShvcHRhcmcpOw0KICAgICAgYnJlYWs7DQogICAgY2FzZSAncCc6CQkv KiBjYWNoZSBwb3J0IG51bWJlciAqLw0KICAgICAgc3NjYW5mKG9wdGFyZywg IiVkIiwgJnBvcnQpOw0KICAgICAgaWYgKHBvcnQgPCAxKQ0KCXBvcnQgPSBE RUZBVUxUX1BPUlQ7CS8qIGRlZmF1bHQgKi8NCiAgICAgIGJyZWFrOw0KICAg IGNhc2UgJ2knOgkJLyogIyBvZiByZXF1ZXN0cyB0byBiZSBzZW50ICovDQog ICAgICBpdHIgPSBhdG9pKG9wdGFyZyk7DQogICAgICBicmVhazsNCiAgICBj YXNlICc/JzoJCS8qIHVzYWdlICovDQogICAgZGVmYXVsdDoNCiAgICAgIHVz YWdlKGFyZ3ZbMF0pOw0KICAgICAgYnJlYWs7DQogICAgfQ0KDQogIAljUmVx dWVzdHMgPSAwOw0KDQoNCg0KCXVzVG90YWxSZXNwb25zZVRpbWUgPSAwOw0K CWZvciAoaSA9IDA7IGkgPCBpdHI7IGkrKykgew0KDQoJICAvKiBDb25uZWN0 IHRvIHRoZSBjYWNoZSBzZXJ2ZXIgKi8NCgkgIGlmICgoY29ubiA9IHNvY2tl dChQRl9JTkVULCBTT0NLX1NUUkVBTSwgMCkpIDwgMCkgew0KCSAgICBwZXJy b3IoImNsaWVudDogc29ja2V0Iik7DQoJICAgIGV4aXQoMSk7DQoJICB9DQoN CgkgIGlmICh0Y3Bfbm9kZWxheSkgDQoJICAgIGlmIChzZXRzb2Nrb3B0KGNv bm4sIElQUFJPVE9fVENQLCBUQ1BfTk9ERUxBWSwgKGNoYXIgKikgJnRjcF9u b2RlbGF5LCBzaXplb2YodGNwX25vZGVsYXkpKSA8IDApIHsNCgkgICAgICBw ZXJyb3IobXNnKTsNCgkgICAgICBleGl0KDEpOw0KCSAgICB9DQogIA0KCSAg d2hpbGUgKGNsaWVudF9jb21tX2Nvbm5lY3QoY29ubiwgaG9zdG5hbWUsIHBv cnQpIDwgMCkgew0KCSAgICBwZXJyb3IoImNvbm5lY3QgZXJyb3IiKTsNCgkg ICAgaWYgKGVycm5vID09IDApIHsNCgkgICAgICBmcHJpbnRmKHN0ZGVyciwg ImNsaWVudDogRVJST1I6IENhbm5vdCBjb25uZWN0IHRvICVzOiVkOiBIb3N0 IHVua25vd24uXG4iLCBob3N0bmFtZSwgcG9ydCk7DQoJICAgICAgLyoNCgkg ICAgfSBlbHNlIHsNCgkgICAgICBzcHJpbnRmKG1zZywgImNsaWVudDogRVJS T1I6IENhbm5vdCBjb25uZWN0IHRvICVzOiVkIiwNCgkJICAgICAgaG9zdG5h bWUsIHBvcnQpOw0KCSAgICAgIHBlcnJvcihtc2cpOw0KCSAgICAgICovCSAg ICANCg0KCSAgICBleGl0KDEpOw0KCSAgICB9DQoJICAgIGVsc2UgaWYgKGVy cm5vID09IEVDT05OUkVGVVNFRCkgew0KCSAgICAgIGNsb3NlKGNvbm4pOw0K CSAgICAgIGlmICgoY29ubiA9IHNvY2tldChQRl9JTkVULCBTT0NLX1NUUkVB TSwgMCkpIDwgMCkgew0KCQlwZXJyb3IoImNsaWVudDogc29ja2V0Iik7DQoJ CWV4aXQoMSk7DQoJICAgICAgfQ0KCSAgICB9DQoJICB9DQoJICANCiAgaWYg KGJ5dGVzVG9TZW5kIDw9IDApIHsNCiAgICBwcmludGYoIlBsZWFzZSBzdXBw bHkgdGhlICMgb2YgYnl0ZXMgeW91IGV4cGVjdCB0byBzZW5kIHBlciB0cmlh bC5cbiIpOw0KICAgIGV4aXQoMSk7DQogIH0NCiAgZm9yIChqID0gMDsgaiA8 IGJ5dGVzVG9TZW5kOyArK2opDQogICAgbXNnW2pdID0gJzAnICsgKGogJSAx MCk7DQoNCiAgbXNnW2J5dGVzVG9TZW5kXSA9IE5VTEw7DQoNCgkgIC8qIHNl dCBSZXF1ZXN0VGltZXIpICovDQoJICBnZXR0aW1lb2ZkYXkoJnR2UmVxdWVz dFRpbWUsIE5VTEwpOw0KCSAgDQoJICAvKiBTZW5kIHRoZSBIVFRQIHJlcXVl c3QgdG8gdGhlIGNhY2hlIHNlcnZlciAqLw0KCSAgYnl0ZXNXcml0dGVuID0g d3JpdGUoY29ubiwgbXNnLCBzdHJsZW4obXNnKSk7DQoJICAgIA0KCSAgaWYg KGJ5dGVzV3JpdHRlbiA8IDApIHsNCgkgICAgcGVycm9yKCJjbGllbnQ6IEVS Uk9SOiB3cml0ZSIpOw0KCSAgICBleGl0KDEpOw0KCSAgfSBlbHNlIGlmIChi eXRlc1dyaXR0ZW4gIT0gc3RybGVuKG1zZykpIHsNCgkgICAgZnByaW50Zihz dGRlcnIsICJjbGllbnQ6IEVSUk9SOiBDYW5ub3Qgc2VuZCByZXF1ZXN0Pzog JXNcbiIsIG1zZyk7DQoJICAgIGV4aXQoMSk7DQoJICB9DQoNCgkgIC8qIFJl YWQgdGhlIGRhdGEgKi8NCgkgIHdoaWxlICgoY2NoID0gcmVhZChjb25uLCBi dWYsIHN0cmxlbihtc2cpKSkgPiAwKTsNCgkgIHByaW50ZigiJXMgZnJvbSBz ZXJ2ZXJcbiIsIGJ1Zik7DQoJICANCgkgIC8qIHNldCBSZXBseVRpbWVyKSAq Lw0KCSAgZ2V0dGltZW9mZGF5KCZ0dlJlcGx5VGltZSwgTlVMTCk7DQoJICBj UmVxdWVzdHMgPSB0dlN1YlVzZWModHZSZXF1ZXN0VGltZSwgdHZSZXBseVRp bWUpOw0KCSAgdXNUb3RhbFJlc3BvbnNlVGltZSArPSBjUmVxdWVzdHM7DQoJ ICANCgkgICh2b2lkKSBjbG9zZShjb25uKTsJCS8qIGRvbmUgd2l0aCBzb2Nr ZXQgKi8NCgkNCglmcHJpbnRmKHN0ZGVyciwgIiU4LjVmXG4iLCAoZmxvYXQp IGNSZXF1ZXN0cy8xZTYpOw0KCX0NCg0KICBmcHJpbnRmKHN0ZGVyciwgIkF2 ZXJhZ2UgUmVzcG9uc2UgVGltZSAlOC41ZiBzZWNvbmRzXG4iLCANCgkgIChm bG9hdCkgdXNUb3RhbFJlc3BvbnNlVGltZS8oaXRyICogMWU2KSk7DQogIGlm ICh0Y3Bfbm9kZWxheSkNCiAgICAgIHByaW50ZigiRGlzYWJsZWQgTmFnbGUn cyBhbGdvcml0aG0uXG4iKTsNCiAgZXhpdCgwKTsNCiAgcmV0dXJuIDA7DQp9 DQoNCg0KLyoNCiAgLSBjbGllbnRfY29tbV9jb25uZWN0DQogIC0NCiAgKiBD b25uZWN0cyB0byB0aGUgY2FjaGUgc2VydmVyDQogICoNCiAgKiBzb2NrICAg c29ja2V0IG9wZW5lZCBieSBjbGllbnQNCiAgKiBkZXN0X2hvc3QgICBob3N0 bmFtZSBvZiB0aGUgZGVzdGluYXRpb24gY2FjaGUgc2VydmVyIA0KICAqIGRl c3RfcG9ydCAgIHBvcnQgb2YgdGhlIGRlc3RfaG9zdCB0byB3aGljaCB0byBj b25uZWN0IA0KICAqDQogICogcmV0dXJucyAtMSBpZiBhbiBlcnJvciBvY2N1 cnMgMCBvdGhlcndpc2UNCiAgKiBjb25uZWN0IHJldHVybnMgMCBvbiBubyBl cnJvciANCiAgKi8gDQpzdGF0aWMgaW50DQpjbGllbnRfY29tbV9jb25uZWN0 KGludCBzb2NrLCBjaGFyICpkZXN0X2hvc3QsIHVfc2hvcnQgZGVzdF9wb3J0 KQ0Kew0KICBjb25zdCBzdHJ1Y3QgaG9zdGVudCAqaHA7DQogIHN0YXRpYyBz dHJ1Y3Qgc29ja2FkZHJfaW4gdG9fYWRkcjsNCiAgDQogIC8qIFNldCB1cCB0 aGUgZGVzdGluYXRpb24gc29ja2V0IGFkZHJlc3MgZm9yIG1lc3NhZ2UgdG8g c2VuZCB0by4gKi8NCiAgdG9fYWRkci5zaW5fZmFtaWx5ID0gQUZfSU5FVDsN CiAgDQogIGlmICgoaHAgPSBnZXRob3N0YnluYW1lKGRlc3RfaG9zdCkpID09 IDApIHsNCiAgICByZXR1cm4gKC0xKTsNCiAgfQ0KICBtZW1jcHkoJnRvX2Fk ZHIuc2luX2FkZHIsIGhwLT5oX2FkZHIsIGhwLT5oX2xlbmd0aCk7DQogIHRv X2FkZHIuc2luX3BvcnQgPSBodG9ucyhkZXN0X3BvcnQpOw0KICByZXR1cm4g Y29ubmVjdChzb2NrLCAoc3RydWN0IHNvY2thZGRyICopICZ0b19hZGRyLCBz aXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSk7DQp9DQoNCnN0YXRpYyBpbnQN CnR2U3ViVXNlYyhzdHJ1Y3QgdGltZXZhbCB0MSwgc3RydWN0IHRpbWV2YWwg dDIpDQp7DQogICAgcmV0dXJuICh0Mi50dl9zZWMgLSB0MS50dl9zZWMpICog MTAwMDAwMCArDQogICAgICAgICh0Mi50dl91c2VjIC0gdDEudHZfdXNlYyk7 DQp9DQo= ---559023410-851401618-899173587=:1437 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="server.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8ZXJybm8uaD4NCiNpbmNs dWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlIDxzaWduYWwuaD4NCiNpbmNsdWRl IDxmY250bC5oPg0KI2luY2x1ZGUgPGN0eXBlLmg+DQojaW5jbHVkZSA8dW5p c3RkLmg+DQojaW5jbHVkZSA8bGltaXRzLmg+DQojaW5jbHVkZSA8c3lzL3R5 cGVzLmg+DQojaW5jbHVkZSA8c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxzeXMv c29ja2V0Lmg+DQojaW5jbHVkZSA8bmV0aW5ldC9pbi5oPg0KI2luY2x1ZGUg PGFycGEvaW5ldC5oPg0KI2luY2x1ZGUgPG5ldGRiLmg+DQoNCiNkZWZpbmUg VElOX1BPUlQgNDg5OA0KDQppbnQgdGluZF9hcmdzKGludCBhcmdjLCBjaGFy ICphcmd2W10sIGludCAqcG9ydCwgaW50ICogYnl0ZXMpOw0KY2hhciAqIHNl bGVjdEFORHJlYWQoaW50IHRkLCBjaGFyICpidWYsIGludCBibGVuKTsNCnZv aWQgdGluZF91c2FnZShjaGFyICpwcm9nbmFtZSk7DQoNCmludCBlcnJubzsN Cg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiBhcmd2W10pIHsNCg0KICBp bnQgcmQsIGNvbm4sIHJldXNlLCBsZW4sIHBvcnQ7DQogIHN0cnVjdCBzb2Nr YWRkcl9pbiBzZWxmLCBjbGllbnQ7DQogIGNoYXIgYnVmWzIwNDhdOw0KICBp bnQgZmxhZ3M7DQogIGludCBieXRlc1RvUmVjZWl2ZSA9IDA7DQoNCiAgLyog b3B0aW9uIHBhcnNpbmcgKi8NCiAgaWYgKHRpbmRfYXJncyhhcmdjLCBhcmd2 LCAmcG9ydCwgJmJ5dGVzVG9SZWNlaXZlKSkgew0KICAgIHRpbmRfdXNhZ2Uo YXJndlswXSk7DQogIH0NCg0KICBpZiAoYnl0ZXNUb1JlY2VpdmUgPD0gMCkg ew0KICAgIHByaW50ZigiUGxlYXNlIHN1cHBseSB0aGUgIyBvZiBieXRlcyB5 b3UgZXhwZWN0IHRvIHJlY2VpdmUgcGVyIHRyaWFsLlxuIik7DQogICAgZXhp dCgxKTsNCiAgfQ0KDQoNCiAgd2hpbGUgKDEpIHsNCiAgICBjb25uID0gc29j a2V0KEFGX0lORVQsIFNPQ0tfU1RSRUFNLCAwKTsNCiAgICBpZiAoY29ubiA8 IDApIHsNCiAgICAgIHBlcnJvcigiU29ja2V0IEVycm9yISEhXG4iKTsNCiAg ICAgIGV4aXQoMSk7DQogICAgfQ0KDQogICAgbWVtc2V0KChjaGFyICopICZz ZWxmLCAwLCBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSk7DQogICAgc2Vs Zi5zaW5fZmFtaWx5ID0gQUZfSU5FVDsNCiAgICBzZWxmLnNpbl9hZGRyLnNf YWRkciA9IElOQUREUl9BTlk7DQogICAgc2VsZi5zaW5fcG9ydCA9IGh0b25z KCh1X3Nob3J0KSBwb3J0KTsNCiAgICByZXVzZSA9IDE7DQogICAgaWYgKHNl dHNvY2tvcHQoY29ubiwgU09MX1NPQ0tFVCwgU09fUkVVU0VBRERSLCAoY2hh ciAqKSAmcmV1c2UsIHNpemVvZihpbnQpKSA8IDApIHsNCiAgICAgIHBlcnJv cigic2V0c29ja29wdCBlcnJvciEhISIpOw0KICAgICAgZXhpdCgxKTsNCiAg ICB9DQoNCiAgICBpZiAoYmluZChjb25uLCAoc3RydWN0IHNvY2thZGRyICop ICZzZWxmLCBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSkgPCAwKSB7DQog ICAgICBwZXJyb3IoImJpbmQgZXJyb3IhISEiKTsNCiAgICAgIGV4aXQoMSk7 DQogICAgfQ0KDQogICAgaWYgKGxpc3Rlbihjb25uLCA1KSA8IDApIHsNCiAg ICAgIHBlcnJvcigibGlzdGVuIGVycm9yISEhIik7DQogICAgICBleGl0KDEp Ow0KICAgIH0NCg0Kdg0KICAgIGxlbiA9IHNpemVvZihzdHJ1Y3Qgc29ja2Fk ZHJfaW4pOw0KDQogICAgcmQgPSBhY2NlcHQoY29ubiwgKHN0cnVjdCBzb2Nr YWRkciAqKSAmY2xpZW50LCAmbGVuKTsNCg0KICAgIGlmIChyZCA8IDApIHsN CiAgICAgIHBlcnJvcigiYWNjZXB0IGVycm9yISEhIik7DQogICAgICBleGl0 KDEpOw0KICAgIH0NCg0KICAgIG1lbXNldChidWYsIDAsIDIwNDgpOyANCiAg ICBzZWxlY3RBTkRyZWFkKHJkLCBidWYsIGJ5dGVzVG9SZWNlaXZlKTsNCiAg ICBwcmludGYoIiVzIGZyb20gY2xpZW50XG4iLCBidWYpOw0KICAgIHNlbmQo cmQsIGJ1ZiwgYnl0ZXNUb1JlY2VpdmUsIDApOw0KICAgIGNsb3NlKGNvbm4p Ow0KICAgIGNsb3NlKHJkKTsNCiAgfQ0KfSAgDQoNCmNoYXIgKg0Kc2VsZWN0 QU5EcmVhZChpbnQgdGQsIGNoYXIgKmJ1ZiwgaW50IGJsZW4pDQp7DQogIGlu dCBpOw0KICBpbnQgZXJyOw0KICBjaGFyICpicDsNCiAgaW50IGxlbiwgbGVm dDsNCiAgY2hhciAqZXJybXNnOw0KICBmZF9zZXQgZmRzZXQ7DQogIHN0cnVj dCB0aW1ldmFsIHRpbWVvdXQ7DQogIA0KICBGRF9aRVJPKCZmZHNldCk7DQog IEZEX1NFVCh0ZCwgJmZkc2V0KTsNCiAgDQogIHRpbWVvdXQudHZfc2VjID0g MDsNCiAgdGltZW91dC50dl91c2VjID0gNTAwOw0KICANCg0KICAvKiBpbml0 aWFsaXplIHZhcmlhYmxlcyAqLw0KICBpID0gMDsNCiAgZXJybm8gPSAwOw0K ICBicCA9IGJ1ZjsNCiAgbGVmdCA9IGJsZW47DQogIGVycm1zZyA9IChjaGFy ICopIDA7DQoNCiAgLyogcG9sbCBzb2NrZXQgZm9yIGRhdGEgZXZlcnkgVElO RF9TTEVFUFVTRUMNCiAgICAgaW4gY2FzZSBjbGllbnQgb3IgY29ubmVjdGlv biBpcyBzbG93IGFuZA0KICAgICBkYXRhIGhhc24ndCBhcnJpdmVkLiAgQnV0 IGRvIHRoaXMgb25seQ0KICAgICBUSU5EX01BWFRSSUVTIHRpbWVzIHNvIHRo YXQgYnVnZ3kgY2xpZW50DQogICAgIHdvbid0IHB1dCB1cyBpbiBhbiBpbmZp bml0ZSBsb29wLg0KICAgICBCZXR0ZXIgaW1wbGVtZW50ZWQgd2l0aCBzZWxl Y3QoKS4gKi8NCiAgZG8gew0KICAgIGxlbiA9IHJlYWQodGQsIGJwLCBsZWZ0 KTsNCiAgICANCiAgICBpZiAobGVuIDwgMCAmJiBlcnJubyA9PSBFV09VTERC TE9DSykgew0KICAgICAgaSsrOw0KICAgICAgbGVuID0gMTsNCiAgICAgIGVy cm5vID0gMDsNCiAgICAgIGlmIChzZWxlY3QodGQrMSwgJmZkc2V0LCBOVUxM LCBOVUxMLCAmdGltZW91dCkgPCAwKSB7DQogICAgICAgIHByaW50ZigiRXJy b3IgaW4gZmlsZSAlcyBsaW5lICVkXG4iLCBfX0ZJTEVfXywgX19MSU5FX18p Ow0KICAgICAgICBleGl0KDEpOw0KICAgICAgfQ0KICAgIH0gZWxzZSB7DQog ICAgICBpID0gMDsNCiAgICAgIGJwICs9IGxlbjsNCiAgICAgIGxlZnQgLT0g bGVuOw0KICAgIH0NCiAgfSB3aGlsZSAobGVuID4gMCAmJiBsZWZ0ID4gMCAm JiBpIDwgMTApOw0KfQ0KICANCnZvaWQNCnRpbmRfdXNhZ2UoY2hhciAqcHJv Z25hbWUpDQp7DQogIGZwcmludGYoc3RkZXJyLCAiVXNhZ2U6ICVzIC1wIDxw b3J0bnVtPlxuIiwgcHJvZ25hbWUpOw0KICBleGl0KGVycm5vKTsNCn0NCg0K LyoNCiAqIHRpbmRfYXJnczogUGFyc2UgYXJncy4NCiAqDQogKiBSZXR1cm4g MCBvbiBzdWNjZXNzIG9yIGVycm5vIG9uIGZhaWx1cmUuDQogKiBPbiBzdWNj ZXNzZnVsIHJldHVybiwgInBvcnQiIGNvbnRhaW5zIHRoZQ0KICogcG9ydCMg dG8gdXNlLCBpbiBob3N0IGJ5dGUgb3JkZXIuDQoqLw0KaW50DQp0aW5kX2Fy Z3MoaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSwgaW50ICpwb3J0LCBpbnQgKiBi eXRlcykNCnsNCiAgY2hhciBjOw0KICBleHRlcm4gaW50IG9wdGluZDsNCiAg ZXh0ZXJuIGNoYXIgKm9wdGFyZzsNCg0KICBlcnJubyA9IDA7DQogICpwb3J0 ID0gVElOX1BPUlQ7DQogIHdoaWxlICgoYyA9IGdldG9wdChhcmdjLCBhcmd2 LCAicDpuOmw6IikpICE9IEVPRikgew0KICAgIHN3aXRjaCAoYykgew0KICAg IGNhc2UgJ3AnOg0KICAgICAgKnBvcnQgPSBhdG9pKG9wdGFyZyk7DQogICAg ICBicmVhazsNCiAgICBjYXNlICduJzoNCiAgICAgICpieXRlcyA9IGF0b2ko b3B0YXJnKTsNCiAgICAgIHJldHVybiAwOw0KICAgIGRlZmF1bHQ6DQogICAg ICBlcnJubyA9IEVJTlZBTDsNCiAgICAgIGJyZWFrOw0KICAgIH0NCiAgfQ0K DQogIHJldHVybihlcnJubyk7DQp9DQoNCg== ---559023410-851401618-899173587=:1437-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:03:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11013 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:03:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shivam.eecs.umich.edu (shivam.eecs.umich.edu [141.213.10.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA10975 for ; Mon, 29 Jun 1998 20:02:57 -0700 (PDT) (envelope-from ymc@eecs.umich.edu) Received: from localhost by shivam.eecs.umich.edu (8.9.0/8.9.0) with SMTP id XAA01557 for ; Mon, 29 Jun 1998 23:02:38 -0400 (EDT) Date: Mon, 29 Jun 1998 23:02:38 -0400 (EDT) From: Yee Man Chan To: freebsd-hackers@FreeBSD.ORG Subject: Sorry Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-899175758=:1555" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-899175758=:1555 Content-Type: TEXT/PLAIN; charset=US-ASCII I am sorry. The server.c I sent before had an extra 'v' at line 71. It won't compile. Attached is a compilable version. Sorry for the inconvenience. Yee Man ---559023410-851401618-899175758=:1555 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="server.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8ZXJybm8uaD4NCiNpbmNs dWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlIDxzaWduYWwuaD4NCiNpbmNsdWRl IDxmY250bC5oPg0KI2luY2x1ZGUgPGN0eXBlLmg+DQojaW5jbHVkZSA8dW5p c3RkLmg+DQojaW5jbHVkZSA8bGltaXRzLmg+DQojaW5jbHVkZSA8c3lzL3R5 cGVzLmg+DQojaW5jbHVkZSA8c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxzeXMv c29ja2V0Lmg+DQojaW5jbHVkZSA8bmV0aW5ldC9pbi5oPg0KI2luY2x1ZGUg PGFycGEvaW5ldC5oPg0KI2luY2x1ZGUgPG5ldGRiLmg+DQoNCiNkZWZpbmUg VElOX1BPUlQgNDg5OA0KDQppbnQgdGluZF9hcmdzKGludCBhcmdjLCBjaGFy ICphcmd2W10sIGludCAqcG9ydCwgaW50ICogYnl0ZXMpOw0KY2hhciAqIHNl bGVjdEFORHJlYWQoaW50IHRkLCBjaGFyICpidWYsIGludCBibGVuKTsNCnZv aWQgdGluZF91c2FnZShjaGFyICpwcm9nbmFtZSk7DQoNCmludCBlcnJubzsN Cg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiBhcmd2W10pIHsNCg0KICBp bnQgcmQsIGNvbm4sIHJldXNlLCBsZW4sIHBvcnQ7DQogIHN0cnVjdCBzb2Nr YWRkcl9pbiBzZWxmLCBjbGllbnQ7DQogIGNoYXIgYnVmWzIwNDhdOw0KICBp bnQgZmxhZ3M7DQogIGludCBieXRlc1RvUmVjZWl2ZSA9IDA7DQoNCiAgLyog b3B0aW9uIHBhcnNpbmcgKi8NCiAgaWYgKHRpbmRfYXJncyhhcmdjLCBhcmd2 LCAmcG9ydCwgJmJ5dGVzVG9SZWNlaXZlKSkgew0KICAgIHRpbmRfdXNhZ2Uo YXJndlswXSk7DQogIH0NCg0KICBpZiAoYnl0ZXNUb1JlY2VpdmUgPD0gMCkg ew0KICAgIHByaW50ZigiUGxlYXNlIHN1cHBseSB0aGUgIyBvZiBieXRlcyB5 b3UgZXhwZWN0IHRvIHJlY2VpdmUgcGVyIHRyaWFsLlxuIik7DQogICAgZXhp dCgxKTsNCiAgfQ0KDQoNCiAgd2hpbGUgKDEpIHsNCiAgICBjb25uID0gc29j a2V0KEFGX0lORVQsIFNPQ0tfU1RSRUFNLCAwKTsNCiAgICBpZiAoY29ubiA8 IDApIHsNCiAgICAgIHBlcnJvcigiU29ja2V0IEVycm9yISEhXG4iKTsNCiAg ICAgIGV4aXQoMSk7DQogICAgfQ0KDQogICAgbWVtc2V0KChjaGFyICopICZz ZWxmLCAwLCBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSk7DQogICAgc2Vs Zi5zaW5fZmFtaWx5ID0gQUZfSU5FVDsNCiAgICBzZWxmLnNpbl9hZGRyLnNf YWRkciA9IElOQUREUl9BTlk7DQogICAgc2VsZi5zaW5fcG9ydCA9IGh0b25z KCh1X3Nob3J0KSBwb3J0KTsNCiAgICByZXVzZSA9IDE7DQogICAgaWYgKHNl dHNvY2tvcHQoY29ubiwgU09MX1NPQ0tFVCwgU09fUkVVU0VBRERSLCAoY2hh ciAqKSAmcmV1c2UsIHNpemVvZihpbnQpKSA8IDApIHsNCiAgICAgIHBlcnJv cigic2V0c29ja29wdCBlcnJvciEhISIpOw0KICAgICAgZXhpdCgxKTsNCiAg ICB9DQoNCiAgICBpZiAoYmluZChjb25uLCAoc3RydWN0IHNvY2thZGRyICop ICZzZWxmLCBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSkgPCAwKSB7DQog ICAgICBwZXJyb3IoImJpbmQgZXJyb3IhISEiKTsNCiAgICAgIGV4aXQoMSk7 DQogICAgfQ0KDQogICAgaWYgKGxpc3Rlbihjb25uLCA1KSA8IDApIHsNCiAg ICAgIHBlcnJvcigibGlzdGVuIGVycm9yISEhIik7DQogICAgICBleGl0KDEp Ow0KICAgIH0NCg0KDQogICAgbGVuID0gc2l6ZW9mKHN0cnVjdCBzb2NrYWRk cl9pbik7DQoNCiAgICByZCA9IGFjY2VwdChjb25uLCAoc3RydWN0IHNvY2th ZGRyICopICZjbGllbnQsICZsZW4pOw0KDQogICAgaWYgKHJkIDwgMCkgew0K ICAgICAgcGVycm9yKCJhY2NlcHQgZXJyb3IhISEiKTsNCiAgICAgIGV4aXQo MSk7DQogICAgfQ0KDQogICAgbWVtc2V0KGJ1ZiwgMCwgMjA0OCk7IA0KICAg IHNlbGVjdEFORHJlYWQocmQsIGJ1ZiwgYnl0ZXNUb1JlY2VpdmUpOw0KICAg IHByaW50ZigiJXMgZnJvbSBjbGllbnRcbiIsIGJ1Zik7DQogICAgc2VuZChy ZCwgYnVmLCBieXRlc1RvUmVjZWl2ZSwgMCk7DQogICAgY2xvc2UoY29ubik7 DQogICAgY2xvc2UocmQpOw0KICB9DQp9ICANCg0KY2hhciAqDQpzZWxlY3RB TkRyZWFkKGludCB0ZCwgY2hhciAqYnVmLCBpbnQgYmxlbikNCnsNCiAgaW50 IGk7DQogIGludCBlcnI7DQogIGNoYXIgKmJwOw0KICBpbnQgbGVuLCBsZWZ0 Ow0KICBjaGFyICplcnJtc2c7DQogIGZkX3NldCBmZHNldDsNCiAgc3RydWN0 IHRpbWV2YWwgdGltZW91dDsNCiAgDQogIEZEX1pFUk8oJmZkc2V0KTsNCiAg RkRfU0VUKHRkLCAmZmRzZXQpOw0KICANCiAgdGltZW91dC50dl9zZWMgPSAw Ow0KICB0aW1lb3V0LnR2X3VzZWMgPSA1MDA7DQogIA0KDQogIC8qIGluaXRp YWxpemUgdmFyaWFibGVzICovDQogIGkgPSAwOw0KICBlcnJubyA9IDA7DQog IGJwID0gYnVmOw0KICBsZWZ0ID0gYmxlbjsNCiAgZXJybXNnID0gKGNoYXIg KikgMDsNCg0KICAvKiBwb2xsIHNvY2tldCBmb3IgZGF0YSBldmVyeSBUSU5E X1NMRUVQVVNFQw0KICAgICBpbiBjYXNlIGNsaWVudCBvciBjb25uZWN0aW9u IGlzIHNsb3cgYW5kDQogICAgIGRhdGEgaGFzbid0IGFycml2ZWQuICBCdXQg ZG8gdGhpcyBvbmx5DQogICAgIFRJTkRfTUFYVFJJRVMgdGltZXMgc28gdGhh dCBidWdneSBjbGllbnQNCiAgICAgd29uJ3QgcHV0IHVzIGluIGFuIGluZmlu aXRlIGxvb3AuDQogICAgIEJldHRlciBpbXBsZW1lbnRlZCB3aXRoIHNlbGVj dCgpLiAqLw0KICBkbyB7DQogICAgbGVuID0gcmVhZCh0ZCwgYnAsIGxlZnQp Ow0KICAgIA0KICAgIGlmIChsZW4gPCAwICYmIGVycm5vID09IEVXT1VMREJM T0NLKSB7DQogICAgICBpKys7DQogICAgICBsZW4gPSAxOw0KICAgICAgZXJy bm8gPSAwOw0KICAgICAgaWYgKHNlbGVjdCh0ZCsxLCAmZmRzZXQsIE5VTEws IE5VTEwsICZ0aW1lb3V0KSA8IDApIHsNCiAgICAgICAgcHJpbnRmKCJFcnJv ciBpbiBmaWxlICVzIGxpbmUgJWRcbiIsIF9fRklMRV9fLCBfX0xJTkVfXyk7 DQogICAgICAgIGV4aXQoMSk7DQogICAgICB9DQogICAgfSBlbHNlIHsNCiAg ICAgIGkgPSAwOw0KICAgICAgYnAgKz0gbGVuOw0KICAgICAgbGVmdCAtPSBs ZW47DQogICAgfQ0KICB9IHdoaWxlIChsZW4gPiAwICYmIGxlZnQgPiAwICYm IGkgPCAxMCk7DQp9DQogIA0Kdm9pZA0KdGluZF91c2FnZShjaGFyICpwcm9n bmFtZSkNCnsNCiAgZnByaW50ZihzdGRlcnIsICJVc2FnZTogJXMgLXAgPHBv cnRudW0+XG4iLCBwcm9nbmFtZSk7DQogIGV4aXQoZXJybm8pOw0KfQ0KDQov Kg0KICogdGluZF9hcmdzOiBQYXJzZSBhcmdzLg0KICoNCiAqIFJldHVybiAw IG9uIHN1Y2Nlc3Mgb3IgZXJybm8gb24gZmFpbHVyZS4NCiAqIE9uIHN1Y2Nl c3NmdWwgcmV0dXJuLCAicG9ydCIgY29udGFpbnMgdGhlDQogKiBwb3J0IyB0 byB1c2UsIGluIGhvc3QgYnl0ZSBvcmRlci4NCiovDQppbnQNCnRpbmRfYXJn cyhpbnQgYXJnYywgY2hhciAqYXJndltdLCBpbnQgKnBvcnQsIGludCAqIGJ5 dGVzKQ0Kew0KICBjaGFyIGM7DQogIGV4dGVybiBpbnQgb3B0aW5kOw0KICBl eHRlcm4gY2hhciAqb3B0YXJnOw0KDQogIGVycm5vID0gMDsNCiAgKnBvcnQg PSBUSU5fUE9SVDsNCiAgd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3Ys ICJwOm46bDoiKSkgIT0gRU9GKSB7DQogICAgc3dpdGNoIChjKSB7DQogICAg Y2FzZSAncCc6DQogICAgICAqcG9ydCA9IGF0b2kob3B0YXJnKTsNCiAgICAg IGJyZWFrOw0KICAgIGNhc2UgJ24nOg0KICAgICAgKmJ5dGVzID0gYXRvaShv cHRhcmcpOw0KICAgICAgcmV0dXJuIDA7DQogICAgZGVmYXVsdDoNCiAgICAg IGVycm5vID0gRUlOVkFMOw0KICAgICAgYnJlYWs7DQogICAgfQ0KICB9DQoN CiAgcmV0dXJuKGVycm5vKTsNCn0NCg0K ---559023410-851401618-899175758=:1555-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:07:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12047 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:07:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12013 for ; Mon, 29 Jun 1998 20:07:10 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id MAA04954; Tue, 30 Jun 1998 12:37:09 +0930 (CST) Message-ID: <19980630123709.O1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 12:37:09 +0930 From: Greg Lehey To: "Daniel O'Connor" , freebsd-hackers@FreeBSD.ORG Subject: Re: Serial port problems fixed with patch References: <199806300207.LAA22625@cain.gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806300207.LAA22625@cain.gsoft.com.au>; from Daniel O'Connor on Tue, Jun 30, 1998 at 11:37:28AM +0930 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 30 June 1998 at 11:37:28 +0930, Daniel O'Connor wrote: > Hi, > I just recently got a new Jet-TX motherboard, and lo and behold the serial > ports would not detect, so I tried out the patch for IWill M/B's that was > floating around, and it fixed it! :) > > I can give more info on the board if needed (ie what chips are on it > for) It would be more interesting if you would install the latest -current or -stable and see if the serial driver there works. It does on my IWill motherboard with 2.2-stable. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:12:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13279 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:12:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13205 for ; Mon, 29 Jun 1998 20:11:59 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id MAA23733; Tue, 30 Jun 1998 12:41:26 +0930 (CST) Message-Id: <199806300311.MAA23733@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Serial port problems fixed with patch In-reply-to: Your message of "Tue, 30 Jun 1998 12:37:09 +0930." <19980630123709.O1880@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 12:41:26 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It would be more interesting if you would install the latest -current > or -stable and see if the serial driver there works. It does on my > IWill motherboard with 2.2-stable. OK.. I have a fairly old current on there ATM v1.199 of sio.c I'll upgrade when I get some time :) Any idea what is a nice version of -current to go to? --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:30:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA16373 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:30:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA16300 for ; Mon, 29 Jun 1998 20:29:53 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id MAA05005; Tue, 30 Jun 1998 12:59:41 +0930 (CST) Message-ID: <19980630125941.P1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 12:59:41 +0930 From: Greg Lehey To: "Daniel O'Connor" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Serial port problems fixed with patch References: <19980630123709.O1880@freebie.lemis.com> <199806300311.MAA23733@cain.gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806300311.MAA23733@cain.gsoft.com.au>; from Daniel O'Connor on Tue, Jun 30, 1998 at 12:41:26PM +0930 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 30 June 1998 at 12:41:26 +0930, Daniel O'Connor wrote: > >> It would be more interesting if you would install the latest -current >> or -stable and see if the serial driver there works. It does on my >> IWill motherboard with 2.2-stable. > > OK.. I have a fairly old current on there ATM v1.199 of sio.c > I'll upgrade when I get some time :) > Any idea what is a nice version of -current to go to? The latest and greatest. The last relevant change to sio.c was on 16 June. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:33:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17224 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:33:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17193 for ; Mon, 29 Jun 1998 20:33:26 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id NAA24141; Tue, 30 Jun 1998 13:03:01 +0930 (CST) Message-Id: <199806300333.NAA24141@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: "Daniel O'Connor" , freebsd-hackers@FreeBSD.ORG Subject: Re: Serial port problems fixed with patch In-reply-to: Your message of "Tue, 30 Jun 1998 12:59:41 +0930." <19980630125941.P1880@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 13:03:01 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Any idea what is a nice version of -current to go to? > The latest and greatest. The last relevant change to sio.c was on 16 > June. OK, I'll try it later, and let you know. --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 20:58:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA21051 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:58:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA21037 for ; Mon, 29 Jun 1998 20:58:36 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d83.syd2.zeta.org.au [203.26.11.83]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA15022 for ; Tue, 30 Jun 1998 13:58:30 +1000 Received: (qmail 25005 invoked by uid 1000); 30 Jun 1998 03:39:00 -0000 Message-ID: <19980630133900.A24973@reilly.home> Date: Tue, 30 Jun 1998 13:39:00 +1000 From: Andrew Reilly To: Jamie Bowden , "Ron G. Minnich" Cc: hackers@FreeBSD.ORG Subject: Re: I2O References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Jamie Bowden on Mon, Jun 29, 1998 at 03:18:17PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 03:18:17PM -0400, Jamie Bowden wrote: > On Mon, 29 Jun 1998, Ron G. Minnich wrote: > > > I2O will be a footnote in a year or so. After that, it will be forgotten > > and in 10 years someone else will reinvent the idea and learn the hard > > way why it is a bad one (as I2O is itself a reinvention of old, bad ideas). > > Why is offloading IO a bad idea? Offloading video and 3D rendering work > well, it's what drives 3dfx and it's competitors. Or am I missing > something? My basic understanding of I2O is using a subprocessor to > handle all IO, thus freeing up the main processor from doing things like > waiting on interrupts and the like. I suspect that the "wheel of reincarnation" has something to say about this. The 3D rendering boards are doing a specific operation that happens to be very popular at the moment, which is keeping it alive. It's never going to be as popular as general purpose processors, though, so they will eventually overtake the special purpose 3D engines, and you'll have dumb(ish) frame buffers again. That way you get to keep your textures and geometry models in main memory, which is so much faster...(by then). Why would you want to spend money on another processor, memory subsystem, and so on, for a processor that can't (doesn't) run FreeBSD? You're better off building a multi-processor system that does. That's why SMP systems are much more popular now than the multi-processors that kept one CPU for the operating system, that came before. Of course, the reason that the wheel of reincarnation is there at all is that it's easier to attack each problem with a specific solution, as it arises, than it is to re-orient the general purpose solution as required. So you get blips of non-generality, while the general purpose solution figures out what to do. In this case, the problem that I2O is solving is the poor interrupt performance of the current general purpose processors, and the poor real-time performance of the current operating systems. There are existence proofs that neither of these faults is insurmountable (vis ARM, i960 etc; QNX, VxWorks, others..), so one can assume that the general purpose solution is going to steamroller the special-purpose one pretty quickly, unless other factors (political, rather than technical) get in the way. -- Andrew "The steady state of disks is full." -- Ken Thompson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 21:24:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA25097 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 21:24:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from homer.supersex.com (homer.supersex.com [209.5.1.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA25081 for ; Mon, 29 Jun 1998 21:24:49 -0700 (PDT) (envelope-from leo@homer.supersex.com) Received: (from leo@localhost) by homer.supersex.com (8.8.8/8.8.5) id AAA11964; Tue, 30 Jun 1998 00:25:47 -0400 (EDT) Message-ID: <19980630002547.30271@supersex.com> Date: Tue, 30 Jun 1998 00:25:47 -0400 From: Leo Papandreou To: hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net References: <199806300045.UAA04359@whizzo.transsys.com> <5776.899169085@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <5776.899169085@time.cdrom.com>; from Jordan K. Hubbard on Mon, Jun 29, 1998 at 06:11:25PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 06:11:25PM -0700, Jordan K. Hubbard wrote: > > It's very unlikely that the spam originates from anyone with a mailbox on > > a UU.NET system. You're probably seeing it from addresses which are in the > > foo.DA.UU.NET or bar.MS.UU.NET which are PPP pool addresses used by resellers > > of the dial network infrastructure. These would include MSN, AOL, Earthlink, > > the Well, WebTV and many others. > 99% of which are vulnerable to a teardrop attack. Instant SPAM cancel. > Right, and I think I made this point in my original email. Since > they're clearly reselling to a lot of folks with no scruples WRT UCE > at all, the easiest thing to do is simply block *.uu.net since I I personally think you are cutting off too many people by blocking uu.net. Uu.net is a *lot* of dialups I'm doubt uu.net has any con- trol over spammers who open an account with MSN, connect and funnel their spam to earthlink or some place in hungary. Spamming software has gotten pretty good at what it does. > certainly don't want the job of having to track down every foo.uu.net > subdomain resold to a spammer-friendly ISP. As Jon has also already > noted, the folks directly affected by this seem quite small and I've > gotten *far* less spam in my mailbox today as a result, so as far as > I'm concerned the exercise is an unqualified success. > > > If you tried to report this to abuse@uu.net and that didn't yield > > satisfactory results, please let me know. While "god ... knows > > which .. is repsonsible > > Heh. I reported it so many times and so frequently that Paul Vixie > finally asked me to cc him on all the reports, someting which I did > for a couple of months until we both got tired of the exercise. > > - Jordan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 21:25:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA25215 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 21:25:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ibridge.iohk.com (root@ibridge.iohk.com [202.21.128.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA25198 for ; Mon, 29 Jun 1998 21:25:18 -0700 (PDT) (envelope-from percy@iohk.com) Received: from igate.iohk.com (percy@igate.iohk.com [202.21.128.81]) by ibridge.iohk.com (8.8.5/8.8.5) with ESMTP id MAA29239 for ; Tue, 30 Jun 1998 12:27:35 +0800 (HKT) Received: from localhost (percy@localhost) by igate.iohk.com (8.8.5/8.8.5) with SMTP id MAA26054 for ; Tue, 30 Jun 1998 12:27:35 +0800 (HKT) Date: Tue, 30 Jun 1998 12:27:34 +0800 (HKT) From: Percy Cheng To: hackers@FreeBSD.ORG Subject: How to attached printer on Netware4.11 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to know how to attach the printer that's located on Novell's intranetware? I'll appricate that anyone can give me a hand...=~> Percy Cheng Internet Online Hong Kong Ltd. Our Web Site:http://www.iohk.com My email box:percy@iohk.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 22:39:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04662 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 22:39:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04657 for ; Mon, 29 Jun 1998 22:39:57 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id BAA01896; Tue, 30 Jun 1998 01:39:51 -0400 (EDT) Date: Tue, 30 Jun 1998 01:39:51 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Leo Papandreou cc: hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net In-Reply-To: <19980630002547.30271@supersex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How hard is it to allow uu.net mail relays, but no direct connections from dialups, ie: foo.tnt.foo.uu.net is blocked but smtp.uu.net is not? I'm looking to do something like this here, but haven't revisited sendmail in some time. There's no reason for a dialup connection to send me (or anyone else) mail directly. They should be sending via their ISP's relay instead. Charles Charles Sprickman spork@super-g.com ---- On Tue, 30 Jun 1998, Leo Papandreou wrote: > On Mon, Jun 29, 1998 at 06:11:25PM -0700, Jordan K. Hubbard wrote: > > > It's very unlikely that the spam originates from anyone with a mailbox on > > > a UU.NET system. You're probably seeing it from addresses which are in the > > > foo.DA.UU.NET or bar.MS.UU.NET which are PPP pool addresses used by resellers > > > of the dial network infrastructure. These would include MSN, AOL, Earthlink, > > > the Well, WebTV and many others. > > > > 99% of which are vulnerable to a teardrop attack. Instant SPAM > cancel. > > > Right, and I think I made this point in my original email. Since > > they're clearly reselling to a lot of folks with no scruples WRT UCE > > at all, the easiest thing to do is simply block *.uu.net since I > > I personally think you are cutting off too many people by blocking > uu.net. Uu.net is a *lot* of dialups I'm doubt uu.net has any con- > trol over spammers who open an account with MSN, connect and funnel > their spam to earthlink or some place in hungary. Spamming software > has gotten pretty good at what it does. > > > > > certainly don't want the job of having to track down every foo.uu.net > > subdomain resold to a spammer-friendly ISP. As Jon has also already > > noted, the folks directly affected by this seem quite small and I've > > gotten *far* less spam in my mailbox today as a result, so as far as > > I'm concerned the exercise is an unqualified success. > > > > > If you tried to report this to abuse@uu.net and that didn't yield > > > satisfactory results, please let me know. While "god ... knows > > > which .. is repsonsible > > > > Heh. I reported it so many times and so frequently that Paul Vixie > > finally asked me to cc him on all the reports, someting which I did > > for a couple of months until we both got tired of the exercise. > > > > - Jordan > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 22:55:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06490 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 22:55:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06481; Mon, 29 Jun 1998 22:55:30 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA12709; Tue, 30 Jun 1998 01:54:56 -0400 (EDT) Date: Tue, 30 Jun 1998 01:54:56 -0400 (EDT) From: "Matthew N. Dodd" To: "Jordan K. Hubbard" cc: "Louis A. Mamakos" , "Jonathan M. Bresler" , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net In-Reply-To: <5776.899169085@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Jordan K. Hubbard wrote: > Right, and I think I made this point in my original email. Since > they're clearly reselling to a lot of folks with no scruples WRT UCE at > all, the easiest thing to do is simply block *.uu.net since I certainly > don't want the job of having to track down every foo.uu.net subdomain > resold to a spammer-friendly ISP. No such domains exist. Customer domains are not delegated in the uu.net zone. /* 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 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 22:55:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06590 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 22:55:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06579 for ; Mon, 29 Jun 1998 22:55:55 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id BAA08270; Tue, 30 Jun 1998 01:55:51 -0400 (EDT) Date: Tue, 30 Jun 1998 01:55:51 -0400 (EDT) From: Snob Art Genre Reply-To: ben@rosengart.com To: Yee Man Chan cc: freebsd-hackers@FreeBSD.ORG Subject: Re: client-server problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Yee Man Chan wrote: > Here is how the program performs under FreeBSD 3.0-CURRENT with different > n: > 1-100 Very fast > 101-207 Very Slow (This range is the strangest I've ever seen) > 208-1024 Very fast (just like 1-100) > >1024 strange errors like unknown host or connection timedout > > Any clue? I don't know about your >1024 problems, but the rest is explainable. It has to do with the way memory is allocated in the kernel for network i/o. I don't remember the exact details, but it's all put forth quite clearly in W. Richard Stevens' _TCP/IP Illustrated Vol. 3_, with graphs and everything. Are you using TCP or UDP? What kind of link are you going over? Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 22:59:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06866 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 22:59:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06860 for ; Mon, 29 Jun 1998 22:59:03 -0700 (PDT) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id WAA22302; Mon, 29 Jun 1998 22:58:41 -0700 (PDT) Date: Mon, 29 Jun 1998 22:58:40 -0700 (PDT) From: Ian Kallen To: Greg Lehey cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ccd configuration In-Reply-To: <19980630110259.A1880@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Looks interesting. I think I recall hearing that the Veritas technology is what hpux and irix use for their dynamic filesystems, that'd be awesome to have something like it rolled into FreeBSD. Once I get things square with my server deployments, I'll try giving vinum a go. Meantime, I'll get these servers going with ccd the constituent filesystems newfs'd prior to ccd'ing them :) Thanks, -Ian On Tue, 30 Jun 1998, Greg Lehey wrote: :> :> Great. That works. I'm just curious why I needed to newfs the disks :> :> individually prior to ccd'ing them? Or did I? :> :No. :> :> Hmm I did because the example in the ccdconfig man page was not using :> the raw devices, when I try running it on a raw device ccdconfig complains :> that it wants a blockdevice and if it's not newfs'd, it complains like :> ccdconfig: ioctl (CCDIOCSET): /dev/ccd1c: Invalid argument : :Hmm. Interesting. This shouldn't be necessary, and I can't remember :having done this when I tried it, but I don't have time to try it out :again. : :Have you looked at vinum? http://www.lemis.com/vinum.html -- Bart: Gee Homer, it looks like you've got yourself a real problem on your hands. Homer: Your right... Uhh... Bart! Vacuum this floor! Bart: Hey Man! I didn't do anything wrong! Homer: In times of trouble you've got to go with what you know. Now hop to it boy! -- ``Moaning Lisa'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 23:26:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10929 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 23:26:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10898; Mon, 29 Jun 1998 23:26:11 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id PAA07197; Tue, 30 Jun 1998 15:56:09 +0930 (CST) Message-ID: <19980630155609.W1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 15:56:09 +0930 From: Greg Lehey To: mkn , freebsd-questions@FreeBSD.ORG Cc: FreeBSD Hackers Subject: Re: Unsupport calls Reply-To: FreeBSD Hackers References: <359823C8.3A28@emailbox.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <359823C8.3A28@emailbox.lucent.com>; from mkn on Mon, Jun 29, 1998 at 07:31:20PM -0400 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a more appropriate message for -hackers, so I'm following up there. On Monday, 29 June 1998 at 19:31:20 -0400, mkn wrote: > Hello! > > I'm looking to port a solaris 2.5 system to FreeBSD. My investigation > has found the following library and system calls to *not* be supported > on FreeBSD: > > Are my observations correct? Partially. I've rearranged these slightly. My comments relate to 3.0-CURRENT, but I've checked 2.2-STABLE and there doesn't seem to be a big difference. > fdatasync - no support in FreeBSD. Maybe not a big deal. Yes, I can't find it either, not even in the Solaris man pages. What does it do? > sigwait - no support in FreeBSD. > sigset - no support in FreeBSD > sighold - no support in FreeBSD > sigrelse - no support in FreeBSD These are the System V signal functions, arguably the worst choice of the currently available signal implementations. FreeBSD has the BSD functions instead, as well as the POSIX.1 signals which were derived from them. See more about this in my book "Porting UNIX software". I recommend porting to the POSIX.1 signals, which are also supported by Solaris. > time - no support in FreeBSD, but there has to be a replacement. time(3) is in libc.a. I don't see how you missed this one. > lockf - no support in FreeBSD. Have to implement our own using fcntl(2) Correct. Again, an improvement which should also work under Solaris. > plock - no support in FreeBSD. Correct. I'm not sure how to do this one, either. What do you need it for? > pthread_sigmask - no support in FreeBSD > pthread_kill - no support in FreeBSD > pthread_mutex_init - no support in FreeBSD > pthread_mutex_lock - no support in FreeBSD > pthread_mutex_unlock - no support in FreeBSD > pthread_mutex_destroy - no support in FreeBSD > pthread_attr_init - no support in FreeBSD > pthread_attr_setscope - no support in FreeBSD > pthread_cancel - no support in FreeBSD > pthread_testcancel - no support in FreeBSD > pthread_setcancelstate - no support in FreeBSD > pthread_setcanceltype - no support in FreeBSD These are all in libc_r.. > readdir_r - no support on FreeBSD. This maybe a threads issue Correct. There's a readdir in libc_r.a. I wonder if it corresponds. > If so, are there alternative calls that I can use as a replacement? About the only serious one I can see is plock. Maybe somebody else on the list can comment. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jun 29 23:51:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA15793 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 23:51:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA15770 for ; Mon, 29 Jun 1998 23:51:39 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.8/8.8.7) id UAA24969; Mon, 29 Jun 1998 20:39:34 -0700 (PDT) Message-ID: <19980629203933.13968@hydrogen.nike.efn.org> Date: Mon, 29 Jun 1998 20:39:33 -0700 From: John-Mark Gurney To: Terry Lambert Cc: Peter da Silva , hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration References: <199806291813.NAA17351@bonkers.taronga.com> <199806291958.MAA04488@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199806291958.MAA04488@usr08.primenet.com>; from Terry Lambert on Mon, Jun 29, 1998 at 07:58:47PM +0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.6-STABLE 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 Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert scribbled this message on Jun 29: > > Actually, you know, a registry implemented as Windows-style INI files > > would be pretty easy to hand-edit OR machine-edit. It's one of the few > > things that Microsoft came up with (if they did, I wouldn't be surprised > > to learn that they just appropriated something some app was using) that's > > actually reasonably well designed. And it'd make it REALLY easy to slip > > Samba in... > > ??? > > Samba implements a .INI file manipulation library. But it is evil. > > The reason for the Windows 95 registry implementation was the explosive > proliferation of .INI files. I would hate for FreeBSD to go down that hun? I thought win31 had a registry too, it's just that apps didn't use/didn't have access to the registry... I remeber running regedit on a win31 box... > road; it's already partly there, and that's what FreeBSD has been > moving *away* from. > > Consider an installation of a tool that requires a shared library; > the shared library is reference counted in the Windows 95 Registry > so that (1) it can be deleted when it is no longer referenced, and > (2) so that it is not delete prematurely as part of a deinstall. > > The ability to reuse shared objects without damaging the ability > to deinstall them is precisely the reason for a *central* information > repository. > > Granted, that's less of an issue for FreeBSD, since there is so very > little commercial software available. 8-|. -- John-Mark Gurney Voice: +1 541 683 7109 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 00:02:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17296 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 00:02:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA17266 for ; Tue, 30 Jun 1998 00:02:22 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id JAA27806 ; Tue, 30 Jun 1998 09:01:49 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id JAA08024; Tue, 30 Jun 1998 09:01:48 +0200 To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: mmap() with stdin/stdout References: <199806291841.LAA21198@usr01.primenet.com> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 30 Jun 1998 09:01:48 +0200 In-Reply-To: Terry Lambert's message of Mon, 29 Jun 1998 18:41:45 +0000 (GMT) Message-ID: Lines: 26 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > BTW, 'advice' (the noun) is misspelt as 'advise' in the mincore(2) and > > madvise(2) man pages. The spelling of madvise() may also be construed > > as a bug unless one argues that 'advise' (the verb) is intended. > The verb is intended. The "madvise(2)" call _advises_ the kernel > about your intended use of the memory. Yes, but "advise" is also used in the NAME section instead of "advice": MADVISE(2) FreeBSD System Calls Manual MADVISE(2) NAME madvise - give advise about use of memory MINCORE(2) FreeBSD System Calls Manual MINCORE(2) NAME mincore - get advise about use of memory DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 00:03:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17513 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 00:03:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA17482 for ; Tue, 30 Jun 1998 00:03:44 -0700 (PDT) (envelope-from smoergrd@oslo.geco-prakla.slb.com) Received: from sunw157.oslo.Geco-Prakla.slb.com (sunw157 [192.23.231.83]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id JAA27858 ; Tue, 30 Jun 1998 09:02:26 +0200 (MET DST) Received: by sunw157.oslo.Geco-Prakla.slb.com (SMI-8.6/SMI-SVR4) id JAA08026; Tue, 30 Jun 1998 09:02:25 +0200 To: joelh@gnu.org Cc: belkovic@albert.osu.cz, freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET References: <199806291440.JAA02540@detlev.UUCP> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 30 Jun 1998 09:02:25 +0200 In-Reply-To: Joel Ray Holveck's message of Mon, 29 Jun 1998 09:40:15 -0500 (CDT) Message-ID: Lines: 15 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joel Ray Holveck writes: > >> I will try in asembler only following: > >> a) i change cpu mode from protected to 'normal' > >> b) i change appropriate segment registers > >> c) i change appropriate bios constant to enable warm post > >> d) i will call appropritae bios function (int 19h ?) > > No, jo do a long jump to FFFF:0 IIRC. > I thought it was F000:0... You may want to consult the pink shirt > book. (Mine's 90 miles away right now, sorry.) Which is why I added IIRC :) DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 00:24:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA20872 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 00:24:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20855 for ; Tue, 30 Jun 1998 00:24:14 -0700 (PDT) (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.8/8.8.8) with ESMTP id AAA07123; Tue, 30 Jun 1998 00:23:45 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Ian Kallen cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ccd configuration In-reply-to: Your message of "Mon, 29 Jun 1998 17:14:57 PDT." Date: Tue, 30 Jun 1998 00:23:44 -0700 Message-ID: <7118.899191424@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Great. That works. I'm just curious why I needed to newfs the disks > individually prior to ccd'ing them? Or did I? Is there any documentation You didn't - you only needed to have valid disk labels on them. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 00:42:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23675 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 00:42:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23594; Tue, 30 Jun 1998 00:42:11 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id RAA07620; Tue, 30 Jun 1998 17:12:02 +0930 (CST) Message-ID: <19980630171202.D1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 17:12:02 +0930 From: Greg Lehey To: Stephen Hocking-Senior Programmer PGS Tensor Perth , hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: Clusters, Distributed File Systems and FreeBSD References: <199806220450.MAA15275@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806220450.MAA15275@ariadne.tensor.pgs.com>; from Stephen Hocking-Senior Programmer PGS Tensor Perth on Mon, Jun 22, 1998 at 12:50:45PM +0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 22 June 1998 at 12:50:45 +0800, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > Is anyone doing work on distributed filesystems (where files can be spread > across > 1 node) on FreeBSD? The reason I'm interested is because I'm working > for a Seismic DP company, and we use clusters all over the place (mainly IBM > SP2 systems). They share filesystems using PIOFS, where each node has a 4GB > disk shared out out. These are combined together and seen as one ginormous fs. I'm planning to put support for multi-node plexes into Vinum. This is more remote replication than distributed file systems, of course. If you or anybody else have any suggestions or wishes, please let me know. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 00:56:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA26362 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 00:56:18 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA26182; Tue, 30 Jun 1998 00:55:12 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id JAA17640; Tue, 30 Jun 1998 09:53:53 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id JAA06939; Tue, 30 Jun 1998 09:54:10 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980630155609.W1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 09:54:10 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: FreeBSD Hackers Subject: Re: Unsupport calls Cc: freebsd-questions@FreeBSD.ORG, mkn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Jun-98 Greg Lehey wrote: > >> sigwait - no support in FreeBSD. >> sigset - no support in FreeBSD >> sighold - no support in FreeBSD >> sigrelse - no support in FreeBSD > > These are the System V signal functions, arguably the worst choice of > the currently available signal implementations. FreeBSD has the BSD > functions instead, as well as the POSIX.1 signals which were derived > from them. See more about this in my book "Porting UNIX software". I > recommend porting to the POSIX.1 signals, which are also supported by > Solaris. > sigwait is in libc_r, being a part of POSIX pthread specification. /Marino > > Greg > -- > See complete headers for address and phone numbers > finger grog@lemis.com for PGP public key > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ---------------------------------- Marino Ladavac Date: 30-Jun-98 Time: 09:52:37 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 02:18:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09982 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 02:18:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from omnix.net (omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA09911 for ; Tue, 30 Jun 1998 02:17:44 -0700 (PDT) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost) by omnix.net (8.8.7/8.8.7) with SMTP id JAA28820 for ; Tue, 30 Jun 1998 09:17:41 GMT (envelope-from didier@omnix.net) Date: Tue, 30 Jun 1998 11:17:41 +0200 (CEST) From: Didier Derny To: hackers@FreeBSD.ORG Subject: ppp with the latest SNAPSHOT (may) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, user ppp worked fine for years but after having changed my mother board/ upgraded to the latest snapshot it is not working anymore as I did both operation at the same time I dont know if the problem comes from the mother board or user ppp. the mother board is an Asus P2B (chipset BX) do you have any clue ? thanks for your help -- Didier Derny didier@omnix.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 02:59:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA15858 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 02:59:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA15835; Tue, 30 Jun 1998 02:59:16 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id TAA08030; Tue, 30 Jun 1998 19:29:10 +0930 (CST) Message-ID: <19980630192910.H1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 19:29:10 +0930 From: Greg Lehey To: Marino Ladavac , FreeBSD Hackers Cc: freebsd-questions@FreeBSD.ORG, mkn Subject: Re: Unsupport calls References: <19980630155609.W1880@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Marino Ladavac on Tue, Jun 30, 1998 at 09:54:10AM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 30 June 1998 at 9:54:10 +0200, Marino Ladavac wrote: > > On 30-Jun-98 Greg Lehey wrote: >> >>> sigwait - no support in FreeBSD. >>> sigset - no support in FreeBSD >>> sighold - no support in FreeBSD >>> sigrelse - no support in FreeBSD >> >> These are the System V signal functions, arguably the worst choice of >> the currently available signal implementations. FreeBSD has the BSD >> functions instead, as well as the POSIX.1 signals which were derived >> from them. See more about this in my book "Porting UNIX software". I >> recommend porting to the POSIX.1 signals, which are also supported by >> Solaris. >> > sigwait is in libc_r, being a part of POSIX pthread specification. That's a different sigwait. This one is, by association, one of the calls of the System V signals implementation. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 03:14:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA18288 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 03:14:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.133.1] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA18231; Tue, 30 Jun 1998 03:14:34 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id MAA13587; Tue, 30 Jun 1998 12:11:48 +0200 (CEST) To: Peter Wemm cc: "Paul T. Root" , rminnich@Sarnoff.COM (Ron G. Minnich), hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: looking for ram file system (NOT MFS) In-reply-to: Your message of "Tue, 30 Jun 1998 06:11:28 +0800." <199806292211.GAA03588@spinner.netplex.com.au> Date: Tue, 30 Jun 1998 12:11:47 +0200 Message-ID: <13585.899201507@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199806292211.GAA03588@spinner.netplex.com.au>, Peter Wemm writes: >"Paul T. Root" wrote: >> In a previous message, Ron G. Minnich said: >> > I'm looking for something like a ram file system for some work i'm doing. >> > It needs to support ram-based lookup, mkdir, rmdir, etc. It needs to be >> > BSD or GPL copyright, and run under current. Any pointers appreciated. >> >> mfs > >Recheck the subject line: "looking for ram file system (NOT MFS)" > ^^^^^^^^^ >I believe Poul-Henning Kamp was working on a mallocfs at some point.. > >MFS is bad in that it doesn't allocate and release swap. It'd be seriously >great to have something that could allocate and free pageable memory as >files were written and deleted. MFS never releases swap space once the >mount_mfs process faults in an anon page. Doing it seperately from UFS >would be a good start since it wouldn't be wasting time emulating a disk >structure. Actually doing it separately from UFS would be a waste of time, but that is a different issue. the mallocfs I wrote used the kernel malloc and was consequently limited to 20Mbyte and non-pageable. A "vmfs" is on my wishlist too... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 04:07:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA26550 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 04:07:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pteradactyl (pteradactyl.vaniercollege.qc.ca [205.236.144.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA26488 for ; Tue, 30 Jun 1998 04:07:10 -0700 (PDT) (envelope-from labrinop@pop.vaniercollege.qc.ca) From: labrinop@pop.vaniercollege.qc.ca Received: from labrinop.vaniercollege.qc.ca by pteradactyl (SMI-8.6/SMI-SVR4) id HAA23527; Tue, 30 Jun 1998 07:08:57 -0400 Message-Id: <199806301108.HAA23527@pteradactyl> To: Josef Belkovics Date: Tue, 30 Jun 1998 07:07:32 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: BROKEN_KEYBOARD_RESET CC: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Jun 1998 Josef Belkovics wrote: > My home pc (Cyrix 486DX4) does not a CPU reset via the keyboard > controller or via invltbl() (/sys/i386/i386/vm_machdep.c). Is > somebody able to say me patch which will reset through bios. Or in > some other way. (Don't write - throw it out.) A software reset is generated by asserting a bit in the 8042 keyboard controller (thats why its called KEYBOARD_RESET), ie: MOV AL , 0xFE ; pulse 8042 output port with bit 0 must be low OUT 0x64 , AL ; output to 8042 command register this is how it has been done since the PC/AT (PC & PC/XT doesn't have this) and is still done. The above sequence has the same effect as the RESET button (internally their wired together). But some motherboard/chipsets are broken and don't work correctly. Another way to reset the system while still in protected mode is to generate a triple fault: clear IDT entries 8 (Double Fault) and 10 (Invalid TSS) and then load TR with an illegal selector. > invalid tss > double fault > triple fault > cpu shutdown > reset PeterL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 04:53:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA06106 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 04:53:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA06010; Tue, 30 Jun 1998 04:52:01 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id NAA01960; Tue, 30 Jun 1998 13:51:23 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id NAA07807; Tue, 30 Jun 1998 13:51:39 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980630192910.H1880@freebie.lemis.com> Date: Tue, 30 Jun 1998 13:51:39 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: Greg Lehey Subject: Re: Unsupport calls Cc: mkn , freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Jun-98 Greg Lehey wrote: > On Tuesday, 30 June 1998 at 9:54:10 +0200, Marino Ladavac wrote: >> >> On 30-Jun-98 Greg Lehey wrote: >>> >>>> sigwait - no support in FreeBSD. >>>> sigset - no support in FreeBSD >>>> sighold - no support in FreeBSD >>>> sigrelse - no support in FreeBSD >>> >>> These are the System V signal functions, arguably the worst choice of >>> the currently available signal implementations. FreeBSD has the BSD >>> functions instead, as well as the POSIX.1 signals which were derived >>> from them. See more about this in my book "Porting UNIX software". I >>> recommend porting to the POSIX.1 signals, which are also supported by >>> Solaris. >>> >> sigwait is in libc_r, being a part of POSIX pthread specification. > > That's a different sigwait. This one is, by association, one of the > calls of the System V signals implementation. > I beg to differ (and so do my SunOS 5 manpages). The SysV simplified signal management APIs are: signal(3C) C Library Functions signal(3C) NAME signal, sigset, sighold, sigrelse, sigignore, sigpause - simplified signal management for application processes whereas: sigwait(2) System Calls sigwait(2) NAME sigwait - wait until a signal is posted SYNOPSIS #include int sigwait(sigset_t *set); POSIX ^^^^^ cc [ flag... ] file ... - D_POSIX_PTHREAD_SEMANTICS [ ^^^^^^^^^^^^^^^^^^^^^^^^^ library... ] #include int sigwait(const sigset_t *set, int *sig); DESCRIPTION sigwait() selects a signal in set that is pending on the calling thread (see thr_create(3T)) or LWP. If no signal in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is the very same sigwait() that resides in libc_r on FreeBSD, name similarities notwithstanding. Non-POSIX version is from the now deprecated SunOS 5 LWP API. > Greg > -- > See complete headers for address and phone numbers > finger grog@lemis.com for PGP public key > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ---------------------------------- Marino Ladavac Date: 30-Jun-98 Time: 13:42:21 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 05:22:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA09887 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 05:22:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from horton.iaces.com (horton.iaces.com [204.147.87.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA09861; Tue, 30 Jun 1998 05:22:27 -0700 (PDT) (envelope-from proot@horton.iaces.com) Received: (from proot@localhost) by horton.iaces.com (8.8.7/8.8.7) id HAA14519; Tue, 30 Jun 1998 07:16:31 -0500 (CDT) From: "Paul T. Root" Message-Id: <199806301216.HAA14519@horton.iaces.com> Subject: Re: looking for ram file system (NOT MFS) In-Reply-To: <13585.899201507@critter.freebsd.dk> from Poul-Henning Kamp at "Jun 30, 1998 12:11:47 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 30 Jun 1998 07:16:31 -0500 (CDT) Cc: peter@netplex.com.au, rminnich@Sarnoff.COM, hackers@FreeBSD.ORG, questions@FreeBSD.ORG X-Organization: USWEST !nterprise Networking - ACES X-Phone: (612) 664-3385 X-Fax: (612) 664-4779 X-Page: (800) SKY-PAGE PIN: 537-7270 X-Address: 600 Stinson Blvd, Fl 1S X-Address: Minneapolis, MN 55413 X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In a previous message, Poul-Henning Kamp said: > >I believe Poul-Henning Kamp was working on a mallocfs at some point.. > > > >MFS is bad in that it doesn't allocate and release swap. It'd be seriously > >great to have something that could allocate and free pageable memory as > >files were written and deleted. MFS never releases swap space once the > >mount_mfs process faults in an anon page. Doing it seperately from UFS > >would be a good start since it wouldn't be wasting time emulating a disk > >structure. > > Actually doing it separately from UFS would be a waste of time, but that > is a different issue. > > the mallocfs I wrote used the kernel malloc and was consequently limited > to 20Mbyte and non-pageable. This would be useful to me for my custom install script. Paul. -- IRS HUMOR EXAMPLE A: "A lawyer, a doctor, and a priest were marooned on a desert island. So we confiscated their homes." --Dave Barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 06:53:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24526 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 06:53:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from donkeykong.rs.itd.umich.edu (smtp@donkeykong.rs.itd.umich.edu [141.211.63.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24467 for ; Tue, 30 Jun 1998 06:53:14 -0700 (PDT) (envelope-from ymc@umich.edu) Received: from qbert.rs.itd.umich.edu (smtp@qbert.rs.itd.umich.edu [141.211.63.94]) by donkeykong.rs.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id JAA12207; Tue, 30 Jun 1998 09:53:11 -0400 (EDT) Received: from localhost (ymc@localhost) by qbert.rs.itd.umich.edu (8.8.8/5.1-client) with SMTP id JAA27422; Tue, 30 Jun 1998 09:53:10 -0400 (EDT) Date: Tue, 30 Jun 1998 09:53:10 -0400 (EDT) From: Yee Man Chan X-Sender: ymc@qbert.rs.itd.umich.edu To: ben@rosengart.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: client-server problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Snob Art Genre wrote: > On Mon, 29 Jun 1998, Yee Man Chan wrote: > > > Here is how the program performs under FreeBSD 3.0-CURRENT with different > > n: > > 1-100 Very fast > > 101-207 Very Slow (This range is the strangest I've ever seen) > > 208-1024 Very fast (just like 1-100) > > >1024 strange errors like unknown host or connection timedout > > > > Any clue? > > I don't know about your >1024 problems, but the rest is explainable. It > has to do with the way memory is allocated in the kernel for network > i/o. I don't remember the exact details, but it's all put forth quite > clearly in W. Richard Stevens' _TCP/IP Illustrated Vol. 3_, with graphs > and everything. > > Are you using TCP or UDP? What kind of link are you going over? Thanks for your response. I will consult Stevens' book. I am using TCP. I don't think anything is going over a link. The program assumes localhost communication, so nothing should be go over a link. I run the program in SunOS but unlike FreeBSD, 101<=n<=207 is just as fast as <100 and >207 <1025. Why? Is it because SunOS and FreeBSD have different memory allocated in the kernel for network i/o? Yee Man P.S. Did I send the email attached with my server-client code? You should be able to get it and show me where my bugs are. If there is no files being attached, tell me and I will put the source code in the email. > > > > Ben > > "You have your mind on computers, it seems." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 07:05:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26679 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 07:05:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yoda.pi.musin.de (yoda.pi.musin.de [194.246.250.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26672 for ; Tue, 30 Jun 1998 07:05:50 -0700 (PDT) (envelope-from sec@yoda.pi.musin.de) Received: (from sec@localhost) by yoda.pi.musin.de (8.8.8/8.8.8) id QAA02193; Tue, 30 Jun 1998 16:04:16 +0200 (CEST) (envelope-from sec) Message-ID: <19980630160415.A2179@yoda.pi.musin.de> Date: Tue, 30 Jun 1998 16:04:15 +0200 From: Stefan Zehl To: Andre Albsmeier , Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running References: <199806291610.JAA00380@dingo.cdrom.com> <199806291859.UAA28827@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.6i In-Reply-To: <199806291859.UAA28827@internal>; from Andre Albsmeier on Mon, Jun 29, 1998 at 08:59:40PM +0200 I-love-doing-this: really X-URL: http://sec.42.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 08:59:40PM +0200, Andre Albsmeier wrote: > However, the installed thing doesn't run properly and consumes only cpu time > but I hadn't had time to investigate this yet... The installed program requires '/proc//cmdline', too. Doing that sed-thing again on the soffice.bin will probably help you. CU, Sec -- Komme wieder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 07:21:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28609 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 07:21:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yoda.pi.musin.de (yoda.pi.musin.de [194.246.250.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28600 for ; Tue, 30 Jun 1998 07:21:28 -0700 (PDT) (envelope-from sec@yoda.pi.musin.de) Received: (from sec@localhost) by yoda.pi.musin.de (8.8.8/8.8.8) id QAA02232; Tue, 30 Jun 1998 16:21:15 +0200 (CEST) (envelope-from sec) Message-ID: <19980630162115.C2179@yoda.pi.musin.de> Date: Tue, 30 Jun 1998 16:21:15 +0200 From: Stefan Zehl To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running References: <19980629132002.A13667@yoda.pi.musin.de> <199806291610.JAA00380@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.6i In-Reply-To: <199806291610.JAA00380@dingo.cdrom.com>; from Mike Smith on Mon, Jun 29, 1998 at 09:10:36AM -0700 I-love-doing-this: really X-URL: http://sec.42.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 09:10:36AM -0700, Mike Smith wrote: > > I just managed to install Staroffice 4.0sp3. > > > > It requires the file /proc//cmdline to run. > > Amazingly enough, it seems that Linux doesn't actually have /proc/curproc, > which would have made this a lot simpler. linux has /proc/self instead of /proc/curproc - but i can't see how this would make it easier for us ? > > I have just added (an dummy-version of) cmdline in my local copy of > > procfs, but I remember that there was some talk, not to 'bloat' procfs > > with such things. > The real issue is that the Linux and FreeBSD procfs' have different > semantics. Yup, so probably an seperate linux-procfs is probably needed. > We need a separate linux-procfs as part of the linux emulator; it > should mount itself on /compat/linux/procfs. If you're interested in > taking this on (please!), I'm sure we can arrange any support that you > might need. I have not much expirience in fs/kernel hacking, but i will try. I think i will start by taking an renamed conpy of procfs and modify it to make it more linux'ish. This could then be seperately loaded as an lkm. Do you think this is the right way to go ? If so, what would be a good name for it ? lprocfs ? Would it be a showstopper if i did this for 2.2-STABLE instead of -CURRENT ? (my only scrapbox is currently running -stable) CU, Sec -- Komme wieder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 07:32:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29699 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 07:32:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29678 for ; Tue, 30 Jun 1998 07:32:09 -0700 (PDT) (envelope-from Ruslan@Shevchenko.Kiev.UA) Received: from Shevchenko.Kiev.UA (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id RAA04930; Tue, 30 Jun 1998 17:29:36 +0300 (EEST) Message-ID: <3598F64C.2AA4FF3F@Shevchenko.Kiev.UA> Date: Tue, 30 Jun 1998 17:29:34 +0300 From: Ruslan Shevchenko Reply-To: rssh@grad.kiev.ua Organization: GlavAPU X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Andrew Reilly CC: Terry Lambert , Mike Smith , njs3@doc.ic.ac.uk, jkh@time.cdrom.com, fullermd@futuresouth.com, pvh@leftside.wcape.school.za, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration References: <199806271900.MAA15753@antipodes.cdrom.com> <199806282320.QAA14794@usr07.primenet.com> <19980629162434.A20703@reilly.home> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Reilly wrote: > On Sun, Jun 28, 1998 at 11:20:11PM +0000, Terry Lambert wrote: > ? ? ? What do you mean Jordan? A windows style registry? LDAP? > ? > ? If nothing else, it would be truly worthwhile to sit down with the > ? schema information from Cisco, Ascend, Livingston, and others, and > ? just go through FreeBSD to see if it can do everything and keeps all > ? the relevent statistics, etc., that the schema's claim the other > ? boxes can do. It would be a heck of an easy process, and it would > ? yield a list of places in FreeBSD where statistics should be kept > ? and aren't being kept, as well as more than a handful of new features > ? that probably wouldn't be that hard to implement. 8-). > > Sorry for leaping into this late, (and consequently getting the > wrong people on the To: line), but what's the "90's" way of handling > the genuinely script-like things in /etc? I can see how a unified > parameter/value store would be a great advance for most things, > but how do you do: > > /etc/ppp/ppp.linkup.foo, the script that is executed by the !bg > line at the bottom of your ppp.linkup file. > > /etc/{daily,weekly,monthly} > > ? > We must have two-side mapping between scripts and config DB. scripts ?-> configDB > -- > Andrew > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- @= //RSSH mailto:Ruslan@Shevchenko.Kiev.UA CORBA in Ukraine ? ex-USSR: http://www.corbadev.kiev.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 08:04:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04419 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 08:04:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.ny.otec.com (bright.ny.otec.com [209.3.16.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04411 for ; Tue, 30 Jun 1998 08:04:46 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.ny.otec.com (8.8.8/8.8.8) with SMTP id LAA00303; Tue, 30 Jun 1998 11:04:37 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.ny.otec.com: bright owned process doing -bs Date: Tue, 30 Jun 1998 11:04:37 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.ny.otec.com To: Percy Cheng cc: hackers@FreeBSD.ORG Subject: Re: How to attached printer on Netware4.11 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG have you tried samba? if the Novell server supports SMB over TCP/IP you _might_ have a chance. you can use smbclient in your printcap. -Alfred On Tue, 30 Jun 1998, Percy Cheng wrote: > > I'd like to know how to attach the printer that's located > on Novell's intranetware? > > I'll appricate that anyone can give me a hand...=~> > > > Percy Cheng > Internet Online Hong Kong Ltd. > Our Web Site:http://www.iohk.com > My email box:percy@iohk.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 08:29:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA08474 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 08:29:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ibridge.iohk.com (root@ibridge.iohk.com [202.21.128.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08468 for ; Tue, 30 Jun 1998 08:29:10 -0700 (PDT) (envelope-from percy@iohk.com) Received: from igate.iohk.com (percy@igate.iohk.com [202.21.128.81]) by ibridge.iohk.com (8.8.5/8.8.5) with ESMTP id XAA27264; Tue, 30 Jun 1998 23:31:12 +0800 (HKT) Received: from localhost (percy@localhost) by igate.iohk.com (8.8.5/8.8.5) with SMTP id XAA22527; Tue, 30 Jun 1998 23:31:11 +0800 (HKT) Date: Tue, 30 Jun 1998 23:31:10 +0800 (HKT) From: Percy Cheng To: Alfred Perlstein cc: hackers@FreeBSD.ORG Subject: Re: How to attached printer on Netware4.11 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Alfred Perlstein wrote: > have you tried samba? > if the Novell server supports SMB over TCP/IP you _might_ have a chance. > > you can use smbclient in your printcap. > > -Alfred > Thanks for your info, but can you tell me more details on it? Becos I just a beginner in FreeBSD world, thanks... Percy Cheng Internet Online Hong Kong Ltd. Our Web Site:http://www.iohk.com My email box:percy@iohk.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 08:31:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA08840 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 08:31:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08834 for ; Tue, 30 Jun 1998 08:31:32 -0700 (PDT) (envelope-from justin@lilith.apple.com) Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id IAA24672 for ; Tue, 30 Jun 1998 08:22:24 -0700 Received: from scv3.apple.com (scv3.apple.com [17.128.100.121]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id for ; Tue, 30 Jun 1998 08:22:18 -0700 Received: from lilith.apple.com (lilith.apple.com [17.202.41.78]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id IAA31922 for ; Tue, 30 Jun 1998 08:22:16 -0700 Received: (justin@localhost) by lilith.apple.com (8.6.9/A/UX 3.1) id IAA13568; Tue, 30 Jun 1998 08:22:58 -0700 Date: Tue, 30 Jun 1998 08:22:58 -0700 From: "Justin C. Walker" Message-Id: <199806301522.IAA13568@lilith.apple.com> To: freebsd-hackers@FreeBSD.ORG In-Reply-To: Snob Art Genre's message of Tue, 30 Jun 1998 01:55:51 -0400 (EDT) Subject: Re: client-server problem Reply-To: justin@apple.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Snob Art Genre (benedict@echonyc.com) opines: /* * On Mon, 29 Jun 1998, Yee Man Chan wrote: * * > Here is how the program performs under FreeBSD 3.0-CURRENT with different * > n: * > 1-100 Very fast * > 101-207 Very Slow (This range is the strangest I've ever seen) * > 208-1024 Very fast (just like 1-100) * > >1024 strange errors like unknown host or connection timedout * > * > Any clue? * * I don't know about your >1024 problems, but the rest is explainable. It * has to do with the way memory is allocated in the kernel for network * i/o. I don't remember the exact details, but it's all put forth quite * clearly in W. Richard Stevens' _TCP/IP Illustrated Vol. 3_, with graphs * and everything. * * Are you using TCP or UDP? What kind of link are you going over? */ This could, as indicated, be related to kernel buffering of network data. The amount of data in an mbuf is ~100 bytes (100 for the first mbuf in a packet, 108 for subsequent ones, assuming 128-byte mbufs), and BSD stacks typically allow up to two mbufs to hold a single "write"s data before switching to clusters which, depending on the OS subspecies, could be from 1K up. The behavior you are seeing likely reflects the cost of going from one to two mbufs, and then from two mbufs to one or more clusters. Most standard BSD-based systems have wierd behavior in their use of clusters, and how the graphs look above the cluster point in the curve depends on that, and on how many times you've run the tests, and how much of the cluster pool has been carved up into mbufs, etc. etc. Most of the BSD-based systems I've looked at show similar performance curves (Rhapsody, AIX, FreeBSD, ...) Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple CoreOS Networking | of boredom Apple Computer, Inc. | For trying to change the system 2 Infinite Loop | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 09:37:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19061 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 09:37:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun1 (bingsun1.cc.binghamton.edu [128.226.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA19042 for ; Tue, 30 Jun 1998 09:37:19 -0700 (PDT) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun1 (SMI-8.6/8.6.9) with SMTP id MAA07825; Tue, 30 Jun 1998 12:37:01 -0400 Date: Tue, 30 Jun 1998 12:37:00 -0400 (EDT) From: zhihuizhang X-Sender: bf20761@bingsun1 Reply-To: zhihuizhang To: Chris Csanady cc: hackers Subject: Re: Interrupt Handling and inline assembly In-Reply-To: <199806292028.NAA07249@tarsier.ca.sandia.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Jun 1998, Chris Csanady wrote: > > > > >I got two questions: > > > >(1) I read in the MailingList Archive that the interrupt blocking in > >FreeBSD is software-based, we do not communicate with 8259 (which I think > >is slower) What is the advantage of doing this besides being faster? If > >we mask interrupts off (by cli or setting the IMR register in 8259), will > >interrupts be simply discarded (the device has to request interrupt > >again) or postponed by 8259? > > > >(2) I am reading the source code in cpufunc.h: > > > > static __inline void > > setbits(volatile unsigned * addr, u_int bits) > > { > > __asm __volatile("orl %1, %0" : "=m" (*addr): "ir"(bits)); > > } > > > >I have read a text on inline assembly at: > > > > http://www.rt66.com/~brennan/djgpp/djgpp_asm.html > > > >But I still do not understand the meaining of "m" and "ir". > > Take a look at at the gcc info files. These are register constraints, > and are described in detail in gcc / C Extensions / Extended Asm. > > Chris > I have looked into the Info file (because of network problem, I could not access the site yesterday). I still am a little confused with the usage of %n and n (where n are 0...9). Also, the setbits() above seems to be contradictory to what is said in the Info document: When the assembler instruction has a read-write operand, or an operand in which only some of the bits are to be changed, you must logically split its function into two separate operands, one input operand and one write-only output operand. The connection between them is expressed by constraints which say they need to be in the same location when the instruction executes. You can use the same C expression for both operands, or different expressions. For example, here we write the (fictitious) `combine' instruction with `bar' as its read-only source operand and `foo' as its read-write destination: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); Obviously, (* addr) in the setbits() is a read-write operand. Thanks for your help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 09:46:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA20522 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 09:46:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA20517 for ; Tue, 30 Jun 1998 09:46:45 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id MAA21361; Tue, 30 Jun 1998 12:46:38 -0400 (EDT) Date: Tue, 30 Jun 1998 12:46:38 -0400 (EDT) From: Snob Art Genre Reply-To: ben@rosengart.com To: Yee Man Chan cc: ben@rosengart.com, freebsd-hackers@FreeBSD.ORG Subject: Re: client-server problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Yee Man Chan wrote: > Thanks for your response. I will consult Stevens' book. Ok. I thought I had it here at work, but I don't, so I can't quote the relevant portions. However, look at http://www.freebsd.org/cgi/getmsg.cgi?fetch=78339+80732+\ /usr/local/www/db/text/1998/freebsd-hackers/19980111.freebsd-hackers (that's one line) for a previous conversation on the topic between me and Marc Slemko. > I am using TCP. I don't think anything is going over a link. The program > assumes localhost communication, so nothing should be go over a link. Ok. > I run the program in SunOS but unlike FreeBSD, 101<=n<=207 is just as fast > as <100 and >207 <1025. Why? Is it because SunOS and FreeBSD have > different memory allocated in the kernel for network i/o? Which version of SunOS? Versions 4 and earlier are BSD-derived and should show similar behavior. Version 5 is SVR4-based, and has a different network subsystem. > P.S. Did I send the email attached with my server-client code? You should > be able to get it and show me where my bugs are. If there is no files > being attached, tell me and I will put the source code in the email. You did, but I was too tired to debug it. If you want, send it to me in private mail and I'll see if I can discern the problem(s). Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 09:55:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21877 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 09:55:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA21857 for ; Tue, 30 Jun 1998 09:55:19 -0700 (PDT) (envelope-from justin@lilith.apple.com) Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id JAA30358 for ; Tue, 30 Jun 1998 09:49:35 -0700 Received: from scv2.apple.com (scv2.apple.com [17.128.100.140]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id for ; Tue, 30 Jun 1998 09:48:09 -0700 Received: from lilith.apple.com (lilith.apple.com [17.202.41.78]) by scv2.apple.com (8.8.5/8.8.5) with ESMTP id JAA23980 for ; Tue, 30 Jun 1998 09:48:08 -0700 Received: (justin@localhost) by lilith.apple.com (8.6.9/A/UX 3.1) id JAA13643; Tue, 30 Jun 1998 09:48:48 -0700 Date: Tue, 30 Jun 1998 09:48:48 -0700 From: "Justin C. Walker" Message-Id: <199806301648.JAA13643@lilith.apple.com> To: freebsd-hackers@FreeBSD.ORG In-Reply-To: Yee Man Chan's message of Tue, 30 Jun 1998 09:53:10 -0400 (EDT) Subject: Re: client-server problem Reply-To: justin@apple.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /* * > I don't know about your >1024 problems, but the rest is explainable. It * > has to do with the way memory is allocated in the kernel for network * > i/o. I don't remember the exact details, but it's all put forth quite * > clearly in W. Richard Stevens' _TCP/IP Illustrated Vol. 3_, with graphs * > and everything. * > * > Are you using TCP or UDP? What kind of link are you going over? * * Thanks for your response. I will consult Stevens' book. * * I am using TCP. I don't think anything is going over a link. The program * assumes localhost communication, so nothing should be go over a link. * * I run the program in SunOS but unlike FreeBSD, 101<=n<=207 is just as fast * as <100 and >207 <1025. Why? Is it because SunOS and FreeBSD have * different memory allocated in the kernel for network i/o? */ Could be that SunOS uses 256-byte mbufs rather than FreeBSD's 128. Unless this is SunOS 5 (Solaris), and then the buffering scheme is completely different (but with possibly similar profiles; I've never looked at Solaris). I'd think that the crossover points for 256-byte mbufs would be <= 228, 229 - 464, > 1024, but here, the details really matter. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple CoreOS Networking | of boredom Apple Computer, Inc. | For trying to change the system 2 Infinite Loop | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 10:21:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25499 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 10:21:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25481 for ; Tue, 30 Jun 1998 10:21:49 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id NAA18574; Tue, 30 Jun 1998 13:21:38 -0400 (EDT) Date: Tue, 30 Jun 1998 13:21:37 -0400 (EDT) From: "Matthew N. Dodd" To: spork cc: Leo Papandreou , hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, spork wrote: > How hard is it to allow uu.net mail relays, but no direct connections > from dialups, ie: foo.tnt.foo.uu.net is blocked but smtp.uu.net is not? > I'm looking to do something like this here, but haven't revisited > sendmail in some time. There's no reason for a dialup connection to > send me (or anyone else) mail directly. They should be sending via > their ISP's relay instead. Sendmail 8.9 has regex matching rules now IIRC. Should not be difficult at all. Not sure how much good it would do you. /* 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 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 10:25:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26226 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 10:25:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26182 for ; Tue, 30 Jun 1998 10:24:57 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA06707; Tue, 30 Jun 1998 10:24:01 -0700 (PDT) Message-Id: <199806301724.KAA06707@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stefan Zehl cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running In-reply-to: Your message of "Tue, 30 Jun 1998 16:21:15 +0200." <19980630162115.C2179@yoda.pi.musin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 10:24:01 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 29, 1998 at 09:10:36AM -0700, Mike Smith wrote: > > > I just managed to install Staroffice 4.0sp3. > > > > > > It requires the file /proc//cmdline to run. > > > > Amazingly enough, it seems that Linux doesn't actually have /proc/curproc, > > which would have made this a lot simpler. > > linux has /proc/self instead of /proc/curproc - but i can't see how this > would make it easier for us ? Not us; it's just amazing that they actually use getpid() and then sprintf instead of just using the "this is me" entry. > > > I have just added (an dummy-version of) cmdline in my local copy of > > > procfs, but I remember that there was some talk, not to 'bloat' procfs > > > with such things. > > The real issue is that the Linux and FreeBSD procfs' have different > > semantics. > > Yup, so probably an seperate linux-procfs is probably needed. Effectively, yes. > > We need a separate linux-procfs as part of the linux emulator; it > > should mount itself on /compat/linux/procfs. If you're interested in > > taking this on (please!), I'm sure we can arrange any support that you > > might need. > > I have not much expirience in fs/kernel hacking, but i will try. I think > i will start by taking an renamed conpy of procfs and modify it to make > it more linux'ish. This could then be seperately loaded as an lkm. Do > you think this is the right way to go ? If so, what would be a good name > for it ? lprocfs ? It should be part of the emulator itself; when you load the emulator, it should mount, when you unload the emulator, it should unmount. > Would it be a showstopper if i did this for 2.2-STABLE instead of > -CURRENT ? (my only scrapbox is currently running -stable) It would make life *very* difficult for bringing it forwards, yes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 11:29:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08639 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 11:29:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA08630 for ; Tue, 30 Jun 1998 11:29:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA28423; Tue, 30 Jun 1998 11:21:39 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028418; Tue Jun 30 18:21:38 1998 Date: Tue, 30 Jun 1998 11:21:35 -0700 (PDT) From: Julian Elischer To: Mike Smith cc: Stefan Zehl , freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running In-Reply-To: <199806301724.KAA06707@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Mike Smith wrote: > > On Mon, Jun 29, 1998 at 09:10:36AM -0700, Mike Smith wrote: > > It should be part of the emulator itself; when you load the emulator, > it should mount, when you unload the emulator, it should unmount. > That's what the other FS's do, maybe the way you turn on linux mode is to mount the linux proc fs :-) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 11:50:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12239 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 11:50:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shivam.eecs.umich.edu (shivam.eecs.umich.edu [141.213.10.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12220; Tue, 30 Jun 1998 11:50:06 -0700 (PDT) (envelope-from ymc@eecs.umich.edu) Received: from localhost by shivam.eecs.umich.edu (8.9.0/8.9.0) with SMTP id OAA02608; Tue, 30 Jun 1998 14:50:02 -0400 (EDT) Date: Tue, 30 Jun 1998 14:50:02 -0400 (EDT) From: Yee Man Chan Reply-To: Yee Man Chan To: freebsd-hackers@FreeBSD.ORG cc: questions@FreeBSD.ORG Subject: something is wrong with freebsd (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, My supervisor sends me the result he collected using tcpdump when running my client-server program post before. Does anyone have an idea of what's going on? Thanks. Yee Man P.S. If anyone can't get the source code I posted before. Please don't hesitate to request it directly from me. Msg from my supervisor: Here're the tcpdump of the client and server on freebsd only, sun only, or one on each. You can see that freebsd consistently splits up pkts of size 101 to 207 bytes into 2 pkts, but sending pkts of size 208 to maxseg bytes in one pkt. Could you please send a question to freebsd-net and ask people how to fix this? You can include the tcpdump output in your msg. Both server and client on FreeBSD 3.0 and older: ================================================ tcpdump: listening on fxp0 13:40:55.040657 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: S 1583609300:1583609300(0) win 16384 (DF) 13:40:55.041020 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2521: S 24174205:24174205(0) ack 1583609301 win 17520 (DF) 13:40:55.041095 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: . ack 1 win 17520 (DF) 13:40:55.042163 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: P 1:101(100) ack 1 win 17520 (DF) 13:40:55.053216 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2521: . ack 101 win 17520 (DF) 13:40:55.053266 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: P 101:102(1) ack 1 win 17520 (DF) 13:40:55.053684 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2521: P 1:101(100) ack 102 win 17520 (DF) 13:40:55.053762 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2521: FP 101:102(1) ack 102 win 17520 (DF) 13:40:55.053800 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: . ack 103 win 17419 (DF) 13:40:55.054003 crib.eecs.umich.edu.2521 > dumpling.eecs.umich.edu.4898: F 102:102(0) ack 103 win 17520 (DF) 13:40:55.054289 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2521: . ack 103 win 17520 (DF) 13:41:06.017166 crib.eecs.umich.edu.2522 > dumpling.eecs.umich.edu.4898: S 1585794092:1585794092(0) win 16384 (DF) 13:41:06.017483 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2522: S 26243071:26243071(0) ack 1585794093 win 17520 (DF) 13:41:06.017565 crib.eecs.umich.edu.2522 > dumpling.eecs.umich.edu.4898: . ack 1 win 17520 (DF) 13:41:06.018664 crib.eecs.umich.edu.2522 > dumpling.eecs.umich.edu.4898: P 1:101(100) ack 1 win 17520 (DF) 13:41:06.019182 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2522: P 1:101(100) ack 101 win 17520 (DF) 13:41:06.019267 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2522: F 101:101(0) ack 101 win 17520 (DF) 13:41:06.019309 crib.eecs.umich.edu.2522 > dumpling.eecs.umich.edu.4898: . ack 102 win 17420 (DF) 13:41:06.019500 crib.eecs.umich.edu.2522 > dumpling.eecs.umich.edu.4898: F 101:101(0) ack 102 win 17520 (DF) 13:41:06.019788 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2522: . ack 102 win 17520 (DF) 13:51:31.037296 crib.eecs.umich.edu.2524 > dumpling.eecs.umich.edu.4898: S 1706371511:1706371511(0) win 16384 (DF) 13:51:31.037644 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2524: S 144196597:144196597(0) ack 1706371512 win 17520 (DF) 13:51:31.037717 crib.eecs.umich.edu.2524 > dumpling.eecs.umich.edu.4898: . ack 1 win 17520 (DF) 13:51:31.038839 crib.eecs.umich.edu.2524 > dumpling.eecs.umich.edu.4898: P 1:209(208) ack 1 win 17520 (DF) 13:51:31.039527 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2524: P 1:209(208) ack 209 win 17520 (DF) 13:51:31.039610 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2524: F 209:209(0) ack 209 win 17520 (DF) 13:51:31.039651 crib.eecs.umich.edu.2524 > dumpling.eecs.umich.edu.4898: . ack 210 win 17312 (DF) 13:51:31.039851 crib.eecs.umich.edu.2524 > dumpling.eecs.umich.edu.4898: F 209:209(0) ack 210 win 17520 (DF) 13:51:31.040129 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2524: . ack 210 win 17520 (DF) 13:51:46.634752 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: S 1709470727:1709470727(0) win 16384 (DF) 13:51:46.635138 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2525: S 147256421:147256421(0) ack 1709470728 win 17520 (DF) 13:51:46.635222 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: . ack 1 win 17520 (DF) 13:51:46.636405 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: P 1:101(100) ack 1 win 17520 (DF) 13:51:46.697158 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2525: . ack 101 win 17520 (DF) 13:51:46.697216 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: P 101:208(107) ack 1 win 17520 (DF) 13:51:46.697748 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2525: P 1:101(100) ack 208 win 17520 (DF) 13:51:46.697905 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2525: FP 101:208(107) ack 208 win 17520 (DF) 13:51:46.697953 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: . ack 209 win 17413 (DF) 13:51:46.698118 crib.eecs.umich.edu.2525 > dumpling.eecs.umich.edu.4898: F 208:208(0) ack 209 win 17520 (DF) 13:51:46.698396 dumpling.eecs.umich.edu.4898 > crib.eecs.umich.edu.2525: . ack 209 win 17520 (DF) Both server and client on Solaris 5.5.1: ======================================== tcpdump: listening on hme0 13:32:59.182925 irl.eecs.umich.edu.43542 > firedragon.eecs.umich.edu.4898: S 1186150257:1186150257(0) win 8760 (DF) 13:32:59.212311 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43542: S 1992735995:1992735995(0) ack 1186150258 win 8760 (DF) 13:32:59.212356 irl.eecs.umich.edu.43542 > firedragon.eecs.umich.edu.4898: . ack 1 win 8760 (DF) 13:32:59.222787 irl.eecs.umich.edu.43542 > firedragon.eecs.umich.edu.4898: P 1:102(101) ack 1 win 8760 (DF) 13:32:59.224128 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43542: P 1:102(101) ack 102 win 8760 (DF) 13:32:59.224222 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43542: F 102:102(0) ack 102 win 8760 (DF) 13:32:59.224269 irl.eecs.umich.edu.43542 > firedragon.eecs.umich.edu.4898: . ack 103 win 8760 (DF) 13:32:59.224499 irl.eecs.umich.edu.43542 > firedragon.eecs.umich.edu.4898: F 102:102(0) ack 103 win 8760 (DF) 13:32:59.225282 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43542: . ack 103 win 8760 (DF) 13:33:11.181965 irl.eecs.umich.edu.43543 > firedragon.eecs.umich.edu.4898: S 1187701767:1187701767(0) win 8760 (DF) 13:33:11.183091 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43543: S 1994520605:1994520605(0) ack 1187701768 win 8760 (DF) 13:33:11.183132 irl.eecs.umich.edu.43543 > firedragon.eecs.umich.edu.4898: . ack 1 win 8760 (DF) 13:33:11.193944 irl.eecs.umich.edu.43543 > firedragon.eecs.umich.edu.4898: P 1:101(100) ack 1 win 8760 (DF) 13:33:11.195319 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43543: P 1:101(100) ack 101 win 8760 (DF) 13:33:11.195408 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43543: F 101:101(0) ack 101 win 8760 (DF) 13:33:11.195454 irl.eecs.umich.edu.43543 > firedragon.eecs.umich.edu.4898: . ack 102 win 8760 (DF) 13:33:11.195682 irl.eecs.umich.edu.43543 > firedragon.eecs.umich.edu.4898: F 101:101(0) ack 102 win 8760 (DF) 13:33:11.196496 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43543: . ack 102 win 8760 (DF) 13:45:36.186920 irl.eecs.umich.edu.43553 > firedragon.eecs.umich.edu.4898: S 1281750398:1281750398(0) win 8760 (DF) 13:45:36.187935 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43553: S 2088713176:2088713176(0) ack 1281750399 win 8760 (DF) 13:45:36.187972 irl.eecs.umich.edu.43553 > firedragon.eecs.umich.edu.4898: . ack 1 win 8760 (DF) 13:45:36.198515 irl.eecs.umich.edu.43553 > firedragon.eecs.umich.edu.4898: P 1:209(208) ack 1 win 8760 (DF) 13:45:36.200273 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43553: P 1:209(208) ack 209 win 8760 (DF) 13:45:36.200378 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43553: F 209:209(0) ack 209 win 8760 (DF) 13:45:36.200425 irl.eecs.umich.edu.43553 > firedragon.eecs.umich.edu.4898: . ack 210 win 8760 (DF) 13:45:36.200673 irl.eecs.umich.edu.43553 > firedragon.eecs.umich.edu.4898: F 209:209(0) ack 210 win 8760 (DF) 13:45:36.201444 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43553: . ack 210 win 8760 (DF) 13:45:46.527543 irl.eecs.umich.edu.43554 > firedragon.eecs.umich.edu.4898: S 1283065142:1283065142(0) win 8760 (DF) 13:45:46.528524 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43554: S 2090117069:2090117069(0) ack 1283065143 win 8760 (DF) 13:45:46.528564 irl.eecs.umich.edu.43554 > firedragon.eecs.umich.edu.4898: . ack 1 win 8760 (DF) 13:45:46.539660 irl.eecs.umich.edu.43554 > firedragon.eecs.umich.edu.4898: P 1:208(207) ack 1 win 8760 (DF) 13:45:46.541430 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43554: P 1:208(207) ack 208 win 8760 (DF) 13:45:46.541524 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43554: F 208:208(0) ack 208 win 8760 (DF) 13:45:46.541570 irl.eecs.umich.edu.43554 > firedragon.eecs.umich.edu.4898: . ack 209 win 8760 (DF) 13:45:46.541806 irl.eecs.umich.edu.43554 > firedragon.eecs.umich.edu.4898: F 208:208(0) ack 209 win 8760 (DF) 13:45:46.542617 firedragon.eecs.umich.edu.4898 > irl.eecs.umich.edu.43554: . ack 209 win 8760 (DF) Server on Solaris 5.5.1 client on FreeBSD 3.0: ============================================== tcpdump: listening on fxp0 14:19:57.082029 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: S 471332325:471332325(0) win 16384 (DF) 14:19:57.083012 irl.eecs.umich.edu.4898 > dumpling.eecs.umich.edu.1035: S 1514486894:1514486894(0) ack 471332326 win 8760 (DF) 14:19:57.083193 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: . ack 1 win 17520 (DF) 14:19:57.084116 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: P 1:101(100) ack 1 win 17520 (DF) 14:19:57.125574 irl.eecs.umich.edu.4898 > dumpling.eecs.umich.edu.1035: . ack 101 win 8760 (DF) 14:19:57.125802 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: P 101:102(1) ack 1 win 17520 (DF) 14:19:57.134066 irl.eecs.umich.edu.4898 > dumpling.eecs.umich.edu.1035: P 1:102(101) ack 102 win 8760 (DF) 14:19:57.134130 irl.eecs.umich.edu.4898 > dumpling.eecs.umich.edu.1035: F 102:102(0) ack 102 win 8760 (DF) 14:19:57.134301 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: . ack 103 win 17419 (DF) 14:19:57.134398 dumpling.eecs.umich.edu.1035 > irl.eecs.umich.edu.4898: F 102:102(0) ack 103 win 17520 (DF) 14:19:57.135061 irl.eecs.umich.edu.4898 > dumpling.eecs.umich.edu.1035: . ack 103 win 8760 (DF) Client on Solaris 5.5.1 server on FreeBSD 3.0: ============================================== 14:20:34.591346 irl.eecs.umich.edu.43595 > dumpling.eecs.umich.edu.4898: S 1519703332:1519703332(0) win 8760 (DF) 14:20:34.592681 dumpling.eecs.umich.edu.4898 > irl.eecs.umich.edu.43595: S 478620568:478620568(0) ack 1519703333 win 17520 (DF) 14:20:34.595418 irl.eecs.umich.edu.43595 > dumpling.eecs.umich.edu.4898: . ack 1 win 8760 (DF) 14:20:34.602409 irl.eecs.umich.edu.43595 > dumpling.eecs.umich.edu.4898: P 1:102(101) ack 1 win 8760 (DF) 14:20:34.602735 dumpling.eecs.umich.edu.4898 > irl.eecs.umich.edu.43595: P 1:101(100) ack 102 win 17520 (DF) 14:20:34.602827 dumpling.eecs.umich.edu.4898 > irl.eecs.umich.edu.43595: FP 101:102(1) ack 102 win 17520 (DF) 14:20:34.603562 irl.eecs.umich.edu.43595 > dumpling.eecs.umich.edu.4898: . ack 103 win 8760 (DF) 14:20:34.603747 irl.eecs.umich.edu.43595 > dumpling.eecs.umich.edu.4898: F 102:102(0) ack 103 win 8760 (DF) 14:20:34.603925 dumpling.eecs.umich.edu.4898 > irl.eecs.umich.edu.43595: . ack 103 win 17520 (DF) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 12:22:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16700 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 12:22:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gershwin.tera.com (gershwin.tera.com [207.224.230.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16686 for ; Tue, 30 Jun 1998 12:22:42 -0700 (PDT) (envelope-from kline@tao.thought.org) Received: from tao.thought.org (tao.tera.com [207.108.223.55]) by gershwin.tera.com (8.8.8/8.8.8) with ESMTP id MAA13421 for ; Tue, 30 Jun 1998 12:22:08 -0700 (PDT) Received: (from kline@localhost) by tao.thought.org (8.8.8/8.7.3) id MAA10264 for hackers@freebsd.org; Tue, 30 Jun 1998 12:21:56 -0700 (PDT) From: Gary Kline Message-Id: <199806301921.MAA10264@tao.thought.org> Subject: source for xgettext To: hackers@FreeBSD.ORG (Hackers Mailing List) Date: Tue, 30 Jun 1998 12:21:56 -0700 (PDT) Organization: <> thought.org: public access uNix in service... <> 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 Precedence: bulk X-Loop: FreeBSD.ORG Can anybody mail me the src for xgettext.c? I see that this is an X11R6 utility (?). For the time being, I'm using some perl scripts to format the strings as I want them, but it would prob'ly make more sense to hack xgettext itself to do what I want. Thanks for any tips on where this source it; even better if you can sent it along. gary -- Gary D. Kline kline@tao.thought.org Public service uNix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 13:16:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26373 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 13:16:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2 (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA26335 for ; Tue, 30 Jun 1998 13:16:42 -0700 (PDT) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2 (SMI-8.6/8.6.9) with SMTP id QAA11387 for ; Tue, 30 Jun 1998 16:16:40 -0400 Date: Tue, 30 Jun 1998 16:16:39 -0400 (EDT) From: zhihuizhang X-Sender: bf20761@bingsun2 To: hackers Subject: Trap types and AST Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to trace down how the vm_fault() gets called via trap mechanism and I find something do not understand: (1) The value of T_PAGEFLT is 12 not 14. Why trap type definitions in trap.h do not conform to the trap numbers defined in 80386 hardware terminology (one more example is T_NMI which is defined as 19 not 2). (2) The setidt() in file machdep.c set the DPL for page fault as SEL_KPL. This will prevent a normal process from handling page fault, only kernel process can. Why is the case? (this question requires the understanding of gate descriptors). (3) I come across many occurrences of AST, such as SWI_AST_MASK. Clearly, AST does not stand for the PC manufacturer here. I read in Mailing list that AST is an event. Can anyone tell me what does AST stand for and how it is used? Thanks in advance. ------------------------------------------------- Zhihui Zhang Department of Computer Science State University of New York at Binghamton Web Site: http://cs.binghamton.edu/~zzhang ------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 14:08:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04919 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 14:08:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04839 for ; Tue, 30 Jun 1998 14:07:33 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA06322; Tue, 30 Jun 1998 14:07:24 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd006272; Tue Jun 30 14:07:18 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA18650; Tue, 30 Jun 1998 14:07:17 -0700 (MST) From: Terry Lambert Message-Id: <199806302107.OAA18650@usr02.primenet.com> Subject: Re: mmap() with stdin/stdout To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Sm?rgrav) Date: Tue, 30 Jun 1998 21:07:17 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Sm?rgrav" at Jun 30, 98 09:01:48 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 Precedence: bulk X-Loop: FreeBSD.ORG > > > BTW, 'advice' (the noun) is misspelt as 'advise' in the mincore(2) and > > > madvise(2) man pages. The spelling of madvise() may also be construed > > > as a bug unless one argues that 'advise' (the verb) is intended. > > The verb is intended. The "madvise(2)" call _advises_ the kernel > > about your intended use of the memory. > > Yes, but "advise" is also used in the NAME section instead of "advice": I noted that the second instance was indeed a bug. > madvise - give advise about use of memory (1) (2) In the part of my message you removed. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 14:33:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08823 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 14:33:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (fullermd@shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08814 for ; Tue, 30 Jun 1998 14:33:21 -0700 (PDT) (envelope-from fullermd@shell.futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) id QAA15487; Tue, 30 Jun 1998 16:33:13 -0500 (CDT) Message-ID: <19980630163313.49201@futuresouth.com> Date: Tue, 30 Jun 1998 16:33:13 -0500 From: "Matthew D. Fuller" To: "Jordan K. Hubbard" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration References: <19980629162434.A20703@reilly.home> <5256.899162971@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <5256.899162971@time.cdrom.com>; from Jordan K. Hubbard on Mon, Jun 29, 1998 at 04:29:31PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 04:29:31PM -0700, Jordan K. Hubbard woke me up to tell me: > > linux(enabled) = YES > linux(doc) = { This variable controls whether linux emulation support > will be automatically loaded at startup. You can also do it manually > with the /usr/bin/linux command. } > linux(exec-command) = "linux > /dev/null 2>&1" OK, so what's wrong with a simple /etc/rc.conf script that looks something like: # Uncomment next line to run mountd (NFS server) # STARTUP_COMMANDS += mountd # Command and flags for mountd mountd_command = "/sbin/mountd -r" # Uncomment next line to run mailer daemon (default sendmail) # STARTUP_COMMANDS += mailer # Command and flags for mailer mailer_command = "/usr/sbin/sendmail -bd -q30m" Then rc being something of the like of: for i in STARTUP_COMMANDS; do $i_command done This is just scribbling down after 30 seconds thought, don't trust my syntax. But you get the general movement; that leaves you with one file to edit (maybe add a rc.local to that too, to have a seperate file for local changes). It makes it simple for an install script for, say, ssh, to just echo/cat 3 lines onto the end of /etc/rc.local to start it up, eliminating the /usr/local/etc/rc.d hack/kludge also. Sure, it ain't perfect, but it's almost elegant! ;) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 14:42:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10471 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 14:42:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10461; Tue, 30 Jun 1998 14:42:19 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA19054; Tue, 30 Jun 1998 14:42:19 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd018958; Tue Jun 30 14:42:09 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA21104; Tue, 30 Jun 1998 14:42:07 -0700 (MST) From: Terry Lambert Message-Id: <199806302142.OAA21104@usr02.primenet.com> Subject: Re: Unsupport calls To: hackers@FreeBSD.ORG Date: Tue, 30 Jun 1998 21:42:06 +0000 (GMT) Cc: mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG In-Reply-To: <19980630155609.W1880@freebie.lemis.com> from "Greg Lehey" at Jun 30, 98 03:56:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > fdatasync - no support in FreeBSD. Maybe not a big deal. > > Yes, I can't find it either, not even in the Solaris man pages. What > does it do? It is a Linux-ism having to do with syncing out the file data and not the file metadata. The FreeBSD equivalent is fsync(), since you have no choice on the metadata, since FreeBSD obeys the POSIX semantics (which require metadata updates to occur). > > lockf - no support in FreeBSD. Have to implement our own using fcntl(2) > > Correct. Again, an improvement which should also work under Solaris. This depends. You can actually avoid the brain-damaged POSIX semantics for "any close removes all locks" if a system support lockf() as a system call. > About the only serious one I can see is plock. Maybe somebody else on > the list can comment. It is trivial to implement p/v semaphores using __asm__ to generate single instruction spinlocks; since the VM/buffer cache is unified, this will work on shared memory/mmap'ed files without needing a special system call to guaranteee lock coherency. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 14:50:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11592 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 14:50:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11579 for ; Tue, 30 Jun 1998 14:50:38 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA21791; Tue, 30 Jun 1998 14:50:35 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd021724; Tue Jun 30 14:50:25 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA21588; Tue, 30 Jun 1998 14:50:22 -0700 (MST) From: Terry Lambert Message-Id: <199806302150.OAA21588@usr02.primenet.com> Subject: Re: BROKEN_KEYBOARD_RESET To: labrinop@pop.vaniercollege.qc.ca Date: Tue, 30 Jun 1998 21:50:22 +0000 (GMT) Cc: belkovic@albert.osu.cz, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199806301108.HAA23527@pteradactyl> from "labrinop@pop.vaniercollege.qc.ca" at Jun 30, 98 07:07:32 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 Precedence: bulk X-Loop: FreeBSD.ORG > A software reset is generated by asserting a bit in the 8042 > keyboard controller (thats why its called KEYBOARD_RESET), > ie: > MOV AL , 0xFE ; pulse 8042 output port with bit 0 must be low > OUT 0x64 , AL ; output to 8042 command register > > this is how it has been done since the PC/AT (PC & PC/XT doesn't have > this) and is still done. The above sequence has the same effect as > the RESET button (internally their wired together). But some > motherboard/chipsets are broken and don't work correctly. No. There is a BIOS vector on the other end of this. Some BIOS reset implementations are incapable of operating in protected mode, because of one assumption or another. If the system were returned to real mode, or the reset was triggered in a VM86, and allowed to run to completion instead of trapping whatever the BIOS poked (ie: I/O address space, outb, CMOS, whatever), then you could reset. > Another way to reset the system while still in protected mode is to > generate a triple fault: clear IDT entries 8 (Double Fault) and 10 > (Invalid TSS) and then load TR with an illegal selector. > > > invalid tss > double fault > triple fault > cpu shutdown > reset This presumes that the CPU reset is wired correctly. The "correct" wiring is undefined in the ISA/PC architecture documents that were widely circulated when ISA was renamed "ISA"; in my experience, a full 30% of motherboards fail to wire the reset such that a triple fault results in the machine resetting. See the Van Gilluwe book for details. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 15:00:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12918 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 15:00:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12913 for ; Tue, 30 Jun 1998 15:00:19 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA08168; Tue, 30 Jun 1998 14:46:18 -0700 (PDT) Message-Id: <199806302146.OAA08168@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Matthew D. Fuller" cc: "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Tue, 30 Jun 1998 16:33:13 CDT." <19980630163313.49201@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 14:46:18 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 29, 1998 at 04:29:31PM -0700, Jordan K. Hubbard woke me up to tell me: > > > > linux(enabled) = YES > > linux(doc) = { This variable controls whether linux emulation support > > will be automatically loaded at startup. You can also do it manually > > with the /usr/bin/linux command. } > > linux(exec-command) = "linux > /dev/null 2>&1" > > OK, so what's wrong with a simple /etc/rc.conf script that looks > something like: It doesn't scale. > This is just scribbling down after 30 seconds thought, don't trust my > syntax. But you get the general movement; that leaves you with one file > to edit (maybe add a rc.local to that too, to have a seperate file for > local changes). It makes it simple for an install script for, say, ssh, > to just echo/cat 3 lines onto the end of /etc/rc.local to start it up, > eliminating the /usr/local/etc/rc.d hack/kludge also. Yes. And you could call it /etc/rc too. Wrong direction, sorry. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 15:10:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14584 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 15:10:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14578 for ; Tue, 30 Jun 1998 15:10:56 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA00381; Tue, 30 Jun 1998 15:10:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd000345; Tue Jun 30 15:10:51 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA22715; Tue, 30 Jun 1998 15:10:50 -0700 (MST) From: Terry Lambert Message-Id: <199806302210.PAA22715@usr02.primenet.com> Subject: Re: Trap types and AST To: bf20761@binghamton.edu (zhihuizhang) Date: Tue, 30 Jun 1998 22:10:50 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "zhihuizhang" at Jun 30, 98 04:16:39 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am trying to trace down how the vm_fault() gets called via trap > mechanism and I find something do not understand: > > (1) The value of T_PAGEFLT is 12 not 14. Why trap type definitions in > trap.h do not conform to the trap numbers defined in 80386 hardware > terminology (one more example is T_NMI which is defined as 19 not 2). I believe this is because of the Pentium bug workaround. > (2) The setidt() in file machdep.c set the DPL for page fault as SEL_KPL. > This will prevent a normal process from handling page fault, only kernel > process can. Why is the case? (this question requires the understanding > of gate descriptors). A process can handle page faults for pages not assigned to it by the kernel: it does this by establishing a handler for SIGSEGV. For pages that are part of the process virtual address space, it does not make sense for the fault to be taken by the process, since the process can not be sure that the pages needed to handle the fault will not, themselves, need to be paged in. Is your intent to implement MACH "external pagers"? I would discourage this, since it is very heavy-weight to have to swap in another process in order to swap in/out your pages. This is because the FreeBSD kernel does not support kernel preemption (ie: it is not fully thread reentrant -- equivalent to SMP reentrant), a facility for dealing with hard realtime. You would need your pager swapped in *now*, not later, when the quantum clock fired one or more times. In general, this would be better accomplished with a "kernel process", such as is used by the existing VM system. It exists to provide a kernel stack and an accounting context, for the most part. If the intent is to support a VMM (Virtual Machine Manager), you would be better off putting that code in the kernel, as part of the VM86 code. How to do this is well documented in: Protected Mode Software Architecture Tom Shanley MindShare, Inc. PC System Architecture Series ISBN: 0-201-55447-X Which basically documents everything you need to consider to implement a VMM capable of *efficiently* running DOS programs or using BIOS based drivers under a protected mode OS. > (3) I come across many occurrences of AST, such as SWI_AST_MASK. Clearly, > AST does not stand for the PC manufacturer here. I read in Mailing list > that AST is an event. Can anyone tell me what does AST stand for and how > it is used? Asynchronous System Trap. The terminology comes from RT11/RSX/VMS/etc. family OS's from DEC. It means an interrupt callback to kernel code; in VMS, it means a supervisor callback to user space code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 15:49:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22094 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 15:49:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22060; Tue, 30 Jun 1998 15:48:41 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id PAA29470; Tue, 30 Jun 1998 15:34:45 -0700 (PDT) Message-Id: <199806302234.PAA29470@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert Cc: hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG Subject: Re: Unsupport calls Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 30 Jun 1998 15:34:44 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998 21:42:06 +0000 (GMT) Terry Lambert wrote: > > > fdatasync - no support in FreeBSD. Maybe not a big deal. > > > > Yes, I can't find it either, not even in the Solaris man pages. What > > does it do? > > It is a Linux-ism having to do with syncing out the file data and > not the file metadata. No it is NOT an Linux-ism. From the NetBSD fdatasync(2) manual page: STANDARDS The fdatasync() function conforms to IEEE Std1003.1b-1993 (``POSIX''). This is in NetBSD-current, and will be in the NetBSD 1.4 release. > The FreeBSD equivalent is fsync(), since you have no choice on the > metadata, since FreeBSD obeys the POSIX semantics (which require > metadata updates to occur). You're a bit out of date. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 650 428 6939 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:02:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA24706 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:02:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA24690 for ; Tue, 30 Jun 1998 16:02:32 -0700 (PDT) (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.8/8.8.8) with ESMTP id QAA10825 for ; Tue, 30 Jun 1998 16:02:07 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Prev-Resent: Tue, 30 Jun 1998 16:02:07 -0700 Prev-Resent: "hackers@freebsd.org " Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id MAA10161 for ; Tue, 30 Jun 1998 12:37:48 -0700 (PDT) (envelope-from saska@acc.umu.se) Received: from montezuma.acc.umu.se (root@montezuma.acc.umu.se [130.239.18.147]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA19344 for ; Tue, 30 Jun 1998 12:38:01 -0700 (PDT) (envelope-from saska@acc.umu.se) Received: from hirohito.acc.umu.se (saska@hirohito.acc.umu.se [130.239.18.140]) by montezuma.acc.umu.se (8.9.0/8.9.0) with SMTP id VAA01406 for ; Tue, 30 Jun 1998 21:37:55 +0200 (MET DST) Date: Tue, 30 Jun 1998 21:37:55 +0200 (CEST) From: Markus Holmberg To: jkh@FreeBSD.ORG Subject: ipfw startup script "bug" in 2.2.6-STABLE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Heya.. I just wanted to notice that the below config in /etc/rc.conf will result in that the ipfw-rules are not loaded at startup since ipfw won't understand.. I tried manually "ipfw -q /etc/firewall.conf" and it results in that ipfw shows usage instead and doesn't load rules. firewall_type="/etc/firewall.conf" # Firewall type (see /etc/rc.firewall) firewall_quiet="YES" # Set to YES to suppress rule display The man page for ipfw doesn't say "ipfw -q filename" is a valid way of using it.. This could potentially result in that someone who wouldn't check their startupmsg could get either locked out (if denydefault) or an all open machine (if allowdefault).... This problem won't occur if firewall_quiet is set to "NO" (obviously since -q isn't involved in that case) OK, just wanted to note it, i'm no expert so i apologize for any ignorance or errors in this report.. Best Regards, Markus Holmberg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:04:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA25272 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:04:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA25207; Tue, 30 Jun 1998 16:04:27 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA18235; Tue, 30 Jun 1998 16:04:26 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd018125; Tue Jun 30 16:04:14 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA25319; Tue, 30 Jun 1998 16:04:07 -0700 (MST) From: Terry Lambert Message-Id: <199806302304.QAA25319@usr02.primenet.com> Subject: Re: Unsupport calls To: thorpej@nas.nasa.gov Date: Tue, 30 Jun 1998 23:04:07 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG In-Reply-To: <199806302234.PAA29470@lestat.nas.nasa.gov> from "Jason Thorpe" at Jun 30, 98 03:34:44 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The FreeBSD equivalent is fsync(), since you have no choice on the > > metadata, since FreeBSD obeys the POSIX semantics (which require > > metadata updates to occur). > > You're a bit out of date. Not really. The distinction drawn between user data and metadata is useless in the face of a technology like soft updates. This is just another case of POSIX adding insult to injury, to no real benefit for anyone. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:05:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA25525 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:05:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from digi.digiware.nl (gtw.digiware.nl [194.151.72.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA25440 for ; Tue, 30 Jun 1998 16:05:04 -0700 (PDT) (envelope-from wjw@digi.digiware.nl) Received: by digi.digiware.nl (8.8.7/1.63) id XAA07485; Tue, 30 Jun 1998 23:03:37 GMT From: wjw@digi.digiware.nl (Willem Jan Withagen) Message-Id: <199806302303.XAA07485@digi.digiware.nl> Subject: Variant Link implementation, continued In-Reply-To: <199806080712.AAA09745@antipodes.cdrom.com> from Mike Smith at "Jun 8, 98 00:12:57 am" To: mike@smith.net.au (Mike Smith) Date: Wed, 1 Jul 1998 01:03:37 +0200 (CEST) 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 Precedence: bulk X-Loop: FreeBSD.ORG => > >> If we really wanted to get variant symlinks, I would suggest copying => > >> the already-fairly-well-known syntax of AFS, `@name_of_parameter'. As => > >> the metasyntactic variable suggests, these should be (a fairly small => > >> number of) parameters which hold system-wide. (Indeed, given the => > >> existence of the sysctlbyname interface in the kernel, one could => > >> simply kick them off in that direction.) => > > => > >Ok. I did actually look at how this could be implemented last time it => > >came up, and I think it would be *reasonably* straightforward. I have actual working code for this. At the moment every variantlink gets replaced by '2.2.6', since that is my current OS version. And /usr/local is thus pointing to /usr/local.${OSVERSION} lrwxrwxrwx 1 root wheel 20 Jul 1 00:50 local@ -> ./.local.${OSVERSION} lrwxrwxrwx 1 root wheel 12 Mar 1 23:08 .local.2.2.6@ -> /home2/local lrwxrwxrwx 1 root wheel 12 Mar 1 23:08 .local.@ -> /home2/local Which is running for quite a while (1-2 weeks). The last link is to be used in case I run a kernel with actual variant translation but OSVERSION is not defined. So I'm up for the next challenge: => Start small; once this is working for you, the next step is the => 'defaults' space, which should be sysctl-accessible. Then you can => start worrying about how to become more process-specific. * sysctl-accessable variant parameters. Currently all I know about this comes from 'man 3 sysctl' and browsing through the kernel-source. But I've never finished my reading on MIB's so any help an/or suggestion is welcom. My 2 major questions: - How can I efficiently obtain the value of a sysctl value? And should they look like 'variant.name', or would/should a variant link be able to look like: kern.osrelease: 2.2.6-STABLE - It seems that names are allocated from within the kernel upon startup, nothing dynamic. Is there any work in progress to make this more flexible? I could start by first creating a standard set of names. * An alternative would be: How do I obtain the environment of the process using the link? (assuming it has nog messed with its *env-pointer) Thanx, --WjW To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:12:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27427 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:12:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (fullermd@shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27395 for ; Tue, 30 Jun 1998 16:12:14 -0700 (PDT) (envelope-from fullermd@shell.futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) id SAA20050; Tue, 30 Jun 1998 18:11:53 -0500 (CDT) Message-ID: <19980630181153.08867@futuresouth.com> Date: Tue, 30 Jun 1998 18:11:53 -0500 From: "Matthew D. Fuller" To: Mike Smith Cc: "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration References: <19980630163313.49201@futuresouth.com> <199806302146.OAA08168@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199806302146.OAA08168@dingo.cdrom.com>; from Mike Smith on Tue, Jun 30, 1998 at 02:46:18PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 30, 1998 at 02:46:18PM -0700, Mike Smith woke me up to tell me: > > On Mon, Jun 29, 1998 at 04:29:31PM -0700, Jordan K. Hubbard woke me up to tell me: > > > > > > linux(enabled) = YES > > > linux(doc) = { This variable controls whether linux emulation support > > > will be automatically loaded at startup. You can also do it manually > > > with the /usr/bin/linux command. } > > > linux(exec-command) = "linux > /dev/null 2>&1" > > > > OK, so what's wrong with a simple /etc/rc.conf script that looks > > something like: > > It doesn't scale. I don't see how. Unless there's a limit (that we're likely to reach) on how long a shell variable can be. I'm sure there is, but I'm not sure if it's low enough that we're likely to hit it on a bootup sequence. I mean, it's the same way Jordan was going with a 'registry', except thrown into a script. I can see it getting a little unwieldy at extreme sizes, but then again, there's only so much you're really going to be DOING on bootup. Have an /etc/configfile.conf which which points something like: ppp_linkup = '/etc/ppp/ppp.linkup' httpd_conf = '/usr/local/www/conf/httpd.conf' system_cshrc = '/etc/csh.cshrc' ... which will A) allow you to see where all the files are and B) allow a monolithic 'sysconfig' script/program/cutesy thing to know right off the bat where all the config files are. Heck, you can even C) move all them to /etc/config/ if you wanted to. Perhaps not an ideal solution, but fairly easy to thrown together and better than it is now. > Yes. And you could call it /etc/rc too. > > Wrong direction, sorry. Well, the way I describe redoing (bootup) procedure above would drop quietly into the present setup; just replace /etc/rc with that nice little 4-line script, and rc.conf with the above. It's a bit more self-explanatory than the present, anyway. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:16:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27931 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:16:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27842; Tue, 30 Jun 1998 16:15:35 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id QAA29682; Tue, 30 Jun 1998 16:01:43 -0700 (PDT) Message-Id: <199806302301.QAA29682@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert Cc: hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG Subject: Re: Unsupport calls Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 30 Jun 1998 16:01:42 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998 23:04:07 +0000 (GMT) Terry Lambert wrote: > Not really. The distinction drawn between user data and metadata is > useless in the face of a technology like soft updates. ...and not only does POSIX not define softupdates, but who says you're using a UFS-like file system, anyhow? > This is just another case of POSIX adding insult to injury, to no > real benefit for anyone. ...and this insults you how? I think you're taking it way too seriously :-) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 650 428 6939 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:22:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28798 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:22:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28736 for ; Tue, 30 Jun 1998 16:21:30 -0700 (PDT) (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.8/8.8.8) with ESMTP id QAA10974; Tue, 30 Jun 1998 16:20:55 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Matthew D. Fuller" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Tue, 30 Jun 1998 16:33:13 CDT." <19980630163313.49201@futuresouth.com> Date: Tue, 30 Jun 1998 16:20:55 -0700 Message-ID: <10970.899248855@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK, so what's wrong with a simple /etc/rc.conf script that looks > something like: Several reasons. 1. If you want to write a nifty editor for it, you have to now have _rules_ for clumping all the mountd_foo variables together in such a way that all "mountd attributes" are editable in a common block. 2. This does not deal *explicitly* with ordering issues unless it will be very well documented that the order in which startup commands are specified must be maintained (and then, of course, the aformentioned editor has another thing to remember in writing things back out). This would be true in your example since portmap, for one, needs to be run before mountd. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:30:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00154 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:30:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00143 for ; Tue, 30 Jun 1998 16:30:18 -0700 (PDT) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id QAA26730 for ; Tue, 30 Jun 1998 16:29:58 -0700 (PDT) Date: Tue, 30 Jun 1998 16:29:57 -0700 (PDT) From: Ian Kallen To: freebsd-hackers@FreeBSD.ORG Subject: ccd & disklabel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After ccd'ing together two of my 4 st19191n's (9 gig barracuda's), sd1 & sd2 as ccd0, I went to slice and label the other two, sd3 & sd 4, and, being lazy as I am, did it in sysinstall. Nothing seemed unusual there but when I could neither newfs those two ccd'd together, as ccd1, nor individually I looked at the disklabels. The latter two labels were totally different from the first two so, being lazy as I am, I dumped the disklabel from sd1 (which is functionally identical to sd2) and restored & edited that onto sd3 & sd4. I'm currently newfs'ing ccd1 which is built of sd3 & sd4 but this difficulty with the disklabels has me concerned. I'm using 2.2.6 on this installation though it's about to get wiped in favor of current & CAM... is it voodoo? -- Fascinating is a word I use for the unexpected. -- Spock, "The Squire of Gothos", stardate 2124.5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:31:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00292 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:31:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iglou.com (sendmail@iglou2.iglou.com [192.107.41.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00277 for ; Tue, 30 Jun 1998 16:31:43 -0700 (PDT) (envelope-from dbj@iglou.com) Received: from lou-ts3-15.iglou.com ([204.255.239.130] helo=localhost) by iglou.com with smtp (8.7.3/8.6.12) id 0yr9s9-00030x-00; Tue, 30 Jun 1998 19:31:38 -0400 Date: Tue, 30 Jun 1998 19:32:00 -0400 (EDT) From: "David E. Brooks Jr" X-Sender: dbj@localhost To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: mlock()/mclear (was Re: Unsupport calls) In-Reply-To: <199806302142.OAA21104@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Terry Lambert wrote: > It is trivial to implement p/v semaphores using __asm__ to generate > single instruction spinlocks; since the VM/buffer cache is unified, > this will work on shared memory/mmap'ed files without needing a > special system call to guaranteee lock coherency. > > > Terry Lambert > terry@lambert.org Funny you should mention this. I was poking around the man page to mmap() the other day looking for any hints on a "standard" way to perform inter-process synchronization when sharing memory. This led me to read the 'newvm' paper, specifically about mlock()/mclear(). Well, to make a short story even shorter, I ended up having a brief e-mail exchange with David Greenman where he said in my mail batch this morning "...a bright beginner could tackle it." So, I figured I'd try and find out how bright I really am . I haven't gotten very far (I'm re-reading relevant portions of _The Design and Implementation of 4.4 BSD Operating System_ and lots of stuff in section 9 right now), but I do have one question right off the bat. Both mmap(2) and the newvm paper make mention of the MAP_HASSEMAPHORE flag; Why is (or was) this necessary? All that comes to mind is multi-processor systems and keeping any copies of that page of memory synchronized. Thanks! -- Dave -- David E. Brooks Jr dbj@iglou.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 16:44:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02799 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 16:44:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02764 for ; Tue, 30 Jun 1998 16:44:21 -0700 (PDT) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id QAA00868; Tue, 30 Jun 1998 16:44:17 -0700 (PDT) Date: Tue, 30 Jun 1998 16:44:17 -0700 (PDT) Message-Id: <199806302344.QAA00868@bangkok.office.cdsnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: Marino Ladavac Cc: FreeBSD Hackers Subject: Re: Unsupport calls In-Reply-To: References: <19980630155609.W1880@freebie.lemis.com> X-Mailer: VM 6.31 under Emacs 20.2.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marino Ladavac writes: > > > sigwait is in libc_r, being a part of POSIX pthread specification. > > /Marino sigwait() is indeed in libc_r, but it is broken. See misc/7039 in gnats. -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts@internetcds.com --------------------------------+------------------------------------ Any sufficiently perverted technology is indistinguishable from Perl. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 17:08:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06492 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 17:08:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sophia.pacific.net.sg (sophia.pacific.net.sg [203.120.90.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06454; Tue, 30 Jun 1998 17:07:54 -0700 (PDT) (envelope-from accel@pacific.net.sg) Received: from pop1.pacific.net.sg (pop1.pacific.net.sg [203.120.90.85]) by sophia.pacific.net.sg with ESMTP id IAA24056; Wed, 1 Jul 1998 08:07:44 +0800 (SGT) Received: from [210.24.241.1] (dyn241ppp1.pacific.net.sg [210.24.241.1]) by pop1.pacific.net.sg with ESMTP id IAA27428; Wed, 1 Jul 1998 08:07:28 +0800 (SGT) Message-Id: In-Reply-To: <359ae341.2257050@afnetinc.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 1 Jul 1998 07:48:16 +0800 To: efinley@castlenet.com, Alfred Perlstein From: Richard Goh Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card Cc: "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Thanks for the info. So far so bad, now I have a $2.5k machine sitting pretty on its own and cant even change the network card which is on the motherboard. Looks like the only option left is to port the linux driver. Anyone with some experience on this ? Or is there a guide? TIA Richard At 2:56 AM +0800 6/30/98, Elliot Finley wrote: >On Sat, 27 Jun 1998 14:37:03 +0800, you wrote: > >I was unable to get my 8129 to work... Had to go back to the 8029.. > >>HI, >>Has anyone got the driver to work yet? >>Just bought an Advantech panel pc thinking that "NE2000 compatible" was >>all i needed. >>Needless to say, countless rebuilds later ..... >> >>Thanks for any tips. >>Rgds >>Richard >> >> >> >>On Tue, 17 Mar 1998, Eivind Eklund wrote: >> >>> On Tue, Mar 17, 1998 at 08:04:15AM -0500, Timothy M. Hughes wrote: >>> > Has anyone got one of these things to work yet?? I mailed >>> > questions@freebsd.org and got a response that it was "probably" a >>> > proprietary driver. If you have a driver or have gotten it to work, >>> > please email me directly (I dont subscibe). >>> >>> RealTek is fairly good at supporting free OSes (even sometimes writing >>> drivers themselves). >>> >>> I don't think you should have a problem getting info from them, but it >>> is probably correct that it is a properitary chip (probably with an >>> almost complete clone of the interface of a popular chipset, so making >>> drivers work should be easy). >> >>Unlike the 8019/8029 (which are NE2000 clones), the 8129/8139 appear to >>be their own design and not compatible with anything else. However, >>datasheets that look complete enough to write a driver are available on >>their website (www.realtek.com.tw), and there also exists a Linux driver >>to crib from (see http://cesdis.gsfc.nasa.gov/linux/misc/100mbs.html ) >> >>[Sorry if you see two copies of this - I think I killed the one with an >>incorrect URL, but it may have escaped] >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-questions" in the body of the message >> >> >> >> >>www@freebsd.org >> >> >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-questions" in the body of the message >> > >-- > Later > Science (efinley@castlenet.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 17:12:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA07601 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 17:12:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA07461; Tue, 30 Jun 1998 17:12:07 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id JAA09589; Wed, 1 Jul 1998 09:41:55 +0930 (CST) Message-ID: <19980701094155.B1880@freebie.lemis.com> Date: Wed, 1 Jul 1998 09:41:55 +0930 From: Greg Lehey To: Marino Ladavac Cc: mkn , freebsd-questions@FreeBSD.ORG, FreeBSD Hackers Subject: Re: Unsupport calls References: <19980630192910.H1880@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Marino Ladavac on Tue, Jun 30, 1998 at 01:51:39PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 30 June 1998 at 13:51:39 +0200, Marino Ladavac wrote: > > On 30-Jun-98 Greg Lehey wrote: >> On Tuesday, 30 June 1998 at 9:54:10 +0200, Marino Ladavac wrote: >>> >>> On 30-Jun-98 Greg Lehey wrote: >>>> >>>>> sigwait - no support in FreeBSD. >>>>> sigset - no support in FreeBSD >>>>> sighold - no support in FreeBSD >>>>> sigrelse - no support in FreeBSD >>>> >>>> These are the System V signal functions, arguably the worst choice of >>>> the currently available signal implementations. FreeBSD has the BSD >>>> functions instead, as well as the POSIX.1 signals which were derived >>>> from them. See more about this in my book "Porting UNIX software". I >>>> recommend porting to the POSIX.1 signals, which are also supported by >>>> Solaris. >>>> >>> sigwait is in libc_r, being a part of POSIX pthread specification. >> >> That's a different sigwait. This one is, by association, one of the >> calls of the System V signals implementation. > > I beg to differ (and so do my SunOS 5 manpages). The SysV simplified signal > management APIs are: > > NAME > sigwait - wait until a signal is posted > > SYNOPSIS > #include > > int sigwait(sigset_t *set); > > POSIX Oops, yes, missed that one. I wonder why this program is mixing two different signal implementations? That way madness lies. BTW, that reminds me that, though signal() was found, it's not the same signal() that is used in the FreeBSD implementation. But since signal handling will need rewriting, mkn should drop signal() altogether in favour of the POSIX.1 routines. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 17:17:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08620 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 17:17:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08559 for ; Tue, 30 Jun 1998 17:17:09 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA08758; Tue, 30 Jun 1998 17:02:30 -0700 (PDT) Message-Id: <199807010002.RAA08758@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Matthew D. Fuller" cc: Mike Smith , "Jordan K. Hubbard" , freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration In-reply-to: Your message of "Tue, 30 Jun 1998 18:11:53 CDT." <19980630181153.08867@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 17:02:30 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, Jun 30, 1998 at 02:46:18PM -0700, Mike Smith woke me up to tell me: > > > On Mon, Jun 29, 1998 at 04:29:31PM -0700, Jordan K. Hubbard woke me up to tell me: > > > > > > > > linux(enabled) = YES > > > > linux(doc) = { This variable controls whether linux emulation support > > > > will be automatically loaded at startup. You can also do it manually > > > > with the /usr/bin/linux command. } > > > > linux(exec-command) = "linux > /dev/null 2>&1" > > > > > > OK, so what's wrong with a simple /etc/rc.conf script that looks > > > something like: > > > > It doesn't scale. > I don't see how. You can't use the same information as a template for more than one system. > > Yes. And you could call it /etc/rc too. > > > > Wrong direction, sorry. > > Well, the way I describe redoing (bootup) procedure above would drop > quietly into the present setup; just replace /etc/rc with that nice > little 4-line script, and rc.conf with the above. It's a bit more > self-explanatory than the present, anyway. Like I said, if you want one big script, call it rc. If you don't fully appreciate the separation between parametric and procedural information, and the concept of procedure-as-parameter (ie. metaprocedures), it's a bit hard to explain. The basic goal is to separate the "do this" configuration from the "how to do this" instructions. Further down the track, you abstract again and all the system is left with is "how to work out what to do"; everything else is parametric from this point of view. You're taking the opposite approach and slamming everything back together. You can't effectively layer a single object when your layering granularity is the object. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 17:46:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14394 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 17:46:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14298 for ; Tue, 30 Jun 1998 17:46:11 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (brian@localhost [127.0.0.1]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id AAA12373; Wed, 1 Jul 1998 00:51:22 +0100 (BST) (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199806302351.AAA12373@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Didier Derny cc: hackers@FreeBSD.ORG Subject: Re: ppp with the latest SNAPSHOT (may) In-reply-to: Your message of "Tue, 30 Jun 1998 11:17:41 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 00:51:21 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > user ppp worked fine for years but after having changed my mother board/ > upgraded to the latest snapshot it is not working anymore > > as I did both operation at the same time I dont know if the problem > comes from the mother board or user ppp. > > the mother board is an Asus P2B (chipset BX) > > do you have any clue ? No. You'll need to explain what ``doesn't work'' means :-( My car doesn't work. Do you have any idea what's wrong with it ? > thanks for your help > > -- > Didier Derny > didier@omnix.net -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 18:15:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20200 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 18:15:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19898; Tue, 30 Jun 1998 18:14:07 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA08988; Tue, 30 Jun 1998 17:58:36 -0700 (PDT) Message-Id: <199807010058.RAA08988@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Goh cc: efinley@castlenet.com, Alfred Perlstein , "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card In-reply-to: Your message of "Wed, 01 Jul 1998 07:48:16 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 17:58:36 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > Thanks for the info. > So far so bad, now I have a $2.5k machine sitting pretty on its own and > cant even change the network card which is on the motherboard. Sounds like you wasted your money. Try spending another $50 on an Intel EtherExpress Pro 100+, which is a controller worth having in the first place. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 18:19:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20899 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 18:19:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from redfish.go2net.com (redfish.go2net.com [207.178.55.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA20791; Tue, 30 Jun 1998 18:18:20 -0700 (PDT) (envelope-from marcs@go2net.com) Received: from marcs by redfish.go2net.com with smtp (Exim 1.82 #2) id 0yrBVu-0002PH-00; Tue, 30 Jun 1998 18:16:46 -0700 Date: Tue, 30 Jun 1998 18:16:46 -0700 (PDT) From: Marc Slemko X-Sender: marcs@redfish To: Yee Man Chan cc: freebsd-hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: something is wrong with freebsd (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Yee Man Chan wrote: > Hi, > > My supervisor sends me the result he collected using tcpdump when > running my client-server program post before. Does anyone have an idea of > what's going on? > > > Thanks. > Yee Man > > P.S. If anyone can't get the source code I posted before. Please don't > hesitate to request it directly from me. > > Msg from my supervisor: > > Here're the tcpdump of the client and server on freebsd only, sun only, > or one on each. You can see that freebsd consistently splits up pkts > of size 101 to 207 bytes into 2 pkts, but sending pkts of size 208 to > maxseg bytes in one pkt. Known problem; wasn't introduced by FreeBSD code, but hasn't been fixed either. Should be in the archives somewhere. Search for a "why 100 byte TCP segments" thread. There is a half page on it in Stevens vol 3(?) or something, not at home now can't check. It has to do with how it shoves things into mbufs and mbuf clusters. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 18:57:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27393 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 18:57:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iglou.com (sendmail@iglou2.iglou.com [192.107.41.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27377 for ; Tue, 30 Jun 1998 18:57:21 -0700 (PDT) (envelope-from dbj@iglou.com) Received: from lou-ts6-29.iglou.com ([204.255.238.96] helo=localhost) by iglou.com with smtp (8.7.3/8.6.12) id 0yrC91-0004HC-00; Tue, 30 Jun 1998 21:57:12 -0400 Date: Tue, 30 Jun 1998 21:58:14 -0400 (EDT) From: "David E. Brooks Jr" X-Sender: dbj@localhost To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: mlock()/mclear (was Re: Unsupport calls) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, David E. Brooks Jr wrote: [ This is in regards to implementing mlock()/mclear() ] > I haven't gotten very far (I'm re-reading relevant portions of _The > Design and Implementation of 4.4 BSD Operating System_ and lots of > stuff in section 9 right now), but I do have one question right off > the bat. Both mmap(2) and the newvm paper make mention of the > MAP_HASSEMAPHORE flag; Why is (or was) this necessary? All that comes > to mind is multi-processor systems and keeping any copies of that > page of memory synchronized. Hmm, I think I can answer my own question: Mmap() needs to know since any reference counts (for those waiting to lock) to a semaphore structure have to be decremented properly when/if a page containing a semaphore is munmap()-ed from memory (either explicitly or through process termination). -- Dave (Who is now only beginning to realize why nobody has whipped this out before...) -- David E. Brooks Jr dbj@iglou.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 19:18:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29655 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 19:18:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29497; Tue, 30 Jun 1998 19:16:45 -0700 (PDT) (envelope-from doconnor@cain.gsoft.com.au) Received: from cain (localhost [127.0.0.1]) by cain.gsoft.com.au (8.8.8/8.6.9) with ESMTP id LAA12509; Wed, 1 Jul 1998 11:44:53 +0930 (CST) Message-Id: <199807010214.LAA12509@cain.gsoft.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Goh cc: efinley@castlenet.com, Alfred Perlstein , "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card In-reply-to: Your message of "Wed, 01 Jul 1998 07:48:16 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 11:44:52 +0930 From: "Daniel O'Connor" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So far so bad, now I have a $2.5k machine sitting pretty on its own and > cant even change the network card which is on the motherboard. > Looks like the only option left is to port the linux driver. > Anyone with some experience on this ? > Or is there a guide? Well, you could add a network card to it... A cheapo PCI card costs around AU$60, so you may as well buy one until you get the driver for the onboard one working... This of course assumes you have a spare PCI slot.. --------------------------------------------------------------------- |Daniel O'Connor software and network engineer for Genesis Software | |http://www.gsoft.com.au | |The nice thing about standards is that there are so many of them to| |choose from. -- Andrew Tanenbaum | --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 19:19:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29841 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 19:19:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29735 for ; Tue, 30 Jun 1998 19:19:05 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA18769; Tue, 30 Jun 1998 19:14:15 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd018763; Wed Jul 1 02:14:13 1998 Date: Tue, 30 Jun 1998 19:14:08 -0700 (PDT) From: Julian Elischer To: Evren Yurtesen cc: hackers@FreeBSD.ORG Subject: Re: hello (proxy redirect) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG you need to use natd.. what natd does is to rewrite the packet.. So you would use ipfw to divert packets to natd and natd will rewrite them so that they want to go to 8080 (I have not the exact syntax, but there are examples in the natd documentation I believe) with the following line in /etc/services, natd 6668/divert # Network Address Translation socket I would imagine that rules of the form: ipfw add divert natd ip from any to any 80 in recv ed0 this will take packets coming in on ed0 (or your LAN port) and direct them to the natd process waiting in divert port 6668 Natd will resend them to 8080 you then need the reverse. ipfw add 1 divert natd ip from [youripaddress] 8080 to any which should capture the return packets and convert them back. you then would use the -redirect_port option to natd do do the mapping. This is all theoretical as I've never done it this way. maybe someone else who HAS done it can give corrections. julian On Wed, 1 Jul 1998, Evren Yurtesen wrote: > well I use a configuration line like this > > ipfw add 1 divert 8080 tcp from any to 195.174.18.2 80 > > is this enough or should I use natd too ? > > On Wed, 1 Jul 1998, Evren Yurtesen wrote: > > > hello > > first thank you for writing an answer to my stupid question :) > > well, I am trying to do that ipfw thing for hours and now it is 4:00am > > here... > > I use 2.2.6 release of freebsd, may I apply the patch? > > anyway even if I may, I do not know how to do it... > > is there any easier way to get the patches and appy and compile > > the ipfw ? > > eh, I am not a unix guru yet :) > > > > thank you > > Evren > > > > > I have a patch for -currnet in > > > http://www.freebsd.org/~julian > > > > > > that allows you to do this > > > > > > I know the patch has a silly typo in it at the moment. > > > (it get's an error on compile but it's easy to dee what's wrong and fix > > > it) > > > > > > I think you can also use natd to do it less efficiently. > > > > > > peter wemm (peter@freebsd.org) has a version of these patches for 2.2.x. > > > > > > > > > > > > On Wed, 1 Jul 1998, Evren Yurtesen wrote: > > > > > > > hello > > > > I want to capture all frames sent to port 80 > > > > and I want to send them to port 8080 which my > > > > proxy server runs. > > > > how may I do it ? > > > > also I guess the reverse action. > > > > > > > > > > > > +--------------------------------------------------------+ > > > > | Name : Evren Yurtesen - yurtesen@ispro.net.tr | > > > > | S-mail: Mithatpasa Cad. No:1079/13 35290 Guzelyali | > > > > | Home:+90-232-2857604 Work:+90-232-2463992 Izmir/TURKEY | > > > > +--------------------------------------------------------+ > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-isp" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 20:00:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05810 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 20:00:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05794 for ; Tue, 30 Jun 1998 19:59:48 -0700 (PDT) (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.8/8.8.8) with ESMTP id TAA11708 for ; Tue, 30 Jun 1998 19:59:24 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: hackers@FreeBSD.ORG Subject: Anyone interested in an "interesting" project idea? Date: Tue, 30 Jun 1998 19:59:24 -0700 Message-ID: <11704.899261964@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is something that DG and I were talking about for awhile on the phone last night and agreed that it would be a nice feature if one were also *very careful* to note that this was neither a replacement or substitute for actual clustering, just one piece of the clustering universe (ala VMS more than "PVM" and friends) brought into FreeBSD for administrative convenience. Right, that disclaimer aside, the basic (and very half-baked, based on a single conversation :) concept. First, you change pid_t from an integer to something like this: typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t; So that for any given pid, you can find out if it's running on your machine (hostid = 0) or is really somewhere else. Then you add some extra smarts to the kernel* to do hostid to network ID translation (an IP address for now, I guess) and also teach it the notion of a cluster group, basically some list of hosts which are said to share the same "cluster identifier." When some operation is carried out against a foreign pid, like signal delivery, the kernel would be responsible for mapping the hostid to an actual IP address and doing an RPC for the remote operation with the user credentials and such being passed along. Needless to say, such machines would also have to trust one another. :-) The cluster naming issues would come up with reporting commands like ps - if you want ps to show the processes running on every node in your cluster, for example, you need to have some notion (somewhere) of which hosts comprise it so that `ps -axC' will generate a nice list of processes for only your home cluster. You also probably want to be able to do things like `ps -axC admin' to get a ps for all the hosts in the `admin' cluster, or allow the default cluster to be overridden in the environment. Note that, again, this is *not* anything like actual clustering even though I'm using that word. It's more like an "administrative unit" paradigm where you can do any process operations for any machine in the unit from any other machine. Just think of the possibilities: "*click* Hey Joe, did you know some crackers are into your systems? They have 40 eggdrops running on every single one of your 29 shell machines! Heh.." "Dammit! Is that true?! Hang on!" # ps -axC shell-group | grep egg # killall -9 -C shell-group eggdrop And isn't that a lot easier than the alternative? :-) Sure, one can always cobble together kludges which do essentially the same thing, but it's a real pain compared to simply teaching the system how to allow process administration to be more group oriented - one of those features, as DG put it, that you wonder how you ever lived without once you've had it. I also said `kernel*' earlier since there's some possibility that you could do a lot of the translation and lookup stuff in usermode, it wouldn't have to be in the kernel. You could even strip the extra hostid information off the pid_t's in the relevant syscall wrappers (kill(), wait(), etc) and do the RPC before the kernel even gets its hands on the pid, going for minimal change, but some aspects of this might end up needing to be stuffed into the kernel anyway for other reasons - it's hard to say without getting more seriously stuck into the problem. Anyway, people are always clamoring for project ideas and saying that we in core don't share enough of our wishlist items with folks, so here I am. Any volunteers? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 20:03:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA06374 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 20:03:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA06304 for ; Tue, 30 Jun 1998 20:03:12 -0700 (PDT) (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.8/8.8.8) with ESMTP id UAA11728; Tue, 30 Jun 1998 20:02:06 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: wjw@digi.digiware.nl (Willem Jan Withagen) cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Wed, 01 Jul 1998 01:03:37 +0200." <199806302303.XAA07485@digi.digiware.nl> Date: Tue, 30 Jun 1998 20:02:05 -0700 Message-ID: <11724.899262125@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have actual working code for this. > At the moment every variantlink gets replaced by '2.2.6', since that is my > current OS version. That's really cool! Apollo, here we come! ;-) > - How can I efficiently obtain the value of a sysctl value? > And should they look like 'variant.name', or would/should a > variant link be able to look like: > kern.osrelease: 2.2.6-STABLE I would expect any sysctl expansion to just use the current names, e.g. /usr/tmp/${kern.osrelease} would pretty much do what you'd expect. > - It seems that names are allocated from within the kernel > upon startup, nothing dynamic. Is there any work in progress to make > this more flexible? I could start by first creating a standard set > of names. I don't know if there's any work ongoing here or not. It's defintely a problem that they're currently created with a static linker set and I don't know of any way to create them at "runtime". > * An alternative would be: How do I obtain the environment of the > process using the link? (assuming it has nog messed with its > *env-pointer) Hooboy. That's the holy grail for variant symlink behavior, of course, but it's not information which is at all easy to get ahold of in the current implementation. :-( - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 20:39:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12441 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 20:39:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zeus.theinternet.com.au (akm@zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12421 for ; Tue, 30 Jun 1998 20:38:53 -0700 (PDT) (envelope-from akm@zeus.theinternet.com.au) Received: (from akm@localhost) by zeus.theinternet.com.au (8.8.7/8.8.7) id NAA06445 for hackers@freebsd.org; Wed, 1 Jul 1998 13:34:08 GMT (envelope-from akm) From: Andrew Kenneth Milton Message-Id: <199807011334.NAA06445@zeus.theinternet.com.au> Subject: Re: hello (proxy redirect) In-Reply-To: from Julian Elischer at "Jun 30, 98 07:14:08 pm" To: hackers@FreeBSD.ORG Date: Wed, 1 Jul 1998 13:34:08 +0000 (GMT) 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 Precedence: bulk X-Loop: FreeBSD.ORG +----[ Julian Elischer ]--------------------------------------------- | you need to use natd.. | Nah, you need the -current ipfw that does forwarding (or ipfilter I believe although I haven't used this). You can get ipfw patches from the mpd distribution if the patches aren't in -current yet. I've never been able to get natd to do transparent proxying. If it is possible using natd then someone who's done it should add it to the handbook, so those places not running 2.2.6+ can use that instead of the new ipfw (or send an email so it's in the archives). Be aware though that transparent proxies will no longer be able to give you stats broken down by hostnames or domains. Because the browser will resolve hostname first, the proxy will only ever receive IP addresses to fetch from. This might also have an impact on IPless virtual hosting, although, it would probably only affect those browsers that IPless virtual hosting doesn't work for anyway. On the surface this isn't that bad, however, if you receive a price break on bandwidth for fetching from an upstream proxy, their proxy will have things stored by domain name not IP, so you will blow away any cost benefits of peered proxies. If you don't want any benefits like domain based cache reporting or don't get a price break on bandwidth for upstream proxies then this is probably for you. You also cannot automatically proxy FTP requests in this way, since browsers usually turn the ftp requests into HTTP requests when using a proxy. There is no such thing as a free lunch. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 403 Booval QLD Australia 4304 |akm@theinternet.com.au|Specialist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:10:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17313 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:10:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (omega.Xerox.COM [13.1.64.95]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA17306 for ; Tue, 30 Jun 1998 21:10:42 -0700 (PDT) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <40657(2)>; Tue, 30 Jun 1998 21:09:33 PDT Received: from mango.parc.xerox.com (localhost [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id VAA06201; Tue, 30 Jun 1998 21:09:26 -0700 (PDT) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199807010409.VAA06201@mango.parc.xerox.com> Date: Tue, 30 Jun 1998 21:09:25 PDT From: Bill Fenner To: To: Subject: Re: client-server problem Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Blind-Carbon-Copy To: Yee Man Chan cc: freebsd-net@freebsd.org, fenner Subject: Re: client-server problem In-reply-to: Your message of "Mon, 29 Jun 1998 19:40:20 PDT." Date: Tue, 30 Jun 1998 21:09:25 -0700 From: Bill Fenner This thread belongs on the freebsd-net mailing list. I've bcc'd - -hackers, since it started there, but please follow up on the -net list. In message you w rite: >Here is how the program performs under FreeBSD 3.0-CURRENT with different >n: >1-100 Very fast >101-207 Very Slow (This range is the strangest I've ever seen) >208-1024 Very fast (just like 1-100) This is an interaction between an optimization for large transfers (see http://www.kohala.com/~rstevens/vanj.88jul20.txt) which ends up interacting with the Nagle algorithm for small transfers. One solution is to simply switch to a cluster mbuf as soon as the transfer doesn't fit in a small mbuf: - --- /sys/sys/mbuf.h Mon Aug 19 11:30:15 1996 +++ /tmp/mbuf.h Tue Jun 30 18:40:59 1998 @@ -52,7 +52,7 @@ #define MLEN (MSIZE - sizeof(struct m_hdr)) /* normal data len */ #define MHLEN (MLEN - sizeof(struct pkthdr)) /* data len w/pkthdr */ - -#define MINCLSIZE (MHLEN + MLEN) /* smallest amount to put in cluster */ +#define MINCLSIZE (MHLEN) /* smallest amount to put in cluster */ #define M_MAXCOMPRESS (MHLEN / 2) /* max amount to copy for compression */ /* This is arguably wasteful of memory, in which case the other solution is to undo the optimization when not using cluster mbuf's. The most straightforward way is probably to set atomic to 1 when top == 0 and resid < MINCLSIZE in sosend(). Both of these fixes are untested. >>1024 strange errors like unknown host or connection timedout This is because your code uses the stdio constant BUFSIZ to size its buffer, and when you use "-n" arguments larger than 1024, it starts overwriting parts of the stack. You probably shouldn't use a value like BUFSIZ to size buffers that you need to know the size of, or if you do, do some range checking to make sure that you don't overrun them. Bill ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:12:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17753 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:12:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17720; Tue, 30 Jun 1998 21:12:16 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id NAA10110; Wed, 1 Jul 1998 13:41:59 +0930 (CST) Message-ID: <19980701134158.C9767@freebie.lemis.com> Date: Wed, 1 Jul 1998 13:41:58 +0930 From: Greg Lehey To: P Lynch Cc: FreeBSD Chat , FreeBSD Hackers Subject: USENIX photos (was: Volvo drivers (was: Tiananmen square (was: Does it's true?))) Reply-To: FreeBSD Chat References: <19980701102721.A9694@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from P Lynch on Tue, Jun 30, 1998 at 10:36:33PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Copying -hackers, since many people concerned may not be reading -chat. Please follow up to -chat. On Tuesday, 30 June 1998 at 22:36:33 -0500, P Lynch wrote: > On Wed, 1 Jul 1998, Greg Lehey wrote: >> I met Jonathan at USENIX. He really doesn't fit the stereotype. >> >> And yes, I'll get those pictures on the web as soon as I get past this >> *(&^&^& Microslop I'm forced to use. Anybody with software or even >> protocol specs for a Casio QV-5000 please raise their hands. It's not >> the same as the protocol for the other Casio cameras. > > Yeh I got a picture of Jordan and Mike Smith at the FreeBSD booth at > USENIX I have yet to be developed. I'll put them up on rush.net when I > have a chance OK, now I have the photos on line. Sorry for the delay, I had to use Microsoft, and it drove me crazy. Take a look at http://www.lemis.com/grog/usenix.html. Beware, I haven't put in thumbnails: the page will download about 1.4 MB of data. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:16:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA18394 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:16:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA18368 for ; Tue, 30 Jun 1998 21:16:12 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt4-59.HiWAAY.net [208.166.127.59]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id XAA18494; Tue, 30 Jun 1998 23:16:09 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id TAA11744; Tue, 30 Jun 1998 19:24:30 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199807010024.TAA11744@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: spork cc: hackers@FreeBSD.ORG From: David Kelly Subject: Re: Too much spam from uu.net In-reply-to: Message from spork of "Tue, 30 Jun 1998 01:39:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jun 1998 19:24:30 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG spork writes: > How hard is it to allow uu.net mail relays, but no direct connections from > dialups, ie: foo.tnt.foo.uu.net is blocked but smtp.uu.net is not? I'm > looking to do something like this here, but haven't revisited sendmail in > some time. There's no reason for a dialup connection to send me (or > anyone else) mail directly. They should be sending via their ISP's relay > instead. Some spam directly from their dialup, others don't seem to mind letting uu.net's hosts do it. I'm thinking seriously about the Death Penalty for all uu.net processed email to my personal account. All of the following were forwarded to abuse@uu.net. Snips from my spam folder: Received: from gte.net (1Cust30.tnt3.redondo-beach.ca.da.uu.net [208.252.35.30]) by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id FAA28616; Tue, 30 Jun 1998 05:49:36 -0500 (CDT) Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id CAA12051 for ; Tue, 30 Jun 1998 02:32:56 -0500 (CDT) Received: from LOCALNAME by relay1.UU.NET with SMTP (peer crosschecked as: 1Cust192.tnt10.nyc3.da.uu.net [153.37.131.192]) id QQevyz20480; Tue, 30 Jun 1998 03:28:02 -0400 (EDT) Received: from mail2.yahoo.com (1Cust236.tnt23.atl2.da.uu.net [153.34.31.236]) by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id WAA16128; Sun, 28 Jun 1998 22:43:18 -0500 (CDT) Received: from 153.37.9.203 (1Cust203.tnt3.sfo3.da.uu.net [153.37.9.203]) by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id OAA12526; Sun, 28 Jun 1998 14:10:17 -0500 (CDT) Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id FAA19141 for ; Sun, 28 Jun 1998 05:54:22 -0500 (CDT) Received: from anonymous by smtp0-alterdial.uu.net with SMTP (peer crosschecked as: wck-ca7-11.ix.netcom.com [204.31.231.43]) id QQevsd13937; Sun, 28 Jun 1998 10:52:52 GMT Received: from river99 (1Cust234.tnt18.atl2.da.uu.net [153.36.118.234]) by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id BAA15638; Sun, 28 Jun 1998 01:48:04 -0500 (CDT) Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id AAA16714 for ; Sun, 28 Jun 1998 00:26:19 -0500 (CDT) Received: from anonymous by smtp0-alterdial.uu.net with SMTP (peer crosschecked as: 146.san-francisco-12.ca.dial-access.att.net [12.64.126.146]) id QQevrh28561; Sun, 28 Jun 1998 05:24:42 GMT -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:28:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20502 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:28:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20496 for ; Tue, 30 Jun 1998 21:28:22 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-54.camalott.com [208.229.74.54]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id XAA05520; Tue, 30 Jun 1998 23:24:20 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id XAA02804; Tue, 30 Jun 1998 23:24:39 -0500 (CDT) (envelope-from joelh) Date: Tue, 30 Jun 1998 23:24:39 -0500 (CDT) Message-Id: <199807010424.XAA02804@detlev.UUCP> To: gurney_j@resnet.uoregon.edu CC: tlambert@primenet.com, peter@taronga.com, hackers@FreeBSD.ORG In-reply-to: <19980629203933.13968@hydrogen.nike.efn.org> (message from John-Mark Gurney on Mon, 29 Jun 1998 20:39:33 -0700) Subject: Re: Adding a new user interface to FreeBSD administration From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199806291813.NAA17351@bonkers.taronga.com> <199806291958.MAA04488@usr08.primenet.com> <19980629203933.13968@hydrogen.nike.efn.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> The reason for the Windows 95 registry implementation was the explosive >> proliferation of .INI files. I would hate for FreeBSD to go down that > hun? I thought win31 had a registry too, it's just that apps didn't > use/didn't have access to the registry... I remeber running regedit > on a win31 box... Win 3.1 did have a registry, accessable to apps (otherwise how would regedit work?). It was the equivilent of the Win32 registry key HKEY_CLASSES_ROOT. (If you use regedit /v you will see a little bit more clearly the hierarchal structure.) All it stored was information about file types and OLE servers; preferences were still in INI files. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:32:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20975 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:32:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20970 for ; Tue, 30 Jun 1998 21:32:36 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-54.camalott.com [208.229.74.54]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id XAA05928; Tue, 30 Jun 1998 23:31:32 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id XAA02840; Tue, 30 Jun 1998 23:30:26 -0500 (CDT) (envelope-from joelh) Date: Tue, 30 Jun 1998 23:30:26 -0500 (CDT) Message-Id: <199807010430.XAA02840@detlev.UUCP> To: kline@tao.thought.org CC: hackers@FreeBSD.ORG In-reply-to: <199806301921.MAA10264@tao.thought.org> (message from Gary Kline on Tue, 30 Jun 1998 12:21:56 -0700 (PDT)) Subject: Re: source for xgettext From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199806301921.MAA10264@tao.thought.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can anybody mail me the src for xgettext.c? I see that this is > an X11R6 utility (?). > For the time being, I'm using some perl scripts to format the > strings as I want them, but it would prob'ly make more sense to > hack xgettext itself to do what I want. > Thanks for any tips on where this source it; even better if you > can sent it along. If it's a utility that's part of X11R6, then look at the X sources on ftp.x.org. If it's not, then try archie. (telnet to archie.unl.edu; login archie; type help.) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 21:37:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA21684 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:37:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA21666 for ; Tue, 30 Jun 1998 21:37:39 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id AAA19337; Wed, 1 Jul 1998 00:37:35 -0400 (EDT) Date: Wed, 1 Jul 1998 00:37:35 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: David Kelly cc: hackers@FreeBSD.ORG Subject: Re: Too much spam from uu.net In-Reply-To: <199807010024.TAA11744@nospam.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How annoying. smtp0-alterdial.uu.net is open to the whole world for relay. That's just incredibly irresponsible... Here's a message I sent to myself through their relay. Note that it *does not* show the host that it received the mail from: ------ Return-Path: Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by arutam.inch.com (8.8.5/8.8.5) with ESMTP id AAA17378 for ; Wed, 1 Jul 1998 00:32:12 -0400 (EDT) From: foo@spam.com Received: by smtp0-alterdial.uu.net with SMTP id QQewcg05158; Wed, 1 Jul 1998 04:31:20 GMT Date: Wed, 1 Jul 1998 04:31:20 GMT Message-Id: Subject: SPAM all you want - We relay MORE! To: undisclosed-recipients:; Nice open relay here. C ------ Charles Sprickman spork@super-g.com ---- On Tue, 30 Jun 1998, David Kelly wrote: > spork writes: > > How hard is it to allow uu.net mail relays, but no direct connections from > > dialups, ie: foo.tnt.foo.uu.net is blocked but smtp.uu.net is not? I'm > > looking to do something like this here, but haven't revisited sendmail in > > some time. There's no reason for a dialup connection to send me (or > > anyone else) mail directly. They should be sending via their ISP's relay > > instead. > > Some spam directly from their dialup, others don't seem to mind letting > uu.net's hosts do it. I'm thinking seriously about the Death Penalty > for all uu.net processed email to my personal account. > > All of the following were forwarded to abuse@uu.net. > > Snips from my spam folder: > > Received: from gte.net (1Cust30.tnt3.redondo-beach.ca.da.uu.net [208.252.35.30]) > by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id FAA28616; > Tue, 30 Jun 1998 05:49:36 -0500 (CDT) > > Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) > by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id CAA12051 > for ; Tue, 30 Jun 1998 02:32:56 -0500 (CDT) > Received: from LOCALNAME by relay1.UU.NET with SMTP > (peer crosschecked as: 1Cust192.tnt10.nyc3.da.uu.net [153.37.131.192]) > id QQevyz20480; Tue, 30 Jun 1998 03:28:02 -0400 (EDT) > > Received: from mail2.yahoo.com (1Cust236.tnt23.atl2.da.uu.net [153.34.31.236]) > by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id WAA16128; > Sun, 28 Jun 1998 22:43:18 -0500 (CDT) > > Received: from 153.37.9.203 (1Cust203.tnt3.sfo3.da.uu.net [153.37.9.203]) > by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id OAA12526; > Sun, 28 Jun 1998 14:10:17 -0500 (CDT) > > Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) > by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id FAA19141 > for ; Sun, 28 Jun 1998 05:54:22 -0500 (CDT) > Received: from anonymous by smtp0-alterdial.uu.net with SMTP > (peer crosschecked as: wck-ca7-11.ix.netcom.com [204.31.231.43]) > id QQevsd13937; Sun, 28 Jun 1998 10:52:52 GMT > > Received: from river99 (1Cust234.tnt18.atl2.da.uu.net [153.36.118.234]) > by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id BAA15638; > Sun, 28 Jun 1998 01:48:04 -0500 (CDT) > > Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) > by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id AAA16714 > for ; Sun, 28 Jun 1998 00:26:19 -0500 (CDT) > Received: from anonymous by smtp0-alterdial.uu.net with SMTP > (peer crosschecked as: 146.san-francisco-12.ca.dial-access.att.net [12.64.126.146]) > id QQevrh28561; Sun, 28 Jun 1998 05:24:42 GMT > > > -- > 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. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 22:38:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28779 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 22:38:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from redfish.go2net.com (redfish.go2net.com [207.178.55.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA28765 for ; Tue, 30 Jun 1998 22:38:32 -0700 (PDT) (envelope-from marcs@go2net.com) Received: from marcs by redfish.go2net.com with smtp (Exim 1.82 #2) id 0yrFZs-0003XM-00; Tue, 30 Jun 1998 22:37:08 -0700 Date: Tue, 30 Jun 1998 22:37:08 -0700 (PDT) From: Marc Slemko X-Sender: marcs@redfish To: Bill Fenner cc: freebsd-hackers@FreeBSD.ORG, jamin@eecs.umich.edu Subject: Re: client-server problem In-Reply-To: <199807010409.VAA06201@mango.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jun 1998, Bill Fenner wrote: > #define MHLEN (MLEN - sizeof(struct pkthdr)) /* data len w/pkthdr */ > > - -#define MINCLSIZE (MHLEN + MLEN) /* smallest amount to put in cluster */ > +#define MINCLSIZE (MHLEN) /* smallest amount to put in cluster */ > #define M_MAXCOMPRESS (MHLEN / 2) /* max amount to copy for compression */ ISTR that there was some problem when someone (I?) suggested this workaround before, in addition to what you mention. Hmm. Maybe it was just dg thinking he remembered something breaking, but he wasn't sure what. David Borman said: >I know what problem you are referring to, but it is not as you describe >it. For a non-atomic protocol (like TCP) sosend() will allocate a >cluster if the data won't fit in the mbuf, even if it is over by only >one byte. This puts a small amount of data into a cluster. It >doesn't take very many of these small writes until sb->sb_mbcnt bumps >into sb->sb_mbmax, long before sb->sb_cc hits sb->sb_hiwat. So, you >get a socket send buffer without much data to send, which can't accept >any more data from the user. You wind up waiting for the delayed ACKs >from the remote side to clear out buffer space, but it is never enough >to allow you to get 2 full packets out to get past the delayed ACKs! >The problem is that sbcompress() does not compress cluster mbufs, to >avoid excessive data copies. I've modified sbcompress() (in the next >release of BSD/OS) to allow cluster mbufs to be compressed, provided >that all the data can be copied and there is no more than 1/4 of a >cluster to copy. This change allows enough data to be copied down >from the user to get out 2 full packets and thus get past the delayed >ACKs. The benchmark will still run slow because of the tiny writes, >and the extra data copies, but at least it no longer runs an order or >two of magnitude slower than really tiny writes (<= the size of an mbuf). about the problem. I don't have the full thread, since I'm in SF and don't have access to my machine at home. It may have been on nanog (? most odd discussions are there). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jun 30 22:59:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00925 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 22:59:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00810; Tue, 30 Jun 1998 22:58:51 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id PAA10442; Wed, 1 Jul 1998 15:10:51 +0930 (CST) Message-ID: <19980701151050.A10131@freebie.lemis.com> Date: Wed, 1 Jul 1998 15:10:50 +0930 From: Greg Lehey To: FreeBSD Chat Cc: FreeBSD Hackers Subject: Re: USENIX photos (was: Volvo drivers (was: Tiananmen square (was: Does it's true?))) Reply-To: FreeBSD Chat References: <19980701102721.A9694@freebie.lemis.com> <19980701134158.C9767@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980701134158.C9767@freebie.lemis.com>; from Greg Lehey on Wed, Jul 01, 1998 at 01:41:58PM +0930 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 1 July 1998 at 13:41:58 +0930, Greg Lehey wrote: > OK, now I have the photos on line. Sorry for the delay, I had to use > Microsoft, and it drove me crazy. > > Take a look at http://www.lemis.com/grog/usenix.html. Beware, I > haven't put in thumbnails: the page will download about 1.4 MB of > data. Wow! I didn't expect so many people to pounce on this at once. Currently I have 17 sessions running concurrently over a 33.6 kb/s line, which gives about 2 kb/s for each of you, and so it's taking forever. I'm moving the files to hub, so you'll probably find it more convenient to wait until they're there (the time is a function of the line load, of course). The URL is http://www.FreeBSD.org/~grog/usenix.html. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 00:59:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13210 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 00:59:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA13204; Wed, 1 Jul 1998 00:59:43 -0700 (PDT) (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 AAA05170; Wed, 1 Jul 1998 00:59:38 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199807010759.AAA05170@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: FreeBSD Chat cc: FreeBSD Hackers Subject: Re: USENIX photos (was: Volvo drivers (was: Tiananmen square (was: Does it's true?))) In-reply-to: Your message of "Wed, 01 Jul 1998 15:10:50 +0930." <19980701151050.A10131@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 00:59:38 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good Job!! Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 01:17:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA15604 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 01:17:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15599 for ; Wed, 1 Jul 1998 01:17:34 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.0/8.9.0) with ESMTP id KAA26374 for ; Wed, 1 Jul 1998 10:16:08 +0200 (MET DST) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.8/8.8.5) with ESMTP id KAA15792 for ; Wed, 1 Jul 1998 10:16:40 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id KAA02104 for ; Wed, 1 Jul 1998 10:17:09 +0200 (CEST) From: Andre Albsmeier Message-Id: <199807010817.KAA05134@internal> Subject: Re: Staroffice 4.0 sp3 running In-Reply-To: <19980630160415.A2179@yoda.pi.musin.de> from Stefan Zehl at "Jun 30, 98 04:04:15 pm" To: sec@yoda.pi.musin.de (Stefan Zehl) Date: Wed, 1 Jul 1998 10:17:03 +0200 (CEST) Cc: andre.albsmeier@mchp.siemens.de, mike@smith.net.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 29, 1998 at 08:59:40PM +0200, Andre Albsmeier wrote: > > However, the installed thing doesn't run properly and consumes only cpu time > > but I hadn't had time to investigate this yet... > > The installed program requires '/proc//cmdline', too. Doing that > sed-thing again on the soffice.bin will probably help you. Thanks for the hint... After modyfing lib/libsal364.so as well Staroffice 4.0 SP3 is running here. So the complete instructions are: 1. Unpack the sp3 distribution 2. cd into the Install directory (where setup.bin is) 3. sed -e 's,/proc/%u/cmdline,/compat/linux/so,' < setup.bin > setup.new 4. mv setup.new setup.bin 5. chmod 755 setup.bin 6. touch /compat/linux/so 7. ./setup The install program should run and install StarOffice. Maybe I missed some step but this is closely what I have done. Then, after installing it, go to the lib directory and do the sed command on libsal364.so: 1. sed -e 's,/proc/%u/cmdline,/compat/linux/so,' < libsal364.so > libsal364.new 2. mv libsal364.new libsal364.so 3. chmod 755 libsal364.so The new /compat/linux/so path can be anything that does not exceed the 16 characters. It only has to point to an empty file... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 01:40:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17930 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 01:40:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from omnix.net (omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA17917 for ; Wed, 1 Jul 1998 01:40:07 -0700 (PDT) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost) by omnix.net (8.8.7/8.8.7) with SMTP id IAA12184; Wed, 1 Jul 1998 08:38:50 GMT (envelope-from didier@omnix.net) Date: Wed, 1 Jul 1998 10:38:50 +0200 (CEST) From: Didier Derny Reply-To: Didier Derny To: Brian Somers cc: hackers@FreeBSD.ORG Subject: Re: ppp with the latest SNAPSHOT (may) In-Reply-To: <199806302351.AAA12373@awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Jul 1998, Brian Somers wrote: > > > > user ppp worked fine for years but after having changed my mother board/ > > upgraded to the latest snapshot it is not working anymore > > > > as I did both operation at the same time I dont know if the problem > > comes from the mother board or user ppp. > > > > the mother board is an Asus P2B (chipset BX) > > > > do you have any clue ? > > No. You'll need to explain what ``doesn't work'' means :-( My car > doesn't work. Do you have any idea what's wrong with it ? > > > thanks for your help > > As everything worked fine before, I only thought that there was a known problem either with the lastest snapshot or with the ASUS P2B motherboard. In fact, it dial, the provider's modem answers, apparently, ppp and the provider are chatting permanently with any success. it seems unable to set the ip adresses I have the same problem with two different providers so, it does not come from the provider side. Thanks for your help -- Didier Derny didier@omnix.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 01:49:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA19003 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 01:49:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18993 for ; Wed, 1 Jul 1998 01:49:56 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id KAA27088; Wed, 1 Jul 1998 10:49:55 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id KAA25121; Wed, 1 Jul 1998 10:49:55 +0200 (MET DST) Date: Wed, 1 Jul 1998 10:49:55 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807010849.KAA25121@surf.IAE.nl> To: jkh@time.cdrom.com Subject: Re: Variant Link implementation, continued X-Newsgroups: list.freebsd.hackers In-Reply-To: References: Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >> I have actual working code for this. >> At the moment every variantlink gets replaced by '2.2.6', since that is my >> current OS version. > >That's really cool! Apollo, here we come! ;-) Just look for the Apollo FAQ and see why I'm chasing this one down. :-D. I just loved my Domain babies. [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( ]] >> - How can I efficiently obtain the value of a sysctl value? >> And should they look like 'variant.name', or would/should a >> variant link be able to look like: >> kern.osrelease: 2.2.6-STABLE > >I would expect any sysctl expansion to just use the current names, >e.g. /usr/tmp/${kern.osrelease} would pretty much do what you'd expect. Oke, sounds sensible. Then you'd have a lot more "useless" values to scan through do, while replacing. But it's a good start. >> * An alternative would be: How do I obtain the environment of the >> process using the link? (assuming it has nog messed with its >> *env-pointer) > >Hooboy. That's the holy grail for variant symlink behavior, of >course, but it's not information which is at all easy to get ahold of >in the current implementation. :-( I've had some discussion with Terry about this, and one of the "options" would be to include the *env pointer into the u-area, such that we know where the user keeps his env. How hard is it to get to the user's data from within the kernel? And what about the copy penalty? Now the problem pointed out by Terry is that users are allowed to do nasty stuff to their environment, and in the process "invalidate" the u-area *env. The solution would be to force a cleaner behaviour towards environment use. I'm still trying to figure out how serious this is for what I'm trying to make. 1) 'legacy' programs have no knowledge about this stuff. So resolving links should make sense. AND perhaps we would be just as happy, using the environment we created at execve-time. Then the user can mess around all he/she wants. Then the u-area would have the keep 2 *env's, one to be manipulated by the user. The other to keep pointing to the old structure. 2) ........ Terry had even more nice suggestions: like turning sysctl-name space into a filesystem like thing. With rights and likes. This will be too far out for my competence....... --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 01:54:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA19919 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 01:54:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA19897 for ; Wed, 1 Jul 1998 01:54:41 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id KAA19232; Wed, 1 Jul 1998 10:54:05 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id KAA11188; Wed, 1 Jul 1998 10:54:22 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199806302344.QAA00868@bangkok.office.cdsnet.net> Date: Wed, 01 Jul 1998 10:54:22 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: Craig Spannring Subject: Re: Unsupport calls Cc: FreeBSD Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Jun-98 Craig Spannring wrote: > Marino Ladavac writes: > > > > > sigwait is in libc_r, being a part of POSIX pthread specification. > > > > /Marino > > > sigwait() is indeed in libc_r, but it is broken. See misc/7039 in > gnats. Sad, but true. In fact, all of pthread stuff is pretty badly broken, at least in 2.2.6-R. I hear that -stable includes a practically full re-write of thread stuff, but I cannot follow stable :( The main point is that it is there, and will work eventually (unlike the sigrelse() and that ilk). /Marino > > > -- > ======================================================================= > Life is short. | Craig Spannring > Ski hard, Bike fast. | cts@internetcds.com > --------------------------------+------------------------------------ > Any sufficiently perverted technology is indistinguishable from Perl. > ======================================================================= > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ---------------------------------- Marino Ladavac Date: 01-Jul-98 Time: 10:51:25 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 02:22:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA22386 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 02:22:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA22379 for ; Wed, 1 Jul 1998 02:22:16 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id TAA29538; Wed, 1 Jul 1998 19:32:52 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199807010932.TAA29538@cimlogic.com.au> Subject: Re: Unsupport calls In-Reply-To: from Marino Ladavac at "Jul 1, 98 10:54:22 am" To: lada@pc8811.gud.siemens.at (Marino Ladavac) Date: Wed, 1 Jul 1998 19:32:47 +1000 (EST) Cc: cts@internetcds.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marino Ladavac wrote: > I hear that -stable includes a practically full > re-write of thread stuff, but I cannot follow stable :( That is not true. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 03:17:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27266 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 03:17:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27261 for ; Wed, 1 Jul 1998 03:17:10 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id DAA07121; Wed, 1 Jul 1998 03:17:09 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA19598; Wed, 1 Jul 1998 03:17:08 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA05610; Wed, 1 Jul 1998 03:17:07 -0700 (PDT) From: Don Lewis Message-Id: <199807011017.DAA05610@salsa.gv.tsc.tdk.com> Date: Wed, 1 Jul 1998 03:17:06 -0700 In-Reply-To: Terry Lambert "Re: Code Logic Question in 2.2 RELENG" (Jun 5, 6:41pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: Code Logic Question in 2.2 RELENG Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jun 5, 6:41pm, Terry Lambert wrote: } Subject: Re: Code Logic Question in 2.2 RELENG } > } Which reminds me. Someone needs to fix the "siginterrupt" man page. } > } } > } I would, but I think it is FreeBSD that is broken, not the man page, } > } and that by default, system calls *should* be restarted after a } > } signal is caught. I find it utterly bogus that I have to springle } > } the bejesus out of my code for while()'s and tests for "EINTR" and } > } manually restart all of my system calls. Gruds, if I wanted that, } > } I load System V on my box instead of BSD. } > } > Why not use the POSIX sigaction() call instead of signal(). } } The point is not my choice of interface, it's that the siginterrupt(3) } man page says: } } System call restart has been the default behavior since 4.2BSD, } and is the default behaviour on FreeBSD. } } } > It seems } > to be available except for really old systems that you probably don't } > want to play with anyway. } } Bad call. I *like* MicroVAX hardware running Ultrix. I'm the one } who always complains about changes that make it so a K&R compiler } on old hardware can't be used to port FreeBSD to that hardware. } } } > It also works the same everywhere, unlike signal(). } } Only because System V implemented signals wrong. The original signal() implementation reset the handler to SIG_DFL before calling the handler, which generally required you to rearm the handler from within the handler. System V kept this behaviour and BSD changed it to something more sane but incompatible. Some implementations can do bad things if you rearm the handler from within the handler. I think the problem is if you rearm the SIGCLD/SIGCHLD handler before reaping any waiting processes, the handler gets re-entered. } > } In The Good Old Days(tm), it wasn't an option; if you wanted EINTR } > } type behaviour, you did a setjmp before the call you wanted the } > } behaviour on, and like a decent, God-fearing BSD'er, you called } > } longjmp from the signal handler to prevent the call from being } > } restarted. } > } > Ick! If you leave out a setjmp(), you'll return to the wrong place. } } And if I call memcpy with arguments in bcopy order, I'll get the } wrong results, too. } } Bad input == bad output. I don't see your objection. I think this makes the code harder to maintain. If you add a new blocking syscall and forget the setjmp(), you'll intermittently return to the wrong place in the code, which will be difficult to debug. Forgetting to catch EINTR is easier to track down, especially if you are careful to check return values and errno. } > This also prevents you from keeping variables in registers, because } > they won't be restored when you return. } } What system are you running? Man setjmp(3) says: } } All accessible objects have values as of the time longjmp() } routine was called, except that the values of objects of } automatic storage invocation duration that do not have the } volatile type and have been changed between the setjmp() } invocation and longjmp() call are indeterminate. This is what I'm referring to. I just love indeterminate code ... } The setjmp()/longjmp() pairs save and restore the signal } mask while _setjmp()/_longjmp() pairs save and restore only } the register set and the stack. (See sigprocmask(2).) } } > In some implementations you have to remember to do a sigrelse() } > after returning from setjmp() if you ever want to catch the signal } > again. } } ??? Which implementations? I've worked on UNIXen from UTS to } Microsoft Xenix on Sun 3 hardware to Heurikon's to whatever, and } I have *never* seen this. % uname -rs HP-UX B.10.20 The fine man page sez: Before calling the signal-catching handler, the system signal action of sig is set to SIG_HOLD. During a normal return from the signal-catching handler, the system signal action is restored to func and any held signal of this type is released. If a non-local goto (longjmp(3C)) is taken, sigrelse() must be called to restore the system signal action to func and release any held signal of this type. though on careful reading this applies to sigset(), while signal() just sets the action back to SIG_DFL. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 03:23:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27938 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 03:23:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tyree.iii.co.uk (tyree.iii.co.uk [195.89.149.230]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27922 for ; Wed, 1 Jul 1998 03:23:53 -0700 (PDT) (envelope-from nik@iii.co.uk) From: nik@iii.co.uk Received: from carrig.strand.iii.co.uk (carrig.strand.iii.co.uk [192.168.7.25]) by tyree.iii.co.uk (8.8.8/8.8.8) with ESMTP id LAA24821; Wed, 1 Jul 1998 11:23:34 +0100 (BST) Received: (from nik@localhost) by carrig.strand.iii.co.uk (8.8.8/8.8.7) id LAA08996; Wed, 1 Jul 1998 11:23:31 +0100 (BST) Message-ID: <19980701112330.02788@iii.co.uk> Date: Wed, 1 Jul 1998 11:23:30 +0100 To: Andre Albsmeier Cc: Stefan Zehl , mike@smith.net.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running References: <19980630160415.A2179@yoda.pi.musin.de> <199807010817.KAA05134@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199807010817.KAA05134@internal>; from Andre Albsmeier on Wed, Jul 01, 1998 at 10:17:03AM +0200 Organization: interactive investor Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 01, 1998 at 10:17:03AM +0200, Andre Albsmeier wrote: > > On Mon, Jun 29, 1998 at 08:59:40PM +0200, Andre Albsmeier wrote: > > > However, the installed thing doesn't run properly and consumes only > > > cpu time but I hadn't had time to investigate this yet... > > > > The installed program requires '/proc//cmdline', too. Doing that > > sed-thing again on the soffice.bin will probably help you. > > Thanks for the hint... After modyfing lib/libsal364.so as well > Staroffice 4.0 SP3 is running here. > > So the complete instructions are: I've been following this with some interest. I've had StarOffice 4.0 (no service pack) running on my -stable box for a while. The only problems I've seen with it are that it leaks shared memory like a sieve, resulting in unpredictable lockups. Are these fixed in SP3? N -- Work: nik@iii.co.uk | FreeBSD + Perl + Apache Rest: nik@nothing-going-on.demon.co.uk | Remind me again why we need Play: nik@freebsd.org | Microsoft? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 04:26:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA04563 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 04:26:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA04527; Wed, 1 Jul 1998 04:26:39 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id LAA19897; Wed, 1 Jul 1998 11:26:32 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA10989; Wed, 1 Jul 1998 13:26:31 +0200 (MET DST) Message-ID: <19980701132630.24761@follo.net> Date: Wed, 1 Jul 1998 13:26:30 +0200 From: Eivind Eklund To: Richard Goh , efinley@castlenet.com, Alfred Perlstein Cc: "Timothy M. Hughes" , freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: RealTek RTL 8129 PCI Fast Ethernet Card References: <359ae341.2257050@afnetinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Richard Goh on Wed, Jul 01, 1998 at 07:48:16AM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 01, 1998 at 07:48:16AM +0800, Richard Goh wrote: > Hi, > Thanks for the info. > So far so bad, now I have a $2.5k machine sitting pretty on its own and > cant even change the network card which is on the motherboard. > Looks like the only option left is to port the linux driver. > Anyone with some experience on this ? > Or is there a guide? There is a Device Driver Writers Guide in the tutorials. If you have problems understanding it, feel free to mail me with questions (I'm trying to do an upgrade of the guide, so that kind of feedback would be useful :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 05:14:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA08851 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 05:14:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from st-lcremean.tidalwave.net (lee@st-lcremean.tidalwave.net [208.213.203.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA08845 for ; Wed, 1 Jul 1998 05:14:10 -0700 (PDT) (envelope-from lee@st-lcremean.tidalwave.net) Received: (from lee@localhost) by st-lcremean.tidalwave.net (8.8.7/8.8.7) id IAA11346; Wed, 1 Jul 1998 08:13:43 -0400 (EDT) (envelope-from lee) Message-ID: <19980701081343.52818@st-lcremean.tidalwave.net> Date: Wed, 1 Jul 1998 08:13:43 -0400 From: Lee Cremeans To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= Cc: joelh@gnu.org, belkovic@albert.osu.cz, freebsd-hackers@FreeBSD.ORG Subject: Re: BROKEN_KEYBOARD_RESET Reply-To: lcremean@tidalwave.net References: <199806291440.JAA02540@detlev.UUCP> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.85e In-Reply-To: =?iso-8859-1?Q?=3Crx4yaufmkxq=2Efsf=40oslo=2Egeco-prakla=2Eslb=2Ecom=3E?= =?iso-8859-1?Q?=3B_from_Dag-Erling_Coidan_Sm=F8rgrav_on_Tue=2C_Jun_30=2C?= =?iso-8859-1?Q?_1998_at_09=3A02=3A25AM_+0200?= X-OS: FreeBSD 2.2.5-STABLE (soon to be 3.0-CURRENT) X-Evil: microsoft.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 30, 1998 at 09:02:25AM +0200, Dag-Erling Coidan Smørgrav wrote: > Joel Ray Holveck writes: > > >> I will try in asembler only following: > > >> a) i change cpu mode from protected to 'normal' > > >> b) i change appropriate segment registers > > >> c) i change appropriate bios constant to enable warm post > > >> d) i will call appropritae bios function (int 19h ?) > > > No, jo do a long jump to FFFF:0 IIRC. > > I thought it was F000:0... You may want to consult the pink shirt > > book. (Mine's 90 miles away right now, sorry.) > > Which is why I added IIRC :) FWIW, you were right; it is FFFF:0000 (0xFFFF0). This is one of those real-mode addresses I have memorised from my DOS hacking days :) -- Lee C. -- Manassas, VA, USA (WakkyMouse on DALnet #watertower) A! JW223 YWD+++^ri P&B++ SL+++^i GDF B&M KK--i MD+++i P++ I++++ Did $++ E5/10/70/3c/73ac/95/96 H2 PonPippi Ay77 M | lcremean@tidalwave.net FreeBSD/Linux/Unix hacker...Win95 and M$ evil! (go see www.freebsd.org) My home page: http://st-lcremean.tidalwave.net/~lee | finger me for geek code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 05:41:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11479 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 05:41:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from eros.che.curtin.edu.au ([134.7.142.140]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11466 for ; Wed, 1 Jul 1998 05:41:41 -0700 (PDT) (envelope-from gdr@eros.che.curtin.edu.au) Received: (from gdr@localhost) by eros.che.curtin.edu.au (8.8.8/8.8.8) id WAA09457; Wed, 1 Jul 1998 22:38:16 +1000 (EST) (envelope-from gdr) From: Gary Roberts Message-Id: <199807011238.WAA09457@eros.che.curtin.edu.au> Subject: Re: Staroffice 4.0 sp3 running In-Reply-To: <19980701112330.02788@iii.co.uk> from "nik@iii.co.uk" at "Jul 1, 98 11:23:30 am" To: nik@iii.co.uk Date: Wed, 1 Jul 1998 22:38:16 +1000 (EST) Cc: andre.albsmeier@mchp.siemens.de (Andre Albsmeier), sec@yoda.pi.musin.de (Stefan Zehl), freebsd-hackers@FreeBSD.ORG Organisation: Well Control Australia Phone: +618 9266 7586 Fax: +618 9266 3554 Reply-To: gdr@wcs.uq.edu.au (Gary Roberts) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG nik@iii.co.uk writes :- > On Wed, Jul 01, 1998 at 10:17:03AM +0200, Andre Albsmeier wrote: > > > > Thanks for the hint... After modyfing lib/libsal364.so as well > > Staroffice 4.0 SP3 is running here. > > > > So the complete instructions are: > > I've been following this with some interest. > > I've had StarOffice 4.0 (no service pack) running on my -stable box for a > while. The only problems I've seen with it are that it leaks shared memory > like a sieve, resulting in unpredictable lockups. > > Are these fixed in SP3? I've also been following this with considerable interest. Because of the reported difficulties with SP3, I actually installed SP2 about two weeks ago. I had it running continuously for about 4-5 days (at one stage when I had a look with ps it has clocked up about 100 mins of CPU time) and at no stage did it exhaust my virtual memory. I did have some other hungry apps like netscape running at the same time and I didn't see any lockups at all. I have a 100Mhz Toshiba notebook with 40Mb physical and 120Mb swap. The only thing I got (within a minute or so of initial startup) was exactly 28 lines on the xterm from which I started it, all saying SalImage::Create pShmInfo_->shmid < 0 (28) After that, nothing else unusual occurred. I would guess that the leaks were probably mostly plugged with SP1 :-) (one would hope anyway). Now that Andre has published the workaround to get SP3 running, the only other thing I would like to see is a report from anyone using SP3 to say if it is worthwhile going to SP3 over SP2. Any comments, anyone?? Cheers, -- Gary Roberts (gdr@wcs.uq.edu.au) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 05:47:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11912 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 05:47:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA11905 for ; Wed, 1 Jul 1998 05:47:55 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA23084; Wed, 1 Jul 1998 08:46:45 -0400 Date: Wed, 1 Jul 1998 08:46:45 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: Anyone interested in an "interesting" project idea? In-Reply-To: <11704.899261964@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jordan proposes: > typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t; And the you fix things so that there is a "route" between the hostid and the ip address. Then you fix commands so they can handle it. You can do this, but 8 bits is too small. I have a solution that has worked much more nicely for me, using the private name space code I have working. Namely, you mount into your name space as follows: /proc/ is from :/proc and so on, for any and all hosts you are interested in. To get status of all procs on all the machines, you just cat /proc/*/*/status Then you can have a ps that understands how to do this too. No 8-bit limits, no need for sysadmin involvment, and in fact every user can build their own /proc tree for their needs. Obviously the sysadmin builds one which includes his machines of interest. So if we could change the format of /proc as follows: /proc/, where the default is /proc/localhost and other hosts come in as needed, then you don't need to change pid formats, and yet you get something that is very fast. /proc/localhost is the moral equivalent in hosts of /proc/curproc. To see who you are, look at /proc/localhost/curproc Also, the "global /proc" is in fact a specialized instance of a very general mechanism. No special mods needed. Lots of other potential uses. This is working now in user mode on freebsd, and user and kernel on linux. What I desperately need is help, so if anyone is interested, let me know. Oh yes: since it is private name spaces, the usual NFS problems need not (and do not) apply. Which is why I did this stuff in the first place. Second oh yes: to control a set of procs across the cluster, obviously you write to /proc//pid/ctl. ron Ron Minnich |Java: an operating-system-independent, rminnich@sarnoff.com |architecture-independent programming language (609)-734-3120 |for Windows/95 and Windows/NT on the Pentium ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 06:14:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14972 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 06:14:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14966 for ; Wed, 1 Jul 1998 06:14:51 -0700 (PDT) (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.8/8.8.8) with ESMTP id GAA13621; Wed, 1 Jul 1998 06:14:25 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Willem Jan Withagen cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Wed, 01 Jul 1998 10:49:55 +0200." <199807010849.KAA25121@surf.IAE.nl> Date: Wed, 01 Jul 1998 06:14:25 -0700 Message-ID: <13617.899298865@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've had some discussion with Terry about this, and one of the "options" > would be to include the *env pointer into the u-area, such that we know > where the user keeps his env. Well, just don't forget that the setenv() code in libc can change the value of environ at any time with a realloc(), so if you're going to copy it into the u_area you're also going to have to keep this copy in sync unless you also had plans on replacing environ. :) > How hard is it to get to the user's data from within the kernel? > And what about the copy penalty? It wouldn't be cheap, and I seriously pity the man who has to hack this code into namei() without seriously perturbing its optimizations for the "normal" case, but I think the speed/functionality tradeoffs would be also be acceptable in the long run. > Now the problem pointed out by Terry is that users are allowed to do nasty > stuff to their environment, and in the process "invalidate" the u-area *env. Yeah, I think it'll be enough to worry about the sanctioned functions for scribbling on *environ like setenv() and handle the people who are deliberately pounding on *environ with some kind of reasonable range checking. > 1) 'legacy' programs have no knowledge about this stuff. So resolving > links should make sense. Hmmm. readlink() would certainly do the expansion and prevent most legacy programs from having to even know about environment variable expansion in syminks, the question remaining as to what you do with variable names which are invalid or non-existant. Pass through the unexpanded token? Eliminate the token? Return NULL? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 07:56:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25997 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 07:56:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.ny.otec.com (bright.ny.otec.com [209.3.16.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25986 for ; Wed, 1 Jul 1998 07:56:26 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.ny.otec.com (8.8.8/8.8.8) with SMTP id KAA02329; Wed, 1 Jul 1998 10:56:12 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.ny.otec.com: bright owned process doing -bs Date: Wed, 1 Jul 1998 10:56:12 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.ny.otec.com To: nik@iii.co.uk cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running In-Reply-To: <19980701112330.02788@iii.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the shared memory problem was a mistake in the linux emulation, it is fixed in -current however i still get lockups from some other reason right after opening a document. i'm gonna try a more current version of StarOffice soon. -Alfred On Wed, 1 Jul 1998 nik@iii.co.uk wrote: > On Wed, Jul 01, 1998 at 10:17:03AM +0200, Andre Albsmeier wrote: > > > On Mon, Jun 29, 1998 at 08:59:40PM +0200, Andre Albsmeier wrote: > > > > However, the installed thing doesn't run properly and consumes only > > > > cpu time but I hadn't had time to investigate this yet... > > > > > > The installed program requires '/proc//cmdline', too. Doing that > > > sed-thing again on the soffice.bin will probably help you. > > > > Thanks for the hint... After modyfing lib/libsal364.so as well > > Staroffice 4.0 SP3 is running here. > > > > So the complete instructions are: > > I've been following this with some interest. > > I've had StarOffice 4.0 (no service pack) running on my -stable box for a > while. The only problems I've seen with it are that it leaks shared memory > like a sieve, resulting in unpredictable lockups. > > Are these fixed in SP3? > > N > -- > Work: nik@iii.co.uk | FreeBSD + Perl + Apache > Rest: nik@nothing-going-on.demon.co.uk | Remind me again why we need > Play: nik@freebsd.org | Microsoft? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 08:11:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27772 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 08:11:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27767 for ; Wed, 1 Jul 1998 08:11:39 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id RAA29071; Wed, 1 Jul 1998 17:11:38 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id RAA08138; Wed, 1 Jul 1998 17:11:38 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807011511.RAA08138@surf.IAE.nl> Subject: Re: Variant Link implementation, continued In-Reply-To: <13617.899298865@time.cdrom.com> from "Jordan K. Hubbard" at "Jul 1, 98 06:14:25 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 1 Jul 1998 17:11:38 +0200 (MET DST) Cc: hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You ( Jordan K. Hubbard ) write: => > I've had some discussion with Terry about this, and one of the "options" => > would be to include the *env pointer into the u-area, such that we know => > where the user keeps his env. => => Well, just don't forget that the setenv() code in libc can change the => value of environ at any time with a realloc(), so if you're going => to copy it into the u_area you're also going to have to keep this copy => in sync unless you also had plans on replacing environ. :) Terry suggested something to this end. Needless to say I share the :) in a :{ sense. The reallocation would show due to the fact that not both *environ pointer are equal. The problem might be that due to a realloc, the original space no longer contains sensible ENV's, and the kernel chokes on that. And as long as it would be in libc, then that might be a solution for most decent programs. What is of more concern are static linked and/or legacy programs. => > How hard is it to get to the user's data from within the kernel? => > And what about the copy penalty? => => It wouldn't be cheap, and I seriously pity the man who has to hack => this code into namei() without seriously perturbing its optimizations => for the "normal" case, but I think the speed/functionality tradeoffs => would be also be acceptable in the long run. The serious penalty only comes when a variant-link element is found in that specific path-element. Now the bad part is searching the user-space env everytime a user access /usr/local in a full-path. I've even deleted a optimsation which is IMHO not very efficient, but do obfuscate the code very much. It all has to do with the special treatement of a path-component of 1 char, just to save a malloc. Namei in itself is relatively simple, it is lookup() where the real pain to understand the code is. And sensibly trying to cache some of the lookups is asking for even more trouble. => > Now the problem pointed out by Terry is that users are allowed to do nasty => > stuff to their environment, and in the process "invalidate" the u-area *env. => => Yeah, I think it'll be enough to worry about the sanctioned functions => for scribbling on *environ like setenv() and handle the people who are => deliberately pounding on *environ with some kind of reasonable range => checking. Well IFF the enviroment has changed we could always fall back to default behaviour. Which I would suggest is to eliminate the token, and thus resulting in something like: /usr/local -> /usr/.local.${OSVERSION} have a few dirs .local.1.1.5 .local.2.2.6 .local.3.0 .local.4.0 (given, a little extreme range) and then have a LINK .local. pointing to the lowest available denomenator which would now be .local.1.1.5 => > 1) 'legacy' programs have no knowledge about this stuff. So resolving => > links should make sense. => => Hmmm. readlink() would certainly do the expansion and prevent most => legacy programs from having to even know about environment variable => expansion in syminks, the question remaining as to what you do with => variable names which are invalid or non-existant. Pass through the => unexpanded token? Eliminate the token? Return NULL? :-) Note that typo's in variant-linsk would be a problem for ALL programs, legacy or not. Non existant names would translate to an empty string. See above. with the addition that I would build it that there are some systemwide settings to be always available through the sysctl stuff. It would be a sort of hierachical namespace, like with the cpp includes. It might even be sensible to create ${} links: search first ENV(), then sysctl @{} links: only sysctl Which reduces the legacy problem, slightly..... I'll first create a standard set of sysctl-values to make the system more or less usable, just to prove the concept (for those without Apollo history). --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 09:01:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03254 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 09:01:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03247 for ; Wed, 1 Jul 1998 09:01:22 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id JAA04116; Wed, 1 Jul 1998 09:01:03 -0700 (PDT) (envelope-from jdp) Message-Id: <199807011601.JAA04116@austin.polstra.com> To: ambrisko@whistle.com Subject: Re: Problem with ld.so + LD_PRELOAD + _init() In-Reply-To: <199806182244.PAA25002@whistle.com> References: <199806182244.PAA25002@whistle.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Date: Wed, 01 Jul 1998 09:01:03 -0700 From: John Polstra Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199806182244.PAA25002@whistle.com>, Doug Ambrisko wrote: > Mikko Työläjärvi writes: > | Fiddling around with LD_PRELOAD and wrapping of system calls, I > | discovered that the "_init()" function of the preloaded lib never gets > | called. ... > Nope wasn't intentional. I didn't know that when I helped add that > feature so I never looked at it. > > I'm sure jdp wouldn't mind a patch that fixed this. I'm coming in kind of late on this. But I agree with Doug. It's a bug, and a patch would be welcomed. On the other hand, when we finally make the switch to ELF (soon, I hope), the a.out ld.so won't be used much any more. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 09:42:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09883 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 09:42:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from base486.home.org (imdave@imdave.pr.mcs.net [205.164.3.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09876; Wed, 1 Jul 1998 09:42:24 -0700 (PDT) (envelope-from imdave@mcs.net) Received: (from imdave@localhost) by base486.home.org (8.8.8/8.8.8) id LAA07192; Wed, 1 Jul 1998 11:42:23 -0500 (CDT) Date: Wed, 1 Jul 1998 11:42:23 -0500 (CDT) From: Dave Bodenstab Message-Id: <199807011642.LAA07192@base486.home.org> To: hackers@FreeBSD.ORG, tlambert@primenet.com Subject: Re: Unsupport calls Cc: freebsd-questions@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Terry Lambert > > > About the only serious one I can see is plock. Maybe somebody else on > > the list can comment. > > It is trivial to implement p/v semaphores using __asm__ to generate > single instruction spinlocks; since the VM/buffer cache is unified, > this will work on shared memory/mmap'ed files without needing a > special system call to guaranteee lock coherency. >From my old system 5 reference (when the OS used swapping rather than paging): plock(2) - lock process, text, or data in memory #include int plock( int op ); Plock allows the calling process to lock its text segment, its data segment, or both into memory. Locked segments are immue to all routine swapping. Plock also allows these segments to unlocked. The effective user ID of the calling process must be super-user. OP is one of: PROCLOCK - lock text and data TXTLOCK - lock text DATLOCK - lock data UNLOCK - remove locks Dave Bodenstab imdave@mcs.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 09:58:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12252 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 09:58:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12236; Wed, 1 Jul 1998 09:58:50 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id MAA15694; Wed, 1 Jul 1998 12:58:21 -0400 (EDT) (envelope-from luoqi) Date: Wed, 1 Jul 1998 12:58:21 -0400 (EDT) From: Luoqi Chen Message-Id: <199807011658.MAA15694@lor.watermarkgroup.com> To: thorpej@nas.nasa.gov, tlambert@primenet.com Subject: Re: Unsupport calls Cc: freebsd-questions@FreeBSD.ORG, hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 30 Jun 1998 23:04:07 +0000 (GMT) > Terry Lambert wrote: > > > Not really. The distinction drawn between user data and metadata is > > useless in the face of a technology like soft updates. > > ...and not only does POSIX not define softupdates, but who says you're > using a UFS-like file system, anyhow? But who says you can't apply soft updates technology to other file systems :) > > This is just another case of POSIX adding insult to injury, to no > > real benefit for anyone. > > ...and this insults you how? I think you're taking it way too seriously :-) > > Jason R. Thorpe thorpej@nas.nasa.gov > NASA Ames Research Center Home: +1 408 866 1912 > NAS: M/S 258-5 Work: +1 650 604 0935 > Moffett Field, CA 94035 Pager: +1 650 428 6939 -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 10:28:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17872 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 10:28:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17817 for ; Wed, 1 Jul 1998 10:27:58 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id KAA20844; Wed, 1 Jul 1998 10:27:15 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma020840; Wed Jul 1 10:26:57 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id KAA10777; Wed, 1 Jul 1998 10:26:56 -0700 (PDT) From: Archie Cobbs Message-Id: <199807011726.KAA10777@bubba.whistle.com> Subject: Re: Anyone interested in an "interesting" project idea? In-Reply-To: <11704.899261964@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 30, 98 07:59:24 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 1 Jul 1998 10:26:56 -0700 (PDT) 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 Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard writes: > typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t; Hmm.. it may be worth reading, e.g., the papers from the Sprite project (headed by John Osterhout) on their process migration system where process would dynamically move from host to host to balance out the load. Bottom line: it was very complicated and messy. What you're suggesting is not nearly as complicated (no migration of processes) but is likely to touch many of the same issues... and these are issues that others have confronted before. "Those who ignore history are condemned to repeat it." :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 11:22:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26482 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 11:22:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26466 for ; Wed, 1 Jul 1998 11:22:27 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA21392; Wed, 1 Jul 1998 11:22:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd021324; Wed Jul 1 11:22:19 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA29206; Wed, 1 Jul 1998 11:22:16 -0700 (MST) From: Terry Lambert Message-Id: <199807011822.LAA29206@usr01.primenet.com> Subject: Re: mlock()/mclear (was Re: Unsupport calls) To: dbj@iglou.com (David E. Brooks Jr) Date: Wed, 1 Jul 1998 18:22:15 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "David E. Brooks Jr" at Jun 30, 98 07:32:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It is trivial to implement p/v semaphores using __asm__ to generate > > single instruction spinlocks; since the VM/buffer cache is unified, > > this will work on shared memory/mmap'ed files without needing a > > special system call to guaranteee lock coherency. > > Funny you should mention this. I was poking around the man page to > mmap() the other day looking for any hints on a "standard" way to > perform inter-process synchronization when sharing memory. This led > me to read the 'newvm' paper, specifically about > mlock()/mclear(). Well, to make a short story even shorter, I ended up > having a brief e-mail exchange with David Greenman where he said in my > mail batch this morning "...a bright beginner could tackle it." > > So, I figured I'd try and find out how bright I really am . Look at the SMP locking code; it handles all of this. Specifically, look at the big giant kernel reentrancy lock. > I haven't gotten very far (I'm re-reading relevant portions of _The > Design and Implementation of 4.4 BSD Operating System_ and lots of > stuff in section 9 right now), but I do have one question right off > the bat. Both mmap(2) and the newvm paper make mention of the > MAP_HASSEMAPHORE flag; Why is (or was) this necessary? All that comes > to mind is multi-processor systems and keeping any copies of that > page of memory synchronized. SMP synchornization is automatic, via IPI (Inter Processor Interrupt) as part of the APIC (Advanced Programmable Interrupt Controller) that is built into the CPU. Intel supports full MESI cache coherence. The place you need MAP_HASSEMAPHORE is when you need to take action to synchronize the memory. For example, the multiprocessor BeBox (and most SMP capable Apple PPC hadrware not running the PPC620) designs remove the L2 cache, and use the cache notification lines for coherency signalling. This is an MEI, not a MESI implementation. Because of this, memory that is shared between processors has to be updated like so in order to ensure cache invalidation: 1) Get a mapping for the memory 2) Mark it non-writeable 3) Take the write fault 4) Do the operation anyway (in the trap handler, using a lookaside) 5) Assert the "L2 cache changed" to invalidate the L1 cache on the other processor(s). For a non-unified VM and buffer cache, it means that you must echo the changes between the buffer cache and the VM immediately. In general, you use the same trick. For many System V shared memory (and for BSD's without a unified cache), you would use the MAP_HASSEMAPHORE flag to notify the kernel. This lets the kernel be lazy (ie: it late binds the updates from the VM to the buffer cache, and vice versa), unless it has no choice in the matter, which is much less expensive. You can actually look at the 386 support code for kernel write faults; the "copyout" function (called from uiomove) has to do similar juggling in order to cause a SEGV if the user space page it is copying out to is not present. This is because you can't get a write fault on a 386 in kernel (supervisor) mode for an unwriteable page. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 11:49:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29699 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 11:49:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29688 for ; Wed, 1 Jul 1998 11:49:12 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id OAA20478; Wed, 1 Jul 1998 14:46:22 -0400 (EDT) Date: Wed, 1 Jul 1998 14:46:22 -0400 (EDT) From: "Larry S. Lile" To: hackers@FreeBSD.ORG Subject: Problems with irq 9(2)? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anybody know if there are problems with interrupt blocking when using interrupt 9(2)? I am having problems with my token ring card getting into a user blocked interrupt state and cannot figure out what to do. This is really screwing up my token ring driver development. Any ideas? Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 12:11:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03682 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 12:11:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03666 for ; Wed, 1 Jul 1998 12:11:24 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00908; Wed, 1 Jul 1998 12:10:47 -0700 (PDT) Message-Id: <199807011910.MAA00908@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Larry S. Lile" cc: hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-reply-to: Your message of "Wed, 01 Jul 1998 14:46:22 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 12:10:46 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Does anybody know if there are problems with interrupt blocking > when using interrupt 9(2)? I am having problems with my token > ring card getting into a user blocked interrupt state and cannot > figure out what to do. This is really screwing up my token > ring driver development. Larry; I meant to get back to you on this earlier, but your previous message is still buried. The short answer is that you can't "block" ISA interupts, so the problem you're seeing has to be related to how you're talking to the card. The only confirmation of interrupt delivery that the card will ever get has to come from your code. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 12:23:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05829 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 12:23:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05823 for ; Wed, 1 Jul 1998 12:23:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00970; Wed, 1 Jul 1998 12:22:59 -0700 (PDT) Message-Id: <199807011922.MAA00970@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: zhihuizhang cc: hackers Subject: Re: Interrupt Handling and inline assembly In-reply-to: Your message of "Mon, 29 Jun 1998 14:42:25 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 12:22:58 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I got two questions: > > (1) I read in the MailingList Archive that the interrupt blocking in > FreeBSD is software-based, we do not communicate with 8259 (which I think > is slower) What is the advantage of doing this besides being faster? If > we mask interrupts off (by cli or setting the IMR register in 8259), will > interrupts be simply discarded (the device has to request interrupt > again) or postponed by 8259? The interrupt mask is manipulated much more often than interrupts are taken, so it makes sense to optimise for this case. Interrupts are always enabled, so the interrupt handler is always called. If the interrupt is masked, the fact that the interrupt was invoked is recorded (see ipending) and the handler returns. When interrupt(s) are unmasked, a check is made to see if any pending interrupts can now be serviced. If interrupts are disabled by cli, they will be delivered at sti. What happens with the 8259 depends on how you disable it. > (2) I am reading the source code in cpufunc.h: > > static __inline void > setbits(volatile unsigned * addr, u_int bits) > { > __asm __volatile("orl %1, %0" : "=m" (*addr): "ir"(bits)); > } > > I have read a text on inline assembly at: > > http://www.rt66.com/~brennan/djgpp/djgpp_asm.html > > But I still do not understand the meaining of "m" and "ir". The gcc info page has more detail. `m' A memory operand is allowed, with any kind of address that the machine supports in general. `r' A register operand is allowed provided that it is in a general register. `i' An immediate integer operand (one with constant value) is allowed. This includes symbolic constants whose values will be known only at assembly time. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 12:32:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07340 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 12:32:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from aaka.3skel.com (aaka.3skel.com [207.240.212.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07265 for ; Wed, 1 Jul 1998 12:32:06 -0700 (PDT) (envelope-from danj@3skel.com) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by aaka.3skel.com (8.8.5/8.8.2) with ESMTP id PAA04807; Wed, 1 Jul 1998 15:32:05 -0400 (EDT) Received: from localhost (danj@localhost) by fnur.3skel.com (8.8.8/8.8.2) with SMTP id PAA01772; Wed, 1 Jul 1998 15:32:04 -0400 (EDT) Date: Wed, 1 Jul 1998 15:32:04 -0400 (EDT) From: Dan Janowski To: John Polstra cc: hackers@FreeBSD.ORG Subject: Re: Load avg 0.33 and 99.2% idle... In-Reply-To: <199805290012.RAA13242@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I know this is really old: asclock was the cause of my high load average. I axed it's all better. It was installed from the 2.2.6-RELEASE dist. Thanks, Dan On Thu, 28 May 1998, John Polstra wrote: > In article , > Dan Janowski wrote: > > > > The odd part is that I hadn't noticed this before. I > > just upgraded to 2.2.6 from 2.2.1. Maybe it's X or some > > other daemon that is running differently. > > The "asclock" program is the usual offender. Take a peek at its > source code and you'll see why. :-O > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Self-knowledge is always bad news." -- John Barth > -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 13:01:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11519 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 13:01:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11492 for ; Wed, 1 Jul 1998 13:01:29 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id PAA21654; Wed, 1 Jul 1998 15:58:28 -0400 (EDT) Date: Wed, 1 Jul 1998 15:58:26 -0400 (EDT) From: "Larry S. Lile" To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-Reply-To: <199807011910.MAA00908@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Jul 1998, Mike Smith wrote: > > > > Does anybody know if there are problems with interrupt blocking > > when using interrupt 9(2)? I am having problems with my token > > ring card getting into a user blocked interrupt state and cannot > > figure out what to do. This is really screwing up my token > > ring driver development. > > Larry; I meant to get back to you on this earlier, but your previous > message is still buried. > > The short answer is that you can't "block" ISA interupts, so the > problem you're seeing has to be related to how you're talking to the > card. The only confirmation of interrupt delivery that the card will > ever get has to come from your code. I thought that was the entire purpose behind splxxx(), It held off the 8259's until the kernel could process the next interrupt. *confused* Anyway, the card has a register (isrp) that has a bit that shows whether or not the card can interrrupt the 8259 on its irq line. This works for the first interrupt but as soon as I enter an spl loop that bit goes high, saying he can't interrupt, and never drops even after exiting the spl loop. Maybe I am confused about how 8259's work, it has been a long time since I played with that level of the machine, and then it was only for college class under dos. Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 13:10:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12896 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 13:10:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12879 for ; Wed, 1 Jul 1998 13:10:11 -0700 (PDT) (envelope-from jabley@clear.co.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.9) with ESMTP id IAA13213; Thu, 2 Jul 1998 08:09:41 +1200 (NZST) Received: from localhost (jabley@localhost) by buddha.clear.net.nz (8.8.8/8.8.8) with SMTP id IAA02124 for ; Thu, 2 Jul 1998 08:09:39 +1200 (NZST) (envelope-from jabley@clear.co.nz) Date: Thu, 2 Jul 1998 08:09:39 +1200 (NZST) From: Joe Abley X-Sender: jabley@buddha.clear.net.nz To: freebsd-hackers@FreeBSD.ORG Subject: pthreads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, Does anybody know the background of posix thread support in FreeBSD? I can't seem to find any docs on the background anywhere... I'm interested in a couple of issues. 1. On Solaris, to compile a pthreaded program, I stick a #define _REENTRANT #include at the top of the source files, and link with -lpthread. With FreeBSD the linking phase is more involved, since I need to exclude the standard C libraries and link with libc_r instead. Why was the decision made to support pthreads in this manner? What benefits does this have over the Solaris way of doing things? 2. Should I really be using the 2.2.6-RELEASE libc_r pthread support, or should I be looking at Chris Provenzano's pmpthreads? I'm by no means any kind of expert on posix threads; I've just been working on some code which compiled but refused to run properly on FreeBSD. Moving the code to Solaris (and removing all the nice BSD networking code which Sun have seen fit not to support on Solaris), it compiled and worked fine, no problems. I'm not asking for help with my code... Just some pointers on the history of pthread support in FreeBSD. Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 13:14:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13846 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 13:14:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13839 for ; Wed, 1 Jul 1998 13:14:54 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id QAA44688 for ; Wed, 1 Jul 1998 16:14:54 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <13617.899298865@time.cdrom.com> References: Your message of "Wed, 01 Jul 1998 10:49:55 +0200." <199807010849.KAA25121@surf.IAE.nl> Date: Wed, 1 Jul 1998 16:18:44 -0400 To: hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:14 AM -0700 7/1/98, Jordan K. Hubbard wrote: >> I've had some discussion with Terry about this, and one of the "options" >> would be to include the *env pointer into the u-area, such that we know >> where the user keeps his env. > > Well, just don't forget that the setenv() code in libc can change the > value of environ at any time with a realloc(), so if you're going > to copy it into the u_area you're also going to have to keep this copy > in sync unless you also had plans on replacing environ. :) My initial reaction is that I wouldn't want links to depend on values in environment variables. If I setup some "clean environment" for a program I'm exec-ing, I'm not going to think to copy values which are important for these links to work. So there's two questions. One is how to you make sure you're looking at the correct & current environment, and the other is how do you know that that environment (once you find it) includes all the symbolic- link-related variables (and values) which will be expected. I'd put the variables used in symbolic links somewhere else, some new place. I just don't see symbolic links as being something which would or should be quite as dynamic as user-level environment variables. It just seems to me that symbolic links are "lower level" than the environment values for the active user-level program. Just my 2 cents on the idea. Note that my thinking may be influenced by the fact that I'm used to working with AFS's @sys variable. I keep thinking how easy it would be for a user to happen to pick a simple name like "sys" for an environment variable in some script, and what absolute havoc that would cause if they did it in our filesystem setup... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 14:02:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21032 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:02:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from eh.est.is (root@eh.est.is [194.144.208.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21023 for ; Wed, 1 Jul 1998 14:02:23 -0700 (PDT) (envelope-from totii@est.is) Received: from gateway.toti.est.is (root@toti.est.is [194.144.208.200]) by eh.est.is (8.8.5/8.8.7) with ESMTP id VAA12004; Wed, 1 Jul 1998 21:01:53 GMT (envelope-from totii@est.is) Received: from didda.toti.est.is ([192.168.255.22]) by gateway.toti.est.is (8.8.7/8.8.7) with ESMTP id VAA08676; Wed, 1 Jul 1998 21:03:29 GMT (envelope-from totii@est.is) Message-ID: <359A95A3.7188625A@est.is> Date: Wed, 01 Jul 1998 21:01:39 +0100 From: "=?iso-8859-1?Q?=DE=F3r=F0ur=20=CDvarsson?=" X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "Larry S. Lile" CC: hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? X-Priority: 3 (Normal) References: 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 OAA21028 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Larry S. Lile wrote: > > Does anybody know if there are problems with interrupt blocking > when using interrupt 9(2)? I am having problems with my token > ring card getting into a user blocked interrupt state and cannot > figure out what to do. This is really screwing up my token > ring driver development. > > Any ideas? I am not sure what is going on, but, IRQ 9/2 is often used by vga adapters, if you have ISA vga adapter then the trouble can be orginated there. Vga cards used IRQ2/9 for some retrace call. Þórður Ívarsson thivars@est.is To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 14:05:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21470 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:05:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iglou.com (sendmail@iglou2.iglou.com [192.107.41.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21452 for ; Wed, 1 Jul 1998 14:05:32 -0700 (PDT) (envelope-from dbj@iglou.com) Received: from lou-ts8-22.iglou.com ([204.255.238.185] helo=localhost) by iglou.com with smtp (8.7.3/8.6.12) id 0yrU46-0000Ci-00; Wed, 1 Jul 1998 17:05:19 -0400 Date: Wed, 1 Jul 1998 17:05:42 -0400 (EDT) From: "David E. Brooks Jr" X-Sender: dbj@localhost To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: mlock()/mclear (was Re: Unsupport calls) In-Reply-To: <199807011822.LAA29206@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Jul 1998, Terry Lambert wrote: > > > It is trivial to implement p/v semaphores using __asm__ to generate > > > single instruction spinlocks; since the VM/buffer cache is unified, > > > this will work on shared memory/mmap'ed files without needing a > > > special system call to guaranteee lock coherency. > > > > Funny you should mention this. I was poking around the man page to > > mmap() the other day looking for any hints on a "standard" way to > > perform inter-process synchronization when sharing memory. This led > > me to read the 'newvm' paper, specifically about > > mlock()/mclear(). Well, to make a short story even shorter, I ended up > > having a brief e-mail exchange with David Greenman where he said in my > > mail batch this morning "...a bright beginner could tackle it." > > > > So, I figured I'd try and find out how bright I really am . > > Look at the SMP locking code; it handles all of this. Specifically, > look at the big giant kernel reentrancy lock. > > > I haven't gotten very far (I'm re-reading relevant portions of _The > > Design and Implementation of 4.4 BSD Operating System_ and lots of > > stuff in section 9 right now), but I do have one question right off > > the bat. Both mmap(2) and the newvm paper make mention of the > > MAP_HASSEMAPHORE flag; Why is (or was) this necessary? All that comes > > to mind is multi-processor systems and keeping any copies of that > > page of memory synchronized. > > SMP synchornization is automatic, via IPI (Inter Processor Interrupt) > as part of the APIC (Advanced Programmable Interrupt Controller) that > is built into the CPU. Intel supports full MESI cache coherence. > > The place you need MAP_HASSEMAPHORE is when you need to take action > to synchronize the memory. [A lot of Terry's informative dissertation trimmed for space] Then (if I'm digesting this correctly) what you're saying is the MAP_HASSEMAPHORE flag isn't necessary under FreeBSD because the kernel already keeps everything nice and synchronized because of the unified VM and buffer caches, right? BTW, I misspoke when I originally was talking about mlock()/mclear(). I meant mset()/mclear() (and their associates msleep() and mwakeup()), which are the partially user mode semaphores I'm looking into implementing for FreeBSD (they're described in newvm paper in /usr/share/doc/papers and 4.4 BSD design book). It goes to show that NyQuil and thinking don't mix...Sorry if I confused anyone. Oh, when I do start to actually work on this, who do I need to coordinate with? -- Dave -- David E. Brooks Jr dbj@iglou.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 14:12:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23000 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:12:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22946 for ; Wed, 1 Jul 1998 14:12:19 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id RAA22580; Wed, 1 Jul 1998 17:09:19 -0400 (EDT) Date: Wed, 1 Jul 1998 17:09:18 -0400 (EDT) From: "Larry S. Lile" To: =?iso-8859-1?Q?=DE=F3r=F0ur=20=CDvarsson?= cc: hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-Reply-To: <359A95A3.7188625A@est.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Jul 1998, =?iso-8859-1?Q?=DE=F3r=F0ur=20=CDvarsson?= wrote: > Larry S. Lile wrote: > > > > Does anybody know if there are problems with interrupt blocking > > when using interrupt 9(2)? I am having problems with my token > > ring card getting into a user blocked interrupt state and cannot > > figure out what to do. This is really screwing up my token > > ring driver development. > > > > Any ideas? > I am not sure what is going on, but, IRQ 9/2 is often used by vga > adapters, if you have ISA vga adapter then the trouble can be orginated > there. Vga cards used IRQ2/9 for some retrace call. I'm using a #9 Motion 771 video card (PCI) > vga0: rev 0x00 int a irq 10 on pci0.11.0 so I am not sure that would be causing this problem. But then again I don't know. I am going to try moving to int 3, after disabling the serial ports, and see if it works better. It will get me off the cascaded 8259 and the broken vga interrupt hack, if that's what it is. Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 14:18:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24179 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 14:18:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24139 for ; Wed, 1 Jul 1998 14:17:56 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA22239; Wed, 1 Jul 1998 14:17:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd022214; Wed Jul 1 14:17:50 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA15402; Wed, 1 Jul 1998 14:17:47 -0700 (MST) From: Terry Lambert Message-Id: <199807012117.OAA15402@usr05.primenet.com> Subject: Re: mlock()/mclear (was Re: Unsupport calls) To: dbj@iglou.com (David E. Brooks Jr) Date: Wed, 1 Jul 1998 21:17:47 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "David E. Brooks Jr" at Jul 1, 98 05:05:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Then (if I'm digesting this correctly) what you're saying is the > MAP_HASSEMAPHORE flag isn't necessary under FreeBSD because the kernel > already keeps everything nice and synchronized because of the unified > VM and buffer caches, right? And the automatic cache coherency of the software. But like using msync() on FreeBSD, MAP_HASSEMAPHORE is *not* optional on other platforms, and correct code will use it (as correct code on other platforms will use msync(); INN was a disaster for a long time in this regard). > BTW, I misspoke when I originally was talking about mlock()/mclear(). > I meant mset()/mclear() (and their associates msleep() and mwakeup()), > which are the partially user mode semaphores I'm looking into > implementing for FreeBSD (they're described in newvm paper in > /usr/share/doc/papers and 4.4 BSD design book). > > It goes to show that NyQuil and thinking don't mix...Sorry if I > confused anyone. the sleep and wakeup functions need to be kernel coordinated, as do the set/clear in the case of a 0->1, 1->0 transition resulting in an "event" that results in a wakeup. These can be proxies for tsleep()/wakeone(), actually, with whatever appropriate base memory address trickery to keep the tsleep out of collision with other tsleep calls in the kernel itself. > Oh, when I do start to actually work on this, who do I need to > coordinate with? I believe David Greenman is the correct person for VM related issues, now that John Dyson has left the project. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:31:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04779 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:31:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04764 for ; Wed, 1 Jul 1998 15:31:00 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id IAA01186; Thu, 2 Jul 1998 08:41:52 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199807012241.IAA01186@cimlogic.com.au> Subject: Re: pthreads In-Reply-To: from Joe Abley at "Jul 2, 98 08:09:39 am" To: jabley@clear.co.nz (Joe Abley) Date: Thu, 2 Jul 1998 08:41:52 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Abley wrote: > #define _REENTRANT > #include If 2.2.X: #define _THREAD_SAFE #include If 3.0: #include > at the top of the source files, and link with -lpthread. With FreeBSD the > linking phase is more involved, since I need to exclude the standard C > libraries and link with libc_r instead. The thread code was first added to 3.0-current and was merged back to the 2.2 tree without the gcc change that added the -pthread argument which selects the libraries properly. > > Why was the decision made to support pthreads in this manner? I wasn't allowed to destablize libc. > What > benefits does this have over the Solaris way of doing things? I doubt there are any. > > 2. Should I really be using the 2.2.6-RELEASE libc_r pthread support, or > should I be looking at Chris Provenzano's pmpthreads? You haven't said what FreeBSD version you're running. Since the 2.2.6 release there have been a few fixes for boundary conditions like reading and writing zero bytes, etc. > I'm by no means any kind of expert on posix threads; I've just been > working on some code which compiled but refused to run properly on > FreeBSD. Moving the code to Solaris (and removing all the nice BSD > networking code which Sun have seen fit not to support on Solaris), it > compiled and worked fine, no problems. If you can isolate the problem with a test program, please send me the test code. Remember that the code in libc_r is a user-space implementation so it is easy for application code to interfere with the operation of the thread library. The worst cases of this that I've seen are those that use GNU configure scripts that incorrectly choose options. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:35:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05272 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:35:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05255; Wed, 1 Jul 1998 15:34:58 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA25448; Wed, 1 Jul 1998 15:34:51 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd025418; Wed Jul 1 15:34:47 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA23763; Wed, 1 Jul 1998 15:34:35 -0700 (MST) From: Terry Lambert Message-Id: <199807012234.PAA23763@usr07.primenet.com> Subject: Re: Unsupport calls To: thorpej@nas.nasa.gov Date: Wed, 1 Jul 1998 22:34:34 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG In-Reply-To: <199806302301.QAA29682@lestat.nas.nasa.gov> from "Jason Thorpe" at Jun 30, 98 04:01:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is just another case of POSIX adding insult to injury, to no > > real benefit for anyone. > > ...and this insults you how? I think you're taking it way too seriously :-) On the theory that, having passed through a committee, standards are somehow ennobled, and none dare criticize them. Arguing based on that theory insults your intelligence. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06502 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:40:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06478 for ; Wed, 1 Jul 1998 15:40:53 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA00776; Wed, 1 Jul 1998 15:40:48 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd000759; Wed Jul 1 15:40:47 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA24131; Wed, 1 Jul 1998 15:40:40 -0700 (MST) From: Terry Lambert Message-Id: <199807012240.PAA24131@usr07.primenet.com> Subject: Re: Adding a new user interface to FreeBSD administration To: fullermd@futuresouth.com (Matthew D. Fuller) Date: Wed, 1 Jul 1998 22:40:39 +0000 (GMT) Cc: mike@smith.net.au, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19980630181153.08867@futuresouth.com> from "Matthew D. Fuller" at Jun 30, 98 06:11:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > linux(enabled) = YES > > > > linux(doc) = { This variable controls whether linux emulation support > > > > will be automatically loaded at startup. You can also do it manually > > > > with the /usr/bin/linux command. } > > > > linux(exec-command) = "linux > /dev/null 2>&1" > > > > > > OK, so what's wrong with a simple /etc/rc.conf script that looks > > > something like: > > > > It doesn't scale. > > I don't see how. > Unless there's a limit (that we're likely to reach) on how long a shell > variable can be. I'm sure there is, but I'm not sure if it's low enough > that we're likely to hit it on a bootup sequence. It doesn't scale because it's a linearly exponential increase in overhead for the programs that source it as they search linearly through the name space for variables which might apply to them. It's also insufficiently dynamic, insufficiently hierarchical, and the interface is insufficiently abstact. The point of an abstract interface is to hide complexity. This doesn't hide complexity of greater than O(1). > I mean, it's the same way Jordan was going with a 'registry', except > thrown into a script. I can see it getting a little unwieldy at extreme > sizes, but then again, there's only so much you're really going to be > DOING on bootup. It's not just for booting. Consider the case of wanting to restart amd, for example. Your script would have to source all of rc.conf (or whatever you called it). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:44:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07120 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:44:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07115 for ; Wed, 1 Jul 1998 15:44:28 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA24866; Wed, 1 Jul 1998 15:44:14 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd024844; Wed Jul 1 15:44:08 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA24247; Wed, 1 Jul 1998 15:44:05 -0700 (MST) From: Terry Lambert Message-Id: <199807012244.PAA24247@usr07.primenet.com> Subject: Re: Adding a new user interface to FreeBSD administration To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 1 Jul 1998 22:44:05 +0000 (GMT) Cc: fullermd@futuresouth.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <10970.899248855@time.cdrom.com> from "Jordan K. Hubbard" at Jun 30, 98 04:20:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1. If you want to write a nifty editor for it, you have to now have > _rules_ for clumping all the mountd_foo variables together in > such a way that all "mountd attributes" are editable in a common > block. And this is where vi editable textual configurations fail. We see this in gated, and we see it again in bind 8.x. > 2. This does not deal *explicitly* with ordering issues unless it will > be very well documented that the order in which startup commands are > specified must be maintained (and then, of course, the aformentioned > editor has another thing to remember in writing things back out). > This would be true in your example since portmap, for one, needs to > be run before mountd. Every time I use the ordering example, a friend of mine laughs and points at the "make" program, which was build specifically yto resolve ordered dependency issues. I wouldn't suggest using make for this myself (mostly because then some idiot would insist on it being liked static). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:46:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07540 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:46:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07512 for ; Wed, 1 Jul 1998 15:46:33 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA29433; Wed, 1 Jul 1998 15:46:31 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd029403; Wed Jul 1 15:46:25 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA24394; Wed, 1 Jul 1998 15:46:16 -0700 (MST) From: Terry Lambert Message-Id: <199807012246.PAA24394@usr07.primenet.com> Subject: Re: Adding a new user interface to FreeBSD administration To: mike@smith.net.au (Mike Smith) Date: Wed, 1 Jul 1998 22:46:16 +0000 (GMT) Cc: fullermd@futuresouth.com, mike@smith.net.au, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807010002.RAA08758@dingo.cdrom.com> from "Mike Smith" at Jun 30, 98 05:02:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > It doesn't scale. > > I don't see how. > > You can't use the same information as a template for more than one > system. You also can't validate the value of a field against the values of all other fields it interacts with... not can you associate the validation code with the name/value pairs in the subschema. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 15:55:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA09123 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 15:55:50 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09117 for ; Wed, 1 Jul 1998 15:55:46 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA01785; Wed, 1 Jul 1998 15:54:29 -0700 (PDT) Message-Id: <199807012254.PAA01785@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Larry S. Lile" cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-reply-to: Your message of "Wed, 01 Jul 1998 15:58:26 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 15:54:29 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Wed, 1 Jul 1998, Mike Smith wrote: > > > > > > > Does anybody know if there are problems with interrupt blocking > > > when using interrupt 9(2)? I am having problems with my token > > > ring card getting into a user blocked interrupt state and cannot > > > figure out what to do. This is really screwing up my token > > > ring driver development. > > > > Larry; I meant to get back to you on this earlier, but your previous > > message is still buried. > > > > The short answer is that you can't "block" ISA interupts, so the > > problem you're seeing has to be related to how you're talking to the > > card. The only confirmation of interrupt delivery that the card will > > ever get has to come from your code. > > I thought that was the entire purpose behind splxxx(), It held off > the 8259's until the kernel could process the next interrupt. *confused* No. Interrupts are never masked in the 8259 (too expensive). But even if they were, your card has no way of knowing what has happened to the interrupt. > Anyway, the card has a register (isrp) that has a bit that shows whether > or not the card can interrrupt the 8259 on its irq line. This works for > the first interrupt but as soon as I enter an spl loop that bit goes > high, saying he can't interrupt, and never drops even after exiting the > spl loop. The ISA interrupt protocol is one-sided, so there's no way that it could know anything about whether it can or can't interrupt. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 16:11:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11825 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 16:11:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11763 for ; Wed, 1 Jul 1998 16:11:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (brian@localhost [127.0.0.1]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id TAA18050; Wed, 1 Jul 1998 19:34:30 +0100 (BST) (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199807011834.TAA18050@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: Didier Derny cc: Brian Somers , hackers@FreeBSD.ORG Subject: Re: ppp with the latest SNAPSHOT (may) In-reply-to: Your message of "Wed, 01 Jul 1998 10:38:50 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Jul 1998 19:34:29 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 1 Jul 1998, Brian Somers wrote: > > > > > > > user ppp worked fine for years but after having changed my mother board/ > > > upgraded to the latest snapshot it is not working anymore > > > > > > as I did both operation at the same time I dont know if the problem > > > comes from the mother board or user ppp. > > > > > > the mother board is an Asus P2B (chipset BX) > > > > > > do you have any clue ? > > > > No. You'll need to explain what ``doesn't work'' means :-( My car > > doesn't work. Do you have any idea what's wrong with it ? > > > > > thanks for your help > > > > > As everything worked fine before, I only thought that there was a known > problem either with the lastest snapshot or with the ASUS P2B motherboard. > > In fact, it dial, the provider's modem answers, apparently, ppp and the > provider are chatting permanently with any success. > > it seems unable to set the ip adresses Do you have a line saying ``set ifaddr 0 0'' in your config ? What snapshot are you talking about - is it a 2.2 snapshot that was created just after 2.2.6-release ? If the answer to both of these questions is ``yes'' then either change the line to read ``set ifaddr 0 0/0'' or upgrade to a later snapshot. If either of the answers are ``no'' you'll really have to supply some information (check http://www.FreeBSD.org/FAQ/userppp.html for how to provide logs). > I have the same problem with two different providers > so, it does not come from the provider side. > > > Thanks for your help > > -- > Didier Derny > didier@omnix.net -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 16:18:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13684 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 16:18:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13618 for ; Wed, 1 Jul 1998 16:18:02 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA13184; Wed, 1 Jul 1998 16:17:49 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd013131; Wed Jul 1 16:17:46 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA25913; Wed, 1 Jul 1998 16:17:42 -0700 (MST) From: Terry Lambert Message-Id: <199807012317.QAA25913@usr07.primenet.com> Subject: Re: Variant Link implementation, continued To: wjw@surf.IAE.nl (Willem Jan Withagen) Date: Wed, 1 Jul 1998 23:17:42 +0000 (GMT) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199807010849.KAA25121@surf.IAE.nl> from "Willem Jan Withagen" at Jul 1, 98 10:49:55 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 Precedence: bulk X-Loop: FreeBSD.ORG > Just look for the Apollo FAQ and see why I'm chasing this one down. > :-D. I just loved my Domain babies. > > [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( > ]] If only you had a block tape device... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 16:38:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16444 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 16:38:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA16366 for ; Wed, 1 Jul 1998 16:38:02 -0700 (PDT) (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.8/8.8.8) with ESMTP id QAA15327; Wed, 1 Jul 1998 16:37:33 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Archie Cobbs cc: hackers@FreeBSD.ORG Subject: Re: Anyone interested in an "interesting" project idea? In-reply-to: Your message of "Wed, 01 Jul 1998 10:26:56 PDT." <199807011726.KAA10777@bubba.whistle.com> Date: Wed, 01 Jul 1998 16:37:33 -0700 Message-ID: <15323.899336253@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Jordan K. Hubbard writes: > > typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t; > > Hmm.. it may be worth reading, e.g., the papers from the Sprite > project (headed by John Osterhout) on their process migration system > where process would dynamically move from host to host to balance > out the load. I have. :-) I used to work just 4 floors down from John in the same building, and one evening I wandered up there and had a stack of sprite documentation literally 2 feet high bestowed upon me by one of the grad students working on it. I read through most of it and was favorably impressed by much of what they'd done but, as you already correctly surmise, it was quite complicated. What I'm suggesting is very deliberately limited in scope. Again, I'm not trying to achieve "true clustering", simply trying to make one aspect of administration more transparent. What Ron has also suggested with his shared /proc paradigm looks interesting, though I'm not sure if I'd want to look at all the nodes in my cluster by matching a wildcard expression on some number of remote /procs. :) I think simplicity and minimum change to existing services is the key here in making incremental improvements to FreeBSD's support [various] shared resources. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 16:39:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16565 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 16:39:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA16556; Wed, 1 Jul 1998 16:39:34 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA17268; Wed, 1 Jul 1998 16:39:30 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd017181; Wed Jul 1 16:39:22 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA27019; Wed, 1 Jul 1998 16:39:17 -0700 (MST) From: Terry Lambert Message-Id: <199807012339.QAA27019@usr07.primenet.com> Subject: Re: Unsupport calls To: imdave@mcs.net (Dave Bodenstab) Date: Wed, 1 Jul 1998 23:39:17 +0000 (GMT) Cc: hackers@FreeBSD.ORG, tlambert@primenet.com, freebsd-questions@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com In-Reply-To: <199807011642.LAA07192@base486.home.org> from "Dave Bodenstab" at Jul 1, 98 11:42:23 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 Precedence: bulk X-Loop: FreeBSD.ORG > > > About the only serious one I can see is plock. Maybe somebody else on > > > the list can comment. > > From my old system 5 reference (when the OS used swapping rather than > paging): > > plock(2) - lock process, text, or data in memory > > #include > int plock( int op ); > > Plock allows the calling process to lock its text segment, its > data segment, or both into memory. Locked segments are immue to > all routine swapping. Plock also allows these segments to > unlocked. The effective user ID of the calling process must be > super-user. OP is one of: > > PROCLOCK - lock text and data > TXTLOCK - lock text > DATLOCK - lock data > UNLOCK - remove locks I forgot this old saw. This was from back in SVR2, before the PMMU hit System V. I can see something being slightly faster because of this, but I think that rtprio will do some of it. Traditionally in BSD, this was handled on a per image basis, using the "sticky bit". Of course, the flip side is that by doing this for your process, you may be starving other processes of resources, causing them to thrash, and thereby consume more quantum. Which, of course, would result in you getting scheduled less often. Which would mean that your program wouldn't be faster. In general, this type of soloution, and things like fixed scheduling classes (which SVR4.2/UnixWare 2.x use to "protect" the interactive response of the X server -- the X server is guaranteed a fixed amount of the available quanta) are a kludge to deal with the fact that there aren't working-set quotas. The corresponding behaviour of the UnixWare 2.x X server is that the X server pages still gets thrashed out to disk by the linker, but the X sever burns a fair amount of your CPU thrashing them back in to guarantee that the mouse handling code is there when you wiggle your mouse. So while this may be missing from FreeBSD, it's not really a bad thing, I think (except that FreeBSD also lacks working-set quotas, which should be implemented as LRU page stealing from your own page list on a per vnode basis -- NOT vnodes being used as swap for executable pages! -- at a minimum). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 16:57:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18467 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 16:57:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18452 for ; Wed, 1 Jul 1998 16:57:48 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA20155; Wed, 1 Jul 1998 16:57:46 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd020137; Wed Jul 1 16:57:41 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA27776; Wed, 1 Jul 1998 16:57:39 -0700 (MST) From: Terry Lambert Message-Id: <199807012357.QAA27776@usr07.primenet.com> Subject: Re: Code Logic Question in 2.2 RELENG To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Wed, 1 Jul 1998 23:57:38 +0000 (GMT) Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807011017.DAA05610@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jul 1, 98 03:17:06 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 Precedence: bulk X-Loop: FreeBSD.ORG > The original signal() implementation reset the handler to SIG_DFL before > calling the handler, which generally required you to rearm the handler > from within the handler. System V kept this behaviour and BSD changed > it to something more sane but incompatible. Some implementations can > do bad things if you rearm the handler from within the handler. I think > the problem is if you rearm the SIGCLD/SIGCHLD handler before reaping > any waiting processes, the handler gets re-entered. Yes. Signals are persistent conditions. Arming a handler in a handler is generally bad practice, anyway, due to the obvious race conditions. Even if you do it as absolutely the last thing, there is a tiny involuntary preeemption window before the ret is executed that could cause you to reenter on the same signal stack. SystemV was technically wrong. The SIGCLD/SIGCHLD behaviour is also technically pilot error; the correct method of handling this (because of the possibility of signal stacking, is to set a flag in the handler and do the reaping in the main loop of the program after the flag is noted as having been set. > } > Ick! If you leave out a setjmp(), you'll return to the wrong place. > } > } And if I call memcpy with arguments in bcopy order, I'll get the > } wrong results, too. > } > } Bad input == bad output. I don't see your objection. > > I think this makes the code harder to maintain. If you add a new blocking > syscall and forget the setjmp(), you'll intermittently return to the > wrong place in the code, which will be difficult to debug. Forgetting > to catch EINTR is easier to track down, especially if you are careful > to check return values and errno. Depends. If the code is a call-conversion user space threads implementation, it makes it a hell of a lot easier, since the calls are restarted, and you don't partially abort a wrappered system call in a library routine. For example, with an fd lock set, but never cleared. Library routines that implement virtual system calls, which is most of them (except where idiot standards writers didn't want to dictate [correct] implementation in the face of existing [incorrect] vendor implementation), want to restart after a flag is set in the handler to indicate one or more events of that type have taken place. > } > This also prevents you from keeping variables in registers, because > } > they won't be restored when you return. > } > } What system are you running? Man setjmp(3) says: > } > } All accessible objects have values as of the time longjmp() > } routine was called, except that the values of objects of > } automatic storage invocation duration that do not have the > } volatile type and have been changed between the setjmp() > } invocation and longjmp() call are indeterminate. > > This is what I'm referring to. I just love indeterminate code ... This indeterminism was brought to you by the ANSI C X3J11 committee, who in their infinite wisdom, decided that a compiler should be able to make some bogus assumptions except where you explicitly tell it it shouldn't through the use of the "volatile" keyword to indicate a non-procedural data flow context escape may affect the variables value. This is one of the reasons I hate the ANSI C specification: you must use a keyword that didn't exist in your old code to make your old code run like it used to instead of malfunctioning. The short answer is "declare the variables 'volatile', and the compiler won't make the bogus assumptions about them". The long answer involves why "volatile" should be a function attribute instead of a variable attribute, and that external variable referenced by a function should taint the variable (the ANSI C "volatile" semantic) and the issue be resolved by a smarter linker, and code generation delayed intil inter-object dependencies of this type can be resolved. > % uname -rs > HP-UX B.10.20 > > The fine man page sez: > > Before calling the signal-catching handler, the system > signal action of sig is set to SIG_HOLD. During a normal > return from the signal-catching handler, the system signal > action is restored to func and any held signal of this type > is released. If a non-local goto (longjmp(3C)) is taken, > sigrelse() must be called to restore the system signal > action to func and release any held signal of this type. > > though on careful reading this applies to sigset(), while signal() just > sets the action back to SIG_DFL. Yes. This is rather bogus; the longjmp semantics are known to push the signal out of scope; the stack transition is easily knowable to the longjmp code, which must unwind the stack. This is a lazy lomgjmp implementation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 17:12:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21005 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 17:12:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20980 for ; Wed, 1 Jul 1998 17:12:29 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA05188; Wed, 1 Jul 1998 17:12:28 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd005163; Wed Jul 1 17:12:22 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA28590; Wed, 1 Jul 1998 17:12:19 -0700 (MST) From: Terry Lambert Message-Id: <199807020012.RAA28590@usr07.primenet.com> Subject: Re: Variant Link implementation, continued To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 2 Jul 1998 00:12:19 +0000 (GMT) Cc: wjw@surf.IAE.nl, hackers@FreeBSD.ORG In-Reply-To: <13617.899298865@time.cdrom.com> from "Jordan K. Hubbard" at Jul 1, 98 06:14:25 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 Precedence: bulk X-Loop: FreeBSD.ORG > Well, just don't forget that the setenv() code in libc can change the > value of environ at any time with a realloc(), so if you're going > to copy it into the u_area you're also going to have to keep this copy > in sync unless you also had plans on replacing environ. :) Well, technically... "extern char **environ" is not required to be updated by setenv(3). I would suggest making getenv(3)/putenv(3)/getenv(3)/unsetenv(3) operate on a lnm_ (logical name) interface, which in turn operates on a multiplex system call (lnm(LNM_GET, ...), etc.). This would effectively hang the environment off the proc struct in data pages belonging to the process but accessible to the kernel. The symbolic links could be accessed from there. This would, of course, leave things that directly reallocate environ instead of using setenv() hanging out to dry. It would also, if the variant "main(ac, av, envp)" is used, yield an envp that was, effectively, read-only. The execve() call would be left intact. I would take a NULL-valued envp argument to execve to mean "copy from parent" (the current semantic is undefined, according tot he man page; if a NULL is legal, then use (((char *)NULL) - 1) as the inheritance escape, instead. > > Now the problem pointed out by Terry is that users are allowed to do nasty > > stuff to their environment, and in the process "invalidate" the u-area *env. > > Yeah, I think it'll be enough to worry about the sanctioned functions > for scribbling on *environ like setenv() and handle the people who are > deliberately pounding on *environ with some kind of reasonable range > checking. Or let them twiddle it, but ignore them. ;-). > Hmmm. readlink() would certainly do the expansion and prevent most > legacy programs from having to even know about environment variable > expansion in syminks, the question remaining as to what you do with > variable names which are invalid or non-existant. Pass through the > unexpanded token? Eliminate the token? Return NULL? :-) My preference?: I. Look in my env II. Look in the process group leader's env III. Look in init's env IV. replace them with "" (zero length string, just as sh does). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 17:31:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24261 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 17:31:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24256 for ; Wed, 1 Jul 1998 17:31:49 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id KAA13526; Thu, 2 Jul 1998 10:01:17 +0930 (CST) Message-ID: <19980702100116.F13424@freebie.lemis.com> Date: Thu, 2 Jul 1998 10:01:16 +0930 From: Greg Lehey To: Willem Jan Withagen , jkh@time.cdrom.com, Michael Smith Cc: hackers@FreeBSD.ORG Subject: Apollo tapes (was: Variant Link implementation, continued) References: <199807010849.KAA25121@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807010849.KAA25121@surf.IAE.nl>; from Willem Jan Withagen on Wed, Jul 01, 1998 at 10:49:55AM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 1 July 1998 at 10:49:55 +0200, Willem Jan Withagen wrote: > In article you write: >>> I have actual working code for this. >>> At the moment every variantlink gets replaced by '2.2.6', since that is my >>> current OS version. >> >> That's really cool! Apollo, here we come! ;-) > > Just look for the Apollo FAQ and see why I'm chasing this one down. > :-D. I just loved my Domain babies. > > [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( What's the problem? I've heard of nightmares with Apollo tapes, and I currently have a set of Domain OS 10.4 tapes here which I need to copy (Mike, are you listening?). Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 17:53:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA28173 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 17:53:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA28155 for ; Wed, 1 Jul 1998 17:53:15 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA17822; Wed, 1 Jul 1998 17:53:15 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd017736; Wed Jul 1 17:53:05 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA01330; Wed, 1 Jul 1998 17:52:59 -0700 (MST) From: Terry Lambert Message-Id: <199807020052.RAA01330@usr07.primenet.com> Subject: Re: pthreads To: jb@cimlogic.com.au (John Birrell) Date: Thu, 2 Jul 1998 00:52:59 +0000 (GMT) Cc: jabley@clear.co.nz, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807012241.IAA01186@cimlogic.com.au> from "John Birrell" at Jul 2, 98 08:41:52 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 Precedence: bulk X-Loop: FreeBSD.ORG > > Why was the decision made to support pthreads in this manner? > > I wasn't allowed to destablize libc. > > > What > > benefits does this have over the Solaris way of doing things? > > I doubt there are any. As far as libc being thread safe at all times, I think this would be a mistake, until such time as kernel and user space cooperative scheduling was actually working. This is because a user space threaded process competes for quantum as one process against all of the other multiple process service implemetnations on your machine. It would be very easy to be out-competed for quantum without this; they you have to play priority and scheduler games just to get back up to par with the unthreaded processes. 8-(. As far as the kernel threading requirement: it's because the user space code in libc wrapping the system calls. This code adds not inconsiderable overhead, and it would be an oppressive burden to foist off on non-threaded processes not gaining benefit from the burden they would have to assume. In any case, there's *currently* a benefit in that the wrappering overhead doesn't have to be eaten by non-threads-using programs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 18:00:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29499 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 18:00:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29411 for ; Wed, 1 Jul 1998 18:00:13 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA12999; Wed, 1 Jul 1998 18:00:10 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd012954; Wed Jul 1 18:00:02 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA00880; Wed, 1 Jul 1998 17:45:00 -0700 (MST) From: Terry Lambert Message-Id: <199807020045.RAA00880@usr07.primenet.com> Subject: Re: pthreads To: jabley@clear.co.nz (Joe Abley) Date: Thu, 2 Jul 1998 00:44:59 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Joe Abley" at Jul 2, 98 08:09:39 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 Precedence: bulk X-Loop: FreeBSD.ORG > Does anybody know the background of posix thread support in FreeBSD? I > can't seem to find any docs on the background anywhere... John Birrell did a lot of hacking on Chris Provenzo's code. Someone else (I forget; sorry) did hacking to mostly bring the return codes up to the Draft 4 standard. Jeremy Allison and I hacked various bits here and there to fix ommissions here and there. John Birrell rewrote lots of it in -current, with an eye toward bringing the code up to the Draft 10 standard (the ratified standard), and he and John Dyson did a lot of work to support a kernel implementation, also in -current, using rfork() and some rather complicated stack management. John Dyson did a number of patches for CPU affinity and a number of other things, which were necessary to make a kernel implementation useful at all (so far as I know, these were distributed from his FreeBSD home directory, so they have sonce been removed from circulation. 8-(. Someone correct me if they snagged a copy before that happened and are willing to share). That's basically the abridged history of pthreads. > I'm interested in a couple of issues. > > 1. On Solaris, to compile a pthreaded program, I stick a > > #define _REENTRANT > #include > > at the top of the source files, and link with -lpthread. With FreeBSD the > linking phase is more involved, since I need to exclude the standard C > libraries and link with libc_r instead. The libc_r will be linked before the default libc. You do *not* need to exclude the standard libc. For FreeBSD, you can: #define _THREADSAFE #include This basically #define's errno to make it per-thread, and little else. This step is not necessary under -current, which unconditionally defines errno (the source of the "undefined: __error" complaints). If you add: CFLAGS+= -pthread All the library mumbo-jumbo will be done for you. > Why was the decision made to support pthreads in this manner? The difference is the name: "libpthread.a" vs. "libc_r.a". > What benefits does this have over the Solaris way of doing things? None (except in the new order of things in -current, you don't need a "#define _THREADSAFE", and sun still needs "_REENTRANT"). > 2. Should I really be using the 2.2.6-RELEASE libc_r pthread support, or > should I be looking at Chris Provenzano's pmpthreads? The 2.2.6-RELEASE libc_r pthread support is Draft 4. There are a few known bugs (mostly to do with signals -- a singla is delivered to the running thread if it hasn't masked it. You are supposed to mask the signals in all threads except the one you designate a handler for the signal in question. This is POSIX behaviour). The "Draft 4" nature of the code means that you can't statically initialize mutexes, and that the "attr" argument to "pthread_create" is the address of the address of the attr, instead of just the address; there are other subtle differences that are explained in the O'Reilly book in gory detail. Effectively, you can test for a Draft 4 using the manifest constant PTHREAD_MUTEX_INITIALIZER to enable the code to run on both Draft 10 (standard) and Draft 4 systems (such as FreeBSD and SGI) like so: #ifdef PTHREAD_MUTEX_INITIALIZER /* * This is a draft 10 or standard pthreads implementation */ if ( pthread_create( &listener_tid, attr, (void *) daemon, (void *) port ) != 0 ) { exit( 1 ); } #else /* !PTHREAD_MUTEX_INITIALIZER*/ /* * This is a draft 4 or earlier pthreads implementation */ if ( pthread_create( &listener_tid, &attr, (void *) daemon, (void *) port ) != 0 ) { exit( 1 ); } #endif /* !PTHREAD_MUTEX_INITIALIZER*/ You should also be aware that if you are using g++ with exceptions, in order to get per thread exception stacks, you will need to use the ports g++ 2.8.1, which was patched by Jeremy. If you are attempting to use STL in combination with pthreads, well... don't use the GNU STL code, it's broken! Use the Moscow Center for SPARC computing code. There are Draft 4 issues with the mutex initialization which are pretty easy to hack around using static constructors. > I'm by no means any kind of expert on posix threads; I've just been > working on some code which compiled but refused to run properly on > FreeBSD. Moving the code to Solaris (and removing all the nice BSD > networking code which Sun have seen fit not to support on Solaris), it > compiled and worked fine, no problems. > > I'm not asking for help with my code... Just some pointers on the history > of pthread support in FreeBSD. Hopefully this will answer your questions enough to get you running. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 18:04:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA00552 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 18:04:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-38.waterford.indigo.ie [194.125.139.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00338; Wed, 1 Jul 1998 18:04:03 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id BAA00874; Thu, 2 Jul 1998 01:59:17 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199807020059.BAA00874@indigo.ie> Date: Thu, 2 Jul 1998 01:59:16 +0000 In-Reply-To: Terry Lambert "Re: Unsupport calls" (Jul 1, 10:34pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Terry Lambert , thorpej@nas.nasa.gov Subject: Re: Unsupport calls Cc: hackers@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com, freebsd-questions@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 1, 10:34pm, Terry Lambert wrote: } Subject: Re: Unsupport calls > > > This is just another case of POSIX adding insult to injury, to no > > > real benefit for anyone. > > > > ...and this insults you how? I think you're taking it way too seriously :-) > > On the theory that, having passed through a committee, standards > are somehow ennobled, and none dare criticize them. They are ennobled in that they are a standardised consensus, it's rare to find that. So rare, in fact, that arguing over small flaws is a waste of time. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 18:39:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA07367 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 18:39:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07347 for ; Wed, 1 Jul 1998 18:39:14 -0700 (PDT) (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.8/8.8.8) with ESMTP id SAA15899; Wed, 1 Jul 1998 18:36:48 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Wed, 01 Jul 1998 16:18:44 EDT." Date: Wed, 01 Jul 1998 18:36:48 -0700 Message-ID: <15895.899343408@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My initial reaction is that I wouldn't want links to depend on values > in environment variables. If I setup some "clean environment" for a > program I'm exec-ing, I'm not going to think to copy values which are > important for these links to work. If you have ever used Apollo's Domain/OS, the advantages of having synlink behavior be configurable by something as dynamic as the user's environment become very quickly apparent. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 18:59:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA10120 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 18:59:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA10112 for ; Wed, 1 Jul 1998 18:59:50 -0700 (PDT) (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.8/8.8.8) with ESMTP id SAA16078; Wed, 1 Jul 1998 18:59:20 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Terry Lambert cc: wjw@surf.IAE.nl, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 00:12:19 -0000." <199807020012.RAA28590@usr07.primenet.com> Date: Wed, 01 Jul 1998 18:59:20 -0700 Message-ID: <16074.899344760@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I. Look in my env > II. Look in the process group leader's env > III. Look in init's env > IV. replace them with "" (zero length string, just as sh does). That looks pretty reasonable. I guess we'd even have a good excuse for making the environment variable support in login.conf work as documented then. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 20:10:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17948 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 20:10:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17943 for ; Wed, 1 Jul 1998 20:10:34 -0700 (PDT) (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 UAA19925; Wed, 1 Jul 1998 20:09:41 -0700 (PDT) Message-Id: <199807020309.UAA19925@implode.root.com> To: "Larry S. Lile" cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-reply-to: Your message of "Wed, 01 Jul 1998 15:58:26 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 01 Jul 1998 20:09:41 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> The short answer is that you can't "block" ISA interupts, so the >> problem you're seeing has to be related to how you're talking to the >> card. The only confirmation of interrupt delivery that the card will >> ever get has to come from your code. > >I thought that was the entire purpose behind splxxx(), It held off >the 8259's until the kernel could process the next interrupt. *confused* Sort of. It has little to do with the 8259, however. The purpose of spl* is to prevent reentrancy into interrupt handlers and to protect critical sections in other parts of the kernel. >Anyway, the card has a register (isrp) that has a bit that shows whether >or not the card can interrrupt the 8259 on its irq line. This works for >the first interrupt but as soon as I enter an spl loop that bit goes >high, saying he can't interrupt, and never drops even after exiting the >spl loop. Sounds to me like you aren't acking the interrupt in your ISR. >Maybe I am confused about how 8259's work, it has been a long time >since I played with that level of the machine, and then it was only for >college class under dos. You don't need to know how the 8259 works to write a device driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 20:19:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19314 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 20:19:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19309 for ; Wed, 1 Jul 1998 20:19:43 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id XAA25605; Wed, 1 Jul 1998 23:16:46 -0400 (EDT) Date: Wed, 1 Jul 1998 23:16:46 -0400 (EDT) From: "Larry S. Lile" To: David Greenman cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-Reply-To: <199807020309.UAA19925@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Jul 1998, David Greenman wrote: > >Anyway, the card has a register (isrp) that has a bit that shows whether > >or not the card can interrrupt the 8259 on its irq line. This works for > >the first interrupt but as soon as I enter an spl loop that bit goes > >high, saying he can't interrupt, and never drops even after exiting the > >spl loop. > > Sounds to me like you aren't acking the interrupt in your ISR. Could I get you to take a peek at whats going on? The adapter spec is at (or at least the pages on the status registers) http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/BK8R1001 /1.4.9.4 and the code for the driver is at http://anarchy.stdio.com (or you can get to it at http://www.jurai.net/~winter/tr/tr.html). I have been working from the MACH source and I can't see what i'm doing wrong. Whats got me really confused is bit 1 in the ISRP high (even) which is called User interrupt blocked? And worst is I can't seem to reset it. Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 20:25:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20143 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 20:25:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hoser (root@in221.inetnebr.com [199.184.119.221]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA20122 for ; Wed, 1 Jul 1998 20:25:10 -0700 (PDT) (envelope-from cradek@in221.inetnebr.com) Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Ethernet driver 2.1 -> 2.2 help Date: Wed, 01 Jul 1998 22:24:47 -0500 From: Chris Radek Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all - A while back I promised to work on a driver for the Accton EtherPocket parallel port ethernet device. Well, I have good news and bad news. I developed the driver under 2.1.7 and it is working beautifully there. Now, however, I want the driver to work under 2.2.X. Looks like things have changed a bit since 2.1. I've done what look like the obvious things, and now the driver compiles again but doesn't work. I'm hoping someone has a description of exactly what had to be changed for the 2.2 port. (I guess someone went through all the drivers and did this?) Thanks, and I promise to contribute the driver once I get it ported... Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 20:41:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22634 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 20:41:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22628 for ; Wed, 1 Jul 1998 20:40:59 -0700 (PDT) (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 UAA20715; Wed, 1 Jul 1998 20:40:24 -0700 (PDT) Message-Id: <199807020340.UAA20715@implode.root.com> To: "Larry S. Lile" cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-reply-to: Your message of "Wed, 01 Jul 1998 23:16:46 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 01 Jul 1998 20:40:24 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Wed, 1 Jul 1998, David Greenman wrote: > >> >Anyway, the card has a register (isrp) that has a bit that shows whether >> >or not the card can interrrupt the 8259 on its irq line. This works for >> >the first interrupt but as soon as I enter an spl loop that bit goes >> >high, saying he can't interrupt, and never drops even after exiting the >> >spl loop. >> >> Sounds to me like you aren't acking the interrupt in your ISR. > >Could I get you to take a peek at whats going on? The adapter spec is >at (or at least the pages on the status registers) >http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/BK8R1001 >/1.4.9.4 >and the code for the driver is at http://anarchy.stdio.com (or you can get >to it at http://www.jurai.net/~winter/tr/tr.html). I have been working >from the MACH source and I can't see what i'm doing wrong. If I get some free time, yes. >Whats got me really confused is bit 1 in the ISRP high (even) which >is called User interrupt blocked? And worst is I can't seem to >reset it. Typically, one resets the bit by setting it. In other words, you read the interrupt status register into a variable and then write the variable out to the ISR to 'ack' whatever interrupt events occured. The you look at the variable to determine what happend and what to do about it. Then when you've handled all of the events, you loop back to the top to see if any new events occured. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 1 22:59:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09027 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 22:59:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iconmail.bellatlantic.net (iconmail.bellatlantic.net [199.173.162.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09021; Wed, 1 Jul 1998 22:59:29 -0700 (PDT) (envelope-from dmm125@bellatlantic.net) Received: from myname.my.domain (client201-122-36.bellatlantic.net [151.201.122.36]) by iconmail.bellatlantic.net (IConNet Sendmail) with SMTP id BAA00596; Thu, 2 Jul 1998 01:58:58 -0400 (EDT) Date: Thu, 2 Jul 1998 01:59:24 +0000 (GMT) From: Donn Miller X-Sender: dmm125@myname.my.domain To: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: FreeBSD equiv. of /proc/loadavg Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I want to use this instead of using getloadavg(). I'm also looking for the equivalent of these. This is what I think they are: Linux FreeBSD ===== ======= /proc/meminfo /proc/curproc/mem /proc/stat /proc/curproc/status /proc/loadavg ??? (probably /kernel) /proc/uptime ??? (probably /kernel) Thanks --Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 00:15:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA20431 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 00:15:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20364 for ; Thu, 2 Jul 1998 00:15:14 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5688) with SMTP id JAA23359 for ; Thu, 2 Jul 1998 09:15:05 +0200 (MET DST) Date: Thu, 2 Jul 1998 09:07:54 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: FreeBSD hackers mailing list Subject: Console driver (was: Problems with irq 9(2)?) In-Reply-To: <359A95A3.7188625A@est.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id AAA20398 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Seeing the message below I just wanted to post a quick remark about the console driver in 2.2.1 (and looking at the source code in syscons.c this is still in there in 3.0-SNAP): Start a utility like top and move the mouse. Wildly. You'll see that the CPU usage goes up to 20 percent on an AMD K6-166. A bit much for a mouse, isn't it, even if the mouse is made by Microsoft. :-) The CPU usage comes from: #if 1 while (!(inb(crtc_addr+6) & 0x08)) /* wait for vertical retrace */ ; #endif Isn't there a way to check in which vertical line the graphical processor is working and then do a tsleep until it arrives at line number max-2 and _then_ start to do this idle loop? Or, much better, use an int routine called by the vertical retrace that is mentioned in the message below. Or, maybe I should stick my head in a bucket of water and not pose problems that do not need to be solved. Nick > > Does anybody know if there are problems with interrupt blocking > > when using interrupt 9(2)? I am having problems with my token > > ring card getting into a user blocked interrupt state and cannot > > figure out what to do. This is really screwing up my token > > ring driver development. > > > > Any ideas? > I am not sure what is going on, but, IRQ 9/2 is often used by vga > adapters, if you have ISA vga adapter then the trouble can be orginated > there. Vga cards used IRQ2/9 for some retrace call. > > Þórður Ívarsson > thivars@est.is > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > STA-ISIS, T.P.270, Joint Research Centre, Italy building: 27A tel.: +39 332 78 9549 fax.: +39 332 78 9185 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 00:32:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA22779 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 00:32:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22771 for ; Thu, 2 Jul 1998 00:32:35 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id JAA14034 ; Thu, 2 Jul 1998 09:32:04 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id JAA07482; Thu, 2 Jul 1998 09:32:03 +0200 To: Joe Abley Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 09:32:01 +0200 In-Reply-To: Joe Abley's message of Thu, 2 Jul 1998 08:09:39 +1200 (NZST) Message-ID: Lines: 45 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Abley writes: > 1. On Solaris, to compile a pthreaded program, I stick a > > #define _REENTRANT > #include > > at the top of the source files, and link with -lpthread. Oh no you don't, unless you have an old Solaris or an old compiler. I know the man pages tell you to do this, but the man pages are wrong... You should just #include #include /* if you want to use Solaris threads */ and compile with -mt. The compiler will define _REENTRANT itself, and pass the correct arguments to ld. A very good reason *not* to define _REENTRANT yourself is that you can catch incorrect compilation: #ifndef _REENTRANT #error "This program needs to be compiled with the -mt option" #endif or even write your application in such a manner that it works without threads, using #ifdef _REENTRANT / #else / #endif For the record, I use the WorkShop Compilers 4.2 cc, dated 30 Oct 1996, on Solaris 2.5 and 2.6. BTW, the Solaris thread implementation has a very nice feature which POSIX threads lack: the ability to wait on all threads in one call, like this: while(thr_join(NULL, NULL, NULL) == 0) /* nothing */ ; This will block until all other threads terminate. Could there be some loophole in the POSIX spec which would allow us to implement something similar? DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 00:36:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23753 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 00:36:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23727 for ; Thu, 2 Jul 1998 00:36:31 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id JAA10721; Thu, 2 Jul 1998 09:36:28 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id JAA10898; Thu, 2 Jul 1998 09:36:27 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807020736.JAA10898@surf.IAE.nl> Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-Reply-To: <19980702100116.F13424@freebie.lemis.com> from Greg Lehey at "Jul 2, 98 10:01:16 am" To: grog@lemis.com (Greg Lehey) Date: Thu, 2 Jul 1998 09:36:27 +0200 (MET DST) Cc: jkh@time.cdrom.com, msmith@smith.net.au, hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You ( Greg Lehey ) write: => On Wednesday, 1 July 1998 at 10:49:55 +0200, Willem Jan Withagen wrote: => > In article you write: => >>> I have actual working code for this. => >>> At the moment every variantlink gets replaced by '2.2.6', since that is my => >>> current OS version. => >> => >> That's really cool! Apollo, here we come! ;-) => > => > Just look for the Apollo FAQ and see why I'm chasing this one down. => > :-D. I just loved my Domain babies. => > => > [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( => => What's the problem? I've heard of nightmares with Apollo tapes, and I => currently have a set of Domain OS 10.4 tapes here which I need to copy => (Mike, are you listening?). The tapes were written on a DAT (old non compressing) but for writting them I had to specify tar cbf 20 /dev/tape And I think it is this blocking factor which prevents me from even dd-ing data from the tape. :-( Maybe I'll have to go to somebody with a driver which does 10K blocks? --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 00:55:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA27298 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 00:55:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27271 for ; Thu, 2 Jul 1998 00:55:12 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id RAA14495; Thu, 2 Jul 1998 17:24:58 +0930 (CST) Message-ID: <19980702172457.E14070@freebie.lemis.com> Date: Thu, 2 Jul 1998 17:24:57 +0930 From: Greg Lehey To: wjw@IAEhv.nl Cc: jkh@time.cdrom.com, msmith@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Apollo tapes (was: Variant Link implementation, continued) References: <19980702100116.F13424@freebie.lemis.com> <199807020736.JAA10898@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807020736.JAA10898@surf.IAE.nl>; from Willem Jan Withagen on Thu, Jul 02, 1998 at 09:36:27AM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 2 July 1998 at 9:36:27 +0200, Willem Jan Withagen wrote: > You ( Greg Lehey ) write: > => On Wednesday, 1 July 1998 at 10:49:55 +0200, Willem Jan Withagen wrote: > => > In article you write: > => >>> I have actual working code for this. > => >>> At the moment every variantlink gets replaced by '2.2.6', since that is my > => >>> current OS version. > => >> > => >> That's really cool! Apollo, here we come! ;-) > => > > => > Just look for the Apollo FAQ and see why I'm chasing this one down. > => > :-D. I just loved my Domain babies. > => > > => > [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( > => > => What's the problem? I've heard of nightmares with Apollo tapes, and I > => currently have a set of Domain OS 10.4 tapes here which I need to copy > => (Mike, are you listening?). > > The tapes were written on a DAT (old non compressing) but for writting them > I had to specify tar cbf 20 /dev/tape > And I think it is this blocking factor which prevents me from even dd-ing > data from the tape. :-( Shouldn't be. That's the FreeBSD default. Are you sure that you haven't written on a device with non-standard compression or some such? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA01747 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:16:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA01625 for ; Thu, 2 Jul 1998 01:16:00 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id KAA14182; Thu, 2 Jul 1998 10:15:17 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id KAA14039; Thu, 2 Jul 1998 10:15:33 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 02 Jul 1998 10:15:32 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: Joe Abley Subject: RE: pthreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Jul-98 Joe Abley wrote: > Hi all, > > Does anybody know the background of posix thread support in FreeBSD? I > can't seem to find any docs on the background anywhere... > > I'm interested in a couple of issues. > > 1. On Solaris, to compile a pthreaded program, I stick a > > #define _REENTRANT > #include > > at the top of the source files, and link with -lpthread. With FreeBSD the > linking phase is more involved, since I need to exclude the standard C > libraries and link with libc_r instead. > > Why was the decision made to support pthreads in this manner? What > benefits does this have over the Solaris way of doing things? Because SunOS 5 has kernel thread support and FreeBSD 2.2.6-R does not. This means that on Solaris, when a syscall blocks, a SIGLWP and SIGWAITING can be issued, and the libpthread catches these signals and creates new LWP's (i.e. kernel supported threads) and schedules the user threads on top of them. The morale thereof is that one can use the normal blocking libc syscalls in threaded applications as well without any adverse effects. FreeBSD (and any other pthread implementation without kernel supported threads) must replace all potentially blocking calls with a non-blocking call plus user space thread context switch. All user space pthread implementations known to me use some sort of libc replacement. /Marino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:21:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02861 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:21:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02826; Thu, 2 Jul 1998 01:21:07 -0700 (PDT) (envelope-from sos) Message-Id: <199807020821.BAA02826@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from Nick Hibma at "Jul 2, 98 09:07:54 am" To: nick.hibma@jrc.it Date: Thu, 2 Jul 1998 01:21:07 -0700 (PDT) Cc: hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Nick Hibma who wrote: > Seeing the message below I just wanted to post a quick remark about the > console driver in 2.2.1 (and looking at the source code in syscons.c > this is still in there in 3.0-SNAP): > > Start a utility like top and move the mouse. Wildly. You'll see that the > CPU usage goes up to 20 percent on an AMD K6-166. A bit much for a > mouse, isn't it, even if the mouse is made by Microsoft. :-) Hmm, I can raise my CPU usage about 2% on my 133P5, you must be doing something strange ???? > The CPU usage comes from: > > #if 1 > while (!(inb(crtc_addr+6) & 0x08)) /* wait for vertical retrace */ ; > #endif > > Isn't there a way to check in which vertical line the graphical > processor is working and then do a tsleep until it arrives at line > number max-2 and _then_ start to do this idle loop? > > Or, much better, use an int routine called by the vertical retrace that > is mentioned in the message below. Hmm, there really is no good way to do this (or it would have been done). The resolution of tsleep is to coarse to be usefull here. The interrupt doesn't work on alot of cards. But on most modern cards you dont even need this wait, they will work fine without. > Or, maybe I should stick my head in a bucket of water and not pose > problems that do not need to be solved. Hmm, thats so final somehow, but thinking before posting might be good advise :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:30:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA04972 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:30:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA04948; Thu, 2 Jul 1998 01:30:36 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5688) with SMTP id KAA25788; Thu, 2 Jul 1998 10:30:33 +0200 (MET DST) Date: Thu, 2 Jul 1998 10:23:22 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: sos@FreeBSD.ORG cc: FreeBSD hackers mailing list Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: <199807020821.BAA02826@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Start a utility like top and move the mouse. Wildly. You'll see that the > > CPU usage goes up to 20 percent on an AMD K6-166. A bit much for a > > mouse, isn't it, even if the mouse is made by Microsoft. :-) > > Hmm, I can raise my CPU usage about 2% on my 133P5, you must be > doing something strange ???? Woopsa, you are using the moused as well, I presume, and 'vidcontrol -m on' and you are looking at one of the text consoles? > doesn't work on alot of cards. But on most modern cards you dont even > need this wait, they will work fine without. Not on mine. S3, bought 4 month ago. New. Nick STA-ISIS, T.P.270, Joint Research Centre, Italy building: 27A tel.: +39 332 78 9549 fax.: +39 332 78 9185 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:34:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA05648 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:34:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA05629 for ; Thu, 2 Jul 1998 01:34:19 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id KAA28430; Thu, 2 Jul 1998 10:33:32 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id KAA29656; Thu, 2 Jul 1998 10:33:32 +0200 (MET DST) Date: Thu, 2 Jul 1998 10:33:32 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807020833.KAA29656@surf.IAE.nl> To: drosih@rpi.edu Subject: Re: Variant Link implementation, continued X-Newsgroups: list.freebsd.hackers In-Reply-To: References: <13617.899298865@time.cdrom.com> Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >My initial reaction is that I wouldn't want links to depend on values >in environment variables. If I setup some "clean environment" for a >program I'm exec-ing, I'm not going to think to copy values which are >important for these links to work. > >So there's two questions. One is how to you make sure you're looking >at the correct & current environment, and the other is how do you know >that that environment (once you find it) includes all the symbolic- >link-related variables (and values) which will be expected. I think I'd agree with you on this. Even Apollo's had certain links which were very critical. For those who never saw Domain OS: Dependant on a env-variable (SYSTYPE) one would be able to switch, on the fly, between 3 OS interfaces. This would hold for: the application layer, ( aka shells and programs ) include files ...... I used it a lot to switch between the differnt releases of software I was maintaining. Working on an older version, just meant that I'd set the env-variable MYVERSION to a previous release, then do a cd ~/src/project and life was again simple. Your argument would lead to introduce 2 types of resolution: - important system-links, which are under control of 'root'. The are extracted first from the/a sysctl-namespace, and then (if not available there) from the users env. - regular links, which follow the process Terry outlined in one of the other messages: user-env, process-grp-env, init-env --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:46:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08502 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:46:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08493 for ; Thu, 2 Jul 1998 01:46:32 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id KAA19233 ; Thu, 2 Jul 1998 10:46:01 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id KAA07641; Thu, 2 Jul 1998 10:46:00 +0200 To: Nick Hibma Cc: FreeBSD hackers mailing list Subject: Re: Console driver (was: Problems with irq 9(2)?) References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 10:46:00 +0200 In-Reply-To: Nick Hibma's message of Thu, 2 Jul 1998 09:07:54 +0200 (MET DST) Message-ID: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma writes: > Isn't there a way to check in which vertical line the graphical > processor is working and then do a tsleep until it arrives at line > number max-2 and _then_ start to do this idle loop? No. The vertical retrace period is the time during which the electron beam is being repositioned from the bottom right to the top left of the screen. Synchronizing with the vertical retrace is not a trivial task, as any demo coder will tell you. However, no VGA board that I know of will exhibit snow while in text mode, so waiting for vertical retrace is not necessary. It should not be removed, though, as older CGA and MDA boards require it; but it could be turned into a kernel option. If you feel very strongly about this, cut'n'paste this article into send-pr and somebody will get around to it. > Or, much better, use an int routine called by the vertical retrace that > is mentioned in the message below. No. Modern graphics adapters do not have that functionality. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 01:56:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA10453 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 01:56:46 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA10436 for ; Thu, 2 Jul 1998 01:56:42 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id TAA02581; Thu, 2 Jul 1998 19:07:35 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199807020907.TAA02581@cimlogic.com.au> Subject: Re: pthreads In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 09:32:01 am" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 19:07:34 +1000 (EST) Cc: jabley@clear.co.nz, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Coidan Smørgrav wrote: > BTW, the Solaris thread implementation has a very nice feature which > POSIX threads lack: the ability to wait on all threads in one call, > like this: > > while(thr_join(NULL, NULL, NULL) == 0) > /* nothing */ ; > > This will block until all other threads terminate. Could there be some > loophole in the POSIX spec which would allow us to implement something > similar? POSIX allows extensions so it is just a matter of writing the code. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 02:41:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA15430 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 02:41:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA15371 for ; Thu, 2 Jul 1998 02:41:19 -0700 (PDT) (envelope-from hiren@tagore.wipinfo.soft.net) Received: from tagore.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id PAA26476; Thu, 2 Jul 1998 15:07:01 -0500 Date: Thu, 2 Jul 1998 15:18:31 +0530 (IST) From: Hiren Mehta X-Sender: hiren@tagore To: freebsd-hackers@FreeBSD.ORG Subject: problem with network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I Installed freebsd on my system. When ifconfig is run to bring the network up, I get the following message : ifconfig: ioctl(SIOCAIFADDR) destination address required. What can be the problem ? How to fix this problem ? Thanks Hiren `All rights left. All lefts reserved. All reserves removed. All removes right.' CHANGE IN EXTENSION NUMBER //// (o o) -------------------------oOO--(_)--OOo----------------------------------- Hiren Mehta --- Email address : AT&T Dedicated Facility /o o\ hiren@wipinfo.soft.net Wipro Infotech Ltd(ADF) | O | Phone: 91-080-2241735, 2241730 Divyasree Complex, \_-_/ 2241735, 2241768 30, Mission Road, Ist Main, Extn. 3411 S. R. Nagar, Bangalore - 560 027 Fax: 91-080-2241769 ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 02:53:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA17031 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 02:53:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lhab-gw.soroscj.ro (lhab-gw.soroscj.ro [193.226.84.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA17012 for ; Thu, 2 Jul 1998 02:53:21 -0700 (PDT) (envelope-from kojak@lhab.soroscj.ro) Received: from lhab.soroscj.ro (lhab.soroscj.ro [193.226.99.146]) by lhab-gw.soroscj.ro (8.8.6/8.7.3) with ESMTP id MAA00173 for ; Thu, 2 Jul 1998 12:38:10 +0300 Received: from localhost (kojak@localhost) by lhab.soroscj.ro (8.8.6/8.6.12) with SMTP id MAA06915 for ; Thu, 2 Jul 1998 12:40:02 +0300 Date: Thu, 2 Jul 1998 12:40:01 +0300 (EET DST) From: elev Ilea Alexandru To: hackers@FreeBSD.ORG Subject: Re: freebsd-hackers-digest V4 #177 In-Reply-To: <199807020816.BAA01814@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG how do I unsubscribe this list? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 03:20:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA21686 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 03:20:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA21576; Thu, 2 Jul 1998 03:19:57 -0700 (PDT) (envelope-from sos) Message-Id: <199807021019.DAA21576@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 10:46:00 am" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 03:19:57 -0700 (PDT) Cc: nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > Nick Hibma writes: > > Isn't there a way to check in which vertical line the graphical > > processor is working and then do a tsleep until it arrives at line > > number max-2 and _then_ start to do this idle loop? > > No. The vertical retrace period is the time during which the electron > beam is being repositioned from the bottom right to the top left of > the screen. Synchronizing with the vertical retrace is not a trivial > task, as any demo coder will tell you. > > However, no VGA board that I know of will exhibit snow while in text > mode, so waiting for vertical retrace is not necessary. It should not > be removed, though, as older CGA and MDA boards require it; but it > could be turned into a kernel option. If you feel very strongly about > this, cut'n'paste this article into send-pr and somebody will get > around to it. Well you dont know much then :), most modern videocards will "snow" when you muck with the font generator, you probably confuses this with writing to the screen buffer, which works on all VGA's etc etc... No idea in makeing a PR on this, I'm aware of the problem, but there really is no good solution to it I'm afraid.. > > Or, much better, use an int routine called by the vertical retrace that > > is mentioned in the message below. > > No. Modern graphics adapters do not have that functionality. > Well, most VGA comaptibles do have it, but there is enough cards outthere that doesn't, so its not a soluiton. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 03:22:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA22173 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 03:22:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA22049; Thu, 2 Jul 1998 03:22:08 -0700 (PDT) (envelope-from sos) Message-Id: <199807021022.DAA22049@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from Nick Hibma at "Jul 2, 98 10:23:22 am" To: nick.hibma@jrc.it Date: Thu, 2 Jul 1998 03:22:07 -0700 (PDT) Cc: sos@FreeBSD.ORG, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Nick Hibma who wrote: > > > Start a utility like top and move the mouse. Wildly. You'll see that the > > > CPU usage goes up to 20 percent on an AMD K6-166. A bit much for a > > > mouse, isn't it, even if the mouse is made by Microsoft. :-) > > > > Hmm, I can raise my CPU usage about 2% on my 133P5, you must be > > doing something strange ???? > Woopsa, you are using the moused as well, I presume, and 'vidcontrol -m > on' and you are looking at one of the text consoles? Yup, here on my dual PPro I cannot even telle the difference, I can see the interupts that the psm device makes though :) > > doesn't work on alot of cards. But on most modern cards you dont even > > need this wait, they will work fine without. > Not on mine. S3, bought 4 month ago. New. Right, my S3 doesn't either, but my old Diamond Viper Pro (P9100 based= works just fine without it... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 03:31:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA23949 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 03:31:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23925; Thu, 2 Jul 1998 03:31:04 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id MAA24261 ; Thu, 2 Jul 1998 12:29:56 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id MAA07752; Thu, 2 Jul 1998 12:29:56 +0200 To: sos@FreeBSD.ORG Cc: nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: Console driver (was: Problems with irq 9(2)?) References: <199807021019.DAA21576@hub.freebsd.org> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 12:29:55 +0200 In-Reply-To: sos@freebsd.org's message of Thu, 2 Jul 1998 03:19:57 -0700 (PDT) Message-ID: Lines: 32 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG sos@freebsd.org writes: > In reply to Dag-Erling Coidan Smørgrav who wrote: > > However, no VGA board that I know of will exhibit snow while in text > > mode, so waiting for vertical retrace is not necessary. It should not > Well you dont know much then :), most modern videocards will > "snow" when you muck with the font generator, you probably > confuses this with writing to the screen buffer, which works > on all VGA's etc etc... Ah. I didn't realize that we were talking font generator here. Honestly, I don't really see the point in having a nifty pseudo- graphical mouse cursor in text mode. First, it's overkill because you only need character resolution, not pixel resolution. Second, it steals four characters from your character set. Third, it doesn't work properly (or at least doesn't look good) in all modes. > > > Or, much better, use an int routine called by the vertical retrace that > > > is mentioned in the message below. > > No. Modern graphics adapters do not have that functionality. > Well, most VGA comaptibles do have it, but there is enough cards > outthere that doesn't, so its not a soluiton. Of all the VGA adapters I've ever laid eyes on, the only one to generate an interrupt on vertical retrace is an old VLB S3 86c805 based accelerator, and even that one has a jumper for it which is off by factory default. I currently own two S3 cards, one TSeng Labs card, and a bunch of no-brand Cirrus Logic and Western Digital based cards. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 04:12:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA00384 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 04:12:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA00304; Thu, 2 Jul 1998 04:12:26 -0700 (PDT) (envelope-from sos) Message-Id: <199807021112.EAA00304@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 12:29:55 pm" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 04:12:26 -0700 (PDT) Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > sos@freebsd.org writes: > > In reply to Dag-Erling Coidan Smørgrav who wrote: > > > However, no VGA board that I know of will exhibit snow while in text > > > mode, so waiting for vertical retrace is not necessary. It should not > > Well you dont know much then :), most modern videocards will > > "snow" when you muck with the font generator, you probably > > confuses this with writing to the screen buffer, which works > > on all VGA's etc etc... > > Ah. I didn't realize that we were talking font generator here. > > Honestly, I don't really see the point in having a nifty pseudo- > graphical mouse cursor in text mode. First, it's overkill because you > only need character resolution, not pixel resolution. Second, it > steals four characters from your character set. Third, it doesn't work > properly (or at least doesn't look good) in all modes. First, I need char resolution in some apps, strange but true. Second, 256 chars is not enough anyways, so having 252 is just a little worse. Third, it was done by "popular demand", so there is use for it. Fourth, it was fun doing :) > Of all the VGA adapters I've ever laid eyes on, the only one to > generate an interrupt on vertical retrace is an old VLB S3 86c805 > based accelerator, and even that one has a jumper for it which is off > by factory default. I currently own two S3 cards, one TSeng Labs card, > and a bunch of no-brand Cirrus Logic and Western Digital based cards. And some has it tied to NMI yikes! so if you enable it in the regs you will get really funny results... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 04:16:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01110 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 04:16:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01066 for ; Thu, 2 Jul 1998 04:15:55 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id NAA26719 ; Thu, 2 Jul 1998 13:15:20 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id NAA07812; Thu, 2 Jul 1998 13:15:19 +0200 To: Hiren Mehta Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: problem with network References: Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 13:15:18 +0200 In-Reply-To: Hiren Mehta's message of Thu, 2 Jul 1998 15:18:31 +0530 (IST) Message-ID: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hiren Mehta writes: > I Installed freebsd on my system. When ifconfig is run to bring the > network up, I get the following message : > > ifconfig: ioctl(SIOCAIFADDR) destination address required. > > What can be the problem ? How to fix this problem ? I think we need some more information in order to help you. Could you show us the contents of the "Basic network options" section from your /etc/rc.conf file? BTW, this should have gone to -questions, not -hackers. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 04:19:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01622 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 04:19:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01602; Thu, 2 Jul 1998 04:19:00 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id NAA26828 ; Thu, 2 Jul 1998 13:17:50 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id NAA07816; Thu, 2 Jul 1998 13:17:49 +0200 To: sos@FreeBSD.ORG Cc: nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: Console driver (was: Problems with irq 9(2)?) References: <199807021112.EAA00304@hub.freebsd.org> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 13:17:48 +0200 In-Reply-To: sos@freebsd.org's message of Thu, 2 Jul 1998 04:12:26 -0700 (PDT) Message-ID: Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG sos@freebsd.org writes: > In reply to Dag-Erling Coidan Smørgrav who wrote: > > Honestly, I don't really see the point in having a nifty pseudo- > > graphical mouse cursor in text mode. First, it's overkill because you > > only need character resolution, not pixel resolution. Second, it > > steals four characters from your character set. Third, it doesn't work > > properly (or at least doesn't look good) in all modes. > First, I need char resolution in some apps, strange but true. ITYM "pixel resolution". HTH. HAND. > Second, 256 chars is not enough anyways, so having 252 is just a little worse. > Third, it was done by "popular demand", so there is use for it. > Fourth, it was fun doing :) Well, can it at least be switched off? or should I go stick my head in a bucket of ice... :) DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 04:39:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA04781 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 04:39:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA04769 for ; Thu, 2 Jul 1998 04:39:38 -0700 (PDT) (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.8/8.8.8) with ESMTP id MAA03941; Thu, 2 Jul 1998 12:39:01 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <359B7155.8E065D03@tdx.co.uk> Date: Thu, 02 Jul 1998 12:39:01 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: elev Ilea Alexandru CC: hackers@FreeBSD.ORG Subject: Re: freebsd-hackers-digest V4 #177 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It tells you at the bottom of every message posted to the list! elev Ilea Alexandru wrote: > how do I unsubscribe this list? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ See? If you still have problems let me know... Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 05:18:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10971 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 05:18:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ibridge.iohk.com (root@ibridge.iohk.com [202.21.128.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10966 for ; Thu, 2 Jul 1998 05:18:22 -0700 (PDT) (envelope-from percy@iohk.com) Received: from igate.iohk.com (percy@igate.iohk.com [202.21.128.81]) by ibridge.iohk.com (8.8.5/8.8.5) with ESMTP id UAA14190 for ; Thu, 2 Jul 1998 20:20:32 +0800 (HKT) Received: from localhost (percy@localhost) by igate.iohk.com (8.8.5/8.8.5) with SMTP id UAA24531 for ; Thu, 2 Jul 1998 20:20:32 +0800 (HKT) Date: Thu, 2 Jul 1998 20:20:31 +0800 (HKT) From: Percy Cheng To: hackers@FreeBSD.ORG Subject: About FreeBSD boot manager... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just want to know would BootEasy need a primary partition to master the booting? If I want to install win95, win98 and FreeBSD in 3 different primary partition, and make the last one to Extended partition, does BootEasy can manage? Furthermore, could FreeBSD installed to logical drive?? Seems it just can find the extened drive and could not detect the logical drive... Sorry for my poor english and thanks for your kind attention...^_^ Percy Cheng Internet Online Hong Kong Ltd. Our Web Site:http://www.iohk.com My email box:percy@iohk.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 05:29:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12125 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 05:29:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12087; Thu, 2 Jul 1998 05:29:00 -0700 (PDT) (envelope-from sos) Message-Id: <199807021229.FAA12087@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 01:17:48 pm" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 05:28:59 -0700 (PDT) Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > sos@freebsd.org writes: > > In reply to Dag-Erling Coidan Smørgrav who wrote: > > > Honestly, I don't really see the point in having a nifty pseudo- > > > graphical mouse cursor in text mode. First, it's overkill because you > > > only need character resolution, not pixel resolution. Second, it > > > steals four characters from your character set. Third, it doesn't work > > > properly (or at least doesn't look good) in all modes. > > First, I need char resolution in some apps, strange but true. > > ITYM "pixel resolution". HTH. HAND. Yeah well :) > > Second, 256 chars is not enough anyways, so having 252 is just a little worse. > > Third, it was done by "popular demand", so there is use for it. > > Fourth, it was fun doing :) > > Well, can it at least be switched off? or should I go stick my head in > a bucket of ice... :) You just dont run vidcontol -m on, thats it .... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 05:33:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12690 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 05:33:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA12683; Thu, 2 Jul 1998 05:33:25 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id OAA01081 ; Thu, 2 Jul 1998 14:32:09 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id OAA08079; Thu, 2 Jul 1998 14:32:07 +0200 To: sos@FreeBSD.ORG Cc: nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: Console driver (was: Problems with irq 9(2)?) References: <199807021229.FAA12087@hub.freebsd.org> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 14:32:07 +0200 In-Reply-To: sos@freebsd.org's message of Thu, 2 Jul 1998 05:28:59 -0700 (PDT) Message-ID: Lines: 18 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG sos@freebsd.org writes: > In reply to Dag-Erling Coidan Smørgrav who wrote: > > sos@freebsd.org writes: > > > Second, 256 chars is not enough anyways, so having 252 is just a little worse. > > > Third, it was done by "popular demand", so there is use for it. > > > Fourth, it was fun doing :) > > Well, can it at least be switched off? or should I go stick my head in > > a bucket of ice... :) > You just dont run vidcontol -m on, thats it .... No, I mean, is there any way to use the mouse with a character- resolution cursor? e.g. reverse the character it points at, or set the background color of that character to red, instead of doing that fancy font manipulation. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 05:39:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA13633 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 05:39:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA13611; Thu, 2 Jul 1998 05:39:00 -0700 (PDT) (envelope-from sos) Message-Id: <199807021239.FAA13611@hub.freebsd.org> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 02:32:07 pm" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 05:39:00 -0700 (PDT) Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > sos@freebsd.org writes: > > In reply to Dag-Erling Coidan Smørgrav who wrote: > > > sos@freebsd.org writes: > > > > Second, 256 chars is not enough anyways, so having 252 is just a little worse. > > > > Third, it was done by "popular demand", so there is use for it. > > > > Fourth, it was fun doing :) > > > Well, can it at least be switched off? or should I go stick my head in > > > a bucket of ice... :) > > You just dont run vidcontol -m on, thats it .... > > No, I mean, is there any way to use the mouse with a character- > resolution cursor? e.g. reverse the character it points at, or set the > background color of that character to red, instead of doing that fancy > font manipulation. Maybe if somebody implements it, I'll look it over and commit it (if deemed OK that is). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 05:57:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15914 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 05:57:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA15903; Thu, 2 Jul 1998 05:57:08 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA12406; Thu, 2 Jul 1998 13:27:00 +0200 From: Luigi Rizzo Message-Id: <199807021127.NAA12406@labinfo.iet.unipi.it> Subject: timeout granularity (was: Re: Console driver...) To: sos@FreeBSD.ORG Date: Thu, 2 Jul 1998 13:26:59 +0200 (MET DST) Cc: smoergrd@oslo.geco-prakla.slb.com, nick.hibma@jrc.it, hackers@FreeBSD.ORG In-Reply-To: <199807021112.EAA00304@hub.freebsd.org> from "sos@FreeBSD.ORG" at Jul 2, 98 04:12:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [about default timer granularity being too coarse for sampling the vertical retrace interval] the code might check if HZ is set to a suitable value (how large, e.g. 1000 or 2000, i have no idea) and use timeout instead of polling if the test is successful. Sooner or later hopefully we will move to large values of HZ anyways. (or, how about adding a utimeout() call to the kernel :) 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:11:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17753 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:11:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17735; Thu, 2 Jul 1998 06:11:47 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id PAA03241 ; Thu, 2 Jul 1998 15:11:14 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id PAA08121; Thu, 2 Jul 1998 15:11:13 +0200 To: Luigi Rizzo Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) References: <199807021127.NAA12406@labinfo.iet.unipi.it> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 15:11:13 +0200 In-Reply-To: Luigi Rizzo's message of Thu, 2 Jul 1998 13:26:59 +0200 (MET DST) Message-ID: Lines: 19 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo writes: > [about default timer granularity being too coarse for sampling > the vertical retrace interval] > > the code might check if HZ is set to a suitable value (how large, > e.g. 1000 or 2000, i have no idea) and use timeout instead of > polling if the test is successful. Sooner or later hopefully we > will move to large values of HZ anyways. > > (or, how about adding a utimeout() call to the kernel :) It's not that simple. You have to know how long to wait, which is practically impossible to do without hooking the timer interrupt and reprogramming it to keep pace with the retrace, and even that is difficult to achieve without a little busy-waiting here and there. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:13:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17987 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:13:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from guinnes.tangram.spb.ru (tangram-gw.chance.ru [194.58.86.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17968; Thu, 2 Jul 1998 06:13:08 -0700 (PDT) (envelope-from caseq@tangram.spb.ru) Received: (from caseq@localhost) by guinnes.tangram.spb.ru (8.8.8/8.8.5) id RAA00789; Thu, 2 Jul 1998 17:10:40 +0400 (MSD) From: Andrew Kosyakov Message-Id: <199807021310.RAA00789@guinnes.tangram.spb.ru> Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: <199807021112.EAA00304@hub.freebsd.org> from "sos@FreeBSD.ORG" at "Jul 2, 98 04:12:26 am" To: sos@FreeBSD.ORG Date: Thu, 2 Jul 1998 17:10:40 +0400 (MSD) Cc: smoergrd@oslo.geco-prakla.slb.com, nick.hibma@jrc.it, 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 Precedence: bulk X-Loop: FreeBSD.ORG Quoting sos@FreeBSD.ORG: > > Honestly, I don't really see the point in having a nifty pseudo- > > graphical mouse cursor in text mode. First, it's overkill because you > > only need character resolution, not pixel resolution. Second, it > > steals four characters from your character set. Third, it doesn't work > > properly (or at least doesn't look good) in all modes. > > First, I need char resolution in some apps, strange but true. > Second, 256 chars is not enough anyways, so having 252 is just a little worse. It's much worse if these 4 characters happen to be widely used letters in your charset. Yes, I know I can load fonts for another charset and then use screen map, but somewhy I like the idea of inverted block character cursor much more. > Third, it was done by "popular demand", so there is use for it. > Fourth, it was fun doing :) It would be really "popular" to be able to customize this feature :) Sincerely yours /&rew --- Andrew Kosyakov, Tangram Ltd, +7 (812) 516-6981, caseq@tangram.spb.ru PGP Key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:17:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA18715 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:17:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA18707 for ; Thu, 2 Jul 1998 06:17:47 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA01134; Thu, 2 Jul 1998 09:17:18 -0400 Date: Thu, 2 Jul 1998 09:17:18 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: <199807021127.NAA12406@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Luigi Rizzo wrote: > polling if the test is successful. Sooner or later hopefully we > will move to large values of HZ anyways. good point. I've experimented with HZ of 10,000 on a 486-25. 10K was a bit large for this machine, but 2500 was no problem. What's the largest HZ anyone out there has used? I'd expect that 10K or 20K would not be a real problem. Anyone know? ron p.s. no, time did not run fast. I put pre-scaling in hardclock so all was well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:25:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19963 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:25:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA19955 for ; Thu, 2 Jul 1998 06:25:28 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5688) with SMTP id PAA05672; Thu, 2 Jul 1998 15:25:09 +0200 (MET DST) Date: Thu, 2 Jul 1998 15:17:59 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Andrew Kosyakov cc: FreeBSD hackers mailing list Subject: Re: Console driver (was: Problems with irq 9(2)?) In-Reply-To: <199807021310.RAA00789@guinnes.tangram.spb.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's much worse if these 4 characters happen to be widely used letters > in your charset. Yes, I know I can load fonts for another charset and then > use screen map, but somewhy I like the idea of inverted block character > cursor much more. > > > Third, it was done by "popular demand", so there is use for it. > > Fourth, it was fun doing :) > It would be really "popular" to be able to customize this feature :) I'll have a look this weekend. While we are customising: - The color should be customisable as well. - The color should of course be transparent, so a red cursor will give you a pink character when you are over a blue character on white background. Gee, we can have lots of discussions about the color scheme... :) Nick. STA-ISIS, T.P.270, Joint Research Centre, Italy building: 27A tel.: +39 332 78 9549 fax.: +39 332 78 9185 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:29:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20662 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:29:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA20640; Thu, 2 Jul 1998 06:29:33 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA12433; Thu, 2 Jul 1998 13:59:19 +0200 From: Luigi Rizzo Message-Id: <199807021159.NAA12433@labinfo.iet.unipi.it> Subject: Re: timeout granularity (was: Re: Console driver...) To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 13:59:19 +0200 (MET DST) Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Smørgrav" at Jul 2, 98 03:10:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > the code might check if HZ is set to a suitable value (how large, > > e.g. 1000 or 2000, i have no idea) and use timeout instead of > > polling if the test is successful. Sooner or later hopefully we > > will move to large values of HZ anyways. > > > > (or, how about adding a utimeout() call to the kernel :) > > It's not that simple. You have to know how long to wait, which is > practically impossible to do without hooking the timer interrupt and > reprogramming it to keep pace with the retrace, and even that is > difficult to achieve without a little busy-waiting here and there. a little busy waiting is not a lot. What is bad is 10ms waiting (I hope interrupts are enabled while waiting!) If one can, say, assume that the vertical retrace is never less than 1ms, then HZ=2000 should do the job (wakeup at every tick...). cheers -----------------------------+-------------------------------------- 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:33:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA21378 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:33:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA21372 for ; Thu, 2 Jul 1998 06:33:27 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Jul 2 08:33 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id IAA08550 for ; Thu, 2 Jul 1998 08:33:21 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 2 Jul 1998 09:33:18 -0400 Message-ID: To: rminnich@Sarnoff.COM, hackers@FreeBSD.ORG Subject: RE: timeout granularity (was: Re: Console driver...) Date: Thu, 2 Jul 1998 09:33:18 -0400 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 Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Ron G. Minnich [SMTP:rminnich@Sarnoff.COM] > > On Thu, 2 Jul 1998, Luigi Rizzo wrote: > > polling if the test is successful. Sooner or later hopefully we > > will move to large values of HZ anyways. > > good point. I've experimented with HZ of 10,000 on a 486-25. 10K was a > > bit large for this machine, but 2500 was no problem. What's the > largest > HZ anyone out there has used? I'd expect that 10K or 20K would not be > a > real problem. Anyone know? > I did not experimented with high HZ but rather long time ago I've experimented with high-speed transfers through serial ports (the ports I had at the time were without FIFO). The measurements have shown that handling 115200 bps transfer caused 11520 interrupts per second and ate up about 20% CPU of 20 MHz 386 in the interrupt handler. The OS was SCO Unix 3.2.1. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 06:35:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA21656 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 06:35:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA21618; Thu, 2 Jul 1998 06:34:45 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id PAA04489 ; Thu, 2 Jul 1998 15:34:08 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id PAA08137; Thu, 2 Jul 1998 15:34:08 +0200 To: Luigi Rizzo Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) References: <199807021159.NAA12433@labinfo.iet.unipi.it> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 02 Jul 1998 15:34:07 +0200 In-Reply-To: Luigi Rizzo's message of Thu, 2 Jul 1998 13:59:19 +0200 (MET DST) Message-ID: Lines: 20 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo writes: > > It's not that simple. You have to know how long to wait, which is > > practically impossible to do without hooking the timer interrupt and > > reprogramming it to keep pace with the retrace, and even that is > > difficult to achieve without a little busy-waiting here and there. > a little busy waiting is not a lot. What is bad is 10ms waiting With a 70 Hz refresh rate, we're talking more like 14 ms in the worst case, which is pretty darn bad. > If one can, say, assume that the vertical retrace is never less than > 1ms, then HZ=2000 should do the job (wakeup at every tick...). Ah, I didn't think of it quite like that. Yes, it would work, and you wouldn't have to busy-wait at all; just wake up at every tick, check if you're in a retrace, and if you are, do your job. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 07:05:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26246 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 07:05:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from indigo.ie (root@ts01-55.waterford.indigo.ie [194.125.139.118]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26222 for ; Thu, 2 Jul 1998 07:05:03 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id OAA00589; Thu, 2 Jul 1998 14:21:54 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199807021321.OAA00589@indigo.ie> Date: Thu, 2 Jul 1998 14:21:53 +0000 In-Reply-To: Terry Lambert "Re: pthreads" (Jul 2, 12:44am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Terry Lambert , jabley@clear.co.nz (Joe Abley) Subject: Re: pthreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 2, 12:44am, Terry Lambert wrote: } Subject: Re: pthreads > > Does anybody know the background of posix thread support in FreeBSD? I > > can't seem to find any docs on the background anywhere... [snip] > John Birrell rewrote lots of it in -current, with an eye toward > bringing the code up to the Draft 10 standard (the ratified standard), > and he and John Dyson did a lot of work to support a kernel > implementation, also in -current, using rfork() and some rather > complicated stack management. This is basically sharing a number of kernel processes among a set of threads, right? Do you know if any progress was made towards a LWP scheme? If John Dyson's async I/O code is in place that would help a lot on that area I think. > John Dyson did a number of patches for CPU affinity CPU affinity? You mean the threading library can pass scheduling hints to the kernel for a set of processes? Was this threading model an interim measure until someone wrote one based on LWP or intended to be the way that it would always be done? There are a number of problems with this approach (outlined in a paper called "Scheduler Activations: Effective Kernel Support for the User Level Management of Parallelism", ask me for a copy if you want one) althought it is much easier to implement than a LWP based model. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 07:22:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00455 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 07:22:53 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00420 for ; Thu, 2 Jul 1998 07:22:41 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id QAA29025 for freebsd-hackers@FreeBSD.ORG; Thu, 2 Jul 1998 16:19:28 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id MAA11096; Thu, 2 Jul 1998 12:24:31 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807021024.MAA11096@semyam.dinoco.de> To: freebsd-hackers@FreeBSD.ORG cc: seggers@semyam.dinoco.de Subject: permission confusion at mount points Date: Thu, 02 Jul 1998 12:24:29 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I had a directory "/usr2" with mode 0700 owned by root.wheel. On that I mounted a filesystem with mode 0755 owned by root.wheel (data of its root node). The OS is 2.2-stable CVSUped lately. By a command (actually CVS checking out the OS source) failing I had to look for a reason why "/usr2/.." from within a subdirectory of "/usr2" could not get accessed. It looked all fine to me. Read and execute permissions for everyone so no good reason to fail I thought except some bug or problem with the filesystem. A few minutes later I thought about it again and came to the conclusion that the underlaying mount point might be the problem and it really was. The more rigorous permissions on the mount point inhibited doing even a complete "ls -la" in "/usr2" - it failed to stat ".." while all other entries were accessible. Should the mount point really influence permissions this way w/o giving any indication of this? Or is this behavior unintentional? Is it worth a PR? Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 07:32:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01858 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 07:32:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01792; Thu, 2 Jul 1998 07:31:33 -0700 (PDT) (envelope-from sos) Message-Id: <199807021431.HAA01792@hub.freebsd.org> Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 03:34:07 pm" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 07:31:33 -0700 (PDT) Cc: luigi@labinfo.iet.unipi.it, sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > Luigi Rizzo writes: > > > It's not that simple. You have to know how long to wait, which is > > > practically impossible to do without hooking the timer interrupt and > > > reprogramming it to keep pace with the retrace, and even that is > > > difficult to achieve without a little busy-waiting here and there. > > a little busy waiting is not a lot. What is bad is 10ms waiting > > With a 70 Hz refresh rate, we're talking more like 14 ms in the worst > case, which is pretty darn bad. Yup, but... > > If one can, say, assume that the vertical retrace is never less than > > 1ms, then HZ=2000 should do the job (wakeup at every tick...). > > Ah, I didn't think of it quite like that. Yes, it would work, and you > wouldn't have to busy-wait at all; just wake up at every tick, check > if you're in a retrace, and if you are, do your job. You will have to be more accurate than that... Its right that you have to wait ~14ms, but the window of opportunity (ie in the blanking period) is only about 330 usecs long, and you have to hit it pretty accurately (ie within a few 10 usec) to be able to do the transfer without shooting over the edge. So there goes that idea, belive me I've thought of this before :) Besides rasing the clock that drastically will impact on our slower customers, I'd say generally its a bad idea... (And I did the code that allows it for the pca device, hi hi hi) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 07:56:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA05032 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 07:56:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA05025; Thu, 2 Jul 1998 07:56:27 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA12564; Thu, 2 Jul 1998 15:26:11 +0200 From: Luigi Rizzo Message-Id: <199807021326.PAA12564@labinfo.iet.unipi.it> Subject: Re: timeout granularity (was: Re: Console driver...) To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 15:26:10 +0200 (MET DST) Cc: sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Smørgrav" at Jul 2, 98 03:33:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > With a 70 Hz refresh rate, we're talking more like 14 ms in the worst > case, which is pretty darn bad. > > > If one can, say, assume that the vertical retrace is never less than > > 1ms, then HZ=2000 should do the job (wakeup at every tick...). > > Ah, I didn't think of it quite like that. Yes, it would work, and you > wouldn't have to busy-wait at all; just wake up at every tick, check > if you're in a retrace, and if you are, do your job. actually, if you could only know how far away you are from the retrace (perhaps by reading some status register ?) you could even tolerate a coarser timer. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:26:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09075 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:26:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08990 for ; Thu, 2 Jul 1998 08:26:15 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id LAA18068; Thu, 2 Jul 1998 11:26:00 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <15895.899343408@time.cdrom.com> References: Your message of "Wed, 01 Jul 1998 16:18:44 EDT." Date: Thu, 2 Jul 1998 11:29:51 -0400 To: "Jordan K. Hubbard" From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:36 PM -0700 7/1/98, Jordan K. Hubbard wrote: >> My initial reaction is that I wouldn't want links to depend on values >> in environment variables. If I setup some "clean environment" for a >> program I'm exec-ing, I'm not going to think to copy values which are >> important for these links to work. > > If you have ever used Apollo's Domain/OS, the advantages of having > synlink behavior be configurable by something as dynamic as the user's > environment become very quickly apparent. :) There's a difference between "being dynamically configurable" and "being part of a namespace which users, scripts, and programs are already clobbering on a regular basis with no current need to worry what that might do to filesystem access". I should note that I do want something that's readily configurable. I just don't think the user-environment is the best place to hold that. We'll still be getting programs from many other sources which will blindly manipulate the standard user environment, and which will not be worried about what that might do to file system access. I would be a little more specific here on what I'd like to see for that, but I haven't quite settled on what that would be... In some sense I'd like a session-level database of keys/values, such that I could type in something in one xterm, and have that effect all active applications (or maybe just all applications which *start* after I enter the command -- even if they are not started from that xterm window). On the other hand, I have a sneaking suspicion that isn't quite what I want either... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:30:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09832 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:30:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA09730 for ; Thu, 2 Jul 1998 08:30:28 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id LAA01885; Thu, 2 Jul 1998 11:29:54 -0400 Date: Thu, 2 Jul 1998 11:29:54 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: RE: timeout granularity (was: Re: Console driver...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998 sbabkin@dcn.att.com wrote: > The measurements > have shown that handling 115200 bps transfer caused 11520 > interrupts per second and ate up about 20% CPU of 20 MHz 386 > in the interrupt handler. The OS was SCO Unix 3.2.1. Interesting. One the 486/25, linux 1.0.xx, the 10k interrupts also seemed to eat about 20% of the machine. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:34:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10745 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:34:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yoda.pi.musin.de (yoda.pi.musin.de [194.246.250.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10681 for ; Thu, 2 Jul 1998 08:34:22 -0700 (PDT) (envelope-from sec@yoda.pi.musin.de) Received: (from sec@localhost) by yoda.pi.musin.de (8.8.8/8.8.8) id RAA19376; Thu, 2 Jul 1998 17:33:45 +0200 (CEST) (envelope-from sec) Message-ID: <19980702173344.A19078@yoda.pi.musin.de> Date: Thu, 2 Jul 1998 17:33:44 +0200 From: Stefan Zehl To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running References: <19980630162115.C2179@yoda.pi.musin.de> <199806301724.KAA06707@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.6i In-Reply-To: <199806301724.KAA06707@dingo.cdrom.com>; from Mike Smith on Tue, Jun 30, 1998 at 10:24:01AM -0700 I-love-doing-this: really X-URL: http://sec.42.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 30, 1998 at 10:24:01AM -0700, Mike Smith wrote: > > I have not much expirience in fs/kernel hacking, but i will try. I think > > i will start by taking an renamed conpy of procfs and modify it to make > > it more linux'ish. This could then be seperately loaded as an lkm. Do > > you think this is the right way to go ? If so, what would be a good name > > for it ? lprocfs ? > > It should be part of the emulator itself; when you load the emulator, > it should mount, when you unload the emulator, it should unmount. Oh, but I have no idea how to archive this. I guess i need some help how to do this, then. > > Would it be a showstopper if i did this for 2.2-STABLE instead of > > -CURRENT ? (my only scrapbox is currently running -stable) > > It would make life *very* difficult for bringing it forwards, yes. Ah, I see. I've been meaning to try out current for some time now. I guess that's the reason i've been waiting for :-) CU, Sec -- Komme wieder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:40:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12160 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:40:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA11960; Thu, 2 Jul 1998 08:39:39 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA12590; Thu, 2 Jul 1998 16:09:37 +0200 From: Luigi Rizzo Message-Id: <199807021409.QAA12590@labinfo.iet.unipi.it> Subject: Re: timeout granularity (was: Re: Console driver...) To: sos@FreeBSD.ORG Date: Thu, 2 Jul 1998 16:09:36 +0200 (MET DST) Cc: smoergrd@oslo.geco-prakla.slb.com, nick.hibma@jrc.it, hackers@FreeBSD.ORG In-Reply-To: <199807021431.HAA01792@hub.freebsd.org> from "sos@FreeBSD.ORG" at Jul 2, 98 07:31:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Its right that you have to wait ~14ms, but the window of opportunity > (ie in the blanking period) is only about 330 usecs long, and you have ok, that (330us) was the thing i did not know and makes the idea not working. > Besides rasing the clock that drastically will impact on our > slower customers, I'd say generally its a bad idea... up to 1000 perhaps wouldn't be that bad though. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:48:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14187 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:48:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA14123 for ; Thu, 2 Jul 1998 08:48:30 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA12618; Thu, 2 Jul 1998 16:18:35 +0200 From: Luigi Rizzo Message-Id: <199807021418.QAA12618@labinfo.iet.unipi.it> Subject: Re: timeout granularity (was: Re: Console driver...) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Thu, 2 Jul 1998 16:18:34 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Ron G. Minnich" at Jul 2, 98 09:16:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 2 Jul 1998, Luigi Rizzo wrote: > > polling if the test is successful. Sooner or later hopefully we > > will move to large values of HZ anyways. > > good point. I've experimented with HZ of 10,000 on a 486-25. 10K was a > bit large for this machine, but 2500 was no problem. What's the largest > HZ anyone out there has used? I'd expect that 10K or 20K would not be a > real problem. Anyone know? > > ron > p.s. no, time did not run fast. I put pre-scaling in hardclock so all was > well. do you have a patch for the above ? I think most things work fine with HZ>100 but i have heard that NTP has problems with it. (i like to use higher values of HZ for many applications) 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:51:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14875 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:51:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14818 for ; Thu, 2 Jul 1998 08:51:42 -0700 (PDT) (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.8/8.8.8) with ESMTP id IAA02437; Thu, 2 Jul 1998 08:50:53 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 11:29:51 EDT." Date: Thu, 02 Jul 1998 08:50:53 -0700 Message-ID: <2433.899394653@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I should note that I do want something that's readily configurable. > I just don't think the user-environment is the best place to hold that. I'm not arguing that the user environment is a poor second choice when compared to a nice, clean private namespace somewhere (or even just sysctl(3), though I suspect you'd want something more dynamic than that). What I guess I'm trying to say is that my personal definition of "readily configurable" for most of the existing tools more or less _requires_ this behavior. If you know, for example, that an existing application is using its environment as a configuration database of sorts (not an uncommon situation), you can take advantage of that knowledge in various interesting ways. Let's say, for example, that you had a program which saved its configuration options into one file and you really wanted that to be a user-specific file because several people were sharing the application now. Let's also say that other docs and general poking around revealed that the invoking user's name was stashed in an environment variable called USER - you can now exploit that knowledge by replacing the configuration file with a v-symlink of ``/tmp/dotfiles/${USER}.thisapp.conf'' or something. As sef has already noted, however, there are still problems with the "let's make it totally transparent" approach. In storing a bunch of v-symlinks in a tar file, for example, you might want to have those v-symlinks left unexpanded so that you can copy them from one place to another with tar/pax/whatever without destroying them. I haven't been able to think of any really clean solutions to this one yet. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:52:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15083 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:52:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14638; Thu, 2 Jul 1998 08:51:00 -0700 (PDT) (envelope-from sos) Message-Id: <199807021551.IAA14638@hub.freebsd.org> Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: <199807021409.QAA12590@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 2, 98 04:09:36 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 2 Jul 1998 08:50:55 -0700 (PDT) Cc: sos@FreeBSD.ORG, smoergrd@oslo.geco-prakla.slb.com, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Luigi Rizzo who wrote: > > Its right that you have to wait ~14ms, but the window of opportunity > > (ie in the blanking period) is only about 330 usecs long, and you have > > ok, that (330us) was the thing i did not know and makes the idea not > working. Always study the problem at hand carefully :) > > Besides rasing the clock that drastically will impact on our > > slower customers, I'd say generally its a bad idea... > > up to 1000 perhaps wouldn't be that bad though. And what would that buy us ?? not much I'm afraid -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 08:59:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16860 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 08:59:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA16848 for ; Thu, 2 Jul 1998 08:59:06 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id LAA11573; Thu, 2 Jul 1998 11:59:03 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id LAA13161; Thu, 2 Jul 1998 11:20:09 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id KAA15866; Thu, 2 Jul 1998 10:52:26 -0400 (EDT) Date: Thu, 2 Jul 1998 10:52:26 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807021452.KAA15866@lakes.dignus.com> To: drosih@rpi.edu, jkh@time.cdrom.com Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG In-Reply-To: <15895.899343408@time.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan writes: > > > My initial reaction is that I wouldn't want links to depend on values > > in environment variables. If I setup some "clean environment" for a > > program I'm exec-ing, I'm not going to think to copy values which are > > important for these links to work. > > If you have ever used Apollo's Domain/OS, the advantages of having > synlink behavior be configurable by something as dynamic as the user's > environment become very quickly apparent. :) > > - Jordan > Well - after working with Domain/OS for several years; I'd have to count this symlink behaviour as one of the least-pratical features. [Although, it sounded good from the start.] What we discovered for decent-sized projects (i.e. more than 1000 source files) was that the proper environment management required to ensure every symlink was "real" became more-and-more cumbersome. And, provided little return for the investment. Eventually, we concluded that the fact that a symlink can change because of an 'external' influence was a bad idea. Imagine, driving home in your red car works, but when you borrow a friend's car because your's is in the shop, (i.e. log in to someone elses machine), you can't find your way home (the streets have changed.) Furthermore, imagine that to get to your house requires a red car. It is then imcumbent on all the visitors to your house to use a red car... it can get quite frustrating... In deliverying products in this environment - we would frequently be called on problems because people couldn't find 'component X'. Our response would be "did you set blah-de-blah environment variable?" We would find that they had set it previously, but not in a permanent fashion, and, after logging on, nothing worked... So, given my experience - I'd prefer to not have this feature in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?) to globally disable it at an installation... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 09:10:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19518 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 09:10:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@[208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19465 for ; Thu, 2 Jul 1998 09:10:10 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-78.camalott.com [208.229.74.78]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id LAA04108; Thu, 2 Jul 1998 11:03:31 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id LAA02923; Thu, 2 Jul 1998 11:03:50 -0500 (CDT) (envelope-from joelh) Date: Thu, 2 Jul 1998 11:03:50 -0500 (CDT) Message-Id: <199807021603.LAA02923@detlev.UUCP> To: smoergrd@oslo.geco-prakla.slb.com CC: nick.hibma@jrc.it, hackers@FreeBSD.ORG In-reply-to: (smoergrd@oslo.geco-prakla.slb.com) Subject: Re: Console driver (was: Problems with irq 9(2)?) From: Joel Ray Holveck Reply-to: joelh@gnu.org References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > However, no VGA board that I know of will exhibit snow while in text > mode, so waiting for vertical retrace is not necessary. It should not > be removed, though, as older CGA and MDA boards require it; but it > could be turned into a kernel option. If you feel very strongly about > this, cut'n'paste this article into send-pr and somebody will get > around to it. Inasmuch as I am suprised, I have noticed snow on my VGA board when switching between vty's. I'm using a generic VLB card with an ET-4000 and a 20C491 RAMDAC. I'm not complaining, I'm just observing. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 10:07:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28138 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 10:07:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA28131 for ; Thu, 2 Jul 1998 10:07:29 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id NAA02473; Thu, 2 Jul 1998 13:06:24 -0400 Date: Thu, 2 Jul 1998 13:06:24 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: <199807021418.QAA12618@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > do you have a patch for the above ? I think most things work fine with > HZ>100 but i have heard that NTP has problems with it. well, this is embarassing. I did the patch on linux and the machine crashed and took the hard disk with it ... all i did was changed the constant put into the timer interrupt by dividing it by a constant factor. Then in hardclock I counted that constant factor times as many interrupts before causing a softclock interrupt. That way, I kept accurate time. I made it a compile time constant so that a rebuild of the clock code would allow me to tweak it. The test was to vary the interrupt rate and then run a program that counted to 10e10. I measured the wall-clock time it took the program to complete. at 2500 interrupts per second the degradation was (maybe) 1%. At 10k IPS degradation was at about 20%. This was a 486/25. I expect we now with P200+ have lots of power to accomodate 10k IPS but I have not tried it. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 10:37:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA02468 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 10:37:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA02463 for ; Thu, 2 Jul 1998 10:37:29 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Jul 2 12:37 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id MAA26793 for ; Thu, 2 Jul 1998 12:37:25 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 2 Jul 1998 13:37:23 -0400 Message-ID: To: rminnich@Sarnoff.COM, hackers@FreeBSD.ORG Subject: RE: timeout granularity (was: Re: Console driver...) Date: Thu, 2 Jul 1998 13:37:22 -0400 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 Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Ron G. Minnich [SMTP:rminnich@Sarnoff.COM] > > On Thu, 2 Jul 1998 sbabkin@dcn.att.com wrote: > > The measurements > > have shown that handling 115200 bps transfer caused 11520 > > interrupts per second and ate up about 20% CPU of 20 MHz 386 > > in the interrupt handler. The OS was SCO Unix 3.2.1. > > Interesting. One the 486/25, linux 1.0.xx, the 10k interrupts also > seemed to > eat about 20% of the machine. > That handler worked with plain ring buffers and had no complex processing, at most it called wakeup() to schedule the higher level routine when it reached the low water mark. It was not a generic serial port driver, it used special protocol to use a slow PC as fast terminal. So it worked at 115Kbps or 56Kbps (the XTs were not able to handle over 56Kbps, ATs worked well with 115Kbps) for output and not more that 100 bytes per second (this was part of the protocol) for input from keyboard. This asymmetric design was also the reason why the lost interrupts were not a problem. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 10:40:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03001 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 10:40:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA02925; Thu, 2 Jul 1998 10:40:17 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00803; Thu, 2 Jul 1998 10:40:17 -0700 (PDT) Message-Id: <199807021740.KAA00803@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=), sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) In-reply-to: Your message of "Thu, 02 Jul 1998 15:26:10 +0200." <199807021326.PAA12564@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 02 Jul 1998 10:40:17 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id KAA02943 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > With a 70 Hz refresh rate, we're talking more like 14 ms in the worst > > case, which is pretty darn bad. > > > > > If one can, say, assume that the vertical retrace is never less than > > > 1ms, then HZ=2000 should do the job (wakeup at every tick...). > > > > Ah, I didn't think of it quite like that. Yes, it would work, and you > > wouldn't have to busy-wait at all; just wake up at every tick, check > > if you're in a retrace, and if you are, do your job. > > actually, if you could only know how far away you are from the retrace > (perhaps by reading some status register ?) you could even tolerate a > coarser timer. Timer delivery for a value X is always > now + X, courtesy of splclock(). Please believe Soren when he says that this is simply not workable. If you *really* want to improve this, you should be thinking about how to enable the hardware cursor on your favorite video adapters. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 10:58:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06169 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 10:58:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06100 for ; Thu, 2 Jul 1998 10:57:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00929; Thu, 2 Jul 1998 10:58:10 -0700 (PDT) Message-Id: <199807021758.KAA00929@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Stefan Zehl cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Staroffice 4.0 sp3 running In-reply-to: Your message of "Thu, 02 Jul 1998 17:33:44 +0200." <19980702173344.A19078@yoda.pi.musin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 10:58:10 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, Jun 30, 1998 at 10:24:01AM -0700, Mike Smith wrote: > > > I have not much expirience in fs/kernel hacking, but i will try. I think > > > i will start by taking an renamed conpy of procfs and modify it to make > > > it more linux'ish. This could then be seperately loaded as an lkm. Do > > > you think this is the right way to go ? If so, what would be a good name > > > for it ? lprocfs ? > > > > It should be part of the emulator itself; when you load the emulator, > > it should mount, when you unload the emulator, it should unmount. > > Oh, but I have no idea how to archive this. I guess i need some help how > to do this, then. You can print it out and file it. You could burn it on a CD. You could tell it to all your neighbours. Oops, typo. 8) On further consideration, it should probably be a separate filesystem LKM (like most of the others can be). The /usr/bin/linux script should load it and mount it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:07:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07746 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:07:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mindcrime.termfrost.org (mindcrime.termfrost.org [208.141.2.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA07738 for ; Thu, 2 Jul 1998 11:07:21 -0700 (PDT) (envelope-from mandrews@termfrost.org) Received: from localhost (mandrews@localhost) by mindcrime.termfrost.org (8.9.0/8.9.0/mindcrime-19980623) with SMTP id OAA17114; Thu, 2 Jul 1998 14:06:52 -0400 (EDT) (envelope-from mandrews@termfrost.org) Date: Thu, 2 Jul 1998 14:06:52 -0400 (EDT) From: Mike Andrews To: Greg Lehey cc: "Daniel O'Connor" , freebsd-hackers@FreeBSD.ORG Subject: Re: Serial port problems fixed with patch In-Reply-To: <19980630125941.P1880@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For what it's worth, I have an old Compaq Contura Aero -- a 486sx/25 laptop computer circa 1994. Neither the onboard serial ports, nor any PCMCIA modems, would work until I put -stable with the June 16th sio.c on it. Works great now. I don't know what kind of mutant UARTs Compaq put in the thing, but it's not specific to Iwill motherboards at any rate... Mike Andrews (MA12) icq 6602506 -------------- mandrews@dcr.net Senior Systems/Network Administrator --- mandrews@termfrost.org Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "Eagles may soar, but weasels don't get sucked into jet engines." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU d- s: a- C++ UBX++++ P++ L+ !E W+++ N++ K++ w--- O+ M+ V+++ PS+++ PE- Y+ !t !5 !X !R tv- b+ DI++ D++ e++ h++ r++ y++*@ -----END GEEK CODE BLOCK----- On Tue, 30 Jun 1998, Greg Lehey wrote: > On Tuesday, 30 June 1998 at 12:41:26 +0930, Daniel O'Connor wrote: > > > >> It would be more interesting if you would install the latest -current > >> or -stable and see if the serial driver there works. It does on my > >> IWill motherboard with 2.2-stable. > > > > OK.. I have a fairly old current on there ATM v1.199 of sio.c > > I'll upgrade when I get some time :) > > Any idea what is a nice version of -current to go to? > > The latest and greatest. The last relevant change to sio.c was on 16 > June. > > Greg > -- > See complete headers for address and phone numbers > finger grog@lemis.com for PGP public key > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:14:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09369 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:14:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09331 for ; Thu, 2 Jul 1998 11:14:23 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01087; Thu, 2 Jul 1998 11:13:22 -0700 (PDT) Message-Id: <199807021813.LAA01087@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Thomas David Rivers cc: drosih@rpi.edu, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 10:52:26 EDT." <199807021452.KAA15866@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 11:13:22 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So, given my experience - I'd prefer to not have this feature > in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?) > to globally disable it at an installation... How about "just don't use it"? The point here is that it's an enabling technology, not an intentional constriction of freedom. If you don't want it or can't manage it properly, you don't have to use it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:17:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09790 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:17:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09716 for ; Thu, 2 Jul 1998 11:16:42 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01116; Thu, 2 Jul 1998 11:17:14 -0700 (PDT) Message-Id: <199807021817.LAA01116@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Percy Cheng cc: hackers@FreeBSD.ORG Subject: Re: About FreeBSD boot manager... In-reply-to: Your message of "Thu, 02 Jul 1998 20:20:31 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 11:17:14 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I just want to know would BootEasy need a primary > partition to master the booting? It can only boot from primary partitions, yes. > If I want to install win95, win98 and FreeBSD in > 3 different primary partition, and make the last one to > Extended partition, does BootEasy can manage? Yes, although there are some problems to be careful of here: - all of these filesystems must be within the first 1024 cylinders of the disk in order to be bootable. - the win98 installation may not get along well with the win95 installation (c:\windows != $WINDOWS) > Furthermore, could FreeBSD installed to logical > drive?? Seems it just can find the extened drive and > could not detect the logical drive... No, FreeBSD can't (currently) be booted from a logical drive. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:28:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12043 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:28:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11999; Thu, 2 Jul 1998 11:27:36 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01241; Thu, 2 Jul 1998 11:26:51 -0700 (PDT) Message-Id: <199807021826.LAA01241@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Donn Miller cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg In-reply-to: Your message of "Thu, 02 Jul 1998 01:59:24 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 11:26:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I > want to use this instead of using getloadavg(). The obvious question here is "why"? > I'm also looking for the equivalent of these. This is what I think they > are: > > Linux FreeBSD > ===== ======= > /proc/meminfo /proc/curproc/mem > /proc/stat /proc/curproc/status No. /proc/meminfo is memory information about the machine, while /proc/ curproc/mem is the current process' address space. /proc/stat is random junk, while /proc/curproc/stat is the status of the current process. > /proc/loadavg ??? (probably /kernel) sysctlbyname("vm.loadavg", ...) > /proc/uptime ??? (probably /kernel) The difference between gettimeofday() and sysctlbyname("kern.boottime", ...) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:40:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14604 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:40:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iconmail.bellatlantic.net (iconmail.bellatlantic.net [199.173.162.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA14565; Thu, 2 Jul 1998 11:39:45 -0700 (PDT) (envelope-from dmm125@bellatlantic.net) Received: from bellatlantic.net (client201-122-36.bellatlantic.net [151.201.122.36]) by iconmail.bellatlantic.net (IConNet Sendmail) with ESMTP id OAA25846; Thu, 2 Jul 1998 14:36:55 -0400 (EDT) Message-ID: <359B9B21.6DE01652@bellatlantic.net> Date: Thu, 02 Jul 1998 14:37:21 +0000 From: Donn Miller X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) MIME-Version: 1.0 To: Mike Smith CC: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg References: <199807021826.LAA01241@antipodes.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > > > Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I > > want to use this instead of using getloadavg(). > > The obvious question here is "why"? I just figured that some Linux programs were trying to obtain load average info that way, and to ease porting, well, I wanted to open the equivalent FreeBSD file. I realize now though that if you want to port some apps with low-level details, you gotta do a little reworking. I was trying to port wmmon from WindowMaker. It's just for Linux now. In addition, the app tries to obtain loadaverage, uptime, and memory info about the machine like this: (from wmmon.c) FILE *fp_meminfo; FILE *fp_stat; FILE *fp_loadavg; /*.....*/ fp = fopen("/proc/uptime", "r"); fp_meminfo = fopen("/proc/meminfo", "r"); fp_loadavg = fopen("/proc/loadavg", "r"); fp_stat = fopen("/proc/stat", "r"); > > > I'm also looking for the equivalent of these. This is what I think they > > are: > > > > Linux FreeBSD > > ===== ======= > > /proc/meminfo /proc/curproc/mem > > /proc/stat /proc/curproc/status > > No. /proc/meminfo is memory information about the machine, while /proc/ > curproc/mem is the current process' address space. /proc/stat is > random junk, while /proc/curproc/stat is the status of the current > process. > > > /proc/loadavg ??? (probably /kernel) > > sysctlbyname("vm.loadavg", ...) > > > /proc/uptime ??? (probably /kernel) > > The difference between gettimeofday() and sysctlbyname("kern.boottime", ...) > --Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 11:51:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17245 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 11:51:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles224.castles.com [208.214.165.224]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17154; Thu, 2 Jul 1998 11:51:03 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01417; Thu, 2 Jul 1998 11:50:04 -0700 (PDT) Message-Id: <199807021850.LAA01417@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Donn Miller cc: Mike Smith , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg In-reply-to: Your message of "Thu, 02 Jul 1998 14:37:21 -0000." <359B9B21.6DE01652@bellatlantic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 11:50:04 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > > > > > Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I > > > want to use this instead of using getloadavg(). > > > > The obvious question here is "why"? > > I just figured that some Linux programs were trying to obtain load > average info that way, and to ease porting, well, I wanted to open the > equivalent FreeBSD file. I realize now though that if you want to port > some apps with low-level details, you gotta do a little reworking. Yup. Particularly when you're dealing with code written for Linux (where NIH is considered a virtue...). Consider the Linux approach: FILE *fp; double la[3]; if ((fp = fopen("/proc/loadavg")) == NULL) error(); if (fscanf(fp, "%f %f %f", la, la+1, la+2) != 3) error(); fclose(fp); vs. double la[3]; if (sysctlbyname("vm.loadavg", NULL, 0, la, sizeof(la))) error(); Now rank them on simplicity, efficiency, and adherence to KISS. 8) > I was trying to port wmmon from WindowMaker. It's just for Linux now. > In addition, the app tries to obtain loadaverage, uptime, and memory > info about the machine like this: (from wmmon.c) > > FILE *fp_meminfo; > FILE *fp_stat; > FILE *fp_loadavg; > > > /*.....*/ > fp = fopen("/proc/uptime", "r"); > fp_meminfo = fopen("/proc/meminfo", "r"); > fp_loadavg = fopen("/proc/loadavg", "r"); > fp_stat = fopen("/proc/stat", "r"); Any application written to use the Linux idea of "memory use" is not going to work well when presented with the way that FreeBSD uses memory. You're probably up for seriously reworking this - have a look at the way that systat gets the numbers you're interested in. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 12:37:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23917 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 12:37:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA23897 for ; Thu, 2 Jul 1998 12:37:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA03015; Thu, 2 Jul 1998 19:37:17 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA18307; Thu, 2 Jul 1998 21:37:16 +0200 (MET DST) Message-ID: <19980702213716.37183@follo.net> Date: Thu, 2 Jul 1998 21:37:16 +0200 From: Eivind Eklund To: Terry Lambert , Joe Abley Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads References: <199807020045.RAA00880@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199807020045.RAA00880@usr07.primenet.com>; from Terry Lambert on Thu, Jul 02, 1998 at 12:44:59AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 02, 1998 at 12:44:59AM +0000, Terry Lambert wrote: > John Dyson did a number of patches for CPU affinity and a number of > other things, which were necessary to make a kernel implementation > useful at all (so far as I know, these were distributed from his > FreeBSD home directory, so they have sonce been removed from > circulation. 8-(. Someone correct me if they snagged a copy before > that happened and are willing to share). They've been lying around at http://www.freebsd.org/~eivind/sysjun07b.diff.gz all this time, and still are there. I don't think it would have been difficult to get the from John, either, but given that I have them, it shouldn't be necessary. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 12:38:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA24079 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 12:38:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA24074 for ; Thu, 2 Jul 1998 12:38:53 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA28401; Thu, 2 Jul 1998 12:35:07 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028389; Thu Jul 2 19:35:02 1998 Date: Thu, 2 Jul 1998 12:34:58 -0700 (PDT) From: Julian Elischer To: "Ron G. Minnich" cc: hackers@FreeBSD.ORG Subject: RE: timeout granularity (was: Re: Console driver...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG why do all that fiddling when there is already support for this in FreeBSD? use "aquire_timer0()" and set the hardware clock to whatever you want dynamically.. it will call whatever function you want at that speed.. remember that the pcaudio driver sets it to 16000 Hz. that would seem a good speed to set it, so that pcaudio could still work.. On Thu, 2 Jul 1998, Ron G. Minnich wrote: > > On Thu, 2 Jul 1998 sbabkin@dcn.att.com wrote: > > The measurements > > have shown that handling 115200 bps transfer caused 11520 > > interrupts per second and ate up about 20% CPU of 20 MHz 386 > > in the interrupt handler. The OS was SCO Unix 3.2.1. > > Interesting. One the 486/25, linux 1.0.xx, the 10k interrupts also seemed to > eat about 20% of the machine. > > ron > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 13:24:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01571 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 13:24:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA01566 for ; Thu, 2 Jul 1998 13:24:19 -0700 (PDT) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id QAA03702; Thu, 2 Jul 1998 16:23:47 -0400 Date: Thu, 2 Jul 1998 16:23:47 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: RE: timeout granularity (was: Re: Console driver...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Julian Elischer wrote: > why do all that fiddling when there is already support for this in > FreeBSD? > use "aquire_timer0()" > and set the hardware clock to whatever you want dynamically.. First answer: cause I did this three years ago ... Second answer: cause I did not know anyway :-) Thanks Julian. I'm saving this one for later use. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 13:31:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03501 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 13:31:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03491; Thu, 2 Jul 1998 13:31:29 -0700 (PDT) (envelope-from sos) Message-Id: <199807022031.NAA03491@hub.freebsd.org> Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: from Julian Elischer at "Jul 2, 98 12:34:58 pm" To: julian@whistle.com (Julian Elischer) Date: Thu, 2 Jul 1998 13:31:28 -0700 (PDT) Cc: rminnich@Sarnoff.COM, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Julian Elischer who wrote: > why do all that fiddling when there is already support for this in > FreeBSD? > > use "aquire_timer0()" > and set the hardware clock to whatever you want dynamically.. > it will call whatever function you want at that speed.. > remember that the pcaudio driver sets it to 16000 Hz. > that would seem a good speed to set it, so that pcaudio could still work.. > Since I'm the one to blame for the aquire_timer stuff, also a fair bit of warning, it ONLY works for one process at a time, and it doesn't increase the resolution of tsleep et all. A higher resolution of the timeout stuff would be neat, but it wouldn't solve the video probelm... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 14:22:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11523 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 14:22:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11512; Thu, 2 Jul 1998 14:22:04 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-108.camalott.com [208.229.74.108]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id QAA05870; Thu, 2 Jul 1998 16:18:55 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id QAA06797; Thu, 2 Jul 1998 16:18:53 -0500 (CDT) (envelope-from joelh) Date: Thu, 2 Jul 1998 16:18:53 -0500 (CDT) Message-Id: <199807022118.QAA06797@detlev.UUCP> To: mike@smith.net.au CC: dmm125@bellatlantic.net, mike@smith.net.au, questions@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: <199807021850.LAA01417@antipodes.cdrom.com> (message from Mike Smith on Thu, 02 Jul 1998 11:50:04 -0700) Subject: Re: FreeBSD equiv. of /proc/loadavg From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199807021850.LAA01417@antipodes.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I realize now though that if you want to port some apps with >> low-level details, you gotta do a little reworking. > Yup. Particularly when you're dealing with code written for Linux > (where NIH is considered a virtue...). What's NIH? Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 14:44:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14629 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 14:44:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA14588 for ; Thu, 2 Jul 1998 14:44:21 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from (ragnet.demon.co.uk) [158.152.46.40] by post.mail.demon.net with smtp (Exim 1.82 #2) id 0yrr9K-0000x4-00; Thu, 2 Jul 1998 21:44:14 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 0yrr70-0003Eh-00; Thu, 2 Jul 1998 22:41:50 +0100 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 02 Jul 1998 22:41:50 +0100 (BST) From: Duncan Barclay To: freebsd-hackers@FreeBSD.ORG Subject: Pkg_create and setting directory ownership. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I'm trying to get pkg_create (on -2.2.6) to set the ownership of some directories for a package I'm building. The problem is that the @owner directive only affects the files listed in the plist. If you list a directory the whole tree below that point is added to the final package tar file. I reckon that either the @owner (and @group) directive is not clever enough or the tar building is wrong in pkg_create: at least one of these is exhibiting wrong behaviour? I could use a specific mtree file or do what I'm currently doing and adding a @exec chmod into the plist. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 15:09:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18521 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 15:09:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18504 for ; Thu, 2 Jul 1998 15:09:01 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id SAA49756; Thu, 2 Jul 1998 18:06:54 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807021813.LAA01087@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 10:52:26 EDT." <199807021452.KAA15866@lakes.dignus.com> Date: Thu, 2 Jul 1998 18:10:44 -0400 To: Mike Smith , Thomas David Rivers From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:13 AM -0700 7/2/98, Mike Smith wrote: >> >> So, given my experience - I'd prefer to not have this feature >> in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?) >> to globally disable it at an installation... > > How about "just don't use it"? The point here is that it's an enabling > technology, not an intentional constriction of freedom. If you don't > want it or can't manage it properly, you don't have to use it. Enabling technology will probably be attractive to people working on ports. I suspect many of us will find ourselves using it, whether we are personally thrilled with it or not. Certainly the idea of using {arch} to distinguish between alpha-specific vs intel-specific files would be immediately attractive, for instance. I'm just asking what the best (most reliable) implementation might be for this variable symlink facility. In my case, I'm only using freebsd for my own personal stuff, so I am not too concerned about how it's implemented. As you say, if it is too dangerous then I simply will not use it. It'd be a pity to implement an enabling technology which is too dangerous to use, but that shouldn't be any skin off my own personal teeth. However, I am also thinking how this capability would work in an environment like the unix (AIX, Solaris, IRIX) environment at RPI. I don't mean, "how would it work under AIX?", I mean "what would it be like if RPI replaced all public unix machines with freebsd machines which have this implemented via environment variables?". My guess is that it would be a nightmare when it came to end-user support. I think there would be less headaches all-around if symlinks did not key off environment variables, although I do think we'd want them to key off of something as simple to adjust as environment variables are. I must admit I can't quite come up with an excellent alternative. I think I want something which works quite a bit like environment variables, but which are at least in a separate namespace (so values aren't clobbered when some script happens to use a name which is also used in some symlink). In some sense I'm basing my thoughts on (what seems to me) a principle here. Symlinks are embedded in the filesystem, and as such they are global in nature. These global values "should not" (in some philosophical sense) depend on something as ephemeral and constantly changing as the user's environment. Yes, you will want to change it's effective value on a "local" basis (such as in one shell in one window), but the symlink itself is a global value. I realize I'm not contributing any particularly good answers here, but I thought it would worthwhile to discuss alternatives, instead of simply rushing out and recreating the Apollo implementation because that was known to be useful in some situations. Perhaps we can come up with something just as useful, but with less potential for pitfalls. Certainly we won't if we just dismiss the discussion by saying "Well, if you don't like it, don't use it". --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 15:47:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24788 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 15:47:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24774 for ; Thu, 2 Jul 1998 15:47:00 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id SAA37432; Thu, 2 Jul 1998 18:46:55 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <2433.899394653@time.cdrom.com> References: Your message of "Thu, 02 Jul 1998 11:29:51 EDT." Date: Thu, 2 Jul 1998 18:50:46 -0400 To: "Jordan K. Hubbard" From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:50 AM -0700 7/2/98, Jordan K. Hubbard wrote: >> I should note that I do want something that's readily configurable. >> I just don't think the user-environment is the best place to hold that. > > I'm not arguing that the user environment is a poor second choice > when compared to a nice, clean private namespace somewhere (or even > just sysctl(3), though I suspect you'd want something more dynamic > than that). > > What I guess I'm trying to say is that my personal definition of > "readily configurable" for most of the existing tools more or less > _requires_ this behavior. [...skipping along ...] > Let's also say that other docs and general poking around revealed > that the invoking user's name was stashed in an environment variable > called USER - you can now exploit that knowledge by replacing the > configuration file with a v-symlink of > ``/tmp/dotfiles/${USER}.thisapp.conf'' > or something. Let me take this specific example, and argue against symlinks that are based on environment variables for multiple reasons. (at least as far as I understand the issues in the example) What you're arguing for here is a symlink based on the unix userid, which certainly is a good candidate for a system-wide variable. All the example shows is that the system should create such a variable for use in symlinks. The example does not prove that the value is "required" to be an environment variable. Also, given the specific key of "USER", that is a value that shells or something else in the login process often sets. As it happens, I once wrote a 'install' script which wrote that very value out to a log file (just to track who was installing what, when...), and I later found that in some makefiles that didn't work. Why? Because the makefile itself defined "USER" to mean something else (the list of user-level programs, as opposed to administrator-type programs). As this shows, most "nice, pretty and convenient" names for use in symlinks are going to be words which are just as "nice, pretty and convenient" for everything else which plays around with the user environment. However, let's say the program itself happens to set an environment variable called "PROGUSER", and you're going to use that. You do not depend on the user themselves remembering to set this variable (which is good (*)), because you know the program itself sets the value before it reads the configuration file. The user runs the program, the program goes to the desired config file, and it happens that the config file isn't exactly what the user wants. They quit the program, and edit the config file via the symlink (because they know that's what *program* opens), and not the target of the symlink. But when they go to do that, the PROGUSER variable is not set, so they do *not* get the same filename that the program itself is using. Just imagine how many times they'll swear at the program because it isn't being effected by changes to it's config file, before they realize that they're editting a different file (especially for the users who did not actually create the symlink which references the environment variable). (*) - Let's say the program itself does not set the environment variable. This now means you won't get the expected behavior out of the program unless the user remembers to sent the environment variable. To that I say "Ick". To avoid that, you write a wrapper around the program to set the environment variable before the program starts up, and point the user at that wrapper instead of the real program. To the user, this wrapper is now the real program, and you're right back to where you were (in the previous paragraph) with using a variable that the program itself sets. Certainly it is an attractive idea to base symlinks on environment variables, but maybe we should ask ourselves how hard it would be to implement a "nice clean private namespace somewhere". I think we'll be happier with the separate namespace, something which isn't disrupted as readily and as often as the user environment. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 16:16:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27382 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 16:16:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27376 for ; Thu, 2 Jul 1998 16:16:38 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA29672; Thu, 2 Jul 1998 16:16:35 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd029649; Thu Jul 2 16:16:30 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA12148; Thu, 2 Jul 1998 16:16:22 -0700 (MST) From: Terry Lambert Message-Id: <199807022316.QAA12148@usr09.primenet.com> Subject: Re: pthreads To: rotel@indigo.ie Date: Thu, 2 Jul 1998 23:16:21 +0000 (GMT) Cc: tlambert@primenet.com, jabley@clear.co.nz, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807021321.OAA00589@indigo.ie> from "Niall Smart" at Jul 2, 98 02:21:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > John Birrell rewrote lots of it in -current, with an eye toward > > bringing the code up to the Draft 10 standard (the ratified standard), > > and he and John Dyson did a lot of work to support a kernel > > implementation, also in -current, using rfork() and some rather > > complicated stack management. > > This is basically sharing a number of kernel processes among a set > of threads, right? Do you know if any progress was made towards > a LWP scheme? If John Dyson's async I/O code is in place that > would help a lot on that area I think. The async I/O is easily used to implement a call conversion scheduler; it's not much help in an LWP scheme (in the Solaris, not the SunOS, sense of LWP). What it buys you is overlapped I/O, which you don't really get with the current pthreads implementation (it's more of a "just-in-time" I/O). Far better than simple async I/O would be an async call gate. This would let you make blocking calls that were unrelated to I/O in an async fashion as well (for example, acquisition of a semaphore). Alas, according to POSIX, async I/O is the future (though it could be implemented on an async call gate in a library, and then ignored). The rfork()-based kernel threading is for SMP scalability. It is generally limited to one kernel thread per user space thread. This can be subjugated to N kernel threads for M user space threads, M > N, in two ways. The first is to allow only N blocking calls to be outstanding, and to starve those threads that are ready to run, but waiting on a kernel scheduling context (kernel thread) in which to run. The second is to create a new kernel thread when the blocking threshold (generally by cooperative scheduling: the kernel signals a user space scheduler thread, which wakes up and spawns a kernel thread to add to the thread group). These approached both have problems, but the second has the highest scalability without starvation of its own threads (but it can't be throttled on its competition for quantum without some hard limit that turns it into the first approach when the limit is enforced). > > John Dyson did a number of patches for CPU affinity > > CPU affinity? You mean the threading library can pass scheduling > hints to the kernel for a set of processes? No. CPU affinity is for protection of the L1 and L2 cache contents by making threads "prefer" one CPU over the other(s). It is an important prescondition for SMP scaling of multithreaded applications. Without it, your effective cache is reduced by the Nth root of the cache size, for N processors. Each kernel thread or process is, in the abstract, a kernel schedulable entity. You want to minimize the context switching between kernel schedulable entites. If you make a blocking call on a kernel thread, that kernel thread is preempted, and the competition is thrown open to all other threads/processes to be the next scheduled. This is not very optimal. An optimal implementation would combine an async call gate, which would mean that once you got the quantum, the threaded process got to use all of it, with kernel threads for SMP scalability. There is some merit to kernel threads in terms of saying: There are a total of E kernel schedulable entites on the system; I want my threaded process to get N quanta out of every E quanta ( N << E ). Basically, establishing that a threaded process competes as N processes. The merit in this approach is very small, however, and is predicated on two ideas: (1) that a threaded process will be competing with conventional processes for quantum, and (2) that the process priority system is not sufficient to make the competition "fair". Fairness arguments are always arguments about transitioning from an old system to a new system. > Was this threading model an interim measure until someone wrote one > based on LWP or intended to be the way that it would always be done? Well, opinions are varied; I've presented mine, above. If I had to boil it down to one (long) sentence, I'd say: Once the scheduler gives me a quantum, it's *my* quantum, and I shouldn't be penalized with context switch overhead and losing the remainder of my partially used quantum just because I want to make a system call. > There are a number of problems with this approach (outlined in > a paper called "Scheduler Activations: Effective Kernel Support for > the User Level Management of Parallelism", ask me for a copy if you > want one) althought it is much easier to implement than a LWP based > model. I've read the "activations" paper. I don't like them; they imply a message passing architecture. There are also unaddressed starvation issues that occur when you are ready to block and some other thread in your group is ready to run. Without an overall accounting of quanta outside your programs virtual machine, there are problems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 16:33:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28758 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 16:33:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28750 for ; Thu, 2 Jul 1998 16:33:09 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt3-163.HiWAAY.net [208.147.146.163]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id SAA27908; Thu, 2 Jul 1998 18:33:08 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id IAA17009; Thu, 2 Jul 1998 08:44:05 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199807021344.IAA17009@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: wjw@IAEhv.nl cc: hackers@FreeBSD.ORG From: David Kelly Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-reply-to: Message from Willem Jan Withagen of "Thu, 02 Jul 1998 09:36:27 +0200." <199807020736.JAA10898@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 08:44:05 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Willem Jan Withagen writes: > > The tapes were written on a DAT (old non compressing) but for writting them > I had to specify tar cbf 20 /dev/tape > And I think it is this blocking factor which prevents me from even dd-ing > data from the tape. :-( > > Maybe I'll have to go to somebody with a driver which does 10K blocks? As others have said, I don't understand what problem you are having yet as FreeBSD's drivers can handle up to 64k blocks. I'd like to see that size increased as often I have to deal with SGI tar tapes which default at 126k for 8mm and 256k for 4mm. Is it possible the byte order is reversed on Apollo tapes so FreeBSD's GNU tar can't make sense of it? I don't see a byte-order option in pax. For dd its "conv=swab". To duplicate your tapes use tcopy(1) if you have two tape drives. Tcopy will figure out what block size is used, and refigure that block size with every block copied. Best that I can tell there are several utilities floating around on the net named "ansitape". At least one of them is capable of storing a tape image on disk, and later restoring that image to tape with the same blocking as the original. At least that's what is claimed, I've not tried it but would like to have a utility that does that. Keep trying to get a "Round Tuit" at work, to enhance tcopy. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 16:36:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29215 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 16:36:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29187; Thu, 2 Jul 1998 16:36:37 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA05666; Thu, 2 Jul 1998 16:36:38 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd005617; Thu Jul 2 16:36:33 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA12912; Thu, 2 Jul 1998 16:36:26 -0700 (MST) From: Terry Lambert Message-Id: <199807022336.QAA12912@usr09.primenet.com> Subject: Re: FreeBSD equiv. of /proc/loadavg To: joelh@gnu.org Date: Thu, 2 Jul 1998 23:36:26 +0000 (GMT) Cc: mike@smith.net.au, dmm125@bellatlantic.net, questions@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199807022118.QAA06797@detlev.UUCP> from "Joel Ray Holveck" at Jul 2, 98 04:18:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> I realize now though that if you want to port some apps with > >> low-level details, you gotta do a little reworking. > > Yup. Particularly when you're dealing with code written for Linux > > (where NIH is considered a virtue...). > > What's NIH? We can't tell you; the use of the term was Not Invented Herei, and thus, like SysV rc.d, we fear and mistrust it... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 16:46:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00300 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 16:46:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00292 for ; Thu, 2 Jul 1998 16:46:09 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id BAA22021; Fri, 3 Jul 1998 01:46:09 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id BAA16546; Fri, 3 Jul 1998 01:46:08 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807022346.BAA16546@surf.IAE.nl> Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-Reply-To: <199807021344.IAA17009@nospam.hiwaay.net> from David Kelly at "Jul 2, 98 08:44:05 am" To: dkelly@hiwaay.net (David Kelly) Date: Fri, 3 Jul 1998 01:46:08 +0200 (MET DST) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You ( David Kelly ) write: => For dd its "conv=swab". => => To duplicate your tapes use tcopy(1) if you have two tape drives. Tcopy Well I can't even dd them of either tape. So I've haven't een gotten into data incompatibility issues Julian suggested RTFM 'mt blocksize'. Which I'll as soon as I reboot to get the tape operational on my FreeBSD box. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 17:00:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA01817 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 17:00:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01812 for ; Thu, 2 Jul 1998 17:00:31 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA13118; Thu, 2 Jul 1998 17:00:32 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd013061; Thu Jul 2 17:00:25 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA14014; Thu, 2 Jul 1998 17:00:21 -0700 (MST) From: Terry Lambert Message-Id: <199807030000.RAA14014@usr09.primenet.com> Subject: Re: Variant Link implementation, continued To: drosih@rpi.edu (Garance A Drosihn) Date: Fri, 3 Jul 1998 00:00:21 +0000 (GMT) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: from "Garance A Drosihn" at Jul 2, 98 06:50:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > However, let's say the program itself happens to set an environment > variable called "PROGUSER", and you're going to use that. You do > not depend on the user themselves remembering to set this variable > (which is good (*)), because you know the program itself sets the > value before it reads the configuration file. The user runs the > program, the program goes to the desired config file, and it > happens that the config file isn't exactly what the user wants. > They quit the program, Bzzzt. The click on "Edit" and then click on "Preferences...". > Certainly it is an attractive idea to base symlinks on environment > variables, but maybe we should ask ourselves how hard it would be > to implement a "nice clean private namespace somewhere". I think > we'll be happier with the separate namespace, something which isn't > disrupted as readily and as often as the user environment. A namespace is a namespace. Your arguments apply no matter where the namespace is located, so long as you permit the user to modify it at all. For the "init" namespace, you don't let the user modify it. This is because what you are in fact modifying is the environment of the "init" process itself. This is, in fact, a "system logical name table". For the "process group leader" or "session leader" (the "group logical name table"), you would, preferentially, make this a session manager program. The session manager program does not need to be owned by the user. There are many good reasons to have a session manager; the main interesting one is to act as a credential holder for credentials and authentications you want shared between processes. The "user logical name table" is the user's environment, as it is currently understood. The only semantic difference that variant symlinks have from VMS logical names is their placement in a filesystem reference. The VMS placement must be as a prefix, and the placement we have been contemplating is "as a path component expansion in a symbolic link target. In point of fact, the concerns about tar'ring up these links was ill-founded: a "readlink" or, reflexively, "symlink" by tar will result in the correct behaviour (tar does not expand the environment, and "readlink" does not evaluate the target, it only reports it). Most of the concerns seem to be of the category "yeah, but if you make it work, people migh actually (shudder!) *use* it!". Something which allows you to do stupid things also allows you to do clever things. The question is whether the value of the clever things outweighs the risk of the stupid things. For the most part, having used systems that provided variant link technology, I have to say that the value of the clever things you can do with them vastly outweighs the risk that comes with them. For example, we could have made the /usr/lib/aout change appear to have zero impact. We could also have done a large number of other things with apparently zero impact, that would allow us to build multiple targets on the same machine, for example, something that the current build environment is not good at. There are numerous other examples that I can bore you with, if you insist... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 17:21:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA04494 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 17:21:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA04484 for ; Thu, 2 Jul 1998 17:21:27 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt3-163.HiWAAY.net [208.147.146.163]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id TAA00977; Thu, 2 Jul 1998 19:21:27 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id TAA18905; Thu, 2 Jul 1998 19:21:25 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199807030021.TAA18905@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Stefan Eggers cc: freebsd-hackers@FreeBSD.ORG From: David Kelly Subject: Re: permission confusion at mount points In-reply-to: Message from Stefan Eggers of "Thu, 02 Jul 1998 12:24:29 +0200." <199807021024.MAA11096@semyam.dinoco.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 19:21:25 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stefan Eggers writes: > Hi! > > I had a directory "/usr2" with mode 0700 owned by root.wheel. On that > I mounted a filesystem with mode 0755 owned by root.wheel (data of its > root node). The OS is 2.2-stable CVSUped lately. [...] > Should the mount point really influence permissions this way w/o > giving any indication of this? Or is this behavior unintentional? > Is it worth a PR? Its that way in every Unix I've used. Can't think of one that it doesn't act up, but somebody would point out the odd system if I was to claim more than I know and say *all* unices. For kicks, "cd /usr2; pwd". Bet it'll fail. Same for SGI's Irix 6.2. Use 755 permissions on your underlying mount point and put the problem out of your misery. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 17:25:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05487 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 17:25:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA05474 for ; Thu, 2 Jul 1998 17:25:34 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt3-163.HiWAAY.net [208.147.146.163]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id TAA03904; Thu, 2 Jul 1998 19:25:31 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id TAA18925; Thu, 2 Jul 1998 19:25:29 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199807030025.TAA18925@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: wjw@IAEhv.nl cc: hackers@FreeBSD.ORG From: David Kelly Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-reply-to: Message from Willem Jan Withagen of "Fri, 03 Jul 1998 01:46:08 +0200." <199807022346.BAA16546@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 19:25:29 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Willem Jan Withagen writes: > You ( David Kelly ) write: > => For dd its "conv=swab". > => > => To duplicate your tapes use tcopy(1) if you have two tape drives. Tcopy > > Well I can't even dd them of either tape. So I've haven't een gotten into > data incompatibility issues > Julian suggested RTFM 'mt blocksize'. Which I'll as soon as I reboot to > get the tape operational on my FreeBSD box. They were written on 4mm DAT? Not something weird like QIC-100? Saw an HP "development system" which wrote QIC-100 format to DC-6150 tapes, I think. Tapes had to be formatted. Then they mounted like a filesystem. Slower than a tax refund. In the early bad old days of DAT (more correctly known as DSS) there were more problems than there should have been with one tape drive not being able to read tapes from another, all other things the same. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 17:27:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05758 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 17:27:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05728; Thu, 2 Jul 1998 17:27:18 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199807030027.RAA05728@hub.freebsd.org> Subject: Re: FreeBSD equiv. of /proc/loadavg In-Reply-To: <199807022336.QAA12912@usr09.primenet.com> from Terry Lambert at "Jul 2, 98 11:36:26 pm" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 2 Jul 1998 17:27:17 -0700 (PDT) Cc: joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@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 Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > >> I realize now though that if you want to port some apps with > > >> low-level details, you gotta do a little reworking. > > > Yup. Particularly when you're dealing with code written for Linux > > > (where NIH is considered a virtue...). > > > > What's NIH? > > We can't tell you; the use of the term was Not Invented Herei, and > thus, like SysV rc.d, we fear and mistrust it... 8-). Oh Terry! i dont like rc.d because i am left which "which of these scripts in which directory did what!" why? grr.... with our current strcuture, we have some separation without reaching the level of cookiness that sunos 5.5.1 provides: 70 shell scripts scattered across 5 directories. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 18:02:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA09968 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 18:02:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ibridge.iohk.com (root@ibridge.iohk.com [202.21.128.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09926 for ; Thu, 2 Jul 1998 18:02:29 -0700 (PDT) (envelope-from percy@iohk.com) Received: from igate.iohk.com (percy@igate.iohk.com [202.21.128.81]) by ibridge.iohk.com (8.8.5/8.8.5) with ESMTP id JAA20561; Fri, 3 Jul 1998 09:04:32 +0800 (HKT) Received: from localhost (percy@localhost) by igate.iohk.com (8.8.5/8.8.5) with SMTP id JAA15752; Fri, 3 Jul 1998 09:04:31 +0800 (HKT) Date: Fri, 3 Jul 1998 09:04:31 +0800 (HKT) From: Percy Cheng To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: About FreeBSD boot manager... In-Reply-To: <199807021817.LAA01116@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Mike Smith wrote: > Yes, although there are some problems to be careful of here: > > - all of these filesystems must be within the first 1024 cylinders of > the disk in order to be bootable. > - the win98 installation may not get along well with the win95 > installation (c:\windows != $WINDOWS) > Thanks for your kind attention, but can I get more detail on : What's mean within 1024 cylinders?? And how much the HDD space can be located within it?? Furthermore, in the second point, does it means may not be posibble if I want to boot win98 with booteasy? Percy Cheng Internet Online Hong Kong Ltd. Our Web Site:http://www.iohk.com My email box:percy@iohk.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 18:03:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA10050 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 18:03:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA10025 for ; Thu, 2 Jul 1998 18:02:58 -0700 (PDT) (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.8/8.8.8) with ESMTP id SAA05410; Thu, 2 Jul 1998 18:02:06 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 18:50:46 EDT." Date: Thu, 02 Jul 1998 18:02:06 -0700 Message-ID: <5406.899427726@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What you're arguing for here is a symlink based on the unix userid, > which certainly is a good candidate for a system-wide variable. All But that's NOT what I was arguing for - that was merely a convenient example. I'm specifically arguing for being able to exploit an application's *existing* use of environment variables and NOT having to think "well gee, I guess a username is one thing we should make a magic variable for, and maybe the uid and pid, and ..." That somehow assumes that the designers are going to know what all the useful variables are going to be in advance, something which Unix itself has shown that they plainly don't. Users in the field are always going to think up even more odd-ball uses of the mechanism than the designers ever thought of. > However, let's say the program itself happens to set an environment > variable called "PROGUSER", and you're going to use that. You do > not depend on the user themselves remembering to set this variable > (which is good (*)), because you know the program itself sets the > value before it reads the configuration file. The user runs the > program, the program goes to the desired config file, and it You're somehow confusing the user for the application writer here. When you say "you are going to use that", what you're really saying is the _user_ is going to use that as a convenient hook only after determining that it *is* a convenient hook. If it's not entirely appropriate then the user is going to have to either figure out another more effective one OR they're going to have to give up on the idea of customizing that application's behavior completely behind its back. Sometimes that works, sometimes it doesn't. In any case, this argument is also somewhat moot since neither of us is actually doing the work of IMPLEMENTING this baby and it's the implementor who is always going to have the final say as to how it works anyway. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 18:19:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13339 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 18:19:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (fullermd@shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13314 for ; Thu, 2 Jul 1998 18:19:01 -0700 (PDT) (envelope-from fullermd@shell.futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) id UAA16589; Thu, 2 Jul 1998 20:18:54 -0500 (CDT) Message-ID: <19980702201854.17640@futuresouth.com> Date: Thu, 2 Jul 1998 20:18:54 -0500 From: "Matthew D. Fuller" To: David Kelly Cc: Stefan Eggers , freebsd-hackers@FreeBSD.ORG Subject: Re: permission confusion at mount points References: <199807030021.TAA18905@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199807030021.TAA18905@nospam.hiwaay.net>; from David Kelly on Thu, Jul 02, 1998 at 07:21:25PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 02, 1998 at 07:21:25PM -0500, David Kelly woke me up to tell me: > Stefan Eggers writes: > > Hi! > > > > I had a directory "/usr2" with mode 0700 owned by root.wheel. On that > > I mounted a filesystem with mode 0755 owned by root.wheel (data of its > > root node). The OS is 2.2-stable CVSUped lately. > [...] > > Should the mount point really influence permissions this way w/o > > giving any indication of this? Or is this behavior unintentional? > > Is it worth a PR? > > Its that way in every Unix I've used. Can't think of one that it doesn't > act up, but somebody would point out the odd system if I was to claim > more than I know and say *all* unices. > > For kicks, "cd /usr2; pwd". Bet it'll fail. Same for SGI's Irix 6.2. > Use 755 permissions on your underlying mount point and put the problem > out of your misery. On a side note, wouldn't it be nice to be able to chmod the mount point of a read-only filesystem while it's mounted? *duck* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 18:40:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15213 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 18:40:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15203 for ; Thu, 2 Jul 1998 18:40:27 -0700 (PDT) (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.8/8.8.8) with ESMTP id SAA05630; Thu, 2 Jul 1998 18:39:44 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Duncan Barclay cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pkg_create and setting directory ownership. In-reply-to: Your message of "Thu, 02 Jul 1998 22:41:50 BST." Date: Thu, 02 Jul 1998 18:39:43 -0700 Message-ID: <5627.899429983@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm trying to get pkg_create (on -2.2.6) to set the ownership of some > directories for a package I'm building. The problem is that > the @owner directive only affects the files listed in the plist. If you > list a directory the whole tree below that point is added to the > final package tar file. Which is a known "limitation" (I hesitate to call it a bug). That's one reason most folks don't list directory names in plists, just their contents, and then set the directory ownerships in an mtree file if necessary (though if you've only a few, nobody will grumble if you "cheat" a little with @exec :-). - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 19:04:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18060 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 19:04:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18019; Thu, 2 Jul 1998 19:04:26 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA19151; Thu, 2 Jul 1998 19:04:25 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd019128; Thu Jul 2 19:04:22 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id TAA17845; Thu, 2 Jul 1998 19:04:16 -0700 (MST) From: Terry Lambert Message-Id: <199807030204.TAA17845@usr04.primenet.com> Subject: Re: FreeBSD equiv. of /proc/loadavg To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Fri, 3 Jul 1998 02:04:16 +0000 (GMT) Cc: tlambert@primenet.com, joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199807030027.RAA05728@hub.freebsd.org> from "Jonathan M. Bresler" at Jul 2, 98 05:27:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What's NIH? > > > > We can't tell you; the use of the term was Not Invented Here, and > > thus, like SysV rc.d, we fear and mistrust it... 8-). > > Oh Terry! i dont like rc.d because i am left which > "which of these scripts in which directory did what!" > why? grr.... You're not supposed to ask that question, because your package management system takes care of that for you, and standard system services are installed as packages, and the installation handles the dependency enforcement for you. In other words, it's a data-drop for post-validated dependent data, not a respository for structural information used in validation. > with our current strcuture, we have some separation without > reaching the level of cookiness that sunos 5.5.1 provides: > 70 shell scripts scattered across 5 directories. These are run levels, as opposed to run states. Run states are better, because I can define an infinite number of them, and I can name them instead of numbering them (which I have to do in run levels because of the sequencing requirements they imply). I'd suggest that you don't have a way of dealing with: 1) remove the "sendmail" module, which exports the "SMTP" service 2) install the "qmail" module, which exports the "SMTP" service 3) the "bind" module exports the "DNS" service 4) the "qmail" module depends on the "DNS" service, so the "bind" module must be started before the "qmail" module. due to the fact that the dependency relationships are coded in the scripts, and not in the data that the startup process acts upon. The installation needs to support the concept of "hard" and "soft" service dependencies, and of "service export" and "service import", of potentially multiple services, totally apart from the concept of "this is what it takes to start a particular module". The point of a script in an rc.d directory is "this is what it takes to start a particular module". Looking at it from the perspective of encoding the ordering and the dependencies in the script names (as Solaris does) or in a shell script (as FreeBSD does) is totally counterintuitive. The concepts of "rc directories" and "this ``rc.statename'' means this collection of services" are totally orthogonal to the idea the "odd numbering of script names" in Solaris. Just because Solaris supports only "hard" dependencies, and just because it overlaods the file name instead of using a seperate ordering hierarchy doesn't mean that a correct implemetnation would have to do the same thing. The only missing "baggage" is defining the rc.# "run level" service clusters, and third party dependencies on having "at least the services in the ``rc.3 cluster''" for the third party software to successfully run. Installation of third party software expecting the Solaris "rc.d" mechanism would have to evaluate the service cluster(s) that the third party software required by virtue of the rc.# files it tried to install, and thereby determine whethr or not it should try to start the third party software in the face of the ``statename'' cluster the user is running at the time. That way, you get IBCS2/Solaris ABI compatability (the rc.d is part of the ABI for server software). Just because only *some* of the SysV rc.d ideas are good, doesn't mean we have to make a choice between taking all of them, or taking none of them. Turning ranges into black and white choices is an Aristotilian mean, and it's simply a bad way of thinking for any true engineer worth his or her salt. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 19:06:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18588 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 19:06:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep2-orange.clear.net.nz (fep2-orange.clear.net.nz [203.97.32.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18546; Thu, 2 Jul 1998 19:06:44 -0700 (PDT) (envelope-from jabley@clear.co.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep2-orange.clear.net.nz (1.5/1.9) with ESMTP id OAA06009; Fri, 3 Jul 1998 14:06:00 +1200 (NZST) Received: from localhost (jabley@localhost) by buddha.clear.net.nz (8.8.8/8.8.8) with SMTP id OAA18983; Fri, 3 Jul 1998 14:05:56 +1200 (NZST) (envelope-from jabley@clear.co.nz) Date: Fri, 3 Jul 1998 14:05:56 +1200 (NZST) From: Joe Abley X-Sender: jabley@buddha.clear.net.nz To: Donn Miller cc: Mike Smith , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg In-Reply-To: <359B9B21.6DE01652@bellatlantic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Donn Miller wrote: > Mike Smith wrote: > > > > > > > > Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I > > > want to use this instead of using getloadavg(). > > > > The obvious question here is "why"? > > I just figured that some Linux programs were trying to obtain load > average info that way, and to ease porting, well, I wanted to open the > equivalent FreeBSD file. I realize now though that if you want to port > some apps with low-level details, you gotta do a little reworking. > > I was trying to port wmmon from WindowMaker. It's just for Linux now. > In addition, the app tries to obtain loadaverage, uptime, and memory > info about the machine like this: (from wmmon.c) What about rpc.rstatd(8) - isn't this a common enough interface for all these numbers? Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 19:15:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20273 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 19:15:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20210; Thu, 2 Jul 1998 19:15:29 -0700 (PDT) (envelope-from jabley@clear.co.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.9) with ESMTP id OAA22996; Fri, 3 Jul 1998 14:14:58 +1200 (NZST) Received: from localhost (jabley@localhost) by buddha.clear.net.nz (8.8.8/8.8.8) with SMTP id OAA19024; Fri, 3 Jul 1998 14:14:53 +1200 (NZST) (envelope-from jabley@clear.co.nz) Date: Fri, 3 Jul 1998 14:14:53 +1200 (NZST) From: Joe Abley X-Sender: jabley@buddha.clear.net.nz To: "Jonathan M. Bresler" cc: Terry Lambert , joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg In-Reply-To: <199807030027.RAA05728@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Jonathan M. Bresler wrote: > > We can't tell you; the use of the term was Not Invented Herei, and > > thus, like SysV rc.d, we fear and mistrust it... 8-). > > Oh Terry! i dont like rc.d because i am left which > "which of these scripts in which directory did what!" > why? grr.... > > with our current strcuture, we have some separation without > reaching the level of cookiness that sunos 5.5.1 provides: > 70 shell scripts scattered across 5 directories. One positive advantage of the SYSV start-script approach is that there is a good chance of finding a single script that can start and stop a single package or daemon. This is a bit of a mess in FreeBSD 2.2.6-R, IMHO - each application that needs to be stopped or started supplies its own administrative interface, like ndc (bind) and apachectl (apache) , each living in a different place, requiring different parameters. My $0.02 only :) -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 19:28:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22793 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 19:28:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22780 for ; Thu, 2 Jul 1998 19:28:15 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.0/frmug-2.3/nospam) with UUCP id EAA23468 for hackers@FreeBSD.ORG; Fri, 3 Jul 1998 04:28:14 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id AAA03495 for hackers@FreeBSD.ORG; Fri, 3 Jul 1998 00:39:57 +0200 (CEST) (envelope-from roberto) Message-ID: <19980703003957.A9464@keltia.freenix.fr> Date: Fri, 3 Jul 1998 00:39:57 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg Mail-Followup-To: hackers@FreeBSD.ORG References: <199807021850.LAA01417@antipodes.cdrom.com> <199807022118.QAA06797@detlev.UUCP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.3i In-Reply-To: <199807022118.QAA06797@detlev.UUCP>; from Joel Ray Holveck on Thu, Jul 02, 1998 at 04:18:53PM -0500 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4419 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Joel Ray Holveck: > What's NIH? "Not Invented Here". -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #11: Sat Jun 27 00:41:06 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 20:21:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29716 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 20:21:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles183.castles.com [208.214.165.183]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29659; Thu, 2 Jul 1998 20:20:54 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id UAA03532; Thu, 2 Jul 1998 20:19:47 -0700 (PDT) Message-Id: <199807030319.UAA03532@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joe Abley cc: Donn Miller , Mike Smith , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg In-reply-to: Your message of "Fri, 03 Jul 1998 14:05:56 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 20:19:47 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 2 Jul 1998, Donn Miller wrote: > > > Mike Smith wrote: > > > > > > > > > > > Am looking for the FreeBSD equivalent of the Linux file /proc/loadavg. I > > > > want to use this instead of using getloadavg(). > > > > > > The obvious question here is "why"? > > > > I just figured that some Linux programs were trying to obtain load > > average info that way, and to ease porting, well, I wanted to open the > > equivalent FreeBSD file. I realize now though that if you want to port > > some apps with low-level details, you gotta do a little reworking. > > > > I was trying to port wmmon from WindowMaker. It's just for Linux now. > > In addition, the app tries to obtain loadaverage, uptime, and memory > > info about the machine like this: (from wmmon.c) > > What about rpc.rstatd(8) - isn't this a common enough interface for all > these numbers? No. Not everybody wants to leak that sort of information, and why should I run two more daemons just to get three bloody numbers from the kernel? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 21:10:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07110 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 21:10:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles185.castles.com [208.214.165.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07088 for ; Thu, 2 Jul 1998 21:10:41 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA03762; Thu, 2 Jul 1998 21:10:50 -0700 (PDT) Message-Id: <199807030410.VAA03762@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Percy Cheng cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: About FreeBSD boot manager... In-reply-to: Your message of "Fri, 03 Jul 1998 09:04:31 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 21:10:50 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 2 Jul 1998, Mike Smith wrote: > > > Yes, although there are some problems to be careful of here: > > > > - all of these filesystems must be within the first 1024 cylinders of > > the disk in order to be bootable. > > - the win98 installation may not get along well with the win95 > > installation (c:\windows != $WINDOWS) > > > Thanks for your kind attention, but can I get more > detail on : What's mean within 1024 cylinders?? And how > much the HDD space can be located within it?? This depends on your disk. Typically, it means that you're restricted to the first 500MB of an IDE disk. > Furthermore, in the second point, does it means > may not be posibble if I want to boot win98 with booteasy? It may not be possible to have Win95 and Win98 coexisting on the same system, regardless of boot manager. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 21:17:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08072 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 21:17:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles185.castles.com [208.214.165.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08050 for ; Thu, 2 Jul 1998 21:17:23 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA03798; Thu, 2 Jul 1998 21:16:23 -0700 (PDT) Message-Id: <199807030416.VAA03798@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garance A Drosihn cc: Mike Smith , Thomas David Rivers , jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 18:10:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 21:16:22 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think there would be less headaches all-around if symlinks did not > key off environment variables, although I do think we'd want them to > key off of something as simple to adjust as environment variables are. This expresses my opinion quite succinctly. Overloading the environment space to also control variant links would be a Very Bad Idea, simply because the risk of name collision is too high. Allowing links to indicate that they *should* be keyed off the environment space, OTOH, isn't such a sin. eg: ${sysctl:hw.arch} and ${env:USER} but this creates a new union space with yet another different syntax. ${space=sysctl, mib=hw.arch} and ${space=env, var=USER} perhaps? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 21:20:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08825 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 21:20:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles185.castles.com [208.214.165.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08812 for ; Thu, 2 Jul 1998 21:20:14 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA03843; Thu, 2 Jul 1998 21:20:51 -0700 (PDT) Message-Id: <199807030420.VAA03843@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Chris Radek cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Ethernet driver 2.1 -> 2.2 help In-reply-to: Your message of "Wed, 01 Jul 1998 22:24:47 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 21:20:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hello all - > > A while back I promised to work on a driver for the Accton EtherPocket > parallel port ethernet device. Well, I have good news and bad news. > I developed the driver under 2.1.7 and it is working beautifully > there. > > Now, however, I want the driver to work under 2.2.X. Looks like > things have changed a bit since 2.1. Uh, no insult, but it would be Really Nice if you could port it to 3.0 so that we could commit it and have it maintained. There's also this really nice infrastructure for parallel-port devices in 3.0... > I've done what look like the obvious things, and now the driver > compiles again but doesn't work. I'm hoping someone has a description > of exactly what had to be changed for the 2.2 port. (I guess someone > went through all the drivers and did this?) This depends. Given that you wrote the driver, and you know what doesn't work, I think you're really the only one that knows how to fix it given the above information. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 21:58:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12162 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 21:58:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12153 for ; Thu, 2 Jul 1998 21:58:31 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id AAA103958 for ; Fri, 3 Jul 1998 00:58:31 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <5406.899427726@time.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:50:46 EDT." Date: Fri, 3 Jul 1998 01:02:23 -0400 To: hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:02 PM -0700 7/2/98, Jordan K. Hubbard wrote: >> What you're arguing for here is a symlink based on the unix userid, >> which certainly is a good candidate for a system-wide variable. All > > But that's NOT what I was arguing for - that was merely a convenient > example. I'm specifically arguing for being able to exploit an > application's *existing* use of environment variables and NOT having > to think "well gee, I guess a username is one thing we should make a > magic variable for, and maybe the uid and pid, and ..." I agree that the possible keys (ie, variable names) for symbolic links should not be something that's fixed at system build time. Some variable names and the default values for them should be system-wide, but users (any and all useres) should be able to add to the set of names without needing any special privileges. >> However, let's say the program itself happens to set an environment >> variable called "PROGUSER", and you're going to use that. You do >> not depend on the user themselves remembering to set this variable >> (which is good (*)), because you know the program itself sets the >> value before it reads the configuration file. The user runs the >> program, the program goes to the desired config file, and it > > You're somehow confusing the user for the application writer here. > When you say "you are going to use that", what you're really saying > is the _user_ is going to use that as a convenient hook only after > determining that it *is* a convenient hook. Hmm. Well, no. Actually I'm assuming another layer of people... :-) In my mind there's the developer of a program (who may be on the other side of the world, and sometimes even seems to be on another planet), the adminstrator of all the local machines (we have a handful of people administering about 500 to 1000 unix machines at RPI), and then the end-users (5,000 to 10,000 end users at RPI). I read your example as: The administrator goes to install the program, and notices he or she can avoid some administrative headaches by using a variant symbolic link. He or she does this, and then releases the package to the end-users, and then waits for end-users to call up with any problems they encounter. Now, admittedly that's not exactly what your example actually *said*, I'm just explaining why I replied the way I did... The person running the program could very well have no idea that a variant symbolic link is being used. I expect that variant symbolic links will be useful enough that one person will be creating a variant symbolic link which will effect (indirectly) a large body of users who won't even know they are using *any* symbolic link. To quote from the article written by Terry: > For example, we could have made the /usr/lib/aout change appear > to have zero impact. My guess is that no one is going to make the aout change appear to have zero impact by assuming *every* *end-user* is individually going to create symbolic links and set environment variables. No, I suspect some administrator or system-developer is the person making the decision to create that particular symbolic link... And once they do, then *every* end user had better not choose that particular environment variable unless they fully understand how it's being used for this symbolic link (even though ideally they wouldn't even know the link exists). > In any case, this argument is also somewhat moot since neither of > us is actually doing the work of IMPLEMENTING this baby and it's > the implementor who is always going to have the final say as to > how it works anyway. :-) Sure, go and get all practical on me. Go ahead and ruin all my fun babbling... :-) Actually, though, I think that what I'm proposing is really just an alternative to environment variables (not just "environment variables for symbolic links", but "an alternative to environment variables for holding configuration settings"). Perhaps that wouldn't be too hard to do a simple cut of? To get the kernel to correctly *use* environment variables for symbolic links is going to take some work (even if everyone agrees it's the best of all ideas), and perhaps an alternative would be less work to do. If so, I can get away with all this babbling without irritating any person who is actually doing the useful work on it... :-) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 22:12:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14006 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 22:12:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles185.castles.com [208.214.165.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13996 for ; Thu, 2 Jul 1998 22:12:10 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA04218; Thu, 2 Jul 1998 22:12:14 -0700 (PDT) Message-Id: <199807030512.WAA04218@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Willem Jan Withagen , jkh@time.cdrom.com, Michael Smith , hackers@FreeBSD.ORG Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-reply-to: Your message of "Thu, 02 Jul 1998 10:01:16 +0930." <19980702100116.F13424@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 22:12:14 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wednesday, 1 July 1998 at 10:49:55 +0200, Willem Jan Withagen wrote: > > In article you write: > >>> I have actual working code for this. > >>> At the moment every variantlink gets replaced by '2.2.6', since that is my > >>> current OS version. > >> > >> That's really cool! Apollo, here we come! ;-) > > > > Just look for the Apollo FAQ and see why I'm chasing this one down. > > :-D. I just loved my Domain babies. > > > > [[ Now If could only read back my old Apollo-tars at 20 blocks = 10Kbyte. :-( > > What's the problem? I've heard of nightmares with Apollo tapes, and I > currently have a set of Domain OS 10.4 tapes here which I need to copy > (Mike, are you listening?). Yeah. Do an install from them first, then use rbak/wbak or whatever the Apollo FAQ suggests for copying them. It's been too long since I wsa reading that stuff to remember, especially as I never had a chance to practice. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 22:14:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14288 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 22:14:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles185.castles.com [208.214.165.185]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14272 for ; Thu, 2 Jul 1998 22:14:27 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA04008; Thu, 2 Jul 1998 21:48:31 -0700 (PDT) Message-Id: <199807030448.VAA04008@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Larry S. Lile" cc: David Greenman , Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-reply-to: Your message of "Wed, 01 Jul 1998 23:16:46 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Jul 1998 21:48:30 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Wed, 1 Jul 1998, David Greenman wrote: > > > >Anyway, the card has a register (isrp) that has a bit that shows whether > > >or not the card can interrrupt the 8259 on its irq line. This works for > > >the first interrupt but as soon as I enter an spl loop that bit goes > > >high, saying he can't interrupt, and never drops even after exiting the > > >spl loop. > > > > Sounds to me like you aren't acking the interrupt in your ISR. > > Could I get you to take a peek at whats going on? The adapter spec is > at (or at least the pages on the status registers) > http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/BK8R1001 > /1.4.9.4 > and the code for the driver is at http://anarchy.stdio.com (or you can get > to it at http://www.jurai.net/~winter/tr/tr.html). I have been working > from the MACH source and I can't see what i'm doing wrong. > > Whats got me really confused is bit 1 in the ISRP high (even) which > is called User interrupt blocked? And worst is I can't seem to > reset it. When you say this, have you tried writing a 0 to it? Also, how about this snippet: ADAPTER INTERRUPT ENABLE For PC System with PC I/O Bus: An I/O Write (OUT instruction) to X'0A23' (adapter 0) or X'0A27' (adapter 1) resets and re-enables the adapter interrupt generation circuitry. An I/O read to this address is reserved. Apart from that, I would be asking IBM for help... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 22:15:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14398 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 22:15:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14376 for ; Thu, 2 Jul 1998 22:14:53 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id BAA70546; Fri, 3 Jul 1998 01:14:47 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807030000.RAA14014@usr09.primenet.com> References: from "Garance A Drosihn" at Jul 2, 98 06:50:46 pm Date: Fri, 3 Jul 1998 01:18:39 -0400 To: Terry Lambert From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:00 AM +0000 7/3/98, Terry Lambert wrote: >> Certainly it is an attractive idea to base symlinks on environment >> variables, but maybe we should ask ourselves how hard it would be >> to implement a "nice clean private namespace somewhere". I think >> we'll be happier with the separate namespace, something which isn't >> disrupted as readily and as often as the user environment. > > A namespace is a namespace. Your arguments apply no matter where the > namespace is located, so long as you permit the user to modify it > at all. No, I don't think they do (just talking about my own opinion, of course). A user (or a script) can create and modify environment variables for whatever reason they happen to need a variable for, and in doing so they clobber some symlink that they may not even realize is referencing an environment variable. Instead, let us say there was a unix command which modified some other namespace. This other namespace is a database of sorts, so we'll call the unix command, oh, say, 'dwrite' (*). I, as a user, am not going to type in dwrite FileSystem somekey somevalue without having some understanding that this might effect symbolic links. Yes, I can still royally screw up all kinds of applications by typing that command in, but it's much less likely that I'd do that without realizing the *scope* of what it is that I'm changing. I'm not saying we should put up some barrier so end-users can not hang themselves by changing a symlink value. I am saying that end-users (or people who write scripts used by end users) can and do use all kinds of variable names which they pick out of thin air because the name sounds like a good name. They should be able to continue to do that without causing wild things to happen to any filesystem accesses. And while I don't consider myself a wizard unix programmer (and I'm sure no one here does either... :-), I have written programs which purposely setup a specific user environment before exec-ing some other program. When I have done that, I have never taken any time to wonder "gee, I wonder if this will screwup access to some file somewhere, because a symbolic-link that this program *unknowingly* references will not see an environment variable that the link needs for it to work correctly". > For example, we could have made the /usr/lib/aout change appear to > have zero impact. We could also have done a large number of other > things with apparently zero impact, that would allow us to build > multiple targets on the same machine, for example, something that > the current build environment is not good at. I well understand how useful it could be. I think the work already done towards variant symbolic links is pretty encouraging. I am only arguing that it is a bad idea to have symbolic links key off environment variables. Let's say freebsd could make the /usr/lib/aout change based on some symbolic-link attribute. This sounds good to me. Now let's say some morass of scripts and programs that you're porting from somewhere else just happen to modify the very environment variable that someone else (not you personally) happened to choose for that aout-related symlink. Wherever that script or application changes the value, you can be sure it will not have a commment: OBJFMT=no # Break important symbolic link in freebsd, # and no other operating system but freebsd, # thus causing incrediable confusion. If it has any comments, it's going to say: OBJFMT=no # Assume the file we are reading is not an # object module. I am not arguing against dynamic values. I am not arguing that users should only be allowed to use variable-names which are hardcoded into the kernel. I am only arguing that we will probably see more headaches if environment variables can effect the target of symlinks than we will see "clever things" which *require* that environment variables can effect symbolic links. > the current build environment is not good at. There are > numerous other examples that I can bore you with, if you > insist... 8-). >From where I am sitting, you are providing excellent arguments against a position that I am not taking. They are very compelling for the position you have focused on, but as near as I can tell they miss the point of the position I am trying to advocate. (hopefully that doesn't come across as snotty, but I really do agree that you have given examples of very useful things, and I honestly feel those examples have absolutely nothing to do with the position I'm trying to take. In my "idealized implementation" (whatever that means...), I fully expect one could and should be able to do every single example that you've suggested so far) So, either there is something about the implementation you're thinking of which I'm just not getting (and thus it's not as prone to headaches as I fear), or there is something about my position that you are not getting. In either case, I don't need more examples of how variant symlinks could be very useful. I understand that part. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 22:37:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA17819 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 22:37:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA17808 for ; Thu, 2 Jul 1998 22:37:16 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id BAA104188; Fri, 3 Jul 1998 01:37:04 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:10:44 EDT." Date: Fri, 3 Jul 1998 01:40:56 -0400 To: Mike Smith From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:16 PM -0700 7/2/98, Mike Smith wrote: > Allowing links to indicate that they *should* be keyed off the > environment space, OTOH, isn't such a sin. eg: > > ${sysctl:hw.arch} and ${env:USER} > > but this creates a new union space with yet another different > syntax. > > ${space=sysctl, mib=hw.arch} and ${space=env, var=USER} > > perhaps? Hmm, not quite the strategy I was leaning towards, but I do feel much less concerned with this than the earlier alternative. If the creator of the link really *wants* the link to change based on an environment value, then any headaches caused are their fault, and not the implementation's fault. Something like this would let administrators or system-developers to use variant symlinks in situations where any value influenced by the users environment would just be begging for trouble. Thus, something long these lines would, I think, make variant symlinks more useful. I must admit I don't understand your comment about a "new union space", so I would lean toward a more terse syntax, such as your first suggestion. Perhaps that just proves I should go home and get some sleep... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 23:09:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20666 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 23:09:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA20654 for ; Thu, 2 Jul 1998 23:09:38 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 19508 invoked by uid 1001); 3 Jul 1998 06:09:38 +0000 (GMT) To: dkelly@hiwaay.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: permission confusion at mount points In-Reply-To: Your message of "Thu, 02 Jul 1998 19:21:25 -0500" References: <199807030021.TAA18905@nospam.hiwaay.net> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 03 Jul 1998 08:09:38 +0200 Message-ID: <19506.899446178@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Should the mount point really influence permissions this way w/o > > giving any indication of this? Or is this behavior unintentional? > > Is it worth a PR? > > Its that way in every Unix I've used. Can't think of one that it doesn't > act up, but somebody would point out the odd system if I was to claim > more than I know and say *all* unices. Yes, I've seen this trip the unwary on many different Unix systems. I've never seen a reason for *why* it has to be this way. Can anybody enlighten us why? Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 2 23:32:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA23934 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 23:32:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picasso.wcape.school.za (picasso.wcape.school.za [196.21.102.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23917 for ; Thu, 2 Jul 1998 23:32:44 -0700 (PDT) (envelope-from pvh@leftside.wcape.school.za) Received: from uucp by picasso.wcape.school.za with local-rmail (Exim 1.92 #2) for freebsd-hackers@freebsd.org id 0yrzOk-0006rx-00; Fri, 3 Jul 1998 08:32:42 +0200 Received: from localhost (pvh@localhost) by leftside.wcape.school.za (8.8.8/8.8.4) with SMTP id IAA01211 for ; Fri, 3 Jul 1998 08:30:18 +0200 (SAT) Date: Fri, 3 Jul 1998 08:30:18 +0200 (SAT) From: Peter van Heusden To: freebsd-hackers@FreeBSD.ORG Subject: SCSI drive not remapping bad block: Any solution (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I sent this message to freebsd-questions, but didn't get a response. Maybe it was too technical for that list... so I was wondering if anyone on freebsd-hackers had any ideas: I'm getting the following error message from my new SCSI disk: Jul 1 21:46:49 leftside /kernel: sd2(ncr0:4:0): MEDIUM ERROR info:0x38787b asc 11,0 Unrecovered read error field replaceable unit: ea sks:80,11 This is a Seagate ST32155N connected to a ncr 53c810 controller. I've recently reformatted it with scsiformat (after getting the error previously), and I assume that this error message means there is a medium error on the disk. The scsi(8) command shows AWRE and ARRE are both set to 1, yet this error persists, which makes me conclude that the disk is not remapping the block correctly. Is there any way to deal with this problem? I read in the freebsd-questions archive that someone talked about manually remapping the block - is this possible, and if so, how? Is there any other solution? Thanks for any advice - I'd really like to not throw out a newly acquired (from my wife's brother) 2gb disk. Peter -- Peter van Heusden | Computers Networks Reds Greens Justice Peace Beer Africa pvh@leftside.wcape.school.za | Support the SAMWU 50 litres campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 00:27:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA01340 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 00:27:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA01334 for ; Fri, 3 Jul 1998 00:27:22 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d22.syd2.zeta.org.au [203.26.11.22]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id RAA22528 for ; Fri, 3 Jul 1998 17:27:21 +1000 Received: (qmail 20320 invoked by uid 1000); 3 Jul 1998 05:51:12 -0000 Message-ID: <19980703155112.A20279@reilly.home> Date: Fri, 3 Jul 1998 15:51:12 +1000 From: Andrew Reilly To: Joe Abley , "Jonathan M. Bresler" Cc: Terry Lambert , joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FreeBSD equiv. of /proc/loadavg References: <199807030027.RAA05728@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Joe Abley on Fri, Jul 03, 1998 at 02:14:53PM +1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 03, 1998 at 02:14:53PM +1200, Joe Abley wrote: > > Oh Terry! i dont like rc.d because i am left which > > "which of these scripts in which directory did what!" > > why? grr.... > > > One positive advantage of the SYSV start-script approach is that there is > a good chance of finding a single script that can start and stop a single > package or daemon. > > This is a bit of a mess in FreeBSD 2.2.6-R, IMHO - each application that > needs to be stopped or started supplies its own administrative interface, > like ndc (bind) and apachectl (apache) , each living in a different place, > requiring different parameters. I've never understood why you would design a service that took more than /usr/sbin/named to start, and kill -HUP `cat /var/run/named.pid` to stop. What's with all of this script nonsense anyway? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 00:42:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03852 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 00:42:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03847 for ; Fri, 3 Jul 1998 00:42:13 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id JAA01954; Fri, 3 Jul 1998 09:42:13 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id JAA05126; Fri, 3 Jul 1998 09:42:12 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807030742.JAA05126@surf.IAE.nl> Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-Reply-To: <199807030025.TAA18925@nospam.hiwaay.net> from David Kelly at "Jul 2, 98 07:25:29 pm" To: dkelly@hiwaay.net (David Kelly) Date: Fri, 3 Jul 1998 09:42:12 +0200 (MET DST) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You ( David Kelly ) write: => They were written on 4mm DAT? Not something weird like QIC-100? Saw an => HP "development system" which wrote QIC-100 format to DC-6150 tapes, I => think. Tapes had to be formatted. Then they mounted like a filesystem. => Slower than a tax refund. Nope, it was an actual DAT. => In the early bad old days of DAT (more correctly known as DSS) there => were more problems than there should have been with one tape drive not => being able to read tapes from another, all other things the same. Now this could be a good case, since I remember ordering a DDS drive somewhere around 1889. -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 01:58:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA15419 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 01:58:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15414 for ; Fri, 3 Jul 1998 01:58:42 -0700 (PDT) (envelope-from lada@pc8811.gud.siemens.at) Received: from pc8811.gud.siemens.at (root@[10.1.140.1]) by zwei.siemens.at with ESMTP id KAA12804; Fri, 3 Jul 1998 10:52:52 +0200 (MET DST) Received: from pc8811.gud.siemens.at (pc8811.gud.siemens.at [195.3.22.159]) by pc8811.gud.siemens.at (8.8.8/8.8.8) with ESMTP id KAA16587; Fri, 3 Jul 1998 10:53:07 +0200 (CEST) (envelope-from lada@pc8811.gud.siemens.at) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 03 Jul 1998 10:53:06 +0200 (CEST) Organization: Siemens Austria AG From: Marino Ladavac To: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG, jkh@time.cdrom.com, Thomas David Rivers , Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Jul-98 Garance A Drosihn wrote: > At 11:13 AM -0700 7/2/98, Mike Smith wrote: >>> >>> So, given my experience - I'd prefer to not have this feature >>> in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?) >>> to globally disable it at an installation... >> >> How about "just don't use it"? The point here is that it's an enabling >> technology, not an intentional constriction of freedom. If you don't >> want it or can't manage it properly, you don't have to use it. > > > Enabling technology will probably be attractive to people working on > ports. I suspect many of us will find ourselves using it, whether we > are personally thrilled with it or not. Certainly the idea of using > {arch} to distinguish between alpha-specific vs intel-specific files > would be immediately attractive, for instance. I'm just asking what > the best (most reliable) implementation might be for this variable > symlink facility. Some of you probably can still recollect the HP-UX Context Dependent Files (I believe they are reduced-functionality Variant Symlinks) which existed till HP-UX 10 threw them out. They offered the limited functionality which could select the CDF file content based on process context (which was basically the arch equivalent). This made it possible to have the HPPA and Motorola executables in the same directory, with the same name. A workalike thereof should suffice for your needs. /Marino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 02:47:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24438 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 02:47:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA24410 for ; Fri, 3 Jul 1998 02:47:07 -0700 (PDT) (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 CAA06443; Fri, 3 Jul 1998 02:46:26 -0700 (PDT) Message-Id: <199807030946.CAA06443@implode.root.com> To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Fri, 03 Jul 1998 01:02:23 EDT." From: David Greenman Reply-To: dg@root.com Date: Fri, 03 Jul 1998 02:46:26 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I agree that the possible keys (ie, variable names) for symbolic >links should not be something that's fixed at system build time. I sure don't agree with that. I also think Jordan's desire to have symlinks translated with the user environment is either not attainable or undesirable or both. I personally would rather that the info be kept in a seperate name table (like what Terry suggested). I also prefer to have a hierarchical structure (also like Terry suggested, except that I'd have the system table as a seperate autonomous thing and not attached to the init process). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 03:05:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27414 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:05:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27404 for ; Fri, 3 Jul 1998 03:05:01 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id DAA14450 for ; Fri, 3 Jul 1998 03:03:38 -0700 (PDT) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id LAA20365 for freebsd-hackers@freefall.cdrom.com; Fri, 3 Jul 1998 11:24:53 +0200 (MEST) (envelope-from kuku) Date: Fri, 3 Jul 1998 11:24:53 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> To: freebsd-hackers@freefall.cdrom.com Subject: trace/KTRACE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to find out where an application 'hangs' for some overly long time (possibly a network/socket call or something) Recently I grabbed out 'trace-1.6' for a HP-UX machine which is supposed to be based on the SUN kernel trace interface. The problem using the kernel option KTRACE would be that I cannot watch the application as it performs, instead I can only trace 'a posteriori'. Would the be a way to support this utility and the kernel trace interface under FreeBSD? Or are there any other ways (other than profiling, which is also an a posteriori method) to 'watch' what an app does? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 03:11:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA28682 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:11:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA28658 for ; Fri, 3 Jul 1998 03:11:41 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 20547 invoked by uid 1001); 3 Jul 1998 10:11:39 +0000 (GMT) To: lada@pc8811.gud.siemens.at Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-Reply-To: Your message of "Fri, 03 Jul 1998 10:53:06 +0200 (CEST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 03 Jul 1998 12:11:39 +0200 Message-ID: <20545.899460699@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Some of you probably can still recollect the HP-UX Context Dependent Files > (I believe they are reduced-functionality Variant Symlinks) which existed > till HP-UX 10 threw them out. They offered the limited functionality which > could select the CDF file content based on process context (which was > basically the arch equivalent). This made it possible to have the HPPA and > Motorola executables in the same directory, with the same name. > > A workalike thereof should suffice for your needs. If anybody should ever consider something similar to HP-UX CDFs, I'd strongly suggest that this should only be available to root by default. (on the assumption that root users know what they're doing). At one of my former employers we had a large number of HP-UX diskless hosts, using CDFs. We saw far too many cases of users inadvertently having their directories "disappear" (and similar problems) because they had turned the CDF bit on. It was a real support hassle. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 03:17:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA29467 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:17:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA29448 for ; Fri, 3 Jul 1998 03:17:18 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id DAA21943; Fri, 3 Jul 1998 03:17:14 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd021936; Fri Jul 3 03:17:13 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id DAA15756; Fri, 3 Jul 1998 03:17:09 -0700 (MST) From: Terry Lambert Message-Id: <199807031017.DAA15756@usr04.primenet.com> Subject: Re: permission confusion at mount points To: sthaug@nethelp.no Date: Fri, 3 Jul 1998 10:17:09 +0000 (GMT) Cc: dkelly@hiwaay.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19506.899446178@verdi.nethelp.no> from "sthaug@nethelp.no" at Jul 3, 98 08:09:38 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 Precedence: bulk X-Loop: FreeBSD.ORG > > > Should the mount point really influence permissions this way w/o > > > giving any indication of this? Or is this behavior unintentional? > > > Is it worth a PR? > > > > Its that way in every Unix I've used. Can't think of one that it doesn't > > act up, but somebody would point out the odd system if I was to claim > > more than I know and say *all* unices. > > Yes, I've seen this trip the unwary on many different Unix systems. I've > never seen a reason for *why* it has to be this way. > > Can anybody enlighten us why? The reason is that FS's "cover" mount points. This means that the mount points are evaluated before the "covering" values are discerned. Practically, this means you determine if the person has access to the vnode being covered before you replace it with the vnode doing the covering. I personally think that the idea of mapping a vnode into an existing directory hierarchy should *not* require acess to the existing hierarchy to implement. My idea is that you seperate the act of mapping from the act of lookup; this is a little inconvenience, in that you ignopre the mapping point in favor of that which is mapped. It has the advantage that "X" replaces "Y" instead of "X" predicates "Y". In more simple terms, it means that the mounted FS permissions are checked instead of the mount point permissions before acces is granted. This is really an issue of data hiding more than anything else, since it has to do with when permissions are evaluated. You could look at this as being like VT100 "am"; the value of the permissions are evaluated before the 81st charater instead of after the 80th. There are a number of *very nice* consequences to looking at mapping into the FS namespace this way, starting with the ability to automount removable media into the hierarchy. This is more of an issue for mobile computing and/or CD changers; never the less, the idea has a certain value above and beyond the simple act of dynamic configuration of system resources... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 03:30:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01268 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:30:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01255 for ; Fri, 3 Jul 1998 03:30:14 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA09031; Fri, 3 Jul 1998 06:28:17 -0400 (EDT) From: "Allen Smith" Message-Id: <9807030628.ZM9030@beatrice.rutgers.edu> Date: Fri, 3 Jul 1998 06:28:16 -0400 In-Reply-To: sthaug@nethelp.no "Re: Variant Link implementation, continued" (Jul 3, 12:11pm) References: <20545.899460699@verdi.nethelp.no> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: sthaug@nethelp.no, lada@pc8811.gud.siemens.at Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 3, 12:11pm, sthaug@nethelp.no (possibly) wrote: > If anybody should ever consider something similar to HP-UX CDFs, I'd > strongly suggest that this should only be available to root by default. > (on the assumption that root users know what they're doing). > > At one of my former employers we had a large number of HP-UX diskless > hosts, using CDFs. We saw far too many cases of users inadvertently > having their directories "disappear" (and similar problems) because > they had turned the CDF bit on. It was a real support hassle. Another reason to have this limit is to prevent people from hiding files using it from various security checking tools; see Garfinkel & Spafford's _Practical Unix & Internet Security_, pages 136-137. (To give you some idea, it's under "Oddities and Dubious Ideas" for a reason.) -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 03:59:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05995 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 03:59:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oslo.geco-prakla.slb.com (geos01.oslo.geco-prakla.slb.com [134.32.44.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05990 for ; Fri, 3 Jul 1998 03:59:24 -0700 (PDT) (envelope-from smoergrd@geos01.oslo.geco-prakla.slb.com) Received: from sunw132.geco-prakla.slb.com (sunw132 [134.32.45.120]) by oslo.geco-prakla.slb.com (8.8.8/8.6.9) with SMTP id MAA16209 ; Fri, 3 Jul 1998 12:58:01 +0200 (MET DST) Received: by sunw132.geco-prakla.slb.com (SMI-8.6/SMI-SVR4) id MAA09244; Fri, 3 Jul 1998 12:58:00 +0200 To: "Allen Smith" Cc: sthaug@nethelp.no, lada@pc8811.gud.siemens.at, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued References: <20545.899460699@verdi.nethelp.no> <9807030628.ZM9030@beatrice.rutgers.edu> Organization: Schlumberger Geco-Prakla X-Disclaimer: I speak only for myself. From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: 03 Jul 1998 12:57:59 +0200 In-Reply-To: "Allen Smith"'s message of Fri, 3 Jul 1998 06:28:16 -0400 Message-ID: Lines: 18 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Allen Smith" writes: > On Jul 3, 12:11pm, sthaug@nethelp.no (possibly) wrote: > > At one of my former employers we had a large number of HP-UX diskless > > hosts, using CDFs. We saw far too many cases of users inadvertently > > having their directories "disappear" (and similar problems) because > > they had turned the CDF bit on. It was a real support hassle. > Another reason to have this limit is to prevent people from hiding > files using it from various security checking tools; see Garfinkel & > Spafford's _Practical Unix & Internet Security_, pages 136-137. (To > give you some idea, it's under "Oddities and Dubious Ideas" for a > reason.) Now why does this remind me of the recent Windows NT "hidden streams" (or whatever they were called) debacle? DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 04:09:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA08670 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 04:09:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA08504; Fri, 3 Jul 1998 04:08:52 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199807031108.EAA08504@hub.freebsd.org> Subject: Re: FreeBSD equiv. of /proc/loadavg In-Reply-To: <199807030204.TAA17845@usr04.primenet.com> from Terry Lambert at "Jul 3, 98 02:04:16 am" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 3 Jul 1998 04:08:52 -0700 (PDT) Cc: jmb@FreeBSD.ORG, tlambert@primenet.com, joelh@gnu.org, mike@smith.net.au, dmm125@bellatlantic.net, questions@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 Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > with our current strcuture, we have some separation without > > reaching the level of cookiness that sunos 5.5.1 provides: > > 70 shell scripts scattered across 5 directories. > > > Just because only *some* of the SysV rc.d ideas are good, doesn't > mean we have to make a choice between taking all of them, or taking > none of them. Turning ranges into black and white choices is an > Aristotilian mean, and it's simply a bad way of thinking for any > true engineer worth his or her salt. aint that what i said....we have some of the benefits now without the cookiness. ;) jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 04:55:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA15771 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 04:55:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA15761; Fri, 3 Jul 1998 04:55:26 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199807031155.EAA15761@hub.freebsd.org> Subject: Re: trace/KTRACE In-Reply-To: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 3, 98 11:24:53 am" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Fri, 3 Jul 1998 04:55:26 -0700 (PDT) Cc: freebsd-hackers@freefall.cdrom.com 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 Precedence: bulk X-Loop: FreeBSD.ORG Christoph Kukulies wrote: > > Or are there any other ways (other than profiling, which is also an a > posteriori method) to 'watch' what an app does? Sean Eric Fagan (sp?) wrote a truss for FreeBSD. write-up appeared in Dr Dobb's Journal. is this what you are looking for? Aspen:[10] truss cat /etc/resolv.conf syscall open("/etc/resolv.conf",0,00) returns 3 (0x3) syscall fstat(1,0xefbfd754) returns 0 (0x0) syscall readlink("/etc/malloc.conf",0xefbfd6e0,63) errno 2 'No such file or directory' syscall mmap(0x0,4096,0x3,0x1002,-1,0x0) returns 536924160 (0x2000d000) syscall break(0x12000) returns 0 (0x0) syscall break(0x22000) returns 0 (0x0) syscall read(0x3,0x12000,0x10000) returns 161 (0xa1) search frb.gov covance.com atinc.com namsserver 192.168.250.1 # ourselves nameserver 198.35.131.208 # primary.frb.gov nameserver 198.35.166.183 # irmmp4.frb.gov syscall write(1,0x12000,161) returns 161 (0xa1) syscall read(0x3,0x12000,0x10000) returns 0 (0x0) syscall close(3) returns 0 (0x0) syscall close(1) returns 0 (0x0) syscall exit(0x0) process exit, rval = 0 jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 04:57:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA16128 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 04:57:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA16109 for ; Fri, 3 Jul 1998 04:57:11 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5688) with SMTP id NAA29650; Fri, 3 Jul 1998 13:55:40 +0200 (MET DST) Date: Fri, 3 Jul 1998 13:48:26 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: freebsd-chat@elec.jrc.it, freebsd-current@elec.jrc.it, freebsd-stable@elec.jrc.it, freebsd-newbies@elec.jrc.it, freebsd-questions@elec.jrc.it, FreeBSD hackers mailing list Subject: PKGINFO statistics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In short, it would be appreciated if you could execute the command below on your FreeBSD box. It is harmless. /usr/sbin/pkg_info -aI | \ /usr/bin/mail -s "PKGINFO `hostname`" \ nick.hibma@jrc.it (this command should be all on one line, like: /usr/bin/pkg_info -aI | mail -s "PKGINFO `hostname`" nick.hibma@jrc.it The `hostname` in the subject is there to be able to filter out duplicates but is not required at all, in case you want to send it anonymously. It sends me a list of all the packages you have installed on the machine you execute the command on. Reason to do this: In a discussion the idea came up to see if profiles for the usage of packages could be found. If a large number of these pkg_info lists are retrieved we can try to find relations between each two installed packages. This could be used to offer predefined profiles to the user when installing packages. This avoids the user to having to wade through the entire list of packages when deciding what to install. The directory structure present in the /usr/ports directory already provides a means to do this but this could be improved upon. See for a more elaborate discussion the message below. Thanks for your help and my apologies for the cross posting. Please note that I am not subscribed to any of the mailing lists (except hackers) and any flames should be sent to my personal address only. I will collect all the flames and post a digest. :-) Nick Hibma ======== >From nick.hibma@jrc.it Fri Jul 3 13:34:37 1998 Date: Wed, 17 Jun 1998 19:01:14 +0200 (MET DST) From: Nick Hibma To: Garance A Drosihn Cc: FreeBSD hackers mailing list Subject: Re: 2.2.6 CD-ROM : Package dependencies up the creek ? > > That is true, but the idea of profiles and a more copious choice of > > what you might want to install is not a bad idea either I think. > > I think it is a "slippery slope", as each of us has a different > collection of packages which we feel are important for machines > once we have them setup as a production service. If we start down > this path, we will probably end up just reorganizing the ports list, > whereas what I'm hoping for is a very short list of packages which > are displayed during the initial install time. Let's separate between two different issues. One, the more important and urgent one: your point of creating a list of packages which should be optional but most probably necessary on a newly installed system. You mention bash as an example, perl5 is another one. Add a tick box in one of the installation menus and add the packages to the CD and you are done. The more room on the CD the more packages you can add to that list if you like. The idea of profiles is the other one and as you say, it is a slippery slope. Most people install the operating system for the first time to try and if they have the feeling that they are being coached through the process and been given choices that they can easily understand, they'll probably have a better feeling about what is happening to them. Profiles you can see as different views on the database of packages available. You can already see this if you look at the way the packages are structured now. The point is that you can select a number of profiles that suite you. They might overlap, for example web, mail and software development, but you have a preselection of packages which should fullfill most your intended uses. Enhancing the profiles with relations makes it even more sexy. For example, installing MSQL on a development system that also has perl installed could trigger the adding perl5-msql. Having selected X and ghostscript makes it invitable to install ghostview as well. An idea is to collect a lot of pkg_info -aI lists and see if you can use statistics to guess what someone might want to install as well. Taking into account the available disk space and using the statistical analysis to rank the automatically added packages would keep the thing from installing too many things. REQUEST: I hereby post a request for pkg_info -aI listings of FBSD machines. Please add in the subject PKGINFO. That makes the message more of an object that _just_knows_ which mail folder to go to. The following should do: pkg_info -aI | mail -s "PKGINFO `hostname`" nick.hibma@jrc.it should do the trick. And, someone has said this (I cannot remember his name), there should be a step in between the installation of the base system (O sys and basic functionality /usr/bin and packages) and the installation of the packages through selection/profiles/whatever. In contrast to MicroDollar there is a difference between the operating system and the user interface. A remark about the fact that the operating system and base functionality (including the item above, the packages on CD 1) has been completely installed and that he now can continue with the installation of added functionality if he wishes to do so, should be added. To avoid the problem Garance had when installing FreeBSD (supposedly nuking his fresh installation during the installation of XFree) maybe some consolidation stage should be added (reboot) after dumping a README on what to do next to the screen/to more. Shouldn't we force a reboot to make sure we run off a decent medium (common guys, one reboot is not the end of the world! :-) Is it at all possible to install XFree at that stage, because of the lack of swap and RO /usr partition? > I would expect most shells will be on this "short list". As part of the > install process the user going to be asked to create some personal ID's, Account creation is a good one as well for the initial setup phase. At least you can log in as user root with a password or as someone else. It makes it feel more like home instead of a black hole. > shell I "need". Obviously I can get by using other shells, but it > only takes about five minutes before I start missing shell features > which I'm pretty used to. The cursor jumping all over the place when pressing tab, very annoying, yes. :-) Someone who has the CD1 handy should tell us how much space is left there before we embark on listing all our favourite toys. Nick Hibma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 05:02:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA17222 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 05:02:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from limbo.rtfm.net (nathan@38.nyack.fcc.net [204.141.125.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA17217 for ; Fri, 3 Jul 1998 05:02:55 -0700 (PDT) (envelope-from nathan@limbo.rtfm.net) Received: (from nathan@localhost) by limbo.rtfm.net (8.8.8/8.8.8) id IAA02018; Fri, 3 Jul 1998 08:02:06 -0400 (EDT) (envelope-from nathan) Date: Fri, 3 Jul 1998 08:02:06 -0400 (EDT) From: Nathan Dorfman Message-Id: <199807031202.IAA02018@limbo.rtfm.net> To: kuku@gilberto.physik.RWTH-Aachen.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: trace/KTRACE X-Newsgroups: mpc.lists.freebsd.hackers,muc.lists.freebsd.hackers In-Reply-To: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> Organization: RTFM.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> you write: > >I would like to find out where an application 'hangs' for >some overly long time (possibly a network/socket call or something) > >Recently I grabbed out 'trace-1.6' for a HP-UX machine which is >supposed to be based on the SUN kernel trace interface. > >The problem using the kernel option KTRACE would be >that I cannot watch the application as it performs, instead I can >only trace 'a posteriori'. > >Would the be a way to support this utility and the kernel trace interface >under FreeBSD? > >Or are there any other ways (other than profiling, which is also an a >posteriori method) to 'watch' what an app does? Compile it with debugging symbols and run gdb? >-- >Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de -- ________________ ___________________________________________ / Nathan Dorfman \ / "My problems start when the smarter bears / nathan@rtfm.net \/ and the dumber visitors intersect." / finger for PGP key \ Steve Thompson, Yosemite wildlife biologist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 05:08:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18122 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 05:08:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18102 for ; Fri, 3 Jul 1998 05:07:57 -0700 (PDT) (envelope-from marc@bowtie.nl) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id FAA18110 for ; Fri, 3 Jul 1998 05:06:36 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.8.8/1.63) with IAEhv.nl; pid 23710 on Fri, 3 Jul 1998 12:07:50 GMT; id MAA23710 efrom: marc@bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by bowtie.nl (8.8.8/8.8.8) with ESMTP id OAA24029; Fri, 3 Jul 1998 14:09:53 +0200 (CEST) (envelope-from marc@bowtie.nl) Message-Id: <199807031209.OAA24029@bowtie.nl> X-Mailer: exmh version 2.0.2 2/24/98 To: Christoph Kukulies cc: freebsd-hackers@freefall.cdrom.com Subject: Re: trace/KTRACE In-reply-to: kuku's message of Fri, 03 Jul 1998 11:24:53 +0200. <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> Reply-to: marc@bowtie.nl Date: Fri, 03 Jul 1998 14:09:52 +0200 From: Marc van Kempen Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I would like to find out where an application 'hangs' for > some overly long time (possibly a network/socket call or something) > > Recently I grabbed out 'trace-1.6' for a HP-UX machine which is > supposed to be based on the SUN kernel trace interface. > > The problem using the kernel option KTRACE would be > that I cannot watch the application as it performs, instead I can > only trace 'a posteriori'. > > Would the be a way to support this utility and the kernel trace interface > under FreeBSD? > > Or are there any other ways (other than profiling, which is also an a > posteriori method) to 'watch' what an app does? > Can't you use gdb and attach to the running process? gdb 'progname' 'pid' Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 05:19:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20178 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 05:19:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20173 for ; Fri, 3 Jul 1998 05:19:56 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id FAA18317 for ; Fri, 3 Jul 1998 05:18:29 -0700 (PDT) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id OAA20957; Fri, 3 Jul 1998 14:19:50 +0200 (MEST) (envelope-from kuku) Message-ID: <19980703141950.02992@gil.physik.rwth-aachen.de> Date: Fri, 3 Jul 1998 14:19:50 +0200 From: Christoph Kukulies To: marc@bowtie.nl Cc: Christoph Kukulies , freebsd-hackers@freefall.cdrom.com Subject: Re: trace/KTRACE References: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> <199807031209.OAA24029@bowtie.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199807031209.OAA24029@bowtie.nl>; from Marc van Kempen on Fri, Jul 03, 1998 at 02:09:52PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 03, 1998 at 02:09:52PM +0200, Marc van Kempen wrote: > > I would like to find out where an application 'hangs' for > > some overly long time (possibly a network/socket call or something) > > > > Recently I grabbed out 'trace-1.6' for a HP-UX machine which is > > supposed to be based on the SUN kernel trace interface. > > > > The problem using the kernel option KTRACE would be > > that I cannot watch the application as it performs, instead I can > > only trace 'a posteriori'. > > > > Would the be a way to support this utility and the kernel trace interface > > under FreeBSD? > > > > Or are there any other ways (other than profiling, which is also an a > > posteriori method) to 'watch' what an app does? > > > Can't you use gdb and attach to the running process? > > gdb 'progname' 'pid' And then? How would I see what the program is doing? ^C-ing is not what I wish. I believe the mentioned 'truss' seems to do what I want. > > Marc. > > ---------------------------------------------------- > Marc van Kempen BowTie Technology > Email: marc@bowtie.nl WWW & Databases > tel. +31 40 2 43 20 65 > fax. +31 40 2 44 21 86 http://www.bowtie.nl > ---------------------------------------------------- > > -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 05:22:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20486 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 05:22:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20480 for ; Fri, 3 Jul 1998 05:22:21 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id FAA18383 for ; Fri, 3 Jul 1998 05:20:57 -0700 (PDT) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id OAA20970; Fri, 3 Jul 1998 14:21:48 +0200 (MEST) (envelope-from kuku) Message-ID: <19980703142147.60917@gil.physik.rwth-aachen.de> Date: Fri, 3 Jul 1998 14:21:47 +0200 From: Christoph Kukulies To: "Jonathan M. Bresler" Cc: Christoph Kukulies , freebsd-hackers@freefall.cdrom.com Subject: Re: trace/KTRACE References: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> <199807031155.EAA15761@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199807031155.EAA15761@hub.freebsd.org>; from Jonathan M. Bresler on Fri, Jul 03, 1998 at 04:55:26AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 03, 1998 at 04:55:26AM -0700, Jonathan M. Bresler wrote: > Christoph Kukulies wrote: > > > > Or are there any other ways (other than profiling, which is also an a > > posteriori method) to 'watch' what an app does? > > Sean Eric Fagan (sp?) wrote a truss for FreeBSD. > write-up appeared in Dr Dobb's Journal. > > is this what you are looking for? Yes, exactly. /usr/bin/truss is the solution. > > Aspen:[10] truss cat /etc/resolv.conf > syscall open("/etc/resolv.conf",0,00) > returns 3 (0x3) > syscall fstat(1,0xefbfd754) > returns 0 (0x0) > syscall readlink("/etc/malloc.conf",0xefbfd6e0,63) > errno 2 'No such file or directory' > syscall mmap(0x0,4096,0x3,0x1002,-1,0x0) > returns 536924160 (0x2000d000) > syscall break(0x12000) > returns 0 (0x0) > syscall break(0x22000) > returns 0 (0x0) > syscall read(0x3,0x12000,0x10000) > returns 161 (0xa1) > search frb.gov covance.com atinc.com > namsserver 192.168.250.1 # ourselves > nameserver 198.35.131.208 # primary.frb.gov > nameserver 198.35.166.183 # irmmp4.frb.gov > syscall write(1,0x12000,161) > returns 161 (0xa1) > syscall read(0x3,0x12000,0x10000) > returns 0 (0x0) > syscall close(3) > returns 0 (0x0) > syscall close(1) > returns 0 (0x0) > syscall exit(0x0) > process exit, rval = 0 > > > jmb -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 05:32:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA21989 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 05:32:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA21984 for ; Fri, 3 Jul 1998 05:32:54 -0700 (PDT) (envelope-from marc@bowtie.nl) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id FAA18677 for ; Fri, 3 Jul 1998 05:31:33 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.8.8/1.63) with IAEhv.nl; pid 26774 on Fri, 3 Jul 1998 12:32:50 GMT; id MAA26774 efrom: marc@bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by bowtie.nl (8.8.8/8.8.8) with ESMTP id OAA25687; Fri, 3 Jul 1998 14:31:34 +0200 (CEST) (envelope-from marc@bowtie.nl) Message-Id: <199807031231.OAA25687@bowtie.nl> X-Mailer: exmh version 2.0.2 2/24/98 To: Christoph Kukulies cc: marc@bowtie.nl, freebsd-hackers@freefall.cdrom.com Subject: Re: trace/KTRACE In-reply-to: kuku's message of Fri, 03 Jul 1998 14:19:50 +0200. <19980703141950.02992@gil.physik.rwth-aachen.de> Reply-to: marc@bowtie.nl Date: Fri, 03 Jul 1998 14:31:34 +0200 From: Marc van Kempen Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, Jul 03, 1998 at 02:09:52PM +0200, Marc van Kempen wrote: > > > I would like to find out where an application 'hangs' for > > > some overly long time (possibly a network/socket call or something) > > > > > > Recently I grabbed out 'trace-1.6' for a HP-UX machine which is > > > supposed to be based on the SUN kernel trace interface. > > > > > > The problem using the kernel option KTRACE would be > > > that I cannot watch the application as it performs, instead I can > > > only trace 'a posteriori'. > > > > > > Would the be a way to support this utility and the kernel trace interface > > > under FreeBSD? > > > > > > Or are there any other ways (other than profiling, which is also an a > > > posteriori method) to 'watch' what an app does? > > > > > Can't you use gdb and attach to the running process? > > > > gdb 'progname' 'pid' > > And then? How would I see what the program is doing? ^C-ing is > not what I wish. > If you attach to it, while it seems to hang, it will display the function it is currently executing. You don't have to abort the program. It is just a normal debugging session. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 06:04:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24935 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 06:04:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24839 for ; Fri, 3 Jul 1998 06:03:56 -0700 (PDT) (envelope-from witr@spooky.rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id JAA02925 for ; Fri, 3 Jul 1998 09:07:21 -0400 (EDT) (envelope-from witr@spooky.rwwa.com) Message-Id: <199807031307.JAA02925@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Thu, 02 Jul 1998 10:52:26 EDT." <199807021452.KAA15866@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jul 1998 09:07:21 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG rivers@dignus.com said: :- Eventually, we concluded that the fact that a symlink can change :- because of an 'external' influence was a bad idea. More or less, so did I. As you point it it seems to be an idea that doesn't scale well. In our environment of > 1000 computers and approx 100 automounted filesystems, I'd worry that the const of management of using this feature would exceed the benefit. Note that AMD solves a similiar problem in different way. For example, /usr/global/bin gets directed to the correct filesystem based on the architecture/os. Perhaps a *limited* form of this feature (for example, not involving a users ENV) might be useful. I don't think that our internal support people would like a sitation where who filesystem subtrees disappear or get misdirected do to a hapless user accidentally clobbering a environment variable named, say, "OS". I'd urge caution here. --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 07:18:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA04030 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 07:18:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA04024 for ; Fri, 3 Jul 1998 07:18:57 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from mail.camalott.com (root@[208.203.140.2]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id HAA23772 for ; Fri, 3 Jul 1998 07:17:35 -0700 (PDT) Received: from detlev.UUCP (tex-113.camalott.com [208.229.74.113]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id JAA12738; Fri, 3 Jul 1998 09:19:03 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id JAA10403; Fri, 3 Jul 1998 09:19:02 -0500 (CDT) (envelope-from joelh) Date: Fri, 3 Jul 1998 09:19:02 -0500 (CDT) Message-Id: <199807031419.JAA10403@detlev.UUCP> To: kuku@gilberto.physik.RWTH-Aachen.DE CC: marc@bowtie.nl, kuku@gilberto.physik.RWTH-Aachen.DE, freebsd-hackers@freefall.cdrom.com In-reply-to: <19980703141950.02992@gil.physik.rwth-aachen.de> (message from Christoph Kukulies on Fri, 3 Jul 1998 14:19:50 +0200) Subject: Re: trace/KTRACE From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> <199807031209.OAA24029@bowtie.nl> <19980703141950.02992@gil.physik.rwth-aachen.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> I would like to find out where an application 'hangs' for >>> some overly long time (possibly a network/socket call or something) >>> Or are there any other ways (other than profiling, which is also an a >>> posteriori method) to 'watch' what an app does? >> Can't you use gdb and attach to the running process? >> gdb 'progname' 'pid' > And then? How would I see what the program is doing? ^C-ing is > not what I wish. > I believe the mentioned 'truss' seems to do what I want. When gdb attaches to a process, it halts it. You can then do a backtrace to find what's going on. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 07:33:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA06305 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 07:33:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ringworld.uniscape.com ([207.245.48.226]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA06298 for ; Fri, 3 Jul 1998 07:33:17 -0700 (PDT) (envelope-from stefanos@ringworld.uniscape.com) Received: from traveler by ringworld.uniscape.com (NX5.67e/NX3.0M) id AA06969; Fri, 3 Jul 98 10:37:31 -0400 Message-Id: <9807031437.AA06969@ringworld.uniscape.com> Received: by traveler.uniscape.com (NX5.67e/NX3.0X) id AA04456; Fri, 3 Jul 98 10:36:45 -0400 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b5) Received: by NeXT.Mailer (1.118.2) From: Stefanos Kiakas Date: Fri, 3 Jul 98 10:36:43 -0400 To: freebsd-hackers@FreeBSD.ORG Subject: GNUstep 0.5.0 Reply-To: stefanos@ringworld.uniscape.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Has anyone been able to get GNUstep (dgs-0.5.0) to work on FreeBSD. I managed to compile the source code, but I can't seem to get the demos to use DGS. Is anyone working with GNUstep on FreeBSD? Stefanos --- ---------------------------------------------------------------------- Stefanos Kiakas stefanos@uniscape.com http://www.uniscape.com/ e-Scape Information Systems Inc. 514.878.1084 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 08:43:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA13804 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 08:43:37 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA13799 for ; Fri, 3 Jul 1998 08:43:35 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id RAA28708; Fri, 3 Jul 1998 17:43:35 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id RAA05469; Fri, 3 Jul 1998 17:43:34 +0200 (MET DST) Date: Fri, 3 Jul 1998 17:43:34 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807031543.RAA05469@surf.IAE.nl> To: drosih@rpi.edu Subject: Re: Variant Link implementation, continued X-Newsgroups: list.freebsd.hackers In-Reply-To: References: <5406.899427726@time.cdrom.com> Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: [ deleted things about why user would faulup the naming scheme ] >> In any case, this argument is also somewhat moot since neither of >> us is actually doing the work of IMPLEMENTING this baby and it's >> the implementor who is always going to have the final say as to >> how it works anyway. :-) Thank you, I hope I'll get that far. If I ever get my RAID's to work prperly, since that is real work. :-) >Sure, go and get all practical on me. Go ahead and ruin all my >fun babbling... :-) No, the reason I threw this into this forum is to get peoples reaction. I could go in the attic, dig out my old Apollo manuals and just implement that. (With or without the problems that come along) But that's not what I want, I'd like it to be usefull in the FreeBSD way of using this system. Best way to frustrate that is to ignore the culture (and code), and "just do something(tm)" >Actually, though, I think that what I'm proposing is really just >an alternative to environment variables (not just "environment >variables for symbolic links", but "an alternative to environment >variables for holding configuration settings"). Perhaps that >wouldn't be too hard to do a simple cut of? Like Jordan said, I'm not up to inventing ALL the variables people might ever want to use. So we need some slack there. And a name-space is just another namespace: Use ENV's with V_ to start??? The point is relatively moot as long as you let the user "mess" with it. But then that is the charme of the whole deal. >To get the kernel to correctly *use* environment variables for >symbolic links is going to take some work (even if everyone agrees >it's the best of all ideas), and perhaps an alternative would be >less work to do. If so, I can get away with all this babbling >without irritating any person who is actually doing the useful >work on it... :-) Talk don't hurt. I'm a one step at the time person. So my next objective is to just get it to work with a set of sysctl variables, and then everybody can have their go at things they'd like to have. Then I'll be thinking about haveing 2 rules of resolution: @{....} and ${....} The first one only uses the 'system name space' and thus can not be modified by the user. (sort of like the /usr/include files) The second one Will follow a 'hierachical' namespace where the user can change the name contents. BTW, Terry, I see this system namespace as what you the INIT-env. As far as I can see, it is rather hard (even for root) to change init's env once it starts running. So that's perhaps a little to rigid. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 08:53:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14847 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 08:53:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14838 for ; Fri, 3 Jul 1998 08:53:48 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id RAA01968; Fri, 3 Jul 1998 17:53:48 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id RAA10108; Fri, 3 Jul 1998 17:53:48 +0200 (MET DST) Date: Fri, 3 Jul 1998 17:53:48 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807031553.RAA10108@surf.IAE.nl> To: easmith@beatrice.rutgers.edu Subject: Waht are CDF's (Was: Variant Link .....) X-Newsgroups: list.freebsd.hackers In-Reply-To: <9807030628.ZM9030@beatrice.rutgers.edu> References: easmith@beatrice.rutgers.edu (Allen Smith) Organization: Internet Access Eindhoven, the Netherlands Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <9807030628.ZM9030@beatrice.rutgers.edu> you write: >On Jul 3, 12:11pm, sthaug@nethelp.no (possibly) wrote: > >> If anybody should ever consider something similar to HP-UX CDFs, I'd >> strongly suggest that this should only be available to root by default. >> (on the assumption that root users know what they're doing). >> >> At one of my former employers we had a large number of HP-UX diskless >> hosts, using CDFs. We saw far too many cases of users inadvertently >> having their directories "disappear" (and similar problems) because >> they had turned the CDF bit on. It was a real support hassle. > >Another reason to have this limit is to prevent people from hiding >files using it from various security checking tools; see Garfinkel & >Spafford's _Practical Unix & Internet Security_, pages 136-137. (To >give you some idea, it's under "Oddities and Dubious Ideas" for a >reason.) You'll have to educate me: I was one of the initiators of the agry letters towards HP when they took over Apollo and decided to kill DomainOS. So I've refused to work with hockey-puck at that time, and CDF's tell me nothing. But from what I read above the files actually disapeared from the filesystem not to be found elsewhere? How does that relate to links point either left or right. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 08:58:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15268 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 08:58:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15260 for ; Fri, 3 Jul 1998 08:58:17 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id LAA04022; Fri, 3 Jul 1998 11:58:09 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id MAA16422; Fri, 3 Jul 1998 12:30:21 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id MAA18581; Fri, 3 Jul 1998 12:02:04 -0400 (EDT) Date: Fri, 3 Jul 1998 12:02:04 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807031602.MAA18581@lakes.dignus.com> To: drosih@rpi.edu, jkh@time.cdrom.com Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > At 6:36 PM -0700 7/1/98, Jordan K. Hubbard wrote: > >> My initial reaction is that I wouldn't want links to depend on values > >> in environment variables. If I setup some "clean environment" for a > >> program I'm exec-ing, I'm not going to think to copy values which are > >> important for these links to work. > > > > If you have ever used Apollo's Domain/OS, the advantages of having > > synlink behavior be configurable by something as dynamic as the user's > > environment become very quickly apparent. :) > > There's a difference between "being dynamically configurable" and > "being part of a namespace which users, scripts, and programs are > already clobbering on a regular basis with no current need to worry > what that might do to filesystem access". > > I should note that I do want something that's readily configurable. > I just don't think the user-environment is the best place to hold that. > We'll still be getting programs from many other sources which will > blindly manipulate the standard user environment, and which will > not be worried about what that might do to file system access. Yes - I like that distinction! > > I would be a little more specific here on what I'd like to see for > that, but I haven't quite settled on what that would be... In some > sense I'd like a session-level database of keys/values, such that I > could type in something in one xterm, and have that effect all active > applications (or maybe just all applications which *start* after I > enter the command -- even if they are not started from that xterm > window). On the other hand, I have a sneaking suspicion that isn't > quite what I want either... Let's explore this a little more... [I *really* like the idea of a separate name space.] First, having it separate might make this easier to implement (not sure about that.) Also, you'd want the environment inherited just as env is today (child processes shouldn't "loose" links just because they are children.) You'd want command-line interfaces for listing, defining, altering the names&values specified in this space. Now, it comes down to what "magic" are you going to use in the symlink string to denote that the space should be queried... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 08:58:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15335 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 08:58:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15326 for ; Fri, 3 Jul 1998 08:58:44 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id LAA04067; Fri, 3 Jul 1998 11:58:30 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id MAA16386; Fri, 3 Jul 1998 12:25:01 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id LAA18542; Fri, 3 Jul 1998 11:56:44 -0400 (EDT) Date: Fri, 3 Jul 1998 11:56:44 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807031556.LAA18542@lakes.dignus.com> To: mike@smith.net.au, rivers@dignus.com Subject: Re: Variant Link implementation, continued Cc: drosih@rpi.edu, hackers@FreeBSD.ORG, jkh@time.cdrom.com In-Reply-To: <199807021813.LAA01087@antipodes.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > So, given my experience - I'd prefer to not have this feature > > in FreeBSD... I'd suggest, at least, a mechanism (vis sysctl var?) > > to globally disable it at an installation... > > How about "just don't use it"? The point here is that it's an enabling > technology, not an intentional constriction of freedom. If you don't > want it or can't manage it properly, you don't have to use it. > Certainly sounds reasonable - can you think of a way to not accidently use it... I mean, if you use, say '$' to indicate the value should come from an environment variable, then you restrict the name space allowed for other symlinks... Granted, it's outstandingly unintelligent on UNIX to use '$' in the name of a directory or file, but, I happen to have such things because of some mainframe issues; where '$' makes a lot of sense... So, in our environment, I'd prefer another mechanism... Unfortunately, I'd imagine the interecting set of interesting characters to mark an environment variable with is pretty close to empty. So - I'd be interested in seeing proposals that allow for a way to "not use it." I would have thought a sysctl variable would be a good way to "not use it." - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 09:36:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18847 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 09:36:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18842 for ; Fri, 3 Jul 1998 09:36:25 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id MAA08001; Fri, 3 Jul 1998 12:36:10 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id MAA16608; Fri, 3 Jul 1998 12:57:52 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id MAA18898; Fri, 3 Jul 1998 12:29:35 -0400 (EDT) Date: Fri, 3 Jul 1998 12:29:35 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807031629.MAA18898@lakes.dignus.com> To: drosih@rpi.edu, mike@smith.net.au Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG, jkh@time.cdrom.com, rivers@dignus.com In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I think there would be less headaches all-around if symlinks did not > > key off environment variables, although I do think we'd want them to > > key off of something as simple to adjust as environment variables are. > > This expresses my opinion quite succinctly. Overloading the > environment space to also control variant links would be a Very Bad > Idea, simply because the risk of name collision is too high. > > Allowing links to indicate that they *should* be keyed off the > environment space, OTOH, isn't such a sin. eg: > > ${sysctl:hw.arch} and ${env:USER} > > but this creates a new union space with yet another different syntax. > > ${space=sysctl, mib=hw.arch} and ${space=env, var=USER} > > perhaps? > I like this idea (with perhaps a sysctl variable to name the default space if none is provided...) However, I'd like to ask the general syntax question... is there a set of letters from which to choose which will not violate POSIX semantics... That is, can't I, right now, create a file named "${FOO}", or just about anything? So, how do we choose this symlink syntax without potentially breaking something else? - Just curious - - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 09:55:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21057 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 09:55:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers2.stdio.com (lile@heathers2.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA21052 for ; Fri, 3 Jul 1998 09:55:54 -0700 (PDT) (envelope-from lile@stdio.com) Received: (from lile@localhost) by heathers2.stdio.com (8.8.8/8.8.8) id MAA13085; Fri, 3 Jul 1998 12:52:44 -0400 (EDT) Date: Fri, 3 Jul 1998 12:52:43 -0400 (EDT) From: "Larry S. Lile" To: Mike Smith cc: David Greenman , Mike Smith , hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? In-Reply-To: <199807030448.VAA04008@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Jul 1998, Mike Smith wrote: > > > > > > On Wed, 1 Jul 1998, David Greenman wrote: > > > > > >Anyway, the card has a register (isrp) that has a bit that shows whether > > > >or not the card can interrrupt the 8259 on its irq line. This works for > > > >the first interrupt but as soon as I enter an spl loop that bit goes > > > >high, saying he can't interrupt, and never drops even after exiting the > > > >spl loop. > > > > > > Sounds to me like you aren't acking the interrupt in your ISR. > > > > Could I get you to take a peek at whats going on? The adapter spec is > > at (or at least the pages on the status registers) > > http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/BK8R1001 > > /1.4.9.4 > > and the code for the driver is at http://anarchy.stdio.com (or you can get > > to it at http://www.jurai.net/~winter/tr/tr.html). I have been working > > from the MACH source and I can't see what i'm doing wrong. > > > > Whats got me really confused is bit 1 in the ISRP high (even) which > > is called User interrupt blocked? And worst is I can't seem to > > reset it. > > When you say this, have you tried writing a 0 to it? Yeah, I tried reset and rw the bit in the register. The mach driver uses reset. > Also, how about this snippet: > > ADAPTER INTERRUPT ENABLE > For PC System with PC I/O Bus: An I/O Write (OUT instruction) to X'0A23' (adapter 0) or X'0A27' (adapter 1) resets > and re-enables the adapter interrupt generation circuitry. An I/O read to this address is reserved. Seems like swatting flies with a 2x4. I dug into the IBM sample driver for aix and that is what their doing. I guess its good enough. > Apart from that, I would be asking IBM for help... I finally got through to 3rd line support at IBM. I should get to talk to a developer sometime next week (I hope). I started hitting the interrupt reset pio just before I leave my interrupt handler and things seem to be better. Now it just loops like mad when it gets a packet, on to new problems. Thanks for the help. Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 10:29:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25672 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 10:29:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25667 for ; Fri, 3 Jul 1998 10:29:37 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id NAA13438; Fri, 3 Jul 1998 13:29:31 -0400 (EDT) Received: from lakes.dignus.com (lakes [10.0.0.3]) by dignus.com (8.8.8/8.8.5) with ESMTP id NAA16847; Fri, 3 Jul 1998 13:30:57 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.8.8/8.6.9) id NAA19145; Fri, 3 Jul 1998 13:02:38 -0400 (EDT) Date: Fri, 3 Jul 1998 13:02:38 -0400 (EDT) From: Thomas David Rivers Message-Id: <199807031702.NAA19145@lakes.dignus.com> To: drosih@rpi.edu, wjw@surf.IAE.nl Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG In-Reply-To: <199807031543.RAA05469@surf.IAE.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Then I'll be thinking about haveing 2 rules of resolution: > @{....} > and ${....} > I don't mean to badger... but what if you, in an existing installation, already have symlinks that contain that text? Won't adding this facility break those existing links? [And, don't laugh, but I do have links and files that begin with '$', and, even worse, have '$' embedded in the middle of them...] - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 13:09:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12393 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 13:09:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12386 for ; Fri, 3 Jul 1998 13:09:56 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id QAA54782 for ; Fri, 3 Jul 1998 16:09:56 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807030416.VAA03798@antipodes.cdrom.com> References: Your message of "Thu, 02 Jul 1998 18:10:44 EDT." Date: Fri, 3 Jul 1998 16:13:48 -0400 To: hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:16 PM -0700 7/2/98, Mike Smith wrote: >> I think there would be less headaches all-around if symlinks did not >> key off environment variables, although I do think we'd want them to >> key off of something as simple to adjust as environment variables are. > > This expresses my opinion quite succinctly. Overloading the > environment space to also control variant links would be a Very > Bad Idea, simply because the risk of name collision is too high. > > Allowing links to indicate that they *should* be keyed off the > environment space, OTOH, isn't such a sin. eg: > > ${sysctl:hw.arch} and ${env:USER} Now that I've caught up on my sleep a bit, I do think something along these lines could be promising. I can't find Terry's earlier suggestion (even though I know I reread it just last night), but I think that what I want might not be all that much different from what he suggested. Let's say there are three namespaces (just to pick a number): sys session process (I know those aren't the names Terry used, but since I can't find his message I'm making up new names. I'm sure we need better names than what I'm using here...). "Sys" variables are system-wide values. Only root can change them, to everyone else they are read-only. If root changes does them, the value changes for all users on that system. These might be things like "platform", "oslevel", and "arch". "Session" variables can be changed by a user. If the user changes them, the change effects only that user. It will effect all processes related to the current "login session" of that user (if that is doable...). Ie, if I have four xterm's up, and I change the value in one xterm, it is also changed in all other xterms. However, if I have done a "telnet localhost", then that session (the one on the other side of the telnet) is not effected. I expect that the login process itself would probably create the initial values for several session-level variables. "process" variables are just standard environment variables. If you change them in one xterm, other xterms are not effected. It just effects that process, and all processes which that process subsequently execs. - - - If I remember right, that isn't too much of a change from what Terry had suggested. What I think we need to change is the rules for name resolution. Where Terry suggested (in a message that I *can* still find...): My preference?: I. Look in my env II. Look in the process group leader's env III. Look in init's env IV. replace them with "" (zero length string, just as sh does). I would suggest that: ${sys:somevar} always resolves to the session-level variable. the user has no way to dynamically change the target of this link. ${session:somevar} uses the session-level variable, if it exists. If it doesn't exist in the seesion-level, look for a system-level variable of the same name. ${process:somevar} or ${env:somevar} uses the environment-level variable, if it exists. Otherwise, try for a session-level variable of the same name, and if that doesn't exist then go with the system-level variable. I'm not sure what should be done in cases where the variable is not found in any namespaces that are appropriate to search for it. I could probably make up good reasons for any one of: a) replace ${blah:somevar} with "" b) replace ${blah:somevar} with "somevar" (ie, if there is no variable of a given name, then substitute with the name of the variable instead of it's value). c) leave ${blah:somevar} as ${blah:somevar} (ie, act as if there is no such thing as variant symlinks, and just look for a real filename which includes those characters in it). I don't know if the above is the ideal mix, but I think it manages to be safer than earlier suggestions, and yet keeps all the flexibility one *might* want to have for variant symbolic links. I do have a feeling there should be something different than the "session" level as I described it, perhaps replacing that with two other levels. I don't know what I'd want to call those levels or how to describe them, but I just have a vague feeling that "session level" isn't quite right (it seems to me I'm trying to solve more than one issue with that one level...). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 13:48:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16153 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 13:48:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16139 for ; Fri, 3 Jul 1998 13:48:25 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id WAA22439; Fri, 3 Jul 1998 22:45:08 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id WAA02287; Fri, 3 Jul 1998 22:42:51 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807032042.WAA02287@semyam.dinoco.de> To: Christoph Kukulies cc: freebsd-hackers@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: trace/KTRACE In-reply-to: Your message of "Fri, 03 Jul 1998 11:24:53 +0200." <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> Date: Fri, 03 Jul 1998 22:42:50 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I would like to find out where an application 'hangs' for > some overly long time (possibly a network/socket call or something) > The problem using the kernel option KTRACE would be > that I cannot watch the application as it performs, instead I can > only trace 'a posteriori'. So you'd like to have the ktrace output right when the call gets done instead of seeing the whole log after the show ended? How about using option -l of kdump then? It works in 2.2-stable - just tried it with xcalc. I saw the system calls when they were done instead of having to go through the log afterwards. If you want to avoid extremly large files with the ktrace output you might redirect it to /dev/stdout, pipe that into kdump and tell kdump to read from /dev/stdin. I didn't test it and it might fail but is worth a try. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 14:47:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22254 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 14:47:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA22248 for ; Fri, 3 Jul 1998 14:47:14 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from (ragnet.demon.co.uk) [158.152.46.40] by post.mail.demon.net with smtp (Exim 1.82 #2) id 0ysDfg-0002M0-00; Fri, 3 Jul 1998 21:47:09 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 0ys8jE-00040L-00; Fri, 3 Jul 1998 17:30:28 +0100 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <5627.899429983@time.cdrom.com> Date: Fri, 03 Jul 1998 17:30:28 +0100 (BST) From: Duncan Barclay To: "Jordan K. Hubbard" Subject: Re: Pkg_create and setting directory ownership. Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jul-98 Jordan K. Hubbard wrote: >> I'm trying to get pkg_create (on -2.2.6) to set the ownership of some >> directories for a package I'm building. The problem is that >> the @owner directive only affects the files listed in the plist. If you >> list a directory the whole tree below that point is added to the >> final package tar file. > > Which is a known "limitation" (I hesitate to call it a bug). That's > one reason most folks don't list directory names in plists, just their > contents, and then set the directory ownerships in an mtree file if > necessary (though if you've only a few, nobody will grumble if you "cheat" > a little with @exec :-). I've only got four directories to deal with so chmod it is. Would anyone find it useful if I had a bash at removing the "limitation"? I'm happy to fix it, if it needs to be. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 15:25:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25026 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 15:25:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ntas4test.cudenver.edu (ntas4test.cudenver.edu [132.194.70.202]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA25018 for ; Fri, 3 Jul 1998 15:25:17 -0700 (PDT) (envelope-from abaram@ntas4test.cudenver.edu) Received: (from abaram@localhost) by ntas4test.cudenver.edu (8.6.12/8.6.9) id QAA16964; Fri, 3 Jul 1998 16:35:45 -0600 Date: Fri, 3 Jul 1998 16:35:45 -0600 (MDT) From: abaram To: ggi-develop@eskimo.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD port? In-Reply-To: <199807032217.QAA03934@sekurity.xig.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, i am cc'ing this to freebsd-hackers, hope they know whats going on:) Btw, stable died at the same spot today, and i rm -rf'd since last time.. thanks! -Alex Fri, 3 Jul 1998, abaram wrote: > > Hi ! > > > Hi, libggi as of 980622 compile dies at linking stage. > > This is really strange ... > > > gmake[2]: Entering directory `/usr/home/abaram/degas/lib/libggi/display/X' > > ld -L/usr/X11R6/lib -lX11 -lXt -lXext -x -Bshareable -o > > /usr/home/abaram/degas/lib/libggi/display/dll/X.so visual.o mode.o > > events.o color.o > > ld: internal error: RRS relocs exceed allocation 82 > > Hmmm - this is odd. Chances are good we triggered a bug in the linker. > > Please check with some BSD linker freak to see if he can make some sense > of that message. Internal error normally means "Ooops - this shouldn't > happen !". > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 15:49:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27312 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 15:49:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.falcon.com (eppp3.sysnet.net [206.142.16.84]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27307 for ; Fri, 3 Jul 1998 15:49:31 -0700 (PDT) (envelope-from patton@sysnet.net) Received: from [192.168.1.10] ([192.168.1.10]) by gatekeeper.falcon.com (8.8.8/8.8.5) with ESMTP id SAA29046 for ; Fri, 3 Jul 1998 18:41:05 -0400 (EDT) X-Sender: patton@mail.sysnet.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Jul 1998 18:53:38 -0400 To: freebsd-hackers@FreeBSD.ORG From: Matthew Patton Subject: CVSing updates Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not subscribed just yet so a direct response would be most welcome. I'm at 2.2.6 fresh from the ftp sites and after munging my FW setup to allow low port connections (ala old rsh) I'm getting the following error message. What am I still doing wrong? enterprise# cvs up -rRELENG_2_2 sys select: protocol failure in circuit setup cvs [update aborted]: end of file from server (consult above messages if any) CVSROOT=anoncvs@anoncvs.freebsd.org:/cvs -------- It is by caffeine alone I set my mind in motion, it is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning, it is by caffeine alone I set my mind in motion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 16:13:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01460 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 16:13:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01450 for ; Fri, 3 Jul 1998 16:13:33 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id UAA06560 for hackers@freebsd.org; Fri, 3 Jul 1998 20:13:34 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199807032313.UAA06560@roma.coe.ufrj.br> Subject: accton on a append-only file ? To: hackers@FreeBSD.ORG Date: Fri, 3 Jul 1998 20:13:34 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm trying to setup my system to do accounting in a secure fashion. I've created the /var/account/acct file with sappend,sunlink flags, but accton return EPERM. If I run accton before setting those flags, it works, but if I (or a hacker) disable acct, I must reboot to reenable it again (in securelevel >=1 ). This seems to be a bug, but I still have much to learn from VFS before searching for the culprit myself. Does it deserve a send-pr, even without patches ? Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 17:49:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15838 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 17:49:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TELOS.ODYSSEY.CS.CMU.EDU (TELOS.ODYSSEY.CS.CMU.EDU [128.2.185.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15821; Fri, 3 Jul 1998 17:49:38 -0700 (PDT) (envelope-from jaharkes@TELOS.ODYSSEY.CS.CMU.EDU) Received: from TELOS.ODYSSEY.CS.CMU.EDU (localhost [127.0.0.1]) by TELOS.ODYSSEY.CS.CMU.EDU (8.8.7/8.8.7) with ESMTP id UAA01805; Fri, 3 Jul 1998 20:49:32 -0400 Message-Id: <199807040049.UAA01805@TELOS.ODYSSEY.CS.CMU.EDU> X-Mailer: exmh version 2.0zeta 7/24/97 To: coda-announce@TELEMANN.coda.cs.cmu.edu, linux-coda@TELEMANN.coda.cs.cmu.edu, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers.edu, freebsd-hackers@FreeBSD.ORG, freebsd-afs@FreeBSD.ORG, netbsd-announce@netbsd.org, netbsd-current@netbsd.org Subject: Coda version 4.6.1 available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jul 1998 20:49:32 -0300 From: jaharkes@cs.cmu.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Coda distributed file system version 4.6.1 now available http://www.coda.cs.cmu.edu Coda is an advanced experimental distributed file system with features such as server replication and disconnected operation for laptops (see the WWW site). Release 4.6.1 is mainly a bug fix release with changes since 4.4.4 detailed in the ChangeLog file available on the WWW site and in the root of the sources. The major improvements in this release are: Since 4.6.0: - an uninitialized variable error has been found which in combination with a lookup of a symlink of a particlar length could cause an internal fd to be closed which would crash venus. (so only upgrading coda-client-4.6.1 is necessary for people who are already running 4.6.0) Since 4.4.4: - no more server hangs on first time startup of a server - RPC2 packet buffers are now checked for sanity and should not cause segfaults when bad - many thread stack overflows fixed - linux 2.1 kernel code is now MUCH more stable (many changes) - a coda-linux kernel package for easy module building - Linux Debian compilation fixed - major improvements in debugging features - preliminary support for NT & 95 Coda servers - very preliminary support for Win 95 clients (see below) - initial support for FreeBSD & NetBSD packages Stability: we believe this release is a major improvement over the previous one. Coda 4.6.1 on Linux, FreeBSD and NetBSD is very usable as an experimental file system. The development of Coda is largely done within /coda and many of us keep email and other vital files in /coda. We have confusing situations, but have not lost any files. Platforms: Linux (i86 and sparc): Kernel 2.0 -- kernel code included in coda-linux package; this code is not much changed from 4.4.4: it is stable in the sense of not crashing your system, but is known to have odd bugs due to an incomplete implementation of the Coda semantics Kernel 2.1 -- kernel code is included in the Linux kernel, HOWEVER, that code lags our current version, so you should use the kernel code provided in the 4.6.1 coda-kernel package instead (we are holding off submitting patches to avoid overloading Linus). This code closely follows the Coda semantics and is in constant use by most of us, but is less extensively exercised than the 2.0 code and may still, rarely, crash systems. User-level issues: we no longer support libc5; it may still work just fine. The Coda tarball compiles under Debian and there will be a Debian maintainer for Coda at some point (details to be announced). Packages for Red Hat 5.0 are available and appear to work fine on Red Hat 5.1. NetBSD 1.3 x86: NetBSD benefits from the general bugfixes and is working very well both as a server and as a client. Coda for NetBSD 1.3 on x86 is available as NetBSD packages. We will be more than happy to help others port Coda to other NetBSD platforms; we just don't have the resources or hardware to do this ourselves. FreeBSD 2.2.5 & 2.2.6: FreeBSD mostly works very well; It is now released as FreeBSD packages. We have also released our internal "ports" collection for the Coda Client and Server to build the FreeBSD packages with. We apologize that for project reasons we will not be able to adequately test 2.2.6 versions until August. It does appear to work reasonably well on both 2.2.5 and 2.2.6. Win32: Preliminary support for running Coda servers on Windows NT and Windows 95. In this release, the Win32 port is only suitable for developers to experiment with. No kernel-mode code is needed for the Coda server. All building is done with cross-compilation using Cygwin32 from Red Hat Linux (cross-build RPMs are available); see README.nt in the root of the source tree for details. Windows 95: Very preliminary support for a client on Windows 95 is included since 4.6.0. To use this, you need to have the entire Microsoft toolchain necessary to build VxDs for the kernel-level components of Coda. In addition, you need a special cross-compilation environment for the user-level components which is available for Red Hat Linux from our website. Note on Windows ports: we hope that by making this code available we will encourage developers to explore it and perhaps join in development. It is not usable as a filesystem yet. We thank many net contributors for patches, but above all Michael Callahan for developing and contributing the Windows 95 port as well as continuing to be an invaluable resource for our group. Please join our bazaar! Signed: The CMU Coda team Peter J. Braam development leader Shafeeq Sinnamohideen extensive networking code improvements Jan Harkes improvements to the client and RVM Bob Baron BSD support Henry Pierce release engineering Satya head of the group vital for past, present and future development To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 18:20:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18770 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 18:20:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ibridge.iohk.com (root@ibridge.iohk.com [202.21.128.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18750 for ; Fri, 3 Jul 1998 18:20:31 -0700 (PDT) (envelope-from percy@iohk.com) Received: from igate.iohk.com (percy@igate.iohk.com [202.21.128.81]) by ibridge.iohk.com (8.8.5/8.8.5) with ESMTP id JAA02464 for ; Sat, 4 Jul 1998 09:22:35 +0800 (HKT) Received: from localhost (percy@localhost) by igate.iohk.com (8.8.5/8.8.5) with SMTP id JAA27119 for ; Sat, 4 Jul 1998 09:22:34 +0800 (HKT) Date: Sat, 4 Jul 1998 09:22:34 +0800 (HKT) From: Percy Cheng To: hackers@FreeBSD.ORG Subject: How to install my NE2000 compat. NIC?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just installed released 2.2.6, during the installation, it could not detect my NE2000 compatable NIC automatically, how can I install it manually? Thanks a lot for your kindly help...=~> Percy Cheng Internet Online Hong Kong Ltd. Our Web Site:http://www.iohk.com My email box:percy@iohk.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 18:59:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22554 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 18:59:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22549; Fri, 3 Jul 1998 18:59:36 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id LAA07439; Sat, 4 Jul 1998 11:29:35 +0930 (CST) Message-ID: <19980704112934.Y358@freebie.lemis.com> Date: Sat, 4 Jul 1998 11:29:34 +0930 From: Greg Lehey To: Percy Cheng , FreeBSD Questions Subject: Re: How to install my NE2000 compat. NIC?? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Percy Cheng on Sat, Jul 04, 1998 at 09:22:34AM +0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 4 July 1998 at 9:22:34 +0800, Percy Cheng wrote: > > I just installed released 2.2.6, during the installation, > it could not detect my NE2000 compatable NIC automatically, how > can I install it manually? > > Thanks a lot for your kindly help...=~> FreeBSD-hackers is intended for detailled technical discussion, not installation help. We have the FreeBSD-questions list for that. Please send questions of this nature there. I'm assuming your board parameters don't match what the system expects. You need to find out what they are (I/O address and IRQ setting). Then boot with the -c option and use UserConfig to change the kernel's expectations to match your hardware. There's an example of doing this with exactly this board in "The Complete FreeBSD", second edition (http://www.cdrom.com/titles/os/bsdbook2.htm). Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 19:26:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25290 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 19:26:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles316.castles.com [208.214.167.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25274 for ; Fri, 3 Jul 1998 19:26:27 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA07461; Fri, 3 Jul 1998 19:26:24 -0700 (PDT) Message-Id: <199807040226.TAA07461@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Thomas David Rivers cc: drosih@rpi.edu, wjw@surf.IAE.nl, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Fri, 03 Jul 1998 13:02:38 EDT." <199807031702.NAA19145@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jul 1998 19:26:23 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Then I'll be thinking about haveing 2 rules of resolution: > > @{....} > > and ${....} > > > > I don't mean to badger... but what if you, in an existing installation, > already have symlinks that contain that text? Won't adding this > facility break those existing links? > > [And, don't laugh, but I do have links and files that begin with '$', > and, even worse, have '$' embedded in the middle of them...] In the existing sample implementation, you would have to have links whose names comply explicitly with the syntax ...${}... where is a valid tag in the variant link namespace. I think that this is sufficiently unlikely given that there have been only two respondents that actually use '$' in names at all... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 19:28:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25493 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 19:28:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles316.castles.com [208.214.167.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25448 for ; Fri, 3 Jul 1998 19:27:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA07480; Fri, 3 Jul 1998 19:28:32 -0700 (PDT) Message-Id: <199807040228.TAA07480@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garance A Drosihn cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Fri, 03 Jul 1998 16:13:48 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jul 1998 19:28:32 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 9:16 PM -0700 7/2/98, Mike Smith wrote: > >> I think there would be less headaches all-around if symlinks did not > >> key off environment variables, although I do think we'd want them to > >> key off of something as simple to adjust as environment variables are. > > > > This expresses my opinion quite succinctly. Overloading the > > environment space to also control variant links would be a Very > > Bad Idea, simply because the risk of name collision is too high. > > > > Allowing links to indicate that they *should* be keyed off the > > environment space, OTOH, isn't such a sin. eg: > > > > ${sysctl:hw.arch} and ${env:USER} > > > Now that I've caught up on my sleep a bit, I do think something > along these lines could be promising. I can't find Terry's > earlier suggestion (even though I know I reread it just last > night), but I think that what I want might not be all that much > different from what he suggested. > > Let's say there are three namespaces (just to pick a number): > sys > session > process This is immediately bad, in that you want a name from the 'session' namespace to be able to (optionally) override a matching name from the 'sys' namespace. My personal preference is *still* to use an isolated portion of the parameter space, preferably one not currently used for anything else. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 20:40:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA03266 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 20:40:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA03257 for ; Fri, 3 Jul 1998 20:40:34 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id WAA21557; Fri, 3 Jul 1998 22:39:35 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199807040226.TAA07461@antipodes.cdrom.com> References: Your message of "Fri, 03 Jul 1998 13:02:38 EDT." <199807031702.NAA19145@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Jul 1998 22:38:49 -0500 To: Mike Smith From: Richard Wackerbarth Subject: Re: Variant Link implementation, continued Cc: Thomas David Rivers , drosih@rpi.edu, wjw@surf.IAE.nl, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:26 PM -0500 7/3/98, Mike Smith wrote: >> > >> > Then I'll be thinking about haveing 2 rules of resolution: >> > @{....} >> > and ${....} >> > >> >> I don't mean to badger... but what if you, in an existing installation, >> already have symlinks that contain that text? Won't adding this >> facility break those existing links? >> >> [And, don't laugh, but I do have links and files that begin with '$', >> and, even worse, have '$' embedded in the middle of them...] > >In the existing sample implementation, you would have to have links >whose names comply explicitly with the syntax ...${}... where >is a valid tag in the variant link namespace. > >I think that this is sufficiently unlikely given that there have been >only two respondents that actually use '$' in names at all... How much trouble is this syntax going to cause since it looks just like shell parameters and will have to be escaped just the right number of times to get it passed through the shells? Wouldn't it be easier if we avoid a syntax that the shell will alter? Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 21:01:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05515 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 21:01:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA05507 for ; Fri, 3 Jul 1998 21:00:51 -0700 (PDT) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion [10.0.1.2]) by quark.ChrisBowman.com (8.8.8/8.8.8) with SMTP id AAA15582; Sat, 4 Jul 1998 00:13:42 -0500 (EST) (envelope-from crb@ChrisBowman.com) Message-Id: <199807040513.AAA15582@quark.ChrisBowman.com> X-Sender: crb@quark.ChrisBowman.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 03 Jul 1998 23:58:05 -0400 To: Mike Smith From: "Christopher R. Bowman" Subject: Re: Variant Link implementation, continued Cc: Thomas David Rivers , drosih@rpi.edu, wjw@surf.IAE.nl, hackers@FreeBSD.ORG In-Reply-To: <199807040226.TAA07461@antipodes.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:26 PM 7/3/98 , Mike Smith wrote: >> > >> > Then I'll be thinking about haveing 2 rules of resolution: >> > @{....} >> > and ${....} >> > >> >> I don't mean to badger... but what if you, in an existing installation, >> already have symlinks that contain that text? Won't adding this >> facility break those existing links? >> >> [And, don't laugh, but I do have links and files that begin with '$', >> and, even worse, have '$' embedded in the middle of them...] > >In the existing sample implementation, you would have to have links >whose names comply explicitly with the syntax ...${}... where >is a valid tag in the variant link namespace. > >I think that this is sufficiently unlikely given that there have been >only two respondents that actually use '$' in names at all... Does anybody else get the feeling we are reinventing plan9 here? I only know what little I remember of the few plan9 papers I read, but this does sorta seem like a solution to the problems they were having with different architectures, and seems like a sort of hack attempt at their directory/name space manipulations. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/~crb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 21:07:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA06320 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 21:07:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles85.castles.com [208.214.165.85]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA06312 for ; Fri, 3 Jul 1998 21:07:30 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA07881; Fri, 3 Jul 1998 21:07:20 -0700 (PDT) Message-Id: <199807040407.VAA07881@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Wackerbarth cc: Mike Smith , Thomas David Rivers , drosih@rpi.edu, wjw@surf.IAE.nl, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Fri, 03 Jul 1998 22:38:49 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jul 1998 21:07:20 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 9:26 PM -0500 7/3/98, Mike Smith wrote: > >> > > >> > Then I'll be thinking about haveing 2 rules of resolution: > >> > @{....} > >> > and ${....} > >> > > >> > >> I don't mean to badger... but what if you, in an existing installation, > >> already have symlinks that contain that text? Won't adding this > >> facility break those existing links? > >> > >> [And, don't laugh, but I do have links and files that begin with '$', > >> and, even worse, have '$' embedded in the middle of them...] > > > >In the existing sample implementation, you would have to have links > >whose names comply explicitly with the syntax ...${}... where > >is a valid tag in the variant link namespace. > > > >I think that this is sufficiently unlikely given that there have been > >only two respondents that actually use '$' in names at all... > > How much trouble is this syntax going to cause since it looks just > like shell parameters and will have to be escaped just the right number > of times to get it passed through the shells? Wouldn't it be easier if > we avoid a syntax that the shell will alter? The point was to look _just_like_ the shell syntax, to avoid inventing Yet Another Syntax. Given that you already have to do all that magic for passing such text to other shells, this is an something that people already know and understand. We already have lots of diversity; no need to invent more complexity. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 3 23:37:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16861 for freebsd-hackers-outgoing; Fri, 3 Jul 1998 23:37:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cyclops.xtra.co.nz (cyclops.xtra.co.nz [202.27.184.96]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA16856 for ; Fri, 3 Jul 1998 23:37:18 -0700 (PDT) (envelope-from hpearce@xtra.co.nz) Received: from xtr851578 (p25-m6-ch7.dialup.xtra.co.nz [202.27.183.89]) by cyclops.xtra.co.nz (8.8.8/8.8.8) with ESMTP id SAA10483 for ; Sat, 4 Jul 1998 18:36:44 +1200 (NZST) Message-Id: <199807040636.SAA10483@cyclops.xtra.co.nz> From: "Hayden Pearce" To: Subject: Re: unsubscribe freebsd-hackers Date: Sat, 4 Jul 1998 18:33:48 +1200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG unsubscribe freebsd-hackers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 00:44:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA21114 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 00:44:10 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA21069 for ; Sat, 4 Jul 1998 00:44:01 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id JAA26022; Sat, 4 Jul 1998 09:44:07 +0200 (MEST) (envelope-from kuku) Message-ID: <19980704094407.07445@gil.physik.rwth-aachen.de> Date: Sat, 4 Jul 1998 09:44:07 +0200 From: Christoph Kukulies To: Stefan Eggers Cc: Christoph Kukulies , freebsd-hackers@FreeBSD.ORG Subject: Re: trace/KTRACE References: <199807030924.LAA20365@gilberto.physik.RWTH-Aachen.DE> <199807032042.WAA02287@semyam.dinoco.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199807032042.WAA02287@semyam.dinoco.de>; from Stefan Eggers on Fri, Jul 03, 1998 at 10:42:50PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 03, 1998 at 10:42:50PM +0200, Stefan Eggers wrote: > > I would like to find out where an application 'hangs' for > > some overly long time (possibly a network/socket call or something) > > > The problem using the kernel option KTRACE would be > > that I cannot watch the application as it performs, instead I can > > only trace 'a posteriori'. > > So you'd like to have the ktrace output right when the call gets done > instead of seeing the whole log after the show ended? How about using > option -l of kdump then? Thanks. That could be a solution as well although I like the presence of 'truss' now that I've learnt it's there. > > It works in 2.2-stable - just tried it with xcalc. I saw the system > calls when they were done instead of having to go through the log > afterwards. > > If you want to avoid extremly large files with the ktrace output you > might redirect it to /dev/stdout, pipe that into kdump and tell kdump > to read from /dev/stdin. I didn't test it and it might fail but is > worth a try. > > Stefan. > -- > Stefan Eggers Lu4 yao2 zhi1 ma3 li4, > Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. > 51109 Koeln > Federal Republic of Germany -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 01:10:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA24359 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 01:10:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA24344 for ; Sat, 4 Jul 1998 01:10:55 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id EAA54824; Sat, 4 Jul 1998 04:10:30 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199807040228.TAA07480@antipodes.cdrom.com> References: Your message of "Fri, 03 Jul 1998 16:13:48 EDT." Date: Sat, 4 Jul 1998 04:14:23 -0400 To: Mike Smith From: Garance A Drosihn Subject: Re: Variant Link implementation, continued Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Now that I've caught up on my sleep a bit, I do think something >> along these lines could be promising. I can't find Terry's >> earlier suggestion (even though I know I reread it just last >> night), but I think that what I want might not be all that much >> different from what he suggested. >> >> Let's say there are three namespaces (just to pick a number): >> sys >> session >> process > > This is immediately bad, in that you want a name from the 'session' > namespace to be able to (optionally) override a matching name from > the 'sys' namespace. I don't see the problem. Which is to say, my proposal was intended to let people do just exactly what you are asking for. Let's say that the "sys" namespace has a variable called "osversion". This value is read-only to most users (except root), and is set to the version of freebsd that the machine is actually running. The login process may very well copy that "osversion" value to a variable in the "session" namespace which is also called "osversion". Users can not change the copy of oslevel in the "sys" namespace, but they can change the value which is in the "session" namespace. Why would I suggest that we bother having the exact same variable name in both namespaces? So that a person who creates a symlink can say "this symlink *must* key off the *real* version of freebsd that the operating system is running". Another person on the same machine may be using "osversion" to mean "the version of freebsd that I am compiling packages for". For that purpose, you do want the default value to be the same as the real osversion the system is running, but you don't really care if the user wants to specify some other version. Now, if you think about that and then reread what I wrote in the earlier message, you'll see that the login process doesn't really have any need to copy any variables in the "sys" namespace to the "session" namespace. Why? Because if variant symlink refers to ${session:somevar}, and the session namespace has no variable named "somevar", then that link will get the value in the "sys" namespace (assuming the "sys" namespace has one). So when any user creates a variant symlink, they can either refer to ${sys:osversion} or ${session:osversion}. The only difference between the two is that the second one allows other users to redirect the symlink, via whatever unix command is used to add or modify values in the session namespace. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 01:58:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA01413 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 01:58:55 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA01408 for ; Sat, 4 Jul 1998 01:58:51 -0700 (PDT) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 28708 invoked by uid 1001); 4 Jul 1998 08:58:51 +0000 (GMT) To: drosih@rpi.edu Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-Reply-To: Your message of "Sat, 4 Jul 1998 04:14:23 -0400" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 04 Jul 1998 10:58:51 +0200 Message-ID: <28706.899542731@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> Let's say there are three namespaces (just to pick a number): > >> sys > >> session > >> process > > > > This is immediately bad, in that you want a name from the 'session' > > namespace to be able to (optionally) override a matching name from > > the 'sys' namespace. > > I don't see the problem. Which is to say, my proposal was intended > to let people do just exactly what you are asking for. > > Let's say that the "sys" namespace has a variable called "osversion". > This value is read-only to most users (except root), and is set to > the version of freebsd that the machine is actually running. > > The login process may very well copy that "osversion" value to a > variable in the "session" namespace which is also called "osversion". > Users can not change the copy of oslevel in the "sys" namespace, > but they can change the value which is in the "session" namespace. Aren't you simply reinventing VMS logical names & tables here? Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 03:00:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA10946 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 03:00:36 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shadows.aeon.net (bsdhack@shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA10900 for ; Sat, 4 Jul 1998 03:00:24 -0700 (PDT) (envelope-from bsdhack@shadows.aeon.net) Received: (from bsdhack@localhost) by shadows.aeon.net (8.8.8/8.8.3) id NAA04094 for hackers@freebsd.org; Sat, 4 Jul 1998 13:05:41 +0300 (EET DST) From: mika ruohotie Message-Id: <199807041005.NAA04094@shadows.aeon.net> Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-Reply-To: <199807030742.JAA05126@surf.IAE.nl> from Willem Jan Withagen at "Jul 3, 98 09:42:12 am" To: hackers@FreeBSD.ORG Date: Sat, 4 Jul 1998 13:05:41 +0300 (EET DST) 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 Precedence: bulk X-Loop: FreeBSD.ORG > Now this could be a good case, since I remember ordering a DDS drive > somewhere around 1889. ^^^^ do you still have it? since i believe any reasonable person would be ready to pay _fortunes_ and more from 1889 DDS technology. ^^^^ =) mickey ps. i just _had_ to say it, sue me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 04:48:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA23867 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 04:48:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nt5.spline.net (nt5.ipi.kiev.ua [194.44.182.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA23848 for ; Sat, 4 Jul 1998 04:48:18 -0700 (PDT) (envelope-from tat@Spline.NET) Received: from localhost (tat@localhost) by nt5.spline.net (8.8.8/8.8.7) with SMTP id OAA22301; Sat, 4 Jul 1998 14:48:01 +0300 (EEST) Date: Sat, 4 Jul 1998 14:48:01 +0300 (EEST) From: Alexander Tatmaniants To: Percy Cheng cc: hackers@FreeBSD.ORG Subject: Re: How to install my NE2000 compat. NIC?? In-Reply-To: Message-ID: Replay-To: tat@spline.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 4 Jul 1998, Percy Cheng wrote: > Date: Sat, 4 Jul 1998 09:22:34 +0800 (HKT) > From: Percy Cheng > To: hackers@FreeBSD.ORG > Subject: How to install my NE2000 compat. NIC?? > > > I just installed released 2.2.6, during the installation, > it could not detect my NE2000 compatable NIC automatically, how > can I install it manually? This is not question for hackers list. You have to manualy enter your card parameters in boot time configuration. boot: -c ... config> visual ... You can use ed0 entry in network devices section for this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 05:52:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA27838 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 05:52:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA27831; Sat, 4 Jul 1998 05:52:36 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from heidi (mobile18.jrc.it [139.191.250.18]) by mrelay.jrc.it (LMC5688) with SMTP id OAA11025; Sat, 4 Jul 1998 14:52:28 +0200 (MET DST) Date: Sat, 4 Jul 1998 14:54:25 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi Reply-To: Nick Hibma To: FreeBSD hackers mailing list cc: sos@FreeBSD.ORG, Nick Hibma Subject: character type mouse Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-725232148-899556865=:352" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-725232148-899556865=:352 Content-Type: TEXT/PLAIN; charset=US-ASCII Here are the diffs for the CHARACTER_MOUSE. They are done on 2.2.1. I'll send you better ones as soon as I get my hands on the 3.0 and 2.2.5 machines at work, Soren. The effect of 10-20% interrupt time, was indeed related to that one occurrence of waiting for the retrace. The CPU utilisation stays at zero now. There is still one of the busy waiting loops in there with the destructive cursor. Dunno if that is anything important/often called though. The code as it is could be improved upon probably by more thoroughly checking whether the mouse pointer has moved at all, but I didn't bother as it most probably only clutters the code with ifdef's with not noticably improving efficiency. The Netherlands will win, 2-1, mark my words. Cheers, A Dutchman in Italy. P.S.: The coloring scheme: const int col_conv[16] = {6,6,6,6,2,2,2,6,14,14,14,14,10,10,10,14}; if ( crtc_addr == COLOR_BASE ) color = (col_conv[(cur_val&0xf000)>>12]<<12) | (cur_val&0x0f00|0x0800); /* Set bold attr */ else /* black & white: reverse colors (XXX untested) */ color = ((cur_val&0xf000)>>4) | ((cur_val&0x0f00)<<4); --0-725232148-899556865=:352 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="syscons.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Diffs -C3 to the files modified KioqIHN5c2NvbnMuYy5vcmlnCVNhdCBKdWwgIDQgMTA6NTI6MDMgMTk5OA0K LS0tIHN5c2NvbnMuYwlTYXQgSnVsICA0IDE0OjE4OjE0IDE5OTgNCioqKioq KioqKioqKioqKg0KKioqIDM0NzksMzQ4NCAqKioqDQotLS0gMzQ3OSwzNDg1 IC0tLS0NCiAgCWFkZHJlc3MgPSAoY2FkZHJfdClWSURFT01FTSArIDB4NDAw MDsNCiAgICAgIH0NCiAgDQorICNpZm5kZWYgQ0hBUkFDVEVSX01PVVNFDQog ICAgICBpZiAoc2NwLT5zdGF0dXMgJiBNT1VTRV9WSVNJQkxFKSB7DQogIAlp ZiAoKHNjcC0+Y3Vyc29yX3NhdmV1bmRlciAmIDB4ZmYpID09IDB4ZDApDQog ICAgICAJICAgIGJjb3B5dygmc2NwLT5tb3VzZV9jdXJzb3JbMF0sIGN1cnNv ciwgc2NwLT5mb250X3NpemUpOw0KKioqKioqKioqKioqKioqDQoqKiogMzQ5 MywzNDk4ICoqKioNCi0tLSAzNDk0LDM1MDAgLS0tLQ0KICAgCSAgICAgICAJ ICAgY3Vyc29yLCBzY3AtPmZvbnRfc2l6ZSk7DQogICAgICB9DQogICAgICBl bHNlDQorICNlbmRpZg0KICAgICAgCWJjb3B5dyhmb250X2J1ZmZlciArICgo c2NwLT5jdXJzb3Jfc2F2ZXVuZGVyICYgMHhmZikgKiBzY3AtPmZvbnRfc2l6 ZSksDQogICAJICAgICAgIGN1cnNvciwgc2NwLT5mb250X3NpemUpOw0KICAg ICAgZm9yIChpPTA7IGk8MzI7IGkrKykNCioqKioqKioqKioqKioqKg0KKioq IDM2MDYsMzYxNyAqKioqDQogIHN0YXRpYyB2b2lkDQogIGRyYXdfbW91c2Vf aW1hZ2Uoc2NyX3N0YXQgKnNjcCkNCiAgew0KICAgICAgY2FkZHJfdCBhZGRy ZXNzOw0KICAgICAgaW50IGk7DQogICAgICBjaGFyICpmb250X2J1ZmZlcjsN CiAgICAgIHVfc2hvcnQgYnVmZmVyWzMyXTsNCiAgICAgIHVfc2hvcnQgeG9m ZnNldCwgeW9mZnNldDsNCi0gICAgIHVfc2hvcnQgKmNydF9wb3MgPSBDcnRh dCArIChzY3AtPm1vdXNlX3BvcyAtIHNjcC0+c2NyX2J1Zik7DQogICAgICBp bnQgZm9udF9zaXplID0gc2NwLT5mb250X3NpemU7DQogIA0KICAgICAgaWYg KGZvbnRfc2l6ZSA8IEZPTlRfMTQpIHsNCi0tLSAzNjA4LDM2MjAgLS0tLQ0K ICBzdGF0aWMgdm9pZA0KICBkcmF3X21vdXNlX2ltYWdlKHNjcl9zdGF0ICpz Y3ApDQogIHsNCisgICAgIHVfc2hvcnQgKmNydF9wb3MgPSBDcnRhdCArIChz Y3AtPm1vdXNlX3BvcyAtIHNjcC0+c2NyX2J1Zik7DQorICNpZm5kZWYgQ0hB UkFDVEVSX01PVVNFDQogICAgICBjYWRkcl90IGFkZHJlc3M7DQogICAgICBp bnQgaTsNCiAgICAgIGNoYXIgKmZvbnRfYnVmZmVyOw0KICAgICAgdV9zaG9y dCBidWZmZXJbMzJdOw0KICAgICAgdV9zaG9ydCB4b2Zmc2V0LCB5b2Zmc2V0 Ow0KICAgICAgaW50IGZvbnRfc2l6ZSA9IHNjcC0+Zm9udF9zaXplOw0KICAN CiAgICAgIGlmIChmb250X3NpemUgPCBGT05UXzE0KSB7DQoqKioqKioqKioq KioqKioNCioqKiAzNjc0LDM2NzkgKioqKg0KLS0tIDM2NzcsMzcwNyAtLS0t DQogICAgICB9DQogICAgICBtYXJrX2Zvcl91cGRhdGUoc2NwLCBzY3AtPm1v dXNlX3BvcyAtIHNjcC0+c2NyX2J1Zik7DQogICAgICBtYXJrX2Zvcl91cGRh dGUoc2NwLCBzY3AtPm1vdXNlX3BvcyArIHNjcC0+eHNpemUgKyAxIC0gc2Nw LT5zY3JfYnVmKTsNCisgI2Vsc2UNCisgICAgIC8qIE5XSCAtIG5pY2suaGli bWFAanJjLml0DQorICAgICAgKiBhZGRlZCBjb2RlIHRvIHN1cHBvcnQgY2hh cmFjdGVyIGZvcm1hdCBtb3VzZS4NCisgICAgICAqLw0KKyAgICAgaW50IGN1 cl92YWwgPSAqKHNjcC0+bW91c2VfcG9zKTsNCisgICAgIGludCBjb2xvcjsN CisgDQorICAgICAvKiBSZWQsIG1hZ2VudGEgYW5kIGJyb3duIGFyZSBtYXBw ZWQgdG8gZ3JlZW4gdG8gdG8ga2VlcCBpdCByZWFkYWJsZQ0KKyAgICAgICov DQorICAgICBjb25zdCBpbnQgY29sX2NvbnZbMTZdID0NCisgCSAgICB7Niw2 LDYsNiwyLDIsMiw2LDE0LDE0LDE0LDE0LDEwLDEwLDEwLDE0fTsNCisgDQor ICAgICBpZiAoIGNydGNfYWRkciA9PSBDT0xPUl9CQVNFICkNCisgCWNvbG9y ID0gICAoY29sX2NvbnZbKGN1cl92YWwmMHhmMDAwKT4+MTJdPDwxMikNCisg CQl8IChjdXJfdmFsJjB4MGYwMHwweDA4MDApOwkvKiBTZXQgZm9yZ3JvdW5k IHRvIGJvbGQgKi8NCisgICAgIGVsc2UNCisgIAkvKiBibGFjayAmIHdoaXRl OiByZXZlcnNlIGNvbG9ycyAoWFhYIHVudGVzdGVkKSAqLw0KKyAJY29sb3Ig PSAoKGN1cl92YWwmMHhmMDAwKT4+NCkgfCAoKGN1cl92YWwmMHgwZjAwKTw8 NCk7DQorIA0KKyAgICAgc2NwLT5tb3VzZV9vbGRwb3MgPSBzY3AtPm1vdXNl X3BvczsNCisgDQorICAgICAqKGNydF9wb3MpID0gKGN1cl92YWwmMHgwMGZm KXwoY29sb3ImMHhmZjAwKTsNCisgDQorICAgICBtYXJrX2Zvcl91cGRhdGUo c2NwLCBzY3AtPm1vdXNlX3BvcyAtIHNjcC0+c2NyX2J1Zik7DQorICNlbmRp Zg0KICB9DQogIA0KICBzdGF0aWMgdm9pZA0KKioqKioqKioqKioqKioqDQoq KiogMzY4MSwzNjkyICoqKioNCi0tLSAzNzA5LDM3MjYgLS0tLQ0KICB7DQog ICAgICB1X3Nob3J0ICpjcnRfcG9zID0gQ3J0YXQgKyAoc2NwLT5tb3VzZV9v bGRwb3MgLSBzY3AtPnNjcl9idWYpOw0KICANCisgI2lmZGVmIENIQVJBQ1RF Ul9NT1VTRQ0KKyAgICAgLyogTldIIC0gbmljay5oaWJtYUBqcmMuaXQgLSBh ZGRlZCBzdXBwb3J0IGZvciBhIGNoYXJhY3RlciBtb3VzZSAqLw0KKyAgICAg KihjcnRfcG9zKSA9ICooc2NwLT5tb3VzZV9vbGRwb3MpOw0KKyAgICAgbWFy a19mb3JfdXBkYXRlKHNjcCwgc2NwLT5tb3VzZV9vbGRwb3MgLSBzY3AtPnNj cl9idWYpOw0KKyAjZWxzZQ0KICAgICAgKihjcnRfcG9zKSA9ICooc2NwLT5t b3VzZV9vbGRwb3MpOw0KICAgICAgKihjcnRfcG9zKzEpID0gKihzY3AtPm1v dXNlX29sZHBvcysxKTsNCiAgICAgICooY3J0X3BvcytzY3AtPnhzaXplKSA9 ICooc2NwLT5tb3VzZV9vbGRwb3Mrc2NwLT54c2l6ZSk7DQogICAgICAqKGNy dF9wb3Mrc2NwLT54c2l6ZSsxKSA9ICooc2NwLT5tb3VzZV9vbGRwb3Mrc2Nw LT54c2l6ZSsxKTsNCiAgICAgIG1hcmtfZm9yX3VwZGF0ZShzY3AsIHNjcC0+ bW91c2Vfb2xkcG9zIC0gc2NwLT5zY3JfYnVmKTsNCiAgICAgIG1hcmtfZm9y X3VwZGF0ZShzY3AsIHNjcC0+bW91c2Vfb2xkcG9zICsgc2NwLT54c2l6ZSAr IDEgLSBzY3AtPnNjcl9idWYpOw0KKyAjZW5kaWYNCiAgfQ0KICANCiAgc3Rh dGljIHZvaWQNCioqKiBIRUlESS5vcmlnCVNhdCBKdWwgIDQgMTE6MTU6MDAg MTk5OA0KLS0tIEhFSURJCVNhdCBKdWwgIDQgMTE6MTY6MDIgMTk5OA0KKioq KioqKioqKioqKioqDQoqKiogMzksNDQgKioqKg0KLS0tIDM5LDQ2IC0tLS0N CiAgb3B0aW9ucwkJU1lTVlNFTQ0KICBvcHRpb25zCQlTWVNWTVNHDQogIA0K KyBvcHRpb25zICAgICBDSEFSQUNURVJfTU9VU0UgICAjIHVzZSBjaGFyYWN0 ZXIgbW91c2UgaW5zdGVhZCBvZiBwaXhlbCBtb3VzZQ0KKyANCiAgb3B0aW9u cwkJRERCCQkjIEFkZCBzdXBwb3J0IGZvciBrZXJuZWwgZGVidWdnZXINCiAg b3B0aW9ucwkJS1RSQUNFDQogIA0KKioqIExJTlQub3JpZwlTYXQgSnVsICA0 IDExOjE0OjU1IDE5OTgNCi0tLSBMSU5UCVNhdCBKdWwgIDQgMTE6MTU6MzYg MTk5OA0KKioqKioqKioqKioqKioqDQoqKiogNTEzLDUxOCAqKioqDQotLS0g NTEzLDUyMCAtLS0tDQogIGRldmljZQkJc2MwCWF0IGlzYT8gcG9ydCAiSU9f S0JEIiB0dHkgaXJxIDEgdmVjdG9yIHNjaW50cg0KICBvcHRpb25zCQlNQVhD T05TPTE2CQkjIG51bWJlciBvZiB2aXJ0dWFsIGNvbnNvbGVzDQogIG9wdGlv bnMJCVNMT1dfVkdBCQkjIGRvIGJ5dGUtd2lkZSBpL28ncyB0byBUUyBhbmQg R0RDIHJlZ3MNCisgb3B0aW9ucyAgICAgU0NfU1BMQVNIX1NDUkVFTiAgIyA/ Pw0KKyBvcHRpb25zICAgICBDSEFSQUNURVJfTU9VU0UgICAjIHVzZSBjaGFy YWN0ZXIgbW91c2UgaW5zdGVhZCBvZiBwaXhlbCBtb3VzZQ0KICANCiAgIw0K ICAjIGBmbGFncycgZm9yIHNjMDoNCioqKiBvcHRpb25zLmkzODYub3JpZwlT YXQgSnVsICA0IDE0OjI0OjE4IDE5OTgNCi0tLSBvcHRpb25zLmkzODYJU2F0 IEp1bCAgNCAxMToxNDoxMyAxOTk4DQoqKioqKioqKioqKioqKioNCioqKiA0 NSw1MCAqKioqDQotLS0gNDUsNTEgLS0tLQ0KICBTQ19TUExBU0hfU0NSRUVO CW9wdF9zeXNjb25zLmgNCiAgTUFYQ09OUwkJCW9wdF9zeXNjb25zLmgNCiAg U0xPV19WR0EJCW9wdF9zeXNjb25zLmgNCisgQ0hBUkFDVEVSX01PVVNFICAg b3B0X3N5c2NvbnMuaA0KICANCiAgUFNNX0FDQ0VMCQlvcHRfcHNtLmgNCiAg UFNNX0VNVUxBVElPTgkJb3B0X3BzbS5oDQo= --0-725232148-899556865=:352-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 06:28:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA00728 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 06:28:39 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00723; Sat, 4 Jul 1998 06:28:37 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id PAA21772; Sat, 4 Jul 1998 15:28:37 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id PAA26905; Sat, 4 Jul 1998 15:28:37 +0200 (MET DST) Date: Sat, 4 Jul 1998 15:28:37 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807041328.PAA26905@surf.IAE.nl> To: hackers@FreeBSD.ORG Subject: Re: Apollo tapes (was: Variant Link implementation, continued) X-Newsgroups: list.freebsd.hackers In-Reply-To: <199807030025.TAA18925@nospam.hiwaay.net> References: Organization: Internet Access Eindhoven, the Netherlands Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199807030025.TAA18925@nospam.hiwaay.net> you write: >Willem Jan Withagen writes: >> You ( David Kelly ) write: >> => For dd its "conv=swab". >> => >> => To duplicate your tapes use tcopy(1) if you have two tape drives. Tcopy >> >> Well I can't even dd them of either tape. So I've haven't een gotten into >> data incompatibility issues >> Julian suggested RTFM 'mt blocksize'. Which I'll as soon as I reboot to >> get the tape operational on my FreeBSD box. > >They were written on 4mm DAT? Not something weird like QIC-100? Saw an >HP "development system" which wrote QIC-100 format to DC-6150 tapes, I >think. Tapes had to be formatted. Then they mounted like a filesystem. >Slower than a tax refund. > >In the early bad old days of DAT (more correctly known as DSS) there >were more problems than there should have been with one tape drive not >being able to read tapes from another, all other things the same. Oke, My drive is again on line: [~] wjw@digi> mt stat Present Mode: Density = X3B5/88-185A Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = X3.136-1986 Blocksize = 512 bytes Mode 2: Density = X3.39-1986 Blocksize variable Mode 3: Density = X3.54-1986 Blocksize variable looking at: man mt: The different density codes are as follows: 0x0 default for device 0xE reserved for ECMA Value Tracks Density(bpi) Code Type Reference Note ........ 0x13 1 61000 DDS CS X3B5/88-185A 4 0x14 1 43245 RLL CS X3.202-1991 4 0x15 1 45434 RLL CS ECMA TC17 4 Which are 3 DAT formats. And thus it is a DDS-coded tape. And thus: How do I read this tape on a: (ncr0:6:0): "HP HP35480A T603" type 1 removable SCSI 2 st0(ncr0:6:0): Sequential-Access I've tried: mt density 0x13 but that buys me very little st0(ncr0:6:0): COMMAND FAILED (4 88) @f0697400. st0(ncr0:6:0): COMMAND FAILED (4 88) @f0697400. st0(ncr0:6:0): Deferred Error: MEDIUM ERROR asc:3b,0 Sequential positioning error Anybody with more suggestions?? (other than finding the "old" tapedrive) --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 06:32:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA01150 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 06:32:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA01138; Sat, 4 Jul 1998 06:32:43 -0700 (PDT) (envelope-from sos) Message-Id: <199807041332.GAA01138@hub.freebsd.org> Subject: Re: character type mouse In-Reply-To: from Nick Hibma at "Jul 4, 98 02:54:25 pm" To: nick.hibma@jrc.it Date: Sat, 4 Jul 1998 06:32:43 -0700 (PDT) Cc: hackers@FreeBSD.ORG, sos@FreeBSD.ORG, nick.hibma@jrc.it From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Nick Hibma who wrote: > > Here are the diffs for the CHARACTER_MOUSE. They are done on 2.2.1. I'll > send you better ones as soon as I get my hands on the 3.0 and 2.2.5 > machines at work, Soren. OK, I'll look at it and commit when I'm done.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 08:48:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10935 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 08:48:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10927 for ; Sat, 4 Jul 1998 08:48:40 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id RAA29430; Sat, 4 Jul 1998 17:47:54 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id RAA12932; Sat, 4 Jul 1998 17:14:49 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807041514.RAA12932@semyam.dinoco.de> Cc: Christoph Kukulies , Stefan Eggers To: freebsd-hackers@FreeBSD.ORG Subject: Re: trace/KTRACE In-reply-to: Your message of "Sat, 04 Jul 1998 09:44:07 +0200." <19980704094407.07445@gil.physik.rwth-aachen.de> Date: Sat, 04 Jul 1998 17:14:48 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Thanks. That could be a solution as well although I like the presence > of 'truss' now that I've learnt it's there. 2.2-stable or 2.2-current? Just a few minutes ago I discovered I have a truss man page on my system and looked for the origin. Now I know that 2.2-stable has such an entry in the ktrace Makefile for the man page but no binary with that name in sight. I will take a closer look at the CVS repository today to find out what's going on. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 08:48:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10984 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 08:48:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10979 for ; Sat, 4 Jul 1998 08:48:55 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id RAA29432; Sat, 4 Jul 1998 17:47:58 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id RAA13938; Sat, 4 Jul 1998 17:45:37 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807041545.RAA13938@semyam.dinoco.de> cc: Joao Carlos Mendes Luis , seggers@semyam.dinoco.de To: hackers@FreeBSD.ORG Subject: Re: accton on a append-only file ? In-reply-to: Your message of "Fri, 03 Jul 1998 20:13:34 -0300." <199807032313.UAA06560@roma.coe.ufrj.br> Date: Sat, 04 Jul 1998 17:45:36 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've created the /var/account/acct file with sappend,sunlink flags, > but accton return EPERM. If I run accton before setting those flags, > This seems to be a bug, but I still have much to learn from VFS To me, too. It is because kern_acct.c in 2.2-stable opens the file for writing, not for appending. There is the problem: /* * If accounting is to be started to a file, open that file for * writing and make sure it's a 'normal'. */ if (uap->path != NULL) { NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_USERSPACE, uap->path, p); error = vn_open(&nd, FWRITE, 0); if (error) return (error); Unless there is already a PR for this (check the PR database on the FreeBSD web pages) I'd suggest sending in a new one. > before searching for the culprit myself. Does it deserve a send-pr, > even without patches ? I think it's as easy as adding FAPPEND to the mode. The only problem is making sure that it has no unexpected side effects. If you like quote this email in the PR to point at a possible way to fix it. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 08:49:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11037 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 08:49:25 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11032 for ; Sat, 4 Jul 1998 08:49:22 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id RAA29431; Sat, 4 Jul 1998 17:47:57 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id RAA13559; Sat, 4 Jul 1998 17:31:55 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199807041531.RAA13559@semyam.dinoco.de> Cc: Mike Smith , Percy Cheng , seggers@semyam.dinoco.de To: hackers@FreeBSD.ORG Subject: Re: About FreeBSD boot manager... In-reply-to: Your message of "Thu, 02 Jul 1998 21:10:50 PDT." <199807030410.VAA03762@antipodes.cdrom.com> Date: Sat, 04 Jul 1998 17:31:54 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > detail on : What's mean within 1024 cylinders?? And how > > much the HDD space can be located within it?? > > This depends on your disk. Typically, it means that you're restricted > to the first 500MB of an IDE disk. But one shouldn't depend on this to be the exact number for all disks. My brothers new 5.1 GByte IDE harddisk says it has 15 heads and then the amount of space useable for bootable partitions will be smaller by a factor of 16/15. Take 1024, multiply it by the number of sectors per track and then multiply by the number of heads. To convert it to KByte divide by a factor of 2 as a sector is 512 Bytes. That's the useable space for booting in KByte. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 09:38:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16024 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 09:38:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15988; Sat, 4 Jul 1998 09:38:31 -0700 (PDT) (envelope-from son@cezanne.prism.uvsq.fr) Received: from cezanne.prism.uvsq.fr (rtc103.reseau.uvsq.fr [193.51.24.19]) by soleil.uvsq.fr (8.8.8/jtpda-5.3) with ESMTP id SAA27068 ; Sat, 4 Jul 1998 18:38:29 +0200 (METDST) Received: (from son@localhost) by cezanne.prism.uvsq.fr (8.8.8/8.8.5) id VAA00485; Thu, 2 Jul 1998 21:28:39 GMT Message-ID: <19980702212453.49115@breizh.prism.uvsq.fr> Date: Thu, 2 Jul 1998 21:24:53 +0000 From: Nicolas Souchu To: fewtch@serv.net Cc: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Syquest SparQ Parallel Port driver... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Tim Gerchmez on Sat, Jun 27, 1998 at 01:23:31PM -0700 X-Operating-System: FreeBSD breizh 3.0-CURRENT FreeBSD 3.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jun 27, 1998 at 01:23:31PM -0700, Tim Gerchmez wrote: > >Greetings, > >Anyone know if anybody is working on a FreeBSD driver for the Syquest SparQ >parallel port drive, or if such a driver exists already in a beta stage? I've >contacted ShuttleTech as well (probably useless) about this requesting any info. >they can provide. Thanks for any info (plz Email me direct), > >Tim >fewtch@serv.net You may try to look at Linux parport home page to see if there's something about it. And maybe try to port it. see at http://www.torque.net/linux-pp.html -- Nicolas.Souchu@prism.uvsq.fr FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 11:38:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25233 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 11:38:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25203; Sat, 4 Jul 1998 11:38:33 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA25911; Sat, 4 Jul 1998 11:33:42 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd025906; Sat Jul 4 18:33:33 1998 Date: Sat, 4 Jul 1998 11:33:29 -0700 (PDT) From: Julian Elischer To: Willem Jan Withagen cc: hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Apollo tapes (was: Variant Link implementation, continued) In-Reply-To: <199807041328.PAA26905@surf.IAE.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It is already running in that mode.. rememberr the four devices rst0.0 thru rst0.3 have the fixed modes mentionned (though you can change each..) and rst0 has the DEFAULT mode so try a few different densities (even past 0x18) and see which ones the DRIVE accepts. also then try setting blocksize to 512 (since that's what you think you wrote) On Sat, 4 Jul 1998, Willem Jan Withagen wrote: > In article <199807030025.TAA18925@nospam.hiwaay.net> you write: > > Oke, My drive is again on line: > > [~] wjw@digi> mt stat > Present Mode: Density = X3B5/88-185A Blocksize variable > ---------available modes--------- > Mode 0: Density = 0x00 Blocksize variable > Mode 1: Density = X3.136-1986 Blocksize = 512 bytes > Mode 2: Density = X3.39-1986 Blocksize variable > Mode 3: Density = X3.54-1986 Blocksize variable > > looking at: man mt: > The different density codes are as follows: > > 0x0 default for device > 0xE reserved for ECMA > > Value Tracks Density(bpi) Code Type Reference Note > ........ > 0x13 1 61000 DDS CS X3B5/88-185A 4 > 0x14 1 43245 RLL CS X3.202-1991 4 > 0x15 1 45434 RLL CS ECMA TC17 4 > no, they are set from the drive type not the tape. The DEFAULT mode is what the drive thinks is there, but you might try teh others in case it is wrong.. > Which are 3 DAT formats. And thus it is a DDS-coded tape. > > And thus: > How do I read this tape on a: > (ncr0:6:0): "HP HP35480A T603" type 1 removable SCSI 2 > st0(ncr0:6:0): Sequential-Access > > I've tried: > mt density 0x13 > but that buys me very little > st0(ncr0:6:0): COMMAND FAILED (4 88) @f0697400. > st0(ncr0:6:0): COMMAND FAILED (4 88) @f0697400. > st0(ncr0:6:0): Deferred Error: MEDIUM ERROR asc:3b,0 Sequential positioning > error > > Anybody with more suggestions?? (other than finding the "old" tapedrive) obviously it is NOT 0x13.. try 0x14 and 0x15 julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 11:59:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27526 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 11:59:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27510 for ; Sat, 4 Jul 1998 11:59:14 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id MAA18298; Sat, 4 Jul 1998 12:54:20 -0600 (MDT) Date: Sat, 4 Jul 1998 12:54:20 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199807041854.MAA18298@narnia.plutotech.com> To: "Larry S. Lile" cc: hackers@FreeBSD.ORG Subject: Re: Problems with irq 9(2)? Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I started hitting the interrupt reset pio just before I leave my > interrupt handler and things seem to be better. Now it just loops like > mad when it gets a packet, on to new problems. Shouldn't you clear the interrupt status (via the reset), before processing the event in your interrupt handler instead of the other way around? I would expect you to potentially miss interrupts the other way around, but I don't know anything about the specifics of the hardware you're working with. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 13:21:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09249 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 13:21:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun1 (bingsun1.cc.binghamton.edu [128.226.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA09240 for ; Sat, 4 Jul 1998 13:21:00 -0700 (PDT) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun1 (SMI-8.6/8.6.9) with SMTP id QAA19647 for ; Sat, 4 Jul 1998 16:20:57 -0400 Date: Sat, 4 Jul 1998 16:20:57 -0400 (EDT) From: zhihuizhang X-Sender: bf20761@bingsun1 To: hackers Subject: Lock mechanism questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think lock is done through some test-and-set hardware instruction. I read the Intel documents and find many instructions can be used for such purpose provided you add the LOCK prefix (However, those instructions do not include SAL mentioned in a previous posting). With these in mind, I began search in vain for something like XCHG, CMPXCHG. However, I do find that in file vm/lock.h, there are comments like: "interlock field is used for hardware exclusion, other fields are modified with *normal* instructions after we got the interlock *bit*" I am confused with this comments. Where is the interlock field defined? Which hardware instruction is used to implement atomic operation on it? By the way, I know spin lock is not suitable for interrupt routines that access the same data structures. Can anyone give me a reason for this? Thanks a lot. ------------------------------------------------- Zhihui Zhang Department of Computer Science State University of New York at Binghamton Web Site: http://cs.binghamton.edu/~zzhang ------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 13:28:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10197 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 13:28:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10186 for ; Sat, 4 Jul 1998 13:28:49 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA09005; Sat, 4 Jul 1998 13:28:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd008992; Sat Jul 4 13:28:45 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA01169; Sat, 4 Jul 1998 13:28:44 -0700 (MST) From: Terry Lambert Message-Id: <199807042028.NAA01169@usr02.primenet.com> Subject: Re: Variant Link implementation, continued To: drosih@rpi.edu (Garance A Drosihn) Date: Sat, 4 Jul 1998 20:28:42 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Garance A Drosihn" at Jul 3, 98 01:02:23 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 Precedence: bulk X-Loop: FreeBSD.ORG > To quote from the article written by Terry: > > For example, we could have made the /usr/lib/aout change appear > > to have zero impact. > > My guess is that no one is going to make the aout change appear to > have zero impact by assuming *every* *end-user* is individually > going to create symbolic links and set environment variables. Actually, that is not what I intended to happen. What I intended to happen was that the variable would be set in the process logical name table by the execuation class loader (which knows this information). If you attempt to execve(2) a program, and it is an a.out program, you get a.out variant link resoloution for it. So if I type "ldconfig", and "ldconfig" is an a,out program, then it will reference the files in /usr/lib -> /usr/libx/${#BINFORMAT} (or however the link is arranged). I chose the # as a namespace escape to place system variable into an environment because: 1) You can't create them with a leading '#', normally, in a shell. 2) You can't create them with a leading '#', normally, using the setenv(3)/putenv(3) interface to the libc. 3) Using: set > x ... ... . x Works as expected: the lines are treated as comments, and not attempted to be set, as use of "@" or some other prefix would be, and it is improper for programs to set into the system space. I expect the list of "system" valiables would either be a view onto the sysctl namespace (for the system logical name table, nominally belonging to the "init" process), or set per process group and per process as an override by the kernel (ie: for things like an a.out binary calling fork(2) then the child calling execve(2) to start a Linux branded ELF binary). In no case would this perticular soloution result in the end user setting anything themselves. > No, I > suspect some administrator or system-developer is the person making > the decision to create that particular symbolic link... And once > they do, then *every* end user had better not choose that particular > environment variable unless they fully understand how it's being used > for this symbolic link (even though ideally they wouldn't even know > the link exists). As you can see, for kernel set variables derived from information beyond the user's control, a namespace escape that in inaccessible to the standard environment interfaces (except "char **environ", and it's deprecated by the design) there is no danger. > Actually, though, I think that what I'm proposing is really just > an alternative to environment variables (not just "environment > variables for symbolic links", but "an alternative to environment > variables for holding configuration settings"). Perhaps that > wouldn't be too hard to do a simple cut of? I do not like the idea of inventing "yet another place to store configuration information"; I would *prefer* a soloution that unifies the environment. Since the kernel can't go to the envronment (if "char **environ" is *ever* extended), the environment can go to the kernel. This seems to be an obvious soloution to me, and it just happens to solve a slew of other problems (the "manipulate parent environmnet after a vfork" problem, the "manipulate an unrelated processes environment, for which you have the uid to do the job" problem -- ie: DISPLAY, among others, etc.). > To get the kernel to correctly *use* environment variables for > symbolic links is going to take some work (even if everyone agrees > it's the best of all ideas), and perhaps an alternative would be > less work to do. If so, I can get away with all this babbling > without irritating any person who is actually doing the useful > work on it... :-) I have implemented the code on an experimental basis. I am not terrifically happy with needing a new system call, nor am I happy with (basically) moving some of the existing libc code into the kernel; I'd prefer a lighter weight approach. I also have not resolved the exec(3) family's passing of "char **environ" to the execve(2) system call issues (in particular, my previous speculation about whther or not you are allowed to pass a NULL environment pointer, or must pass a NULL-valued real memory pointer remains unknown, so the "magic cookie" for the default "inherit from parent" is still not nailed down. But the code works. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 13:36:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11059 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 13:36:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11054 for ; Sat, 4 Jul 1998 13:36:39 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id NAA15957; Sat, 4 Jul 1998 13:36:42 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd015932; Sat Jul 4 13:36:32 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA01481; Sat, 4 Jul 1998 13:36:30 -0700 (MST) From: Terry Lambert Message-Id: <199807042036.NAA01481@usr02.primenet.com> Subject: Re: Variant Link implementation, continued To: dg@root.com Date: Sat, 4 Jul 1998 20:36:29 +0000 (GMT) Cc: drosih@rpi.edu, hackers@FreeBSD.ORG In-Reply-To: <199807030946.CAA06443@implode.root.com> from "David Greenman" at Jul 3, 98 02:46:26 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 Precedence: bulk X-Loop: FreeBSD.ORG > >I agree that the possible keys (ie, variable names) for symbolic > >links should not be something that's fixed at system build time. > > I sure don't agree with that. I also think Jordan's desire to have symlinks > translated with the user environment is either not attainable or undesirable > or both. I personally would rather that the info be kept in a seperate name > table (like what Terry suggested). I also prefer to have a hierarchical > structure (also like Terry suggested, except that I'd have the system table > as a seperate autonomous thing and not attached to the init process). Hmmm. I think "#kern.osrelease" or "#hw.machine" might be a sufficient escape mechanism. The point was really the the init PID (or 0) be used to reference an inherited system space. It's not as important that it actually be hung off a proc structure, it just makes it more orthoganal to have one type of object backing the logical name table. I'm easy on this one, etiher way... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 13:51:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12591 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 13:51:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12574 for ; Sat, 4 Jul 1998 13:51:10 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA13028; Sat, 4 Jul 1998 13:51:10 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd013014; Sat Jul 4 13:51:08 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id NAA01973; Sat, 4 Jul 1998 13:51:04 -0700 (MST) From: Terry Lambert Message-Id: <199807042051.NAA01973@usr02.primenet.com> Subject: Re: Variant Link implementation, continued To: easmith@beatrice.rutgers.edu (Allen Smith) Date: Sat, 4 Jul 1998 20:51:04 +0000 (GMT) Cc: sthaug@nethelp.no, lada@pc8811.gud.siemens.at, hackers@FreeBSD.ORG In-Reply-To: <9807030628.ZM9030@beatrice.rutgers.edu> from "Allen Smith" at Jul 3, 98 06:28:16 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 Precedence: bulk X-Loop: FreeBSD.ORG > > If anybody should ever consider something similar to HP-UX CDFs, I'd > > strongly suggest that this should only be available to root by default. > > (on the assumption that root users know what they're doing). > > > > At one of my former employers we had a large number of HP-UX diskless > > hosts, using CDFs. We saw far too many cases of users inadvertently > > having their directories "disappear" (and similar problems) because > > they had turned the CDF bit on. It was a real support hassle. > > Another reason to have this limit is to prevent people from hiding > files using it from various security checking tools; see Garfinkel & > Spafford's _Practical Unix & Internet Security_, pages 136-137. (To > give you some idea, it's under "Oddities and Dubious Ideas" for a > reason.) CDF's have a number of technical problems, not the least of which is their abuse. The are similar in nature to Macintosh "resource forks". A better model is the OS/2 "extended attributes", which tend to scale vastly better (consider Macintosh PPC dual-mode binaries as an example of the wrong way to do things). True variant symbolic links (or even the more limited VMS "logical names", which are left-anchored instead of free-floating in the path), do not have these issues, primarily because the link target must be an exposed namespace. Even if you were to miss the consequences of a link target. The one real security issue that this introduces is suid/sgid binaries depending on a variant link. Consider /usr/bin/su, which is dynamically linked against: /usr/lib/libutil.so.2.2 /usr/lib/libskey.so.2.0 /usr/lib/libcrypt.so.2.0 /usr/lib/libc.so.3.0 One need only change the value that evaluates to "/usr/lib/" to stage a man-in-the-middle attack, right? This is very easily thwarted: 1) Use a system namespace introducer (such as "#"). 2) If the user directly calls an exec(3) family routine that takes an envp, and thus passes an envp to execve(2), then filter the incoming environment, removing system variables. 3) Reset the system variables per the normal methods used during loading the executable. In other words, protect regions of the namespace from user override. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 14:08:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14472 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 14:08:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14461; Sat, 4 Jul 1998 14:08:10 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA28826; Sat, 4 Jul 1998 13:58:43 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028820; Sat Jul 4 20:58:34 1998 Date: Sat, 4 Jul 1998 13:58:28 -0700 (PDT) From: Julian Elischer To: hackers@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: block device on wst device. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ther is a block interface to wst is this used by anyone? does it work? I think the block interface should go away as it doesn't really make much sense on tapes. (same for wt.c) In effect it went a way some time ago for st.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 14:30:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17025 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 14:30:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA17020 for ; Sat, 4 Jul 1998 14:30:07 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA23762; Sat, 4 Jul 1998 14:30:08 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd023679; Sat Jul 4 14:30:01 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA02700; Sat, 4 Jul 1998 14:09:43 -0700 (MST) From: Terry Lambert Message-Id: <199807042109.OAA02700@usr02.primenet.com> Subject: Re: Variant Link implementation, continued To: witr@rwwa.com (Robert Withrow) Date: Sat, 4 Jul 1998 21:09:42 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199807031307.JAA02925@spooky.rwwa.com> from "Robert Withrow" at Jul 3, 98 09:07:21 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :- Eventually, we concluded that the fact that a symlink can change > :- because of an 'external' influence was a bad idea. > > More or less, so did I. As you point it it seems to be an > idea that doesn't scale well. > > In our environment of > 1000 computers and approx 100 automounted > filesystems, I'd worry that the const of management of using this feature > would exceed the benefit. One problem with a non-hierachical approach is that two of the most interesting applications are per process, not per system. This fits poorly into the "put it in sysconfig" model. > Note that AMD solves a similiar problem in different way. For > example, /usr/global/bin gets directed to the correct filesystem > based on the architecture/os. One issue with amd (which is only partially resolvable using the symlink generation on the mounted fs instead of loopback) is that loopback mounts via NFS are poison. It is rather easy to hang every process using the loopback with a nice starvation deadlock when using it for programs for which the loopback is a swap store. Pretty much every time a local application server bounces (from which I run netscape and fvwm95 locally) I end up having to reboot my FreeBSD box because it believe the NFS handles are "stale", and does not properly recover operations in progress at the time of the bounce. This was a real problem, when the machine in question had hardware stability problems recently. I felt like my FreeBSD box had been turned into a (Gack!) PC. FS architecture politics aside, the use of the existing NFS client code for critical functions like locating your real /usr/lib would be a *very* bad move. It's a resolv*able* problem, but it is not a resolv*ed* problem. > Perhaps a *limited* form of this feature (for example, not involving a > users ENV) might be useful. I don't think that our internal support > people would like a sitation where who filesystem subtrees disappear > or get misdirected do to a hapless user accidentally clobbering a > environment variable named, say, "OS". Per previous discussion: this can't happen, if it's implemented correctly. The particular environment variable in question on the a.out issue would be (re)set in the execve(2), and apply to the process about to run, in any case. It's children would derive the same variable. A program could screw itself, without the namespace escape being implemented, but it couldn't screw another program, even subprocesses. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 14:43:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18017 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 14:43:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18006; Sat, 4 Jul 1998 14:43:42 -0700 (PDT) (envelope-from sos) Message-Id: <199807042143.OAA18006@hub.freebsd.org> Subject: Re: block device on wst device. In-Reply-To: from Julian Elischer at "Jul 4, 98 01:58:28 pm" To: julian@whistle.com (Julian Elischer) Date: Sat, 4 Jul 1998 14:43:42 -0700 (PDT) Cc: hackers@FreeBSD.ORG, sos@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@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 Precedence: bulk X-Loop: FreeBSD.ORG In reply to Julian Elischer who wrote: > > ther is a block interface to wst > > is this used by anyone? no > does it work? The entire wst driver is only alpha code, it will be replaced with atapi-tape when I get the new ata/atapi subsystem finished, so dont waste any time on it ok?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 14:53:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18928 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 14:53:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18920; Sat, 4 Jul 1998 14:53:16 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id XAA20273; Sat, 4 Jul 1998 23:53:15 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id TAA05966; Sat, 4 Jul 1998 19:47:19 +0200 (CEST) X-Face: " Date: Sat, 4 Jul 1998 19:47:19 +0200 From: Stefan Esser To: Peter van Heusden , freebsd-hackers@FreeBSD.ORG Cc: Stefan Esser Subject: Re: SCSI drive not remapping bad block: Any solution (fwd) Mail-Followup-To: Peter van Heusden , freebsd-hackers@FreeBSD.ORG, Stefan Esser References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Peter van Heusden on Fri, Jul 03, 1998 at 08:30:18AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-07-03 08:30 +0200, Peter van Heusden wrote: > I'm getting the following error message from my new SCSI disk: > > Jul 1 21:46:49 leftside /kernel: sd2(ncr0:4:0): MEDIUM ERROR > info:0x38787b asc 11,0 Unrecovered read error field replaceable unit: ea > sks:80,11 Seems the disk got a physical defect, which is detected only when data is read from that sector (i.e. the sector header is not affected). But you already knew that ... > I've recently reformatted it with scsiformat (after getting the error > previously), and I assume that this error message means there is a medium If you reformat the drive and retain the grown defects list, then I'd expect the drive to replace that bad sector. This did not work for you, so I expect that the format command started with just the vendor defects list and did not find the bad spot during the verification pass. > error on the disk. The scsi(8) command shows AWRE and ARRE are both set to > 1, yet this error persists, which makes me conclude that the disk is > not remapping the block correctly. The ARRE bit controls whether a sector is automatically, if the drive notices a read error. In case of a recoverable read error the original contents is written to the replacement sector, and you will never notice :) But in case of a "Unrecovered read error" (see error message above ;-) the replacement sector will be marked "force error" until it is rewritten with new data. This is done to have a new sector assigned, but still return an indication that the original data has been lost to the application. In order to recover from that error, you may want to write new data to the replacement sector, and the easiest way to do this is to "dd if=/dev/zero of=/dev/rsd1c bs=64k" (assuming that the drive is "sd1" ...). Use "dd if=/dev/rsd1c of=/dev/null bs=64" to verify that the drive actually marked the replacement block "valid" ... Then restore the backup you made as the first step (you didn't forget to make a backup, did you ? ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 15:09:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21009 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 15:09:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hobby.digiware.nl (hobby.digiware.nl [194.151.74.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20996 for ; Sat, 4 Jul 1998 15:09:01 -0700 (PDT) (envelope-from wjw@hobby.digiware.nl) Received: (from wjw@localhost) by hobby.digiware.nl (8.8.8/8.8.5) id AAA00267 for hackers@freebsd.org; Sun, 5 Jul 1998 00:12:13 +0200 (CEST) Date: Sun, 5 Jul 1998 00:12:13 +0200 (CEST) From: Willem Jan Withagen Message-Id: <199807042212.AAA00267@hobby.digiware.nl> To: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 15:12:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21535 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 15:12:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hobby.digiware.nl (hobby.digiware.nl [194.151.74.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21524 for ; Sat, 4 Jul 1998 15:12:04 -0700 (PDT) (envelope-from wjw@hobby.digiware.nl) Received: (from wjw@localhost) by hobby.digiware.nl (8.8.8/8.8.5) id AAA00277 for hackers@freebsd.org; Sun, 5 Jul 1998 00:15:22 +0200 (CEST) From: Willem Jan Withagen Message-Id: <199807042215.AAA00277@hobby.digiware.nl> Subject: adding to sysctl env. To: hackers@FreeBSD.ORG Date: Sun, 5 Jul 1998 00:15:22 +0200 (CEST) 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 Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm trying to add things to the sysctl environment, and I thought to take a simple step first: make a debug.switch for the vlink module. So I added: ---- /* * For the vlink module debugging */ static int vlinkxlatedebug = 0; SYSCTL_INT(_debug, OID_AUTO, vlinkxlate, CTLFLAG_RW, &vlinkxlatedebug, 0, ""); ---- expecting to see it apear in my sysctl -a output. But guess what: I didn't. :-{ Now I've been grepping my feed off, but I can not seem to be able to find any other information on how to do this. I've studied the "equal" debug.vfscache, but I'm still missing the clou. --WjW To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 17:24:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00729 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 17:24:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep2-orange.clear.net.nz (fep2-orange.clear.net.nz [203.97.32.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00724 for ; Sat, 4 Jul 1998 17:24:30 -0700 (PDT) (envelope-from jabley@clear.co.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep2-orange.clear.net.nz (1.5/1.9) with ESMTP id MAA23427; Sun, 5 Jul 1998 12:23:59 +1200 (NZST) Received: from localhost (jabley@localhost) by buddha.clear.net.nz (8.8.8/8.8.8) with SMTP id MAA26594 for ; Sun, 5 Jul 1998 12:23:51 +1200 (NZST) (envelope-from jabley@clear.co.nz) Date: Sun, 5 Jul 1998 12:23:51 +1200 (NZST) From: Joe Abley X-Sender: jabley@buddha.clear.net.nz Reply-To: Joe Abley To: hackers@FreeBSD.ORG Subject: ethernet peculiarity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I just put FreeBSD 2.2.6-RELEASE on a Pentium 133 box, 8M RAM, Intel 82439 PCI chipset, Intel 82371SB PCI-ISA bridge. Everything looks normal, and yet I have had a complete inability to get either 3c509 or NE2000-clone ethernet cards to function. The following example is from the NE2000 clone, but the 3c509 symptoms were identical (but with the ep driver). I tried three different 3c509 cards with the same results. Basically, the machine appears to boot and identify the card, but I get repeated kernel messages of "ed0: device timeout". dmesg reveals: ed0 at 0x300-0x31f irq 10 flags 0x4 on isa ed0: address 00:c0:58:20:bg:16, type NE2000 (16 bit) This results from a kernel configuration of: device ed0 at isa? port 0x300 net irq 10 flags 0x04 iomem 0xd8000 vector edintr I have tried this without the flags parameter, and with a flags parameter of 0x02. Same result. This card is an ExpertLan INET2000, which works on win95 as an NE2000. The manufacturer's setup utility confirms the card is working, and is set for port 0x300, irq 10 (with no memory-mapped I/O). This may well be a completely inappropriate list for this (in which case "sorry"); however, I _was_ interested in what could cause a generic kernel-wide ethernet (or ISA?) failure in a machine. What is going on? Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 18:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03856 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:16:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03839; Sat, 4 Jul 1998 18:16:49 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id KAA17365; Sun, 5 Jul 1998 10:46:48 +0930 (CST) Message-ID: <19980705104647.O358@freebie.lemis.com> Date: Sun, 5 Jul 1998 10:46:47 +0930 From: Greg Lehey To: Willem Jan Withagen , hackers@FreeBSD.ORG Cc: scsi@FreeBSD.ORG Subject: Re: Apollo tapes (was: Variant Link implementation, continued) References: <199807030025.TAA18925@nospam.hiwaay.net> <199807041328.PAA26905@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807041328.PAA26905@surf.IAE.nl>; from Willem Jan Withagen on Sat, Jul 04, 1998 at 03:28:37PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 4 July 1998 at 15:28:37 +0200, Willem Jan Withagen wrote: > In article <199807030025.TAA18925@nospam.hiwaay.net> you write: >> In the early bad old days of DAT (more correctly known as DSS) there >> were more problems than there should have been with one tape drive not >> being able to read tapes from another, all other things the same. > > Oke, My drive is again on line: > > [~] wjw@digi> mt stat > Present Mode: Density = X3B5/88-185A Blocksize variable > ---------available modes--------- > Mode 0: Density = 0x00 Blocksize variable > Mode 1: Density = X3.136-1986 Blocksize = 512 bytes > Mode 2: Density = X3.39-1986 Blocksize variable > Mode 3: Density = X3.54-1986 Blocksize variable > > looking at: man mt: > The different density codes are as follows: > > 0x0 default for device > 0xE reserved for ECMA > > Value Tracks Density(bpi) Code Type Reference Note > ........ > 0x13 1 61000 DDS CS X3B5/88-185A 4 > 0x14 1 43245 RLL CS X3.202-1991 4 > 0x15 1 45434 RLL CS ECMA TC17 4 > > Which are 3 DAT formats. And thus it is a DDS-coded tape. This describes the tape unit, not the tape. We've already established that it can't read the tape. > Anybody with more suggestions?? (other than finding the "old" tapedrive) Give up? Or send them to Mike? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 18:19:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04195 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:19:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Gatekeeper.Alameda.net (root@gatekeeper.Alameda.net [207.90.181.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA04178 for ; Sat, 4 Jul 1998 18:19:21 -0700 (PDT) (envelope-from soren@soekris.dk) Received: by Gatekeeper.Alameda.net (8.9.0/8.8.6) with SMTP id SAA25469; Sat, 4 Jul 1998 18:19:16 -0700 (PDT) X-SMTP: helo soren.soekris from soren@soekris.dk server @207.90.187.212 ip 207.90.187.212 Message-ID: <359ED491.7F3C@soekris.dk> Date: Sat, 04 Jul 1998 18:19:13 -0700 From: Soren Kristensen Reply-To: soren@soekris.dk Organization: Soekris Engineering X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: Joe Abley CC: hackers@FreeBSD.ORG Subject: Re: ethernet peculiarity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Joe, It looks like a classic interrupt conflict, have you tried using another irq number, irq 10 is usually used by the PS2 mouse port, even if no mouse is connected ? Joe Abley wrote: > > Hi all, > > I just put FreeBSD 2.2.6-RELEASE on a Pentium 133 box, 8M RAM, Intel 82439 > PCI chipset, Intel 82371SB PCI-ISA bridge. > > Everything looks normal, and yet I have had a complete inability to get > either 3c509 or NE2000-clone ethernet cards to function. The following > example is from the NE2000 clone, but the 3c509 symptoms were identical > (but with the ep driver). I tried three different 3c509 cards with the > same results. > > Basically, the machine appears to boot and identify the card, but I get > repeated kernel messages of "ed0: device timeout". > > dmesg reveals: > > ed0 at 0x300-0x31f irq 10 flags 0x4 on isa > ed0: address 00:c0:58:20:bg:16, type NE2000 (16 bit) > > This results from a kernel configuration of: > > device ed0 at isa? port 0x300 net irq 10 flags 0x04 iomem 0xd8000 vector edintr > > I have tried this without the flags parameter, and with a flags parameter > of 0x02. Same result. This card is an ExpertLan INET2000, which works on > win95 as an NE2000. The manufacturer's setup utility confirms the card is > working, and is set for port 0x300, irq 10 (with no memory-mapped I/O). > > This may well be a completely inappropriate list for this (in which case > "sorry"); however, I _was_ interested in what could cause a generic > kernel-wide ethernet (or ISA?) failure in a machine. > > What is going on? > > Joe > > -- > Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 > Network Architect, CLEAR Net http://www.clear.net.nz/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 18:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06007 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:40:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles321.castles.com [208.214.167.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05998 for ; Sat, 4 Jul 1998 18:40:53 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00808; Sat, 4 Jul 1998 12:49:48 -0700 (PDT) Message-Id: <199807041949.MAA00808@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Peter van Heusden cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI drive not remapping bad block: Any solution (fwd) In-reply-to: Your message of "Sat, 03 Jul 1998 08:30:18 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Jul 1998 12:49:48 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I sent this message to freebsd-questions, but didn't get a response. Maybe > it was too technical for that list... so I was wondering if anyone on > freebsd-hackers had any ideas: See the manpage for scsi(8), which contains an exampled ready for cutting-and-pasting. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 18:42:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06247 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:42:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles321.castles.com [208.214.167.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06168 for ; Sat, 4 Jul 1998 18:42:00 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00679; Sat, 4 Jul 1998 12:31:58 -0700 (PDT) Message-Id: <199807041931.MAA00679@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: sthaug@nethelp.no cc: drosih@rpi.edu, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Sat, 04 Jul 1998 10:58:51 +0200." <28706.899542731@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Jul 1998 12:31:58 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Aren't you simply reinventing VMS logical names & tables here? > If you were following this discussion last time, you would have the background on where we overlap and differ. Basically, we are faced with a large parameter space, and the need to present 'views' of this space varying with context. Right now, the space is fragmented along storage/access boundaries, with sections grown on an ad-hoc basis as required for their immediate consumers. What we are seeing now is a growing number of situations where consumers need to access parameters from multiple spaces, and are being confronted with numerous problems stemming from the nature of implementation of these separate fragments. For example, the variant link decoder really wants to be able to key a link off many things, but in the specific context or 'view' of the process for whom the link translation is being made. The link may want to draw on parameters that are traditionally stored in the process' environment (or that of its parents), or on parameters stored in the sysctl database, or others again. This is the same basic problem that led Apollo, Digital and many others to look at a single, unified parametric store. To grow, we need to do this as well. We have a lot of other peoples' experience to learn from, not to mention bicker about. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 18:54:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA07719 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:54:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07713 for ; Sat, 4 Jul 1998 18:54:29 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id LAA17478; Sun, 5 Jul 1998 11:24:06 +0930 (CST) Message-ID: <19980705112405.U358@freebie.lemis.com> Date: Sun, 5 Jul 1998 11:24:05 +0930 From: Greg Lehey To: Mike Smith , sthaug@nethelp.no Cc: drosih@rpi.edu, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued References: <28706.899542731@verdi.nethelp.no> <199807041931.MAA00679@antipodes.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807041931.MAA00679@antipodes.cdrom.com>; from Mike Smith on Sat, Jul 04, 1998 at 12:31:58PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 4 July 1998 at 12:31:58 -0700, Mike Smith wrote: >> >> Aren't you simply reinventing VMS logical names & tables here? > > If you were following this discussion last time, you would have the > background on where we overlap and differ. Well, I wasn't--there's just been too much discussion. When you stop beating each other over the head, would the winner please come out and say what you've decided? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 22:24:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22582 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 22:24:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dog.farm.org (gw-hssi-2.farm.org [209.66.103.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22577 for ; Sat, 4 Jul 1998 22:23:56 -0700 (PDT) (envelope-from dog.farm.org!dk) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id WAA03651; Sat, 4 Jul 1998 22:21:16 -0700 (PDT) Date: Sat, 4 Jul 1998 22:21:16 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199807050521.WAA03651@dog.farm.org> To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Console driver (was: Problems with irq 9(2)?) 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 Precedence: bulk X-Loop: FreeBSD.ORG In article you wrote: > sos@freebsd.org writes: > > In reply to Dag-Erling Coidan Smørgrav who wrote: > > > sos@freebsd.org writes: > > > > Second, 256 chars is not enough anyways, so having 252 is just a little worse. > > > > Third, it was done by "popular demand", so there is use for it. > > > > Fourth, it was fun doing :) > > > Well, can it at least be switched off? or should I go stick my head in > > > a bucket of ice... :) > > You just dont run vidcontol -m on, thats it .... > No, I mean, is there any way to use the mouse with a character- > resolution cursor? e.g. reverse the character it points at, or set the > background color of that character to red, instead of doing that fancy > font manipulation. the canonical way to do it in DOS mouse drivers was to xor the color with 7, i.e., leave brightness/blinking bit untouched and just invert the CGA-style color. This way, it's guaranteed to be distinct from color of text. (black on white -> white on black, yellow on red -> blue on cyan, etc.) by the way, while we are talking syscons, Soren, what ever happened to my `invert border color in cyrillic mode' and `visual bell by blinking border' patches I sent to you in, what, 1996? Should I dig them up and port to 2.2.6?? -- The danger from computers is not that they will eventually get as smart as men, but that we will meanwhile agree to meet them halfway. --Bernard Avishai To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 4 23:11:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA24998 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 23:11:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Gatekeeper.Alameda.net (root@gatekeeper.Alameda.net [207.90.181.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA24993 for ; Sat, 4 Jul 1998 23:11:28 -0700 (PDT) (envelope-from soren@soekris.dk) Received: by Gatekeeper.Alameda.net (8.9.0/8.8.6) with SMTP id XAA06281; Sat, 4 Jul 1998 23:11:28 -0700 (PDT) X-SMTP: helo soren.soekris from soren@soekris.dk server @207.90.187.212 ip 207.90.187.212 Message-ID: <359F190F.5A83@soekris.dk> Date: Sat, 04 Jul 1998 23:11:27 -0700 From: Soren Kristensen Reply-To: soren@soekris.dk Organization: Soekris Engineering X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: Joe Abley , hackers@FreeBSD.ORG Subject: Re: ethernet peculiarity References: <359ED491.7F3C@soekris.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I think I'm getting old, the mouse port is of course irq 12. But I still thinks it looks like a classic interrupt conflict. But it might be because irq 10 is assigned to the PCI slots, that's default for most PCI based computers. Go into the BIOS and make sure that the irq 10 setting is assigned to ISA instead of PCI/PnP. Soren Kristensen wrote: > > Hi Joe, > > It looks like a classic interrupt conflict, have you tried using another > irq number, irq 10 is usually used by the PS2 mouse port, even if no > mouse is connected ? > > Joe Abley wrote: > > > > Hi all, > > > > I just put FreeBSD 2.2.6-RELEASE on a Pentium 133 box, 8M RAM, Intel 82439 > > PCI chipset, Intel 82371SB PCI-ISA bridge. > > > > Everything looks normal, and yet I have had a complete inability to get > > either 3c509 or NE2000-clone ethernet cards to function. The following > > example is from the NE2000 clone, but the 3c509 symptoms were identical > > (but with the ep driver). I tried three different 3c509 cards with the > > same results. > > > > Basically, the machine appears to boot and identify the card, but I get > > repeated kernel messages of "ed0: device timeout". > > > > dmesg reveals: > > > > ed0 at 0x300-0x31f irq 10 flags 0x4 on isa > > ed0: address 00:c0:58:20:bg:16, type NE2000 (16 bit) > > > > This results from a kernel configuration of: > > > > device ed0 at isa? port 0x300 net irq 10 flags 0x04 iomem 0xd8000 vector edintr > > > > I have tried this without the flags parameter, and with a flags parameter > > of 0x02. Same result. This card is an ExpertLan INET2000, which works on > > win95 as an NE2000. The manufacturer's setup utility confirms the card is > > working, and is set for port 0x300, irq 10 (with no memory-mapped I/O). > > > > This may well be a completely inappropriate list for this (in which case > > "sorry"); however, I _was_ interested in what could cause a generic > > kernel-wide ethernet (or ISA?) failure in a machine. > > > > What is going on? > > > > Joe > > > > -- > > Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 > > Network Architect, CLEAR Net http://www.clear.net.nz/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message