From owner-freebsd-hackers Sun Jul 4 0:12:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id A51AF14D96 for ; Sun, 4 Jul 1999 00:12:50 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id BAA10805; Sun, 4 Jul 1999 01:12:42 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <377F0969.B4BF6496@softweyr.com> Date: Sun, 04 Jul 1999 01:12:41 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "G. Adam Stanislav" Cc: "Brian F. Feldman" , Janie Dykes , freebsd-hackers@FreeBSD.ORG Subject: Re: how to start to be a hacker? References: <377EA69C.6729DB43@softweyr.com> <19990704012556.A220@whizkidtech.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" wrote: > > On Sat, Jul 03, 1999 at 06:11:08PM -0600, Wes Peters wrote: > > Trust me, greenie, those of us who a FAR from 16 wish we weren't. ;^) > > What, and miss the sixties??? Get back to your handbasket! :-) Our experiences of the sixties were probably different. I spent mine as a dirt-poor "GI brat", the son of an American military man, watching my father fly to far away lands to get maimed. He was wounded in Tripoli when Qaddafi took Libya from King Idris, and later in Thailand during the Khmer Rouge reign of terror, sending young pilots to die at Thud Ridge. We just wanted him home safe. We spent 1970 at Fort Benning, Ga. We went to the commissary every Thursday, and watched the fleet of chaplains cars coming and going, doing next of kin notification. That (and the space program) are what the sixties mean to me. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 3: 6:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 0C96C14CB0 for ; Sun, 4 Jul 1999 03:06:07 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA19425; Sun, 4 Jul 1999 11:10:23 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 4 Jul 1999 11:05:14 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: hackers@freebsd.org Subject: Re: The busspace modernization initiative. In-Reply-To: <199907032124.PAA33313@harmony.village.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 Sat, 3 Jul 1999, Warner Losh wrote: > > I'm trying to update the bus-space routines to match more closely the > NetBSD routines. The new-config project has already done this, so > I've been moving their code into a relatively pure -current tree. > > I'm finding that there are many places that assume that > bus_space_handle_t is the same thing as u_int or that > bus_space_handles can be compared with !=. Some of this code I even > wrote :-(. > > These strike me as unwise assumptions. Fortunately, it appears that > there are only 4 files impacted (at least in my config, I've not tried > GENERIC yet): > ../../pci/bt_pci.c > ../../i386/i386/nexus.c > ../../i386/isa/aha_isa.c > ../../pci/es1370.c > It strikes me as unwise to make these assumptions, even if they should > generally prove to be true. > > Comments? I think you are on the right lines here. Where does the resource come from? Are you going to support bus_space_map() and if so, how are you planning to call BUS_ALLOC_RESOURCE? I assume that you will update the alpha version of bus.h too. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 3:16:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 05A5F14C0B for ; Sun, 4 Jul 1999 03:16:15 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA21547; Sun, 4 Jul 1999 11:20:22 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 4 Jul 1999 11:15:13 +0100 (BST) From: Doug Rabson To: Jonathan Lemon Cc: hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au Subject: Re: poll() scalability In-Reply-To: <19990704000042.59954@right.PCS> 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, 4 Jul 1999, Jonathan Lemon wrote: > > This is an earlier posting that I attempted to make, perhaps > it can provide a starting point for discussion. While this > is already implemented, I'm not adverse to tossing it all for > something better. > -- > Jonathan > > > ----- Forwarded message from owner-freebsd-arch@FreeBSD.ORG ----- > > Date: Mon, 5 Apr 1999 17:42:02 -0500 > From: Jonathan Lemon > To: freebsd-arch@freebsd.org > > I'd like to open discussion on adding a new interface to FreeBSD, > specifically, a variant of poll(). > > The problem is that poll() (and select(), as well) do not scale > well as the number of open file descriptors increases. When there > are a large number of descriptors under consideration, poll() takes > an inordinate amount of time. For the purposes of my particular > application, "large" translates into roughly 40K descriptors. > > As having to walk this descriptor list (and pass it between user and > kernel space) is unpalatable, I would like to have the interface > simply take a "change" list instead. The kernel would keep the > state of the descriptors being examined, and would in turn, return > a short list of descriptors that actually had any activity. > > In essence, I want to move the large "struct pollfd" array that I > have into the kernel, and then instruct the kernel to add/remove > entries from this array, and only return the array subset which > has activity. How does the kernel manage this? Does each process potentially store a struct pollfd in struct proc? This seems a bit limiting since it forces a program to have exactly one call to poll. Peter's description of David Filo's event queue thing seems to solve that problem by introducing a new kernel object (the event queue). > > A possible (actually, my current) implementation looks like this: > > struct fd_change { > short fd; > short events; > }; Limited to 32767 file descriptors. Trivial to change though. Do you remove a fd from the list by setting events to 0? > > int > new_poll( > int nchanges; // entries in new changelist > struct fd_change *changelist; // changes to be made > int n_events; // max size of output list > struct fd_change *event; // returned list of events > int timeout; // timeout (same as poll) > ) > > Where the returned value is either an error, or the number of events > stored in the returned changelist. > > Some pseudo-code that would exercise the interface: > > struct fd_change fc[ MAXCHANGE ]; > > fc[0].fd = 20; > fc[0].events = ADD | READ ; // add, mark read "interest" > > fc[1].fd = -1; // ignore this one > > fc[2].fd = 32; > fc[2].events = DELETE ; // delete previous fd > > fc[3].fd = 46; > fc[3].events = WRITE ; // ask for writable events > > n_changes = new_poll(4, fc, MAXCHANGE, fc, -1); > > > Comments? Note that I haven't discussed the implementation details; > the implementation is done, and can probably be altered/improved, > but I would like to solicit feedback on the feasability of the interface. As I said before I'm uneasy about the kernel tracking the state (list of fds) in the process. A separate kernel object would be a much cleaner solution and would be usable by a program which called poll in many different ways. With this api, a library would be unable to use the new interface since it would not know the new_poll state setup by the main program and would not be able to change it without potentially breaking the caller's state. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 4:36:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 51C1714BF4 for ; Sun, 4 Jul 1999 04:36:15 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id NAA82312; Sun, 4 Jul 1999 13:36:07 +0200 (CEST) (envelope-from des) To: Tim Vanderhoek Cc: Janie Dykes , Wes Peters , "G. Adam Stanislav" , Bill Fumerola , haodongpan@netease.com, freebsd-hackers@FreeBSD.ORG Subject: Re: how to start to be a hacker? References: <377DB95C.448E4227@softweyr.com> <19990703113140.B220@whizkidtech.net> <377E4C45.522F3E78@softweyr.com> <377E71F6.8877ED47@pangeatech.com> <19990703194700.A44583@mad> From: Dag-Erling Smorgrav Date: 04 Jul 1999 13:36:06 +0200 In-Reply-To: Tim Vanderhoek's message of "Sat, 3 Jul 1999 19:47:00 -0400" Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Not to let this become a passage of right or anything. ITYM "rite of passage". HTH, HAND! DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 5:10: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BC50414C87 for ; Sun, 4 Jul 1999 05:09:57 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA83072; Sun, 4 Jul 1999 14:09:48 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) References: From: Dag-Erling Smorgrav Date: 04 Jul 1999 14:09:47 +0200 In-Reply-To: Jamie Howard's message of "Sat, 3 Jul 1999 15:18:07 -0400 (EDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C, > -num, and -Z. These are not required by the Single Unix Specification or > POSIX and I felt they would bloat my code too significantly. I find those quite useful, and I don't see how they'd bloat your code a lot. You need a line @queue and a $toprint counter, as well as $lead and $trail counters. $regexp is the expression to search for, and $line is a scratch variable. Initialize by setting $lead to the -A argument, $trail to the -B argument; if you encounter -C, set $lead and $trail to 2; if you encounter -, set $lead and $trail to . Now for the search algorithm in Perl: $toprint = 0; @queue = qw(); while ($line = ) { if ($toprint) { print $line; --$toprint; } else { shift @queue if (@queue > $lead); push @queue, $line; } next unless ($line ~ m/$regexp/o); while (@queue) { print shift @queue; } $toprint = $trail; } This should be trivial to translate to C. The only non-trivial part of implementing this stuff is that you have to trick getopt() to make - work. You'll have to put a : at the start of your getopt() string and examine every argument getopt() complains about. Hope this helps... keep up the good work! DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 5:13:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 962D914C87 for ; Sun, 4 Jul 1999 05:13:22 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA83157; Sun, 4 Jul 1999 14:13:14 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) References: From: Dag-Erling Smorgrav Date: 04 Jul 1999 14:13:13 +0200 In-Reply-To: Jamie Howard's message of "Sat, 3 Jul 1999 15:18:07 -0400 (EDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > All of the code is original except for binary.c. It is used with the -a > option to prevent searching binary files. binary.c is extricated from > less-332's binary checking code. I was just that lazy. Less's binary checking code is a tad too strict. It complains about files with my name at the top (e.g. /usr/include/fetch.h in FreeBSD 3.x and 4.x) in non-ISO8859 locales. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 5:38:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id B6E6114EB9 for ; Sun, 4 Jul 1999 05:38:24 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18327.on.bellglobal.com [206.172.130.7]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA13421; Sun, 4 Jul 1999 08:41:24 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id IAA48639; Sun, 4 Jul 1999 08:38:34 -0400 (EDT) (envelope-from tim) Date: Sun, 4 Jul 1999 08:38:34 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) Message-ID: <19990704083834.B48190@mad> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Dag-Erling Smorgrav on Sun, Jul 04, 1999 at 02:09:47PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 04, 1999 at 02:09:47PM +0200, Dag-Erling Smorgrav wrote: > > This should be trivial to translate to C. The only non-trivial part of > implementing this stuff is that you have to trick getopt() to make > - work. You'll have to put a : at the start of your getopt() > string and examine every argument getopt() complains about. Actually, the (FreeBSD) getopt(3) manpage includes at its end an example showing how to handle - options. This is preceeded by bold letters: "backwards compatibility only". HTH. HAND. :) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 6:53: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 094F914C36 for ; Sun, 4 Jul 1999 06:53:01 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id IAA29060; Sun, 4 Jul 1999 08:52:50 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id IAA09801; Sun, 4 Jul 1999 08:52:49 -0500 Message-ID: <19990704085249.54969@right.PCS> Date: Sun, 4 Jul 1999 08:52:49 -0500 From: Jonathan Lemon To: Doug Rabson Cc: hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au Subject: Re: poll() scalability References: <19990704000042.59954@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Doug Rabson on Jul 07, 1999 at 11:15:13AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote: > > In essence, I want to move the large "struct pollfd" array that I > > have into the kernel, and then instruct the kernel to add/remove > > entries from this array, and only return the array subset which > > has activity. > > How does the kernel manage this? Does each process potentially store a > struct pollfd in struct proc? This seems a bit limiting since it forces a > program to have exactly one call to poll. Right now, the selection list is hung off of struct filedesc, since that seemed a good place as any to put it. I'm not sure what you mean by a 'single call' to poll; there can be multiple calls. The caller can also call poll() or select() on a descriptor as well. > Peter's description of David Filo's event queue thing seems to solve that > problem by introducing a new kernel object (the event queue). Yes, it does seem more interesting, but I'd like to see more details. If multiple processes are sharing the queue, then the queue registry would have to be done at the struct file level, with something converting the struct file pointer back into an fd, yes? > > struct fd_change { > > short fd; > > short events; > > }; > > Limited to 32767 file descriptors. Trivial to change though. Do you remove > a fd from the list by setting events to 0? Actually, by setting events to "DELETE"; then the descriptor is removed from the kernel's internal list. > As I said before I'm uneasy about the kernel tracking the state (list of > fds) in the process. A separate kernel object would be a much cleaner > solution and would be usable by a program which called poll in many > different ways. > > With this api, a library would be unable to use the new interface since it > would not know the new_poll state setup by the main program and would not > be able to change it without potentially breaking the caller's state. I'm not sure how a library would fit in. The main program will have to keep some state, which wouldn't be available to the library either. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 7:10:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 38C2214C36 for ; Sun, 4 Jul 1999 07:10:28 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id PAA62671; Sun, 4 Jul 1999 15:14:39 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 4 Jul 1999 15:09:27 +0100 (BST) From: Doug Rabson To: Jonathan Lemon Cc: hackers@freebsd.org, grog@freebie.lemis.com, peter@netplex.com.au Subject: Re: poll() scalability In-Reply-To: <19990704085249.54969@right.PCS> 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, 4 Jul 1999, Jonathan Lemon wrote: > On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote: > > > In essence, I want to move the large "struct pollfd" array that I > > > have into the kernel, and then instruct the kernel to add/remove > > > entries from this array, and only return the array subset which > > > has activity. > > > > How does the kernel manage this? Does each process potentially store a > > struct pollfd in struct proc? This seems a bit limiting since it forces a > > program to have exactly one call to poll. > > Right now, the selection list is hung off of struct filedesc, since that > seemed a good place as any to put it. I'm not sure what you mean by > a 'single call' to poll; there can be multiple calls. The caller can > also call poll() or select() on a descriptor as well. What I mean is that since there is only set of new_poll information per filedesc (mostly the same as per-process), you can only have one piece of code in a program which calls new_poll. Imagine a routine in libc (or whatever) which could usefully use new_poll in its implication. To be able to work correctly when called form a program which is calling new_poll itself, the library routine would need to somehow read out the list of events the caller was using, replace it with its own list and then restore the caller's list later which defeats the object. I'm not arguing against the idea of new_poll but I just think it should scale to large and complex programs as well as large numbers of fds. > > > > Peter's description of David Filo's event queue thing seems to solve that > > problem by introducing a new kernel object (the event queue). > > Yes, it does seem more interesting, but I'd like to see more details. > If multiple processes are sharing the queue, then the queue registry > would have to be done at the struct file level, with something converting > the struct file pointer back into an fd, yes? I would like to see more details too. It sounds as if the implementation is at the struct file level. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 7:33:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CEB214CAE for ; Sun, 4 Jul 1999 07:33:52 -0700 (PDT) (envelope-from wjw@iae.nl) Received: by surf.iae.nl (Postfix, from userid 74) id 01DF99E52; Sun, 4 Jul 1999 16:33:51 +0200 (MET DST) To: grog@lemis.com Subject: Re: Pictures from USENIX X-Newsgroups: list.freebsd.hackers In-Reply-To: <19990704112426.J709@freebie.lemis.com> References: Organization: Internet Access Eindhoven Cc: hackers@freebsd.org Message-Id: <19990704143351.01DF99E52@surf.iae.nl> Date: Sun, 4 Jul 1999 16:33:51 +0200 (MET DST) From: wjw@iae.nl (Willem Jan Withagen) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19990704112426.J709@freebie.lemis.com> you write: >On Saturday, 3 July 1999 at 17:28:51 -0700, John Polstra wrote: >> I put a handful of pictures from this year's USENIX conference at >> . > >Hey, they're some of the best I've seen of USENIX. Proves my statement that it is unwise to assume the looks of people from their E-mail. :-) All of the pictures supprised me very mucho. --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 9.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 Sun Jul 4 7:41:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 86A701514F for ; Sun, 4 Jul 1999 07:41:10 -0700 (PDT) (envelope-from wjw@iae.nl) Received: by surf.iae.nl (Postfix, from userid 74) id EE0A79E52; Sun, 4 Jul 1999 16:41:09 +0200 (MET DST) To: bright@rush.net Subject: Re: devices in sysctl MIB? X-Newsgroups: list.freebsd.hackers In-Reply-To: Organization: Internet Access Eindhoven Cc: hackers@freebsd.org Message-Id: <19990704144109.EE0A79E52@surf.iae.nl> Date: Sun, 4 Jul 1999 16:41:09 +0200 (MET DST) From: wjw@iae.nl (Willem Jan Withagen) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Something like below? That is what you get available when running ucd-snmp. So I guess that a lot of the data is already available. Just not in sysctl (yet) -_WjW interfaces.ifNumber.0 = 6 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifDescr.1 = "de0" Hex: 64 65 30 interfaces.ifTable.ifEntry.ifDescr.2 = "tun0" Hex: 74 75 6E 30 interfaces.ifTable.ifEntry.ifDescr.3 = "tun1" Hex: 74 75 6E 31 interfaces.ifTable.ifEntry.ifDescr.4 = "ppp0" Hex: 70 70 70 30 interfaces.ifTable.ifEntry.ifDescr.5 = "ppp1" Hex: 70 70 70 31 interfaces.ifTable.ifEntry.ifDescr.6 = "lo0" Hex: 6C 6F 30 interfaces.ifTable.ifEntry.ifType.1 = ethernet-csmacd(6) interfaces.ifTable.ifEntry.ifType.2 = 0 interfaces.ifTable.ifEntry.ifType.3 = 0 interfaces.ifTable.ifEntry.ifType.4 = ppp(23) interfaces.ifTable.ifEntry.ifType.5 = ppp(23) interfaces.ifTable.ifEntry.ifType.6 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifMtu.1 = 1500 interfaces.ifTable.ifEntry.ifMtu.2 = 1500 interfaces.ifTable.ifEntry.ifMtu.3 = 1500 interfaces.ifTable.ifEntry.ifMtu.4 = 1500 interfaces.ifTable.ifEntry.ifMtu.5 = 1500 interfaces.ifTable.ifEntry.ifMtu.6 = 16384 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 10000000 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 0 interfaces.ifTable.ifEntry.ifPhysAddress.1 = Hex: 00 80 48 EA 6C 8B interfaces.ifTable.ifEntry.ifPhysAddress.2 = "" interfaces.ifTable.ifEntry.ifPhysAddress.3 = "" interfaces.ifTable.ifEntry.ifPhysAddress.4 = "" interfaces.ifTable.ifEntry.ifPhysAddress.5 = "" interfaces.ifTable.ifEntry.ifPhysAddress.6 = "" interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.2 = down(2) In article you write: > >Just a suggestion, perhaps there should be a dev tree in >sysctl with nodes for each device type then device. > >interesting applications for this: > >reporting on packets dropped/sent and such >displaying connection status (duplex/100mb/10mb... etc) >enabling/disabling power saving features > >dev.iface.fxp0.ipkts = 432523 >dev.iface.fxp0.opkts = 432523 >dev.iface.fxp0.linkspeed = 100 >dev.iface.fxp0.linkmode = full-duplex >dev.dsk.da0.tags = 32 >.... > >sysctl -w dev.iface.fxp0.linkmode=half-duplex > >? > >-Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] >systems administrator and programmer > Win Telecom - http://www.wintelcom.net/ > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message -- 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 9.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 Sun Jul 4 7:54:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 0B1A514D22 for ; Sun, 4 Jul 1999 07:54:41 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id KAA29269; Sun, 4 Jul 1999 10:54:15 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA12640; Sun, 4 Jul 1999 10:53:45 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id KAA03044; Sun, 4 Jul 1999 10:53:39 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907041453.KAA03044@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <19990703142624.ED06C64@overcee.netplex.com.au> from Peter Wemm at "Jul 3, 1999 10:26:24 pm" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 4 Jul 1999 10:53:39 -0400 (EDT) Cc: rivers@dignus.com (Thomas David Rivers), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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've got some prototype code in place which supports the context switching part of this. It's pretty simple right now, as I'm trying to keep changes to a minimum. What I've done is simply added the dr0-dr3,dr6,dr7 registers to 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu_switch(), during a save operation, I load %dr7, and check the lower 8 bits, which indicate if any breakpoints are in use. If they are, I save all the debug registers, then clear out %dr7, which disables the breakpoints. During a restore operation, I load the value of %dr7 from the pcb structure of the new process, and if any of the lower 8 bits are set, I restore all the debug registers. This is not as efficent as it could be implemented with a separate flag to indicate whether saving the debug registers is necessary since loading/storing the debug registers is fairly expensive (11 clocks on an i486). This kernel is running right now and has not appeared to have suffered any ill-affects :) Now I'm asking for guidance for the cleanest way to hook into the rest of the kernel. Should 'struct reg' be extended to directly include the debug registers or should we go the route of having another data structure for the debug registers, not unlike how the floating point registers are handled? Extending 'struct reg' would be simplest in that I would merely need to modify the existing routines such as 'set_regs()' and 'fill_regs()' to set/save the additional registers. Also, doing it this way would minimize the changes required to 'ptrace()' in order to support setting and retrieving the new registers. However, I am unsure how existing code bases would be affected by such a change, i.e., we'd probably be breaking binary compatibility. Otherwise, I think I will need to set up a 'struct dbregs', provide the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. Comments? Either way, I think the changes to gdb would be minimal. It already supports hardware debug support. We'd just need to hook in our facility for setting/getting the hardware watchpoints at the apropriate place(s). Thanks, -Brian -- Brian Dean SAS Institute Inc brdean@unx.sas.com > To: Thomas David Rivers > Cc: brdean@unx.sas.com, freebsd-hackers@FreeBSD.ORG > Subject: Re: support for i386 hardware debug watch points > Date: Sat, 03 Jul 1999 22:26:24 +0800 > From: Peter Wemm > > > Is there any interest in supporting something like this in FreeBSD? > > > I'm volunteering to spend some cycles on this, but I don't want to go > > > to the effort if there's little chance that the work would be > > > integrated. > > > > > > Thanks, > > > -Brian > > > -- > > > Brian Dean SAS Institute Inc brdean@unx.sas.com > > > > Brian - > > > > Scan through the mail archives - I brought this up about this > > time last year, I think... > > > > There were several responses - some people may be willing to > > assist... > > I'll chime in.. I'd be quite willing to bring something like this in, > assuming it was done reasonably cleanly. It shouldn't be too hard to do it > without imparing portability across cpu/arch types. > > I think this would be quite useful, especially if gdb could be made aware > of it too. > > > - Dave Rivers - > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 8:51:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rt2.synx.com (gw0.boostworks.com [194.167.81.213]) by hub.freebsd.org (Postfix) with ESMTP id D86A514C36 for ; Sun, 4 Jul 1999 08:51:20 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id RAA05530; Sun, 4 Jul 1999 17:51:07 +0200 (CEST) Message-Id: <199907041551.RAA05530@rt2.synx.com> Date: Sun, 4 Jul 1999 17:51:04 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: poll() scalability To: dfr@nlsystems.com Cc: hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 4 Jul, Doug Rabson wrote: > On Sun, 4 Jul 1999, Jonathan Lemon wrote: > >> On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote: >> > > In essence, I want to move the large "struct pollfd" array that I >> > > have into the kernel, and then instruct the kernel to add/remove >> > > entries from this array, and only return the array subset which >> > > has activity. >> > >> > How does the kernel manage this? Does each process potentially store a >> > struct pollfd in struct proc? This seems a bit limiting since it forces a >> > program to have exactly one call to poll. >> >> Right now, the selection list is hung off of struct filedesc, since that >> seemed a good place as any to put it. I'm not sure what you mean by >> a 'single call' to poll; there can be multiple calls. The caller can >> also call poll() or select() on a descriptor as well. > > What I mean is that since there is only set of new_poll information per > filedesc (mostly the same as per-process), you can only have one piece of > code in a program which calls new_poll. > > Imagine a routine in libc (or whatever) which could usefully use new_poll > in its implication. To be able to work correctly when called form a > program which is calling new_poll itself, the library routine would need > to somehow read out the list of events the caller was using, replace it > with its own list and then restore the caller's list later which defeats > the object. > > I'm not arguing against the idea of new_poll but I just think it should > scale to large and complex programs as well as large numbers of fds. > IMHO, having only one poll central point is quiet common. From my POV, based on my needs, the calls I would like to see are : - old_flags = poll_conditions(fd, READ|WRITE) ; - poll_reset() ; - fd = poll_next(&fd, &condition_returned, &timeout) - len = poll_read(&fd, &buffer, len, &timeout); - len = poll_write(fd, &buffer, len); with the behaviors: - closing an fd cancels participation in the poll round. - fork() and vfork() keeps the polls flags. in this case, poll_reset() allows for resetting all poll flags() on any fd. - rfork() allows for sharing flags (and rounding) between processes. - poll_next() will give the next fd next to the one previously returned (or the next to the one based on its input value, using NULLs as "don't care") restarting at lower flagged fd when last one reached. - poll_read() being equivalent to {poll_next() ; read()}. - poll_write() being able to automatically have WRITE polling flags turned on if write fails, and off if it succeeds. I agree that the last poll_write() stuff is questionable and is just there for regularity. I also recognize that introduces new calls that can be implemented using standard ones is also questionable. Anyway, my main use would be the poll_read() stuff. Implementation would be easy in the filedesc, using : char *fd_pollflags : same usage as fd_ofileflags u_short fd_firstpolled ; lowest polled fd u_short fd_lastpolled ; highest polled fd u_short fd_currentpolled ; current polled fd (to base next one) also, fd_ofileflags could be extended to store the polling flags instead of creating a new table. RN. IhM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 8:55:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id B859514C36 for ; Sun, 4 Jul 1999 08:55:44 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id KAA29302 for ; Sun, 4 Jul 1999 10:55:43 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id KAA15687 for ; Sun, 4 Jul 1999 10:55:42 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id KAA22371; Sun, 4 Jul 1999 10:55:41 -0500 (CDT) Date: Sun, 4 Jul 1999 10:55:41 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907041555.KAA22371@free.pcs> To: hackers@freebsd.org Subject: Re: support for i386 hardware debug watch points X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article yo u write: >This is not as efficent as it could be implemented with a separate >flag to indicate whether saving the debug registers is necessary since >loading/storing the debug registers is fairly expensive (11 clocks on >an i486). Yes; you may want to just use another bit in pcb_flags that indicates if the debug registers are in use. >Should 'struct reg' be extended to directly include the debug >registers or should we go the route of having another data structure >for the debug registers, not unlike how the floating point registers >are handled? I'd be inclined to create another data structure, unless the debug registers are architecturally defined to be identical on all x86 chips. >Otherwise, I think I will need to set up a 'struct dbregs', provide >the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a >PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. Either that, or create a routine like i386_set_breakpoint() in sys_machdep that would handle setting breakpoints for different types of cpu architectures. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 9:16:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id BCF1314C09 for ; Sun, 4 Jul 1999 09:16:44 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id MAA17326; Sun, 4 Jul 1999 12:15:54 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Sun, 4 Jul 1999 12:15:54 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: Peter Wemm Cc: "Brian F. Feldman" , Jonathan Lemon , wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() In-Reply-To: <19990704040435.35CD464@overcee.netplex.com.au> 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, 4 Jul 1999, Peter Wemm wrote: > Now what I particular like is the event queue system that David Filo put > together for Yahoo. In a nutshell you create a queue (a fd), and then > register the descriptors you want to monitor with the queue. You then run > an accept()-like loop where the accept returns the fd number that has met > the conditions you asked for. For example, if you wanted to know if fd > number 4251 becomes readable, then the accept would return 4251. This has > potential to work across multiple processes sharing a queue so that events > could get round robined or whatever. The other good part is that it > maintains the state and lists persistantly and doesn't have to keep copying > it to/from the kernel. It handles 50,000 to 100,000 connections without > too much trouble. You can still use this with select as the queue fd > becomes readable when there is an event waiting for your process. > > Is there interest in doing something like this in general? yes, its been done, and its called posix real time signal queues :) check out http://www.redhat.com/~zab/phhttpd it basically registers sigio on the fds it cares about, but the signal it registers is a real time signal ( > 32) so the kernel queues them in a fifo rather than usually delivering them. for each signal in the queue there is an attached siginfo struct that has things like which fd the event is for, which POLL_ event caused the signal, etc. phhttpd is a quick silly static web server that masks the signal and has threads spinning on sigwaitinfo() popping events off the queue. phhtpd isn't going anywhere, but it's event model is planned to go into apache's mpm architecture once dean has it solid, and I'm debating writing up a super-mega network server based around it.. If anyone's near ottawa in late july, head over to ols and we'll chat about this stuff over drinks ;) -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 9:21: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id 7672A14C46 for ; Sun, 4 Jul 1999 09:21:05 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id MAA17342 for ; Sun, 4 Jul 1999 12:20:59 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Sun, 4 Jul 1999 12:20:59 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: hackers@FreeBSD.ORG Subject: Re: poll() vs select() 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 > But poll() copies in HUGE amounts of data compared to the few bytes for > thousands of FDs that select does. but the size of the select() mask is dependant on the highest numbered fd that we care about, rather than the number of fds we actually care about. this becomes highly uncool in a mondo threaded server that shares fd space :) -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 9:46:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by hub.freebsd.org (Postfix) with ESMTP id 95D9D14CDF for ; Sun, 4 Jul 1999 09:46:53 -0700 (PDT) (envelope-from Marc.Espie@liafa.jussieu.fr) Received: from mail.liafa.jussieu.fr (liafa1.liafa.jussieu.fr [132.227.81.128]) by isis.lip6.fr (8.8.8/jtpda-5.2.9.1+lip6) with ESMTP id SAA08797 ; Sun, 4 Jul 1999 18:46:47 +0200 (MET DST) Received: from (espie@localhost) by mail.liafa.jussieu.fr (8.8.6/jtpda-5.2) id SAA09466 ; Sun, 4 Jul 1999 18:46:46 +0200 (MET DST) Date: Sun, 4 Jul 1999 18:46:46 +0200 From: Marc Espie To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) Message-ID: <19990704184646.D9548@liafa1.liafa.jussieu.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Dag-Erling Smorgrav on Sun, Jul 04, 1999 at 02:13:13PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 04, 1999 at 02:13:13PM +0200, Dag-Erling Smorgrav wrote: > Jamie Howard writes: > > All of the code is original except for binary.c. It is used with the -a > > option to prevent searching binary files. binary.c is extricated from > > less-332's binary checking code. I was just that lazy. > > Less's binary checking code is a tad too strict. It complains about > files with my name at the top (e.g. /usr/include/fetch.h in FreeBSD > 3.x and 4.x) in non-ISO8859 locales. I have half a port of jless in my files (less + code to let it handle exotic charsets) which I might finally get the time to finish at some points. No, this beastie does not only handle japanese charsets, but since they're probably the weirdest charsets available, everything else turns out to be considerably simpler. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 10:24: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mu.egroups.com (mu.egroups.com [207.138.41.151]) by hub.freebsd.org (Postfix) with SMTP id 0959E14E6F for ; Sun, 4 Jul 1999 10:24:00 -0700 (PDT) (envelope-from sams@virtualtek.com) Received: from [10.1.2.15] by mu.egroups.com with NNFMP; 04 Jul 1999 18:24:00 -0000 Date: Sun, 04 Jul 1999 10:23:55 -0700 From: sams@virtualtek.com To: freebsd-hackers@freebsd.org Subject: freebsd web based groupware Message-ID: <7lo5bb$d0l9@eGroups.com> User-Agent: eGroups-EW/0.73 Content-Length: 352 X-Mailer: www.eGroups.com Message Poster Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, We're looking for sites who may want to integrate customizable web based groupware (email, message board, calendar and address book)onto their sites. Joydesk 2.1 runs on NT, Linux and FreeBSD. When you have an opportunity, please visit http://joydesk.com, open free account and play with the features. Let me know what you think. Cheers, Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 10:45: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2768414DC8 for ; Sun, 4 Jul 1999 10:45:05 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA21707; Sun, 4 Jul 1999 19:30:32 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA02529; Sun, 4 Jul 1999 19:06:48 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907041706.TAA02529@yedi.iaf.nl> Subject: Re: Pictures from USENIX In-Reply-To: <19990704143351.01DF99E52@surf.iae.nl> from Willem Jan Withagen at "Jul 4, 1999 4:33:51 pm" To: wjw@iae.nl (Willem Jan Withagen) Date: Sun, 4 Jul 1999 19:06:48 +0200 (CEST) Cc: grog@lemis.com, hackers@FreeBSD.ORG 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+ 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 As Willem Jan Withagen wrote ... > In article <19990704112426.J709@freebie.lemis.com> you write: > >On Saturday, 3 July 1999 at 17:28:51 -0700, John Polstra wrote: > >> I put a handful of pictures from this year's USENIX conference at > >> . > > > >Hey, they're some of the best I've seen of USENIX. > > Proves my statement that it is unwise to assume the looks of people > from their E-mail. :-) Which makes a good case for a permanent picture gallery @ www.freebsd.org I guess. I can donate a bunch of pictures taken at last year's hackersparty here in the Netherlands. -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl 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 Jul 4 11: 1: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by hub.freebsd.org (Postfix) with ESMTP id A23821511B for ; Sun, 4 Jul 1999 11:00:58 -0700 (PDT) (envelope-from cmsedore@mailbox.syr.edu) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.A687A670@mailer.syr.edu>; 4 Jul 1999 14:01:02 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id OAA29286; Sun, 4 Jul 1999 14:00:56 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Sun, 4 Jul 1999 14:00:56 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: Peter Wemm Cc: "Brian F. Feldman" , Jonathan Lemon , wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() In-Reply-To: <19990704040435.35CD464@overcee.netplex.com.au> 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, 4 Jul 1999, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 2 Jul 1999, Jonathan Lemon wrote: > > > > > In article 0000@crb.crb-web.com> you write: > > > >now supports the select() and poll() system calls. My question is really > one > > > >of usage. Why would one us poll() over select()? Is select eventually go > ing > > > >to go away for some reason? > > > > > > select() as a user-level call will never go away; there is a large base > > > of code that uses it. > > > > > > poll() is faster (it doesn't have to do bit twiddling), and it's interface > > > is cleaner (it can report invalid fd's, something select() can't do). As > > > its functionality is a superset of select()'s, it is used as the internal > > > implementation for select(). > > > > Actually, select() doesn't require horrendous amounts of copyin()s, which > > poll() does. So have you benchmarked the two? I'd expect select to be faster. > > Actually.. select() has three copyins and three copyouts per call. poll() > has one copyin and one copyout per call. > > Now what I particular like is the event queue system that David Filo put > together for Yahoo. In a nutshell you create a queue (a fd), and then > register the descriptors you want to monitor with the queue. You then run > an accept()-like loop where the accept returns the fd number that has met > the conditions you asked for. For example, if you wanted to know if fd > number 4251 becomes readable, then the accept would return 4251. This has > potential to work across multiple processes sharing a queue so that events > could get round robined or whatever. The other good part is that it > maintains the state and lists persistantly and doesn't have to keep copying > it to/from the kernel. It handles 50,000 to 100,000 connections without > too much trouble. You can still use this with select as the queue fd > becomes readable when there is an event waiting for your process. > > Is there interest in doing something like this in general? You can do much the same thing by using aio functions. I do this now with an added syscall aio_waitcomplete, which allows a process to sleep waiting for the next aio operation to finish. If more work was done on the aio routines to improve their performance (the existing ones are better than select() when you exceed about 40 descriptors), they would be faster than poll or select, and could function in a similar fashion to the event queue scheme above. I've only had about 140 or so connections open in my experiments, but aio has no trouble with these, to the point where my switched 100Mb line is the bottleneck. I experiment more with NNTP than HTTP, though I have toyed with the idea of hacking an existing web server to use aio. I like the event queue idea, but I'd like it for aio completions rather than an enhanced select() function. All IMHO, -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 11:57: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id A84A0150F8 for ; Sun, 4 Jul 1999 11:56:56 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA084699378; Sun, 4 Jul 1999 10:42:58 -0400 Date: Sun, 4 Jul 1999 10:42:58 -0400 (EDT) From: Bill Fumerola To: Wilko Bulte Cc: Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <199907041706.TAA02529@yedi.iaf.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 On Sun, 4 Jul 1999, Wilko Bulte wrote: > Which makes a good case for a permanent picture gallery @ www.freebsd.org > I guess. I can donate a bunch of pictures taken at last year's > hackersparty here in the Netherlands. When FreeBSDcon comes closer, I'll probably be be asking which of the developers are coming to it. I'm going to try to get some large group photos etc etc. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Jul 4 12:16:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 81E0B14EA2 for ; Sun, 4 Jul 1999 12:16:23 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA50576; Sun, 4 Jul 1999 12:15:03 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Bill Fumerola Cc: Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-reply-to: Your message of "Sun, 04 Jul 1999 10:42:58 EDT." Date: Sun, 04 Jul 1999 12:15:02 -0700 Message-ID: <50572.931115702@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm going to have a "core team page" worked on which has pictures and brief bios, perhaps something by next week. Such things may seem frivolous, but I it helps people relate a little more directly to the core team if they can see what they look like and read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) - Jordan > On Sun, 4 Jul 1999, Wilko Bulte wrote: > > > Which makes a good case for a permanent picture gallery @ www.freebsd.org > > I guess. I can donate a bunch of pictures taken at last year's > > hackersparty here in the Netherlands. > > When FreeBSDcon comes closer, I'll probably be be asking which of the > developers are coming to it. I'm going to try to get some large group > photos etc etc. > > > - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Sun Jul 4 13: 5:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1DE5014E18 for ; Sun, 4 Jul 1999 13:05:29 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA16184; Sun, 4 Jul 1999 14:05:28 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA43735; Sun, 4 Jul 1999 14:03:29 -0600 (MDT) Message-Id: <199907042003.OAA43735@harmony.village.org> To: Doug Rabson Subject: Re: The busspace modernization initiative. Cc: hackers@freebsd.org In-reply-to: Your message of "Sun, 04 Jul 1999 11:05:14 BST." References: Date: Sun, 04 Jul 1999 14:03:29 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : I think you are on the right lines here. Where does the resource come : from? Are you going to support bus_space_map() and if so, how are you : planning to call BUS_ALLOC_RESOURCE? In i386/i386/resource.c :-). Here's what is there now. It looks like it currently bypasses BUS_ALLOC_RESOURCE, going to the resource manager (rman) directly. Do you have any comments on this code? Or would you rather I send you a complete patch/diff to comment on? int bus_space_alloc(t, rstart, rend, size, alignment, boundary, flags, bpap, bshp) bus_space_tag_t t; bus_addr_t rstart, rend; bus_size_t size, alignment, boundary; int flags; bus_addr_t *bpap; bus_space_handle_t *bshp; { struct resource *rv; struct rman *ex; unsigned long bpa; int error; /* * Pick the appropriate resource. */ if (t == I386_BUS_SPACE_IO) { if (flags & BUS_SPACE_MAP_LINEAR) return EOPNOTSUPP; ex = &ioport_rman; } else if (t == I386_BUS_SPACE_MEM) ex = &iomem_rman; else panic("bus_space_alloc: bad bus space tag"); /* * Sanity check the allocation against the resource's boundaries. */ if (rstart < ex->rm_start || rend > ex->rm_end) panic("bus_space_alloc: bad region start/end"); /* * Do the requested allocation. */ retry: /* printf("bus_space_alloc %lx,%lx,%lx,%lx\n", (u_long)rstart, (u_long)rend, (u_long)size, (u_long)alignment); */ rv = rman_reserve_resource(ex, rstart, rend, size, flags, NULL); /* XXX NULL? */ if (!rv) { return EAGAIN; } if ( rv->r_start != EXTENT_ALIGN (rv->r_start, alignment, 0) ) { rstart = EXTENT_ALIGN (rv->r_start, alignment, 0); rman_release_resource (rv); goto retry; } bpa = rv->r_start; rman_activate_resource (rv); /* * For I/O space, that's all she wrote. */ if (t == I386_BUS_SPACE_IO) { bshp->addr = *bpap = bpa; bshp->resource = rv; return 0; } /* * For memory space, map the bus physical address to * a kernel virtual address. */ if (bpa >= ISA_HOLE_START && (bpa + size) <= ISA_HOLE_START + ISA_HOLE_LENGTH) { /* ISA hole */ bshp->addr = (u_int)ISA_HOLE_VADDR(bpa); } else { /* General */ if((error = i386_mem_alloc_and_map (bpa, size, (vm_offset_t*)(&bshp->addr)))) { rman_release_resource (rv); return 1; } } *bpap = bpa; bshp->resource = rv; return 0; } : I assume that you will update the alpha version of bus.h too. Of course. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 13:41: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles538.castles.com [208.214.165.102]) by hub.freebsd.org (Postfix) with ESMTP id 270A414CAE for ; Sun, 4 Jul 1999 13:40:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id NAA07661; Sun, 4 Jul 1999 13:37:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907042037.NAA07661@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jonathan Lemon Cc: hackers@freebsd.org, zach@zabbo.net Subject: Re: poll() scalability In-reply-to: Your message of "Sun, 04 Jul 1999 00:00:42 CDT." <19990704000042.59954@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jul 1999 13:37:13 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to open discussion on adding a new interface to FreeBSD, > specifically, a variant of poll(). > > The problem is that poll() (and select(), as well) do not scale > well as the number of open file descriptors increases. When there > are a large number of descriptors under consideration, poll() takes > an inordinate amount of time. For the purposes of my particular > application, "large" translates into roughly 40K descriptors. > > As having to walk this descriptor list (and pass it between user and > kernel space) is unpalatable, I would like to have the interface > simply take a "change" list instead. The kernel would keep the > state of the descriptors being examined, and would in turn, return > a short list of descriptors that actually had any activity. Zach Brown (copied) had some interesting ideas about this sort of thing that he was very happy to espose while we were wandering around ZD a few weeks back. I'm rather enamoured of anything that effectively works like a callback mechanism (eg. signal delivery on an alternate stack) as it scales far better to a threaded application. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ 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 Jul 4 14: 1:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id DCDE714D00 for ; Sun, 4 Jul 1999 14:01:19 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA14496; Sun, 4 Jul 1999 14:01:11 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <377FCB96.995920EA@gorean.org> Date: Sun, 04 Jul 1999 14:01:10 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gustavo V G C Rios Cc: hackers@freebsd.org Subject: Re: login problem: References: <377EC869.D742F80@tdnet.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For future reference, questions of this sort should be directed to freebsd-questions, not freebsd-hackers. Gustavo V G C Rios wrote: > > My login.conf classes does not work, i have already looked for into The > Complete FBSD, man pages, /usr/src/lib/libutil/* but nothing works the > way i wanna. > I have a user that belong to shell shell login classes, but he is not > disconnected after 1 minute of idle time? Not all of the login class items work the way they are supposed to. You should probably look at 'idled' in the ports collection. Good luck, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 14: 3:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 335BB152A9 for ; Sun, 4 Jul 1999 14:02:52 -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 UAA17298; Sun, 4 Jul 1999 20:31:24 +0200 From: Luigi Rizzo Message-Id: <199907041831.UAA17298@labinfo.iet.unipi.it> Subject: Re: Pictures from USENIX To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Sun, 4 Jul 1999 20:31:24 +0200 (MET DST) Cc: billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG In-Reply-To: <50572.931115702@zippy.cdrom.com> from "Jordan K. Hubbard" at Jul 4, 99 12:14:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 976 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm going to have a "core team page" worked on which has pictures and > brief bios, perhaps something by next week. > > Such things may seem frivolous, but I it helps people relate a little > more directly to the core team if they can see what they look like and > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) just collecting URLs for people home pages might be an easier task perhaps ? cheers luigi (URL below) -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 14:40:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 2806614BFF for ; Sun, 4 Jul 1999 14:40:15 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id WAA66694; Sun, 4 Jul 1999 22:40:05 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 4 Jul 1999 22:40:05 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: hackers@freebsd.org Subject: Re: The busspace modernization initiative. In-Reply-To: <199907042003.OAA43735@harmony.village.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 Sun, 4 Jul 1999, Warner Losh wrote: > In message Doug Rabson writes: > : I think you are on the right lines here. Where does the resource come > : from? Are you going to support bus_space_map() and if so, how are you > : planning to call BUS_ALLOC_RESOURCE? > > In i386/i386/resource.c :-). Here's what is there now. It looks like > it currently bypasses BUS_ALLOC_RESOURCE, going to the resource > manager (rman) directly. Do you have any comments on this code? Or > would you rather I send you a complete patch/diff to comment on? This seems to bypass the nexus completely which isn't right. It wouldn't detect conflicts between bus_space_alloc and the new-bus resource apis since it has its own instances of struct rman. Do we really need to support this api for common newconfig style drivers? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 15: 0: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5AE6314FB3 for ; Sun, 4 Jul 1999 14:59:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA16607; Sun, 4 Jul 1999 15:59:50 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA44776; Sun, 4 Jul 1999 15:57:52 -0600 (MDT) Message-Id: <199907042157.PAA44776@harmony.village.org> To: Doug Rabson Subject: Re: The busspace modernization initiative. Cc: hackers@freebsd.org In-reply-to: Your message of "Sun, 04 Jul 1999 22:40:05 BST." References: Date: Sun, 04 Jul 1999 15:57:52 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : This seems to bypass the nexus completely which isn't right. It wouldn't : detect conflicts between bus_space_alloc and the new-bus resource apis : since it has its own instances of struct rman. This is true. However, that's just because that was what the code that I acquired from the newconfig people did. I don't think that it must be this way. : Do we really need to : support this api for common newconfig style drivers? Yes. I believe that we do. One thing that this is used for is to map things, even if they conflict. I'm sure I understand why it does that beyond checks for conflicts/valid I/O addresses in some drivers (mostly the scsi drivers). I'll have to look into what this API is supposed to do.... It is definitely heavily used (or at least used in almost all) in the few drivers that I've tried to port over.... It doesn't change the fact that bus_space_hanle_t is supposed to be an opaque type and many places in the three don't treat it as such.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 15:32:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 7C40615140 for ; Sun, 4 Jul 1999 15:32:48 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id SAA63048; Sun, 4 Jul 1999 18:32:29 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 4 Jul 1999 18:32:28 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.org Subject: Re: Pictures from USENIX In-Reply-To: <50572.931115702@zippy.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 Sun, 4 Jul 1999, Jordan K. Hubbard wrote: > I'm going to have a "core team page" worked on which has pictures and > brief bios, perhaps something by next week. > > Such things may seem frivolous, but I it helps people relate a little > more directly to the core team if they can see what they look like and > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) How about including a link with the e-mail address link on the relevant page to point http://www.FreeBSD.org/~user/personal.html? Either that or, for putting things on a single page, have everyone put their stuff in their ~/public_html in a specified location (i.e. bio.txt (bio.sgml?) self.jpg) and having the document projecteers use that as a base? If noone else wants to, I could do this, but keep it separate from the docproj... > > - Jordan Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Jul 4 15:42:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 909C714DCB for ; Sun, 4 Jul 1999 15:42:39 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA22750; Mon, 5 Jul 1999 08:12:27 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA13070; Mon, 5 Jul 1999 08:12:07 +0930 (CST) Date: Mon, 5 Jul 1999 08:12:07 +0930 From: Greg Lehey To: Luigi Rizzo Cc: "Jordan K. Hubbard" , billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX Message-ID: <19990705081206.D10702@freebie.lemis.com> References: <50572.931115702@zippy.cdrom.com> <199907041831.UAA17298@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907041831.UAA17298@labinfo.iet.unipi.it>; from Luigi Rizzo on Sun, Jul 04, 1999 at 08:31:24PM +0200 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 4 July 1999 at 20:31:24 +0200, Luigi Rizzo wrote: >> I'm going to have a "core team page" worked on which has pictures and >> brief bios, perhaps something by next week. >> >> Such things may seem frivolous, but I it helps people relate a little >> more directly to the core team if they can see what they look like and >> read a bit about them. Same for the committers group, but at 165+ >> members that's going to be a somewhat larger, long-term project. :-) > > just collecting URLs for people home pages might be an easier task > perhaps ? Much easier. Get the individual committers to put them in the handbook. We already have the mail addresses there. Greg -- See complete headers for address, home page 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 Jul 4 15:51:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id C39F314D72 for ; Sun, 4 Jul 1999 15:51:08 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA00383; Sun, 4 Jul 1999 17:51:08 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id RAA02124; Sun, 4 Jul 1999 17:51:06 -0500 Message-ID: <19990704175106.56355@right.PCS> Date: Sun, 4 Jul 1999 17:51:06 -0500 From: Jonathan Lemon To: Mike Smith Cc: hackers@freebsd.org, zach@zabbo.net Subject: Re: poll() scalability References: <19990704000042.59954@right.PCS> <199907042037.NAA07661@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199907042037.NAA07661@dingo.cdrom.com>; from Mike Smith on Jul 07, 1999 at 01:37:13PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 01:37:13PM -0700, Mike Smith wrote: > > I'd like to open discussion on adding a new interface to FreeBSD, > > specifically, a variant of poll(). > > > > The problem is that poll() (and select(), as well) do not scale > > well as the number of open file descriptors increases. When there > > are a large number of descriptors under consideration, poll() takes > > an inordinate amount of time. For the purposes of my particular > > application, "large" translates into roughly 40K descriptors. > > > > As having to walk this descriptor list (and pass it between user and > > kernel space) is unpalatable, I would like to have the interface > > simply take a "change" list instead. The kernel would keep the > > state of the descriptors being examined, and would in turn, return > > a short list of descriptors that actually had any activity. > > Zach Brown (copied) had some interesting ideas about this sort of thing > that he was very happy to espose while we were wandering around ZD a > few weeks back. I'm rather enamoured of anything that effectively > works like a callback mechanism (eg. signal delivery on an alternate > stack) as it scales far better to a threaded application. I would think that a system that uses callbacks (like POSIX's completion signals) would be more expensive than a call like poll() or select(). Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). Also, I would guess that you would start getting into locking problems, and how to cancel a signal which has already been posted. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 15:54:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 39B0B1514D for ; Sun, 4 Jul 1999 15:54:20 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (Hamilton-ppp44839.sympatico.ca [206.172.76.32]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA27078; Sun, 4 Jul 1999 18:57:23 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA53901; Sun, 4 Jul 1999 18:54:36 -0400 (EDT) (envelope-from tim) Date: Sun, 4 Jul 1999 18:54:36 -0400 From: Tim Vanderhoek To: "Jordan K. Hubbard" Cc: Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.org Subject: Re: Pictures from USENIX Message-ID: <19990704185436.B53737@mad> References: <50572.931115702@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <50572.931115702@zippy.cdrom.com>; from Jordan K. Hubbard on Sun, Jul 04, 1999 at 12:15:02PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 16: 1:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from npcollege-edu.net (mail.npcollege-edu.net [209.232.226.194]) by hub.freebsd.org (Postfix) with SMTP id 9C74015206; Sun, 4 Jul 1999 16:01:36 -0700 (PDT) (envelope-from workshop@npcollege-edu.net) From: Subject: Re: Deleting Your Address. Date: Sun, 4 Jul 1999 12:36:40 Message-Id: <165.534422.563833@npcollege-edu.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From:The SFSE(Scientific Facts Search Engine). When you send an email to EDU,R&D,or Job sites,your email might be forwarded via the SFSE to find the info you are looking for. The NU(NewAmerica University)has received a copy of your email,but the date is Feb/25/99.Do you still need this info? To refresh your memory you can go again to the NU website and look for these topics: "The Redeemat has solved all environmental problems"-"The 9% Producer Fee would eliminate crime & taxes within 3 years"-"The free NHRI (National Health & Retirement Insurance")- "The job guarantee system(JIC/Job Insurance Corporation)"and "The list of 22nd Centurys' products & businesses available right now". Or,request for the records of the SFSE search by putting in the subject REQUESTING INFO and click REPLY. Or,in the future send "REQUEST FOR SEARCH" (on any topic) directly to SFSE, and they will do the search for you,put in the subject SFSE. Or,please allow us to DELETE your address permanently by simply clicking REPLY. B.Morrison workshop@npcollege-edu.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 16:41:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dazed.slacker.com (dazed.slacker.com [208.15.208.76]) by hub.freebsd.org (Postfix) with SMTP id CD5B515189 for ; Sun, 4 Jul 1999 16:41:32 -0700 (PDT) (envelope-from nugget@dazed.slacker.com) Received: (qmail 38442 invoked by uid 1000); 4 Jul 1999 23:41:31 -0000 Date: Sun, 4 Jul 1999 18:41:31 -0500 From: David McNett To: freebsd-hackers@freebsd.org Subject: Re: Pictures from USENIX Message-ID: <19990704184131.C38157@dazed.slacker.com> References: <50572.931115702@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <50572.931115702@zippy.cdrom.com>; from Jordan K. Hubbard on Sun, Jul 04, 1999 at 12:15:02PM -0700 X-Operating-System: FreeBSD 3.2-STABLE i386 X-Distributed: Join the Effort! http://www.distributed.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Jul-1999, Jordan K. Hubbard wrote: > Such things may seem frivolous, but I it helps people relate a little > more directly to the core team if they can see what they look like and > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) Far from frivolous, I think that things like this will go a long way to dispel the common misconception that FreeBSD is developed by a small, closed, and unapproachable cadre of monks. Shouldn't be too unwieldy, assuming you don't also choose to include the cats of the core team as well. -- ________________________________________________________________________ |David McNett |To ensure privacy and data integrity this message has| |nugget@slacker.com|been encrypted using dual rounds of ROT-13 encryption| |Birmingham, AL USA|Please encrypt all important correspondence with PGP!| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 16:50: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id 4355314C59 for ; Sun, 4 Jul 1999 16:49:54 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA186586981; Sun, 4 Jul 1999 15:36:21 -0400 Date: Sun, 4 Jul 1999 15:36:21 -0400 (EDT) From: Bill Fumerola To: David McNett Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <19990704184131.C38157@dazed.slacker.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 Sun, 4 Jul 1999, David McNett wrote: > Far from frivolous, I think that things like this will go a long way > to dispel the common misconception that FreeBSD is developed by a > small, closed, and unapproachable cadre of monks. Shouldn't be too > unwieldy, assuming you don't also choose to include the cats of the > core team as well. It also clears up the misconception that being a member of -core requires a beard. A constant 5 o'clock shadow, maybe, but not a beard. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Jul 4 17:16:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thneed.ubergeeks.com (thneed.ubergeeks.com [206.205.41.245]) by hub.freebsd.org (Postfix) with ESMTP id EF5A115140 for ; Sun, 4 Jul 1999 17:16:14 -0700 (PDT) (envelope-from adrian@ubergeeks.com) Received: from localhost (adrian@localhost) by thneed.ubergeeks.com (8.9.3/8.9.3) with ESMTP id UAA00489; Sun, 4 Jul 1999 20:16:01 -0400 (EDT) (envelope-from adrian@ubergeeks.com) X-Authentication-Warning: thneed.ubergeeks.com: adrian owned process doing -bs Date: Sun, 4 Jul 1999 20:16:01 -0400 (EDT) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Anthony Kimball Cc: hackers@FreeBSD.ORG Subject: Re: Lizard... In-Reply-To: <14205.24876.313315.658481@avalon.east> 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 Fri, 2 Jul 1999, Anthony Kimball wrote: > > Lizard has a tetris game built in for those long waits... > Now THAT is cool. Using the "holistic emergency shell" on vty4 when doing a network install is more fun. At the very least it has been useful during evangelical installations. While the system extracting the bundles over ftp, I was able to telnet to another box and continue showing one of the deans of technology at UVa how a configured system looked. He was duly impressed by the fact that we didn't have to watch the progress meter twiddling my thumbs. Seriously though, do we really want frivolous bloat? If we need to provide entertainment, give the installer the option of reading netnews or a few select newbie articles from daemonnews or even a brief history of BSD. Adrian -- [ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 17:30:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id C03B114ECB for ; Sun, 4 Jul 1999 17:30:07 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA23171; Mon, 5 Jul 1999 10:00:01 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA00680; Mon, 5 Jul 1999 09:59:57 +0930 (CST) Date: Mon, 5 Jul 1999 09:59:57 +0930 From: Greg Lehey To: Bill Fumerola Cc: David McNett , freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX Message-ID: <19990705095957.C451@freebie.lemis.com> References: <19990704184131.C38157@dazed.slacker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Bill Fumerola on Sun, Jul 04, 1999 at 03:36:21PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 4 July 1999 at 15:36:21 -0400, Bill Fumerola wrote: > On Sun, 4 Jul 1999, David McNett wrote: > >> Far from frivolous, I think that things like this will go a long way >> to dispel the common misconception that FreeBSD is developed by a >> small, closed, and unapproachable cadre of monks. Shouldn't be too >> unwieldy, assuming you don't also choose to include the cats of the >> core team as well. > > It also clears up the misconception that being a member of -core requires > a beard. > > A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Greg -- See complete headers for address, home page 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 Jul 4 17:34:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 7BB4B14ECB for ; Sun, 4 Jul 1999 17:34:10 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id KAA16284; Mon, 5 Jul 1999 10:35:26 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199907050035.KAA16284@cimlogic.com.au> Subject: Re: Pictures from USENIX In-Reply-To: <19990705095957.C451@freebie.lemis.com> from Greg Lehey at "Jul 5, 1999 09:59:57 am" To: grog@lemis.com (Greg Lehey) Date: Mon, 5 Jul 1999 10:35:26 +1000 (EST) Cc: billf@chc-chimes.com (Bill Fumerola), nugget@slacker.com (David McNett), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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: > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? Nothing that a sharp knife or some hedge clippers couldn't fix. -- 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 Sun Jul 4 17:35:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 3B3DB151A4; Sun, 4 Jul 1999 17:35:15 -0700 (PDT) From: "Jonathan M. Bresler" To: grog@lemis.com Cc: billf@chc-chimes.com, nugget@slacker.com, freebsd-hackers@FreeBSD.ORG In-reply-to: <19990705095957.C451@freebie.lemis.com> (message from Greg Lehey on Mon, 5 Jul 1999 09:59:57 +0930) Subject: Re: Pictures from USENIX Message-Id: <19990705003515.3B3DB151A4@hub.freebsd.org> Date: Sun, 4 Jul 1999 17:35:15 -0700 (PDT) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? beards are great...women love them, getting fluffed is much better than getting scratched....kids love them. brush the beard whenever you brush your hair. dont hae to deal with a buzzing razor, very unkind to newly awoken folk. dont ahve to wield a blade across you neck in a fogged monring stupor. jmb--i aint shaved in 18 years. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 17:37:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id A72B6151A4 for ; Sun, 4 Jul 1999 17:37:17 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 82784 invoked from network); 5 Jul 1999 00:37:16 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 5 Jul 1999 00:37:16 -0000 Date: Sun, 4 Jul 1999 19:37:16 -0500 (CDT) From: David Scheidt To: Greg Lehey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <19990705095957.C451@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 Mon, 5 Jul 1999, Greg Lehey wrote: > On Sunday, 4 July 1999 at 15:36:21 -0400, Bill Fumerola wrote: > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? > > Greg Depends if it 100 F or not. David, clean shaven for the first time in months, Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 18: 4:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4449414BE2 for ; Sun, 4 Jul 1999 18:04:52 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA23330; Mon, 5 Jul 1999 10:34:50 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA00852; Mon, 5 Jul 1999 10:34:50 +0930 (CST) Date: Mon, 5 Jul 1999 10:34:49 +0930 From: Greg Lehey To: David Scheidt Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX Message-ID: <19990705103449.E451@freebie.lemis.com> References: <19990705095957.C451@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.4i In-Reply-To: ; from David Scheidt on Sun, Jul 04, 1999 at 07:37:16PM -0500 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 4 July 1999 at 19:37:16 -0500, David Scheidt wrote: > On Mon, 5 Jul 1999, Greg Lehey wrote: > >> On Sunday, 4 July 1999 at 15:36:21 -0400, Bill Fumerola wrote: >>> It also clears up the misconception that being a member of -core requires >>> a beard. >>> >>> A constant 5 o'clock shadow, maybe, but not a beard. >> >> And what's wrong with a beard? > > Depends if it 100 F or not. It's all in the mind. Anyway, how often does it get to 100°F in the middle of winter? > David, clean shaven for the first time in months, Scheidt Greg "haven't seen my chin in 30 years" Lehey -- See complete headers for address, home page 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 Jul 4 18: 6: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id BD27F151C3 for ; Sun, 4 Jul 1999 18:06:02 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA51932; Sun, 4 Jul 1999 18:03:07 -0700 (PDT) From: Archie Cobbs Message-Id: <199907050103.SAA51932@bubba.whistle.com> Subject: Re: poll() vs select() In-Reply-To: from Christopher Sedore at "Jul 4, 99 02:00:56 pm" To: cmsedore@mailbox.syr.edu (Christopher Sedore) Date: Sun, 4 Jul 1999 18:03:07 -0700 (PDT) Cc: peter@netplex.com.au, green@unixhelp.org, jlemon@americantv.com, wayne@crb-web.com, hackers@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 Christopher Sedore writes: > > Actually.. select() has three copyins and three copyouts per call. poll() > > has one copyin and one copyout per call. > > > > Now what I particular like is the event queue system that David Filo put > > together for Yahoo. In a nutshell you create a queue (a fd), and then > > register the descriptors you want to monitor with the queue. You then run > > an accept()-like loop where the accept returns the fd number that has met > > the conditions you asked for. For example, if you wanted to know if fd > > number 4251 becomes readable, then the accept would return 4251. This has > > potential to work across multiple processes sharing a queue so that events > > could get round robined or whatever. The other good part is that it > > maintains the state and lists persistantly and doesn't have to keep copying > > it to/from the kernel. It handles 50,000 to 100,000 connections without > > too much trouble. You can still use this with select as the queue fd > > becomes readable when there is an event waiting for your process. > > > > Is there interest in doing something like this in general? > > You can do much the same thing by using aio functions. I do this now with > an added syscall aio_waitcomplete, which allows a process to sleep waiting > for the next aio operation to finish. If more work was done on the aio > routines to improve their performance (the existing ones are better than > select() when you exceed about 40 descriptors), they would be faster than > poll or select, and could function in a similar fashion to the event queue > scheme above. I've only had about 140 or so connections open in my > experiments, but aio has no trouble with these, to the point where my > switched 100Mb line is the bottleneck. I experiment more with NNTP than > HTTP, though I have toyed with the idea of hacking an existing web server > to use aio. > > I like the event queue idea, but I'd like it for aio completions rather > than an enhanced select() function. A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. I.e., signal delivery, child exit notification, maybe even support for an arbitrary number of (independent) timers. And make the events independent from each other -- to avoid problems like when an application completely hangs for 90 seconds when it calls gethostbyname(). I've seen a zillion programs that have had to manually solve the problems caused by UNIX's lack of a unified event notification system. Eg., ppp(8) has its own timer library, etc. See also bind's event library. What a shameful waste/duplication of effort.. Really the underlying problem is that UNIX (originally) did not have any lightweight threads and options for IPC were (and still are) limited. This is one of the reasons I prefer programming in Java, even if it's slower. -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 Sun Jul 4 18: 6:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D424F15238 for ; Sun, 4 Jul 1999 18:06:49 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA51943; Sun, 4 Jul 1999 18:05:34 -0700 (PDT) From: Archie Cobbs Message-Id: <199907050105.SAA51943@bubba.whistle.com> Subject: Re: Porting LILO to FreeBSD In-Reply-To: <199907031915.NAA28969@harmony.village.org> from Warner Losh at "Jul 3, 99 01:15:22 pm" To: imp@harmony.village.org (Warner Losh) Date: Sun, 4 Jul 1999 18:05:34 -0700 (PDT) Cc: mike@smith.net.au, hackers@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 Warner Losh writes: > In message <199907031912.MAA01095@dingo.cdrom.com> Mike Smith writes: > : Neither; he'll have to tell the BIOS that the drive's not there. > > That's what he's doing right now... He doesn't want to keep doing > this since it is such a PITA. > > However, other posters in the thread gave me enough hints that I think > that I can help him make it work. LILO's trick of installing a small > translating shim on INT 13 may be just the ticket... Long ago I was a Linux hacker before converting to FreeBSD. I thought LILO was great and beat the heck out of FreeBSD's booteasy... -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 Sun Jul 4 18: 9:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 504B014DA7 for ; Sun, 4 Jul 1999 18:09:41 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA51971; Sun, 4 Jul 1999 18:09:02 -0700 (PDT) From: Archie Cobbs Message-Id: <199907050109.SAA51971@bubba.whistle.com> Subject: Re: Repalcement for grep(1) In-Reply-To: from Jamie Howard at "Jul 3, 99 03:18:07 pm" To: howardjp@wam.umd.edu (Jamie Howard) Date: Sun, 4 Jul 1999 18:09:02 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org, tech@openbsd.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 Jamie Howard writes: > Now, I am having a problem though. I cannot figure out how to implement > -w and -x. For -x, I tried modifying the regular expression (foo) into > ^(foo)$ before compiling, but that did not work. I intended to do > something similar with -w. Anyway, I am probably missing the obvious, but > does anyone have any ideas regarding how I should implement -w and -x? From the re_format(7) man page: There are two special cases- of bracket expressions: the bracket expressions `[[:<:]]' and `[[:>:]]' match the null string at the beginning and end of a word respectively. A word is defined as a sequence of word characters which is neither preceded nor followed by word characters. A word character is an alnum character (as defined by ctype(3)) or an underscore. This is an extension, compatible with but not specified by POSIX 1003.2, and should be used with caution in software intended to be portable to other sys- tems. Perhaps this will help with -w? -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 Sun Jul 4 18:32:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 5060714F86 for ; Sun, 4 Jul 1999 18:32:27 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac9.wam.umd.edu (root@rac9.wam.umd.edu [128.8.10.149]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA29329; Sun, 4 Jul 1999 21:32:24 -0400 (EDT) Received: from rac9.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac9.wam.umd.edu (8.9.3/8.9.3) with SMTP id VAA23896; Sun, 4 Jul 1999 21:32:23 -0400 (EDT) Received: from localhost by rac9.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA23892; Sun, 4 Jul 1999 21:32:23 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: howardjp owned process doing -bs Date: Sun, 4 Jul 1999 21:32:22 -0400 (EDT) From: Jamie Howard To: Archie Cobbs Cc: freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) In-Reply-To: <199907050109.SAA51971@bubba.whistle.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 Sun, 4 Jul 1999, Archie Cobbs wrote: > There are two special cases- of bracket expressions: the > bracket expressions `[[:<:]]' and `[[:>:]]' match the null > string at the beginning and end of a word respectively. A > word is defined as a sequence of word characters which is > neither preceded nor followed by word characters. A word > character is an alnum character (as defined by ctype(3)) > or an underscore. This is an extension, compatible with > but not specified by POSIX 1003.2, and should be used with > caution in software intended to be portable to other sys- > tems. > > Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am still having trouble with -x though. It turns out that even if I specify a commandline with a pattern of the form "^pattern$", it fails. If I specify "^pattern" it works. If I specify "pattern$" it does not. I have yet to find a case where my version will sucessfully match when a $ is at the end. Has anyone encountered anything like this before? Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 18:56:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A9128150F7 for ; Sun, 4 Jul 1999 18:56:41 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id VAA66263; Sun, 4 Jul 1999 21:56:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 4 Jul 1999 21:56:35 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Archie Cobbs Cc: Christopher Sedore , peter@netplex.com.au, green@unixhelp.org, jlemon@americantv.com, wayne@crb-web.com, hackers@FreeBSD.org Subject: Re: poll() vs select() In-Reply-To: <199907050103.SAA51932@bubba.whistle.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 Sun, 4 Jul 1999, Archie Cobbs wrote: > Christopher Sedore writes: > > A new, faster event notification system would be great. But don't forget > to include *all* events, not just file descriptor readability/writability. > I.e., signal delivery, child exit notification, maybe even support for > an arbitrary number of (independent) timers. And make the events independent > from each other -- to avoid problems like when an application completely > hangs for 90 seconds when it calls gethostbyname(). An async thread to do hostname lookups would be great! Wouldn't be too hard in libc_r, would it? But in regular apps, setitimer and sigsetjmp() would be a solution. > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Jul 4 18:58:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 89BC4150F7 for ; Sun, 4 Jul 1999 18:58:39 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id VAA66292; Sun, 4 Jul 1999 21:58:34 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 4 Jul 1999 21:58:34 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Archie Cobbs Cc: Warner Losh , mike@smith.net.au, hackers@FreeBSD.org Subject: Re: Porting LILO to FreeBSD In-Reply-To: <199907050105.SAA51943@bubba.whistle.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 Sun, 4 Jul 1999, Archie Cobbs wrote: > Long ago I was a Linux hacker before converting to FreeBSD. I thought > LILO was great and beat the heck out of FreeBSD's booteasy... But now, we have the FreeBSD loader courtesy of the BTX toolchain and the hard-working loader hackers :) > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Jul 4 21:26:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id A01BE14BF1 for ; Sun, 4 Jul 1999 21:26:27 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id OAA12630; Mon, 5 Jul 1999 14:25:27 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907050425.OAA12630@mycenae.ilion.eu.org> To: Brian Dean Cc: peter@netplex.com.au (Peter Wemm), rivers@dignus.com (Thomas David Rivers), freebsd-hackers@FreeBSD.ORG Subject: Re: support for i386 hardware debug watch points In-reply-to: Your message of "Sun, 04 Jul 1999 10:53:39 -0400." <199907041453.KAA03044@dean.pc.sas.com> Date: Mon, 05 Jul 1999 14:25:26 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've got some prototype code in place which supports the context > switching part of this. It's pretty simple right now, as I'm trying > to keep changes to a minimum. > > What I've done is simply added the dr0-dr3,dr6,dr7 registers to > 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu_switch(), > during a save operation, I load %dr7, and check the lower 8 bits, > which indicate if any breakpoints are in use. If they are, I save all > the debug registers, then clear out %dr7, which disables the > breakpoints. During a restore operation, I load the value of %dr7 > from the pcb structure of the new process, and if any of the lower 8 > bits are set, I restore all the debug registers. > > This is not as efficent as it could be implemented with a separate > flag to indicate whether saving the debug registers is necessary since > loading/storing the debug registers is fairly expensive (11 clocks on > an i486). 22 clocks on i386, 10 on i486, 11 on pentium. Also, on another topic, DRs are fairly portable as they've been a part of IA32 since i386. > Comments? I'm no expert on FreeBSD kernels, but I can speak for L4, and it's always good to look at past experiences in the area. (L4 is a very lean microkernel running on x86's, MIPS, (and soon Alphas and ARMs, although I'm currently in a process of convincing the authors of the later two to use BSD lincence instead of GPL ;) It currently claims to have the fastest IPC and lightweight thread implementation, so I guess it's a good raw model. From Jochen Liedtke's L4/x86 Reference Manual: User-level debug registers exist per thread. DR0..3, DR6 and DR7 can be accessed by the machine instructions MOV DRx,n and MOV r,DRx. However, only task-local breakpoints can be activated, i.e. bits L0...3 in DR7 cannot be set. Breakpoints operate per thread. Breakpoints are signalled as #DB exception (INT 1). Note that user-level breakpoints are suspended when kernel breakpoints are set by the kernel debugger. This says it all in terms of the user interface (which I think is brilliant in that it doesn't introduce any ugly new system calls.) Anyway, the MOV instructions are simulated in sofware, which should be easy enough. When a MOV DRx, n instruction is executed, it sets a bit in the TCB (well, it would be a PCB on FreeBSD ;) telling the scheduler that the DR registers are now valid (and hence should be saved/restored on a context switch from/to that process.) While on the topic of L4, would there be any interest in implementing Liedtke's small address spaces in FreeBSD? Basically, the idea is to improve TLB utilisation by simulated a tagged TLB on x86 using x86's segment registers. Because a typical process does not need the full 4GB address space, multiple processes could be multiplexed into a preallocated portion of the 4GB address space, eliminating the need for TLB flushes and CR0 reloads when switching between small processes (which hopefully constitute the bulk of the system load.) As a rough guide as to what's up for grabs, Liedtke's measured a reduction of the cost of a context switch on L4 from somewhere between 95 and 914 clocks (on pentium) down to 23 clock cycles when using small address spaces. The performance improvement is huge on pentiums, 6x86s and pentiums II, although the task is far from trivial (read: major changes to the memory manager and dynamic libraries.) Oh, if someone's interested, the original paper is at http://i30www.ira.uka.de/publications/pubcat/As-pent.ps And no, I don't voluneer to do it all by myself, although I'd be glad to help, coordinate the project, or even do most of the work myself given enough time. Patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 21:51:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DB6331526C for ; Sun, 4 Jul 1999 21:51:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA73084; Sun, 4 Jul 1999 21:51:29 -0700 (PDT) (envelope-from dillon) Date: Sun, 4 Jul 1999 21:51:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907050451.VAA73084@apollo.backplane.com> To: Patryk Zadarnowski Cc: Brian Dean , peter@netplex.com.au (Peter Wemm), rivers@dignus.com (Thomas David Rivers), freebsd-hackers@FreeBSD.ORG Subject: Re: support for i386 hardware debug watch points References: <199907050425.OAA12630@mycenae.ilion.eu.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :(which hopefully constitute the bulk of the system load.) As a rough :guide as to what's up for grabs, Liedtke's measured a reduction of the :cost of a context switch on L4 from somewhere between 95 and 914 clocks :(on pentium) down to 23 clock cycles when using small address spaces. :The performance improvement is huge on pentiums, 6x86s and pentiums :II, although the task is far from trivial (read: major changes to the :memory manager and dynamic libraries.) It's an interesting idea but you will never notice the difference unless you are making tens of thousands of context switches per second. Taking 900 clocks as an example, on a 400 MHz pentium this comes to, roughly 2uS. A thousand context switches per second would eat 2mS out of a second, wasting only 0.2% of the cpu. I think that there are places where we can make use of the 4MB segment capabilities, and kernel threads will eliminate mmu overhead for kernel processes. Anything too complex starts to get into diminishing returns. Using rfork() it is possible to share the same page table across multiple processes (though you'd have to write a little assembly to use the feature at the moment). You could certainly implement this single-address-space idea that way. ELF will allow you to load a program anywhere so it is theoretically possible to put together a system that operates in this manner. -Matt Matthew Dillon :And no, I don't voluneer to do it all by myself, although I'd be glad :to help, coordinate the project, or even do most of the work myself :given enough time. : :Patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 22:11:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id A94EC14EAB for ; Sun, 4 Jul 1999 22:11:24 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id BAA17867; Mon, 5 Jul 1999 01:10:38 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Mon, 5 Jul 1999 01:10:38 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: Jonathan Lemon Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability In-Reply-To: <19990704175106.56355@right.PCS> 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, 4 Jul 1999, Jonathan Lemon wrote: > I would think that a system that uses callbacks (like POSIX's completion > signals) would be more expensive than a call like poll() or select(). the sigio/siginfo model is a few orders of magnitude cheaper than poll/select as you scale the number of fds you're watching. The reasons for this being that select()/poll() have that large chunk of state to throw around every syscall, and the real world behaviour of very rarely ever returning more than than a few active pollfds with the sigio/siginfo model you register your interest in the fd at fd creation. from then on, when a POLL_ event happens on the fd we notice that it has an rt signal queue registered and a siginfo struct is tacked onto the end. these code paths can be nice and light. the siginfo enqueueing can be pointed at multiple queues by registering a process group with F_SETOWN, etc. ( and yes, the siginfo struct has stuff for telling what process just sent you a signal via kill(), posix timers, normal signal delivery, telling things about the child that just send you sigchld, faulting addr for segv and friends, in addition to the band (POLL_) info for sigio ) its important to notice that we don't actually use signal delivery for this sigio/siginfo stuff, we mask the signal and use signwaitinfo() to block or pop the next siginfo struct off the queue. dealing with async signals jumping in would be annoying, and to do it right one would probably want to simply enqueue the siginfo delivered to the signal handler into a nice fifo that the real thread of execution would deal with.. instead of doing all this grossness, we just let the kernel maintain the siginfo queue. its quite like the 'delta poll' system proposed, but with differently inelegant semantics. I'd say if one were to design an event queueing/notification system and add a new api for it, we'd want to do it correctly from the get-go and lose the similarity to existing interfaces entirely unless they really makes sense to behave like them (which it doesn't in the poll() case, imho) > Also, you really want to return more than one event at at time in > order to amortize the cost of the system call over several events, this > doesn't seem possible with callbacks (or upcalls). yes, that would be a nice behaviour, but I haven't seen it become a real issue yet. the sigwaitinfo() syscall is just so much lighter than all the other things going on in the situation where you actually use this system. for example, using this to serve a web page in the super fast case looks something like: sigwaitinfo() - aha, POLL_IN on listening socket.. accept() new fd setup sigio and such on new fd (dorky, we have to do this in linux rather than inheriting it from the listening fd. but it has yet to show up on the profile radar, so, whatever :)) read() in the header (usually done in one read, but rarely will block and require falling back to a POLL_IN on the new fd) parse header, ideally hash/lookup. write() out the precalced header and premapped data. perhaps a writev() if you're a wimp :) :) so even in the ridiculously light path of a cheating caching webserver, the overhead of copying the siginfo over is dwarfed by the rest of the stuff we're doing in response to the event. of course, this could change if you had a situation where you could burn through events like nothing else and simply couldn't deal with the lock-step.. > Also, I would guess that you would start getting into locking problems, > and how to cancel a signal which has already been posted. locking problems? yes, the possibility of getting stale events in the queue is _annoying_. This is going to be a problem in any system that passes state deltas to the process in a queued manner. hacks could be put in, and perhaps should, to remove events in the queue for a fd when it is closed, etc. take the web server case again. it is quite possible to close() an fd while there is an event queued for it, and then accept() a new fd that now has a bogus event coming down the pipe for it. I get around this garbage in the cheesy web server by doing deferred close()s on fds based on the length of the queue when I stopped being interested in the fd (and as such turned off sigio delivery). Its gross. but even with these problems, the rt signal queue is quite powerful. to do better would require a fair bit of engineering, and one might quickly be bogged down in featuritis. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 23:14: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 627E314D20 for ; Sun, 4 Jul 1999 23:13:58 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA13192; Mon, 5 Jul 1999 00:13:38 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37804D11.968AB2C0@softweyr.com> Date: Mon, 05 Jul 1999 00:13:37 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David McNett Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: <50572.931115702@zippy.cdrom.com> <19990704184131.C38157@dazed.slacker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David McNett wrote: > > On 04-Jul-1999, Jordan K. Hubbard wrote: > > Such things may seem frivolous, but I it helps people relate a little > > more directly to the core team if they can see what they look like and > > read a bit about them. Same for the committers group, but at 165+ > > members that's going to be a somewhat larger, long-term project. :-) > > Far from frivolous, I think that things like this will go a long way > to dispel the common misconception that FreeBSD is developed by a > small, closed, and unapproachable cadre of monks. Shouldn't be too > unwieldy, assuming you don't also choose to include the cats of the > core team as well. Why not? Cats are important, you know. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 23:14:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id B1160152B5 for ; Sun, 4 Jul 1999 23:14:12 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA13188; Mon, 5 Jul 1999 00:12:56 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37804CE7.D821B50F@softweyr.com> Date: Mon, 05 Jul 1999 00:12:55 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tim Vanderhoek Cc: "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Vanderhoek wrote: > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > read a bit about them. Same for the committers group, but at 165+ > > members that's going to be a somewhat larger, long-term project. :-) > > Did Wes Peters finish his collection of committer ICBMNet lat/long > co-ordinates? Here's what I have so far: # # Walnut Creek, our good friends. # 37.91 -122.06 "Walnut Creek" # Walnut Creek CD-ROM # # FreeBSD core team members # 37.9, -122.3, "asami" # Berkeley, CA 40.0, -123.5, "jkh" # Miranda, CA 40.1, -105.3, "gibbs, wosh" # Boulder, CO (wow!) 45.5, -122.6, "davidg" # near Portland, OR 47.5, -122.4, "jdp" # Seattle, WA 42.4, -71.1, "wollman" # Boston, MA 39.2, -77.0, "jmb" # Silver Spring, MD 56.0, -4.5, "gary" # Glasgow, UK 55.8, 37.6, "ache" # Moscow 53.0, 5.0, "guido" # Eindhoven, the Netherlands 55.4, 11.3, "phk, sos" # Denmark 52.0, 13.8, "joerg" # Germany 29.7, -95.4, "rich" # Houston, TX 39.8, -86.2, "dyson" # Indianapolis, IN -33.55,151.1, "bde" # Sydney, Australia. -31.58,115.49, "peter" # Perth, Australia. # # Other committers # 40.55 -111.90 "wes" # South Jordan, UT 46.59 -112.04 "nate" # Helena, MT 43.19 -89.38 "jlemon" # Madison, WI 34.13 -118.12 "mph" # Pasadena, CA -34 18 "markm" # Cape Town, South Africa 42.02 -93.67 "ghelmer" # Ames, IA 29.99 -90.13 "nectar" # Metairie, LA 42.34 -71.19 "gwollman" # Brighton, MA -34.53 138.35 "newton, kris, grog" # Adelaide, SA Australia 43.37 -79.79 "hoek" # Burlington, ON Canada 44.05 -123.08 "jmg" # Eugene, OR 59.72 10.85 "eivind" # Ski, Norway 53.33 9.59 "stb" # Hamburg Germany 38.54 -121.76 "obrien, mharo" # Davis, CA 43.71 10.40 "luigi" # Pisa, Italy 51.67 0.61 "brian" # Amersham, Bucks, UK 48.8 2.28 "ollivier" # Les Ulis, France 55.87 -4.26 " , roger" # Glasgow, UK 40.1 -105.3 " , merry, passe" # Boulder, CO (wow!) # # Others? # 50.70 6.2 "gellekum" # Thomas Gellekum, Aachen, Germany 12.58 77.35 "koshy" # Joseph Koshy, Bangalore, India 48.36 2.99 "philippe" # Phillipe Charnier, Cannes Ecluse, Fran ce The three marked Others were individuals who responded to didn't appear to have accounts on freefall. This looks pretty cool when used with xearth -markerfile, you can see that the sun never sets on the FreeBSD empire. ;^) So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. This, of course, doesn't count the bay area which is a lot of small town. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 23:16: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 99A4914D20 for ; Sun, 4 Jul 1999 23:16:03 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA13204; Mon, 5 Jul 1999 00:15:48 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37804D93.25A60635@softweyr.com> Date: Mon, 05 Jul 1999 00:15:47 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Scheidt Cc: Greg Lehey , freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Scheidt wrote: > > On Mon, 5 Jul 1999, Greg Lehey wrote: > > > On Sunday, 4 July 1999 at 15:36:21 -0400, Bill Fumerola wrote: > > > It also clears up the misconception that being a member of -core requires > > > a beard. > > > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > > > And what's wrong with a beard? > > > > Greg > > Depends if it 100 F or not. > > David, clean shaven for the first time in months, Scheidt It's 100F here on a regular basis through the summer. I've had a beard for over 10 years now. I shaved it once right after I was married. My wife told me I looked like my brother and should grow it back posthaste. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 4 23:37:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id A107A14C40 for ; Sun, 4 Jul 1999 23:37:41 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id QAA24479; Mon, 5 Jul 1999 16:07:38 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id QAA67576; Mon, 5 Jul 1999 16:07:33 +0930 (CST) Date: Mon, 5 Jul 1999 16:07:33 +0930 From: Greg Lehey To: Wes Peters Cc: Tim Vanderhoek , "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , hackers@FreeBSD.ORG Subject: FreeBSD locations (was: Pictures from USENIX) Message-ID: <19990705160732.N451@freebie.lemis.com> References: <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.4i In-Reply-To: <37804CE7.D821B50F@softweyr.com>; from Wes Peters on Mon, Jul 05, 1999 at 12:12:55AM -0600 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: > Tim Vanderhoek wrote: >> >> On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: >>> >>> read a bit about them. Same for the committers group, but at 165+ >>> members that's going to be a somewhat larger, long-term project. :-) >> >> Did Wes Peters finish his collection of committer ICBMNet lat/long >> co-ordinates? > > Here's what I have so far: > > 52.0, 13.8, "joerg" # Germany You've put Jörg somewhere near Berlin. He's in Dresden, further to the South-East. > -31.58,115.49, "peter" # Perth, Australia. Peter's gone to the USA, we think. > -34.53 138.35 "newton, kris, grog" # Adelaide, SA Australia I'm not in Adelaide, remember? Here are my coordinates: -35.14 138.77 grog > So far, Eivind is the northernmost and Grog and the Adelaide crowd the > southernmost. John Birrell's further South (Melbourne, for a first approximation): -37.7 144.9 jb > BDE is the easternmost and Jordan the westernmost. The largest > concentration so far is Boulder Colorado with 4, followed by the > Adelaide gang with 3. Hmm. Doesn't Daniel O'Connor have commit privileges? And it's time for Mike Smith to come home, then we'd have 5 :-) Greg -- See complete headers for address, home page 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 Jul 5 0: 4: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 0AA51152A3 for ; Mon, 5 Jul 1999 00:03:59 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id RAA17222; Mon, 5 Jul 1999 17:05:01 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199907050705.RAA17222@cimlogic.com.au> Subject: Re: FreeBSD locations (was: Pictures from USENIX) In-Reply-To: <19990705160732.N451@freebie.lemis.com> from Greg Lehey at "Jul 5, 1999 04:07:33 pm" To: grog@lemis.com (Greg Lehey) Date: Mon, 5 Jul 1999 17:05:00 +1000 (EST) Cc: wes@softweyr.com (Wes Peters), vanderh@ecf.utoronto.ca (Tim Vanderhoek), jkh@zippy.cdrom.com (Jordan K. Hubbard), billf@chc-chimes.com (Bill Fumerola), wilko@yedi.iaf.nl (Wilko Bulte), wjw@iae.nl (Willem Jan Withagen), hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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: > John Birrell's further South (Melbourne, for a first approximation): > > -37.7 144.9 jb Close enough. Danny O'Callaghan (danny) and Peter Hawkins (thpish) are in Melbourne too. -- 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 Mon Jul 5 0:16:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id BBC0114CCA for ; Mon, 5 Jul 1999 00:16:38 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id JAA26821; Mon, 5 Jul 1999 09:16:00 +0200 (MET DST) Date: Mon, 5 Jul 1999 09:15:58 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Wes Peters Cc: Tim Vanderhoek , "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <37804CE7.D821B50F@softweyr.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 your information http://www.mapblast.com specifies LongLat at the bottom of the page when you are looking at a map. Just move the icon to the right place. Cheers Nick n_hibma [ Icon Latitude: 45.869154, Longitude: 8.620118 ] On Mon, 5 Jul 1999, Wes Peters wrote: > Tim Vanderhoek wrote: > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > members that's going to be a somewhat larger, long-term project. :-) > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > co-ordinates? > > Here's what I have so far: > # > # Walnut Creek, our good friends. > # > 37.91 -122.06 "Walnut Creek" # Walnut Creek CD-ROM > # > # FreeBSD core team members > # > 37.9, -122.3, "asami" # Berkeley, CA ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 1:17:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id E79E614E25 for ; Mon, 5 Jul 1999 01:17:14 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id KAA54203; Mon, 5 Jul 1999 10:14:39 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907050814.KAA54203@freebsd.dk> Subject: Re: Pictures from USENIX In-Reply-To: <37804CE7.D821B50F@softweyr.com> from Wes Peters at "Jul 5, 1999 0:12:55 am" To: wes@softweyr.com (Wes Peters) Date: Mon, 5 Jul 1999 10:14:39 +0200 (CEST) Cc: vanderh@ecf.utoronto.ca, jkh@zippy.cdrom.com, billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 It seems Wes Peters wrote: > Tim Vanderhoek wrote: > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > members that's going to be a somewhat larger, long-term project. :-) > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > co-ordinates? > > Here's what I have so far: > 55.4, 11.3, "phk, sos" # Denmark That should be: 55.4, 11.3, "phk" # Denmark 57.2, 10.2, "sos" # Denmark We dont live THAT close together :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 1:44:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 33E88152B5 for ; Mon, 5 Jul 1999 01:44:24 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id KAA29798; Mon, 5 Jul 1999 10:38:29 +0200 (MET DST) Date: Mon, 5 Jul 1999 10:38:24 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Soren Schmidt Cc: Wes Peters , vanderh@ecf.utoronto.ca, jkh@zippy.cdrom.com, billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <199907050814.KAA54203@freebsd.dk> 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 > > > > read a bit about them. Same for the committers group, but at 165+ > > > > members that's going to be a somewhat larger, long-term project. :-) > > > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > > co-ordinates? > > > > Here's what I have so far: > > 55.4, 11.3, "phk, sos" # Denmark > > That should be: > 55.4, 11.3, "phk" # Denmark > 57.2, 10.2, "sos" # Denmark > > We dont live THAT close together :) Or rather, they live on opposite ends of the country ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 2:20:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2ACD614C3D for ; Mon, 5 Jul 1999 02:20:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id DAA18114; Mon, 5 Jul 1999 03:20:10 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id DAA52176; Mon, 5 Jul 1999 03:18:17 -0600 (MDT) Message-Id: <199907050918.DAA52176@harmony.village.org> To: Bill Fumerola Subject: Re: Pictures from USENIX Cc: David McNett , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 04 Jul 1999 15:36:21 EDT." References: Date: Mon, 05 Jul 1999 03:18:16 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bill Fumerola writes: : It also clears up the misconception that being a member of -core requires : a beard. If it did, then Jordan would be out. :-) Justin too. Those are the only two core members that I can even recall what they looked like... I don't think I've ever seen a 5 O'clock shadow on Justin... Certainly not on a regular basis. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 2:32:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F3D4D151E2 for ; Mon, 5 Jul 1999 02:32:24 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id DAA18144; Mon, 5 Jul 1999 03:32:22 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id DAA52245; Mon, 5 Jul 1999 03:30:29 -0600 (MDT) Message-Id: <199907050930.DAA52245@harmony.village.org> To: Wes Peters Subject: Re: Pictures from USENIX Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 00:12:55 MDT." <37804CE7.D821B50F@softweyr.com> References: <37804CE7.D821B50F@softweyr.com> <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> Date: Mon, 05 Jul 1999 03:30:28 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37804CE7.D821B50F@softweyr.com> Wes Peters writes: : 40.1, -105.3, "gibbs, wosh" # Boulder, CO (wow!) wosh? Didn't know there was a wosh in core. It certainly isn't me, since I'm in Boulder, but not in core. There appears to be no wosh account on freefall. : 40.1 -105.3 " , merry, passe" # Boulder, CO (wow!) Warner Losh, Ken Merry, Steve Passe and (until recently) Sean Kelly. Boulder is a small town, since I used to work with Ken, Sean and Justin. I now work with Steve Passe.... : largest concentration so far is Boulder Colorado with 4, followed by Yes. And if those are the only committers, their places of employment are separated by only a few blocks (literally walking distance, I've made the walk before when I was at Pluto since my wife works across the street from Timing Solutions).... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 2:51:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgate.rz.uni-karlsruhe.de (nz41.rz.uni-karlsruhe.de [129.13.197.5]) by hub.freebsd.org (Postfix) with ESMTP id B1FA2152E3 for ; Mon, 5 Jul 1999 02:50:30 -0700 (PDT) (envelope-from uk1o@rz.uni-karlsruhe.de) Received: from rzstud1.rz.uni-karlsruhe.de (exim@rzstud1.rz.uni-karlsruhe.de [129.13.197.183]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 2.04 #3) id 1115M2-0003Wc-00; Mon, 5 Jul 1999 11:48:04 +0200 Received: from uk1o by rzstud1.rz.uni-karlsruhe.de with local (Exim 2.12 #1) id 1115Lw-0006ow-00; Mon, 5 Jul 1999 11:47:56 +0200 Message-ID: <19990705114754.A23278@rz.uni-karlsruhe.de> Date: Mon, 5 Jul 1999 11:47:54 +0200 From: Hannah Schroeter To: Todd Vierling , Jamie Howard Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) Mail-Followup-To: Todd Vierling , Jamie Howard , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Todd Vierling on Sat, Jul 03, 1999 at 05:00:41PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! On Sat, Jul 03, 1999 at 05:00:41PM -0400, Todd Vierling wrote: > [...] > Hm. Adding ^ and $ should work, provided you don't specify either > REG_NOTBOL or REG_NOTEOL. (I assume that (foo) above, including the parens, > is the RE. With the parens, it depends whether you're using standard REs or > extended REs. :) But be careful about adding ^ and $ to something like (extended syntax) foo|bar. ^foo|bar$ is wrong, and ^(foo|bar)$ works HERE but not always, as when the original regex uses \number backreferences, you must patch them (increase by one), and you're hosed if \9 is already used. > [...] Regards, Hannah. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 2:53: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 4785D152DD for ; Mon, 5 Jul 1999 02:52:59 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id DAA18393; Mon, 5 Jul 1999 03:52:58 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id DAA52359; Mon, 5 Jul 1999 03:51:05 -0600 (MDT) Message-Id: <199907050951.DAA52359@harmony.village.org> To: Nick Hibma Subject: Re: Pictures from USENIX Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 09:15:58 +0200." References: Date: Mon, 05 Jul 1999 03:51:05 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Nick Hibma writes: : For your information : http://www.mapblast.com : specifies LongLat at the bottom of the page when you are looking at a : map. Just move the icon to the right place. That puts my current employer at 40.029322, -105.227900 and Pluto at 40.023712, -105.225382. Well, I'd have to knock a couple of significant figures off those since the addresses for these two places don't quite match the icon on the map... I told you they were walking distance... :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 3:14:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 3AB2A152CC for ; Mon, 5 Jul 1999 03:14:12 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 099B0370E3 for ; Mon, 5 Jul 1999 06:14:08 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id FAA00399 for hackers@FreeBSD.org; Mon, 5 Jul 1999 05:11:58 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 05:11:57 -0500 From: Chris Costello To: hackers@FreeBSD.org Subject: 'rtfm' script Message-ID: <19990705051156.B97224@holly.dyndns.org> Reply-To: chris@calldei.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=M9NhX3UHpAaciwkO User-Agent: Mutt/0.96.3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii I've been encountering people recently who, for one reason or another, are unable to find information for themselves when they have a question on FreeBSD. I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. The source is attached. Sample output: (-s = simple, don't search sections 3, 4, or 9, and 'e' means 'exact', or 'use whatis instead of apropos') --------- $ rtfm -s -e ASCII Manual pages found: ascii(7) hexdump(1) map3270(5) mset(1) neqn(1) od(1) pfbtops(1) Found FAQ entries: 1.18. Where can I get ASCII/PostScript versions of the FAQ? http://www.freebsd.org/FAQ/FAQ19.html#19 1.19. Where can I get ASCII/PostScript versions of the Handbook? http://www.freebsd.org/FAQ/FAQ20.html#20 1.20. The ASCII handbook isn't plain text! http://www.freebsd.org/FAQ/FAQ21.html#21 -- Chris Costello "I'll rob that rich person and give it to some poor deserving slob. That will *prove* I'm Robin Hood." -- Daffy Duck, "Robin Hood Daffy", [1958, Chuck Jones] --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=rtfm #!/usr/bin/perl -w # Copyright (c) 1999 Chris Costello # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. use IO::Socket; my ($mancnt, $line, @manuals, $manual, $simple, $exactword, @faqs); my ($http_socket); $mancnt = 0; $simple = 0; $exactword = 0; # Somehow I need to be able to try and find a 'closest mirror'. $http_server = 'www.freebsd.org'; $faq_path = '/FAQ'; &usage if $#ARGV < 0; while ($_ = $ARGV[0], /^-/) { shift(@ARGV); if (/^-s/) { $simple++; } # see simple description in man page elsif (/^-e/) { $exactword++; } elsif (/^-h/) { &usage } } $ent = $ARGV[0]; $prog = "whatis" if $exactword; $prog = "apropos" unless defined($prog); # First check to see if we have a man page. open(APROPOS, "$prog $ent|") || die "error encountered running $prog: $!"; while (defined($line = )) { chomp($line); $mancnt++; if ($line =~ /$ent: nothing appropriate/) { last; } # innovation. $line =~ s/^(.+?)\(([0-9nqt]+?)\).*/$2 $1/g; push(@manuals, $line); } close(APROPOS); if ($mancnt > 0) { print "Manual pages found:\n"; foreach $manual (@manuals) { my ($sect, $mman) = split(/ /, $manual); if ($simple > 0 && ($sect =~ /[349qt]+/)) { next; } print " $mman($sect)\n"; } } $http_socket = IO::Socket::INET->new($http_server . ':80'); print $http_socket "GET $faq_path/ HTTP/1.0\r\n\r\n"; while (defined($line = <$http_socket>)) { chomp($line); # superiority. if ($line =~ /^
(.+?)(.+?)<.*$/) { my ($faq_ent, $faq_page, $faq_question); $faq_ent = $1; $faq_page = $2; $faq_question = $3; if ($faq_question =~ /$ent/) { push(@faqs, sprintf("%s|%s|%s", $faq_ent, $faq_page, $faq_question)); } } } close($http_socket); print "\nFound FAQ entries:\n"; foreach (@faqs) { my ($faq_ent, $faq_page, $faq_question) = split(/\|/); print " $faq_ent $faq_question\n http://$http_server/FAQ/$faq_page\n"; } # usage: # prints usage info and exits. sub usage { print STDERR "usage: rtfm command\n"; exit 1; } --M9NhX3UHpAaciwkO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 5:16:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id B818214C3D for ; Mon, 5 Jul 1999 05:16:19 -0700 (PDT) (envelope-from gram@cequrux.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id OAA19630; Mon, 5 Jul 1999 14:14:20 +0200 (SAST) Received: by citadel via recvmail id 19628; Mon Jul 5 14:13:54 1999 Message-ID: <3780A23F.91B4951D@cdsec.com> Date: Mon, 05 Jul 1999 14:17:03 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Warner Losh Cc: Adrian Filipi-Martin , hackers@FreeBSD.ORG Subject: Re: Porting LILO to FreeBSD References: <199907030731.BAA23530@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message Adrian Filipi-Martin writes: > : The standard boot partition selection softwre also works fine > : booting windoze OS's from other disks. All you need to do is set the "disk > : id" in the DOS MBR to the correct number, 0x81 for your second disk. That's > : the only thing that MS doesn't do correctly whe installing the OS on the > : non-primary disk. I used to do this a long time ago to boot FreeBSD of the > : "C" drive and the other stuff off of "second C" drive. > > How does one do that? What tools do you use? I did this, using an old copy of Norton Disk Edit. It didn't work, although it did do something. Before I did it, if I told os-bs beta to boot DOS, it would give a `non-system disk or disk error' message (if I recall correctly; if not, it simply hung with no message). After changing the disk ID, it got as far as `Starting MS-DOS' but hung at that point. Note that os-bs beta was not good enough on its own. Actually, come to think of it, I didn't quite do this - I changed the disk ID in the boot sector of the DOS partition, rather than the MBR. Given that you do this with Norton Disk Editor, do you have to run DE and tweak it every time you want to change the disk? I guess one could write progs that runs under either O/S that will just toggle the appropriate byte, making it a bit less convenient. It's still a bit of a drag if you want to boot one O/S and the other is enabled, and you're powering up - you have to boot the wrong one, toggle the byte, and then reboot. I subsequently gave up and tried to uninstall os-bs beta. It told me that the uninstall option was not available. So I used Norton Disk Editor to restore my LILO boot record - except I mistakenly specified a logical rather than a physical sector. I spent the next day recovering from this (to the point where I had the screwdrivers out!). I gave myself a hundred lines: I will not confuse the physical and the logical; I will not confuse the physical and the logical... In the end I was back to square one. But then I remembered the real reason I had such a screwy setup - not for DOS itself, but because I wanted Windoze 3.1. But I haven't actually needed it in about two years, so I installed os-bs 3.5, scrapped the \Linux directory on my C: drive, and I'm quite happy (I can still boot DOS 6.2 from Win 95 by pressing F8 and selecting `Boot previous version of MS-DOS'). I still think it would be a good thing to port LILO to FreeBSD (and/or DOS/Windoze for that matter), but I'll leave that for another time (or another person!) -- Dr Graham Wheeler E-mail: gram@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 5:20:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id DD8121502F for ; Mon, 5 Jul 1999 05:20:51 -0700 (PDT) (envelope-from gram@cequrux.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id OAA20027; Mon, 5 Jul 1999 14:20:31 +0200 (SAST) Received: by citadel via recvmail id 20025; Mon Jul 5 14:20:27 1999 Message-ID: <3780A3C8.DB04812A@cdsec.com> Date: Mon, 05 Jul 1999 14:23:36 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Porting LILO to FreeBSD References: <199907031912.MAA01095@dingo.cdrom.com> <199907031915.NAA28969@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <199907031912.MAA01095@dingo.cdrom.com> Mike Smith writes: > : Neither; he'll have to tell the BIOS that the drive's not there. > > That's what he's doing right now... He doesn't want to keep doing > this since it is such a PITA. > > However, other posters in the thread gave me enough hints that I think > that I can help him make it work. LILO's trick of installing a small > translating shim on INT 13 may be just the ticket... But how will he install LILO, if he only has Windoze and FreeBSD? He could install Linux on his Windoze drive, get LILO bootstrapped, and take it off again afterwards, but making any changes to the LILO config will be tricky (I suppose he could make a bootable LINUX floppy). If he wants to install the shim, it has to be resident on the drive somewhere, but that's easy to sort out. It may be better to leave the shim (any_d.b) on the FreeBSD partition - LILO relies on it being at a known physical location on the disk. Under Windoze, if he ran disk defragmenter, he could break the boot. Now that I think of it, I'm probably lucky that I have never defragmented my Windoze drive or I would most likely have broken my LILO. -- Dr Graham Wheeler E-mail: gram@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 5:32:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id 8DF9614F76 for ; Mon, 5 Jul 1999 05:32:16 -0700 (PDT) (envelope-from gram@cequrux.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id OAA20788; Mon, 5 Jul 1999 14:31:59 +0200 (SAST) Received: by citadel via recvmail id 20724; Mon Jul 5 14:31:29 1999 Message-ID: <3780A65B.DE517E1F@cdsec.com> Date: Mon, 05 Jul 1999 14:34:35 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: Robert Nordier Cc: hackers@freebsd.org Subject: Re: Porting LILO to FreeBSD References: <199907021925.VAA16275@ceia.nordier.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Nordier wrote: > A Microsoft-style MBR gets the drive number from the byte at offset > 0 of the partition entry (field dp_flag of structure dos_partition > in /sys/sys/disklabel.h). This is usually known as the "active > flag", and all standard fdisk utilities set this to 0x80 (corresponding > to BIOS fixed drive 0) when flagging a partition as active. > > This can be patched by hand to some other value (eg. 0x81 for BIOS > fixed drive 1) but in a standard pre-Win95 OSR2 MBR this causes > problems, as the MBR code validates the partition table entries, > and will respond to the 0x81 with the message "Invalid partition > table" followed by a hang. Man, I wish I read this earlier on the weekend. One of the things I tried doing was haxing the FreeBSD fdisk program so that I could pass a different value for the flag as a command line argument. After doing this, I got just that behaviour. Unfortunately, so many other things had been tweaked by this stage (I had already clobbered the DOS boot sector once and had managed to reconstruct it by hand with a bit of trial and error) that I ended up doing more damage in my attempt to get the machine to boot again... > The easiest approach, probably adopted by LILO, is to install a > wrapper around the BIOS int 0x13 services and just change drive > numbers as they go by. That's exactly what LILO does, I believe. -- Dr Graham Wheeler E-mail: gram@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 5:41:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 12E6F14F73 for ; Mon, 5 Jul 1999 05:40:27 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11182U-000CjY-00; Mon, 05 Jul 1999 14:40:02 +0200 From: Sheldon Hearn To: John Polstra Cc: kernel@tdnet.com.br, hackers@freebsd.org Subject: Re: Login.conf (Whose problem is this) ? In-reply-to: Your message of "Sat, 03 Jul 1999 18:57:06 MST." <199907040157.SAA06552@vashon.polstra.com> Date: Mon, 05 Jul 1999 14:40:02 +0200 Message-ID: <48951.931178402@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 03 Jul 1999 18:57:06 MST, John Polstra wrote: > This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any > more. (It never was fully supported, actually.) Don't use it. There's an open PR for this, PR 10115. I assume all that's required is that we smack the outdated comments from login.conf? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 6: 8:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from agamaweb.agama.ru (www.agama.com [195.94.226.130]) by hub.freebsd.org (Postfix) with SMTP id 3912314FBE for ; Mon, 5 Jul 1999 06:08:15 -0700 (PDT) (envelope-from andrey@agama.com) Received: from [195.94.226.144] by agamaweb.agama.com (NTMail 4.01.0008/NU2432.00.3e8112ca) with ESMTP id cagbaaaa for ; Mon, 5 Jul 1999 17:03:53 +0400 Message-ID: <3780AEB2.206160E0@agama.com> Date: Mon, 05 Jul 1999 17:10:10 +0400 From: Andrew Iltchenko Organization: AGAMA X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Dynamic linking Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everyone! Is there a way of making dlopen return an error from the shared object's _init function? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 6:54:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.esat.net (relay02.esat.net [192.111.39.21]) by hub.freebsd.org (Postfix) with ESMTP id 5638A14DA7 for ; Mon, 5 Jul 1999 06:54:45 -0700 (PDT) (envelope-from niall@pobox.com) Received: from (pobox.com) [193.120.161.36] by relay02.esat.net with esmtp id 1119Cg-0007DJ-00; Mon, 5 Jul 1999 14:54:38 +0100 Message-ID: <3780B8D5.C32D210C@pobox.com> Date: Mon, 05 Jul 1999 14:53:25 +0100 From: Niall Smart X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Zach Brown Cc: Jonathan Lemon , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Also, you really want to return more than one event at at time in > > order to amortize the cost of the system call over several events, this > > doesn't seem possible with callbacks (or upcalls). > > yes, that would be a nice behaviour, but I haven't seen it become a real > issue yet. the sigwaitinfo() syscall is just so much lighter than all the > other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 7: 8:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 3893C1500A for ; Mon, 5 Jul 1999 07:08:07 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6627F64; Mon, 5 Jul 1999 22:08:06 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Lehey Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: FreeBSD locations (was: Pictures from USENIX) In-reply-to: Your message of "Mon, 05 Jul 1999 16:07:33 +0930." <19990705160732.N451@freebie.lemis.com> Content-Transfer-Encoding: 8bit Date: Mon, 05 Jul 1999 22:08:06 +0800 From: Peter Wemm Message-Id: <19990705140806.6627F64@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: [..] > > > -31.58,115.49, "peter" # Perth, Australia. > > Peter's gone to the USA, we think. Not yet. Not till later this year. 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 Jul 5 7:22:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id E9E7315255 for ; Mon, 5 Jul 1999 07:22:17 -0700 (PDT) (envelope-from cpiazza@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1002) id 67440740; Tue, 6 Jul 1999 07:21:27 -0700 (PDT) Date: Tue, 6 Jul 1999 07:21:27 -0700 From: Chris Piazza To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX Message-ID: <19990706072127.A373@norn.ca.eu.org> References: <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37804CE7.D821B50F@softweyr.com>; from Wes Peters on Mon, Jul 05, 1999 at 12:12:55AM -0600 X-Operating-System: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 05, 1999 at 12:12:55AM -0600, Wes Peters wrote: [cc's trimmed] > Tim Vanderhoek wrote: > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > members that's going to be a somewhat larger, long-term project. :-) > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > co-ordinates? > > Here's what I have so far: > # > # Walnut Creek, our good friends. > # > 37.91 -122.06 "Walnut Creek" # Walnut Creek CD-ROM > # 49.01, -122.68, "cpiazza" # near Vancouver, BC Wow, right on the 49th parallel! (FYI I can walk to the US border from my apartment...) > > So far, Eivind is the northernmost and Grog and the Adelaide crowd the > southernmost. BDE is the easternmost and Jordan the westernmost. The > largest concentration so far is Boulder Colorado with 4, followed by > the Adelaide gang with 3. This, of course, doesn't count the bay area > which is a lot of small town. Not enough Canadians, I think. -Chris -- cpiazza@home.net cpiazza@FreeBSD.org "Optimist, n. A proponent of the doctrine that black is white." -Ambrose Bierce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 7:23:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.logx.com (mail.logx.com [206.162.23.33]) by hub.freebsd.org (Postfix) with SMTP id 8C8AF15255 for ; Mon, 5 Jul 1999 07:23:22 -0700 (PDT) (envelope-from jir@logx.com) Received: (qmail 9817 invoked from network); 5 Jul 1999 14:23:16 -0000 Received: from p84b66b.sng4.ap.so-net.ne.jp (HELO jir) (210.132.182.107) by pop3.logx.com with SMTP; 5 Jul 1999 14:23:16 -0000 Message-ID: <000201bec6f2$12538000$0101a8c0@aladdin.jp> From: "jir" To: References: <3780AEB2.206160E0@agama.com> Subject: Re: Dynamic linking Date: Mon, 5 Jul 1999 23:22:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG - jir ji jimaria jir@logx.com irc#tokyo15 icq jir 3941247- http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi VAIO@PCG-C1@‚e‚’‚…‚…‚a‚r‚c‚Q‚Q‚W > Hi everyone! > > Is there a way of making dlopen return an error from the shared object's > _init function? > Thanks. What matters? May you instool some windows'soft? and change *.dll file serch *.dll and *is err's *dll You got? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 8: 9:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id 06C6F14CFD for ; Mon, 5 Jul 1999 08:09:54 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id LAA22802; Mon, 5 Jul 1999 11:09:30 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Mon, 5 Jul 1999 11:09:30 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: Niall Smart Cc: Jonathan Lemon , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability In-Reply-To: <3780B8D5.C32D210C@pobox.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 about a modified sigwaitinfo that will return a number of waiting > siginfo -- of course this introduces the problem of deciding how long > to wait for new additions to the queue before returning. This is you'd just have a 'give me up to X' parameter, if you get a single one under high load they will queue up until you call it next time.. waiting around stinks, these operations usually want low latency. > could buffer siginfo's in user space, although this introduces > complexity if you want the ability to cancel queued signals... yes, that is the hard part :) -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 9:11:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id A840614EAE for ; Mon, 5 Jul 1999 09:11:21 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 14028 invoked by uid 1001); 5 Jul 1999 16:24:02 -0000 Date: Mon, 5 Jul 1999 12:24:02 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: FreeBSD Hackers List Subject: Re: Porting LILO to FreeBSD In-Reply-To: <3780A3C8.DB04812A@cdsec.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, 5 Jul 1999, Graham Wheeler wrote: > Date: Mon, 05 Jul 1999 14:23:36 +0200 > From: Graham Wheeler > To: Warner Losh > Cc: hackers@FreeBSD.ORG > Subject: Re: Porting LILO to FreeBSD > > Warner Losh wrote: > > > > In message <199907031912.MAA01095@dingo.cdrom.com> Mike Smith writes: > > : Neither; he'll have to tell the BIOS that the drive's not there. > > > > That's what he's doing right now... He doesn't want to keep doing > > this since it is such a PITA. > > > > However, other posters in the thread gave me enough hints that I think > > that I can help him make it work. LILO's trick of installing a small > > translating shim on INT 13 may be just the ticket... > > But how will he install LILO, if he only has Windoze and FreeBSD? > He could install Linux on his Windoze drive, get LILO bootstrapped, > and take it off again afterwards, but making any changes to the LILO > config will be tricky (I suppose he could make a bootable LINUX floppy). > If he wants to install the shim, it has to be resident on the drive > somewhere, but that's easy to sort out. It may be better to leave > the shim (any_d.b) on the FreeBSD partition - LILO relies on it being > at a known physical location on the disk. Under Windoze, if he ran disk > defragmenter, he could break the boot. Now that I think of it, I'm > probably lucky that I have never defragmented my Windoze drive or I > would most likely have broken my LILO. I have, it works fine. I believe that the defrag program is smart enough not to move those precious bytes from the beginning of the partition. Come to think of it, if it did the system might not boot even if one wasn't using LILO. > > -- > Dr Graham Wheeler E-mail: gram@cequrux.com > Cequrux Technologies Phone: +27(21)423-6065/6/7 > Firewalls/Virtual Private Networks Fax: +27(21)24-3656 > Data/Network Security Specialists WWW: > http://www.cequrux.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 Mon Jul 5 10: 1: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id BC7161533A for ; Mon, 5 Jul 1999 10:00:42 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id KAA04077; Mon, 5 Jul 1999 10:00:38 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA10957; Mon, 5 Jul 1999 10:00:37 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: <48951.931178402@axl.noc.iafrica.com> Date: Mon, 05 Jul 1999 10:00:37 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Sheldon Hearn Subject: Re: Login.conf (Whose problem is this) ? Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: >> This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any >> more. (It never was fully supported, actually.) Don't use it. > > There's an open PR for this, PR 10115. I assume all that's required is > that we smack the outdated comments from login.conf? Yes, I think so. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 10: 4:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 73DD514A2D for ; Mon, 5 Jul 1999 10:04:43 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA19055; Mon, 5 Jul 1999 11:04:41 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA53599; Mon, 5 Jul 1999 11:02:53 -0600 (MDT) Message-Id: <199907051702.LAA53599@harmony.village.org> To: Graham Wheeler Subject: Re: Porting LILO to FreeBSD Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 14:23:36 +0200." <3780A3C8.DB04812A@cdsec.com> References: <3780A3C8.DB04812A@cdsec.com> <199907031912.MAA01095@dingo.cdrom.com> <199907031915.NAA28969@harmony.village.org> Date: Mon, 05 Jul 1999 11:02:53 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3780A3C8.DB04812A@cdsec.com> Graham Wheeler writes: : But how will he install LILO, if he only has Windoze and FreeBSD? Actually, he's happily booting Win95 and OpenBSD now. He's using radish which makes things just work. It did take some work getting rid of vestages of a WinNT install on the Win95 disk (it used to dual boot), but once that was done things were happy. No need to get Lilo involved at all :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 10:10:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id A6D7614C0F for ; Mon, 5 Jul 1999 10:09:32 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id AAA52427; Tue, 6 Jul 1999 00:08:58 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Tue, 6 Jul 1999 00:08:58 +0700 (NSS) From: Max Khon To: Andrew Iltchenko Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Dynamic linking In-Reply-To: <3780AEB2.206160E0@agama.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 hi, there! On Mon, 5 Jul 1999, Andrew Iltchenko wrote: > Is there a way of making dlopen return an error from the shared object's > _init function? > Thanks. You can do this by yourself by defining something like int _module_init() and calling it after dlopen'inig the object /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 10:37:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id F1B1D15206 for ; Mon, 5 Jul 1999 10:37:37 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA247331054; Mon, 5 Jul 1999 09:24:14 -0400 Date: Mon, 5 Jul 1999 09:24:14 -0400 (EDT) From: Bill Fumerola To: Greg Lehey Cc: David McNett , freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <19990705095957.C451@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 Mon, 5 Jul 1999, Greg Lehey wrote: > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Jul 5 11: 8:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3E81D14C2F for ; Mon, 5 Jul 1999 11:08:22 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id LAA54803; Mon, 5 Jul 1999 11:07:47 -0700 (PDT) From: Archie Cobbs Message-Id: <199907051807.LAA54803@bubba.whistle.com> Subject: Re: Repalcement for grep(1) In-Reply-To: from Jamie Howard at "Jul 4, 99 09:32:22 pm" To: howardjp@wam.umd.edu (Jamie Howard) Date: Mon, 5 Jul 1999 11:07:47 -0700 (PDT) Cc: archie@whistle.com, freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org, tech@openbsd.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 Jamie Howard writes: > > Perhaps this will help with -w? > > Yes, I received a patch from Simon Burge which implements this. It also > beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am > still having trouble with -x though. It turns out that even if I specify > a commandline with a pattern of the form "^pattern$", it fails. If I > specify "^pattern" it works. If I specify "pattern$" it does not. I have > yet to find a case where my version will sucessfully match when a $ is at > the end. Has anyone encountered anything like this before? Are you sure you're stripping out the newline and carriage return? -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 Mon Jul 5 11:25:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id 0AC2915093 for ; Mon, 5 Jul 1999 11:25:51 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA264463967; Mon, 5 Jul 1999 10:12:47 -0400 Date: Mon, 5 Jul 1999 10:12:47 -0400 (EDT) From: Bill Fumerola To: hackers@FreeBSD.org Subject: re: 'rtfm script' 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 in favor of the rtfm script. It's amazing the positive things that come out of an offhand IRC comment. [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] [15:29] tribune: yes, RTFM. [15:29] we need rtfm(1) [15:30] rtfm(1) would search the man pages, FAQ, and handbook for the COMPLETLY clueless. [15:31] billf: that rtfm command, I might write one. maybe it'll get people to shut the hell up ;) [15:32] It'd be easy to do in Perl. [15:32] cmc: I'd import it for you. [15:32] rtfm would work good.. in perl even [15:32] have it translate between "rtfm subject" and "rtfm subject(1)" [15:33] First it'll search the man pages. Then the handbook. Then the FAQ. Then, maybe see if I can find out if they start bitching, and if so, email Jesus Monroy. At that point the converstaion turned to talking about Irish soap carving and the fact that www.OpenBSD.org doesn't run OpenBSD. I guess I was wrong about IRC being positive. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Jul 5 11:37:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id E79E315093 for ; Mon, 5 Jul 1999 11:37:31 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id MAA14414; Mon, 5 Jul 1999 12:37:23 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3780FB62.96C773D2@softweyr.com> Date: Mon, 05 Jul 1999 12:37:22 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD locations (was: Pictures from USENIX) References: <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> <19990705160732.N451@freebie.lemis.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: > > > > Here's what I have so far: > > > > 52.0, 13.8, "joerg" # Germany > > You've put Jörg somewhere near Berlin. He's in Dresden, further to > the South-East. That's what he mailed me. I can't find a map of Dresden with lat- long right now. Help? > > -31.58,115.49, "peter" # Perth, Australia. > > Peter's gone to the USA, we think. Not another one? The FreeBSD Aussie invasion continues... > > -34.53 138.35 "newton, kris, grog" # Adelaide, SA Australia > > I'm not in Adelaide, remember? Here are my coordinates: > > -35.14 138.77 grog You didn't respond, so I lumped you in with the Adelaid crowd. I knew you were south of Adelaide, but I couldn't find Echunga on the only map I could find that gave coordinates. > > So far, Eivind is the northernmost and Grog and the Adelaide crowd the > > southernmost. > > John Birrell's further South (Melbourne, for a first approximation): > > -37.7 144.9 jb > > > BDE is the easternmost and Jordan the westernmost. The largest > > concentration so far is Boulder Colorado with 4, followed by the > > Adelaide gang with 3. > > Hmm. Doesn't Daniel O'Connor have commit privileges? And it's time > for Mike Smith to come home, then we'd have 5 :-) Oh lord, are we going to have to rename ourselves OzBSD now? ;^) Daniel doesn't have an account on freefall. -- "Where am I, and what am I doing in this handbasket?" ` Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 11:42: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id B1B1C15093 for ; Mon, 5 Jul 1999 11:42:07 -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 SAA20442; Mon, 5 Jul 1999 18:11:31 +0200 From: Luigi Rizzo Message-Id: <199907051611.SAA20442@labinfo.iet.unipi.it> Subject: mouse/keyboard usage statistics... To: hackers@freebsd.org Date: Mon, 5 Jul 1999 18:11:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1180 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, just as a curiosity (or maybe not...) i was wondering what would be the easiest way to get rough estimate of the number of keypress and mouse movements i do. It appears that vmstat -i already gives some estimate for the keyboard, e.g. ordinary keys give a couple of interrupts (on press/release), but whenever the autorepeat starts I get some 18 int/s and thus the data is extremely noisy. Is there a way to get 'true' keypress counts in the "sc" driver, and especially log this info into syslog when the system is shut down ? Same problems for mouse movements, except perhaps that i can hook into moused and so the problem is a little bit easier to deal with. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 12:18: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 7FA3D14CA7 for ; Mon, 5 Jul 1999 12:17:58 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id D4CF737076; Mon, 5 Jul 1999 15:17:54 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id OAA01308; Mon, 5 Jul 1999 14:16:36 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 14:16:36 -0500 From: Chris Costello To: Bill Fumerola Cc: hackers@FreeBSD.org Subject: Re: 'rtfm script' Message-ID: <19990705141635.D97224@holly.dyndns.org> Reply-To: chris@calldei.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Bill Fumerola on Mon, Jul 05, 1999 at 10:12:47AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 5, 1999, Bill Fumerola wrote: > I'm in favor of the rtfm script. It's amazing the positive > things that come out of an offhand IRC comment. > > [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] > > [15:33] First it'll search the man pages. Then the handbook. Then > the FAQ. Then, maybe see if I can find out if they start bitching, and if > so, email Jesus Monroy. Note that I can't figure out a decent way to search the Handbook at this point, but I'm open to ideas. -- Chris Costello Stack Error: Lost on a cluttered desk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 12:44: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id DBA1314D56 for ; Mon, 5 Jul 1999 12:44:00 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id OAA03201; Mon, 5 Jul 1999 14:43:53 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id OAA14310; Mon, 5 Jul 1999 14:43:52 -0500 Message-ID: <19990705144352.55649@right.PCS> Date: Mon, 5 Jul 1999 14:43:52 -0500 From: Jonathan Lemon To: Zach Brown Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability References: <19990704175106.56355@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Zach Brown on Jul 07, 1999 at 01:10:38AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 01:10:38AM -0400, Zach Brown wrote: > the sigio/siginfo model is a few orders of magnitude cheaper than > poll/select as you scale the number of fds you're watching. The reasons > for this being that select()/poll() have that large chunk of state to > throw around every syscall, and the real world behaviour of very rarely > ever returning more than than a few active pollfds Yes; that's effectively what the "delta" method I'm using now gets rid of; it only passes around state changes instead of the entire state. I agree that passing around the entire state is quite un-efficient; that's what I would like to get rid of. We just need to agree on a new method. > with the sigio/siginfo model you register your interest in the fd at fd > creation. from then on, when a POLL_ event happens on the fd we notice > that it has an rt signal queue registered and a siginfo struct is tacked > onto the end. these code paths can be nice and light. the siginfo > enqueueing can be pointed at multiple queues by registering a process > group with F_SETOWN, etc. Yes, but I also need support for temporarily "de-registering" interest in an fd, as well selectively choosing read/write/close events. > its important to notice that we don't actually use signal delivery for > this sigio/siginfo stuff, we mask the signal and use signwaitinfo() to > block or pop the next siginfo struct off the queue. dealing with async > signals jumping in would be annoying, and to do it right one would > probably want to simply enqueue the siginfo delivered to the signal > handler into a nice fifo that the real thread of execution would deal > with.. instead of doing all this grossness, we just let the kernel > maintain the siginfo queue. In this case, it doesn't seem all that different than a poll() type call, or an event queue that Peter was talking about. If the signal is blocked, then sigwaitinfo() effectively becomes a poll(), but with no timeout parameter. > its quite like the 'delta poll' system proposed, but with differently > inelegant semantics. I'd say if one were to design an event > queueing/notification system and add a new api for it, we'd want to do it > correctly from the get-go and lose the similarity to existing interfaces > entirely unless they really makes sense to behave like them (which it > doesn't in the poll() case, imho) I agree. One aspect of the design that should be explored is whether the new call should report "events", or "state". My current implementation reports state; (think of it as a level-triggered design), while the siginfo approach appears to be more of an "edge-triggered" design. I just looked at Banga's USENIX paper and they have a nice discussion of this issue. > setup sigio and such on new fd (dorky, we have to do this in > linux rather than inheriting it from the listening fd. > but it has yet to show up on the profile radar, so, > whatever :)) Hah. It showed up on my profiling; the kernel I'm running has routines so the child fd inherits certain settings from the parent. > read() in the header (usually done in one read, but rarely > will block and require falling back to a POLL_IN on > the new fd) Well, we _NEVER_ want to block. Ever. And in my particular case, it is quite common for the header/data to be spread out over several reads. > of course, this could change if you had a situation where you could burn > through events like nothing else and simply couldn't deal with the > lock-step.. Correct. I need this for a web caching proxy. The above loop won't work in my particular case. > > Also, I would guess that you would start getting into locking problems, > > and how to cancel a signal which has already been posted. > > locking problems? For asynchronous signal delivery, you alluded to this problem earlier as well. Since you're blocking signals, this isn't a problem. > yes, the possibility of getting stale events in the queue is _annoying_. > This is going to be a problem in any system that passes state deltas to > the process in a queued manner. hacks could be put in, and perhaps > should, to remove events in the queue for a fd when it is closed, etc. > > take the web server case again. it is quite possible to close() an fd > while there is an event queued for it, and then accept() a new fd that now > has a bogus event coming down the pipe for it. I get around this garbage > in the cheesy web server by doing deferred close()s on fds based on the > length of the queue when I stopped being interested in the fd (and as such > turned off sigio delivery). Its gross. Exactly. Sometimes, we just want to close() an fd, even if there are pending events, and then immediately re-open with a new fd. Deferred closes are not an option. What I do at the moment is remove queued events/state when the fd is closed. (actually, my implementation sucks a bit, as I re-scan the state for this particular case). > but even with these problems, the rt signal queue is quite powerful. to > do better would require a fair bit of engineering, and one might quickly > be bogged down in featuritis. Well, I'm sure that we have a lot of engineering talent around here. :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 13:11:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id 6DB2E14CB7 for ; Mon, 5 Jul 1999 13:11:23 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id QAA23091; Mon, 5 Jul 1999 16:11:07 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Mon, 5 Jul 1999 16:11:07 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: Jonathan Lemon Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability In-Reply-To: <19990705144352.55649@right.PCS> 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, 5 Jul 1999, Jonathan Lemon wrote: > Yes, but I also need support for temporarily "de-registering" interest > in an fd, as well selectively choosing read/write/close events. yeah, this isn't terribly doable in the sigio/signal model. as you note later, this is indeed edge triggered so if you were to 'turn off' sigio on the fds for a bit, you might lose a state transition. this can be trivially accounted for in the userland code by receiving all events and filtering out the ones you aren't interested in, and thats what I currently do, but having a mask in the kernel might be more sensible. (as it turns out there are very few errant signals) > In this case, it doesn't seem all that different than a poll() type > call, or an event queue that Peter was talking about. If the signal > is blocked, then sigwaitinfo() effectively becomes a poll(), but with > no timeout parameter. in that its blocking, yes, but its the only thing we're blocking on in the event engine. thats the only way I can see that it is like poll() :) > I agree. One aspect of the design that should be explored is whether > the new call should report "events", or "state". My current implementation > reports state; (think of it as a level-triggered design), while the the call should be able to do either, I'd guess. everything will be based around changes in state, regardless. the difference is wether you send those as units of work off to userland or if you toss them at an internal data structure that will then determine if the user cares about the resulting state. (so note that the 'level triggered' system could be built in user space code provided a 'edge triggered' kernel facility. some might argue taking this path) > siginfo approach appears to be more of an "edge-triggered" design. I definitely.. > Hah. It showed up on my profiling; the kernel I'm running has routines > so the child fd inherits certain settings from the parent. that strikes me as odd.. these calls should be trivial when compared to other things that are going on.. the only annoying thing this does to the sigio/siginfo state machine is requiring an initial read() on the socket.. but as that almost always returns the request, its all right. > > read() in the header (usually done in one read, but rarely > > will block and require falling back to a POLL_IN on > > the new fd) > > Well, we _NEVER_ want to block. Ever. And in my particular case, > it is quite common for the header/data to be spread out over several > reads. this only blocks when there is no work to do :) what I was referring to up there was the read() returning EAGAIN and us waiting for the POLL_IN event on the socket to say that there is data ready.. > Correct. I need this for a web caching proxy. The above loop won't work > in my particular case. ?? works fine for me. (am getting 3500 reqs/second over a single thread over localhost with small files on an smp machine) > Exactly. Sometimes, we just want to close() an fd, even if there are > pending events, and then immediately re-open with a new fd. Deferred > closes are not an option. What I do at the moment is remove queued > events/state when the fd is closed. (actually, my implementation sucks > a bit, as I re-scan the state for this particular case). the act of walking the queues could easily be more expensive than doing the defered close stuff if your queues are of respectable length. all the deferred close really does is add a latency to fd re-use, it doesn't significantly change the work involved.. > Well, I'm sure that we have a lot of engineering talent around here. :-) :) I need to go give that paper a read.. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 13:48:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 3C3D415008 for ; Mon, 5 Jul 1999 13:48:33 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA05780; Mon, 5 Jul 1999 13:46:43 -0700 (PDT) Message-Id: <199907052046.NAA05780@implode.root.com> To: Bill Fumerola Cc: Greg Lehey , David McNett , freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-reply-to: Your message of "Mon, 05 Jul 1999 09:24:14 EDT." From: David Greenman Reply-To: dg@root.com Date: Mon, 05 Jul 1999 13:46:43 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > A constant 5 o'clock shadow, maybe, but not a beard. >> >> And what's wrong with a beard? > >Nothing. I just remember someone pointing out in a previous e-mail that >all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14: 0:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 068CE150E3 for ; Mon, 5 Jul 1999 14:00:18 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id WAA55852; Mon, 5 Jul 1999 22:58:37 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907052058.WAA55852@freebsd.dk> Subject: Re: Pictures from USENIX In-Reply-To: <199907052046.NAA05780@implode.root.com> from David Greenman at "Jul 5, 1999 1:46:43 pm" To: dg@root.com Date: Mon, 5 Jul 1999 22:58:37 +0200 (CEST) Cc: billf@chc-chimes.com, grog@lemis.com, nugget@slacker.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 It seems David Greenman wrote: > >> > A constant 5 o'clock shadow, maybe, but not a beard. > >> > >> And what's wrong with a beard? > > > >Nothing. I just remember someone pointing out in a previous e-mail that > >all the core members had some sort of beard. > > Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14:14:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 7B03414D15 for ; Mon, 5 Jul 1999 14:14:38 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA05931; Mon, 5 Jul 1999 14:12:32 -0700 (PDT) Message-Id: <199907052112.OAA05931@implode.root.com> To: Soren Schmidt Cc: billf@chc-chimes.com, grog@lemis.com, nugget@slacker.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-reply-to: Your message of "Mon, 05 Jul 1999 22:58:37 +0200." <199907052058.WAA55852@freebsd.dk> From: David Greenman Reply-To: dg@root.com Date: Mon, 05 Jul 1999 14:12:31 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >It seems David Greenman wrote: >> >> > A constant 5 o'clock shadow, maybe, but not a beard. >> >> >> >> And what's wrong with a beard? >> > >> >Nothing. I just remember someone pointing out in a previous e-mail that >> >all the core members had some sort of beard. >> >> Very few core members have beards, so whoever said that was wrong. > >Nah, are you sure ?? I havn't shaved in over a decade :) Yes, I'm sure that all of the core members don't have beards (proven with just myself not having one). Although now that I think about it, about 25% of us do. This thread doesn't belong on hackers. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14:19:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (unknown [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id ED5DD14D15 for ; Mon, 5 Jul 1999 14:19:23 -0700 (PDT) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id RAA09800; Mon, 5 Jul 1999 17:22:30 -0400 (EDT) Date: Mon, 5 Jul 1999 17:22:29 -0400 (EDT) From: Dan Seguin To: Ladavac Marino Cc: FreeBSD Hackers Subject: RE: Connect and so on.. In-Reply-To: <55586E7391ACD211B9730000C11002761796AB@r-lmh-wi-100.corpnet.at> 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, 28 Jun 1999, Ladavac Marino wrote: > > > Essentially, we're trying to mediate system calls. Read, Write, Open, > > Socket calls from userland are caught, information about the calling > > process (i.e. caller UID) are sent to an external source for > > authorization and depending on the reply, the system call will proceed > > or > > not. This is the reason why the connection should be atomic and (so I > > think) in the kernel. Can't have other calls going through in the > > interim. > [ML] If I understand this correctly, only the syscall which is > being authenticated must block during the authentication. This makes > the authentication atomic from the viewpoint of the syscall. The other > processes/kernel supported threads may proceed. Sounds like > RAGF(spelling?) scheme you're doing there. Sorry about tardy response, I've been away. What you describe above is correctly expresses what I was trying to say. Could you point me to more about this (RAGF) scheme? > > NFS daemon approach may be feasible for you, because this is > exactly what it does. You have one central authentication daemon which > is blocked in kernel syscall all the time, unless some other process > (syscall) requests the authentication. The daemon then returns to user > space, performs the neccessary authentication, and goes back into kernel > with results. This is the way I would implement it, because it makes > adding authentication schemes rather simple. > > [ML] /Marino > Excellent, thank you. Although, looking through NFS code doesn't sound like fun. Oh well, time to pay my dues. Something else I need to look into is how to effeciently pass info back and forth from kernel space to user space and vice-versa. (See above for brief background of what I'm attempting to do). For every syscall being tracked/authenticated, a record is constructed and needs to be sent to the (userland) comms daemon that will send it to another server and await a response. In the mean time, the process making the syscall is blocked. Understandably this will really cut off process performance at the knees, but then again this a proof of concept project. One can easily imagine the processes being blocked starting to backup, since the comm daemon is competing for processor time, even if every entry into the kernel by (arbitrary) tracked syscalls resets the priority of the comms daemon to a higher level. (I'm trying to let the daemon get as much of the processor as possible to complete what it is doing. It releases it's quanta whenever it needs to wait for something). The comms daemon would keep a table of records received from the kernel to be authenticated, and only mark it as read when it has received a response (while being preempted many times), so that at the next arbitrary tracked syscall, the kernel would look at this table, look at all the status word fields (one per record) and read in the (response) records, if any, and mark these slots as unused for later use. This table would have to be in userland, with a single byte status field for every record. The table would have fixed size records, say 1k per entry. The seond field holds the PID and the third is free form. The status field would act as a signal to the kernel that a response was received. The kernel would read the status and PID and unblock the process, and either let the syscall proceed or not. Can't use a restart here, because, as I understand it, this would create another syscall, and hence a loop. Now, what I need to know is what is the best way to move this info over the fence, back and forth. Seems copyin() and copyout() are used throughout kernel code. With a table with fixed size records, I would simply need to loop through every status byte with copy*(addr + size(record)) to find out the responses, without (*ahem*) being interrupted. Is there an easier/better/more effecient subsystem to use that I don't know about? There are a lot of timing issues here, and I'm sure I've missed some. The comms daemon becomes a huge bottleneck for the processes that happen to make syscalls that are being tracked, but I don't see a better way. One of the things that the comm daemon would do is cache a lot of these recurring requests so that it wouldn't have to go "outside" to respond to the auth request. Also, if someone can point me to some books/papers/soliloquies of how to effeciently manage a shared table, I'd be grateful. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14:24:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.esat.net (relay02.esat.net [192.111.39.21]) by hub.freebsd.org (Postfix) with ESMTP id 31FF11512A for ; Mon, 5 Jul 1999 14:24:49 -0700 (PDT) (envelope-from niall@pobox.com) Received: from (pobox.com) [193.120.161.36] by relay02.esat.net with esmtp id 111GEK-0007U7-00; Mon, 5 Jul 1999 22:24:48 +0100 Message-ID: <3781225A.6C164A78@pobox.com> Date: Mon, 05 Jul 1999 22:23:38 +0100 From: Niall Smart X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: hackers@FreeBSD.org Subject: Re: 'rtfm script' References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At that point the converstaion turned to talking about Irish soap carving > and the fact that www.OpenBSD.org doesn't run OpenBSD. I guess I was wrong > about IRC being positive. Well, you can blame the first bit of surrealism on jkh, the poor fella has some awful ideas about what the Irish do in their spare time. God bless him. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14:42:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-28.ppp.wenet.net [206.15.85.28]) by hub.freebsd.org (Postfix) with ESMTP id C7AFF1514F for ; Mon, 5 Jul 1999 14:42:14 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id OAA15510; Mon, 5 Jul 1999 14:42:06 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Mon, 5 Jul 1999 14:42:06 -0700 (PDT) From: Alex Zepeda To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script In-Reply-To: <19990705051156.B97224@holly.dyndns.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 > I propose an rtfm(1) command, and I've got some Perl code that > works. If people are interested, I will continue with it, and > write a man page. [...] > (-s = simple, don't search sections 3, 4, or 9, and 'e' means > 'exact', or 'use whatis instead of apropos') If rtfm(1) is really for newbies and other clueless people, perhaps it should be made interactive. I mean, this whole idea sounds like it's geared towards people who wouldn't know what sections 3, 4, or 9 are. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 14:42:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 2643A152BB for ; Mon, 5 Jul 1999 14:42:22 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA85323; Mon, 5 Jul 1999 17:41:40 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 5 Jul 1999 17:41:40 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Wes Peters Cc: Tim Vanderhoek , "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.org Subject: Re: Pictures from USENIX In-Reply-To: <37804CE7.D821B50F@softweyr.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 Don't ICBM coordinates require an elevation. BTW, I'm at 38.75N 76.87W for the lovely list :) Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Jul 5 15: 4:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 52A03151F2 for ; Mon, 5 Jul 1999 15:04:34 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA20153; Mon, 5 Jul 1999 16:04:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA58611; Mon, 5 Jul 1999 16:02:47 -0600 (MDT) Message-Id: <199907052202.QAA58611@harmony.village.org> To: Wes Peters Subject: Re: FreeBSD locations (was: Pictures from USENIX) Cc: Greg Lehey , hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 05 Jul 1999 12:37:22 MDT." <3780FB62.96C773D2@softweyr.com> References: <3780FB62.96C773D2@softweyr.com> <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> <19990705160732.N451@freebie.lemis.com> Date: Mon, 05 Jul 1999 16:02:47 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3780FB62.96C773D2@softweyr.com> Wes Peters writes: : Oh lord, are we going to have to rename ourselves OzBSD now? ;^) We could have BoulderBSD, which would be 10MB surrounded by reality :-) There is also at least one OpenBSD committer in Boulder (aside from myself): Todd Miller. Warner P.S. For those of you unfamiliar with the poilical scene in Boulder, it has been summed up by the phrase "Boulder, 10 square miles surrounded by reality." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 15:18:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 5256315159 for ; Mon, 5 Jul 1999 15:18:08 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 5F3B837098; Mon, 5 Jul 1999 18:18:06 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id RAA01643; Mon, 5 Jul 1999 17:17:06 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 17:17:06 -0500 From: Chris Costello To: Alex Zepeda Cc: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990705171705.E97224@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705051156.B97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Alex Zepeda on Mon, Jul 05, 1999 at 02:42:06PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 5, 1999, Alex Zepeda wrote: > > I propose an rtfm(1) command, and I've got some Perl code that > > works. If people are interested, I will continue with it, and > > write a man page. > [...] > > (-s = simple, don't search sections 3, 4, or 9, and 'e' means > > 'exact', or 'use whatis instead of apropos') > > If rtfm(1) is really for newbies and other clueless people, perhaps it > should be made interactive. I mean, this whole idea sounds like it's > geared towards people who wouldn't know what sections 3, 4, or 9 are. It'll probably have a lot of changes in the actual interface if people accept it as useful or not. I may have 'simple' (default to don't search 3, 4, and 9) on as default. -- Chris Costello The computer is mightier than the pen, the sword, and usually, the programmer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 15:26:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id C470315238 for ; Mon, 5 Jul 1999 15:25:54 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id AAA76779 for ; Tue, 6 Jul 1999 00:25:53 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <00f101bec735$58fe2f80$0e00a8c0@neland.dk> From: "Leif Neland" To: "FreeBSD Hackers" Subject: Budget on user-ppp Date: Tue, 6 Jul 1999 00:20:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It could be nice with some sort of budget control in ppp. A few days ago I found out bb caused a dialup every 5 minutes. Today I found I had been online 27 hours uninterrupted. Some dialup-routers allows a setup of "max a connects/b minutes online over c hours". Also, I know it is possible to have a longer and longer retry wait between unsuccessful calls, but this is (as far as I can see) not documented anywhere. (Except perhaps archives) Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16: 5:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id BF9ED14EC7 for ; Mon, 5 Jul 1999 16:02:47 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id XAA83456 for hackers@freebsd.org; Mon, 5 Jul 1999 23:56:18 +0100 (BST) (envelope-from nik) Date: Mon, 5 Jul 1999 23:56:17 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: docs/12377: doc patch for login_cap. Message-ID: <19990705235617.T71138@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Thanks, N ----- Forwarded message from adrian@ubergeeks.com ----- From: adrian@ubergeeks.com To: FreeBSD-gnats-submit@freebsd.org Subject: docs/12377: doc patch for login_cap. >Number: 12377 >Category: docs >Synopsis: differences of a NULL login class need amplification >Originator: Adrian Filipi-Martin >Release: FreeBSD 3.2-RELEASE i386 >Environment: stock 3.2 installation. >Description: The fact that the root account has a different default login class is not well documented. It is documented, but only in passing in a paragraph low in the login_cap(3) manpage and in the login_cap.h header. The fact that the NULL login class has different interpretations depending upon the context of the capability lookup should be noted clearly or the behavior of the look up should be modified to make it more intuitive. The fact that the NULL class has two default values begs the question, "is there really a default class?" >How-To-Repeat: N/A >Fix: A quick fix is to apply the following doc patch. A better fix is to make all accounts with NULL login classes default to the "default" class and explicitly set root's class to 'root' in master.passwd. This would be an application of the "principle of least surprise". *** login.conf.orig Thu Jun 24 10:24:22 1999 --- login.conf Thu Jun 24 10:25:22 1999 *************** *** 60,65 **** --- 60,66 ---- # # Root can always login # + # N.B. This is the default class for the root account, not 'default'. root:\ :ignorenologin:\ :tc=default: --- login_cap.3.orig Thu Jun 24 10:27:45 1999 +++ login_cap.3 Thu Jun 24 10:32:53 1999 @@ -139,14 +139,15 @@ .Fn login_getclass or .Fn login_getuserclass . -If the referenced user has no login class specified in +If the referenced user is not root and has no login class specified in .Pa /etc/master.passwd , the class name is NULL or an empty string, or if the class specified does not exist in the database, each of these functions will search for a record with an id of "default", with that name returned in the .Ar lc_class -field. +field. If the user is root, then record with an id of "root" will +be returned instead of "default". .Pp The .Ar lc_cap >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message ----- End forwarded message ----- -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16:11: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id DD4FB15107 for ; Mon, 5 Jul 1999 16:09:09 -0700 (PDT) (envelope-from kbyanc@alcnet.com) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from kbyanc (ws-41.alcnet.com [63.69.28.41]) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with SMTP id TAA32278 for ; Mon, 5 Jul 1999 19:22:27 -0400 (EDT) From: "Kelly Yancey" To: Subject: mmap question Date: Mon, 5 Jul 1999 19:19:51 -0400 Message-ID: <000101bec73c$e20e3660$291c453f@kbyanc.alcnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a quick question about mmap, hopefully someone can smack me and point out what I'm missing :) the man page says: The mmap() function causes the pages starting at addr and continuing for at most len bytes to be mapped from the object described by fd, starting at byte offset offset. If len is not a multiple of the pagesize, the mapped region may extend past the specified range. Any such extension beyond the end of the mapped object will be zero-filled. Which is fine and dandy, I'll just stat() the file to get the filesize and mmap() it. But what happens in someone comes along and replaces the file with a larger file? I understand that my view of the file will change to the new file, but only the length that I mmap()ed originally. Do I have to periodically stat() the file to determine if I need to re-mmap() it should the file size change? And if so, doesn't that partly diminish the usefulness of mmap()? I mean, sure you can edit the file as a file and they are reflected in the in-memory image, but how many edits don't change the file size? Also, in case it hasn't been notice already (I'm running -stable from May 18th), the mmap(2) manpage has a typo: it has "#include " Thanks for your help, Kelly ~kbyanc@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16:16:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.ham.muohio.edu (dragon.ham.muohio.edu [134.53.147.33]) by hub.freebsd.org (Postfix) with ESMTP id 2F23F150BC for ; Mon, 5 Jul 1999 16:16:17 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from localhost (howardjp@localhost) by dragon.ham.muohio.edu (8.9.3/8.9.3) with ESMTP id SAA14705; Mon, 5 Jul 1999 18:19:44 -0400 X-Authentication-Warning: dragon.ham.muohio.edu: howardjp owned process doing -bs Date: Mon, 5 Jul 1999 18:19:43 -0400 (EDT) From: Jamie Howard X-Sender: howardjp@dragon.ham.muohio.edu To: Archie Cobbs Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) In-Reply-To: <199907051807.LAA54803@bubba.whistle.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, 5 Jul 1999, Archie Cobbs wrote: > Are you sure you're stripping out the newline and carriage return? You know, that did it. I'l put together another version tonight incorporating all the bug fixes and suggestions I have received over the past few days. More on that shortly. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16:23:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 2D63D14C40 for ; Mon, 5 Jul 1999 16:23:11 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-166.skylink.it [194.185.55.166]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id BAA07194 for ; Tue, 6 Jul 1999 01:22:44 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id BAA13916 for ; Tue, 6 Jul 1999 01:21:54 +0200 (CEST) Date: Tue, 6 Jul 1999 01:21:54 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: CAM: delaying new commands during 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 The Iomega USB Zip drive is a bit slow when resetting (reset of the USB part of the drive). It takes 1s or more to reset. The reset is initiated because for example an illegal command was received (sync cache for example). umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: CBW 45: cmd = 10b (0x250000000000...), data = 8 bytes, dir = in umass0: Handling state 2, Bulk Data, TIMEOUT umass0: data-in 8b failed, TIMEOUT umass0: Bulk Reset (reset is now in progress and previous SCSI has been cancelled) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) (CAM retries command) umass0: Busy, state 5, Bulk Reset (but gets told that the SCSI bus is busy) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) (tries again) umass0: Busy, state 5, Bulk Reset (and is again told to go away, etc.) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: Busy, state 5, Bulk Reset umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: Busy, state 5, Bulk Reset (da0:umass0:0:1:0): got CAM status 0x3f (da0:umass0:0:1:0): fatal error, failed to attach to device (da0:umass0:0:1:0): lost device (da0:umass0:0:1:0): removing device entry The problem is that the reset is initiated and the command that failed xpt_done()-d with an error. scsi_da then retries the command, but it is returned instantly with a CAM_SCSI_BUSY error because the reset is still in progress. What would be the proper approach to make the ccb delay until the reset has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or store the ccb and process it when the reset is done? Thanks for any advice. Nick umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16:23:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B77D15353 for ; Mon, 5 Jul 1999 16:23:16 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-166.skylink.it [194.185.55.166]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id BAA07197 for ; Tue, 6 Jul 1999 01:22:52 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id BAA13900 for ; Tue, 6 Jul 1999 01:04:08 +0200 (CEST) Date: Tue, 6 Jul 1999 01:04:08 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: CAM panic in camq_fini 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 When, after attaching to the CAM later with cam_simq_alloc(1) cam_sim_alloc(action, poll, "umass", sc, unit, 1, 0, devq) xpt_bus_register(sc->sim, 0) xpt_create_path(&sc->path, NULL, cam_sim_path(sc->sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) doing an immediate detach from it again, like so: xpt_async(AC_LOST_DEVICE, sc->path, NULL) xpt_free_path(sc->path) xpt_bus_deregister(cam_sim_path(sc->sim)) cam_sim_free(sc->sim, /*free_devq*/TRUE) (see also umass.c available at http://www.etla.net/~n_hibma/usb/umass.c.new after adding a call to umass_cam_detach right after umass_cam_attach). I get the following panic (frame #10): panic: free: address 0xdeadc0e2 out of range #0 0xc014b838 in boot () #1 0xc014ba85 in panic () #2 0xc012ea35 in db_panic () #3 0xc012e9d5 in db_command () #4 0xc012ea9a in db_command_loop () #5 0xc0130bfb in db_trap () #6 0xc021cc90 in kdb_trap () #7 0xc0228bb4 in trap () #8 0xc021ced3 in Debugger () #9 0xc014ba7c in panic () #10 0xc01482c6 in free () #11 0xc0122e22 in camq_fini () #12 0xc0122df5 in camq_free () #13 0xc012301e in cam_devq_free () #14 0xc01246db in cam_simq_free () #15 0xc0124785 in cam_sim_free () #16 0xc0209e46 in umass_cam_detach () #17 0xc0209067 in umass_detach () #18 0xc011d5eb in DEVICE_DETACH () #19 0xc01520c8 in device_detach () #20 0xc0151a6f in device_delete_child () #21 0xc0203836 in uhub_disconnect_port () #22 0xc020363f in uhub_explore () #23 0xc01ff45e in usb_discover () #24 0xc01ff192 in usbioctl () #25 0xc017e14c in spec_ioctl () #26 0xc017dab1 in spec_vnoperate () #27 0xc01e914d in ufs_vnoperatespec () #28 0xc0178441 in vn_ioctl () #29 0xc0157f43 in ioctl () #30 0xc02293f2 in syscall () #31 0xc021d5c0 in Xint0x80_syscall () #32 0x8048655 in ?? () It's pretty sure that it is not me doing anything nasty as the calls to attach and detach are virtually one after the other. Did I miss out on one of the deregister calls? One too many? On a sideline: the following is more consistent with the rest of the code: Index: cam_queue.c =================================================================== RCS file: /home/ncvs/src/sys/cam/cam_queue.c,v retrieving revision 1.3 diff -u -r1.3 cam_queue.c --- cam_queue.c 1999/04/19 21:26:08 1.3 +++ cam_queue.c 1999/07/05 22:58:55 @@ -136,8 +136,9 @@ queue->entries * sizeof(cam_pinfo *)); free(queue->queue_array, M_DEVBUF); } - queue->queue_array = new_array-1; + queue->queue_array = new_array; queue->array_size = new_size; + queue->queue_array--; return (CAM_REQ_CMP); } Cheers, Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 16:45:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 66C3214C41; Mon, 5 Jul 1999 16:45:40 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA35437; Mon, 5 Jul 1999 16:45:40 -0700 (PDT) Date: Mon, 5 Jul 1999 16:45:39 -0700 (PDT) From: Julian Elischer To: "Brian F. Feldman" Cc: Wes Peters , Tim Vanderhoek , "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: ICBM co-ords 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, 5 Jul 1999, Brian F. Feldman wrote: > Don't ICBM coordinates require an elevation. > BTW, I'm at 38.75N 76.87W for the lovely list :) according to maps.yahoo.com, I'm at: lt=37.7954 ln=-122.4267 (san francisco) (it's in the url line when you look up an address and then click on the place you want the co-ords of.) (I forget who is collecting these) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 17:21:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4793514C94 for ; Mon, 5 Jul 1999 17:21:30 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id RAA10653; Mon, 5 Jul 1999 17:21:22 -0700 Date: Mon, 5 Jul 1999 17:21:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nick Hibma Cc: FreeBSD Hackers mailing list Subject: Re: CAM: delaying new commands during reset 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 I'm not sure what you mean by 'Busy' here, but it doesn't matter I believe- the cam_periph_async called with case AC_SENT_BDR: case AC_BUS_RESET: { cam_periph_bus_settle(periph, SCSI_DELAY); break; } should do bus settling for SCSI_DELAY. If you're not actually doing a bus reset, you need to hold off the command with a requeue but only if you tell it when it can go (I believe- I sure wish Justin would document this stuff). On Tue, 6 Jul 1999, Nick Hibma wrote: > > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > part of the drive). It takes 1s or more to reset. The reset is initiated > because for example an illegal command was received (sync cache for > example). > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > umass0: CBW 45: cmd = 10b (0x250000000000...), data = 8 bytes, dir = in > umass0: Handling state 2, Bulk Data, TIMEOUT > umass0: data-in 8b failed, TIMEOUT > umass0: Bulk Reset > (reset is now in progress and previous SCSI has been cancelled) > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > (CAM retries command) > umass0: Busy, state 5, Bulk Reset > (but gets told that the SCSI bus is busy) > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > (tries again) > umass0: Busy, state 5, Bulk Reset > (and is again told to go away, etc.) > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > umass0: Busy, state 5, Bulk Reset > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > umass0: Busy, state 5, Bulk Reset > (da0:umass0:0:1:0): got CAM status 0x3f > (da0:umass0:0:1:0): fatal error, failed to attach to device > (da0:umass0:0:1:0): lost device > (da0:umass0:0:1:0): removing device entry > > The problem is that the reset is initiated and the command that failed > xpt_done()-d with an error. scsi_da then retries the command, but it is > returned instantly with a CAM_SCSI_BUSY error because the reset is > still in progress. > > What would be the proper approach to make the ccb delay until the reset > has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or > store the ccb and process it when the reset is done? > > Thanks for any advice. > > Nick > > umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new > -- > e-Mail: hibma@skylink.it > > > > 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 Jul 5 17:58:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by hub.freebsd.org (Postfix) with ESMTP id 30A3514E2F for ; Mon, 5 Jul 1999 17:58:34 -0700 (PDT) (envelope-from jabley@tardis.patho.gen.nz) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id MAA30926; Tue, 6 Jul 1999 12:58:23 +1200 (NZST) Date: Tue, 6 Jul 1999 12:58:22 +1200 From: Joe Abley To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990706125822.A26646@patho.gen.nz> References: <19990705051156.B97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <19990705051156.B97224@holly.dyndns.org>; from Chris Costello on Mon, Jul 05, 1999 at 05:11:57AM -0500 X-Files: the Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: > I've been encountering people recently who, for one reason or > another, are unable to find information for themselves when they > have a question on FreeBSD. > > I propose an rtfm(1) command, and I've got some Perl code that > works. If people are interested, I will continue with it, and > write a man page. > > The source is attached. It would be good if you could use fetch(1) instead of forming the HTTP request yourself. That way people who already have fetch working through proxies don't have to modify anything to use rtfm. Is there a particular reason you're writing it in perl? Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 18:14:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 097DC1538D for ; Mon, 5 Jul 1999 18:14:45 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from uther.wam.umd.edu (uther.wam.umd.edu [129.2.8.189]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA02799; Mon, 5 Jul 1999 21:14:41 -0400 (EDT) Received: from uther.wam.umd.edu (localhost [127.0.0.1]) by uther.wam.umd.edu (8.9.3/8.9.3) with SMTP id VAA13882; Mon, 5 Jul 1999 21:14:40 -0400 (EDT) Received: from localhost by uther.wam.umd.edu (8.9.3/8.9.3) with ESMTP id VAA13878; Mon, 5 Jul 1999 21:14:38 -0400 (EDT) X-Authentication-Warning: uther.wam.umd.edu: howardjp owned process doing -bs Date: Mon, 5 Jul 1999 21:14:36 -0400 (EDT) From: Jamie Howard To: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) 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 Due to the number of fixes I have received over the past few days, I decided to put together a new release of grep. It was either this or watch _Titanic_ on Cinemax. I incorporated a huge patch from Dag-Erling Smorgrav which as he put it "cleaned it up to make it conform to FreeBSD's coding style standards. I also removed a bunch of unused or unnecessary variables, fixed one or two minor bugs, and made a few entirely subjective cosmetic improvements." He also modified the Makefile to generate links for fgrep and egrep as well. All things I was going to worry with when it was done. :) I added the links for zgrep. I changed the sample length in the binary checker from 64 bytes to 32 at his suggestion. This is the same as how GNU grep handles it. I changed it so that even when called as grep or with -G, it treats the pattern as an extended regular expression. GNU grep behaves the same way. Simon Burge sent code to enable -w as well as several smaller code fixes and clean ups. I changed bin_file() and seekable() to operate on a pointer to a FILE rather than on an integer file descriptor. Due to popular demand, I added support for searching gzip compressed files. GNU grep only supports searching gzip compressed files. It did not bloat my code as much as I expected; I vapor locked and forgot about libz, which did all the hard work for me. It would be trivial to add support for bzip and bzip2 files for those OSes that have libbz2. Archie Cobbs dropped the hint needed to solve the problems with -x. Right now, I wrap the pattern with "^(" and ")$". I know GNU grep does this, but is this correct? Now, as it stands, I beleive this implementation is identical to GNU grep, except for the added -o option, and the -A num, -B num, -C, and -num family of options. Despite what I said before, I will implement them. Another popular demand thing. So I will take care of that over the next few days. It would be really swank if someone were to go over what I have and make sure it is correct. I know I was blowing $ before, and I think that is correct now. Due to problems with the previous download site (it is down as I type this), I will place this file in two locations: ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz It will probably be slow to hit the second, as it may be down until tomorrow morning. Thank you everyone who helped, Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 18:18: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 3B4EB1537A for ; Mon, 5 Jul 1999 18:18:03 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id E14F3370D5; Mon, 5 Jul 1999 21:18:00 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id UAA03020; Mon, 5 Jul 1999 20:17:00 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 20:16:59 -0500 From: Chris Costello To: Joe Abley Cc: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990705201658.G97224@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705051156.B97224@holly.dyndns.org> <19990706125822.A26646@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990706125822.A26646@patho.gen.nz>; from Joe Abley on Tue, Jul 06, 1999 at 12:58:22PM +1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 5, 1999, Joe Abley wrote: > On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: > > I've been encountering people recently who, for one reason or > > another, are unable to find information for themselves when they > > have a question on FreeBSD. > > > > I propose an rtfm(1) command, and I've got some Perl code that > > works. If people are interested, I will continue with it, and > > write a man page. > > > > The source is attached. > > It would be good if you could use fetch(1) instead of forming the > HTTP request yourself. That way people who already have fetch working > through proxies don't have to modify anything to use rtfm. > > Is there a particular reason you're writing it in perl? Mostly regexp and such. If I can figure out how to use the regexp code for C, I'd probably rewrite it. > > > Joe -- Chris Costello The generation of random numbers is too important to be left to chance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 18:34:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id DB3B315389 for ; Mon, 5 Jul 1999 18:34:50 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 5EF4E37101 for ; Mon, 5 Jul 1999 21:34:44 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id UAA03392 for hackers@FreeBSD.ORG; Mon, 5 Jul 1999 20:33:01 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 20:32:57 -0500 From: Chris Costello To: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990705203257.H97224@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705051156.B97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990705051156.B97224@holly.dyndns.org>; from Chris Costello on Mon, Jul 05, 1999 at 05:11:57AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've added texinfo searching and made it use fetch(1) instead for those behind proxies. Is there any word as to whether this might be imported into the actual tree or if I should just make it a port? -- Chris Costello Machine independent code isn't. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 18:38:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 77EC11508F for ; Mon, 5 Jul 1999 18:38:36 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id A56AA370E2 for ; Mon, 5 Jul 1999 21:38:34 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id UAA03503 for hackers@FreeBSD.ORG; Mon, 5 Jul 1999 20:37:22 -0500 (CDT) (envelope-from chris) Date: Mon, 5 Jul 1999 20:37:21 -0500 From: Chris Costello To: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990705203721.J97224@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705051156.B97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990705051156.B97224@holly.dyndns.org>; from Chris Costello on Mon, Jul 05, 1999 at 05:11:57AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The updated version (with support for texinfo searching, and use of fetch(1)) is availible at http://www.calldei.com/~chris/rtfm.pl -- Chris Costello It is now pitch dark. If you proceed, you will likely fall into a pit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 19:25:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 867A814DF1 for ; Mon, 5 Jul 1999 19:25:54 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id WAA06733; Mon, 5 Jul 1999 22:25:43 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA02224; Mon, 5 Jul 1999 22:25:12 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id WAA08230; Mon, 5 Jul 1999 22:25:12 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907060225.WAA08230@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <199907041554.KAA22328@free.pcs> from Jonathan Lemon at "Jul 4, 1999 10:54:41 am" To: jlemon@americantv.com (Jonathan Lemon) Date: Mon, 5 Jul 1999 22:25:12 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (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 Jonathan Lemon writes: > In article you write: > >This is not as efficent as it could be implemented with a separate > >flag to indicate whether saving the debug registers is necessary since > >loading/storing the debug registers is fairly expensive (11 clocks on > >an i486). > > Yes; you may want to just use another bit in pcb_flags that indicates > if the debug registers are in use. OK, I did that. What is the convention for naming the flags? The only one in use for that set of flags is FP_SOFTFP. I'm currently using PCB_DBREGS, but I but I easily change the name to whatever convention dictates - please advise. > >Should 'struct reg' be extended to directly include the debug > >registers or should we go the route of having another data structure > >for the debug registers, not unlike how the floating point registers > >are handled? > > I'd be inclined to create another data structure, unless the debug > registers are architecturally defined to be identical on all x86 > chips. > > > >Otherwise, I think I will need to set up a 'struct dbregs', provide > >the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a > >PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. > > Either that, or create a routine like i386_set_breakpoint() in > sys_machdep that would handle setting breakpoints for different > types of cpu architectures. What I ended up doing is make a new struct dbregs, similar to struct fpregs. Additionally, I modified the necessary procfs code to create a view to read and write the registers called "dbregs". The only thing that concerns me here is that maybe this entry in procfs is too architecture dependent, or maybe it violates some standards regarding procfs semantics (if there are any). I don't know enough about the Alpha architecture to know if this entry makes sense or not. Any comments here are appreciated. It appears as though some other systems do this with an ioctl call using the fd to the "/proc/$pid/ctl" file. However, these semantics seem to go against the precedent set by the ./regs and ./fpregs interfaces. I chose to use ./dbregs primarily because it was consistant with the use of ./regs and ./fpregs. Again, comments here are appreciated. I've got this kernel running right now and everything seems to be working fine, at least no panics or smoke. Here's a question: Are there any security concerns with being able to update the debug registers? Should a process be able to set a breakpoint inside the kernel, for example? In such a case, an INT 3 exception would be generated from within kernel code. Would this drop the system into the kernel debugger if it was enabled? If I've implemented the saving and restoring (and clearing) of the debug registers in cpu_switch() the way that I have intended, a watchpoint that a process sets within the kernel should not be able to occur outside the context of the process in which it was set. However, it is conceivable that a user (if allowed to put a breakpoint outside of his address space) could force the kernel to be interrupted at any location that could execute within the context of his process. This could result in breaking into code that was never designed to be interruptible, such as in the middle of updating a shared data structure. Any ideas are welcome, and I will do my best to implement them. Now that I've done this much, I now need to look at gdb some more and hook in the new interface. I'll follow that up with additional testing. Thanks, -Brian -- Brian Dean SAS Institute Inc brdean@unx.sas.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 19:42:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-32.ppp.wenet.net [206.15.85.32]) by hub.freebsd.org (Postfix) with ESMTP id 7DBA914DF1 for ; Mon, 5 Jul 1999 19:42:39 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id TAA00762; Mon, 5 Jul 1999 19:42:33 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Mon, 5 Jul 1999 19:42:33 -0700 (PDT) From: Alex Zepeda To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: 'rtfm' script In-Reply-To: <19990705171705.E97224@holly.dyndns.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 Mon, 5 Jul 1999, Chris Costello wrote: > > If rtfm(1) is really for newbies and other clueless people, perhaps it > > should be made interactive. I mean, this whole idea sounds like it's > > geared towards people who wouldn't know what sections 3, 4, or 9 are. > > It'll probably have a lot of changes in the actual interface > if people accept it as useful or not. I may have 'simple' > (default to don't search 3, 4, and 9) on as default. This sounds like a good idea. Now, ideally, I'd love to see something that could take an english phrase and figure out where to go from there. Sort of like an Ask Jeeves (ask.com) for FreeBSD newbies. This is not to say that the more advanced options wouldn't be useful; I could personally find a use for something to search the handbook, FAQs and man pages at once. I think I'll volunteer a few of my newbie friends once this progresses a bit further. P.S. If you're looking for an easy to use regexp implementation, and aren't afraid of C++, check out Qt; if you're looking for more of a challenge, there's always the need for an rtsl(1) ;) - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 20: 0:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id 1DB1B15396 for ; Mon, 5 Jul 1999 20:00:19 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA138244767; Mon, 5 Jul 1999 18:46:07 -0400 Date: Mon, 5 Jul 1999 18:46:07 -0400 (EDT) From: Bill Fumerola To: Alex Zepeda Cc: Chris Costello , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script 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, 5 Jul 1999, Alex Zepeda wrote: > P.S. If you're looking for an easy to use regexp implementation, and > aren't afraid of C++, check out Qt; if you're looking for more of a > challenge, there's always the need for an rtsl(1) ;) rtsl(1) = glimpse(1) :> - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 Jul 5 20:18:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-92.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.92]) by hub.freebsd.org (Postfix) with ESMTP id 3B30E14BF6 for ; Mon, 5 Jul 1999 20:18:45 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id EAA01573; Tue, 6 Jul 1999 04:11:42 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id EAA51783; Tue, 6 Jul 1999 04:11:41 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907060311.EAA51783@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "Leif Neland" Cc: "FreeBSD Hackers" Subject: Re: Budget on user-ppp In-reply-to: Your message of "Tue, 06 Jul 1999 00:20:00 +0200." <00f101bec735$58fe2f80$0e00a8c0@neland.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 04:11:39 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It could be nice with some sort of budget control in ppp. > A few days ago I found out bb caused a dialup every 5 minutes. > Today I found I had been online 27 hours uninterrupted. > Some dialup-routers allows a setup of "max a connects/b minutes online over > c hours". Patches are always welcome ;-) > Also, I know it is possible to have a longer and longer retry wait between > unsuccessful calls, but this is (as far as I can see) not documented > anywhere. > (Except perhaps archives) ? How about under ``set redial'' in the man page ? set redial secs[+inc[-max]][.next] [attempts] ppp can be instructed to attempt to redial attempts times. If more than one phone number is specified (see ``set phone'' above), a pause of next is taken before dialing each number. A pause of secs is taken before starting at the first number again. A literal value of ``random'' may be used here in place of secs and next, causing a random delay of between 1 and 30 seconds. If inc is specified, its value is added onto secs each time ppp tries a new number. secs will only be incremented at most maxinc times. maxinc defaults to 10. Note, the secs delay will be effective, even after attempts has been exceeded, so an immediate manual dial may appear to have done nothing. If an immediate dial is required, a ``!'' should immediately follow the ``open'' keyword. See the ``open'' de- scription above for further details. (Hmm, I'd better change maxinc -> max !) > Leif -- 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 Mon Jul 5 20:40:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from csudsu.com (clockwork.csudsu.com [209.0.50.131]) by hub.freebsd.org (Postfix) with ESMTP id 6545D15248 for ; Mon, 5 Jul 1999 20:40:21 -0700 (PDT) (envelope-from stefan@csudsu.com) Received: from localhost (stefan@localhost) by csudsu.com (8.8.8/1.3.2) with SMTP id UAA01758; Mon, 5 Jul 1999 20:38:58 -0700 (PDT) (envelope-from stefan@csudsu.com) Date: Mon, 5 Jul 1999 20:38:58 -0700 (PDT) From: Stefan Molnar To: "Jordan K. Hubbard" Cc: Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-Reply-To: <50572.931115702@zippy.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 Frivolous is to have a page with pics from Ulf's Partys and play "Spot The Devloper." Stefan On Sun, 4 Jul 1999, Jordan K. Hubbard wrote: > I'm going to have a "core team page" worked on which has pictures and > brief bios, perhaps something by next week. > > Such things may seem frivolous, but I it helps people relate a little > more directly to the core team if they can see what they look like and > read a bit about them. Same for the committers group, but at 165+ > members that's going to be a somewhat larger, long-term project. :-) > > - Jordan > > > > On Sun, 4 Jul 1999, Wilko Bulte wrote: > > > > > Which makes a good case for a permanent picture gallery @ www.freebsd.org > > > I guess. I can donate a bunch of pictures taken at last year's > > > hackersparty here in the Netherlands. > > > > When FreeBSDcon comes closer, I'll probably be be asking which of the > > developers are coming to it. I'm going to try to get some large group > > photos etc etc. > > > > > > - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - > > - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 22:17:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7D085153B1 for ; Mon, 5 Jul 1999 22:17:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA79921; Mon, 5 Jul 1999 22:17:23 -0700 (PDT) (envelope-from dillon) Date: Mon, 5 Jul 1999 22:17:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907060517.WAA79921@apollo.backplane.com> To: "Kelly Yancey" Cc: Subject: Re: mmap question References: <000101bec73c$e20e3660$291c453f@kbyanc.alcnet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Which is fine and dandy, I'll just stat() the file to get the filesize and :mmap() it. But what happens in someone comes along and replaces the file :with :a larger file? I understand that my view of the file will change to the new :file, but only the length that I mmap()ed originally. Do I have to :periodically stat() the file to determine if I need to re-mmap() it should :the file size change? And if so, doesn't that partly diminish the usefulness :of mmap()? I mean, sure you can edit the file as a file and they are :reflected in the in-memory image, but how many edits don't change the file :size? You can mmap() an area that is larger then the file. For example, you could mmap a 100 bytes file into a 32MB area. If the file then grows, you can access the new data up to the amount of space you reserved. However, accessing pages beyond the file EOF via the mmap() will result in a segfault. This is also true if a file is truncated out from under you - previously valid data pages will disappear. If you mmap() the exact size of a file and the file grows, you have to mmap() the new area of the file or unmap the old area and remap the entire file to gain access to the additional data. You can mmap() areas of a file in a piecemeal fashion though this should not be taken to extremes since it will slow down page-fault handling. Most programs using mmap() use it on files which are not expected to change out from under the program's control. Thus most programs using mmap() simply map the file's full size and do not try to do anything fancy. : Kelly : ~kbyanc@posi.net~ -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 22:42:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ontario.mooseriver.com (erie.mooseriver.com [208.138.31.117]) by hub.freebsd.org (Postfix) with ESMTP id 05A7A14F2B for ; Mon, 5 Jul 1999 22:42:14 -0700 (PDT) (envelope-from jgrosch@ontario.mooseriver.com) Received: (from jgrosch@localhost) by ontario.mooseriver.com (8.9.3/8.9.1) id WAA14029 for freebsd-hackers@freebsd.org; Mon, 5 Jul 1999 22:42:13 -0700 (PDT) (envelope-from jgrosch) Date: Mon, 5 Jul 1999 22:42:13 -0700 From: Josef Grosch To: freebsd-hackers@freebsd.org Subject: IPv6 and FreeBSD Message-ID: <19990705224213.A13996@ontario.mooseriver.com> Reply-To: jgrosch@MooseRiver.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Found this on slashdot. http://www.infoworld.com/articles/hn/xml/990705hn3com.xml There is a link to www.ipv6.org which lists IPv6 implementations. FreeBSD is listed as well as Linux, OpenBSD, and NetBSD. Linux ships with IPv6, OpenBSD will ship it's next version with IPv6. Any idea what the current status of our IPv6 implementation ? Josef -- Josef Grosch | Another day closer to a | FreeBSD 3.2 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23: 6:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8DCC114C94 for ; Mon, 5 Jul 1999 23:06:36 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 111ON8-000OFU-00; Tue, 06 Jul 1999 08:06:26 +0200 From: Sheldon Hearn To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. In-reply-to: Your message of "Mon, 05 Jul 1999 23:56:17 +0100." <19990705235617.T71138@catkin.nothing-going-on.org> Date: Tue, 06 Jul 1999 08:06:26 +0200 Message-ID: <93215.931241186@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: > I'm unfamiliar with the ins and outs of the login_cap system. Could > someone who is versed in it please take a look at this PR (text included) > and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as "root" if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system "default" entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23:13:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id ABEDB151AC for ; Mon, 5 Jul 1999 23:13:47 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA05087; Tue, 6 Jul 1999 15:13:39 +0900 (JST) To: jgrosch@MooseRiver.com Cc: freebsd-hackers@freebsd.org In-reply-to: jgrosch's message of Mon, 05 Jul 1999 22:42:13 MST. <19990705224213.A13996@ontario.mooseriver.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 and FreeBSD Date: Tue, 06 Jul 1999 15:13:39 +0900 Message-ID: <5085.931241619@coconut.itojun.org> From: Jun-ichiro itojun Hagino Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Found this on slashdot. > http://www.infoworld.com/articles/hn/xml/990705hn3com.xml >There is a link to www.ipv6.org which lists IPv6 implementations. FreeBSD >is listed as well as Linux, OpenBSD, and NetBSD. Linux ships with IPv6, >OpenBSD will ship it's next version with IPv6. Any idea what the current >status of our IPv6 implementation ? unified-ipv6 (INRIA+NRL+KAME) effort is under way, and current plan is to merge this in whenever it is ready. NetBSD-current recently merged in KAME codebase as they have feature freeze soon. NetBSD will be updating to unified-ipv6 when it becomes ready, but this two-step merger comes with some cost (API changes, bunch of code changes, whatever you may imagine). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23:13:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C55B3152EF for ; Mon, 5 Jul 1999 23:13:47 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 111OU5-000OKZ-00; Tue, 06 Jul 1999 08:13:37 +0200 From: Sheldon Hearn To: Jamie Howard Cc: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Mon, 05 Jul 1999 21:14:36 -0400." Date: Tue, 06 Jul 1999 08:13:37 +0200 Message-ID: <93530.931241617@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 05 Jul 1999 21:14:36 -0400, Jamie Howard wrote: > It would be really swank if someone were to go over what I have and make > sure it is correct. I know I was blowing $ before, and I think that is > correct now. Hi Jamie, One way to make it easier for people to test drive your software under FreeBSD is to create a port for the software (FreeBSD-style port, not NetBSD-style port). I'm home with flu right now, but if nobody else has done a port for your grep(1) by Thursday morning, I'll do it for you then. Would you be happy being listed as the maintainer of such a port? The reason I'm suggesting using a port rather than having the code imported into the base system is that it allows people to "opt in" to testing it, rather than forcing it down people's throats. The idea is that, when it's proved itself as a port, enough people will clamor for its inclusion in the base system for that to become a reality. Trying to get software imported directly into the base system without a trial run as a port is almost always a painful exercise (and I'm not talking about technical issues here). Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23:29:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mtk.comcor.ru (mtk.comcor.ru [212.45.0.156]) by hub.freebsd.org (Postfix) with SMTP id 68BF414C0C; Mon, 5 Jul 1999 23:29:07 -0700 (PDT) (envelope-from ryndin@mtk.comcor.ru) Received: by mtk.comcor.ru(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C32567A6.00239964 ; Tue, 6 Jul 1999 10:28:50 +0400 X-Lotus-FromDomain: COMCOR From: ryndin@mtk.comcor.ru To: questions@freebsd.org Cc: hackers@freebsd.org Message-ID: Date: Tue, 6 Jul 1999 10:28:54 +0400 Subject: Firewall and Oracle SQLNet Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody! Does anybody manage to install firewall before an Oracle SQL Server? We need to allow a few remote users to connect to our Oracle SQL Server. We install FreeBSD box with ipfw and discover next problem: we allow for remote users to connect to the Oracle box using port mentioned in SQLNet listener configuration (1521). But remote user try to connect twice: first time using port mentioned above and second time using some other port, which, as we suggest, Oracle server sent him during first connection. This port value start from 1030 (after Oracle restart) and increase after each connection and we don't manage to find it upper limit. As we suggest, Oracle uses second port to resolve sessions. We think that it is not a very good idea to allow users to connect to our server using such a wide port range. We look through all Oracle documentation and don't find any mention about the second connection. Oracle's people said that we need to use Oracle certified firewall, but it cost about 30000 backs and what hell of it!!!!! The question is does anybody managed to restrict Oracle in range of using second port values or have any idea about how to do it (there is no way to configure it in SQLNet configuration file). Thanks in advance, Alexey Ryndin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23:48:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 922EA14C0C for ; Mon, 5 Jul 1999 23:48:46 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA15929; Tue, 6 Jul 1999 00:48:40 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3781A6C7.798D1D60@softweyr.com> Date: Tue, 06 Jul 1999 00:48:39 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Soren Schmidt Cc: hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: <199907050814.KAA54203@freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt wrote: > > It seems Wes Peters wrote: > > Tim Vanderhoek wrote: > > > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > > members that's going to be a somewhat larger, long-term project. :-) > > > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > > co-ordinates? > > > > Here's what I have so far: > > 55.4, 11.3, "phk, sos" # Denmark > > That should be: > 55.4, 11.3, "phk" # Denmark > 57.2, 10.2, "sos" # Denmark OK, I've put the latest version in ~wes/FreeBSDmarkers on freefall, and it is public writable. Have at it. I'll check in a few days and when the edits have tapered off, I'll commit it back in CVS. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 5 23:56: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from io.checker.org (unknown [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 0371414C0C for ; Mon, 5 Jul 1999 23:55:56 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.checker.org (localhost [127.0.0.1]) by io.checker.org (Postfix) with ESMTP id 26B8810D; Mon, 5 Jul 1999 23:55:57 -0700 (PDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Sheldon Hearn Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 06 Jul 1999 08:13:37 +0200." <93530.931241617@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jul 1999 23:55:56 -0700 From: Jake Burkholder Message-Id: <19990706065557.26B8810D@io.checker.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One way to make it easier for people to test drive your software under > FreeBSD is to create a port for the software (FreeBSD-style port, not > NetBSD-style port). very rough port available at http://gulf.uvic.ca/~jburkhol/grep.shar -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 0:35: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 7A68214C37 for ; Tue, 6 Jul 1999 00:34:54 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id BAA16070; Tue, 6 Jul 1999 01:34:39 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3781B18E.1C502C56@softweyr.com> Date: Tue, 06 Jul 1999 01:34:38 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Greg Lehey , hackers@FreeBSD.ORG Subject: Re: FreeBSD locations (was: Pictures from USENIX) References: <3780FB62.96C773D2@softweyr.com> <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> <19990705160732.N451@freebie.lemis.com> <199907052202.QAA58611@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <3780FB62.96C773D2@softweyr.com> Wes Peters writes: > : Oh lord, are we going to have to rename ourselves OzBSD now? ;^) > > We could have BoulderBSD, which would be 10MB surrounded by reality > :-) We could all stick our computers in cases that look like rocks and... Never mind. > P.S. For those of you unfamiliar with the poilical scene in Boulder, > it has been summed up by the phrase "Boulder, 10 square miles > surrounded by reality." It seems to share that situation with Park City, where reality is no longer necessary because they have movie stars. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 1:36:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id C5EFE15348 for ; Tue, 6 Jul 1999 01:36:15 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id KAA29809; Tue, 6 Jul 1999 10:36:08 +0200 (MET DST) Date: Tue, 6 Jul 1999 10:36:06 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Matthew Jacob Cc: FreeBSD Hackers mailing list Subject: Re: CAM: delaying new commands during reset 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 > I'm not sure what you mean by 'Busy' here, but it doesn't matter I > believe- the cam_periph_async called with CAM actions come in and initiate one or more USB transfers. When the action has completed or failed, xpt_done() is called to mark the ccb as completed. If the command has failed, the umass driver initiates a bus reset that takes a while to complete. In the meantime CAM tries to submit new actions that fail because the subsystem is busy. Those commands have to be delayed until the reset has completed. > case AC_SENT_BDR: > case AC_BUS_RESET: > { > cam_periph_bus_settle(periph, SCSI_DELAY); > break; > } I guess I should dig through the async commands a bit more. It looks like there is quite a few features document in C. Cheers, Nick > > should do bus settling for SCSI_DELAY. If you're not actually doing a bus > reset, you need to hold off the command with a requeue but only if you > tell it when it can go (I believe- I sure wish Justin would document this > stuff). > > > On Tue, 6 Jul 1999, Nick Hibma wrote: > > > > > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > > part of the drive). It takes 1s or more to reset. The reset is initiated > > because for example an illegal command was received (sync cache for > > example). > > > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > > umass0: CBW 45: cmd = 10b (0x250000000000...), data = 8 bytes, dir = in > > umass0: Handling state 2, Bulk Data, TIMEOUT > > umass0: data-in 8b failed, TIMEOUT > > umass0: Bulk Reset > > (reset is now in progress and previous SCSI has been cancelled) > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > > (CAM retries command) > > umass0: Busy, state 5, Bulk Reset > > (but gets told that the SCSI bus is busy) > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > > (tries again) > > umass0: Busy, state 5, Bulk Reset > > (and is again told to go away, etc.) > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > > umass0: Busy, state 5, Bulk Reset > > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) > > umass0: Busy, state 5, Bulk Reset > > (da0:umass0:0:1:0): got CAM status 0x3f > > (da0:umass0:0:1:0): fatal error, failed to attach to device > > (da0:umass0:0:1:0): lost device > > (da0:umass0:0:1:0): removing device entry > > > > The problem is that the reset is initiated and the command that failed > > xpt_done()-d with an error. scsi_da then retries the command, but it is > > returned instantly with a CAM_SCSI_BUSY error because the reset is > > still in progress. > > > > What would be the proper approach to make the ccb delay until the reset > > has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or > > store the ccb and process it when the reset is done? > > > > Thanks for any advice. > > > > Nick > > > > umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new > > -- > > e-Mail: hibma@skylink.it > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 1:37:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 134E014C25 for ; Tue, 6 Jul 1999 01:37:24 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id KAA29852; Tue, 6 Jul 1999 10:36:56 +0200 (MET DST) Date: Tue, 6 Jul 1999 10:36:54 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Chris Costello Cc: Joe Abley , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script In-Reply-To: <19990705201658.G97224@holly.dyndns.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 libperl? Nick On Mon, 5 Jul 1999, Chris Costello wrote: > On Mon, Jul 5, 1999, Joe Abley wrote: > > On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: > > > I've been encountering people recently who, for one reason or > > > another, are unable to find information for themselves when they > > > have a question on FreeBSD. > > > > > > I propose an rtfm(1) command, and I've got some Perl code that > > > works. If people are interested, I will continue with it, and > > > write a man page. > > > > > > The source is attached. > > > > It would be good if you could use fetch(1) instead of forming the > > HTTP request yourself. That way people who already have fetch working > > through proxies don't have to modify anything to use rtfm. > > > > Is there a particular reason you're writing it in perl? > > Mostly regexp and such. If I can figure out how to use the > regexp code for C, I'd probably rewrite it. > > > > > > > Joe > > -- > Chris Costello > The generation of random numbers is too important to be left to chance. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 1:50:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hunter.Sisis.de (hunter.Sisis.de [193.31.11.194]) by hub.freebsd.org (Postfix) with SMTP id 1ACCA14A2F; Tue, 6 Jul 1999 01:50:50 -0700 (PDT) (envelope-from Matthias.Apitz@Sisis.de) Received: (from mail@localhost) by hunter.Sisis.de (8.6.9/8.6.12) id KAA08361; Tue, 6 Jul 1999 10:55:15 +0200 Received: from hermes.sisis.de(193.31.10.38) by hunter.Sisis.de via smap (V1.3) id sma008358; Tue Jul 6 10:55:06 1999 Received: from almare.Sisis.de (almare.sisis.de [193.31.10.40]) by hermes.sisis.de (8.8.8/8.8.8) with ESMTP id KAA22875; Tue, 6 Jul 1999 10:42:11 +0200 (CEST) (envelope-from guru@almare.Sisis.de) Received: (from guru@localhost) by mail.sisis.de (8.8.8/8.8.8) id KAA02315; Tue, 6 Jul 1999 10:49:37 +0200 (CEST) (envelope-from guru) Message-ID: <19990706104936.02747@sisis.de> Date: Tue, 6 Jul 1999 10:49:36 +0200 From: Matthias Apitz To: ryndin@mtk.comcor.ru Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Firewall and Oracle SQLNet Reply-To: guru@Sisis.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from ryndin@mtk.comcor.ru on Tue, Jul 06, 1999 at 10:28:54AM +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 10:28:54AM +0400, ryndin@mtk.comcor.ru wrote: > > > Hi everybody! > Does anybody manage to install firewall before an Oracle SQL Server? We need to > allow a few remote users to connect to our Oracle SQL Server. We install FreeBSD > box with ipfw and discover next problem: we allow for remote users to connect to > the Oracle box using port mentioned in SQLNet listener configuration (1521). But > remote user try to connect twice: first time using port mentioned above and > second time using some other port, which, as we suggest, Oracle server sent him ... check this article Message-ID: <930243288.714.0.pluto.d4ee154e@news.demon.nl> in comp.databases.oracle.server matthias -- firm: matthias.apitz@sisis.de [voc:+49 89 61308 351, fax: +49 89 61308 188] priv: guru@thias.muc.de WWW: http://www.sisis.de/~guru/ Give me UNIX or give me a typewriter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 2:59:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id F3F8B153EF; Tue, 6 Jul 1999 02:59:26 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id SAA05637; Tue, 6 Jul 1999 18:59:23 +0900 (JST) Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> To: freebsd-multimedia@freebsd.org, freebsd-hackers@freebsd.org Cc: Seigo Tanimura Subject: MPU401 now works under New Midi Driver Framework with a Fine Timer From: Seigo Tanimura X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 06 Jul 1999 18:59:23 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! MPU401, the most widely-used midi interface now works under my midi driver framework. Another new thing is a fine timer at a period of 156us, called directly from hardclock(). You can try the patch at: http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/ newmidi-19990706.diff.gz The instruction is at: http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/ Here is the introduction of my new timer: Unlike 16550, MPU401 does not generate an interrupt on TX-ready. So we have to choose one of the following two options to drive MPU401: A. polling the status to wait until TX-ready, B. emulating a TX-ready interrupt by a timer. The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()), consumes most of syscall time to wait for MPU401 to come TX-ready. One byte of midi message takes 0.32ms to transmit. Some certain midi sequences contain continuous long sysexes summed up to 200 bytes or more, leaving a latency of 0.32 * 200 = 60ms or something like that. This latency results in an unstable tempo. I have chosen the option B to eliminate the latency on message transmission. In this case, the timer needs to be capable of a period less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s], which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems to shorten the period of timeout(9) enough, many parts of the kernel would be affected by this change, likely to end up with poor stability. To solve this problem, I propose a new *fine* callout mechanism. The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where (1 << hzmul) is the mutiplication ratio of hz. Although the ratio can be any natural number in theory, I have chosen the power of two to reduce the computational cost of the clock divider. (discussed later) As desceribed above, (for i386) clkintr() is called at (hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency. hardclock() has two elements in it: a callout detector and a clock divider. A callout detector traverses the callout list and makes a callout, as in softclock(), except that the IPL stays at splclock. A clock divider reduces the frequency to hz[Hz], to process the conventional hardclock(), which is now renamed to hardclock1(), and softclock(). Although dividing a clock tick generally involves a costing division operation of the dividor counter by (1 << hzmul), a ratio of 2^n allows us to replace the operation with a simple shift of (clkdiv >> hzmul), where clkdiv is the dividor counter incremented one by one on a hardclock(). Fig 1 shows the frequency and the IPL of the new timer handlers. Frequency IPL Timer ^ ^ Generator | | | | | v (hz * (1 << hzmul))[Hz] splclock clkintr() | | | | | v v v hardclock() -> Fine ________________________________________ | Callouts ^ ^ v | | hardclock1() | | | hz[Hz] splsoftclock v | | softclock() -> Conventional | | Callouts v v Fig 1: Call Frequency and IPL under New Timer Handling I have implemented the new fine callout system discussed above in the latest patch of my midi driver. hzmul is 6, to multiply the timer frequency to 6400Hz. The usage of the fine callout is the same as timeout(9), except for the prefix of fine-, and that the granularity of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done any quantitative evaluation yet, I played some midi sequences with sysex messages to show a picture on the LCD of my SC-88, recognizing no latency like VoxWare. This result states the effectiveness of my proposing fine callout system. The future works include porting to alpha and PC98, and tuning hzmul. Whew, that was some kind of a paper to write! I would be pleased very much if you let me know how you think of my idea. Thanks in advance! Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 3: 1: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 39A3414C0C for ; Tue, 6 Jul 1999 03:01:03 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id KAA22631; Tue, 6 Jul 1999 10:59:43 +0100 (BST) (envelope-from joe) Date: Tue, 6 Jul 1999 10:59:43 +0100 From: Josef Karthauser To: Brian Somers Cc: Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp Message-ID: <19990706105943.E9669@pavilion.net> References: <00f101bec735$58fe2f80$0e00a8c0@neland.dk> <199907060311.EAA51783@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907060311.EAA51783@dev.lan.awfulhak.org>; from Brian Somers on Tue, Jul 06, 1999 at 04:11:39AM +0100 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 04:11:39AM +0100, Brian Somers wrote: > > ? How about under ``set redial'' in the man page ? > Brian, The i4b stuff seems to have some sophisticated costing control code (isdn.rates). It appears that you can define the costs at different times of day and thereby vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 3:16:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 4D23114F1D; Tue, 6 Jul 1999 03:15:59 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:KGLxdLz7XsflZC/cyNekQ9R04KsJc2DL@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id TAA21371; Tue, 6 Jul 1999 19:15:57 +0900 (JST) 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 TAA09981; Tue, 6 Jul 1999 19:20:11 +0900 (JST) Message-Id: <199907061020.TAA09981@zodiac.mech.utsunomiya-u.ac.jp> To: hackers@freebsd.org, doc@freebsd.org Cc: bde@freebsd.org, wpaul@freebsd.org, rnordier@freebsd.org, nik@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: README.serial update? Date: Tue, 06 Jul 1999 19:20:10 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From time to time people ask questions about the serial console. As README.serial is buried deep inside the kernel source tree, it's almost time to have a decent text on the serial console in our handbook. I am reformatting README.serial so that it can be included in our handbook, and adding bits and pieces to clarify things. I haven't finished it yet, but would like to have your comments now, so that we can make it more informative and useful. I put up the HTML version in: http://www.freebsd.org/~yokota/serialconsole.html and the SGML version in: ftp://www.freebsd.org/~yokota/serial-console.sgml Please have a look and send me comments, corrections, additional useful text, relevant pointers, etc. Some notes: - The text describes FreeBSD versions 3.0 and 3.1 or later. Version 3.0 doesn't have our new boot loader, so there is a note in the introduction section about it. - Because there are many differences regarding the serial console setup between 2.X systems and 3.X systems, I don't directly deal with 2.X systems in this text. - I am not a SGML expart ;-< formatting and links may be wrong. - Some sections are not yet finished :-) - The chapter number is arbitrary. When this text will be eventually included in the handbook, I expect Nik will put it somewhere suitable and give appropriate chapter number. Thank you. Kazu PS: I don't subscribe to the doc ML. Please send mail to the hackers ML or to me directly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 3:34:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.indigo.ie (relay02.indigo.ie [194.125.133.226]) by hub.freebsd.org (Postfix) with SMTP id 4DFFD14BCC for ; Tue, 6 Jul 1999 03:34:42 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 8783 messnum 46307 invoked from network[194.125.148.104/ts03-104.dublin.indigo.ie]); 6 Jul 1999 10:34:40 -0000 Received: from ts03-104.dublin.indigo.ie (HELO pobox.com) (194.125.148.104) by relay02.indigo.ie (qp 8783) with SMTP; 6 Jul 1999 10:34:40 -0000 Message-ID: <36E113A5.21F85DE5@pobox.com> Date: Sat, 06 Mar 1999 11:38:13 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Zach Brown Cc: Jonathan Lemon , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > could buffer siginfo's in user space, although this introduces > > complexity if you want the ability to cancel queued signals... > > yes, that is the hard part :) Well, how about the kernel passes siginfo and siginfo_cancel events up to userland, siginfo will remove any siginfo's from its buffer that it sees a siginfo_cancel event for -- naturally we need a flag to tell siginfo when to poll for events, this flag would be set by the function which cancels siginfo's. Would this work? Is it worth the complexity? Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 3:56:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6925A1512B for ; Tue, 6 Jul 1999 03:56:18 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id MAA46950; Tue, 6 Jul 1999 12:56:04 +0200 (CEST) (envelope-from des) To: Wes Peters Cc: Tim Vanderhoek , "Jordan K. Hubbard" , Bill Fumerola , Wilko Bulte , Willem Jan Withagen , grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: <50572.931115702@zippy.cdrom.com> <19990704185436.B53737@mad> <37804CE7.D821B50F@softweyr.com> From: Dag-Erling Smorgrav Date: 06 Jul 1999 12:56:04 +0200 In-Reply-To: Wes Peters's message of "Mon, 05 Jul 1999 00:12:55 -0600" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters writes: > # > # Others? > # > 50.70 6.2 "gellekum" # Thomas Gellekum, Aachen, Germany > 12.58 77.35 "koshy" # Joseph Koshy, Bangalore, India > 48.36 2.99 "philippe" # Phillipe Charnier, Cannes Ecluse, Fran > ce > > The three marked Others were individuals who responded to didn't appear > to have accounts on freefall. This looks pretty cool when used with > xearth -markerfile, you can see that the sun never sets on the FreeBSD > empire. ;^) "gellekum" == tg@freebsd.org "koshy" == jkoshy@freebsd.org "philippe" == charnier@freebsd.org > So far, Eivind is the northernmost and Grog and the Adelaide crowd the > southernmost. Put me in the same spot as Eivind (I actually live in Oslo, 15 miles to the north of Ski, but I work in Ski). If you can find the right coordinates for Oslo, put me there instead :) I think tegge also lives in Oslo now, but I'm not sure. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 3:56:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall2.lehman.com (firewall.Lehman.COM [192.147.65.99]) by hub.freebsd.org (Postfix) with ESMTP id ACA7E15223; Tue, 6 Jul 1999 03:56:13 -0700 (PDT) (envelope-from nclayton@lehman.com) Received: from relay3.messaging-svcs5.lehman.com by firewall2.lehman.com (8.8.6/8.8.6) id GAA08944; Tue, 6 Jul 1999 06:56:00 -0400 (EDT) Message-ID: <19990706115526.Z15628@lehman.com> Date: Tue, 6 Jul 1999 11:55:26 +0100 From: Nik Clayton To: chris@calldei.com, Bill Fumerola , doc@freebsd.org Cc: hackers@freebsd.org Subject: Searching the Handbook (was Re: 'rtfm script') References: <19990705141635.D97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990705141635.D97224@holly.dyndns.org>; from Chris Costello on Mon, Jul 05, 1999 at 02:16:36PM -0500 Organization: Lehman Brothers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've added doc@freebsd.org to the distribution list, for obvious reasons. On Mon, Jul 05, 1999 at 02:16:36PM -0500, Chris Costello wrote: > On Mon, Jul 5, 1999, Bill Fumerola wrote: > > I'm in favor of the rtfm script. It's amazing the positive > > things that come out of an offhand IRC comment. > > > > [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] > > > > [15:33] First it'll search the man pages. Then the handbook. Then > > the FAQ. Then, maybe see if I can find out if they start bitching, and if > > so, email Jesus Monroy. > > Note that I can't figure out a decent way to search the > Handbook at this point, but I'm open to ideas. There are a couple of ways you could do it. Some of them more optimal than others. Executive summary: sgrep is probably your best choice now, which can can be found at . But read on for more. The simplest way is to assume that the user has the plain text handbook installed, and do a simple grep through that for what you're looking for. This is nice and easy to do, but doesn't take advantage of the additional smarts built in to the Handbook's native format. To do that requires some additional work. A brief recap for those not au fait with how the Handbook is organised in source form. The Handbook is 'marked up' in a language called DocBook. DocBook was designed specifically for formatting technical documentation, and looks a lot like HTML. However, instead of tags like , ,
    , and so on, DocBook has tags like , , , , , and so forth. A document that is marked up in DocBook therefore contains a lot of additional semantic information about the content (and very little formatting information). When the Handbook is converted to HTML, some of this semantic information is retained. For example, the DocBook source for an example that the user might want to copy verbatim would look like, # rm -rf / and might be converted to HTML that looks like
    # rm -rf /
    Lots more information can be found at http://www.freebsd.org/tutorials/docproj-primer/. A smart searching mechanism will be able to use this additional semantic information to reject (or lower the rankings of) results that don't match what the user wanted. For example, suppose you're searching the Handbook for examples of the make(1) command in action. The simple string "make" occurs lots of times in the Handbook. However, you're only interested in those sections where it occurs *inside* a element; all the other occurences can be ignored. For a simple rtfm(1) style search most of this can probably be ignored, and you can just search the plain text handbook. But even then you might want to provide switches that allow the user to specify: - Only match this word if found in an example - Only match this word if found in a title - Only match this word if found in a command name and so on. How do you do that? Good question. This has been on my list of things to investigate (at the back of my mind) for a while, but more important things have taken my time. If anyone's interested in doing this, here's what I've discovered. You could go the full SGML route. This would involve building an application that can parse the DocBook source of the Handbook (and other articles, and soon to be the FAQ) and allow the user to do their queries using this application. This is probably the most 'correct' route from a purist point of view, but is an awful lot of work. You could go the XML route. XML is the buzzword of the moment, can be thought of as being SGML-Lite. Writing an XML parser is much easier than writing an SGML parser, and you could write an XML aware application could parse the Handbook and other docs, returning results that only appeared inside certain elements. This is still a chunk of work, and the end user will need to keep an XML copy of the documentation somewhere on their disk. Converting from SGML to XML is not a hard problem for our documents though, so at least that hurdle is skipped. For an example of this, check out SCOOBS, at . This is still probably too heavyweight a solution though. *Much* simpler is to build a grep-alike that understands structured documents, but that doesn't care how those documents are structured. This is such a great idea that someone's already done it -- sgrep, which can be found at can search structured text (such as DocBook, HTML, or even mail files). Some examples of sgrep queries; sgrep 'start or "\n" .. (end or "\n") containing "Hello World"' You can define macros in sgrep, so the above could be simplified to sgrep 'LINE containing "Hello World"' If you wanted to find all the From: fields in a Unix mbox file; sgrep '"\nFrom: " .. "\n" extracting ("\n" in "\nFrom: ")' or with macros sgrep 'MAIL_FROM' Print out the title from a collection of HTML documents in which the word "SGML" is mentioned more than 12 times, or which have the word "SGML" inside H1 or H2 elements; sgrep 'HTML_TITLE in (start .. end containing (\ join(12,"SGML") or (HTML_H1 or HTML_H2 containing "SGML") ) )' *.html rtfm(1) could provide a simpler front-end to a series of canned sgrep searches, depending on switches passed to rtfm(1). As you can probably tell, I'm in favour of the sgrep(1) approach, simply because you'll get something working much faster. One caveat though -- the sgrep query language is not standard, and is only implemented by sgrep. There is a proposal going through for something called XQL, the XML Query Language. In the long run, something that supported searching using XQL is likely to be most useful. But in the short-term, sgrep will probably get you up and running quickly. More information about XQL can be found at . If you do a search for "xql" at Google () then you'll turn up all sorts of goodies, including various Perl and Python interfaces to XQL, which might make writing an XQL search system easier. HTH, N -- --+==[ Systems Administrator, Year 2000 Test Lab, Lehman Brothers, Inc. ]==+-- --+==[ 1 Broadgate, London, EC2M 7HA 0171-601-0011 x5514 ]==+-- --+==[ Year 2000 Testing: It's about time. . . ]==+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 4: 0:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id C76EE153D2 for ; Tue, 6 Jul 1999 04:00:02 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Tue, 6 Jul 1999 13:03:05 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Dan Seguin' , Ladavac Marino Cc: FreeBSD Hackers Subject: RE: Connect and so on.. Date: Tue, 6 Jul 1999 12:56:56 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Dan Seguin [SMTP:dseg@texar.com] > Sent: Monday, July 05, 1999 11:22 PM > To: Ladavac Marino > Cc: FreeBSD Hackers > Subject: RE: Connect and so on.. > > > > On Mon, 28 Jun 1999, Ladavac Marino wrote: > > > [ML] If I understand this correctly, only the syscall which is > > being authenticated must block during the authentication. This > makes > > the authentication atomic from the viewpoint of the syscall. The > other > > processes/kernel supported threads may proceed. Sounds like > > RAGF(spelling?) scheme you're doing there. > What you describe above is correctly expresses what I was trying to > say. > > Could you point me to more about this (RAGF) scheme? [ML] I don't know if I have spelled it out correctly, but this is the authentication scheme used on mainframes (IBM at least) where all syscalls are routed through the authentication subsystem before proceeding. However, the subsystem seems to reside in kernel, and is (possibly precompiled) table driven so that it does not cause gross inefficiency. You should ask a local mainframe guru about that. > > > > NFS daemon approach may be feasible for you, because this is > > exactly what it does. You have one central authentication daemon > which > > is blocked in kernel syscall all the time, unless some other process > > (syscall) requests the authentication. The daemon then returns to > user > > space, performs the neccessary authentication, and goes back into > kernel > > with results. This is the way I would implement it, because it > makes > > adding authentication schemes rather simple. > > > > [ML] /Marino > > > > Excellent, thank you. Although, looking through NFS code doesn't sound > like fun. Oh well, time to pay my dues. [ML] Stevens book, or Daemon book may be of some utility. > Something else I need to look into is how to effeciently pass info > back > and forth from kernel space to user space and vice-versa. (See above > for > brief background of what I'm attempting to do). For every syscall > being tracked/authenticated, a record is constructed and needs to be > sent > to the (userland) comms daemon that will send it to another server and > await a response. In the mean time, the process making the syscall is > blocked. > > Understandably this will really cut off process performance at the > knees, > but then again this a proof of concept project. [ML] Regardless of userland/kernel daemon implementation, the real bottleneck is going to be the network latency. Do not expect anything under a millisecond (compared to that, the daemon rescheduling latency of a couple of microseconds is really negligible). > One can easily imagine the processes being blocked starting to backup, > since the comm daemon is competing for processor time, even if every > entry > into the kernel by (arbitrary) tracked syscalls resets the priority of > the > comms daemon to a higher level. (I'm trying to let the daemon get as > much > of the processor as possible to complete what it is doing. It releases > it's quanta whenever it needs to wait for something). [ML] They will backup, since all of them will be waiting on I/O. But it will not be because the authentication daemon is starving them of CPU. In effect, you will have a machine with *really*really* slow syscalls. A more feasible proof of concept would be a table driven authenticator which lives in kernel and provides a syscall for table update. Then, you could call this authentication from a syscall gate glue. One could even imagine a KLD which replaces the syscall table with the authentication table and then calls the original entries. The mainframe practice shows that the auth entries remain pretty static. > The comms daemon would keep a table of records received from the > kernel to > be authenticated, and only mark it as read when it has received a > response > (while being preempted many times), so that at the next arbitrary > tracked > syscall, the kernel would look at this table, look at all the status > word > fields (one per record) and read in the (response) records, if any, > and > mark these slots as unused for later use. > > This table would have to be in userland, with a single byte status > field > for every record. The table would have fixed size records, say 1k per > entry. The seond field holds the PID and the third is free form. The > status field would act as a signal to the kernel that a response was > received. The kernel would read the status and PID and unblock the > process, and either let the syscall proceed or not. Can't use a > restart > here, because, as I understand it, this would create another syscall, > and > hence a loop. > > > Now, what I need to know is what is the best way to move this info > over > the fence, back and forth. Seems copyin() and copyout() are used > throughout kernel code. With a table with fixed size records, I would > simply need to loop through every status byte with copy*(addr + > size(record)) to find out the responses, without (*ahem*) being > interrupted. [ML] memmapping? AFAIK, the kernel has access to the mmaped areas. > Is there an easier/better/more effecient subsystem to use that I don't > know about? > > There are a lot of timing issues here, and I'm sure I've missed some. > The > comms daemon becomes a huge bottleneck for the processes that happen > to > make syscalls that are being tracked, but I don't see a better way. [ML] Don't use one. The RPC and the network latency will kill you. > One of the things that the comm daemon would do is cache a lot of > these > recurring requests so that it wouldn't have to go "outside" to respond > to > the auth request. [ML] Do you have to go outside at all is the relevant question. > Also, if someone can point me to some books/papers/soliloquies of how > to > effeciently manage a shared table, I'd be grateful. [ML] IBM probably has loads of documentation on the topic of kernel enforced syscall authentication. /Marino > 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 Jul 6 4: 2:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 4D40515223 for ; Tue, 6 Jul 1999 04:02:19 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA24567; Tue, 6 Jul 1999 07:01:16 -0400 (EDT) Date: Tue, 6 Jul 1999 07:01:16 -0400 (EDT) From: Daniel Eischen Message-Id: <199907061101.HAA24567@pcnet1.pcnet.com> To: mjacob@feral.com, nick.hibma@jrc.it Subject: Re: CAM: delaying new commands during reset Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma wrote: > > I'm not sure what you mean by 'Busy' here, but it doesn't matter I > > believe- the cam_periph_async called with > > CAM actions come in and initiate one or more USB transfers. When the > action has completed or failed, xpt_done() is called to mark the ccb as > completed. If the command has failed, the umass driver initiates a bus > reset that takes a while to complete. In the meantime CAM tries to > submit new actions that fail because the subsystem is busy. Those > commands have to be delayed until the reset has completed. In this case, you're suppose to use xpt_freeze_simq() or xpt_freeze_devq(). This will stop commands from being issued to the bus (simq) or device (devq) while the bus/device reset is being processed. After the reset, you can then use xpt_release_simq()/xpt_release_devq() to allow commands to be sent once again. During a bus/device queue freeze, I think it is safe to mark pending CCBs to be resent (the xpt layer shouldn't resend them until you unfreeze the queue). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 4: 4:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 0495F1512B; Tue, 6 Jul 1999 04:04:22 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id TAA06155; Tue, 6 Jul 1999 19:26:52 +0900 (JST) Message-Id: <199907061026.TAA06155@rina.naklab.dnj.ynu.ac.jp> To: freebsd-multimedia@freebsd.org, freebsd-hackers@freebsd.org Cc: Seigo Tanimura Subject: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer From: Seigo Tanimura In-Reply-To: Your message of "Tue, 06 Jul 1999 18:59:23 +0900" References: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 06 Jul 1999 19:26:52 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ouch... On Tue, 06 Jul 1999 18:59:23 +0900, Seigo Tanimura said: tanimura> You can try the patch at: tanimura> http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/ tanimura> newmidi-19990706.diff.gz s/patch/patches/ Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 4:17:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id E967B153D3 for ; Tue, 6 Jul 1999 04:17:09 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id NAA15108; Tue, 6 Jul 1999 13:04:58 +0200 (CEST) Message-Id: <199907061104.NAA15108@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: Josef Karthauser Cc: Brian Somers , Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp Reply-To: Gary Jennejohn In-reply-to: Your message of "Tue, 06 Jul 1999 10:59:43 BST." <19990706105943.E9669@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 13:04:58 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Josef Karthauser writes: >On Tue, Jul 06, 1999 at 04:11:39AM +0100, Brian Somers wrote: >> >> ? How about under ``set redial'' in the man page ? >> > >Brian, > >The i4b stuff seems to have some sophisticated costing control code (isdn.rate >s). >It appears that you can define the costs at different times of day and thereby >vary the timeouts, etc. I wonder whether any of this can be adapted for "mode >m ppp". > as I'm sure you're aware, there's a lot of hairy support in the kernel for this mechanism. It wouldn't be exactly trivial to implement for user-ppp, although it could probably be made to work in user space. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 4:30:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 6F8EA14C16 for ; Tue, 6 Jul 1999 04:30:06 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Tue, 6 Jul 1999 13:33:05 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796D4@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Alex Zepeda' , Chris Costello Cc: hackers@FreeBSD.ORG Subject: RE: 'rtfm' script Date: Tue, 6 Jul 1999 13:27:03 +0200 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: Alex Zepeda [SMTP:garbanzo@hooked.net] > Sent: Tuesday, July 06, 1999 4:43 AM > To: Chris Costello > Cc: hackers@FreeBSD.ORG > Subject: Re: 'rtfm' script > > P.S. If you're looking for an easy to use regexp implementation, and > aren't afraid of C++, check out Qt; if you're looking for more of a > challenge, there's always the need for an rtsl(1) ;) [ML] BSD (donated by Henry Spencer) regexp is easy enough to use (RTFM suffices, believe me) and even easier to port to platforms which do not have it in libc[1] /Marino [1] If you ever wondered why Windows applications all use different syntaxes for wildcard searches, if they support them at all, now you know. BTW, it took only two strategic unsigned's to shut the VC++ warnings up--that's all the porting "effort" one needed to spend. > - alex > > > > 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 Jul 6 5: 2:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id B1B0E153A0 for ; Tue, 6 Jul 1999 05:01:45 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id VAA10474; Tue, 6 Jul 1999 21:01:41 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id VAA00725; Tue, 6 Jul 1999 21:01:38 +0900 (JST) Date: Tue, 6 Jul 1999 21:01:38 +0900 (JST) Message-Id: <199907061201.VAA00725@atohasi.mickey.ai.kyutech.ac.jp> To: dmiller@search.sparks.net Cc: freebsd-hackers@freebsd.org Subject: Re: DVD-ram In-Reply-To: Your message of "Wed, 30 Jun 1999 01:18:29 JST". From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, dmiller>>Apologies if this should be on -scsi.... dmiller>> dmiller>>Has anyone done any work with dvd-ram drives under FreeBSD? dmiller>> dmiller>>I will soon need to duplicate dvd-ram media and would very much like to do dmiller>>it under unix. All I need to start with is the ability to read/write the dmiller>>raw device. dmiller>> dmiller>>Currently the drive is recognized as cd0 (FreeBSD 3.2) and I can read a dmiller>>2.x GB side but not, of course, write it. I'm looking at cdrecord for dmiller>>clues but would like not to reinvent someone elses work. dmiller>> dmiller>>Thanks in advance, dmiller>> dmiller>>--- David Akiyama-san who was the auther of od driver for pre-CAM SCSI system has made new od driver for CAM SCSI system. Now the new od driver for FreeBSD-3.2-R is under the testing phase to release. Please wait a while. od1 at adv0 bus 0 target 6 lun 0 od1: Removable Optical SCSI-0 device od1: 4.032MB/s transfers (4.032MHz, offset 8) od1: 121MB (248826 512 byte sectors: 64H 32S/T 121C) cd0 at adv0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at adv0 bus 0 target 4 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present od0 at adv0 bus 0 target 4 lun 0 od0: Removable CD-ROM SCSI-2 device od0: 10.000MB/s transfers (10.000MHz, offset 15) od0: Attempt to query device size failed: NOT READY, Medium not present /dev/od1a 120428 110641 153 100% /mnt /dev/od0a 2399598 2244196 131408 94% /od -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 5:42:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id B376814BB8 for ; Tue, 6 Jul 1999 05:42:38 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac8.wam.umd.edu (root@rac8.wam.umd.edu [128.8.10.148]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA10982; Tue, 6 Jul 1999 08:42:24 -0400 (EDT) Received: from rac8.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac8.wam.umd.edu (8.9.3/8.9.3) with SMTP id IAA06890; Tue, 6 Jul 1999 08:42:24 -0400 (EDT) Received: from localhost by rac8.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA06886; Tue, 6 Jul 1999 08:42:23 -0400 (EDT) X-Authentication-Warning: rac8.wam.umd.edu: howardjp owned process doing -bs Date: Tue, 6 Jul 1999 08:42:23 -0400 (EDT) From: Jamie Howard To: Sheldon Hearn Cc: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <93530.931241617@axl.noc.iafrica.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, 6 Jul 1999, Sheldon Hearn wrote: > The reason I'm suggesting using a port rather than having the code > imported into the base system is that it allows people to "opt in" to > testing it, rather than forcing it down people's throats. The idea is > that, when it's proved itself as a port, enough people will clamor for > its inclusion in the base system for that to become a reality. > > Trying to get software imported directly into the base system without a > trial run as a port is almost always a painful exercise (and I'm not > talking about technical issues here). Ahh, this is a good idea. I have not yet replaced GNU grep on my system with this so it has not yet occurred to me that there might be issues with that. I noticed Jake Burkholder put together a simple port. I'll go ahead and make sure that stays updated. Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 6: 3:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (Postfix) with ESMTP id E0D0514BE5 for ; Tue, 6 Jul 1999 06:03:41 -0700 (PDT) (envelope-from gram@cequrux.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.9.3/8.9.3) id PAA24673; Tue, 6 Jul 1999 15:03:00 +0200 (SAST) Received: by citadel via recvmail id 24608; Tue Jul 6 15:02:06 1999 Message-ID: <3781FF10.A0AF1083@cdsec.com> Date: Tue, 06 Jul 1999 15:05:20 +0200 From: Graham Wheeler Organization: Cequrux Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) MIME-Version: 1.0 To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: Porting LILO to FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wayne Cuddy wrote: > > If he wants to install the shim, it has to be resident on the drive > > somewhere, but that's easy to sort out. It may be better to leave > > the shim (any_d.b) on the FreeBSD partition - LILO relies on it being > > at a known physical location on the disk. Under Windoze, if he ran disk > > defragmenter, he could break the boot. Now that I think of it, I'm > > probably lucky that I have never defragmented my Windoze drive or I > > would most likely have broken my LILO. > > I have, it works fine. I believe that the defrag program is smart enough not > to move those precious bytes from the beginning of the partition. Come to > think of it, if it did the system might not boot even if one wasn't using LILO. I think you're missing part of the picture here: Defrag is smart enough not to touch the first few sectors of the disk, which under DOS include the boot sector, the FATs, and the software interrupt services in IO.SYS and MSDOS.SYS. But the any_d.b LILO shim can be located anywhere on the disk. When you run /etc/lilo it obtains the physical location of any_d.b and patches the lilo map. If defrag relocates the any_d.b file, then booting DOS off a secondary drive should stop working. LILO should still be able to boot any O/S off the primary drive or any O/S that doesn't need a special shim off the secondary. I suspect in your case you weren't trying to boot DOS off the D: drive and thus weren't using the any_d.b shim, or, if you were, your any_d.b shim was in an ext2fs FS on a Linux partition rather than in your DOS filesystem. In my case I had Linux running off a DOS filesystem, and wanted to boot DOS off the D: drive, so I had lilo.conf pointing to the any_d.b file that was in C:\LINUX\BOOT. regards Gram -- Dr Graham Wheeler E-mail: gram@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 7:55:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.globalone.ru (mx.globalone.ru [194.84.254.251]) by hub.freebsd.org (Postfix) with ESMTP id 82CFB14C83 for ; Tue, 6 Jul 1999 07:55:20 -0700 (PDT) (envelope-from a.voropay@globalone.ru) Received: from hq.globalone.ru (hq.globalone.ru [172.16.38.1]) by mx.globalone.ru (8.9.3/8.8.7) with ESMTP id SAA16967 for ; Tue, 6 Jul 1999 18:55:19 +0400 Received: from host205.spb.in.rosprin.ru ([172.17.13.205]) by hq.globalone.ru (Netscape Messaging Server 3.5) with SMTP id 214; Tue, 6 Jul 1999 18:55:26 +0400 Message-ID: <075501bec7bf$eb55c3e0$cd0d11ac@host205.spb.in.rosprin.ru> Reply-To: "Alexander Voropay" From: "Alexander Voropay" To: "Sheldon Hearn" , "Nik Clayton" Cc: Subject: Re: docs/12377: doc patch for login_cap. Date: Tue, 6 Jul 1999 18:54:20 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I'm unfamiliar with the ins and outs of the login_cap system. Could >> someone who is versed in it please take a look at this PR (text included) >> and let me know whether or not the suggested patch is correct. > >Quite often, we receive requests to improve documentation that are born >out of a failure to read that documentation correctly. AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... -- -=AV=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 8:35:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from unix1.it-datacntr.louisville.edu (unix1.it-datacntr.louisville.edu [136.165.4.27]) by hub.freebsd.org (Postfix) with ESMTP id C011814D3B for ; Tue, 6 Jul 1999 08:35:56 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.louisville.edu [136.165.1.20]) by unix1.it-datacntr.louisville.edu (8.8.8/8.8.7) with ESMTP id LAA37954; Tue, 6 Jul 1999 11:35:54 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id LAA23144; Tue, 6 Jul 1999 11:35:54 -0400 (EDT) Message-ID: <19990706113554.B22672@homer.louisville.edu> Date: Tue, 6 Jul 1999 11:35:54 -0400 From: Keith Stevenson To: Alexander Voropay Cc: freebsd-hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. References: <075501bec7bf$eb55c3e0$cd0d11ac@host205.spb.in.rosprin.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <075501bec7bf$eb55c3e0$cd0d11ac@host205.spb.in.rosprin.ru>; from Alexander Voropay on Tue, Jul 06, 1999 at 06:54:20PM +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 06:54:20PM +0400, Alexander Voropay wrote: > > AFAIK, most of login_cap functions could be done via PAM subsystem. > > It's sound very strange to have two different subsystem with too close > functions... Based upon several conversations at USENIX, PAM integration is still a work in progress. John Polstra laid out a lot of the groundwork, but there is still a lot of work left to be done. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 8:42:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hoser.devel (hoser.devel.redhat.com [207.175.42.139]) by hub.freebsd.org (Postfix) with ESMTP id 70CC614D3B for ; Tue, 6 Jul 1999 08:42:10 -0700 (PDT) (envelope-from zab@zabbo.net) Received: from localhost (zab@localhost) by hoser.devel (8.9.3/8.9.3) with ESMTP id LAA28383; Tue, 6 Jul 1999 11:41:35 -0400 X-Authentication-Warning: hoser.devel: zab owned process doing -bs Date: Tue, 6 Jul 1999 11:41:35 -0400 (EDT) From: Zach Brown X-Sender: zab@hoser To: Niall Smart Cc: Jonathan Lemon , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability In-Reply-To: <36E113A5.21F85DE5@pobox.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, how about the kernel passes siginfo and siginfo_cancel events > up to userland, siginfo will remove any siginfo's from its buffer > that it sees a siginfo_cancel event for -- naturally we need a flag > to tell siginfo when to poll for events, this flag would be > set by the function which cancels siginfo's. Would this work? Is > it worth the complexity? sure I imagine it would work, but I'd want to see someone come up for a darn good reason to need it before bogging the system down with a mess like that. at least in my case, some clever hoop-jumping gets rid of the nastiness of having stale events.. keeping the kernel side as light weight as humanly possible should be very high on the list of priorities here. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 9:18:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 57EED15421 for ; Tue, 6 Jul 1999 09:18:21 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id LAA06477; Tue, 6 Jul 1999 11:18:13 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id LAA07877; Tue, 6 Jul 1999 11:18:12 -0500 Message-ID: <19990706111812.31063@right.PCS> Date: Tue, 6 Jul 1999 11:18:12 -0500 From: Jonathan Lemon To: Zach Brown Cc: Niall Smart , Mike Smith , hackers@FreeBSD.ORG Subject: Re: poll() scalability References: <36E113A5.21F85DE5@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Zach Brown on Jul 07, 1999 at 11:41:35AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 11:41:35AM -0400, Zach Brown wrote: > > Well, how about the kernel passes siginfo and siginfo_cancel events > > up to userland, siginfo will remove any siginfo's from its buffer > > that it sees a siginfo_cancel event for -- naturally we need a flag > > to tell siginfo when to poll for events, this flag would be > > set by the function which cancels siginfo's. Would this work? Is > > it worth the complexity? > > sure I imagine it would work, but I'd want to see someone come up for a > darn good reason to need it before bogging the system down with a mess > like that. I wouldn't want to post the events to userland; I think it would be better (and simpler) to handle the aggregation in the kernel. > at least in my case, some clever hoop-jumping gets rid of the nastiness of > having stale events.. keeping the kernel side as light weight as humanly > possible should be very high on the list of priorities here. Currently, I'm thinking along the lines of: 1. create an "event queue" 2. register your interest in various events with this queue. Note that it appears possible to get a little carried away here with specifying exactly what an event is. E.g.: only call it an event after > X bytes have arrived, or only after Y amount of time has passed with no activity, or some combination of the two. This would provide something like the reverse of a "delayed ack", on the receiver side. You could probably even register multiple timer events, and have an arbitrary number of timer events pending. :-) 3. a structure is allocated to handle the event at registration time, and hooked into the appropriate points in the kernel. 4. when an event occurs, instead of just tacking a new structure onto the queue, a kernel callback routine for the type of event specified in step 2 is performed. If it's determined that the event should be posted, the event structure is moved onto the "posted event" queue. If the event structure is already on this queue, no action is needed. 5. when the event is passed to userland, the stucture is dequeued. If the descriptor is closed (or interest unregistered), the structure is simply removed from the queue and deallocated. This should be fairly lightweight, as well as providing flexibility. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 9:36:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id C496B14A0B for ; Tue, 6 Jul 1999 09:36:42 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA09966; Tue, 6 Jul 1999 09:36:41 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA15322; Tue, 6 Jul 1999 09:36:41 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 6 Jul 1999 09:36:41 -0700 (PDT) Message-Id: <199907061636.JAA15322@vashon.polstra.com> To: archie@whistle.com Subject: Re: poll() vs select() In-Reply-To: <199907050103.SAA51932@bubba.whistle.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907050103.SAA51932@bubba.whistle.com>, Archie Cobbs wrote: > > A new, faster event notification system would be great. But don't forget > to include *all* events, not just file descriptor readability/writability. Yes! Yes! Yes! (I agree.) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 9:45: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0643E14D8C; Tue, 6 Jul 1999 09:45:00 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA09995; Tue, 6 Jul 1999 09:45:00 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA15384; Tue, 6 Jul 1999 09:44:59 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 6 Jul 1999 09:44:59 -0700 (PDT) Message-Id: <199907061644.JAA15384@vashon.polstra.com> To: green@freebsd.org Subject: Re: poll() vs select() In-Reply-To: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Brian F. Feldman wrote: > On Sun, 4 Jul 1999, Archie Cobbs wrote: > > > A new, faster event notification system would be great. But don't forget > > to include *all* events, not just file descriptor readability/writability. > > I.e., signal delivery, child exit notification, maybe even support for > > an arbitrary number of (independent) timers. And make the events independent > > from each other -- to avoid problems like when an application completely > > hangs for 90 seconds when it calls gethostbyname(). > > An async thread to do hostname lookups would be great! Wouldn't be too > hard in libc_r, would it? The application itself has to get involved if it wants to do async name lookups, or async anything else, for that matter. Suppose you do have an async thread to do hostname lookups as you propose. What is the application going to do while that thread is waiting for the lookup to complete? It depends on the application, and thus it has to be coded into the application. Maybe there's nothing useful the application could do until the lookup returns. I've been told that it works fine to use libc_r and put the name lookups into a separate thread. But to take advantage of it, the application has to have something useful it wants to do (and can do) in the meantime. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 9:56:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 9BDBE14C4E for ; Tue, 6 Jul 1999 09:56:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id JAA00454; Tue, 6 Jul 1999 09:52:12 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907061652.JAA00454@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ladavac Marino Cc: "'Dan Seguin'" , FreeBSD Hackers Subject: Re: Connect and so on.. In-reply-to: Your message of "Tue, 06 Jul 1999 12:56:56 +0200." <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 09:52:12 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > processes/kernel supported threads may proceed. Sounds like > > > RAGF(spelling?) scheme you're doing there. > > What you describe above is correctly expresses what I was trying to > > say. > > > > Could you point me to more about this (RAGF) scheme? > [ML] I don't know if I have spelled it out correctly, but this > is the authentication scheme used on mainframes (IBM at least) where all > syscalls are routed through the authentication subsystem before > proceeding. However, the subsystem seems to reside in kernel, and is > (possibly precompiled) table driven so that it does not cause gross > inefficiency. RACF IIRC, often pronounced "Rack Off". -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ 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 Jul 6 9:59:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id CA2DA14CFB for ; Tue, 6 Jul 1999 09:59:47 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA10052; Tue, 6 Jul 1999 09:59:45 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA15453; Tue, 6 Jul 1999 09:59:45 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 6 Jul 1999 09:59:45 -0700 (PDT) Message-Id: <199907061659.JAA15453@vashon.polstra.com> To: andrey@agama.com Subject: Re: Dynamic linking In-Reply-To: <3780AEB2.206160E0@agama.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <3780AEB2.206160E0@agama.com>, Andrew Iltchenko wrote: > Hi everyone! > > Is there a way of making dlopen return an error from the shared object's > _init function? No. The _init function by definition is "void _init(void)", and so it cannot return a value. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10: 0: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak2.texar.com (unknown [216.208.160.130]) by hub.freebsd.org (Postfix) with ESMTP id EDC0D15049 for ; Tue, 6 Jul 1999 10:00:01 -0700 (PDT) (envelope-from dseg@pak2.texar.com) Received: from localhost (dseg@localhost) by pak2.texar.com (8.9.2/8.8.3) with ESMTP id NAA12320; Tue, 6 Jul 1999 13:03:19 -0400 (EDT) Date: Tue, 6 Jul 1999 13:03:15 -0400 (EDT) From: Dan Seguin To: Ladavac Marino Cc: FreeBSD Hackers Subject: RE: Connect and so on.. In-Reply-To: <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at> 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, 6 Jul 1999, Ladavac Marino wrote: > [ML] Regardless of userland/kernel daemon implementation, the > real bottleneck is going to be the network latency. Do not expect > anything under a millisecond (compared to that, the daemon rescheduling > latency of a couple of microseconds is really negligible). Of course. We knew the network latency would be the problem from the beginning. But the rescheduling might be an issue when a sufficient amount of request caching has been achieved. > > > One can easily imagine the processes being blocked starting to backup, > > since the comm daemon is competing for processor time, even if every > > entry > > into the kernel by (arbitrary) tracked syscalls resets the priority of > > the > > comms daemon to a higher level. (I'm trying to let the daemon get as > > much > > of the processor as possible to complete what it is doing. It releases > > it's quanta whenever it needs to wait for something). > [ML] They will backup, since all of them will be waiting on > I/O. But it will not be because the authentication daemon is starving > them of CPU. You're right, but that's not what I was thinking. I guess I didn't state it very clearly. What I meant to convey was this: since the processes are blocked awaiting authentication, they cannot proceed until the comm server receives a response. They are not being starved because of the daemon, they were explicitly turned "off" until such a time as the daemon can instruct the kernel to unblock them. In essence, I want to make sure that the daemon is made to wait as little as possible for whatever reason, be it pre-emption, or resource allocation. It'll be waiting long enough on the network. In effect, you will have a machine with *really*really* > slow syscalls. A more feasible proof of concept would be a table driven > authenticator which lives in kernel and provides a syscall for table > update. Then, you could call this authentication from a syscall gate > glue. One could even imagine a KLD which replaces the syscall table > with the authentication table and then calls the original entries. The > mainframe practice shows that the auth entries remain pretty static. This is essentially what I've done. Replaced syscalls with a flow through syscall of my own. Couple this with the caching mentioned in the previous post and we'll get to a point where the request may never need to go further than the local table. If an entry is not chached, then the comm daemon will unevitably have to pass it on to the central server. > > > Is there an easier/better/more effecient subsystem to use that I don't > > know about? > > > > There are a lot of timing issues here, and I'm sure I've missed some. > > The > > comms daemon becomes a huge bottleneck for the processes that happen > > to > > make syscalls that are being tracked, but I don't see a better way. > [ML] Don't use one. The RPC and the network latency will kill > you. *sigh*. I know, I know... > [ML] Do you have to go outside at all is the relevant question. > Yes. > > Also, if someone can point me to some books/papers/soliloquies of how > > to > > effeciently manage a shared table, I'd be grateful. > [ML] IBM probably has loads of documentation on the topic of > kernel enforced syscall authentication. > > /Marino Thanks! You've been a great help and sounding board. Dan Seguin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10: 5: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 6A5FA14E01 for ; Tue, 6 Jul 1999 10:05:02 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id KAA10093; Tue, 6 Jul 1999 10:05:00 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA15507; Tue, 6 Jul 1999 10:04:59 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 6 Jul 1999 10:04:59 -0700 (PDT) Message-Id: <199907061704.KAA15507@vashon.polstra.com> To: kbyanc@alcnet.com Subject: Re: mmap question In-Reply-To: <000101bec73c$e20e3660$291c453f@kbyanc.alcnet.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <000101bec73c$e20e3660$291c453f@kbyanc.alcnet.com>, Kelly Yancey wrote: > > Also, in case it hasn't been notice already (I'm running -stable from May > 18th), the mmap(2) manpage has a typo: it has "#include " So what's the typo, exactly? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10: 7:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 0C96614CFB for ; Tue, 6 Jul 1999 10:07:21 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id MAA06716; Tue, 6 Jul 1999 12:07:21 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id MAA15754; Tue, 6 Jul 1999 12:07:20 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id MAA27353; Tue, 6 Jul 1999 12:07:19 -0500 (CDT) Date: Tue, 6 Jul 1999 12:07:19 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907061707.MAA27353@free.pcs> To: jdp@polstra.com, hackers@freebsd.org Subject: Re: poll() vs select() X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >In article <199907050103.SAA51932@bubba.whistle.com>, >Archie Cobbs wrote: >> >> A new, faster event notification system would be great. But don't forget >> to include *all* events, not just file descriptor readability/writability. > >Yes! Yes! Yes! (I agree.) There was another message in this thread indicating that this has the potential to grow creeping featuritis. :-) I've been thinking this over, and unlimited timers should be easy to do. I suppose you could fold signal delivery into an event notification mechanism as well. What other events are on the various wishlists out there? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:18:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 0CCD014BD7 for ; Tue, 6 Jul 1999 10:18:56 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id KAA05148; Tue, 6 Jul 1999 10:18:48 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 6 Jul 1999 10:18:47 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Chris Costello Cc: Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script In-Reply-To: <19990705171705.E97224@holly.dyndns.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 I'm confused about this script. How does it differ from 'apropos'? Feeling a little dense, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:23:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id BFB0614C46; Tue, 6 Jul 1999 10:23:47 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA68449; Tue, 6 Jul 1999 11:13:14 -0600 (MDT) Date: Tue, 6 Jul 1999 11:13:14 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907061713.LAA68449@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This stuff should really go to the SCSI list. I read that list much more frequently than this one. > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB > part of the drive). It takes 1s or more to reset. The reset is initiated > because for example an illegal command was received (sync cache for > example). The hard coded reset delay in there is quite crude. You should just call xpt_freeze_devq() for that device and then release the queue from a timeout handler. In general, the peripheral drivers will wait until after a bus settle delay anyway, but the only way to ensure this delay is to freeze the queue. > The problem is that the reset is initiated and the command that failed > xpt_done()-d with an error. All ccbs that have an error status set should cause the device queue to be frozen and the CAM_DEV_QFRZN flag should be set in the cam status field of the CCB. If you don't freeze the queue, the peripheral driver cannot perform error recovery in a consistant way. It also looks like all umass I/O is blocking/polling. Since this can occur from a SWI, this is pretty bad to do. Is there no alternative? It also appears that this driver has a very limited error code vocabulary. Is that because the transport or device gives little information about errors? > What would be the proper approach to make the ccb delay until the reset > has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or > store the ccb and process it when the reset is done? CAM_REQUEUE_REQ is for commands that have been queued in the SIM but have never been sent to a device. The error modle goes something like this: All ccbs with non-zero status should cause the device queue to be frozen and the CAM_DEV_QFRZN flag set in the status word. When an error occurrs: Return all queued CCBs that match the device(s) affected by the error with CAM_REQUEUE_REQ status. Return any 'invalidated' commands (commands that were on the device but have been thrown out in response to this error) with the correct error status (CAM_BUS_RESET, CAM_BDR_SENT, etc.) Return any commands that have completed with an error with the apropriate error code (CAM_UNCOR_PARIY, CAM_SCSI_STATUS_ERROR, CAM_DATA_RUN_ERR, etc.) If you require a specific amount of recovery time, freeze the device or simq and schedule a timeout to release the queue. An underrun is not an error. If a ccb is returned with no error codes set, the residual will be examined, so you must set the residual on all completed commands. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:25: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 50E2214C84 for ; Tue, 6 Jul 1999 10:25:02 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA85126; Tue, 6 Jul 1999 11:24:28 -0600 (MDT) (envelope-from ken) Message-Id: <199907061724.LAA85126@panzer.kdm.org> Subject: Re: DVD-ram In-Reply-To: <199907061201.VAA00725@atohasi.mickey.ai.kyutech.ac.jp> from Takeshi OHASHI at "Jul 6, 1999 09:01:38 pm" To: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) Date: Tue, 6 Jul 1999 11:24:28 -0600 (MDT) Cc: dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (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 Takeshi OHASHI wrote... > Hi folks, > > dmiller>>Apologies if this should be on -scsi.... > dmiller>> > dmiller>>Has anyone done any work with dvd-ram drives under FreeBSD? > dmiller>> > dmiller>>I will soon need to duplicate dvd-ram media and would very much like to do > dmiller>>it under unix. All I need to start with is the ability to read/write the > dmiller>>raw device. > dmiller>> > dmiller>>Currently the drive is recognized as cd0 (FreeBSD 3.2) and I can read a > dmiller>>2.x GB side but not, of course, write it. I'm looking at cdrecord for > dmiller>>clues but would like not to reinvent someone elses work. > dmiller>> > dmiller>>Thanks in advance, > dmiller>> > dmiller>>--- David > > Akiyama-san who was the auther of od driver for pre-CAM SCSI system > has made new od driver for CAM SCSI system. > > Now the new od driver for FreeBSD-3.2-R is under the testing phase to > release. Please wait a while. > > od1 at adv0 bus 0 target 6 lun 0 > od1: Removable Optical SCSI-0 device > od1: 4.032MB/s transfers (4.032MHz, offset 8) > od1: 121MB (248826 512 byte sectors: 64H 32S/T 121C) > cd0 at adv0 bus 0 target 3 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 3.300MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > cd1 at adv0 bus 0 target 4 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 10.000MB/s transfers (10.000MHz, offset 15) > cd1: Attempt to query device size failed: NOT READY, Medium not present > od0 at adv0 bus 0 target 4 lun 0 > od0: Removable CD-ROM SCSI-2 device > od0: 10.000MB/s transfers (10.000MHz, offset 15) > od0: Attempt to query device size failed: NOT READY, Medium not present > > /dev/od1a 120428 110641 153 100% /mnt > /dev/od0a 2399598 2244196 131408 94% /od Just out of curiosity, what problems are you trying to solve here? It looks like you have a DVD drive probing as an OD drive, and a MO drive probing as an OD drive. IMO, DVD drives are probably best handled through the CD driver, and Optical drives are probably best handled through the DA driver. The CD driver doesn't currently handle writes, but it's a one-line fix to change that. I'd like to hear what your rationale for a separate driver is, though. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:28:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 292B214C46 for ; Tue, 6 Jul 1999 10:28:52 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id NAA04616; Tue, 6 Jul 1999 13:28:37 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 13:28:37 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: John Polstra Cc: hackers@FreeBSD.org Subject: Re: poll() vs select() In-Reply-To: <199907061644.JAA15384@vashon.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 On Tue, 6 Jul 1999, John Polstra wrote: > In article , > > The application itself has to get involved if it wants to do async > name lookups, or async anything else, for that matter. Suppose you > do have an async thread to do hostname lookups as you propose. What > is the application going to do while that thread is waiting for the > lookup to complete? It depends on the application, and thus it has > to be coded into the application. Maybe there's nothing useful the > application could do until the lookup returns. > > I've been told that it works fine to use libc_r and put the name > lookups into a separate thread. But to take advantage of it, the > application has to have something useful it wants to do (and can do) > in the meantime. It would let the other threads run more while the lookup is occurring. Wouldn't that be the most natural expectation of it? Or would this be too hard without kernel-assisted threading? > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "No matter how cynical I get, I just can't keep up." -- Nora Ephron > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Tue Jul 6 10:32:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 3FCF514EE9 for ; Tue, 6 Jul 1999 10:32:24 -0700 (PDT) (envelope-from justin@walker3.apple.com) Received: from mailgate1.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 KAA27110 for ; Tue, 6 Jul 1999 10:32:10 -0700 Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Tue, 06 Jul 1999 10:13:41 -0700 Received: from walker3.apple.com (walker3.apple.com [17.219.24.201]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA26904; Tue, 6 Jul 1999 10:13:40 -0700 Received: (from justin@localhost) by walker3.apple.com (8.9.1/8.9.1) id KAA00667; Tue, 6 Jul 1999 10:13:45 -0700 (PDT) Message-Id: <199907061713.KAA00667@walker3.apple.com> To: John Polstra Subject: Re: poll() vs select() Cc: archie@whistle.com, hackers@freebsd.org In-Reply-To: <199907050103.SAA51932@bubba.whistle.com> Date: Tue, 6 Jul 1999 10:13:42 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: John Polstra > Date: 1999-07-06 09:36:51 -0700 > To: archie@whistle.com > Subject: Re: poll() vs select() > Cc: hackers@FreeBSD.ORG > In-reply-to: <199907050103.SAA51932@bubba.whistle.com> > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > Organization: Polstra & Co., Seattle, WA > > In article <199907050103.SAA51932@bubba.whistle.com>, > Archie Cobbs wrote: > > > > A new, faster event notification system would be great. But don't forget > > to include *all* events, not just file descriptor readability/writability. > > Yes! Yes! Yes! (I agree.) To add to the confusion, we've implemented something very similar for Mac OS X Server, designed to be a replacement for select(), and for use in a similar way to select's use in existing code. You can see it in the Darwin code. Check out "sys/ev.h" for a typically terse description of the API. In the released Darwin source, the code deals only with sockets. The Darwin release that deals with Mac OS X (possibly by fall) should have a more involved design that deals with a number of different kinds of events, including Mach messages (not a big deal for this group, of course). See www.publicsource.apple.com and follow the links to Darwin OS. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:33:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 8A09C14F68; Tue, 6 Jul 1999 10:33:17 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id KAA10337; Tue, 6 Jul 1999 10:33:16 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA15634; Tue, 6 Jul 1999 10:33:16 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [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: Tue, 06 Jul 1999 10:33:16 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: "Brian F. Feldman" Subject: Re: poll() vs select() Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian F. Feldman wrote: > On Tue, 6 Jul 1999, John Polstra wrote: > >> In article , >> >> The application itself has to get involved if it wants to do async >> name lookups, or async anything else, for that matter. Suppose you >> do have an async thread to do hostname lookups as you propose. What >> is the application going to do while that thread is waiting for the >> lookup to complete? It depends on the application, and thus it has >> to be coded into the application. Maybe there's nothing useful the >> application could do until the lookup returns. >> >> I've been told that it works fine to use libc_r and put the name >> lookups into a separate thread. But to take advantage of it, the >> application has to have something useful it wants to do (and can do) >> in the meantime. > > It would let the other threads run more while the lookup is occurring. > Wouldn't that be the most natural expectation of it? Or would this > be too hard without kernel-assisted threading? What I'm saying is, we already have that in multi-threaded applications. The system can't just provide it automatically to single-threaded applications; they wouldn't know how to take advantage of it. In other words: * Multi-threaded applications already have it. * Single-threaded applications can't use it. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 10:56:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0E46E14FC2 for ; Tue, 6 Jul 1999 10:56:45 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id KAA07127; Tue, 6 Jul 1999 10:56:11 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA20904; Tue, 6 Jul 1999 10:56:12 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA18760; Tue, 6 Jul 99 10:56:09 PDT Message-Id: <37824338.4A65506E@softweyr.com> Date: Tue, 06 Jul 1999 11:56:08 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Ladavac Marino Cc: "'Dan Seguin'" , FreeBSD Hackers Subject: Re: Connect and so on.. References: <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ladavac Marino wrote: > > > -----Original Message----- > > From: Dan Seguin [SMTP:dseg@texar.com] > > Sent: Monday, July 05, 1999 11:22 PM > > To: Ladavac Marino > > Cc: FreeBSD Hackers > > Subject: RE: Connect and so on.. > > > > > > > > On Mon, 28 Jun 1999, Ladavac Marino wrote: > > > > > [ML] If I understand this correctly, only the syscall which is > > > being authenticated must block during the authentication. This > > > makes the authentication atomic from the viewpoint of the syscall. > > > The other processes/kernel supported threads may proceed. Sounds like > > > RAGF(spelling?) scheme you're doing there. > > > > What you describe above is correctly expresses what I was trying to > > say. > > > > Could you point me to more about this (RAGF) scheme? > > [ML] I don't know if I have spelled it out correctly, but this > is the authentication scheme used on mainframes (IBM at least) where all > syscalls are routed through the authentication subsystem before > proceeding. However, the subsystem seems to reside in kernel, and is > (possibly precompiled) table driven so that it does not cause gross > inefficiency. > > You should ask a local mainframe guru about that. RACF. Remote Access Control Facility, IIRC. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:12: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from itchy.serv.net (itchy.serv.net [205.153.153.233]) by hub.freebsd.org (Postfix) with ESMTP id 52F8B14FE1; Tue, 6 Jul 1999 11:11:54 -0700 (PDT) (envelope-from utz@itchy.serv.net) Received: from localhost (utz@localhost) by itchy.serv.net (8.8.5/8.8.5) with SMTP id LAA26361; Tue, 6 Jul 1999 11:13:01 -0700 (PDT) Date: Tue, 6 Jul 1999 11:12:59 -0700 (PDT) From: The Utz Family To: Seigo Tanimura Cc: freebsd-multimedia@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer In-Reply-To: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> 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 this is really cool, and i look forward to making use to this. (perhaps it might be time to change the name of the patch subdir from serial-midi to something else?) thankyou so much for your diligent efforts! On Tue, 6 Jul 1999, Seigo Tanimura wrote: > Hi! > > > MPU401, the most widely-used midi interface now works under > my midi driver framework. Another new thing is a fine timer > at a period of 156us, called directly from hardclock(). > > You can try the patch at: > http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/ > newmidi-19990706.diff.gz > > The instruction is at: > http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/ > > > Here is the introduction of my new timer: > > Unlike 16550, MPU401 does not generate an interrupt on TX-ready. > So we have to choose one of the following two options to drive > MPU401: > > A. polling the status to wait until TX-ready, > B. emulating a TX-ready interrupt by a timer. > > The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()), > consumes most of syscall time to wait for MPU401 to come TX-ready. > One byte of midi message takes 0.32ms to transmit. Some certain midi > sequences contain continuous long sysexes summed up to 200 bytes or > more, leaving a latency of 0.32 * 200 = 60ms or something like that. > This latency results in an unstable tempo. > > I have chosen the option B to eliminate the latency on message > transmission. In this case, the timer needs to be capable of a period > less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s], > which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems > to shorten the period of timeout(9) enough, many parts of the kernel > would be affected by this change, likely to end up with poor stability. > > To solve this problem, I propose a new *fine* callout mechanism. > The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where > (1 << hzmul) is the mutiplication ratio of hz. Although the ratio can > be any natural number in theory, I have chosen the power of two to > reduce the computational cost of the clock divider. (discussed later) > > As desceribed above, (for i386) clkintr() is called at > (hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency. > hardclock() has two elements in it: a callout detector and a clock > divider. A callout detector traverses the callout list and makes > a callout, as in softclock(), except that the IPL stays at splclock. > A clock divider reduces the frequency to hz[Hz], to process the > conventional hardclock(), which is now renamed to hardclock1(), and > softclock(). Although dividing a clock tick generally involves a > costing division operation of the dividor counter by (1 << hzmul), > a ratio of 2^n allows us to replace the operation with a simple > shift of (clkdiv >> hzmul), where clkdiv is the dividor counter > incremented one by one on a hardclock(). > > Fig 1 shows the frequency and the IPL of the new timer handlers. > > > Frequency IPL > Timer ^ ^ > Generator | | > | | | > v (hz * (1 << hzmul))[Hz] splclock > clkintr() | | > | | | > v v v > hardclock() -> Fine ________________________________________ > | Callouts ^ ^ > v | | > hardclock1() | | > | hz[Hz] splsoftclock > v | | > softclock() -> Conventional | | > Callouts v v > > Fig 1: Call Frequency and IPL under New Timer Handling > > > I have implemented the new fine callout system discussed above > in the latest patch of my midi driver. hzmul is 6, to multiply the > timer frequency to 6400Hz. The usage of the fine callout is the same > as timeout(9), except for the prefix of fine-, and that the granularity > of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done > any quantitative evaluation yet, I played some midi sequences with > sysex messages to show a picture on the LCD of my SC-88, recognizing > no latency like VoxWare. This result states the effectiveness of my > proposing fine callout system. The future works include porting to > alpha and PC98, and tuning hzmul. > > > Whew, that was some kind of a paper to write! I would be pleased > very much if you let me know how you think of my idea. > > Thanks in advance! > > > Seigo Tanimura > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-multimedia" 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 Jul 6 11:20:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 03B8414F88 for ; Tue, 6 Jul 1999 11:20:05 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 3905 invoked from network); 6 Jul 1999 18:20:05 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 6 Jul 1999 18:20:05 -0000 Date: Tue, 6 Jul 1999 11:19:54 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Where are the Disk on Chip drivers? 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 got a DOC2K in, and am anxious to play with it. I know Poul had done some work with it, but his web page doesn't have a link to it, and I cannot find his original email. The reference in freebsd-small doesn't contain an URL... Any help appreciated. I want to run under 3.2-stable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:24:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from at.dotat.com (zed.dotat.com [203.2.134.254]) by hub.freebsd.org (Postfix) with ESMTP id 4380114D3B for ; Tue, 6 Jul 1999 11:24:29 -0700 (PDT) (envelope-from hart@at.dotat.com) Received: from at.dotat.com (localhost.dotat.com [127.0.0.1]) by at.dotat.com (8.8.8/8.8.8) with ESMTP id DAA02006; Wed, 7 Jul 1999 03:57:51 +0930 (CST) Message-Id: <199907061827.DAA02006@at.dotat.com> To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Where are the Disk on Chip drivers? In-reply-to: Your message of "Tue, 06 Jul 1999 11:19:54 MST." Date: Wed, 07 Jul 1999 03:57:50 +0930 From: Leigh Hart Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Jaye, All of the DOC stuff I've played with has usually had an IDE style interface associated with it - I may be way off track here tho...? Jaye Mathisen wrote: > > I just got a DOC2K in, and am anxious to play with it. I know Poul > had done some work with it, but his web page doesn't have a link to > it, and I cannot find his original email. > > The reference in freebsd-small doesn't contain an URL... > > Any help appreciated. > > I want to run under 3.2-stable. Cheers Leigh -- | "By the time they had diminished | Leigh Hart, | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:25:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from medulla.hippocampus.net (medulla.hippocampus.net [204.138.241.6]) by hub.freebsd.org (Postfix) with ESMTP id 462BF14D3B for ; Tue, 6 Jul 1999 11:25:35 -0700 (PDT) (envelope-from marc@netstor.com) Received: from localhost (marc@localhost) by medulla.hippocampus.net (8.9.2/8.9.2) with ESMTP id OAA06242; Tue, 6 Jul 1999 14:31:25 -0400 (EDT) Date: Tue, 6 Jul 1999 14:31:25 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Where are the Disk on Chip drivers? 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 http://phk.freebsd.dk/doc2k/ Linked from http://www.freebsd.org/~picobsd. -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com "Fast, Expandable and Affordable Internet Caching Products" 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 On Tue, 6 Jul 1999, Jaye Mathisen wrote: > > > I just got a DOC2K in, and am anxious to play with it. I know Poul had > done some work with it, but his web page doesn't have a link to it, and I > cannot find his original email. > > The reference in freebsd-small doesn't contain an URL... > > Any help appreciated. > > I want to run under 3.2-stable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:26:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 2237115006 for ; Tue, 6 Jul 1999 11:26:23 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 92CD7370C4; Tue, 6 Jul 1999 14:26:17 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id NAA06822; Tue, 6 Jul 1999 13:25:05 -0500 (CDT) (envelope-from chris) Date: Tue, 6 Jul 1999 13:24:55 -0500 From: Chris Costello To: Doug Cc: Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990706132455.E4158@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705171705.E97224@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Doug on Tue, Jul 06, 1999 at 10:18:47AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 6, 1999, Doug wrote: > I'm confused about this script. How does it differ from 'apropos'? It differs in that it _uses_ apropos (or 'whatis' if you specify the -e flag), as well as a Texinfo search, as well as a FAQ search, using the FAQ pages at http://www.freebsd.org/FAQ/. It's meant to be an information center for those just getting started with FreeBSD. > Doug -- Chris Costello It's 10 o'clock. Do you know where your child processes are? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:27:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from medulla.hippocampus.net (medulla.hippocampus.net [204.138.241.6]) by hub.freebsd.org (Postfix) with ESMTP id BCFC414D8C for ; Tue, 6 Jul 1999 11:27:20 -0700 (PDT) (envelope-from marc@netstor.com) Received: from localhost (marc@localhost) by medulla.hippocampus.net (8.9.2/8.9.2) with ESMTP id OAA06259; Tue, 6 Jul 1999 14:33:00 -0400 (EDT) Date: Tue, 6 Jul 1999 14:33:00 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: Leigh Hart Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Where are the Disk on Chip drivers? In-Reply-To: <199907061827.DAA02006@at.dotat.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 Leigh: PHK wrote a driver (under the watchful eye of M-Systems) for the "true" DOCs that have a BIOS driver to make them look like a disk rather than an IDE interface. That's what Jaye is referring to... -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com "Fast, Expandable and Affordable Internet Caching Products" 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 On Wed, 7 Jul 1999, Leigh Hart wrote: > Hi Jaye, > > All of the DOC stuff I've played with has usually had an IDE style > interface associated with it - I may be way off track here tho...? > > Jaye Mathisen wrote: > > > > I just got a DOC2K in, and am anxious to play with it. I know Poul > > had done some work with it, but his web page doesn't have a link to > > it, and I cannot find his original email. > > > > The reference in freebsd-small doesn't contain an URL... > > > > Any help appreciated. > > > > I want to run under 3.2-stable. > > Cheers > > Leigh > -- > | "By the time they had diminished | Leigh Hart, | > | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | > | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | > | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | > > > 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 Jul 6 11:32: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DA3A2150E3 for ; Tue, 6 Jul 1999 11:31:58 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA05822; Tue, 6 Jul 1999 14:31:38 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 14:31:38 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Chris Costello Cc: Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script In-Reply-To: <19990706132455.E4158@holly.dyndns.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 Tue, 6 Jul 1999, Chris Costello wrote: > On Tue, Jul 6, 1999, Doug wrote: > > I'm confused about this script. How does it differ from 'apropos'? > > It differs in that it _uses_ apropos (or 'whatis' if you > specify the -e flag), as well as a Texinfo search, as well as a > FAQ search, using the FAQ pages at http://www.freebsd.org/FAQ/. > It's meant to be an information center for those just getting > started with FreeBSD. RTFM isn't a newby-apparent term. Name it help(1). > > > Doug > > -- > Chris Costello > It's 10 o'clock. Do you know where your child processes are? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Tue Jul 6 11:42:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 9597F15003 for ; Tue, 6 Jul 1999 11:42:27 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA12538 for freebsd-hackers@freebsd.org; Tue, 6 Jul 1999 13:42:26 -0500 (CDT) From: Mohit Aron Message-Id: <199907061842.NAA12538@cs.rice.edu> Subject: paper on improving Webserver performance To: freebsd-hackers@freebsd.org Date: Tue, 6 Jul 1999 13:42:26 -0500 (CDT) 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 Hi, I'd like to tell the FreeBSD community about my recent paper that proposes some TCP implementation techniques for improving Webserver performance. I used FreeBSD for my study and I thought perhaps FreeBSD's TCP maintainers might like to incorporate some of the propositions in FreeBSD. The abstract of the paper is attached below and the paper is available from: http://cs-tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR99-335/ - Mohit Aron aron@cs.rice.edu Abstract: This paper studies the performance of BSD-based TCP implementations in Web servers. We find that lack of scalability with respect to high TCP connection rates reduces the throughput of Web servers by up to 25% and imposes a memory overhead of up to 32 MB on the kernel. We also find that insufficient accuracy in TCP's timers results in overly conservative delays for retransmission timeouts, causing poor response time, low network utilization and throughput loss. The paper proposes enhancements to the TCP implementation that eliminate these problems, without requiring changes to the protocol or the API. We also find that conventional benchmark environments do not fully expose certain significant performance aspects of TCP implementations and propose techniques that allow these benchmarks to more accurately predict the performance of real servers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:48:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id B3AEF14EF0; Tue, 6 Jul 1999 11:48:45 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id E34DA3708F; Tue, 6 Jul 1999 14:48:42 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id NAA06949; Tue, 6 Jul 1999 13:47:40 -0500 (CDT) (envelope-from chris) Date: Tue, 6 Jul 1999 13:47:39 -0500 From: Chris Costello To: "Brian F. Feldman" Cc: Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script Message-ID: <19990706134739.G4158@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990706132455.E4158@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Brian F. Feldman on Tue, Jul 06, 1999 at 02:31:38PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 6, 1999, Brian F. Feldman wrote: > RTFM isn't a newby-apparent term. Name it help(1). That would cause problems with bash users. They already have a builtin help command. -- Chris Costello On a clear disk you can seek forever. - Denning To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 11:52:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CF4D715003 for ; Tue, 6 Jul 1999 11:52:19 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA06178; Tue, 6 Jul 1999 14:52:08 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 14:52:08 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Chris Costello Cc: Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script In-Reply-To: <19990706134739.G4158@holly.dyndns.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 Tue, 6 Jul 1999, Chris Costello wrote: > On Tue, Jul 6, 1999, Brian F. Feldman wrote: > > RTFM isn't a newby-apparent term. Name it help(1). > > That would cause problems with bash users. They already have > a builtin help command. Which can be disabled in the bash port before the next release... help(1) is really a much more appropriate name. > > -- > Chris Costello > On a clear disk you can seek forever. - Denning > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Tue Jul 6 12:25:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 4356C14FEF for ; Tue, 6 Jul 1999 12:25:26 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id OAA07425; Tue, 6 Jul 1999 14:25:25 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id OAA10465; Tue, 6 Jul 1999 14:25:24 -0500 Message-ID: <19990706142523.38487@right.PCS> Date: Tue, 6 Jul 1999 14:25:23 -0500 From: Jonathan Lemon To: Brian Dean Cc: freebsd-hackers@freebsd.org Subject: Re: support for i386 hardware debug watch points References: <199907041554.KAA22328@free.pcs> <199907060225.WAA08230@dean.pc.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199907060225.WAA08230@dean.pc.sas.com>; from Brian Dean on Jul 07, 1999 at 10:25:12PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 10:25:12PM -0400, Brian Dean wrote: > OK, I did that. What is the convention for naming the flags? The > only one in use for that set of flags is FP_SOFTFP. I'm currently > using PCB_DBREGS, but I but I easily change the name to whatever > convention dictates - please advise. Whatever you think is appropriate, and that Bruce doesn't complain about. The name you picked is fine with me. > Here's a question: Are there any security concerns with being able to > update the debug registers? Should a process be able to set a > breakpoint inside the kernel, for example? In such a case, an INT 3 > exception would be generated from within kernel code. Would this drop > the system into the kernel debugger if it was enabled? If I've If a breakpoint is set in the kernel, and is hit in kernel mode, it will cause a breakpoint fault in kernel mode. This will drop into ddb (if enabled). Is it possible (when setting the debug registers) to check that the breakpoint is being set in user space? This should be fairly simple; just check the va against VM_MAXUSER_ADDRESS. However, interpreting the contents of the debug registers is MD code, and should probably wind up in a short routine inside i386/sys_machdep.c, the alpha would have their own version of this. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13: 1:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-33.ppp.wenet.net [206.15.85.33]) by hub.freebsd.org (Postfix) with ESMTP id 7C83A14C13; Tue, 6 Jul 1999 13:01:18 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id NAA00967; Tue, 6 Jul 1999 13:00:48 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 6 Jul 1999 13:00:48 -0700 (PDT) From: Alex Zepeda To: "Brian F. Feldman" Cc: Chris Costello , Doug , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script 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, 6 Jul 1999, Brian F. Feldman wrote: > RTFM isn't a newby-apparent term. Name it help(1). Sure it is. Some hapless newbie wanders into #FreeBDS on efnet, and asks an already answered question. Aside from a kick, and a possible ban, they're likely to be met with a chorus of "rtfm", which in all likelyhood would prompt the inquisitive newbie to try and run rtfm. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:15:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 963EC14FA0 for ; Tue, 6 Jul 1999 13:15:48 -0700 (PDT) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA17844 for ; Tue, 6 Jul 1999 13:15:47 -0700 (PDT) Message-Id: <199907062015.NAA17844@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: kern/11222 X-Url: http://www.isi.edu/~faber Date: Tue, 06 Jul 1999 13:15:47 -0700 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hi, folks. I was hoping that someone would take a look at kern/11222, which has been open since I submitted it in April. The problem it addresses is that MFS buffers that are dirty when the reboot syscall is made are never cleaned because the reboot call never calls sleep, so the user-level process backing the MFS can never run to mark the buffers as clean. There are two patches with the pr, one from the date it was submitted which specifically detects MFS buffers and calls sleep if they're present, and one which replaces the DELAY calls in reboot with tsleep calls. The second was at the suggestion of Matt Dillon, who looked at the patch and PR in late April, but apparently hasn't had more time to look at it (yes, I pinged him). Is there someone else who is knowledgable about the reboot sequence who's willing to have a look at these patches? I've been running the second patch (removes DELAY) on my 3 3.1-RELEASE and 3.2-RELEASE machines (2 desktops and a laptop) without incident since April. I think they're pretty stable. Of course I'm happy to discuss the patches in tdetail with anyone willing to look at them. Thanks! - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4Jj8ob4eisfQ5rpAQHvvgP/fCJtGuQnoQjnc9/BXlLwvV9+5kzj1Imr TPk1gIQNwGkTDtqFnznm9nXV83baD7rZkKajb+O7NcqBoiohI/5Ir99PNhjiwxgc Ff5WSlE1ezO2V6Kp+wJjalB5ASXlekfWdwaFdgF4HihbAeRkJ8u3tvzuxiutjqeF DHzh8AwkO5I= =jZtL -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:30: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8907814D26 for ; Tue, 6 Jul 1999 13:30:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA86024; Tue, 6 Jul 1999 13:30:02 -0700 (PDT) (envelope-from dillon) Date: Tue, 6 Jul 1999 13:30:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907062030.NAA86024@apollo.backplane.com> To: Ted Faber Cc: hackers@FreeBSD.ORG Subject: Re: kern/11222 References: <199907062015.NAA17844@boreas.isi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Ted. I did look at it and it seems ok, though I didn't run it by the gurus. Unfortunately, without commit privs my hands are tied and I am just not willing to spend the hours of testing necessary to ensure that obvious bugs have been avoided when other people get the credit and the comments in the commit message. I was hoping the issue would be resolved at USENIX but core is unwilling to discuss the issue in a frank and open manner, instead opting for closed, one-sided, and jaded discussions. Even now what they say on open forums belies their actual actions - which so far has been zippo. It is a sad state of affairs and although I'm sure I'm not making very many friends by keeping the pressure up, at this point I don't have anything to lose. Core has been entirely unresponsive for several months now and I'm through being nice about it. Perhaps someone else can look at it and commit it. There are several items on my hot list submitted by other people which I have not been able to move on due to the lack of resolution to my committer's status, including some very cool looking optimizations that would cut NFS stat traffic in half. I find it rather humorous that I always spend hours testing things that other committers would commit without any testing whatsoever. -Matt Matthew Dillon :-----BEGIN PGP SIGNED MESSAGE----- : :Hi, folks. I was hoping that someone would take a look at kern/11222, :which has been open since I submitted it in April. The problem it :addresses is that MFS buffers that are dirty when the reboot syscall :is made are never cleaned because the reboot call never calls sleep, :so the user-level process backing the MFS can never run to mark the :buffers as clean. There are two patches with the pr, one from the :date it was submitted which specifically detects MFS buffers and calls :sleep if they're present, and one which replaces the DELAY calls in :reboot with tsleep calls. The second was at the suggestion of Matt :Dillon, who looked at the patch and PR in late April, but apparently :hasn't had more time to look at it (yes, I pinged him). : :Is there someone else who is knowledgable about the reboot sequence :who's willing to have a look at these patches? I've been running the :second patch (removes DELAY) on my 3 3.1-RELEASE and 3.2-RELEASE :machines (2 desktops and a laptop) without incident since April. I :think they're pretty stable. Of course I'm happy to discuss the :patches in tdetail with anyone willing to look at them. : :Thanks! : :- ---------------------------------------------------------------------- :Ted Faber faber@isi.edu :USC/ISI Computer Scientist http://www.isi.edu/~faber :(310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:31:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 1CF4F14BFD for ; Tue, 6 Jul 1999 13:31:45 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id NAA68734 for freebsd-hackers@FreeBSD.ORG; Tue, 6 Jul 1999 13:31:45 -0700 (PDT) Date: Tue, 6 Jul 1999 13:31:45 -0700 (PDT) From: David Wolfskill Message-Id: <199907062031.NAA68734@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Connect and so on.. In-Reply-To: <199907061652.JAA00454@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Tue, 06 Jul 1999 09:52:12 -0700 >From: Mike Smith >> > Could you point me to more about this (RAGF) scheme? >> [ML] I don't know if I have spelled it out correctly, but this >> is the authentication scheme used on mainframes (IBM at least) where all >> syscalls are routed through the authentication subsystem before >> proceeding. However, the subsystem seems to reside in kernel, and is >> (possibly precompiled) table driven so that it does not cause gross >> inefficiency. >RACF IIRC, often pronounced "Rack Off". Mike's pronunciation notwithstanding.... :-) From 1982 - 1992, I was involved in (among other things) installing and implementing RACF in IBM MVS{,/{X,ES}A} (mainframe) systems. During the bulk of that time, I also wrote system exits (packaged as "usermods") to make use of RACF capabilities to control various aspects of the system's operation -- for example, to control which disk drives were used for creating files. (This latter was intended to allow one set of drives to be used for the files that were necessary for bringing MVS up, a different (non-intersecting) set that was used (only) for "production" files, and another set that was for "normal user" files. Worked reasonably well, too -- despite some of the uglier interfaces available to folks who wanted to try to implement something like this.) Assuming that the product with which I retain some familiarity is the one in question, characterizing it as "where all syscalls are routed through the authentication subsystem before proceeding" is somewhat of an over-simplification (since only a few "resource managers" (as they were (are?) called) were present in the system -- OPEN/CLOSE/EOV was one of the first ones). However, I don't expect that additional details of RACF are likely to be of general interest to -hackers, so I'll spare further bandwidth on that... but I'm available as a resource for out-of-band discussions of RACF(-like) facilities. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:44:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 2AA6E1529C for ; Tue, 6 Jul 1999 13:44:48 -0700 (PDT) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA20776; Tue, 6 Jul 1999 13:44:44 -0700 (PDT) Message-Id: <199907062044.NAA20776@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: kern/11222 In-Reply-To: Your message of "Tue, 06 Jul 1999 13:30:02 PDT." <199907062030.NAA86024@apollo.backplane.com> X-Url: http://www.isi.edu/~faber Date: Tue, 06 Jul 1999 13:44:43 -0700 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Matthew Dillon wrote: > Hi Ted. I did look at it and it seems ok, though I didn't run it > by the gurus. Thanks. I know you're busy, and I just figured it was buried under other more pressing concerns. Sorry the commit problems are still lingering, but I really don't know enough about both sides to take a side. I hope the situation will be resolved in a way everyone can live with. In the meantime, anyone else want to take my little MFS fix under their wing? Or give *me* commit privs? :-) :-) :-) - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCUAwUBN4Jquob4eisfQ5rpAQEN+wP4mez0ASDxZZlBGJDqh6jML65c4GGgImLG sGYhvyHuAOQOOTsOgRx87a+7kUUMzqlqA/EpkiVCsRIWKKZrfVfYPTteArJAUK2y cNnSL3yVqAxRbG7qe0c3EF8xKeCtnOGVYxbNSI96ExotB6QRW9ySE6tUYH0Kxs/d pyskY57xdQ== =Lopy -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:46:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 032A814FE5; Tue, 6 Jul 1999 13:46:27 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18394.on.bellglobal.com [206.172.130.74]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id QAA19369; Tue, 6 Jul 1999 16:49:32 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id QAA69691; Tue, 6 Jul 1999 16:47:00 -0400 (EDT) (envelope-from tim) Date: Tue, 6 Jul 1999 16:47:00 -0400 From: Tim Vanderhoek To: "Brian F. Feldman" Cc: Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script Message-ID: <19990706164700.D59236@mad> References: <19990706134739.G4158@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Brian F. Feldman on Tue, Jul 06, 1999 at 02:52:08PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 02:52:08PM -0400, Brian F. Feldman wrote: > > On Tue, Jul 6, 1999, Brian F. Feldman wrote: > > > RTFM isn't a newby-apparent term. Name it help(1). > > > > That would cause problems with bash users. They already have > > a builtin help command. > > Which can be disabled in the bash port before the next release... Ugh. No. Objection on the grounds of "create more problems than it solves". We've already seen enough confusion from builtins such as time(1) having conflicting names. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 13:56:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-118.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.118]) by hub.freebsd.org (Postfix) with ESMTP id 6F59C14E0F for ; Tue, 6 Jul 1999 13:56:35 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA04494; Tue, 6 Jul 1999 21:04:27 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA74215; Tue, 6 Jul 1999 21:04:28 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907062004.VAA74215@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Josef Karthauser Cc: Brian Somers , Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp In-reply-to: Your message of "Tue, 06 Jul 1999 10:59:43 BST." <19990706105943.E9669@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jul 1999 21:04:28 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, Jul 06, 1999 at 04:11:39AM +0100, Brian Somers wrote: > > > > ? How about under ``set redial'' in the man page ? > > > > Brian, > > The i4b stuff seems to have some sophisticated costing control code (isdn.rates). > It appears that you can define the costs at different times of day and thereby > vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". I've added it to my todo list. I'll probably look at the BACP or MP+ stuff first though, and then at the ``when to bring up another link'' code.... all fun & games :-) > Joe > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] -- 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 Jul 6 14: 4:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E8C6C14E0F; Tue, 6 Jul 1999 14:04:47 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA04251; Tue, 6 Jul 1999 14:03:36 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Brian F. Feldman" Cc: Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script In-reply-to: Your message of "Tue, 06 Jul 1999 14:52:08 EDT." Date: Tue, 06 Jul 1999 14:03:35 -0700 Message-ID: <4247.931295015@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Which can be disabled in the bash port before the next release... No, that's a really stupid idea. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:26:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 896B214E0F for ; Tue, 6 Jul 1999 14:26:31 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA08680; Tue, 6 Jul 1999 17:26:18 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 17:26:18 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script In-Reply-To: <4247.931295015@zippy.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, 6 Jul 1999, Jordan K. Hubbard wrote: > > Which can be disabled in the bash port before the next release... > > No, that's a really stupid idea. Thanks! But still, I don't think rtfm is very appropriate... Can we look for something better, more obvious? Or perhaps it would be in the motd like /stand/sysinstall is.... people would need to be aware of this. > > - Jordan > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Tue Jul 6 14:28:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 1F04D14E0F; Tue, 6 Jul 1999 14:28:51 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA04411; Tue, 6 Jul 1999 14:27:40 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Brian F. Feldman" Cc: Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script In-reply-to: Your message of "Tue, 06 Jul 1999 17:26:18 EDT." Date: Tue, 06 Jul 1999 14:27:40 -0700 Message-ID: <4407.931296460@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that whomever actually writes it will get to name it whatever the hell they way, that's what I think. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:39:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id CFF3514CE6 for ; Tue, 6 Jul 1999 14:39:43 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40361>; Wed, 7 Jul 1999 07:22:00 +1000 Date: Wed, 7 Jul 1999 07:39:33 +1000 From: Peter Jeremy Subject: Re: Pictures from USENIX To: hackers@FreeBSD.ORG Message-Id: <99Jul7.072200est.40361@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: >Greg Lehey wrote: >> Peter's gone to the USA, we think. > >Not another one? The FreeBSD Aussie invasion continues... You're likely to see a lot more. The Oz Government has just enacted Internet censorship legislation placing us on a par with China (http://www.efa.org.au/Campaigns/99.html for details). >> John Birrell's further South (Melbourne, for a first approximation): Don't we have any Tasmaniacs? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:42:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id E74D314CE6; Tue, 6 Jul 1999 14:42:29 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA08196; Tue, 6 Jul 1999 14:42:28 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 6 Jul 1999 14:42:28 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: "Brian F. Feldman" Cc: Chris Costello , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script 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, 6 Jul 1999, Brian F. Feldman wrote: > On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: > > > > Which can be disabled in the bash port before the next release... > > > > No, that's a really stupid idea. > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > for something better, more obvious? Or perhaps it would be in the motd > like /stand/sysinstall is.... people would need to be aware of this. I think your logic is faulty here. There are already many adequate resources in the motd, but your argument for the 'rtfm script' presupposes that the person has not looked at the motd, because if they had they wouldn't need the script. Honestly, while this is one of those things that sounds good when you first start talking about it, in practice I don't see what we gain from it. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:46: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 8880D14CE6; Tue, 6 Jul 1999 14:46:03 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 1B6CC3707B; Tue, 6 Jul 1999 17:45:56 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id QAA34854; Tue, 6 Jul 1999 16:44:51 -0500 (CDT) (envelope-from chris) Date: Tue, 6 Jul 1999 16:44:50 -0500 From: Chris Costello To: Doug Cc: "Brian F. Feldman" , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script Message-ID: <19990706164450.M4158@holly.dyndns.org> Reply-To: chris@calldei.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Doug on Tue, Jul 06, 1999 at 02:42:28PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 6, 1999, Doug wrote: > Honestly, while this is one of those things that sounds good when > you first start talking about it, in practice I don't see what we gain > from it. What we gain from it is really simple and can be obtained from looking at how it operates. It's a starting point for newbies looking for information. Often, people will say "rtfm" when someone asks for help on something that's pretty well documented. I've known many a newbie to try and see if an rtfm command exists. -- Chris Costello If you have a procedure with 10 parameters, you probably missed some. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:47:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DBEEC14E0F for ; Tue, 6 Jul 1999 14:47:47 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA09053; Tue, 6 Jul 1999 17:47:44 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 6 Jul 1999 17:47:44 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Doug Cc: Chris Costello , Alex Zepeda , hackers@FreeBSD.org Subject: Re: 'rtfm' script 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, 6 Jul 1999, Doug wrote: > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: > > > > > > Which can be disabled in the bash port before the next release... > > > > > > No, that's a really stupid idea. > > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > for something better, more obvious? Or perhaps it would be in the motd > > like /stand/sysinstall is.... people would need to be aware of this. > > I think your logic is faulty here. There are already many adequate > resources in the motd, but your argument for the 'rtfm script' presupposes > that the person has not looked at the motd, because if they had they > wouldn't need the script. /bin/rtfmsh? > > Honestly, while this is one of those things that sounds good when > you first start talking about it, in practice I don't see what we gain > from it. > > Doug > -- > On account of being a democracy and run by the people, we are the only > nation in the world that has to keep a government four years, no matter > what it does. > -- Will Rogers > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Tue Jul 6 14:50:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-6.ppp.wenet.net [206.15.85.6]) by hub.freebsd.org (Postfix) with ESMTP id 96A7514E0F for ; Tue, 6 Jul 1999 14:50:13 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id OAA01261; Tue, 6 Jul 1999 14:49:21 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 6 Jul 1999 14:49:21 -0700 (PDT) From: Alex Zepeda To: "Kenneth D. Merry" Cc: Takeshi OHASHI , dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG Subject: Re: DVD-ram In-Reply-To: <199907061724.LAA85126@panzer.kdm.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 Tue, 6 Jul 1999, Kenneth D. Merry wrote: > IMO, DVD drives are probably best handled through the CD driver, and > Optical drives are probably best handled through the DA driver. The > CD driver doesn't currently handle writes, but it's a one-line fix to > change that. From what I can tell, some of the DVD-RAM drives are actually treated as disks (would use the da driver). For example, check out http://mpeg.openprojects.net/panasonic.html to see the Linux "driver" for the Panasonic LF-D100. The comments outnumber the code. > I'd like to hear what your rationale for a separate driver is, though. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 14:58:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 877AD14E0F; Tue, 6 Jul 1999 14:58:31 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 4062C37089; Tue, 6 Jul 1999 17:58:29 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id QAA34908; Tue, 6 Jul 1999 16:57:09 -0500 (CDT) (envelope-from chris) Date: Tue, 6 Jul 1999 16:57:08 -0500 From: Chris Costello To: Nik Clayton Cc: Bill Fumerola , doc@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Searching the Handbook (was Re: 'rtfm script') Message-ID: <19990706165708.N4158@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990705141635.D97224@holly.dyndns.org> <19990706115526.Z15628@lehman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990706115526.Z15628@lehman.com>; from Nik Clayton on Tue, Jul 06, 1999 at 11:55:26AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 6, 1999, Nik Clayton wrote: > I've added doc@freebsd.org to the distribution list, for obvious reasons. > > On Mon, Jul 05, 1999 at 02:16:36PM -0500, Chris Costello wrote: > > Note that I can't figure out a decent way to search the > > Handbook at this point, but I'm open to ideas. > > There are a couple of ways you could do it. Some of them more optimal > than others. > > Executive summary: sgrep is probably your best choice now, which can > can be found at . > But read on for more. > > The simplest way is to assume that the user has the plain text handbook > installed, and do a simple grep through that for what you're looking for. See the FAQ parser. I want to be able to get meaningful output for users. sgrep is also not viable because it's not in the default system. > This is nice and easy to do, but doesn't take advantage of the additional > smarts built in to the Handbook's native format. To do that requires some > additional work. The handbook's native format won't be on the default system, will it? They're all in HTML. > A smart searching mechanism will be able to use this additional semantic > information to reject (or lower the rankings of) results that don't match > what the user wanted. See above. I want rtfm(1) to remain viable on base installs. > For example, suppose you're searching the Handbook for examples of the > make(1) command in action. The simple string "make" occurs lots of times > in the Handbook. However, you're only interested in those sections where > it occurs *inside* a element; all the other occurences can be > ignored. > > For a simple rtfm(1) style search most of this can probably be ignored, and > you can just search the plain text handbook. But even then you might want > to provide switches that allow the user to specify: > > - Only match this word if found in an example > > - Only match this word if found in a title > > - Only match this word if found in a command name This can only be done if the user can access the SGML files. First off, the SGML files are not installed by default. Accessing them online would require having to search every single one or one big one, which isn't a good idea at this point. > You could go the full SGML route. This would involve building an > application that can parse the DocBook source of the Handbook (and other > articles, and soon to be the FAQ) and allow the user to do their queries > using this application. This is probably the most 'correct' route from > a purist point of view, but is an awful lot of work. If the FAQ is to be DocBook-ified, will the SGML sources be made availible via HTTP so rtfm(1) can still cleanly parse them with a minor rewrite of the FAQ section? > *Much* simpler is to build a grep-alike that understands structured > documents, but that doesn't care how those documents are structured. This > is such a great idea that someone's already done it -- sgrep, which can > be found at can > search structured text (such as DocBook, HTML, or even mail files). I'd have to integrate it into rtfm(1), and see above about access to the handbook. -- Chris Costello Computers are only human. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 15: 1:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picalon.gun.de (picalon.gun.de [194.77.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 8AECA15491 for ; Tue, 6 Jul 1999 15:01:26 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.8.6/8.8.6) with ESMTP id AAA05444; Wed, 7 Jul 1999 00:00:11 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id XAA77125; Tue, 6 Jul 1999 23:58:27 +0200 (CEST) (envelope-from andreas) Date: Tue, 6 Jul 1999 23:58:27 +0200 From: Andreas Klemm To: hackers@FreeBSD.ORG Cc: Marcel Moolenaar , Grant Taylor Subject: [gtaylor@picante.com: apsfilter/pnp database integration] Message-ID: <19990706235827.A76827@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=SUOF0GtieIMvvwua X-Mailer: Mutt 0.95.5i X-Operating-System: FreeBSD 3.2-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Is somebody perhaps working on that ? I think Grant's idea is very good of maintaining a ghostscript printer database and his idea to make apsfilter aware of connected printer type. In FreeBSD possibly some infrastructure is missing. Please look his comments about how Linux folks implemented this. I think it would be fine, if we could be compatible with Linux to do the printer auto recognition via IEEE parport probe strings. Is there some work in the pipeline or has somebody interest to implement it. Perhaps some code from Linux can be used ? See http://www.picante.com/~gtaylor/pht/#2 for general information about the printer database. Cc'd to Marcel since he does Linux Emulation. Cc'd to Grant, that he can perhaps exchange infos with Marcel. Thanks Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Latest song from our band: http://www.freebsd.org/~andreas/mp3/schaukel.mp3 --SUOF0GtieIMvvwua Content-Type: message/rfc822 Return-Path: Received: (from uucp@localhost) by klemm.gtn.com (8.9.3/8.9.3) with UUCP id XAA76236 for andreas@klemm.gtn.com; Tue, 6 Jul 1999 23:26:57 +0200 (CEST) (envelope-from gtaylor@pace.picante.com) Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by mail.gtn.com (8.8.6/8.8.6) with ESMTP id WAA08547 for ; Tue, 6 Jul 1999 22:39:41 +0200 (MET DST) Received: by hub.freebsd.org (Postfix) id 4A37415135; Tue, 6 Jul 1999 13:39:22 -0700 (PDT) Delivered-To: andreas@freebsd.org Received: from pace.picante.com (pace.picante.com [199.103.241.49]) by hub.freebsd.org (Postfix) with ESMTP id BEB8915171 for ; Tue, 6 Jul 1999 13:39:14 -0700 (PDT) (envelope-from gtaylor@pace.picante.com) Received: from pace.picante.com (gtaylor@localhost [127.0.0.1]) by pace.picante.com (8.8.7/8.8.7) with ESMTP id QAA09142 for ; Tue, 6 Jul 1999 16:39:12 -0400 Message-Id: <199907062039.QAA09142@pace.picante.com> To: andreas@freebsd.org Subject: apsfilter/pnp database integration Date: Tue, 06 Jul 1999 16:39:10 -0300 From: Grant Taylor Sender: gtaylor@pace.picante.com Hi there. I maintain the Linux Printing HOWTO and an associated printer compatibility database, and I'd like to add a feature to apsfilter. The database contains IEEE parport probe strings, and driver information, for many printers. It seems like it should be possible to have apsfilter automatically identify connected printers and drivers by connecting the autoprobe info and the compatibility list. I want to mangle this feature in. For a little background, see the database, notes and example_script at http://gatekeeper.picante.com/~gtaylor/pht/#2 So my questions are: - What version of apsfilter should I sit down and play with? 5.1.2? A development snapshot from somewhere? - Does FreeBSD report the parport probe info for attached printers, and how? In Linux 2.2, for example, the ID strings appear in the file /proc/parport//autoprobe. - Any opinions on how this should be implemented? -- Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/ Cellphone information: http://www.picante.com/~gtaylor/cell/ Libretto information: http://www.picante.com/~gtaylor/portable/ --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 15: 4:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from detlev.UUCP (tex-70.camalott.com [208.229.74.70]) by hub.freebsd.org (Postfix) with ESMTP id 1CE6814E83 for ; Tue, 6 Jul 1999 15:04:16 -0700 (PDT) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.3/8.9.3) id RAA13141; Tue, 6 Jul 1999 17:03:28 -0500 (CDT) (envelope-from joelh) To: Wes Peters Cc: Bill Fumerola , "G. Adam Stanislav" , haodongpan@netease.com, freebsd-hackers@FreeBSD.ORG Subject: Re: how to start to be a hacker? References: <377DB95C.448E4227@softweyr.com> From: Joel Ray Holveck Date: 06 Jul 1999 17:03:28 -0500 In-Reply-To: Wes Peters's message of "Sat, 03 Jul 1999 01:18:52 -0600" Message-ID: <86r9ml5tcf.fsf@detlev.UUCP> Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>> I know the basic admin knowledge of UNIX,perl,cgi,c >>>> how to become a hacker? >>> You either are a hacker, or you are not. It is not something someone else >>> can teach you. >> This deserves a FAQ entry. What an awesome response. > But it's certainly NOT something that you just are, either. You have to > have talent, but you also have to have experience. This is most often > done by a mentor. I think the general gist was summed up in Levy[1]: "If a hacker's made, he's got to be born; but if a hacker's born, he's gonna be made." (I haven't read Levy in ages, and I am probably mangling the quote. I can't even be sure that it's from Levy. FWIW, I think the originator was either Gosper or GLS.) Cheers, joelh [1] Levy, Steven. _Hackers_. Anchor/Doubleday 1984 ISBN 0-385-19195-2 -- Joel Ray Holveck - joelh@gnu.org 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 Jul 6 15:23:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 02CFB14E83 for ; Tue, 6 Jul 1999 15:23:34 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA86704; Tue, 6 Jul 1999 16:23:03 -0600 (MDT) (envelope-from ken) Message-Id: <199907062223.QAA86704@panzer.kdm.org> Subject: Re: DVD-ram In-Reply-To: from Alex Zepeda at "Jul 6, 1999 02:49:21 pm" To: garbanzo@hooked.net (Alex Zepeda) Date: Tue, 6 Jul 1999 16:23:03 -0600 (MDT) Cc: ken@plutotech.com (Kenneth D. Merry), ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI), dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM931299783-86655-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM931299783-86655-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Alex Zepeda wrote... > On Tue, 6 Jul 1999, Kenneth D. Merry wrote: > > > IMO, DVD drives are probably best handled through the CD driver, and > > Optical drives are probably best handled through the DA driver. The > > CD driver doesn't currently handle writes, but it's a one-line fix to > > change that. > > >From what I can tell, some of the DVD-RAM drives are actually treated as > disks (would use the da driver). For example, check out > http://mpeg.openprojects.net/panasonic.html to see the Linux "driver" for > the Panasonic LF-D100. The comments outnumber the code. Well, that makes sense from one perspective, and doesn't make sense from another perspective. Sure, DVD drives look like a disk from the standpoint that you can use standard read *and* write calls on them. But in most other ways, they're like CDROM drives. You can play audio CDs in them, mount regular data CDs in them, etc. With a disk driver, you don't have any of the special ioctl set to deal with CD-type drives and media. In fact, you probably wouldn't be able to mount disk with an ISO 9660 filesystem using the da driver, since it doesn't support the TOC ioctls that the cd9660 filesystem code uses. (because DA devices don't support those SCSI commands) The best of both worlds for accessing a DVD-RAM drive would be to just add write support to the CD driver. The CAM CD driver already has write support, but it isn't currently enabled. The attached one-line patch enables write support, and should make things just work. If anyone has a DVD-RAM drive and cares to test it, I'd be very interested to hear how things work. Ken -- Kenneth Merry ken@plutotech.com --ELM931299783-86655-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=scsi_cd.c.diffs.070699 Content-Description: scsi_cd.c.diffs.070699 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_cd.c#107 - /a/ken/perforce/cam/sys/cam/scsi/scsi_cd.c ==== *** /tmp/tmp.73024.0 Tue Jul 6 16:16:09 1999 --- /a/ken/perforce/cam/sys/cam/scsi/scsi_cd.c Tue Jul 6 11:18:01 1999 *************** *** 247,253 **** /* open */ cdopen, /* close */ cdclose, /* read */ physread, ! /* write */ nowrite, /* ioctl */ cdioctl, /* stop */ nostop, /* reset */ noreset, --- 247,253 ---- /* open */ cdopen, /* close */ cdclose, /* read */ physread, ! /* write */ physwrite, /* ioctl */ cdioctl, /* stop */ nostop, /* reset */ noreset, --ELM931299783-86655-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 15:50:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id D7E83153EE; Tue, 6 Jul 1999 15:50:07 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18392.on.bellglobal.com [206.172.130.72]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA06631; Tue, 6 Jul 1999 18:51:28 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA72607; Tue, 6 Jul 1999 18:50:40 -0400 (EDT) (envelope-from tim) Date: Tue, 6 Jul 1999 18:50:40 -0400 From: Tim Vanderhoek To: Nik Clayton Cc: chris@calldei.com, Bill Fumerola , doc@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Searching the Handbook (was Re: 'rtfm script') Message-ID: <19990706185040.N59236@mad> References: <19990705141635.D97224@holly.dyndns.org> <19990706115526.Z15628@lehman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990706115526.Z15628@lehman.com>; from Nik Clayton on Tue, Jul 06, 1999 at 11:55:26AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 11:55:26AM +0100, Nik Clayton wrote: > > *Much* simpler is to build a grep-alike that understands structured > documents, but that doesn't care how those documents are structured. This Perhaps dtags(1) a-la ctags(1). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 16:20:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 8EBA614C8E for ; Tue, 6 Jul 1999 16:20:48 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 111eW1-0004pP-00; Tue, 6 Jul 1999 16:20:41 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id QAA13212; Tue, 6 Jul 1999 16:20:38 -0700 Date: Tue, 6 Jul 1999 16:20:38 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Repalcement for grep(1) To: Jamie Howard Cc: archie@whistle.com, freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org, tech@openbsd.org In-Reply-To: <199907051807.LAA54803@bubba.whistle.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 Jamie Howard writes: > > Perhaps this will help with -w? > > Yes, I received a patch from Simon Burge which implements this. It also > beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am > still having trouble with -x though. It turns out that even if I specify > a commandline with a pattern of the form "^pattern$", it fails. If I > specify "^pattern" it works. If I specify "pattern$" it does not. I > have yet to find a case where my version will sucessfully match when a $ > is at the end. Has anyone encountered anything like this before? If you are using double quotes, as you show here, the shell may be attempting a variable substitution. Try single quotes. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 16:50:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 4826314CFF for ; Tue, 6 Jul 1999 16:50:42 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id JAA13894; Wed, 7 Jul 1999 09:20:40 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA10613; Wed, 7 Jul 1999 09:20:39 +0930 Date: Wed, 7 Jul 1999 09:20:39 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: hackers@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990706160524.DD35C78@overcee.netplex.com.au> 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've redirected this to -hackers where I probably should have sent it initially.] On Wed, 7 Jul 1999, Peter Wemm wrote: > > It would probably also be worthwhile redefining New-DES and our blowfish > > format to fit this common form: > > > > $DES$$salt$hash > > IMHO, don't change the existing new-des stuff since it's partially understood > in a number of places already. Okay. > > The question then becomes whether we make implementation-defined or > > always log base-2? > > I'd suggest leave it implementation defined since there's no telling how > fast or slow a given algorithm may be. IMHO, do it either log2 or log10 or > do some sort of power encoding, ie literally store 2 and 12 for 2^12 or 10 > and 6 for 10^6 rounds. Hmm. I don't know that using variable bases buys much; you can always approximate to the nearest power-of-2 and not pay much. I think leaving it implementation-defined is best. There's a danger of over-engineering this, but I was also considering the merits of a 'version number' like OpenBSD's "algorithm 2, version a" for blowfish. That allows for algorithm changes without requiring a new name token, and /possibly/ reduces the impact of other vendors choosing incompatible algorithms with the same name (although only statistically). So the generic format would be $token$version$rounds$salt$hash e.g. $MD5$1$$salt$hash (the rounds being null because the algorithm doesn't support variable-round encryption). The extra size of password entries doesn't seem to be a big deal to me.. > The risk is that there has to be a reasonable minimum, otherwise an evil > hacker (TM) might run some cpu burners to slow down the timing to get a > weaker number of rounds. You could run the timer so it counts the CPU time of the passwd program itself, not the wall time. e.g. run it for some period of time, find it did 1000 basic operations per CPU-second, and calculate that 10000 rounds are needed for passwords that crypt() in 10 seconds. > There's also the risk that your K7-1000 encodes > and exports a password to a 386SX-25. :-) There is that, but it's mroe of an administrative problem. You can already screw yourself that way by specifying 2^16-round blowfish passwords :-) Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 17:29:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id B91B815062; Tue, 6 Jul 1999 17:29:35 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA12839; Tue, 6 Jul 1999 17:29:30 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA07168; Tue, 6 Jul 1999 17:29:30 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA09531; Tue, 6 Jul 99 17:29:28 PDT Message-Id: <37829F68.A0193C6E@softweyr.com> Date: Tue, 06 Jul 1999 18:29:28 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: "Brian F. Feldman" Cc: Chris Costello , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: > > On Tue, 6 Jul 1999, Chris Costello wrote: > > > On Tue, Jul 6, 1999, Doug wrote: > > > I'm confused about this script. How does it differ from 'apropos'? > > > > It differs in that it _uses_ apropos (or 'whatis' if you > > specify the -e flag), as well as a Texinfo search, as well as a > > FAQ search, using the FAQ pages at http://www.freebsd.org/FAQ/. > > It's meant to be an information center for those just getting > > started with FreeBSD. > > RTFM isn't a newby-apparent term. Name it help(1). And link it to whatthehell(1). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 19:11:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sol (cs1-gw.cs.binghamton.edu [128.226.171.72]) by hub.freebsd.org (Postfix) with SMTP id 2F3D814FB4 for ; Tue, 6 Jul 1999 19:11:11 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from localhost (zzhang@localhost) by sol (SMI-8.6/8.6.9) with SMTP id VAA18515 for ; Tue, 6 Jul 1999 21:59:00 -0400 Date: Tue, 6 Jul 1999 21:59:00 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: Overwrite an executable file that is running 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 a big executable file that is being run by the OS, all its contents may not be loaded into the memory. At the same time, the developer gets impatient and wants to create a new version of the same file. He could modify the makefile to output the new version to a different file name, but this is tedious. This new version should not overwrite the older verion of the file being run. My question is how FreeBSD prevents this from happening? Can anyone point out for me where in the source code this is handled? Thanks a lot. -------------------------------------------------- Zhihui Zhang. Please visit 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 Tue Jul 6 19:28:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id EAED0150C1 for ; Tue, 6 Jul 1999 19:28:15 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id WAA08044; Tue, 6 Jul 1999 22:28:10 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA24599; Tue, 6 Jul 1999 22:27:40 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id WAA83834; Tue, 6 Jul 1999 22:27:39 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907070227.WAA83834@bb01f39.unx.sas.com> Subject: Re: Connect and so on.. In-Reply-To: From David Wolfskill at "Jul 6, 1999 1:31:45 pm" To: dhw@whistle.com (David Wolfskill) Date: Tue, 6 Jul 1999 22:27:39 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, mike@smith.net.au 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 Ahhh.. RACF... MVS... Music to my ears... And speaking of resource managers... don't forget the ESM on CMS for SFS... :-) I would have spared the bandwidth.. but it's worth noting that we run a production system that installs user exits into the Shared File System on CMS via the Callable Services Libraries (CSL). ie: We take over the CSL entry points. Whenever accessing files within a given Filepool, we dynamically redirect the I/O to our FreeBSD systems where the data actually resides. No modifications are then required to the application running on the mainframe, and they have no idea the data isn't local. Never underestimate the power of good user exits and the ability to implement your own External Security Manager... Just my 0.02 :-) John ps: I've always pronounced it 'RACK-F' (as in the letter F). > >Date: Tue, 06 Jul 1999 09:52:12 -0700 > >From: Mike Smith > > >> > Could you point me to more about this (RAGF) scheme? > >> [ML] I don't know if I have spelled it out correctly, but this > >> is the authentication scheme used on mainframes (IBM at least) where all > >> syscalls are routed through the authentication subsystem before > >> proceeding. However, the subsystem seems to reside in kernel, and is > >> (possibly precompiled) table driven so that it does not cause gross > >> inefficiency. > > >RACF IIRC, often pronounced "Rack Off". > > Mike's pronunciation notwithstanding.... :-) > > From 1982 - 1992, I was involved in (among other things) installing and > implementing RACF in IBM MVS{,/{X,ES}A} (mainframe) systems. During the > bulk of that time, I also wrote system exits (packaged as "usermods") to > make use of RACF capabilities to control various aspects of the system's > operation -- for example, to control which disk drives were used for > creating files. (This latter was intended to allow one set of drives to > be used for the files that were necessary for bringing MVS up, a different > (non-intersecting) set that was used (only) for "production" files, and > another set that was for "normal user" files. Worked reasonably well, > too -- despite some of the uglier interfaces available to folks who > wanted to try to implement something like this.) > > Assuming that the product with which I retain some familiarity is the > one in question, characterizing it as "where all syscalls are routed > through the authentication subsystem before proceeding" is somewhat of > an over-simplification (since only a few "resource managers" (as they > were (are?) called) were present in the system -- OPEN/CLOSE/EOV was one > of the first ones). > > However, I don't expect that additional details of RACF are likely to be > of general interest to -hackers, so I'll spare further bandwidth on > that... but I'm available as a resource for out-of-band discussions of > RACF(-like) facilities. > > Cheers, > david > - -- > David Wolfskill dhw@whistle.com UNIX System Administrator > voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 > > > 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 Jul 6 19:49:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id 1856E14D5A for ; Tue, 6 Jul 1999 19:49:32 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id LAA13456; Wed, 7 Jul 1999 11:47:00 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id LAA01724; Wed, 7 Jul 1999 11:46:59 +0900 (JST) Date: Wed, 7 Jul 1999 11:46:59 +0900 (JST) Message-Id: <199907070246.LAA01724@atohasi.mickey.ai.kyutech.ac.jp> To: ken@plutotech.com Cc: garbanzo@hooked.net, dmiller@search.sparks.net, freebsd-hackers@FreeBSD.ORG, akiyama@kme.mei.co.jp Subject: Re: DVD-ram From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ken>>Alex Zepeda wrote... ken>>> On Tue, 6 Jul 1999, Kenneth D. Merry wrote: ken>>> ken>>> > IMO, DVD drives are probably best handled through the CD driver, and ken>>> > Optical drives are probably best handled through the DA driver. The ken>>> > CD driver doesn't currently handle writes, but it's a one-line fix to ken>>> > change that. ken>>> ken>>> >From what I can tell, some of the DVD-RAM drives are actually treated as ken>>> disks (would use the da driver). For example, check out ken>>> http://mpeg.openprojects.net/panasonic.html to see the Linux "driver" for ken>>> the Panasonic LF-D100. The comments outnumber the code. ken>> ken>>Well, that makes sense from one perspective, and doesn't make sense from ken>>another perspective. ken>> ken>>Sure, DVD drives look like a disk from the standpoint that you can use ken>>standard read *and* write calls on them. ken>> ken>>But in most other ways, they're like CDROM drives. You can play audio CDs ken>>in them, mount regular data CDs in them, etc. With a disk driver, you ken>>don't have any of the special ioctl set to deal with CD-type drives and ken>>media. ken>> ken>>In fact, you probably wouldn't be able to mount disk with an ISO 9660 ken>>filesystem using the da driver, since it doesn't support the TOC ioctls ken>>that the cd9660 filesystem code uses. (because DA devices don't support ken>>those SCSI commands) ken>> ken>>The best of both worlds for accessing a DVD-RAM drive would be to just add ken>>write support to the CD driver. The CAM CD driver already has write ken>>support, but it isn't currently enabled. ken>> ken>>The attached one-line patch enables write support, and should make things ken>>just work. If anyone has a DVD-RAM drive and cares to test it, I'd be very ken>>interested to hear how things work. ken>> ken>>Ken ken>>-- ken>>Kenneth Merry ken>>ken@plutotech.com How do you think about some MO(Magneto Otpical disk) and PD drives? 3.5" 650MB and 1.3GB MO drives should handle 512KB/sector(128MB, 230MB, 540MB) and 2048KB/sector media(640MB, 1.3GB). Some PD drives use 2 LUNs. One of them is used for CD drive mode and another is for PD drive. How do you treat write protection? DVD-RAM type II media can be remove from the cartridge and be read as like as DVD-ROM media by some latest DVD-ROM drives, for example Panasonic's. But the striped DVD-RAM media is treat ad read only media by DVD-RAM drive. In addition, there are many bugy MO drives, ex. cash probelem, and media, ex. formated media for Windows. They cause to need some extra error handling. We were very happy to use DVD-RAM/MO/PD drives on FreeBSD-2.2.X, because pre-CAM SCSI system had the od-driver. We could not use these devices on FreeBSD-3.X without the new od-driver. Thank you very much, Mr. Akiyama. -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 20:27:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 70C0914D5A for ; Tue, 6 Jul 1999 20:27:24 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id VAA68901; Tue, 6 Jul 1999 21:15:38 -0600 (MDT) Date: Tue, 6 Jul 1999 21:15:38 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907070315.VAA68901@narnia.plutotech.com> To: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) Cc: hackers@FreeBSD.org Subject: Re: DVD-ram X-Newsgroups: pluto.freebsd.hackers In-Reply-To: <199907070246.LAA01724@atohasi.mickey.ai.kyutech.ac.jp> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > How do you think about some MO(Magneto Otpical disk) and PD drives? > > 3.5" 650MB and 1.3GB MO drives should handle 512KB/sector(128MB, > 230MB, 540MB) and 2048KB/sector media(640MB, 1.3GB). The da driver should handle 2048KB sector sized media right now. If it doesn't for some reason, that is a bug and it should be fixed. > Some PD drives use 2 LUNs. One of them is used for CD drive mode and > another is for PD drive. I don't see any problem with the 2 LUNs. CAM probes all luns and has no restrictions on the device types allowed on those luns. Lun 0 could be handled by the cd driver and lun 1 could be handled by the da driver. > How do you treat write protection? DVD-RAM type II media can be remove > from the cartridge and be read as like as DVD-ROM media by some latest > DVD-ROM drives, for example Panasonic's. But the striped DVD-RAM media > is treat ad read only media by DVD-RAM drive. The cd driver will have to understand that some media can be written to and some cannot. The main reason to use the cd driver for this is that DVD is under the MMC command set that the cd driver is supposed to support. The fact that it doesn't support all of those commands right now is a bug, but that doesn't mean that a new driver type is needed. > In addition, there are many bugy MO drives, ex. cash probelem, and > media, ex. formated media for Windows. They cause to need some extra > error handling. So you need quirk entries. The CD driver already has a quirk facility that could be expanded to handle these bugs. Again, I don't see a compelling reason for writing a new driver over expanding the functionality in the old. > We were very happy to use DVD-RAM/MO/PD drives on FreeBSD-2.2.X, > because pre-CAM SCSI system had the od-driver. We could not use these > devices on FreeBSD-3.X without the new od-driver. How did the da driver fail? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 20:41:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D54B314D58 for ; Tue, 6 Jul 1999 20:41:48 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA88466; Tue, 6 Jul 1999 21:39:54 -0600 (MDT) (envelope-from ken) Message-Id: <199907070339.VAA88466@panzer.kdm.org> Subject: Re: DVD-ram In-Reply-To: <199907070246.LAA01724@atohasi.mickey.ai.kyutech.ac.jp> from Takeshi OHASHI at "Jul 7, 1999 11:46:59 am" To: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) Date: Tue, 6 Jul 1999 21:39:53 -0600 (MDT) Cc: garbanzo@hooked.net, dmiller@search.sparks.net, akiyama@kme.mei.co.jp, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (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 Takeshi OHASHI wrote... > ken>>Alex Zepeda wrote... > ken>>> On Tue, 6 Jul 1999, Kenneth D. Merry wrote: > ken>>> > ken>>> > IMO, DVD drives are probably best handled through the CD driver, and > ken>>> > Optical drives are probably best handled through the DA driver. The > ken>>> > CD driver doesn't currently handle writes, but it's a one-line fix to > ken>>> > change that. > ken>>> > ken>>> >From what I can tell, some of the DVD-RAM drives are actually treated as > ken>>> disks (would use the da driver). For example, check out > ken>>> http://mpeg.openprojects.net/panasonic.html to see the Linux "driver" for > ken>>> the Panasonic LF-D100. The comments outnumber the code. > ken>> > ken>>Well, that makes sense from one perspective, and doesn't make sense from > ken>>another perspective. > ken>> > ken>>Sure, DVD drives look like a disk from the standpoint that you can use > ken>>standard read *and* write calls on them. > ken>> > ken>>But in most other ways, they're like CDROM drives. You can play audio CDs > ken>>in them, mount regular data CDs in them, etc. With a disk driver, you > ken>>don't have any of the special ioctl set to deal with CD-type drives and > ken>>media. > ken>> > ken>>In fact, you probably wouldn't be able to mount disk with an ISO 9660 > ken>>filesystem using the da driver, since it doesn't support the TOC ioctls > ken>>that the cd9660 filesystem code uses. (because DA devices don't support > ken>>those SCSI commands) > ken>> > ken>>The best of both worlds for accessing a DVD-RAM drive would be to just add > ken>>write support to the CD driver. The CAM CD driver already has write > ken>>support, but it isn't currently enabled. > ken>> > ken>>The attached one-line patch enables write support, and should make things > ken>>just work. If anyone has a DVD-RAM drive and cares to test it, I'd be very > ken>>interested to hear how things work. > ken>> > ken>>Ken > ken>>-- > ken>>Kenneth Merry > ken>>ken@plutotech.com > > How do you think about some MO(Magneto Otpical disk) and PD drives? > > 3.5" 650MB and 1.3GB MO drives should handle 512KB/sector(128MB, > 230MB, 540MB) and 2048KB/sector media(640MB, 1.3GB). The CAM DA driver was specifically designed to handle various sector sizes, and should work fine with non-512 byte sector sizes. If it doesn't, it needs to be fixed. > Some PD drives use 2 LUNs. One of them is used for CD drive mode and > another is for PD drive. I don't know very much about PD drives. Can you give me a brief description of the sort of interface they present? Is it like a MO drive, or something else? What SCSI type does the PD drive LUN probe as? Optical, direct access, CDROM, what? > How do you treat write protection? DVD-RAM type II media can be remove > from the cartridge and be read as like as DVD-ROM media by some latest > DVD-ROM drives, for example Panasonic's. But the striped DVD-RAM media > is treat ad read only media by DVD-RAM drive. If the drive treats the media as read-only, then the driver will just return an error if the user tries to write to it. > In addition, there are many bugy MO drives, ex. cash probelem, and > media, ex. formated media for Windows. They cause to need some extra > error handling. Device specific error handling should be doable within the current DA driver with quirk entries. How broken are the drives in question? Can you make source code to the OD driver available, so I can take a look at it, and see what sorts of things you have to do to make these drives work? > We were very happy to use DVD-RAM/MO/PD drives on FreeBSD-2.2.X, > because pre-CAM SCSI system had the od-driver. We could not use these > devices on FreeBSD-3.X without the new od-driver. Well...I would expect that DVD-RAM drives might not work exactly as you expect, without a tweak to the CDROM driver to allow it to write to the media. MO drives should work okay with the DA driver, and since I'm not sure what PD drives look/act like, I can't really say whether they should work or not. > Thank you very much, Mr. Akiyama. Thanks for the response. I'd certainly like to hear more about the OD driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 20:42: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id CA32615453 for ; Tue, 6 Jul 1999 20:42:03 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id XAA00407; Tue, 6 Jul 1999 23:48:22 -0400 (EDT) Date: Tue, 6 Jul 1999 22:48:20 -0500 (EST) From: Alfred Perlstein To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Overwrite an executable file that is running 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, 6 Jul 1999, Zhihui Zhang wrote: > > For a big executable file that is being run by the OS, all its contents > may not be loaded into the memory. At the same time, the developer gets > impatient and wants to create a new version of the same file. He could > modify the makefile to output the new version to a different file name, > but this is tedious. This new version should not overwrite the older > verion of the file being run. My question is how FreeBSD prevents this > from happening? Can anyone point out for me where in the source code this > is handled? He should unlink the file before "overwriting it". The running executable will still remain tied to the old data as the reference count will stay positive until all open descriptors pointing to it are close()'d. You can test this by writing a program that opens a file, scribbles some data to it, keeps the file open, meanwhile something else comes along and deletes that file, the first program will still see the old contents, even if a new program writes out a file with the same name but different contents. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 22: 6:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id E754014CA4 for ; Tue, 6 Jul 1999 22:04:53 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id NAA14256; Wed, 7 Jul 1999 13:58:08 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id NAA01916; Wed, 7 Jul 1999 13:58:07 +0900 (JST) Date: Wed, 7 Jul 1999 13:58:07 +0900 (JST) Message-Id: <199907070458.NAA01916@atohasi.mickey.ai.kyutech.ac.jp> To: ken@plutotech.com Cc: garbanzo@hooked.net, dmiller@search.sparks.net, akiyama@kme.mei.co.jp, freebsd-hackers@FreeBSD.ORG, ohashi@mickey.ai.kyutech.ac.jp Subject: Re: DVD-ram In-Reply-To: Your message of "Wed, 7 Jul 1999 12:39:53 JST". <199907070339.VAA88466@panzer.kdm.org> From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for many suggestions. I'll try latest CAM system. ken>>Can you make source code to the OD driver available, so I can take a look ken>>at it, and see what sorts of things you have to do to make these drives ken>>work? I am a beta tester of the new od driver. It almost works fine on some beta testers system, but we cannot redistribute without Mr. Akiyama's permit. I have a new question. If od driver is needless, why cd and da drivers are sepalate yet? Only difference is TOC ioctls, isn't it? Thanks. -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 22: 8:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 4B29914CA4; Tue, 6 Jul 1999 22:08:26 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id OAA61600; Wed, 7 Jul 1999 14:08:05 +0900 (JST) Message-Id: <199907070508.OAA61600@rina.naklab.dnj.ynu.ac.jp> To: utz@serv.net Cc: freebsd-multimedia@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: MPU401 now works under New Midi Driver Framework with a FineTimer From: Seigo Tanimura In-Reply-To: Your message of "Tue, 6 Jul 1999 11:12:59 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 07 Jul 1999 14:08:04 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 6 Jul 1999 11:12:59 -0700 (PDT), The Utz Family said: utz> (perhaps it might be time to change the name of the patch subdir from utz> serial-midi to something else?) Definitely. The patches themselves are now 'newmidi-...' so I have s/freebsd-serialmidi/freebsd-newmidi/ed the URIs. (the old dir is symlinked, so it should not make a trouble) Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 22:38:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 70BED1511C for ; Tue, 6 Jul 1999 22:38:47 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA88983; Tue, 6 Jul 1999 23:36:13 -0600 (MDT) (envelope-from ken) Message-Id: <199907070536.XAA88983@panzer.kdm.org> Subject: Re: DVD-ram In-Reply-To: <199907070458.NAA01916@atohasi.mickey.ai.kyutech.ac.jp> from Takeshi OHASHI at "Jul 7, 1999 01:58:07 pm" To: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) Date: Tue, 6 Jul 1999 23:36:12 -0600 (MDT) Cc: ken@plutotech.com, garbanzo@hooked.net, dmiller@search.sparks.net, akiyama@kme.mei.co.jp, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (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 Takeshi OHASHI wrote... > Thanks for many suggestions. > > I'll try latest CAM system. Cool, I'm interested to hear how it works for you. If things don't work properly, we'll try to fix the bugs. > ken>>Can you make source code to the OD driver available, so I can take a look > ken>>at it, and see what sorts of things you have to do to make these drives > ken>>work? > > I am a beta tester of the new od driver. It almost works fine on some > beta testers system, but we cannot redistribute without Mr. Akiyama's > permit. Of course. Well, if he doesn't mind, I'd like to take a look at it at some point. > I have a new question. If od driver is needless, why cd and da drivers > are sepalate yet? Only difference is TOC ioctls, isn't it? There are more differences than just that, actually. The da driver has a dump routine and code to deal with ordered tags (no CDROM drive that I've seen can do tagged queueing, and it really only matters on write in this case). The CD driver has a builtin changer scheduler, to deal with LUN-based changers, like the Nakamichi and Pioneer boxes. (5-7 CDs, one laser, and each CD appears as a separate LUN) Because of all the audio (start, stop, play, eject, etc), TOC, and other ioctls and the changer scheduling code, the CD driver is twice as large as the DA driver. It's true that the read/write interfaces of the two drivers are very similar, but there are a number of other differences. They probably could be combined with some difficulty, but then there are booting concerns (if everything is a DA device, how can you make sure you aren't booting off a CDROM drive?), major numbers, and device names to think about as well. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 6 23:46:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from phi.sinica.edu.tw (phi.sinica.edu.tw [140.109.7.52]) by hub.freebsd.org (Postfix) with SMTP id CBAF7150AF for ; Tue, 6 Jul 1999 23:46:06 -0700 (PDT) (envelope-from ycheng@phi.sinica.edu.tw) Received: (qmail 29254 invoked by uid 1005); 7 Jul 1999 06:45:33 -0000 Date: 7 Jul 1999 06:45:33 -0000 Message-ID: <19990707064533.29253.qmail@phi.sinica.edu.tw> From: ycheng@phi.sinica.edu.tw To: freebsd-hackers@freebsd.org Subject: Re: DVD-ram In-Reply-To: <199907070246.LAA01724@atohasi.mickey.ai.kyutech.ac.jp> <199907070339.VAA88466@panzer.kdm.org> Reply-To: ycheng@sinica.edu.tw User-Agent: tin/pre-1.4-981225 ("Volcane") (UNIX) (Linux/2.2.2 (i686)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907070339.VAA88466@panzer.kdm.org> you wrote: >> 3.5" 650MB and 1.3GB MO drives should handle 512KB/sector(128MB, >> 230MB, 540MB) and 2048KB/sector media(640MB, 1.3GB). > The CAM DA driver was specifically designed to handle various sector sizes, > and should work fine with non-512 byte sector sizes. If it doesn't, it > needs to be fixed. I use "Mitsubishi MCA 640" with Tekram 390F scsi card. I guess one of error message is from /usr/src/sys/kern/subr_diskslice.c line 308 (or line 314, I am not very sure) which is: "dscheck: b_bcount %ld is not on a sector boundary (ssize %d)\n" I think this can help you to find why we say that 2048/sector won't work. Thank you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 0:15:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 7846E14DA5 for ; Wed, 7 Jul 1999 00:15:01 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id KAA16620; Wed, 7 Jul 1999 10:10:20 +0300 (EEST) (envelope-from will) To: zzhang@cs.binghamton.edu (Zhihui Zhang) Cc: hackers@freebsd.org Subject: Re: Overwrite an executable file that is running References: From: Ville-Pertti Keinonen Date: 07 Jul 1999 10:10:19 +0300 In-Reply-To: zzhang@cs.binghamton.edu's message of "7 Jul 1999 05:11:56 +0300" Message-ID: <86pv25q6jo.fsf@not.demophon.com> Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG zzhang@cs.binghamton.edu (Zhihui Zhang) writes: > For a big executable file that is being run by the OS, all its contents > may not be loaded into the memory. At the same time, the developer gets > impatient and wants to create a new version of the same file. He could > modify the makefile to output the new version to a different file name, > but this is tedious. This new version should not overwrite the older > verion of the file being run. My question is how FreeBSD prevents this > from happening? Can anyone point out for me where in the source code this It is prevented by not allowing it. A file cannot simultaneously be executing and opened for writing. To find the relevant bits in the sources, try: grep ETXTBSY /sys/kern/* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 0:45:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from NTTMSCCJ02.nttmsc.com.my (unknown [203.106.4.3]) by hub.freebsd.org (Postfix) with SMTP id 850C715345; Wed, 7 Jul 1999 00:45:36 -0700 (PDT) (envelope-from ettikan@nttmsc.com.my) Received: by NTTMSCCJ02.nttmsc.com.my(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id C82567A7.00255010 ; Wed, 7 Jul 1999 15:47:33 +0900 X-Lotus-FromDomain: NTTMSC From: "Ettikan Kandasamy" To: freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Message-ID: Date: Wed, 7 Jul 1999 15:47:29 +0900 Subject: PCCARD Installation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I'm trying to install 3Com Fast Ethernet 10/100 Base-TX (model 3CCFE575BT-D) into my Dell laptop-freeBSD 2.2.8. Could some one help me with the setup/installation procedure. I tried modifying the GENERIC file for the kernel and /etc/pccard* files. But did not succeed. 1) Does FreeBSD 2.2.8 has the driver for it or I need to download it. ( if no where can I download it) ? 2) Is there any page gives the step by step installation guide for this purpose ?? Let me know. 3) If not how/ where to begin ?? Thanks for the help. Ettikan. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 1: 2:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (Postfix) with ESMTP id 5096314C8B for ; Wed, 7 Jul 1999 01:02:04 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id KAA32611 for ; Wed, 7 Jul 1999 10:02:01 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m111meX-002ZjZC; Wed, 7 Jul 99 10:02 MET DST Received: from bert.kts.org([194.55.156.2]) (1579 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Wed, 7 Jul 1999 10:01:50 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #5 built 1999-Apr-19) Received: from localhost (1129 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Wed, 7 Jul 1999 10:04:24 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: howto allocate 32k phys. mem-space in driver ? To: freebsd-hackers@freebsd.org (FreeBSD Hackers) Date: Wed, 7 Jul 1999 10:04:24 +0200 (CEST) Organization: Kitchen Table Systems Reply-To: hm@kts.org 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 Hi, perhaps i don't see the wood for trees. I'd like to write a driver for a PCI ISDN chipset which uses a 32k byte memory window as a sort of "dual ported ram" in the memory address space. What has to be done in the driver attach routine is - allocate a 32k contingous memory window - get the physical address of it - program the ISDN PCI chipset with the start address of the window Now can i just malloc 32k and then use vtophys() to get the physical start address to program the PCI chip with ? hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 1: 8:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from agamaweb.agama.ru (www.agama.com [195.94.226.130]) by hub.freebsd.org (Postfix) with SMTP id 5A21F14FA7 for ; Wed, 7 Jul 1999 01:08:17 -0700 (PDT) (envelope-from andrey@agama.com) Received: from [195.94.226.144] by agamaweb.agama.com (NTMail 4.01.0008/NU2432.00.3e8112ca) with ESMTP id gqgbaaaa for ; Wed, 7 Jul 1999 12:04:12 +0400 Message-ID: <000701bec850$311d3850$90e25ec3@agama.ru> From: "Andrew Iltchenko" To: References: <199907061659.JAA15453@vashon.polstra.com> Subject: Re: Dynamic linking Date: Wed, 7 Jul 1999 12:10:35 +0400 Organization: Agama MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How clever Jhon. I know that a void function cannot return a value, the same is also true of destructors and constractors, to be exact. I asked, how I can make dlopen return an error from the shared object's _init function, and not what value I should return from the void function to fail dlopen. I mean what function shall I call from _init so that dlopen will return error. I am sure it is possible, because dlopen calls _init prior to returning. ----- Original Message ----- From: John Polstra To: Cc: Sent: Tuesday, July 06, 1999 8:59 PM Subject: Re: Dynamic linking > In article <3780AEB2.206160E0@agama.com>, > Andrew Iltchenko wrote: > > Hi everyone! > > > > Is there a way of making dlopen return an error from the shared object's > > _init function? > > No. The _init function by definition is "void _init(void)", and so > it cannot return a value. > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 1:14: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 94A3314FA7; Wed, 7 Jul 1999 01:13:50 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id RAA06663; Wed, 7 Jul 1999 17:43:47 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA01450; Wed, 7 Jul 1999 17:43:46 +0930 (CST) Date: Wed, 7 Jul 1999 17:43:46 +0930 From: Greg Lehey To: Ettikan Kandasamy Cc: FreeBSD Questions Subject: Re: PCCARD Installation Message-ID: <19990707174346.G447@freebie.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Ettikan Kandasamy on Wed, Jul 07, 1999 at 03:47:29PM +0900 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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 [following up to -questions; -hardware and -hackers are not appropriate for this question] On Wednesday, 7 July 1999 at 15:47:29 +0900, Ettikan Kandasamy wrote: > > > I'm trying to install 3Com Fast Ethernet 10/100 Base-TX (model > 3CCFE575BT-D) into my Dell laptop-freeBSD 2.2.8. Could some one help me with the > setup/installation procedure. > > I tried modifying the GENERIC file for the kernel and /etc/pccard* files. But > did not succeed. > > 1) Does FreeBSD 2.2.8 has the driver for it or I need to download > it. ( if no where can I download it) ? I don't know. I don't see this particular model anywhere in our documentation, but it's likely that the 3C579/3C589 driver would work. In any case, I'd recommend you move to FreeBSD 3.2 before expending a lot of work on a release which is no longer supported. > 2) Is there any page gives the step by step installation guide for > this purpose. ?? Let me know. It appears that there isn't. > 3) If not how/ where to begin ?? Well, I'm planning to write a chapter about mobile computing in the next edition of "The Complete FreeBSD", but it's not in any shape to show at the moment. Basically, here's what you need to do: 1. Build a kernel with the following device entries: # PCCARD (PCMCIA) support controller card0 device pcic0 at card? irq 0 device pcic1 at card? irq 0 2. Copy /etc/pccard.conf.sample to /etc/pccard.conf. 3. Run pccardd (just start it). 4. Insert your PCMCIA board. 5. Watch the messages that appear on the console. You'll get one of these (or something like it): Jul 7 17:33:53 mojave pccardd[56962]: No card in database for "3Com Corporation"("3CCFE575BT-D") This message shows that pccardd has found the card, but that it doesn't know how to configure it. ep0: utp/bnc[*UTP*] address 00:60:97:40:fb:e1 This one means that pccardd has found the card and has configured it. 6. I think it's unlikely that the standard pccardd will recognize your card, since nothing I've seen recognizes the 3CCFE575BT-D ID. Look at the contents of /etc/pccard.conf. You'll find an entry like: # 3Com Etherlink III 3C589D card "3Com Corporation" "3C589D" config 0x1 "ep0" ? insert echo 3Com Etherlink III inserted insert /etc/pccard_ether ep0 remove echo 3Com Etherlink III removed remove /sbin/ifconfig ep0 delete Change the second line of this entry to: card "3Com Corporation" "3CCFE575BT-D" The two strings must be *exactly* what appeared in the console message above. Save the file, stop pccardd (kill will do it) and restart it. With any luck, pccardd should bind the driver to the board, and the driver should recognize it. Let me know how this works; I need some examples for the book, and this would help me too. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page 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 7 2:50:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id D6B6A15483 for ; Wed, 7 Jul 1999 02:50:00 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id SAA16723; Wed, 7 Jul 1999 18:49:52 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id SAA02232; Wed, 7 Jul 1999 18:49:51 +0900 (JST) Date: Wed, 7 Jul 1999 18:49:51 +0900 (JST) Message-Id: <199907070949.SAA02232@atohasi.mickey.ai.kyutech.ac.jp> To: ycheng@sinica.edu.tw Cc: freebsd-hackers@freebsd.org, ohashi@mickey.ai.kyutech.ac.jp Subject: Re: DVD-ram In-Reply-To: Your message of "Wed, 7 Jul 1999 15:45:33 JST". <19990707064533.29253.qmail@phi.sinica.edu.tw> From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ycheng>>In article <199907070339.VAA88466@panzer.kdm.org> you wrote: ycheng>>>> 3.5" 650MB and 1.3GB MO drives should handle 512KB/sector(128MB, ycheng>>>> 230MB, 540MB) and 2048KB/sector media(640MB, 1.3GB). Ofcouse, my typo: 512KB/sector -> 512B/sector, 2048KB/sector -> 2048B/sector ycheng>>> The CAM DA driver was specifically designed to handle various sector sizes, ycheng>>> and should work fine with non-512 byte sector sizes. If it doesn't, it ycheng>>> needs to be fixed. ycheng>>I use "Mitsubishi MCA 640" with Tekram 390F scsi card. ycheng>>I guess one of error message is from ycheng>> ycheng>>/usr/src/sys/kern/subr_diskslice.c ycheng>> line 308 (or line 314, I am not very sure) ycheng>> which is: ycheng>> "dscheck: b_bcount %ld is not on a sector boundary (ssize %d)\n" ycheng>> ycheng>>I think this can help you to find why we say that 2048/sector won't work. Thanks. But that was disklabel or slice problem. And also current ffs and msdosfs need some patches for 2048 sector media. -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.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 7 3: 3:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall2.lehman.com (firewall.Lehman.COM [192.147.65.99]) by hub.freebsd.org (Postfix) with ESMTP id 713F514DAF; Wed, 7 Jul 1999 03:03:53 -0700 (PDT) (envelope-from nclayton@lehman.com) Received: from relay3.messaging-svcs5.lehman.com by firewall2.lehman.com (8.8.6/8.8.6) id GAA16089; Wed, 7 Jul 1999 06:03:44 -0400 (EDT) Message-ID: <19990707110320.U15628@lehman.com> Date: Wed, 7 Jul 1999 11:03:20 +0100 From: Nik Clayton To: chris@calldei.com Cc: Bill Fumerola , doc@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Searching the Handbook (was Re: 'rtfm script') References: <19990705141635.D97224@holly.dyndns.org> <19990706115526.Z15628@lehman.com> <19990706165708.N4158@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990706165708.N4158@holly.dyndns.org>; from Chris Costello on Tue, Jul 06, 1999 at 04:57:08PM -0500 Organization: Lehman Brothers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 04:57:08PM -0500, Chris Costello wrote: > On Tue, Jul 6, 1999, Nik Clayton wrote: > > There are a couple of ways you could do it. Some of them more optimal > > than others. > > > > Executive summary: sgrep is probably your best choice now, which can > > can be found at . > > But read on for more. > > > > The simplest way is to assume that the user has the plain text handbook > > installed, and do a simple grep through that for what you're looking for. > > See the FAQ parser. I want to be able to get meaningful > output for users. sgrep is also not viable because it's not in > the default system. Neither is rtfm(1) yet. Why not put them in ports, publicise them in the FAQ (OK, I realise that's a bit of a chicken/egg problem), lobby JKH to get it mentioned when installing the system, publicise it on the -newbie's list, and so on. I'd be surprised if this was something that was bought in to the system straight away -- pushing it through ports first seems like the natural way to do it. > > This is nice and easy to do, but doesn't take advantage of the additional > > smarts built in to the Handbook's native format. To do that requires some > > additional work. > > The handbook's native format won't be on the default system, > will it? They're all in HTML. You are in a maze of twist future plans, all different. I want to pull the Handbook (and other documentation, like the FAQ) out of the system as it currently stands. Instead, these should be packages, and available in a variety of different formats. At install time, sysinstall can present the user with a list of documentation options they want (including "All docs, all formats"), which will just pkg_add(1) the appropriate files. This doesn't work yet, because I haven't put the code to build the packages in to the doc/ Makefiles yet. If anyone wants to collabotate on this (or, better yet, present me with code that does it) please stand up and be counted. > > A smart searching mechanism will be able to use this additional semantic > > information to reject (or lower the rankings of) results that don't match > > what the user wanted. > > See above. I want rtfm(1) to remain viable on base installs. I'm not sure you do. You want rtfm(1) to remain viable on "newbie" installs. With a "base" install you can't even count on the manual pages being available. > > You could go the full SGML route. This would involve building an > > application that can parse the DocBook source of the Handbook (and other > > articles, and soon to be the FAQ) and allow the user to do their queries > > using this application. This is probably the most 'correct' route from > > a purist point of view, but is an awful lot of work. > > If the FAQ is to be DocBook-ified, will the SGML sources be > made availible via HTTP so rtfm(1) can still cleanly parse them > with a minor rewrite of the FAQ section? Yes, you could do it that way. I prefer the package approach, where you'll have packages like fdp-books-faq-html.tgz fdp-books-faq-sgml.tgz fdp-books-faq-html-split.tgz fdp-books-faq-xml.tgz fdp-books-faq-rtf.tgz and so on. Makes it vastly easier for tools like yours to say In order to have the greatest chance of finding what you want, you need to install the SGML sources for the FAQ. If you do not install these sources your searches will still work, but have a greater chance of returning false hits. The SGML source will take up roughly 500KB of disk space. Do you want to install the FAQ SGML source now? [Y]: As I say, for this to work we need to build packages from the doc/ repository -- I haven't had the time to investigate doing this yet. N -- --+==[ Systems Administrator, Year 2000 Test Lab, Lehman Brothers, Inc. ]==+-- --+==[ 1 Broadgate, London, EC2M 7HA 0171-601-0011 x5514 ]==+-- --+==[ Year 2000 Testing: It's about time. . . ]==+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 3:30: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id 61ABD14C8D; Wed, 7 Jul 1999 03:30:01 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id TAA16813; Wed, 7 Jul 1999 19:07:05 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id TAA02260; Wed, 7 Jul 1999 19:07:04 +0900 (JST) Date: Wed, 7 Jul 1999 19:07:04 +0900 (JST) Message-Id: <199907071007.TAA02260@atohasi.mickey.ai.kyutech.ac.jp> To: ettikan@nttmsc.com.my Cc: freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, ohashi@mickey.ai.kyutech.ac.jp Subject: Re: PCCARD Installation In-Reply-To: Your message of "Wed, 7 Jul 1999 15:47:29 JST". From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ettikan>> I'm trying to install 3Com Fast Ethernet 10/100 Base-TX (model ettikan>>3CCFE575BT-D) into my Dell laptop-freeBSD 2.2.8. Could some one help me with the ettikan>>setup/installation procedure. If the card is CardBus card, it would not be use on a normal FreeBSD box. FreeBSD-2.2.8 and even -currnet don't support any CardBus cards, they only support 16bits PC cards. My 3Com 10/100 LAN CardBus PC card(3CCFE575BT-JP) works fine on FreeBSD box, but the kernel is built by FreeBSD newconfig project. http://www.jp.FreeBSD.org/newconfig/ Thanks. -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.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 7 5: 8:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 80BB314BB8 for ; Wed, 7 Jul 1999 05:08:11 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id VAA19131; Wed, 7 Jul 1999 21:38:07 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA13845; Wed, 7 Jul 1999 21:38:07 +0930 Date: Wed, 7 Jul 1999 21:38:07 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: hackers@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990706175814.3A9CE78@overcee.netplex.com.au> 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, 7 Jul 1999, Peter Wemm wrote: > Say... you wouldn't like to impliment an NT-style password hash, would you? This is actually very easy, it turns out - the NT hash is just an MD4 over the unicode version of the password, which is (for the default english locale or whatever you call it), just the ascii character string padded out to be 16-bit little-endian (i.e. alternating the 8bit characters with zero bytes). MS-CHAP then takes this password hash and encrypts it with the challenge which is communicated to the peer, so the password hash is effectively plaintext equivalent for the purpose of the handshake. I'm not sure whether this would help out ppp at all except by breaking out the code into libcrypt(), since you're not authenticating with your local account password, and since PPPD is maintained externally the code would stay there for the general (non-FreeBSD) case. This would make samba account management easier as there's only one password file to keep in sync. Even though MD4 is insecure and therefore makes a bad password hashing algorithm, if you're running samba for the purposes of authenticating a user against an NT domain then you already have a copy of the (samba) password file on-hand so you can just break that one if you're evil. I should have the code ready by tomorrow night. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 6: 0: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall2.lehman.com (firewall.Lehman.COM [192.147.65.99]) by hub.freebsd.org (Postfix) with ESMTP id 077B714D79; Wed, 7 Jul 1999 05:59:57 -0700 (PDT) (envelope-from nclayton@lehman.com) Received: from relay3.messaging-svcs5.lehman.com by firewall2.lehman.com (8.8.6/8.8.6) id IAA15356; Wed, 7 Jul 1999 08:59:52 -0400 (EDT) Message-ID: <19990707135918.A15628@lehman.com> Date: Wed, 7 Jul 1999 13:59:18 +0100 From: Nik Clayton To: Kazutaka YOKOTA , hackers@freebsd.org, doc@freebsd.org Cc: bde@freebsd.org, wpaul@freebsd.org, rnordier@freebsd.org, nik@freebsd.org Subject: Re: README.serial update? References: <199907061020.TAA09981@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199907061020.TAA09981@zodiac.mech.utsunomiya-u.ac.jp>; from Kazutaka YOKOTA on Tue, Jul 06, 1999 at 07:20:10PM +0900 Organization: Lehman Brothers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 07:20:10PM +0900, Kazutaka YOKOTA wrote: > >From time to time people ask questions about the serial console. As > README.serial is buried deep inside the kernel source tree, it's almost > time to have a decent text on the serial console in our handbook. > > I am reformatting README.serial so that it can be included in our > handbook, and adding bits and pieces to clarify things. I haven't > finished it yet, but would like to have your comments now, so that we > can make it more informative and useful. This is great. Every now and then someone says "Hey, Nik, the Doc. Proj., is dying, no one's writing new docs" and then people like you submit something like this and help prove them wrong. > I put up the HTML version in: > > http://www.freebsd.org/~yokota/serialconsole.html > > and the SGML version in: > > ftp://www.freebsd.org/~yokota/serial-console.sgml I couldn't get the .sgml using FTP, but it was fine using HTTP. This might just be because of the firewall settings here. > - I am not a SGML expart ;-< formatting and links may be wrong. I'll get on to that in a second. > - The chapter number is arbitrary. When this text will be eventually > included in the handbook, I expect Nik will put it somewhere suitable > and give appropriate chapter number. Looking at the Handbook as it stands at the moment, a couple of places look like they might be suitable. (a) As a chapter somewhere in part 2 ("System Administration"). (b) As a section inside chapter 14 ("Serial Communications"). (c) As a chapter somewhere in part 4 ("Advanced topics"). I think (b) can probably be ruled out, as the rest of that part deals with network communications. Of the other two options, I'm leaning towards (a) rather than (c). As to the text and the SGML formatting; I'll change the text a little bit before committing it. There are a few areas where you've used a plural instead of a singular, and general policy in the documentation is to avoid contractions like "don't" in favour of "do not" and the like. But apart from these very small nits the text is great -- your English is certainly much better than my Japanese. The SGML formatting is also off, see http://www.freebsd.org/tutorials/docproj-primer/x2041.html for more specific information. But this should only take me 10 minutes or so in Emacs to fix up, so don't worry about it. I'm very grateful to you for taking the time to do this. If you could let me know when you're happy with the text I'll do a final edit and commit it. Once again, thanks very much. N -- --+==[ Systems Administrator, Year 2000 Test Lab, Lehman Brothers, Inc. ]==+-- --+==[ 1 Broadgate, London, EC2M 7HA 0171-601-0011 x5514 ]==+-- --+==[ Year 2000 Testing: It's about time. . . ]==+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 7:15:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 63DDB14BC9 for ; Wed, 7 Jul 1999 07:15:48 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id HAA71896; Wed, 7 Jul 1999 07:15:47 -0700 (PDT) Date: Wed, 7 Jul 1999 07:15:47 -0700 (PDT) From: David Wolfskill Message-Id: <199907071415.HAA71896@pau-amma.whistle.com> To: jwd@unx.sas.com Subject: Re: Connect and so on.. Cc: freebsd-hackers@freebsd.org In-Reply-To: <199907070227.WAA83834@bb01f39.unx.sas.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: "John W. DeBoskey" >Date: Tue, 6 Jul 1999 22:27:39 -0400 (EDT) This part may well actually be relevant to -hackers (albeit in a way that will probably seem heretical to some): > Never underestimate the power of good user exits and the >ability to implement your own External Security Manager... [Fair warning: this is long. Sorry; I'm hoping some of it might actually be of interest or use. dhw] Actaully, I have found the "user exit" approach to be extremely powerful as a means of implementing local policy, while maintaining a clear distinction between the vendor-provided codebase & the site's code. It also provided an API for accomplishing these things (though it was a separate API for each "user exit", and the quality of the API thus varied from one exit point to another -- but the "variable quality" aspect is an implementation artifact, more than anything else). Back to -hackers, I've been using and (many times, by necessity) administering UNIX systems since '86. It seems to me that having points within "privileged" code where the OS could invoke site-supplied code on the way in (so the site-supplied code would be able to examine, and possibly replace, a parameter list), the OS could check some sort of "return code" from the site-supplied code (absence of the code being treated as pathologically equivalent to "return code 0"), and either continue processing with the (possibly replaced) parameter list or terminate processing early. then, if processing did take place, just before retunring control to the user-level code, see if there's a post-processing exit point, and if so, pass control to it (first), to perform any additional site-specific policy. The big advantage, it seems to me, is providing these "hooks" so that a given installation, site, machine, or whatever can be customized (possibly fairly extensively)... without touching the OS at all (once the hooks are in place, of course). Granted, with FreeBSD (as well as the other 4.4Lite descendants, and Linux), one has full sources, and can customize it to any extent imaginable. But then re-integrating any such changes in whatever next release of the OS you use can well be a royal pain: since full sources are available, it becomes easy to over-customize... which can contribute to making the re-integration more difficult. The "user exit" approach imposes some discipline; it was originally taken (in the MVS world) because (for example) JES2 was provided in full source form, and folks would make site-specific modifications to the source. Then when it came time to upgrade JES2 or the OS, various things would break in the usual wonderfully pleasant ways familiar to anyone who modifies OSs. This resulted in much whining (typically, in the form of support calls, but also a fair amount of groaning and moaning at SHARE), and IBM decided to impose the dreaded "OCO" ("Object Code Only") policy: no more looking at the microfiche assemply listings for the OS and its components, and many of the data structures (called "control blocks" in MVS) became documented only in that their existence at size was acknowledged, but their contents were intentionally undocumented, so that IBM would be under no obligation (in theory) to document changes to such structures. To counter-balance this, IBM provided several additional "exit points" (as described above). Now, at some point, especially given recent (last month's) history with respect to my employer & IBM, I should highlight a couple of things: * I'm not intending to represent Whistle or IBM in any of this. * The above observations were formed over a period (starting in '69) during which I've dealt with IBM, its products, and IBMers, and the last 30 days haven't had a chance to impact that history a whole lot. And I've never worked for IBM before. * I'm certainly *not* holding up MVS as an example of anything approaching perfection. (The interpretation "Man Versus System" is not for nought.) However, I believe that there were a few good ideas in there, and if the FreeBSD community can learn from others' experiences, that's to the good. Who knows; there might even be a good idea embodied somewhere in some code from Redmond -- but I'll leave it to someone else to discuss that. Anyway, like the stuff the RACF & resource managers, I'm certainly willing to discuss this type of thing in more detail, but I suspect that most folks on -hackers would rather the discussion took place elsewhere (at least for now), so I'll be quiet (on -hackers) for a bit, but welcome out-of-band discussion. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 7:19:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 3307014EBB; Wed, 7 Jul 1999 07:19:18 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id KAA02734; Wed, 7 Jul 1999 10:21:29 -0400 From: Bill Paul Message-Id: <199907071421.KAA02734@skynet.ctr.columbia.edu> Subject: Call for testers: SysKonnect gigabit ethernet driver To: hackers@freebsd.org, hardware@freebsd.org Date: Wed, 7 Jul 1999 10:21:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3410 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a call for testers for yet another gigabit ethernet driver. If you happen to have a SysKonnect gigabit ethernet server adapter and want to use it with FreeBSD, then please try the driver code at: http://www.freebsd.org/~wpaul/SysKonnect Currently I only have a driver for FreeBSD 3.0 and up. The following cards are supported: - SK-9841 1000baseLX, single port, single mode fiber - SK-9842 1000baseSX, single port, multimode fiber - SK-9843 1000baseLX, dual port, single mode fiber - SK-9844 1000baseSX, dual port, multimode fiber Yes, that's right: dual port gigabit ethernet. :) SysKonnect's driver software currently only uses the dual port adapters in a failover configuration, where the second port is monitored by the driver and only activated if the link on the primary port fails. This driver doesn't use that approach: instead, both ports are treated as separate and independent logical network interfaces. This means you should see something like the the following: skc0: rev 0x10 int a irq 11 on pci0.14.0 skc0: SysKonnect SK-NET Gigabit Ethernet Adapter SK-9844 SX dual link sk0: at skc0 port 0 sk0: Ethernet address: 00:00:5a:98:21:6c sk1: at skc0 port 1 sk1: Ethernet address: 00:00:5a:98:21:6d Yes, you can have both interfaces up and running at once. The SysKonnect cards use the XaQti XMAC II gigabit ethernet MAC and a controller designed by SysKonnect called the GEnesis. It is the GEnesis controller that provides all the PCI logic, plus other functions. The GEnesis controller can have up to two XMACs connected; single port cards have only one, of course. Information about the cards, including programming manuals for the GEnesis controller, can be found at http://www.syskonnect.com. The datasheet for the XaQti XMAC II can be found at http://www.xaqti.com. The sk driver supports hardware multicast filtering, BPF, promiscuous mode and jumbo frames up to 9000 bytes. It should also work on both FreeBSD/i386 and FreeBSD/alpha. To add the driver to an existing system: - Download if_sk.c, if_skreg.h, xmaciireg.h and if_media.h from http://www.freebsd.org/~wpaul/SysKonnect/3.0. - Copy if_sk.c, if_skreg.h and xmaciireg.h to /sys/pci - If you have a version of FreeBSD older than 3.2-RELEASE, copy if_media.h to /sys/net and /usr/include/net. You may also want to recompile ifconfig at this point, though it's not mandatory. - Edit /sys/conf/files and add a line that says: pci/if_sk.c optional sk device-driver - Edit your kernel config file (e.g. /sys/i386/conf/GENERIC) and add a line that says: device sk0 - Compile a new kernel and boot it. NOTE: make sure to recompile if_media.c now that the new if_media.h is in place. If you have problems, please send them to wpaul@skynet.ctr.columbia.edu. Include lots of details. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 9: 0:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mickey00.mickey.ai.kyutech.ac.jp (mickey00.mickey.ai.kyutech.ac.jp [131.206.21.1]) by hub.freebsd.org (Postfix) with ESMTP id C61EC14E03 for ; Wed, 7 Jul 1999 09:00:11 -0700 (PDT) (envelope-from ohashi@mickey.ai.kyutech.ac.jp) Received: from atohasi.mickey.ai.kyutech.ac.jp (atohasi.mickey.ai.kyutech.ac.jp [131.206.21.80]) by mickey00.mickey.ai.kyutech.ac.jp (8.9.3/3.7W-mickey) with ESMTP id AAA17843; Thu, 8 Jul 1999 00:58:48 +0900 (JST) Received: (from ohashi@localhost) by atohasi.mickey.ai.kyutech.ac.jp (8.9.3/3.7W) id AAA02586; Thu, 8 Jul 1999 00:58:47 +0900 (JST) Date: Thu, 8 Jul 1999 00:58:47 +0900 (JST) Message-Id: <199907071558.AAA02586@atohasi.mickey.ai.kyutech.ac.jp> To: ken@plutotech.com Cc: garbanzo@hooked.net, dmiller@search.sparks.net, akiyama@kme.mei.co.jp, freebsd-hackers@FreeBSD.ORG, ohashi@mickey.ai.kyutech.ac.jp Subject: Re: DVD-ram In-Reply-To: Your message of "Wed, 7 Jul 1999 14:36:12 JST". <199907070536.XAA88983@panzer.kdm.org> From: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ken>>> I am a beta tester of the new od driver. It almost works fine on some ken>>> beta testers system, but we cannot redistribute without Mr. Akiyama's ken>>> permit. ken>> ken>>Of course. Well, if he doesn't mind, I'd like to take a look at it at some ken>>point. He is preparing the review version of od-driver. Please wait some days. ken>>> I have a new question. If od driver is needless, why cd and da drivers ken>>> are sepalate yet? Only difference is TOC ioctls, isn't it? ken>>It's true that the read/write interfaces of the two drivers are very ken>>similar, but there are a number of other differences. They probably could ken>>be combined with some difficulty, but then there are booting concerns (if ken>>everything is a DA device, how can you make sure you aren't booting off a ken>>CDROM drive?), major numbers, and device names to think about as well. Thank you for your answer. I think this situation is like as OD devices. Some DVD-RAM/MO/PD drives are recognized as DA and others are CD. For example, A PD media is used as a DA on PD drives. The PD media is used as a CD on DVD-RAM and DVD-ROM drives. It is very confusing. Sometime we want to disable booting from these devices. The reason why we want od driver. -- Takeshi OHASHI ohashi@mickey.ai.kyutech.ac.jp ohashi@jp.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 7 9:17:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9A46315063 for ; Wed, 7 Jul 1999 09:17:28 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA91832; Wed, 7 Jul 1999 10:16:13 -0600 (MDT) (envelope-from ken) Message-Id: <199907071616.KAA91832@panzer.kdm.org> Subject: Re: DVD-ram In-Reply-To: <199907071558.AAA02586@atohasi.mickey.ai.kyutech.ac.jp> from Takeshi OHASHI at "Jul 8, 1999 00:58:47 am" To: ohashi@mickey.ai.kyutech.ac.jp (Takeshi OHASHI) Date: Wed, 7 Jul 1999 10:16:13 -0600 (MDT) Cc: garbanzo@hooked.net, dmiller@search.sparks.net, akiyama@kme.mei.co.jp, freebsd-hackers@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (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 Takeshi OHASHI wrote... > ken>>> I am a beta tester of the new od driver. It almost works fine on some > ken>>> beta testers system, but we cannot redistribute without Mr. Akiyama's > ken>>> permit. > ken>> > ken>>Of course. Well, if he doesn't mind, I'd like to take a look at it at some > ken>>point. > > He is preparing the review version of od-driver. Please wait some days. Cool. > ken>>> I have a new question. If od driver is needless, why cd and da drivers > ken>>> are sepalate yet? Only difference is TOC ioctls, isn't it? > > ken>>It's true that the read/write interfaces of the two drivers are very > ken>>similar, but there are a number of other differences. They probably could > ken>>be combined with some difficulty, but then there are booting concerns (if > ken>>everything is a DA device, how can you make sure you aren't booting off a > ken>>CDROM drive?), major numbers, and device names to think about as well. > > Thank you for your answer. > > I think this situation is like as OD devices. Some DVD-RAM/MO/PD > drives are recognized as DA and others are CD. For example, A PD media > is used as a DA on PD drives. The PD media is used as a CD on DVD-RAM > and DVD-ROM drives. It is very confusing. Sometime we want to disable > booting from these devices. It's a similar situation, but not the same. It's fairly difficult to boot off a CDROM drive, since the media is read-only. I've done it before, but it certainly isn't the usual case. A medium capable of read/write, however, could more easily be used for booting. The bottom line is, we want to avoid duplicating code if we can help it. If there is a good reason to have a separate OD driver, it can certainly be done. If it's only done so that PD drives have a different device name, I don't think that's enough to justify it. Ken -- Kenneth Merry ken@plutotech.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 7 9:26:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles522.castles.com [208.214.165.86]) by hub.freebsd.org (Postfix) with ESMTP id 061F3151FD for ; Wed, 7 Jul 1999 09:26:30 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id JAA04081; Wed, 7 Jul 1999 09:22:44 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907071622.JAA04081@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: David Wolfskill Cc: jwd@unx.sas.com, freebsd-hackers@freebsd.org Subject: Re: Connect and so on.. In-reply-to: Your message of "Wed, 07 Jul 1999 07:15:47 PDT." <199907071415.HAA71896@pau-amma.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jul 1999 09:22:43 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Back to -hackers, I've been using and (many times, by necessity) > administering UNIX systems since '86. It seems to me that having points > within "privileged" code where the OS could invoke site-supplied code on > the way in (so the site-supplied code would be able to examine, and > possibly replace, a parameter list), the OS could check some sort of > "return code" from the site-supplied code (absence of the code being > treated as pathologically equivalent to "return code 0"), and either > continue processing with the (possibly replaced) parameter list or > terminate processing early. then, if processing did take place, just > before retunring control to the user-level code, see if there's a > post-processing exit point, and if so, pass control to it (first), to > perform any additional site-specific policy. For system calls at least, you can already do this with KLDs (and you used to be able to do it with LKMs). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ 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 7 11:19:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 6F21C14C17 for ; Wed, 7 Jul 1999 11:19:17 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id LAA73288; Wed, 7 Jul 1999 11:19:14 -0700 (PDT) Date: Wed, 7 Jul 1999 11:19:14 -0700 (PDT) From: David Wolfskill Message-Id: <199907071819.LAA73288@pau-amma.whistle.com> To: wilko@yedi.iaf.nl Subject: Re: Pictures from USENIX Cc: freebsd-hackers@freebsd.org In-Reply-To: <199907041706.TAA02529@yedi.iaf.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: Wilko Bulte >Date: Sun, 4 Jul 1999 19:06:48 +0200 (CEST) >> Proves my statement that it is unwise to assume the looks of people >> from their E-mail. :-) >Which makes a good case for a permanent picture gallery @ www.freebsd.org >I guess. I can donate a bunch of pictures taken at last year's >hackersparty here in the Netherlands. I'm having a sense of deja vu... flashbacks to USENIX conferences of years past and the "faces" project... and the X-Face: header on email. (ftp.uu.net:/faces/{dhw68k.cts,pooh}.com/david.Z, in case anyone cares.) Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 11:21:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8910214D7D for ; Wed, 7 Jul 1999 11:21:12 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id UAA89618; Wed, 7 Jul 1999 20:20:53 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 20:20:53 +0200 In-Reply-To: Jamie Howard's message of "Mon, 5 Jul 1999 21:14:36 -0400 (EDT)" Message-ID: Lines: 33 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > Due to the number of fixes I have received over the past few days, I > decided to put together a new release of grep. It was either this or > watch _Titanic_ on Cinemax. A clear-cut choice. > I changed it so that even when called as grep or with -G, it treats the > pattern as an extended regular expression. GNU grep behaves the same way. Hmm, well, never mind standards I guess. > Archie Cobbs dropped the hint needed to solve the problems with -x. Right > now, I wrap the pattern with "^(" and ")$". I know GNU grep does this, > but is this correct? Yes. You can solve -w in a similar manner by using \< and \>. > Now, as it stands, I beleive this implementation is identical to GNU grep, *functionally* identical. > Due to problems with the previous download site (it is down as I type > this), I will place this file in two locations: > > ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz > ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz Mirror site: ftp://ftp.ofug.org/pub/grep/ DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 11:22:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CDCED14E80 for ; Wed, 7 Jul 1999 11:22:29 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id UAA89657; Wed, 7 Jul 1999 20:22:06 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 20:22:05 +0200 In-Reply-To: Jamie Howard's message of "Tue, 6 Jul 1999 08:42:23 -0400 (EDT)" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > Ahh, this is a good idea. I have not yet replaced GNU grep on my system > with this so it has not yet occurred to me that there might be issues with > that. I tried it; it works fine except for the lack of -w. Haven't tried 0.3 yet. A good test is to build lots of ports, since the ports framework uses grep a lot. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 11:32:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 30E7414D7D; Wed, 7 Jul 1999 11:32:08 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id OAA19760; Wed, 7 Jul 1999 14:32:00 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA22096; Wed, 7 Jul 1999 14:31:29 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id OAA16835; Wed, 7 Jul 1999 14:31:29 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907071831.OAA16835@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <19990706142523.38487@right.PCS> from Jonathan Lemon at "Jul 6, 1999 02:25:23 pm" To: freebsd-hackers@freebsd.org Date: Wed, 7 Jul 1999 14:31:29 -0400 (EDT) Cc: jlemon@americantv.com, peter@netplex.com.au, freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (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've CC'd -current because of the implications there ...) Here are my patches for hardware debug register support for the i386 port. I think this is ready to be reviewed and hopefully committed. It consists of modifications to 13 files and the addition of 1 new file. The new file is listed out at the bottom of this message. My implementation consists of: * saving and restoring the debug registers at context switch time if necessary * procfs modifications to support reading/writing to the 'dbregs' file of the process, which works in an identical manner as the interface to 'regs' and 'fpregs'. * two additional request implementations for the 'ptrace()' call: PT_GETDBREGS and PT_SETDBREGS. The only thing that it does not do right now that might be useful (that I'm aware of) is include the state of the debug registers in a core dump. This was more than I wanted to get into at the moment, and would require modification of any tools that read a core dump image. Also, I've made a first pass attempt at security by denying a process the ability to set a debug watch or breakpoint outside of his address space, unless the process is owned by root. It can certainly be useful to use these registers for kernel debugging, but I thought that should be limited to the root user. I haven't done anything with the Alpha, though some of the procfs mods will affect the Alpha port, at least to the point of possibly needing to include a couple of stub functions in MD code to avoid unresolved references for 'procfs_read_dbregs()' and 'procfs_write_dbregs()'. Also, I have not included anything for 'gdb' because I just have not had time to figure it out yet. I'm hoping that someone else, who knows the gdb code better than I, can make the required modifications there for hardware debug support. Essentially, you would need to make a call like this: { struct dbreg dbregs ptrace ( PT_GETDBREGS, pid, &dbregs, 0 ); dbregs.dr7 |= 0x000d0002; dbregs.dr0 = watch_addr; ptrace ( PT_SETDBREGS, pid, &dbregs, 0 ); } This would enable the first watch address and would break whenever the 4 bytes at watch_addr were written to. An Intel ix86 systems programming manual will have detailed information on how to set up the registers for various breakpoint and watchpoint conditions. The manuals can be downloaded in pdf format from http://developer.intel.com if anyone is interested. If no one wants to take this on, I will give it a try, but I can't commit to it being done within the next week or so. Here is the patch set, generated against a current tree about 4 hours or so old. The new file that is required is listed out after the patches. Please let me know if anything else is needed or if anything needs to be changed (style or feature). Thanks to Jonathan Lemon, Peter Wemm, and others for answering my questions. Thanks, -- Brian Dean SAS Institute Inc brdean@unx.sas.com Index: conf/files =================================================================== RCS file: /usr/mirror/ncvs/src/sys/conf/files,v retrieving revision 1.228 diff -r1.228 files 364a365 > miscfs/procfs/procfs_dbregs.c standard Index: i386/i386/genassym.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/genassym.c,v retrieving revision 1.72 diff -r1.72 genassym.c 130a131,137 > printf("#define\tPCB_DR0 %#x\n", OS(pcb, pcb_dr0)); > printf("#define\tPCB_DR1 %#x\n", OS(pcb, pcb_dr1)); > printf("#define\tPCB_DR2 %#x\n", OS(pcb, pcb_dr2)); > printf("#define\tPCB_DR3 %#x\n", OS(pcb, pcb_dr3)); > printf("#define\tPCB_DR6 %#x\n", OS(pcb, pcb_dr6)); > printf("#define\tPCB_DR7 %#x\n", OS(pcb, pcb_dr7)); > printf("#define\tPCB_DBREGS %#x\n", PCB_DBREGS ); Index: i386/i386/machdep.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.353 diff -r1.353 machdep.c 1929a1930,2010 > int > fill_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > struct pcb *pcb; > > pcb = &p->p_addr->u_pcb; > dbregs->dr0 = pcb->pcb_dr0; > dbregs->dr1 = pcb->pcb_dr1; > dbregs->dr2 = pcb->pcb_dr2; > dbregs->dr3 = pcb->pcb_dr3; > dbregs->dr4 = 0; > dbregs->dr5 = 0; > dbregs->dr6 = pcb->pcb_dr6; > dbregs->dr7 = pcb->pcb_dr7; > return (0); > } > > int > set_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > struct pcb *pcb; > > pcb = &p->p_addr->u_pcb; > > /* > * Don't let a process set a breakpoint that is not within the > * process's address space. If a process could do this, it > * could halt the system by setting a breakpoint in the kernel > * (if ddb was enabled). Thus, we need to check to make sure > * that no breakpoints are being enabled for addresses outside > * process's address space, unless, perhaps, we were called by > * uid 0. > * > * XXX - what about when the watched area of the user's > * address space is written into from within the kernel > * ... wouldn't that still cause a breakpoint to be generated > * from within kernel mode? > */ > > if (p->p_cred->pc_ucred->cr_uid != 0) { > if (dbregs->dr7 & 0x3) { > /* dr0 is enabled */ > if (dbregs->dr0 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<2)) { > /* dr1 is enabled */ > if (dbregs->dr1 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<4)) { > /* dr2 is enabled */ > if (dbregs->dr2 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > > if (dbregs->dr7 & (0x3<<6)) { > /* dr3 is enabled */ > if (dbregs->dr3 >= VM_MAXUSER_ADDRESS) > return (EINVAL); > } > } > > pcb->pcb_dr0 = dbregs->dr0; > pcb->pcb_dr1 = dbregs->dr1; > pcb->pcb_dr2 = dbregs->dr2; > pcb->pcb_dr3 = dbregs->dr3; > pcb->pcb_dr6 = dbregs->dr6; > pcb->pcb_dr7 = dbregs->dr7; > > pcb->pcb_flags |= PCB_DBREGS; > > return (0); > } > Index: i386/i386/procfs_machdep.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/procfs_machdep.c,v retrieving revision 1.11 diff -r1.11 procfs_machdep.c 61a62,64 > * procfs_read_dbregs, procfs_write_dbregs > * deal with the processor debug register set, otherwise as above. > * 100a104,123 > } > > int > procfs_read_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > if ((p->p_flag & P_INMEM) == 0) > return (EIO); > return (fill_dbregs(p, dbregs)); > } > > int > procfs_write_dbregs(p, dbregs) > struct proc *p; > struct dbreg *dbregs; > { > if ((p->p_flag & P_INMEM) == 0) > return (EIO); > return (set_dbregs(p, dbregs)); Index: i386/i386/swtch.s =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/i386/swtch.s,v retrieving revision 1.83 diff -r1.83 swtch.s 482a483,502 > /* test if debug regisers should be saved */ > movb PCB_FLAGS(%edx),%al > andb $PCB_DBREGS,%al > jz 1f /* no, skip over */ > movl %dr7,%eax /* yes, do the save */ > movl %eax,PCB_DR7(%edx) > andl $0x0000ff00, %eax /* disable all watchpoints */ > movl %eax,%dr7 > movl %dr6,%eax > movl %eax,PCB_DR6(%edx) > movl %dr3,%eax > movl %eax,PCB_DR3(%edx) > movl %dr2,%eax > movl %eax,PCB_DR2(%edx) > movl %dr1,%eax > movl %eax,PCB_DR1(%edx) > movl %dr0,%eax > movl %eax,PCB_DR0(%edx) > 1: > 719a740,757 > > /* test if debug regisers should be restored */ > movb PCB_FLAGS(%edx),%al > andb $PCB_DBREGS,%al > jz 1f /* no, skip over */ > movl PCB_DR6(%edx),%eax /* yes, do the restore */ > movl %eax,%dr6 > movl PCB_DR3(%edx),%eax > movl %eax,%dr3 > movl PCB_DR2(%edx),%eax > movl %eax,%dr2 > movl PCB_DR1(%edx),%eax > movl %eax,%dr1 > movl PCB_DR0(%edx),%eax > movl %eax,%dr0 > movl PCB_DR7(%edx),%eax > movl %eax,%dr7 > 1: Index: i386/include/md_var.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/md_var.h,v retrieving revision 1.29 diff -r1.29 md_var.h 66a67 > struct dbreg; 82a84 > int fill_dbregs __P((struct proc *p, struct dbreg *dbregs)); Index: i386/include/pcb.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/pcb.h,v retrieving revision 1.28 diff -r1.28 pcb.h 56a57,64 > > int pcb_dr0; > int pcb_dr1; > int pcb_dr2; > int pcb_dr3; > int pcb_dr6; > int pcb_dr7; > 61a70 > #define PCB_DBREGS 0x02 /* process using debug registers */ Index: i386/include/ptrace.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/ptrace.h,v retrieving revision 1.6 diff -r1.6 ptrace.h 46a47,48 > #define PT_GETDBREGS (PT_FIRSTMACH + 5) > #define PT_SETDBREGS (PT_FIRSTMACH + 6) Index: i386/include/reg.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/i386/include/reg.h,v retrieving revision 1.18 diff -r1.18 reg.h 120a121,132 > struct dbreg { > unsigned int dr0; /* debug address register 0 */ > unsigned int dr1; /* debug address register 1 */ > unsigned int dr2; /* debug address register 2 */ > unsigned int dr3; /* debug address register 3 */ > unsigned int dr4; /* reserved */ > unsigned int dr5; /* reserved */ > unsigned int dr6; /* debug status register */ > unsigned int dr7; /* debug control register */ > }; > > 127a140 > int set_dbregs __P((struct proc *p, struct dbreg *dbregs)); Index: kern/sys_process.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/kern/sys_process.c,v retrieving revision 1.46 diff -r1.46 sys_process.c 277a278,283 > #ifdef PT_GETDBREGS > case PT_GETDBREGS: > #endif > #ifdef PT_SETDBREGS > case PT_SETDBREGS: > #endif 503a510,535 > > #ifdef PT_SETDBREGS > case PT_SETDBREGS: > write = 1; > /* fallthrough */ > #endif /* PT_SETDBREGS */ > #ifdef PT_GETDBREGS > case PT_GETDBREGS: > /* write = 0 above */ > #endif /* PT_SETDBREGS */ > #if defined(PT_SETDBREGS) || defined(PT_GETDBREGS) > if (!procfs_validdbregs(p)) /* no P_SYSTEM procs please */ > return EINVAL; > else { > iov.iov_base = uap->addr; > iov.iov_len = sizeof(struct dbreg); > uio.uio_iov = &iov; > uio.uio_iovcnt = 1; > uio.uio_offset = 0; > uio.uio_resid = sizeof(struct dbreg); > uio.uio_segflg = UIO_USERSPACE; > uio.uio_rw = write ? UIO_WRITE : UIO_READ; > uio.uio_procp = curp; > return (procfs_dodbregs(curp, p, NULL, &uio)); > } > #endif /* defined(PT_SETDBREGS) || defined(PT_GETDBREGS) */ Index: miscfs/procfs/procfs.h =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.26 diff -r1.26 procfs.h 53a54 > Pdbregs, /* the process's debug register set */ 126a128 > struct dbreg; 139a142,143 > int procfs_read_dbregs __P((struct proc *, struct dbreg *)); > int procfs_write_dbregs __P((struct proc *, struct dbreg *)); 142a147 > int procfs_dodbregs __P((struct proc *, struct proc *, struct pfsnode *pfsp, struct uio *uio)); 157a163 > int procfs_validdbregs __P((struct proc *)); Index: miscfs/procfs/procfs_subr.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs_subr.c,v retrieving revision 1.24 diff -r1.24 procfs_subr.c 169a170 > case Pdbregs: 265a267,270 > > case Pdbregs: > rtval = procfs_dodbregs(curp, p, pfs, uio); > break; Index: miscfs/procfs/procfs_vnops.c =================================================================== RCS file: /usr/mirror/ncvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.69 diff -r1.69 procfs_vnops.c 97a98 > { DT_REG, N("dbregs"), Pdbregs, procfs_validdbregs }, 493a495 > case Pdbregs: 572a575,578 > > case Pdbregs: > vap->va_bytes = vap->va_size = sizeof(struct dbreg); > break; ---------------------------------------------------------------------- And here is the new file: /* * Copyright (c) 1999 Brian Scott Dean, brdean@unx.sas.com. * All rights reserved. * * This code is derived from software contributed to Berkeley by * Jan-Simon Pendry under the following copyrights and conditions: * * Copyright (c) 1993 Jan-Simon Pendry * Copyright (c) 1993 * The Regents of the University of California. All rights reserved. * * This code is derived from software contributed to Berkeley by * Jan-Simon Pendry. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include #include #include #include #include #include #include int procfs_dodbregs(curp, p, pfs, uio) struct proc *curp; struct proc *p; struct pfsnode *pfs; struct uio *uio; { int error; struct dbreg r; char *kv; int kl; if (!CHECKIO(curp, p)) return EPERM; kl = sizeof(r); kv = (char *) &r; kv += uio->uio_offset; kl -= uio->uio_offset; if (kl > uio->uio_resid) kl = uio->uio_resid; PHOLD(p); if (kl < 0) error = EINVAL; else error = procfs_read_dbregs(p, &r); if (error == 0) error = uiomove(kv, kl, uio); if (error == 0 && uio->uio_rw == UIO_WRITE) { if (p->p_stat != SSTOP) error = EBUSY; else error = procfs_write_dbregs(p, &r); } PRELE(p); uio->uio_offset = 0; return (error); } int procfs_validdbregs(p) struct proc *p; { return ((p->p_flag & P_SYSTEM) == 0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 11:43:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DE6DD14D7D; Wed, 7 Jul 1999 11:43:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA92954; Wed, 7 Jul 1999 11:43:44 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 11:43:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199907071843.LAA92954@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Heh heh, humorous lockup Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, but for a kernel hacker this *should* be funny. My system locked up because it had too much memory. Specifically, there is a contrived limit to the size of the kernel malloc pool of 40MB, and 80MB for the entire pool based on VM_KMEM_SIZE_MAX. Unfortunately, if you have a lot of memory the vnode cache can actually wind up *using* 40MB, because the system isn't throwing away active VM objects and so isn't throwing away vnodes. Result: lockup. Since we have increased the hard page table allocation for the kernel to 1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was thinking of increasing it to 512MB. This increase only effects large-memory systems. It keeps them from locking up :-) Anyone have any objections? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 11:58: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id E68761544E for ; Wed, 7 Jul 1999 11:57:51 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id UAA90456; Wed, 7 Jul 1999 20:57:16 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 20:57:16 +0200 In-Reply-To: Jamie Howard's message of "Mon, 5 Jul 1999 21:14:36 -0400 (EDT)" Message-ID: Lines: 236 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > I incorporated a huge patch from Dag-Erling Smorgrav [...] Here's more :) BTW, I assume you've read this: I see you switched to using extended regexps by default, and made -E a no-op; this breaks the ports collection, so I changed it back. Sort your switch cases. Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. Don't use calloc() needlessly. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no --- grep-0.3/grep.c Mon Jul 5 21:23:18 1999 +++ des/grep.c Wed Jul 7 20:53:46 1999 @@ -28,6 +28,7 @@ #include #include + #include #include #include @@ -89,9 +90,6 @@ case 'G': Gflag++; break; - case 'Z': - Zflag++; - break; case 'L': lflag = 0; Lflag = qflag = 1; @@ -100,6 +98,9 @@ fprintf(stderr, "Jamie's grep version %u.%u\n", VER_MAJ, VER_MIN); usage(); break; + case 'Z': + Zflag++; + break; case 'a': aflag = 1; break; @@ -115,11 +116,11 @@ case 'f': if (stat(optarg, &patternstat)) err(2, "%s", optarg); - if ((pattern = calloc(1, patternstat.st_size + 1)) == NULL) - err(1, "calloc"); + pattern = grep_malloc(patternstat.st_size + 1); if ((patternfile = fopen(optarg, "r")) == NULL) err(2, "%s", optarg); fread(pattern, patternstat.st_size, 1, patternfile); + pattern[patternstat.st_size] = 0; break; case 'h': oflag = 0; @@ -192,40 +193,37 @@ cflags |= REG_NOSPEC; while (pattern != NULL) { patterns++; - if ((pat = realloc(pat, patterns * sizeof(regex_t))) == NULL) - err(1, "realloc"); + pat = grep_realloc(pat, patterns * sizeof(regex_t)); if ((c = regcomp(&pat[patterns - 1], tmp, cflags))) { fprintf(stderr, "%s\n", tmp); - regerror(c, pat, (char *)&re_error, RE_ERROR_BUF); + regerror(c, pat, re_error, RE_ERROR_BUF); err(2, re_error); } tmp = strsep(&pattern, "\n"); } } else { - cflags |= REG_EXTENDED; + cflags |= Eflag ? REG_EXTENDED : REG_BASIC; if (xflag) { - if ((realpat = malloc(strlen(pattern) + sizeof("^(") + - sizeof(")$") + 1)) == NULL) - err(1, "malloc"); + realpat = grep_malloc(strlen(pattern) + sizeof("^(") + + sizeof(")$") + 1); strcpy(realpat, "^("); strcat(realpat, pattern); strcat(realpat, ")$"); } else if (wflag) { - if ((realpat = malloc(strlen(pattern) + sizeof("[[:<:]]") + - sizeof("[[:>:]]") + 1)) == NULL) - err(1, "malloc"); + realpat = grep_malloc(strlen(pattern) + sizeof("[[:<:]]") + + sizeof("[[:>:]]") + 1); strcpy(realpat, "[[:<:]]"); strcat(realpat, pattern); strcat(realpat, "[[:>:]]"); - } + } else { realpat = pattern; - if((pat = malloc(sizeof(regex_t))) == NULL) - err(1, "malloc"); - if((c = regcomp(pat, realpat, cflags))) { - regerror(c, pat, (char *)&re_error, RE_ERROR_BUF); + } + pat = grep_malloc(sizeof(regex_t)); + if ((c = regcomp(pat, realpat, cflags))) { + regerror(c, pat, re_error, RE_ERROR_BUF); err(2, re_error); } - if(wflag) + if (xflag || wflag) free(realpat); patterns = 1; } @@ -233,9 +231,8 @@ if ((argc == 0 || argc == 1) && !oflag) hflag = 1; if (argc == 0) - exit(!procfile((char *)NULL)); - c = 0; - for (i = 0; i < argc; i++) { + exit(!procfile(NULL)); + for (c = i = 0; i < argc; i++) { c += procfile(argv[i]); } if (Fflag) --- grep-0.3/grep.h Mon Jul 5 14:25:46 1999 +++ des/grep.h Wed Jul 7 20:28:28 1999 @@ -66,3 +66,5 @@ int procline(str_t ln); int seekable(FILE *f); void usage(void); +void *grep_malloc(size_t size); +void *grep_realloc(void *ptr, size_t size); --- grep-0.3/util.c Mon Jul 5 17:50:56 1999 +++ des/util.c Wed Jul 7 20:55:57 1999 @@ -27,7 +27,9 @@ */ #include + #include +#include #include #include #include @@ -60,12 +62,11 @@ */ gzf = gzdopen(STDIN_FILENO, "rb"); fn = "-"; - } else - if (!(gzf = gzopen(fn, "r"))) { - if (!sflag) - warn("%s", fn); - return 0; - } + } else if ((gzf = gzopen(fn, "r")) == NULL) { + if (!sflag) + warn("%s", fn); + return 0; + } if (aflag && gzbin_file(gzf)) return 0; @@ -74,8 +75,7 @@ ln.off = gztell(gzf); if ((tmp = gzfgetln(gzf, &ln.len)) == NULL) break; - if ((ln.dat = malloc(ln.len + 1)) == NULL) - err(1, "malloc"); + ln.dat = grep_malloc(ln.len + 1); memcpy(ln.dat, tmp, ln.len); ln.dat[ln.len] = 0; ln.line_no++; @@ -88,12 +88,11 @@ if (fn == NULL) { f = stdin; fn = "-"; - } else - if (!(f = fopen(fn, "r"))) { - if (!sflag) - warn("%s", fn); - return 0; - } + } else if ((f = fopen(fn, "r")) == NULL) { + if (!sflag) + warn("%s", fn); + return 0; + } if (aflag && bin_file(f)) return 0; @@ -102,8 +101,7 @@ ln.off = ftell(f); if ((tmp = fgetln(f, &ln.len)) == NULL) break; - if ((ln.dat = malloc(ln.len + 1)) == NULL) - err(1, "malloc"); + ln.dat = grep_malloc(ln.len + 1); memcpy(ln.dat, tmp, ln.len); ln.dat[ln.len] = 0; ln.line_no++; @@ -179,4 +177,26 @@ s[n - 1] = '\0'; *len = n; return s; +} + +void * +grep_malloc(size_t size) +{ + void *ptr; + + if ((ptr = malloc(size)) == NULL) { + errno = ENOMEM; + err(1, "malloc"); + } + return ptr; +} + +void * +grep_realloc(void *ptr, size_t size) +{ + if ((ptr = realloc(ptr, size)) == NULL) { + errno = ENOMEM; + err(1, "realloc"); + } + return ptr; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12: 8:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 9476215457 for ; Wed, 7 Jul 1999 12:08:05 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id MAA15591; Wed, 7 Jul 1999 12:07:36 -0700 (PDT) Message-Id: <199907071907.MAA15591@lestat.nas.nasa.gov> To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 12:07:35 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 07 Jul 1999 20:57:16 +0200 Dag-Erling Smorgrav wrote: > Don't use err() indiscriminately after a malloc() failure; malloc() > doesn't set errno. This is a bug in malloc(3), is it not? -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:12:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2D4D8153ED; Wed, 7 Jul 1999 12:12:50 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id VAA90872; Wed, 7 Jul 1999 21:12:47 +0200 (CEST) (envelope-from des) Subject: Re: Replacement for grep(1) (part 2) To: Jason Thorpe Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, phk@FreeBSD.ORG From: Dag-Erling Smorgrav Date: 07 Jul 1999 21:12:47 +0200 Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [accidentally b0rked the cc: line; apologies to those who get this twice] Jason Thorpe writes: > On 07 Jul 1999 20:57:16 +0200 > Dag-Erling Smorgrav wrote: > > Don't use err() indiscriminately after a malloc() failure; malloc() > > doesn't set errno. > This is a bug in malloc(3), is it not? According to the Single Unix Specification, yes. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:15:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 67CDC153ED for ; Wed, 7 Jul 1999 12:15:15 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id VAA90956; Wed, 7 Jul 1999 21:15:06 +0200 (CEST) (envelope-from des) To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 21:15:05 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "07 Jul 1999 20:57:16 +0200" Message-ID: Lines: 240 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Jamie Howard writes: > > I incorporated a huge patch from Dag-Erling Smorgrav [...] > Here's more :) Following up on myself, I introduced a bug in the previous round of patches; here's a corrected patch against 0.3. (the bug was that grep would always bail out if no pattern was specified after the options, even if one was provided with the -e or -F option) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no --- grep-0.3/grep.c Mon Jul 5 21:23:18 1999 +++ des/grep.c Wed Jul 7 21:13:29 1999 @@ -28,6 +28,7 @@ #include #include + #include #include #include @@ -89,17 +90,18 @@ case 'G': Gflag++; break; - case 'Z': - Zflag++; - break; case 'L': lflag = 0; Lflag = qflag = 1; break; case 'V': fprintf(stderr, "Jamie's grep version %u.%u\n", VER_MAJ, VER_MIN); + fprintf(stderr, argv[0]); usage(); break; + case 'Z': + Zflag++; + break; case 'a': aflag = 1; break; @@ -115,11 +117,11 @@ case 'f': if (stat(optarg, &patternstat)) err(2, "%s", optarg); - if ((pattern = calloc(1, patternstat.st_size + 1)) == NULL) - err(1, "calloc"); + pattern = grep_malloc(patternstat.st_size + 1); if ((patternfile = fopen(optarg, "r")) == NULL) err(2, "%s", optarg); fread(pattern, patternstat.st_size, 1, patternfile); + pattern[patternstat.st_size] = 0; break; case 'h': oflag = 0; @@ -162,7 +164,7 @@ argc -= optind; argv += optind; - if (argc == 0) + if (argc == 0 && !pattern) usage(); if (!pattern) { @@ -192,40 +194,37 @@ cflags |= REG_NOSPEC; while (pattern != NULL) { patterns++; - if ((pat = realloc(pat, patterns * sizeof(regex_t))) == NULL) - err(1, "realloc"); + pat = grep_realloc(pat, patterns * sizeof(regex_t)); if ((c = regcomp(&pat[patterns - 1], tmp, cflags))) { fprintf(stderr, "%s\n", tmp); - regerror(c, pat, (char *)&re_error, RE_ERROR_BUF); + regerror(c, pat, re_error, RE_ERROR_BUF); err(2, re_error); } tmp = strsep(&pattern, "\n"); } } else { - cflags |= REG_EXTENDED; + cflags |= Eflag ? REG_EXTENDED : REG_BASIC; if (xflag) { - if ((realpat = malloc(strlen(pattern) + sizeof("^(") + - sizeof(")$") + 1)) == NULL) - err(1, "malloc"); + realpat = grep_malloc(strlen(pattern) + sizeof("^(") + + sizeof(")$") + 1); strcpy(realpat, "^("); strcat(realpat, pattern); strcat(realpat, ")$"); } else if (wflag) { - if ((realpat = malloc(strlen(pattern) + sizeof("[[:<:]]") + - sizeof("[[:>:]]") + 1)) == NULL) - err(1, "malloc"); + realpat = grep_malloc(strlen(pattern) + sizeof("[[:<:]]") + + sizeof("[[:>:]]") + 1); strcpy(realpat, "[[:<:]]"); strcat(realpat, pattern); strcat(realpat, "[[:>:]]"); - } + } else { realpat = pattern; - if((pat = malloc(sizeof(regex_t))) == NULL) - err(1, "malloc"); - if((c = regcomp(pat, realpat, cflags))) { - regerror(c, pat, (char *)&re_error, RE_ERROR_BUF); + } + pat = grep_malloc(sizeof(regex_t)); + if ((c = regcomp(pat, realpat, cflags))) { + regerror(c, pat, re_error, RE_ERROR_BUF); err(2, re_error); } - if(wflag) + if (xflag || wflag) free(realpat); patterns = 1; } @@ -233,9 +232,8 @@ if ((argc == 0 || argc == 1) && !oflag) hflag = 1; if (argc == 0) - exit(!procfile((char *)NULL)); - c = 0; - for (i = 0; i < argc; i++) { + exit(!procfile(NULL)); + for (c = i = 0; i < argc; i++) { c += procfile(argv[i]); } if (Fflag) --- grep-0.3/grep.h Mon Jul 5 14:25:46 1999 +++ des/grep.h Wed Jul 7 20:28:28 1999 @@ -66,3 +66,5 @@ int procline(str_t ln); int seekable(FILE *f); void usage(void); +void *grep_malloc(size_t size); +void *grep_realloc(void *ptr, size_t size); --- grep-0.3/util.c Mon Jul 5 17:50:56 1999 +++ des/util.c Wed Jul 7 20:55:57 1999 @@ -27,7 +27,9 @@ */ #include + #include +#include #include #include #include @@ -60,12 +62,11 @@ */ gzf = gzdopen(STDIN_FILENO, "rb"); fn = "-"; - } else - if (!(gzf = gzopen(fn, "r"))) { - if (!sflag) - warn("%s", fn); - return 0; - } + } else if ((gzf = gzopen(fn, "r")) == NULL) { + if (!sflag) + warn("%s", fn); + return 0; + } if (aflag && gzbin_file(gzf)) return 0; @@ -74,8 +75,7 @@ ln.off = gztell(gzf); if ((tmp = gzfgetln(gzf, &ln.len)) == NULL) break; - if ((ln.dat = malloc(ln.len + 1)) == NULL) - err(1, "malloc"); + ln.dat = grep_malloc(ln.len + 1); memcpy(ln.dat, tmp, ln.len); ln.dat[ln.len] = 0; ln.line_no++; @@ -88,12 +88,11 @@ if (fn == NULL) { f = stdin; fn = "-"; - } else - if (!(f = fopen(fn, "r"))) { - if (!sflag) - warn("%s", fn); - return 0; - } + } else if ((f = fopen(fn, "r")) == NULL) { + if (!sflag) + warn("%s", fn); + return 0; + } if (aflag && bin_file(f)) return 0; @@ -102,8 +101,7 @@ ln.off = ftell(f); if ((tmp = fgetln(f, &ln.len)) == NULL) break; - if ((ln.dat = malloc(ln.len + 1)) == NULL) - err(1, "malloc"); + ln.dat = grep_malloc(ln.len + 1); memcpy(ln.dat, tmp, ln.len); ln.dat[ln.len] = 0; ln.line_no++; @@ -179,4 +177,26 @@ s[n - 1] = '\0'; *len = n; return s; +} + +void * +grep_malloc(size_t size) +{ + void *ptr; + + if ((ptr = malloc(size)) == NULL) { + errno = ENOMEM; + err(1, "malloc"); + } + return ptr; +} + +void * +grep_realloc(void *ptr, size_t size) +{ + if ((ptr = realloc(ptr, size)) == NULL) { + errno = ENOMEM; + err(1, "realloc"); + } + return ptr; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:31:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C9E451502A for ; Wed, 7 Jul 1999 12:31:40 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id VAA91346; Wed, 7 Jul 1999 21:31:11 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: Archie Cobbs , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Repalcement for grep(1) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 21:31:10 +0200 In-Reply-To: Jamie Howard's message of "Sun, 4 Jul 1999 21:32:22 -0400 (EDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > On Sun, 4 Jul 1999, Archie Cobbs wrote: > > There are two special cases- of bracket expressions: the > > bracket expressions `[[:<:]]' and `[[:>:]]' match the null > > string at the beginning and end of a word respectively. > > Perhaps this will help with -w? > Yes, I received a patch from Simon Burge which implements this. It also > beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk) which rely on this behaviour. I suggest you explore the magic of the nmatch and pmatch arguments to regexec() :) Specifically, the pattern matched a word if: ((pmatch[0].rm_so == 0 || !isalpha(line[pmatch[0].rm_so-1])) && (pmatch[0].rm_eo == len || !isalpha(line[pmatch[0].rm_eo]))) This is off the top of my head, from reading the man page: you'll have to try it out to see if it works. You might want to replace isalpha with something less restrictive, such as isalnum(), or: #define isword(x) (isalnum(x) || (x) == '_') (judging from empirical observation, the latter corresponds to what GNU grep does) As for full-line matches (-x), simply check that (pmatch[0].rm_so == 0 && pmatch[0].rm_eo == len) This should save you from playing games with back-references. (both code snippets assume that line points to a line of text from the input and that len is the length of that line minus the newline) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:36:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from majordomo2.umd.edu (majordomo2.umd.edu [128.8.10.7]) by hub.freebsd.org (Postfix) with ESMTP id EEB1F15027 for ; Wed, 7 Jul 1999 12:35:42 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac10.wam.umd.edu (root@rac10.wam.umd.edu [128.8.10.150]) by majordomo2.umd.edu (8.9.3/8.9.3) with ESMTP id PAA27048; Wed, 7 Jul 1999 15:35:22 -0400 (EDT) Received: from rac10.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac10.wam.umd.edu (8.9.3/8.9.3) with SMTP id PAA11909; Wed, 7 Jul 1999 15:35:21 -0400 (EDT) Received: from localhost by rac10.wam.umd.edu (8.9.3/8.9.3) with ESMTP id PAA11902; Wed, 7 Jul 1999 15:35:19 -0400 (EDT) X-Authentication-Warning: rac10.wam.umd.edu: howardjp owned process doing -bs Date: Wed, 7 Jul 1999 15:35:19 -0400 (EDT) From: Jamie Howard To: Dag-Erling Smorgrav Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) 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 7 Jul 1999, Dag-Erling Smorgrav wrote: > BTW, I assume you've read this: > > Of course, my copy of the printout is all marked up. :) > I see you switched to using extended regexps by default, and made -E a > no-op; this breaks the ports collection, so I changed it back. The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: Grep understands two different versions of regular expression syntax: ``basic'' and ``extended.'' In GNU grep, there is no difference in available functionality using either syntax. Is this inaccurate or am I reading it wrong? > Sort your switch cases. > Don't use err() indiscriminately after a malloc() failure; malloc() > doesn't set errno. Shouldn't malloc be fixed? :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:40:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 0EF3A14F08 for ; Wed, 7 Jul 1999 12:40:17 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id OAA11951; Wed, 7 Jul 1999 14:40:16 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id OAA04230; Wed, 7 Jul 1999 14:40:14 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id OAA28900; Wed, 7 Jul 1999 14:40:13 -0500 (CDT) Date: Wed, 7 Jul 1999 14:40:13 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907071940.OAA28900@free.pcs> To: hm@kts.org, hackers@freebsd.org Subject: Re: howto allocate 32k phys. mem-space in driver ? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Hi, > >perhaps i don't see the wood for trees. > >I'd like to write a driver for a PCI ISDN chipset which uses a 32k byte >memory window as a sort of "dual ported ram" in the memory address space. > >What has to be done in the driver attach routine is > > - allocate a 32k contingous memory window > - get the physical address of it > - program the ISDN PCI chipset with the start address of the window > >Now can i just malloc 32k and then use vtophys() to get the physical >start address to program the PCI chip with ? With the "new-bus" architecture, I believe this is done the following way: 1. Create a DMA tag describing the amount of memory needed, and what the alignment constraints are. error = bus_dma_tag_create( .... ); 2. Allocate the memory described by the tag. error = bus_dmamem_alloc( .... ); 3. Map the memory into the address space. A callback routine is used to record the physical -> virtual mapping. bus_dmamap_load( .... ); For pre-newbus, I think you just call contigmalloc(), and vtophys(). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:42:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4844A14FEE for ; Wed, 7 Jul 1999 12:42:51 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id VAA91613; Wed, 7 Jul 1999 21:42:31 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 21:42:31 +0200 In-Reply-To: Jamie Howard's message of "Wed, 7 Jul 1999 15:35:19 -0400 (EDT)" Message-ID: Lines: 39 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > On 7 Jul 1999, Dag-Erling Smorgrav wrote: > > I see you switched to using extended regexps by default, and made -E a > > no-op; this breaks the ports collection, so I changed it back. > > The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: > > Grep understands two different versions of regular expression > syntax: ``basic'' and ``extended.'' In GNU grep, there is > no difference in available functionality using either syntax. > > Is this inaccurate or am I reading it wrong? One or the other. Try it out for yourself. root@flood /tmp# cat > foo abcd efgh ijkl abcd (efgh) ijkl root@flood /tmp# grep -V GNU grep version 2.0 usage: grep [-[AB] ] [-CEFGLVXHPRSZabchilnqsvwxy] [-e ] [-f file] [files ...] root@flood /tmp# grep '(efgh)' foo abcd (efgh) ijkl root@flood /tmp# grep -E '(efgh)' foo abcd efgh ijkl abcd (efgh) ijkl > > Don't use err() indiscriminately after a malloc() failure; malloc() > > doesn't set errno. > Shouldn't malloc be fixed? :) Should, but probably won't in the near future. Oh well. I guess you can just remove 'errno = ENOMEM' from grep_malloc() and grep_realloc() and blame phk if anyone complains :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:45:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 3D87A15027 for ; Wed, 7 Jul 1999 12:45:21 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac1.wam.umd.edu (root@rac1.wam.umd.edu [128.8.10.141]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id PAA06561; Wed, 7 Jul 1999 15:44:49 -0400 (EDT) Received: from rac1.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id PAA20456; Wed, 7 Jul 1999 15:44:48 -0400 (EDT) Received: from localhost by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id PAA20451; Wed, 7 Jul 1999 15:44:48 -0400 (EDT) X-Authentication-Warning: rac1.wam.umd.edu: howardjp owned process doing -bs Date: Wed, 7 Jul 1999 15:44:48 -0400 (EDT) From: Jamie Howard To: Dag-Erling Smorgrav Cc: Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Repalcement for grep(1) 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 7 Jul 1999, Dag-Erling Smorgrav wrote: > Jamie Howard writes: > > On Sun, 4 Jul 1999, Archie Cobbs wrote: > > > There are two special cases- of bracket expressions: the > > > bracket expressions `[[:<:]]' and `[[:>:]]' match the null > > > string at the beginning and end of a word respectively. > > > Perhaps this will help with -w? > > Yes, I received a patch from Simon Burge which implements this. It also > > beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. > > No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk) > which rely on this behaviour. I just knocked this down to just freebsd-hackers because this only applies here (so far). I am not the internationalization expert, but doesn't [^A-Za-z] and [A-Xa-z$] limit you to just English and other Roman languages? Won't [[:<:]] and [[:>:]] be languages independent, presuming regex supports it? Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 12:49:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6CB2F14F4E for ; Wed, 7 Jul 1999 12:49:43 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id VAA91795; Wed, 7 Jul 1999 21:49:22 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: Dag-Erling Smorgrav , Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Repalcement for grep(1) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 21:49:22 +0200 In-Reply-To: Jamie Howard's message of "Wed, 7 Jul 1999 15:44:48 -0400 (EDT)" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard writes: > I am not the internationalization expert, but doesn't [^A-Za-z] and > [A-Xa-z$] limit you to just English and other Roman languages? Won't > [[:<:]] and [[:>:]] be languages independent, presuming regex supports > it? They don't DTRT. They only match whitespace boundaries IIRC. Anyway, I already posted a solution which does not involve screwing around with the pattern. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 13: 9:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id ADA8814D06 for ; Wed, 7 Jul 1999 13:09:38 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id WAA92320; Wed, 7 Jul 1999 22:09:24 +0200 (CEST) (envelope-from des) To: Jamie Howard Cc: Dag-Erling Smorgrav , Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Repalcement for grep(1) References: From: Dag-Erling Smorgrav Date: 07 Jul 1999 22:09:24 +0200 In-Reply-To: Jamie Howard's message of "Wed, 7 Jul 1999 15:44:48 -0400 (EDT)" Message-ID: Lines: 8 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG BTW, the end-of-line handling is wrong; grep will fail to select a line where the pattern appears at the end and the line is not terminated by a newline. I'm working on a fix (and on implementing my solution for -w and -x). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 13:28:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monk.via.net (monk.via.net [209.81.2.10]) by hub.freebsd.org (Postfix) with ESMTP id EEE7514C99 for ; Wed, 7 Jul 1999 13:28:38 -0700 (PDT) (envelope-from joe@monk.via.net) Received: (from joe@localhost) by monk.via.net (8.9.3/8.9.3) id NAA21795 for hackers@freebsd.org; Wed, 7 Jul 1999 13:28:28 -0700 (PDT) (envelope-from joe) Date: Wed, 7 Jul 1999 13:28:28 -0700 (PDT) From: User Joe Message-Id: <199907072028.NAA21795@monk.via.net> To: hackers@freebsd.org Subject: Berkeley DB question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is the berkeley db (or any other small db) multi user safe? Are there locks to maintain coherency of multiple processes access the same database files? Thanks, Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 13:56:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by hub.freebsd.org (Postfix) with ESMTP id 4E4891506C for ; Wed, 7 Jul 1999 13:56:47 -0700 (PDT) (envelope-from assar@sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id WAA20321; Wed, 7 Jul 1999 22:57:09 +0200 (CEST) To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 07 Jul 1999 22:57:07 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "07 Jul 1999 21:15:05 +0200" Message-ID: <5laet8b2l8.fsf@assaris.sics.se> Lines: 46 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > - if ((realpat = malloc(strlen(pattern) + sizeof("^(") + > - sizeof(")$") + 1)) == NULL) > - err(1, "malloc"); > + realpat = grep_malloc(strlen(pattern) + sizeof("^(") > + + sizeof(")$") + 1); > strcpy(realpat, "^("); > strcat(realpat, pattern); > strcat(realpat, ")$"); Why not just use asprintf? > +void * > +grep_malloc(size_t size) > +{ > + void *ptr; > + > + if ((ptr = malloc(size)) == NULL) { > + errno = ENOMEM; > + err(1, "malloc"); > + } > + return ptr; > +} In this case it doesn't matter but in general this function is wrong. malloc(0) can return NULL. And besides, I really don't think this is a grep function but actually is useful for programs that don't have any strategy for handling out of memory errors and might as well die (with a descriptive error message, of course). Let's call it emalloc and let's put in somewhere where it can be used. void * emalloc (size_t sz) { void *tmp = malloc (sz); if (tmp == NULL && sz != 0) { errno = ENOMEM; err (1, "malloc %lu", (unsigned long)sz); } return tmp; } /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 14: 2:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 663C314F0B for ; Wed, 7 Jul 1999 14:02:38 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id XAA93574; Wed, 7 Jul 1999 23:01:13 +0200 (CEST) (envelope-from des) To: Assar Westerlund Cc: Dag-Erling Smorgrav , Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> From: Dag-Erling Smorgrav Date: 07 Jul 1999 23:01:13 +0200 In-Reply-To: Assar Westerlund's message of "07 Jul 1999 22:57:07 +0200" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Assar Westerlund writes: > Dag-Erling Smorgrav writes: > > + realpat = grep_malloc(strlen(pattern) + sizeof("^(") > > + + sizeof(")$") + 1); > Why not just use asprintf? Doesn't matter, thsis code is gone in the latest version. You though the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep of the minute' :) > In this case it doesn't matter but in general this function is wrong. > malloc(0) can return NULL. Agreed. > And besides, I really don't think this is a grep function but actually > is useful for programs that don't have any strategy for handling out > of memory errors and might as well die (with a descriptive error > message, of course). Let's call it emalloc and let's put in somewhere > where it can be used. Too simple to warrant that, and other programs will likely want to handle the error differently. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 14:13:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (Postfix) with ESMTP id F212F14E48; Wed, 7 Jul 1999 14:13:41 -0700 (PDT) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA100656837; Wed, 7 Jul 1999 13:00:37 -0400 Date: Wed, 7 Jul 1999 13:00:37 -0400 (EDT) From: Bill Fumerola To: "Brian F. Feldman" Cc: "Jordan K. Hubbard" , Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script 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, 6 Jul 1999, Brian F. Feldman wrote: > Thanks! But still, I don't think rtfm is very appropriate... Can we look > for something better, more obvious? Or perhaps it would be in the motd > like /stand/sysinstall is.... people would need to be aware of this. it can be called anything. the new user isn't going to know it unless refered to it. (or unless there is a question mark to click) - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@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 7 15:21: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasquatch.dannyland.org (sasquatch.dannyland.org [207.229.158.70]) by hub.freebsd.org (Postfix) with SMTP id 042CA14E32 for ; Wed, 7 Jul 1999 15:20:53 -0700 (PDT) (envelope-from dannyman@sasquatch.dannyland.org) Received: (qmail 11923 invoked by uid 1000); 7 Jul 1999 22:20:53 -0000 Date: Wed, 7 Jul 1999 17:20:53 -0500 From: dannyman To: Leif Neland Cc: FreeBSD Hackers Subject: Re: Budget on user-ppp Message-ID: <19990707172052.O15291@dannyland.org> References: <00f101bec735$58fe2f80$0e00a8c0@neland.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <00f101bec735$58fe2f80$0e00a8c0@neland.dk>; from Leif Neland on Tue, Jul 06, 1999 at 12:20:00AM +0200 X-Loop: djhoward@uiuc.edu X-URL: http://www.dannyland.org/~dannyman/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 12:20:00AM +0200, Leif Neland wrote: > It could be nice with some sort of budget control in ppp. > A few days ago I found out bb caused a dialup every 5 minutes. > Today I found I had been online 27 hours uninterrupted. > Some dialup-routers allows a setup of "max a connects/b minutes online over > c hours". I had things set up so that the users on my system could bring up ppp at will, and bring it down. I also had /etc/daily bring up ppp when it needed it. The problem being, of course, that the on-demand stuff gets pretty nasty at times ... *shrug* -- dannyman - http://www.dannyland.org/~dannyman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 15:30:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id 9B03A14EA6 for ; Wed, 7 Jul 1999 15:30:12 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id SAA28873 for ; Wed, 7 Jul 1999 18:30:12 -0400 (EDT) (envelope-from jay@oneway.com) Date: Wed, 7 Jul 1999 18:30:12 -0400 (EDT) From: Jay Kuri To: hackers@freebsd.org Subject: Problem with fxp driver and 82559 cards 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 Good Afternoon, I have been using the Intel EtherExpress Pro 10/100B cards for some time. I just recieved a batch of the Intel Pro/100+ management adapters. In most of my machines, they don't work. Everything I can find says they should be compatible, but there are very clearly some problems. Doing FTP installs is impossible, on 3.2, if I can get it to start at all, it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. Large data transfers seem to cause the lockup. I know at least 1 netbsd person has reported similar problems with these new cards, (kern/7216). Has anyone seen problems like these? Any ideas? Thanks, Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 15:50:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id CC7041549F; Wed, 7 Jul 1999 15:50:53 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA23598; Wed, 7 Jul 1999 15:49:39 -0700 (PDT) Message-Id: <199907072249.PAA23598@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 11:43:44 PDT." <199907071843.LAA92954@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 15:49:39 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Since we have increased the hard page table allocation for the kernel to > 1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was > thinking of increasing it to 512MB. This increase only effects > large-memory systems. It keeps them from locking up :-) > > Anyone have any objections? Yes, I do - at least with the 512MB figure. That would be half of the 1GB KVA space and large systems really need that space for things like network buffers and other map regions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 7 15:55:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.beta.com (mcgovern.ne.mediaone.net [24.218.8.93]) by hub.freebsd.org (Postfix) with ESMTP id 2B96A14BFC for ; Wed, 7 Jul 1999 15:55:51 -0700 (PDT) (envelope-from mcgovern@spoon.beta.com) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.9.3/8.9.3) with ESMTP id SAA12143 for ; Wed, 7 Jul 1999 18:55:50 -0400 (EDT) (envelope-from mcgovern@spoon.beta.com) Message-Id: <199907072255.SAA12143@spoon.beta.com> To: hackers@freebsd.org Subject: Terminal CTRL-C processing... Date: Wed, 07 Jul 1999 18:55:50 -0400 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a dumb question, but I've been trying to hack on it all day, and I'm getting frustrated, so I want throw this in the air for comment... I'm putting the finishing touches on a second revision of the Cyclades Z driver. Its pretty much there, except for when you hit CTRL-C with a shell.... I suspect the problem has to do with an ioctl() call that isn't completing properly, but I might be terribly wrong. In my first test scenario, when I hit CTRL-C, the application continues to write to the port (ie - the device driver write() routine continues to get called), but the data is basically garbage - rewrites of old data, command history - basically just junk output. I'm 99.9% sure its not the write half of the device drive, as I mentioned the write routine is actually being called repeatedly. On one run, I happened to catch some output (on screen, there doesn't appear to be anything in the logs) that a tiocsettr failed, so I suspected that maybe an IOCTL was getting called at too low of a priority, and the interrupt handler was just hosing it. So, I moved the spltty() call to the top of the routine, so baically the whole routine will run at the tty spl level. Then, on rerunning the test, the machine just hung. Any thoughts on what might be causing this when CTRL-C is hit? I'm expecting that SIGKILL is being sent to the ls command thats running, but I don't understand how that could hose the system so badly that everything else fails.... -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 15:56:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C982F14E2A; Wed, 7 Jul 1999 15:56:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA94642; Wed, 7 Jul 1999 15:56:12 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 15:56:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072256.PAA94642@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072249.PAA23598@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : Yes, I do - at least with the 512MB figure. That would be half of the 1GB :KVA space and large systems really need that space for things like network :buffers and other map regions. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com What would be an acceptable upper limit? 256MB? 128MB? The test I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area before the number of vnodes stabilized, on a 1GB machine. I would say that a 128MB upper limit would be too small for a 4G machine. A 256MB limit ought to work for a 4G machine Since most of those news files were small, I think Kirk's news test code is pretty much the worse case scenario as far as vnode allocation goes. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 16: 5:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 42040154C2 for ; Wed, 7 Jul 1999 16:05:19 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA23678; Wed, 7 Jul 1999 16:04:09 -0700 (PDT) Message-Id: <199907072304.QAA23678@implode.root.com> To: Jay Kuri Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-reply-to: Your message of "Wed, 07 Jul 1999 18:30:12 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 16:04:09 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Good Afternoon, > > I have been using the Intel EtherExpress Pro 10/100B cards for >some time. I just recieved a batch of the Intel Pro/100+ management >adapters. In most of my machines, they don't work. > >Everything I can find says they should be compatible, but there are very >clearly some problems. > >Doing FTP installs is impossible, on 3.2, if I can get it to start at all, >it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. > >Large data transfers seem to cause the lockup. I know at least 1 netbsd >person has reported similar problems with these new cards, (kern/7216). > >Has anyone seen problems like these? Any ideas? Hmmm...I've been using them in some machines here and haven't seen any problems. Strange. Do all of your systems have similar motherboards and CPU? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 7 16: 6:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 36152154BC for ; Wed, 7 Jul 1999 16:06:49 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D771A78; Thu, 8 Jul 1999 07:06:48 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: Doug Rabson , hackers@freebsd.org Subject: Re: The busspace modernization initiative. In-reply-to: Your message of "Sun, 04 Jul 1999 15:57:52 CST." <199907042157.PAA44776@harmony.village.org> Date: Thu, 08 Jul 1999 07:06:48 +0800 From: Peter Wemm Message-Id: <19990707230648.D771A78@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message Do ug Rabson writes: > : This seems to bypass the nexus completely which isn't right. It wouldn't > : detect conflicts between bus_space_alloc and the new-bus resource apis > : since it has its own instances of struct rman. > > This is true. However, that's just because that was what the code > that I acquired from the newconfig people did. I don't think that it > must be this way. At the very least it must use the real resource lists, not a second copy. That probably means that nexus.c itself would have to export these functions. > : Do we really need to > : support this api for common newconfig style drivers? > > Yes. I believe that we do. One thing that this is used for is to map > things, even if they conflict. I'm sure I understand why it does that > beyond checks for conflicts/valid I/O addresses in some drivers > (mostly the scsi drivers). > > I'll have to look into what this API is supposed to do.... It is > definitely heavily used (or at least used in almost all) in the few > drivers that I've tried to port over.... At the moment, the probe/attach routines use ia_iot from the aux arg: struct isa_attach_args { bus_space_tag_t ia_iot; /* isa i/o space tag */ bus_space_tag_t ia_memt; /* isa mem space tag */ bus_dma_tag_t ia_dmat; /* DMA tag */ isa_chipset_tag_t ia_ic; int ia_iobase; /* base i/o address */ int ia_iosize; /* span of ports used */ int ia_irq; /* interrupt request */ int ia_drq; /* DMA request */ int ia_drq2; /* second DMA request */ int ia_maddr; /* physical i/o mem addr */ u_int ia_msize; /* size of i/o memory */ void *ia_aux; /* driver specific */ }; .. using the isa stuff for an example. (tough if they want multiple IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with another device in between...) It uses the tag to get a handle: if (bus_space_map(iot, ia->ia_iobase, SATLINK_IOSIZE, 0, &ioh)) return (0); rv = 1; ia->ia_iosize = SATLINK_IOSIZE; ia->ia_msize = 0; bus_space_unmap(iot, ioh, SATLINK_IOSIZE); return (rv); And uses the tag and handle in the bus_space_read/write_xxx() macros. Under NetBSD/i386: typedef int bus_space_tag_t; typedef u_long bus_space_handle_t; But NetBSD/Alpha: typedef struct alpha_bus_space *bus_space_tag_t; typedef u_long bus_space_handle_t; struct alpha_bus_space { /* cookie */ void *abs_cookie; /* mapping/unmapping */ int (*abs_map) __P((void *, bus_addr_t, bus_size_t, int, bus_space_handle_t *, int)); [..] I don't see why we couldn't add a device_t pointer in there as well, and the newconfig shim could use it to store the device_t of the wrapper device. The bus_space_map() etc macros could then do the proper uplink calls to the parent bus since it now has access to the device pointer. > It doesn't change the fact that bus_space_hanle_t is supposed to be an > opaque type and many places in the three don't treat it as such.... Yes, agreed there. > Warner Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.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 7 16:11: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 57E3D154BC; Wed, 7 Jul 1999 16:10:55 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA23725; Wed, 7 Jul 1999 16:09:46 -0700 (PDT) Message-Id: <199907072309.QAA23725@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 15:56:12 PDT." <199907072256.PAA94642@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 16:09:46 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >: Yes, I do - at least with the 512MB figure. That would be half of the 1GB >:KVA space and large systems really need that space for things like network >:buffers and other map regions. >: >:-DG >: >:David Greenman >:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org >:Creator of high-performance Internet servers - http://www.terasolutions.com > > What would be an acceptable upper limit? 256MB? 128MB? The test > I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area > before the number of vnodes stabilized, on a 1GB machine. I would say > that a 128MB upper limit would be too small for a 4G machine. A 256MB > limit ought to work for a 4G machine > > Since most of those news files were small, I think Kirk's news test code > is pretty much the worse case scenario as far as vnode allocation goes. Well, I could possibly live with 256MB, but the vnode/fsnode consumption seems to be getting a bit silly in the memory overhead department, even for machines with 4GB of RAM. It seems like there needs to be fewer of them and/or they need to go on a diet. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 7 16:23:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8A3DD14D34; Wed, 7 Jul 1999 16:23:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA94794; Wed, 7 Jul 1999 16:23:29 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 16:23:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072323.QAA94794@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072309.QAA23725@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> limit ought to work for a 4G machine :> :> Since most of those news files were small, I think Kirk's news test code :> is pretty much the worse case scenario as far as vnode allocation goes. : : Well, I could possibly live with 256MB, but the vnode/fsnode consumption :seems to be getting a bit silly in the memory overhead department, even for :machines with 4GB of RAM. It seems like there needs to be fewer of them :and/or they need to go on a diet. : :-DG : :David Greenman Well, the problem occurs because the system has sufficient memory to keep the underlying VM object around. The current vnode code will not place a vnode on the free list until the underlying VM object goes away. The 60MB worth of KVM being used to hold vnodes is supporting 1GB worth of cached VM pages ( associated with small files, that is ). So even though the numbers look strange, it does seem to scale. In order to turn the maxvnodes sysctl into a harder limit, the vnode allocation & freeing code would have to be reworked some. Right now vnodes are not placed back onto the free list until their underlying VM objects go away. We would need to make the vnode lists (which are headed by mount table entries) LRU and then attempt to reuse the vnodes that way, destroying the underlying VM object when necessary. Alternatively we can try to make the vnode structure smaller, or we could try to decouple the vnode from the VM object and instead reference the VM object by inode. All I can say to that: Yuch. I'd rather just bump up the KVM. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 16:26:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 1FBBB14D34; Wed, 7 Jul 1999 16:26:17 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40363>; Thu, 8 Jul 1999 09:08:30 +1000 Date: Thu, 8 Jul 1999 09:26:09 +1000 From: Peter Jeremy Subject: Re: Heh heh, humorous lockup To: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Message-Id: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > Yes, I do - at least with the 512MB figure. That would be half of the 1GB >KVA space and large systems really need that space for things like network >buffers and other map regions. Matthew Dillon wrote: > What would be an acceptable upper limit? 256MB? 128MB? The test > I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area > before the number of vnodes stabilized, on a 1GB machine. I would say > that a 128MB upper limit would be too small for a 4G machine. A 256MB > limit ought to work for a 4G machine It appears we're rapidly approaching the point where 32-bits isn't enough. We could increase KVA - but that cuts into process VM space (and a large machine is likely to have large processes). The other option is moving away from a flat memory model: How about putting some of the larger kernel-only data-structures into another segment? The downside is that unless we want to start passing `far' pointers around (which is both ugly and inefficient), we need to make the pointer address space transparent to the compiler. Of course, with proper data-hiding, this exercise is fairly trivial - only the functions that physically reference the object need to know where it is. But I don't think the kernel is structured in this way (for good and valid reasons - CS theoreticians notwithstanding). And any bugs (like `cheating' by not accessing data through the approved mechanisms) will lead to fairly obscure panics (the address is perfectly valid - it's just the wrong segment). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 16:35:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 69C1A14CCB; Wed, 7 Jul 1999 16:35:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA94883; Wed, 7 Jul 1999 16:34:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 16:34:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907072334.QAA94883@apollo.backplane.com> To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <99Jul8.090830est.40363@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It appears we're rapidly approaching the point where 32-bits isn't :enough. We could increase KVA - but that cuts into process VM space :(and a large machine is likely to have large processes). True, though what we are talking about here is scaling issue with main memory. We should be able to fit everything necessary to support 4GB of ram into a 1GB of KVM. That we aren't means we are doing something wrong somewhere. :The other option is moving away from a flat memory model: How about :putting some of the larger kernel-only data-structures into another :segment? The downside is that unless we want to start passing `far' :pointers around (which is both ugly and inefficient), we need to :make the pointer address space transparent to the compiler. I don't think it is worth it. We would then have to switch the MMU context just going from user to supervisor mode. It would not be too hard to do that since all data movement from the user address space is encapsulated, but it just wouldn't be worth the overhead. The biggest thorn in our side is the filesystem buffer cache. If we could somehow make the KVA mappings apply only to I/O in progress and actively retrieved buffers (getblk()), we would have plenty of KVA space left over for other things. Right now it is fairly expensive to KVA map and unmap the filesystem buffer's b_data pointer. I'm not sure why. :Of course, with proper data-hiding, this exercise is fairly trivial - :only the functions that physically reference the object need to know :where it is. But I don't think the kernel is structured in this way :(for good and valid reasons - CS theoreticians notwithstanding). And :any bugs (like `cheating' by not accessing data through the approved :mechanisms) will lead to fairly obscure panics (the address is :perfectly valid - it's just the wrong segment). : :Peter -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 16:36: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id F09F21567B for ; Wed, 7 Jul 1999 16:35:35 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id AAA37913; Thu, 8 Jul 1999 00:03:11 +0100 (BST) (envelope-from nik) Date: Thu, 8 Jul 1999 00:03:10 +0100 From: Nik Clayton To: Sheldon Hearn Cc: Nik Clayton , hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. Message-ID: <19990708000310.A37390@catkin.nothing-going-on.org> References: <19990705235617.T71138@catkin.nothing-going-on.org> <93215.931241186@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <93215.931241186@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 06, 1999 at 08:06:26AM +0200 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 06, 1999 at 08:06:26AM +0200, Sheldon Hearn wrote: > On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: > > I'm unfamiliar with the ins and outs of the login_cap system. Could > > someone who is versed in it please take a look at this PR (text included) > > and let me know whether or not the suggested patch is correct. > > Quite often, we receive requests to improve documentation that are born > out of a failure to read that documentation correctly. I think this PR > might be one of those cases. Have a look at the login_cap(3) manpage, > into which I suspect the submitter may not have dug deeply enough: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." The patch in the PR just rewords the paragraph slightly to make this a little more obvious for the next person to come along. I've got no objection to the patch itself, as (IMHO) it does make the para read a little more clearly. If no one objects that it's actually changing the intent of the paragraph then I'll commit it soonish. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 16:36:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id AA5AC15106; Wed, 7 Jul 1999 16:36:10 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA23809; Wed, 7 Jul 1999 16:34:59 -0700 (PDT) Message-Id: <199907072334.QAA23809@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 16:23:29 PDT." <199907072323.QAA94794@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 16:34:59 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >:> limit ought to work for a 4G machine >:> >:> Since most of those news files were small, I think Kirk's news test code >:> is pretty much the worse case scenario as far as vnode allocation goes. >: >: Well, I could possibly live with 256MB, but the vnode/fsnode consumption >:seems to be getting a bit silly in the memory overhead department, even for >:machines with 4GB of RAM. It seems like there needs to be fewer of them >:and/or they need to go on a diet. > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. We've been here before, a couple of times. This started to become an issue when the limits were removed and has gotten worse as the vnode and fsnode structs have grown over time. We're running into some limits on how much space we can give to the kernel since there are a number of folks which think that 3GB of process VA space is a minimum. I tend to think that the 2GB/2GB split that I use on wcarchive is probably more appropriate as a default, but like I say, others disagree. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 7 16:46:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id E02301512E; Wed, 7 Jul 1999 16:46:37 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA26809; Wed, 7 Jul 1999 16:46:31 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA05336; Wed, 7 Jul 1999 16:46:32 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA15337; Wed, 7 Jul 99 16:46:30 PDT Message-Id: <37830CE9.480EF78A@softweyr.com> Date: Wed, 07 Jul 1999 02:16:41 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Bill Fumerola Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , Chris Costello , Doug , Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > for something better, more obvious? Or perhaps it would be in the motd > > like /stand/sysinstall is.... people would need to be aware of this. > > it can be called anything. the new user isn't going to know it unless > refered to it. (or unless there is a question mark to click) Now there's an idea! Someone wanna code up wmrtfm real quick? It should start an rxvt (if available) or xterm running rtfm on strings that are dropped onto or pasted into the dock icon. You know, being a program designer is a WHOLE lot easier than being a programmer. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 7 16:50: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id BA24914E9D for ; Wed, 7 Jul 1999 16:49:53 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA26853; Wed, 7 Jul 1999 16:49:21 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA05496; Wed, 7 Jul 1999 16:49:21 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA15564; Wed, 7 Jul 99 16:49:20 PDT Message-Id: <3783E780.C9AB3D41@softweyr.com> Date: Wed, 07 Jul 1999 17:49:20 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: User Joe Cc: hackers@FreeBSD.ORG Subject: Re: Berkeley DB question References: <199907072028.NAA21795@monk.via.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG User Joe wrote: > > Is the berkeley db (or any other small db) multi user safe? Are there > locks to maintain coherency of multiple processes access the same database files? No. I've heard that Cygnus newlib has a thread-safe version of db or dbm, but haven't checked it out myself. It may bear looking into. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 7 16:55:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8C7BF14E9D; Wed, 7 Jul 1999 16:55:37 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA25930; Wed, 7 Jul 1999 16:55:29 -0700 (PDT) Date: Wed, 7 Jul 1999 16:55:28 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-Reply-To: <199907072323.QAA94794@apollo.backplane.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, 7 Jul 1999, Matthew Dillon wrote: > :> limit ought to work for a 4G machine > :> > :> Since most of those news files were small, I think Kirk's news test code > :> is pretty much the worse case scenario as far as vnode allocation goes. > : > : Well, I could possibly live with 256MB, but the vnode/fsnode consumption > :seems to be getting a bit silly in the memory overhead department, even for > :machines with 4GB of RAM. It seems like there needs to be fewer of them > :and/or they need to go on a diet. > : > :-DG > : > :David Greenman > > Well, the problem occurs because the system has sufficient memory to keep > the underlying VM object around. The current vnode code will not place > a vnode on the free list until the underlying VM object goes away. The > 60MB worth of KVM being used to hold vnodes is supporting 1GB worth > of cached VM pages ( associated with small files, that is ). So even > though the numbers look strange, it does seem to scale. > > In order to turn the maxvnodes sysctl into a harder limit, the vnode > allocation & freeing code would have to be reworked some. Right now > vnodes are not placed back onto the free list until their underlying > VM objects go away. We would need to make the vnode lists (which are > headed by mount table entries) LRU and then attempt to reuse the vnodes > that way, destroying the underlying VM object when necessary. > > Alternatively we can try to make the vnode structure smaller, or we > could try to decouple the vnode from the VM object and instead reference > the VM object by inode. All I can say to that: Yuch. I'd rather just > bump up the KVM. or do what Kirk wants to do and merge the VM and Vnode structures I belive the UVM does a bit in this direction due to kirk's influence. julian > > -Matt > Matthew Dillon > > > > > 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 7 17: 1:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BC14D1510E; Wed, 7 Jul 1999 17:01:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA95104; Wed, 7 Jul 1999 17:01:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 17:01:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080001.RAA95104@apollo.backplane.com> To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907072334.QAA23809@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : We've been here before, a couple of times. This started to become an issue :when the limits were removed and has gotten worse as the vnode and fsnode :structs have grown over time. We're running into some limits on how much :space we can give to the kernel since there are a number of folks which :think that 3GB of process VA space is a minimum. I tend to think that the :2GB/2GB split that I use on wcarchive is probably more appropriate as a :default, but like I say, others disagree. : :-DG : :David Greenman If we added the capability to the buffer cache to delete B_DELWRI B_VMIO buffers (leaving dirty VM pages behind), we could reduce the size of the filesystem buffer cache considerably while at the same time improve our ability to cache dirty data - assuming all the other problems related to doing that sort of thing get fixed, that is. I am heading this way already as are others -- the filesystem buffer cache really needs to be relegated to handling active I/O and filesystem mappings, not holding onto dirty data for dear life. This would require keeping track of most dirty pages, which isn't too hard to do - we split the vm_object page list into a clean and a dirty list, and we keep the notion of clean and dirty vnodes so the update daemon doesn't change. If we can reduce the size of the filesystem buffer cache to something reasonable, more KVA space will be available for other kernel things. -- The biggest stumbling block to doing this is the reconstitution overhead of the buffer cache, as demonstrated by this simple test. As you can see by this test, the cost of reconstituting a filesystem buffer on a pentium-Pro 200 is roughly equivalent to 27 MBytes/sec worth of bandwidth. Create a big file: dd if=/dev/zero of=test bs=32k count=4096 DD back in (several times) a block big enough to fit in the VM page cache but not big enough to fit into the filesystem buffer cache. No actual disk I/O occurs: dd if=test of=/dev/null bs=32k count=256 8388608 bytes transferred in 0.146539 secs (57244848 bytes/sec) DD back in (several times) a block big enough to fit in the VM page cache *AND* the filesystem buffer cache. No actual disk I/O occurs: apollo:/usr/obj# dd if=test of=/dev/null bs=32k count=64 2097152 bytes transferred in 0.024780 secs (84630712 bytes/sec) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17: 3:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C24EE154D5; Wed, 7 Jul 1999 17:03:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA95132; Wed, 7 Jul 1999 17:03:16 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 17:03:16 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080003.RAA95132@apollo.backplane.com> To: Julian Elischer Cc: David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :or do what Kirk wants to do and merge the VM and Vnode structures :I belive the UVM does a bit in this direction due to kirk's influence. : :julian If this could result in a smaller overall structure, it may be worth it. To really make the combined structure smaller we would also have to pair-down the fields in both structures. For example, the vnode structure contains a lot of temporary clustering fields that could be removed entirely if clustering operations are done at the time of the actual I/O rather then before hand ( which leads to other problems related to low-memory deadlocks :-(... but assuming that could be fixed... ). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:13:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 5669C14FAC; Wed, 7 Jul 1999 17:13:17 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19187; Wed, 7 Jul 1999 17:12:54 -0700 (PDT) Message-Id: <199907080012.RAA19187@lestat.nas.nasa.gov> To: Julian Elischer Cc: Matthew Dillon , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:12:53 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) Julian Elischer wrote: > or do what Kirk wants to do and merge the VM and Vnode structures > I belive the UVM does a bit in this direction due to kirk's influence. A uvm_object is not a standalone thing in UVM. Every thing that's mappable in UVM has a uvm_object embedded in it. In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains a uvm_object. This has direct performance benefits as described in both Chuck's thesis and in his USENIX paper. Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is where the unified buffer cache work is happening, there is almost no distinction between a vnode and an object. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:21:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7B582154D7; Wed, 7 Jul 1999 17:21:04 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id RAA26717; Wed, 7 Jul 1999 17:20:55 -0700 (PDT) Date: Wed, 7 Jul 1999 17:20:54 -0700 (PDT) From: Julian Elischer To: Jason Thorpe Cc: Matthew Dillon , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-Reply-To: <199907080012.RAA19187@lestat.nas.nasa.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 Wed, 7 Jul 1999, Jason Thorpe wrote: > On Wed, 7 Jul 1999 16:55:28 -0700 (PDT) > Julian Elischer wrote: > > > or do what Kirk wants to do and merge the VM and Vnode structures > > I belive the UVM does a bit in this direction due to kirk's influence. > > A uvm_object is not a standalone thing in UVM. Every thing that's > mappable in UVM has a uvm_object embedded in it. > > In the case of vnodes, a vnode contains a uvm_vnode, which in turn contains > a uvm_object. This has direct performance benefits as described in both > Chuck's thesis and in his USENIX paper. > > Now, in the case of the chs-ubc2 branch of the NetBSD source tree, which is > where the unified buffer cache work is happening, there is almost no > distinction between a vnode and an object. Yes, I understand... I was simplifying :-) > > -- Jason R. Thorpe > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:24:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 225A314C88; Wed, 7 Jul 1999 17:24:02 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19330; Wed, 7 Jul 1999 17:23:57 -0700 (PDT) Message-Id: <199907080023.RAA19330@lestat.nas.nasa.gov> To: Matthew Dillon Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:23:57 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) Matthew Dillon wrote: > If this could result in a smaller overall structure, it may be worth it. > To really make the combined structure smaller we would also have to > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). The way this is done in the still-in-development branch of NetBSD's unified buffer cache is to basically elimiate the old buffer cache interface for vnode read/write completely. When you want to do that sort of I/O to a vnode, you simply map a window of the object into KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault in as necessary, getting added to the vnode's memq), and release the window (via ubc_release()). The actual window mappings themselves can persist, as well (although those mappings are nuked immediately if the vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Clustering is done by the same clustered pagein/pageout that already exists in UVM. In addition, as described in the UVM paper at USENIX, placing the object directly in the vnode (which requires a somewhat fundamental change in the objects, at least nuking the concept of object chains) allows a mapped file's pages to persist in the page cache as long as the vnode itself is not recycled, as opposed to they annoying limit on persisting vnode objects that used to exist in NetBSD's Mach VM. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:36:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9A59F14C4A; Wed, 7 Jul 1999 17:36:21 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 7032B79; Thu, 8 Jul 1999 08:36:19 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: Matthew Dillon , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup In-reply-to: Your message of "Wed, 07 Jul 1999 17:23:57 MST." <199907080023.RAA19330@lestat.nas.nasa.gov> Date: Thu, 08 Jul 1999 08:36:19 +0800 From: Peter Wemm Message-Id: <19990708003619.7032B79@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) > Matthew Dillon wrote: > > > If this could result in a smaller overall structure, it may be worth i t. > > To really make the combined structure smaller we would also have to > > pair-down the fields in both structures. For example, the vnode struc ture > > contains a lot of temporary clustering fields that could be removed > > entirely if clustering operations are done at the time of the actual I /O > > rather then before hand ( which leads to other problems related to > > low-memory deadlocks :-(... but assuming that could be fixed... ). > > The way this is done in the still-in-development branch of NetBSD's > unified buffer cache is to basically elimiate the old buffer cache > interface for vnode read/write completely. When you want to do that > sort of I/O to a vnode, you simply map a window of the object into > KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault > in as necessary, getting added to the vnode's memq), and release the > window (via ubc_release()). The actual window mappings themselves can > persist, as well (although those mappings are nuked immediately if the > vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Out of curiosity, how does it handle the problem of small 512 byte directories? Does it consume a whole page or does it do something smarter? Or does the ubc work apply to read/write only and the filesystem itself continues to use the buffer cache interfaces for metadata and directories still? Does the caching part of the bio system still exist? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:37: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id 3E6B81552B for ; Wed, 7 Jul 1999 17:36:49 -0700 (PDT) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id UAA10633; Wed, 7 Jul 1999 20:36:47 -0400 (EDT) Received: (from ath@localhost) by stiegl.niksun.com (8.9.2/8.8.7) id UAA14167; Wed, 7 Jul 1999 20:36:47 -0400 (EDT) (envelope-from ath) To: Ollivier Robert Cc: "FreeBSD Hackers' list" Subject: Re: Sony Z505S [was: USB floppy & booting] References: <19990703174459.A57506@keltia.freenix.fr> From: Andrew Heybey Date: 07 Jul 1999 20:36:47 -0400 In-Reply-To: Ollivier Robert's message of "Sat, 3 Jul 1999 17:44:59 +0200" Message-ID: <85vhbwq8o0.fsf@stiegl.niksun.com> Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ollivier Robert writes: > Do we support booting from USB floppies ? I plan to buy one of the new VAIOs > (probably the Z505S with Celeron/333 + 64 MB + 12.1" screen) and it seems to > come with an USB floppy (as opposed to the probably-IDE of former models). > > They've apparently ditched both the PS/2 mouse and the IDE floppy and moved to > 2x USB ports... I also have my eye on one of these (or possibly the Z505SX: P-II/366 + 128M). Anyone know what kind of ethernet card is built in? What about the modem? These are new enough that a web search did not reveal much about what is inside. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:43:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 2267714C4A; Wed, 7 Jul 1999 17:43:44 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA19553; Wed, 7 Jul 1999 17:43:28 -0700 (PDT) Message-Id: <199907080043.RAA19553@lestat.nas.nasa.gov> To: Peter Wemm Cc: Matthew Dillon , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 17:43:27 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 08 Jul 1999 08:36:19 +0800 Peter Wemm wrote: > Out of curiosity, how does it handle the problem of small 512 byte > directories? Does it consume a whole page or does it do something smarter? > Or does the ubc work apply to read/write only and the filesystem itself > continues to use the buffer cache interfaces for metadata and directories > still? Does the caching part of the bio system still exist? At the moment, only VREG is handled w/ UBC. We plan on addressing that in the future. In the case of file system blocks smaller than a page size, multiple blocks are read into the page. In the case of small directories, "we'll burn that bridge when we come to it" (i.e. when we attempt to deal with non-VREG). So, the caching part of the bio interface still exists for now (in part, this helps us to use file systems which haven't yet been converted to the UBC interface). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:49:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.webnology.com (mercury.webnology.com [209.155.51.2]) by hub.freebsd.org (Postfix) with ESMTP id DAFF414C4A for ; Wed, 7 Jul 1999 17:49:09 -0700 (PDT) (envelope-from jooji@webnology.com) Received: from localhost (jooji@localhost) by mercury.webnology.com (8.9.2/8.9.2) with SMTP id SAA05696 for ; Wed, 7 Jul 1999 18:50:02 -0500 (CDT) Date: Wed, 7 Jul 1999 18:50:02 -0500 (CDT) From: "Jasper O'Malley" To: hackers@freebsd.org Subject: ARP breakage 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 haven't gotten much of a response in -stable, so I'll ask here. Any one know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See problem report bin/12448, but in a nutshell: # ifconfig ed1 ed1: flags=8843 mtu 1500 inet 192.168.54.1 netmask 0xffffff00 broadcast 192.168.54.255 ether 00:e0:29:32:21:ee # arp -a ? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet] ? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet] # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.54.254 UGSc 2 0 ed1 127.0.0.1 127.0.0.1 UH 0 4 lo0 192.168.27 link#1 UC 0 0 fxp0 192.168.54 link#2 UC 0 0 ed1 192.168.54.133 0:a0:c9:70:4c:1c UHLW 1 128 ed1 818 192.168.54.254 0:e0:1e:b9:7d:c1 UHLW 1 0 ed1 818 # arp -s 192.168.54.5 auto pub using interface ed1 for proxy with address 0:e0:29:32:21:ee arp: writing to routing socket: File exists ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What broke? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jooji@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 17:50:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cse.unl.edu (cse.unl.edu [129.93.33.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B1F214C18 for ; Wed, 7 Jul 1999 17:50:13 -0700 (PDT) (envelope-from obanta@cse.unl.edu) Received: (from obanta@localhost) by cse.unl.edu (8.9.1/8.9.1) id TAA568941; Wed, 7 Jul 1999 19:50:12 -0500 (CDT) From: Oliver Banta Message-Id: <199907080050.TAA568941@cse.unl.edu> Subject: Re: Problem with fxp driver and 82559 cards In-Reply-To: from Jay Kuri at "Jul 7, 1999 06:30:12 pm" To: jay@oneway.com (Jay Kuri) Date: Wed, 7 Jul 1999 19:50:12 -0500 (CDT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL49 (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 > I have been using the Intel EtherExpress Pro 10/100B cards for > some time. I just recieved a batch of the Intel Pro/100+ management > adapters. In most of my machines, they don't work. > > Everything I can find says they should be compatible, but there are very > clearly some problems. > > Doing FTP installs is impossible, on 3.2, if I can get it to start at all, > it gets 60% through bin and hangs. 2.2.8 gets 30% through and hangs. > > Large data transfers seem to cause the lockup. I know at least 1 netbsd > person has reported similar problems with these new cards, (kern/7216). I use the new Intel Pro/100+ Management adapters in several FreeBSD servers with no problems. I have also have done a FTP install using these adapters without a problem. You probably want to look elsewhere for the cause of the lockup. Cheers, -- Oliver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 18: 8:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 1073514D75 for ; Wed, 7 Jul 1999 18:08:22 -0700 (PDT) (envelope-from justin@rhapture.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id SAA27622 for ; Wed, 7 Jul 1999 18:08:20 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Wed, 07 Jul 1999 18:08:16 -0700 Received: from rhapture.apple.com (rhapture.apple.com [17.202.40.59]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id SAA23016 for ; Wed, 7 Jul 1999 18:08:16 -0700 Received: by rhapture.apple.com (8.9.1/8.9.1) id SAA00947 for hackers@FreeBSD.ORG; Wed, 7 Jul 1999 18:08:16 -0700 (PDT) Message-Id: <199907080108.SAA00947@rhapture.apple.com> To: hackers@freebsd.org Subject: Re: ARP breakage Date: Wed, 7 Jul 1999 18:08:14 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Jasper O'Malley > Date: 1999-07-07 17:49:24 -0700 > To: hackers@FreeBSD.ORG > Subject: ARP breakage > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > > > I haven't gotten much of a response in -stable, so I'll ask here. Any one > know what happened to proxy ARP in recent incarnations of 3.2-STABLE? See > problem report bin/12448, but in a nutshell: > [snip] > > # arp -s 192.168.54.5 auto pub > using interface ed1 for proxy with address 0:e0:29:32:21:ee > arp: writing to routing socket: File exists > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What broke? Out of curiosity, what does 'arp -a' show after the 'arp -s' command? Could be something like the "alias" response of 'ifconfig'... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 18:17:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f58.hotmail.com [207.82.251.192]) by hub.freebsd.org (Postfix) with SMTP id 692D214D75 for ; Wed, 7 Jul 1999 18:17:42 -0700 (PDT) (envelope-from repenting@hotmail.com) Received: (qmail 82315 invoked by uid 0); 8 Jul 1999 01:17:40 -0000 Message-ID: <19990708011740.82314.qmail@hotmail.com> Received: from 209.57.150.91 by www.hotmail.com with HTTP; Wed, 07 Jul 1999 18:17:40 PDT X-Originating-IP: [209.57.150.91] From: Mike Del To: freebsd-hackers@FreeBSD.org Subject: Someone want to add support for computer radio scaners? Date: Thu, 08 Jul 1999 01:17:40 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello All, I was just looking at http://www.winradio.com/ and was thinking that it would be a nice addition to FreeBSD. I don't own one of the cards, otherwise I would have started to see what I could do. But if anyone out there has one/has access to one, it would be interesting to add into FreeBSD. They also supply information for programming use of the device (http://www.winradio.com/home/developer.htm). Well thats all for now, Mike _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.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 7 18:21:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2214714D75; Wed, 7 Jul 1999 18:21:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95641; Wed, 7 Jul 1999 18:21:03 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:21:03 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080121.SAA95641@apollo.backplane.com> To: Jason Thorpe Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907080023.RAA19330@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The way this is done in the still-in-development branch of NetBSD's :unified buffer cache is to basically elimiate the old buffer cache :interface for vnode read/write completely. When you want to do that :sort of I/O to a vnode, you simply map a window of the object into :KVA space (via ubc_alloc()), do the uiomove (lettings the pages fault :in as necessary, getting added to the vnode's memq), and release the :window (via ubc_release()). The actual window mappings themselves can :persist, as well (although those mappings are nuked immediately if the :vnode is marked VTEXT on VAC machines, to eliminate bad cache interactions). Effectively this is what a piece of our buffer cache code does now. The problem is the other 60% of the buffer cache code that does the more complex stuff. I'd like to see our buffer cache devolve into just the I/O and mapping piece. Now, I also believe that when UVM maps those pages, it makes them copy-on-write so I/O can be initiated on the data without having to stall anyone attempting to make further modifications to the VM object. Is this correct? This is something I would like to throw into FreeBSD at some point. It would get rid of all the freeze/bogus-page hacks already in there and avoid a number of I/O blocking conditions that we currently face. However, I do not like the idea of taking page faults in kernel mode, which I believe UVM also does -- but I think the above could be implemented in FreeBSD without taking page faults. :In addition, as described in the UVM paper at USENIX, placing the :object directly in the vnode (which requires a somewhat fundamental :change in the objects, at least nuking the concept of object chains) Well, I do not like the "nuke the object chains" part of UVM. From what I can tell UVM is doing a considerable amount of extra work to avoid the object chain stuff, but only saving a small amount of overhead on vm_fault's ( though, compared to the original Mach stuff the UVM stuff is much, much better ). We've made a considerable number of improvements to our vm_object's in the last few months. But I do like the idea of a VM-specific substructure for vnodes and I do agree that embedding the master VM object in the vnode is a good idea. -Matt Matthew Dillon :allows a mapped file's pages to persist in the page cache as long as :the vnode itself is not recycled, as opposed to they annoying limit :on persisting vnode objects that used to exist in NetBSD's Mach VM. : : -- Jason R. Thorpe : : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 18:25:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 273AF15089 for ; Wed, 7 Jul 1999 18:25:32 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id VAA36031 for ; Wed, 7 Jul 1999 21:25:36 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 7 Jul 1999 21:25:36 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: hackers@FreeBSD.org Subject: sysctl question 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 set up a sysctl so that I may pass in a two pointers: one to pass in some data another to receive some data ? Is it possible? Otherwise, I think I should just do something with passing in an arbitrary data buffer (pointer to, rather) which contains the data necessary on entrance on exit will receive the (other type) of data as output. Right now, I have myself confused with the sysctl interface and I'm attempting to use oldptr, oldlen, newptr, and newlen all at the same time which is definitely wrong. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Wed Jul 7 18:27:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C6A2D14D75; Wed, 7 Jul 1999 18:27:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95703; Wed, 7 Jul 1999 18:27:23 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:27:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080127.SAA95703@apollo.backplane.com> To: Jason Thorpe Cc: Peter Wemm , Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup References: <199907080043.RAA19553@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Thu, 08 Jul 1999 08:36:19 +0800 : Peter Wemm wrote: : : > Out of curiosity, how does it handle the problem of small 512 byte : > directories? Does it consume a whole page or does it do something smarter? : > Or does the ubc work apply to read/write only and the filesystem itself : > continues to use the buffer cache interfaces for metadata and directories : > still? Does the caching part of the bio system still exist? : :At the moment, only VREG is handled w/ UBC. We plan on addressing that :in the future. : :In the case of file system blocks smaller than a page size, multiple :blocks are read into the page. In the case of small directories, :"we'll burn that bridge when we come to it" (i.e. when we attempt to :deal with non-VREG). : :So, the caching part of the bio interface still exists for now (in part, :this helps us to use file systems which haven't yet been converted to :the UBC interface). : : -- Jason R. Thorpe I would also like to add that FreeBSD's current method of handling small directories does not work very well. It saves memory, sure, but it is based on specialized B_MALLOC buffers in the buffer cache and is unable to use the wider-ranging VM page cache. Since we do not keep buffers around for very long and non-VMIO-backed memory goes away with the buffer, the result is that FreeBSD does a terrible job caching directories. DG and I have experimented with turning on VMIO backing for directories. It works except for a bug in softupdates which I am going to get Kirk interested in (so hopefully it will get fixed). John Dyson is against it due to the waste in memory but I am of the opinion that the waste will not be that bad - and, in anycase, the worst that can happen is that we will throw pages containing directory data away that would have long since been thrown away with the old buffer cache mechanism anyway. For FreeBSD, the changes are so simple that we can add a sysctl to turn the capability on and off. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 18:35: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 735EB150DF; Wed, 7 Jul 1999 18:34:50 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA11251; Thu, 8 Jul 1999 11:04:49 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA04756; Thu, 8 Jul 1999 11:04:47 +0930 (CST) Date: Thu, 8 Jul 1999 11:04:47 +0930 From: Greg Lehey To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Bursting at the seams (was: Heh heh, humorous lockup) Message-ID: <19990708110446.P2340@freebie.lemis.com> References: <99Jul8.090830est.40363@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <99Jul8.090830est.40363@border.alcanet.com.au>; from Peter Jeremy on Thu, Jul 08, 1999 at 09:26:09AM +1000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 8 July 1999 at 9:26:09 +1000, Peter Jeremy wrote: > David Greenman wrote: >> Yes, I do - at least with the 512MB figure. That would be half of the 1GB >> KVA space and large systems really need that space for things like network >> buffers and other map regions. > > Matthew Dillon wrote: >> What would be an acceptable upper limit? 256MB? 128MB? The test >> I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >> before the number of vnodes stabilized, on a 1GB machine. I would say >> that a 128MB upper limit would be too small for a 4G machine. A 256MB >> limit ought to work for a 4G machine > > It appears we're rapidly approaching the point where 32-bits isn't > enough. We could increase KVA - but that cuts into process VM space > (and a large machine is likely to have large processes). > > The other option is moving away from a flat memory model: How about > putting some of the larger kernel-only data-structures into another > segment? The downside is that unless we want to start passing `far' > pointers around (which is both ugly and inefficient), we need to > make the pointer address space transparent to the compiler. Why not put the kernel in a different address space? IIRC there's no absolute requirement for the kernel and userland to be in the same address space, and that way we would have 4 GB for each. Greg -- See complete headers for address, home page 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 7 18:38: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0989114D75; Wed, 7 Jul 1999 18:37:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95818; Wed, 7 Jul 1999 18:37:35 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Jul 1999 18:37:35 -0700 (PDT) From: Matthew Dillon Message-Id: <199907080137.SAA95818@apollo.backplane.com> To: Greg Lehey Cc: Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) References: <99Jul8.090830est.40363@border.alcanet.com.au> <19990708110446.P2340@freebie.lemis.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Why not put the kernel in a different address space? IIRC there's no :absolute requirement for the kernel and userland to be in the same :address space, and that way we would have 4 GB for each. : :Greg No, the syscall overhead is way too high if we have to mess with MMU context. This would work fine on certain cpus with hardware PID support, such as the MIPS, but the entire TLB is wiped when you change the mmu context on an Intel cpu. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 18:51:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.webnology.com (mercury.webnology.com [209.155.51.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B8AC14EF1 for ; Wed, 7 Jul 1999 18:51:13 -0700 (PDT) (envelope-from jooji@webnology.com) Received: from localhost (jooji@localhost) by mercury.webnology.com (8.9.2/8.9.2) with SMTP id TAA07070; Wed, 7 Jul 1999 19:52:04 -0500 (CDT) Date: Wed, 7 Jul 1999 19:52:04 -0500 (CDT) From: "Jasper O'Malley" To: "Justin C. Walker" Cc: hackers@FreeBSD.ORG Subject: Re: ARP breakage In-Reply-To: <199907080108.SAA00947@rhapture.apple.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, 7 Jul 1999, Justin C. Walker wrote: > Out of curiosity, what does 'arp -a' show after the 'arp -s' > command? Same thing it shows before the "arp -s" attempt, as does "netstat -nr" :( For the record, regular "arp -s" commands without the "pub" parameter (i.e. static ARP cache entries, no proxying) work fine. I have a couple of other related questions for anyone who knows the answer, too: 1) Can anyone explain the difference between "permanent published" ARP table entries, and "permanent published (proxy only)" ARP table entries? 2) What purpose does the RTF_ANNOUNCE (aka RTF_PROTO2) routing message flag serve? How about the sin_other parameter of the sockaddr_inarp structure (defined in /usr/include/netinet/if_ether.h)? How do they relate? 3) How about the significance of the RTF_HOST routing message flag (i.e. how does an IP "host" route functionally differ from a "net" route with a /32 netmask)? Or does this only have significance for non-IP routes? 4) What's the purpose of this snippet of code from rtmsg() in usr.sbin/arp/arp.c? if (doing_proxy) { if (export_only) sin_m.sin_other = SIN_PROXY; else { rtm->rtm_addrs |= RTA_NETMASK; rtm->rtm_flags &= ~RTF_HOST; } } If I remove the last line of code (rtm->rtm_flags &= ~RTF_HOST;) and recompile the arp command, it seems to insert the correct entry according to netstat -nr, but arp -a doesn't recognize it as "published": # newarp -s 192.168.54.5 auto pub using interface ed1 for proxy with address 0:e0:29:32:21:ee # newarp -a ? (192.168.54.5) at 0:e0:29:32:21:ee permanent [ethernet] ? (192.168.54.133) at 0:a0:c9:70:4c:1c [ethernet] ? (192.168.54.254) at 0:e0:1e:b9:7d:c1 [ethernet] # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.54.254 UGSc 2 0 ed1 127.0.0.1 127.0.0.1 UH 0 4 lo0 192.168.27 link#1 UC 0 0 fxp0 192.168.54 link#2 UC 0 0 ed1 192.168.54.5 0:e0:29:32:21:ee UHLS2 0 0 ed1 192.168.54.133 0:a0:c9:70:4c:1c UHLW 1 322 ed1 509 192.168.54.254 0:e0:1e:b9:7d:c1 UHLW 1 0 ed1 509 Note, however, that the code *with* the rtm->rtm_flags &= ~RTF_HOST; worked in earlier incarnations of 3.2-STABLE (it's in 3.2-RELEASE). Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jooji@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19: 0: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 574F414EF1; Wed, 7 Jul 1999 19:00:00 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id KAA20622; Thu, 8 Jul 1999 10:59:58 +0900 (JST) Message-Id: <199907080159.KAA20622@rina.naklab.dnj.ynu.ac.jp> To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Tue, 06 Jul 1999 18:59:23 +0900" References: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 10:59:58 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another idea has come to my mind... pca(4) currently uses acquire_timer0(), which changes the timer frequency directly, breaking finetimer(9). I am considering to move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) comes to work again. Furthermore, we can get rid of acquire_timer0() and the related stuff in clkintr() to be much more simple than now. Any comments? Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19: 0:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2776F154E3 for ; Wed, 7 Jul 1999 19:00:10 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA27107; Wed, 7 Jul 1999 20:00:00 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA05546; Wed, 7 Jul 1999 19:57:41 -0600 (MDT) Message-Id: <199907080157.TAA05546@harmony.village.org> To: Peter Wemm Subject: Re: The busspace modernization initiative. Cc: Doug Rabson , hackers@freebsd.org In-reply-to: Your message of "Thu, 08 Jul 1999 07:06:48 +0800." <19990707230648.D771A78@overcee.netplex.com.au> References: <19990707230648.D771A78@overcee.netplex.com.au> Date: Wed, 07 Jul 1999 19:57:41 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990707230648.D771A78@overcee.netplex.com.au> Peter Wemm writes: : At the very least it must use the real resource lists, not a second copy. : That probably means that nexus.c itself would have to export these functions. Yes. Or that bus_space_*map would live in nexus.c. : At the moment, the probe/attach routines use ia_iot from the aux arg: ... : .. using the isa stuff for an example. (tough if they want multiple : IO ports per device, eh? like the keyboard controller at 0x60 and 0x64 with : another device in between...) ok. : It uses the tag to get a handle: : And uses the tag and handle in the bus_space_read/write_xxx() macros. Hmmm. That may mean we'd have to make both bus_space_tag_t and bus_space_handle_t be structs. The bus_space_tag_t so that we know which device it is, and bus_space_handle_t to record the rid. Must ponder. : I don't see why we couldn't add a device_t pointer in there as well, and the : newconfig shim could use it to store the device_t of the wrapper device. Yes. Right now on NetBSD there is only one instance per bus type of the bus_space_tag structure, however. We'd have to have one per device_t that is wrapped. : The bus_space_map() etc macros could then do the proper uplink calls to the : parent bus since it now has access to the device pointer. Yes. That's true. Suddenly, a light has gone on in my head, so I'll try to code this up later this evening and see if the light was a good light, or a wil-o-the-wisp.[*] Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19: 5:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 69EFA14BCD; Wed, 7 Jul 1999 19:04:46 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA32439; Wed, 7 Jul 1999 19:04:27 -0700 (PDT) Date: Wed, 7 Jul 1999 19:04:26 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-Reply-To: <199907080137.SAA95818@apollo.backplane.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 we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this.... (%fs points to user space or something) julian On Wed, 7 Jul 1999, Matthew Dillon wrote: > :Why not put the kernel in a different address space? IIRC there's no > :absolute requirement for the kernel and userland to be in the same > :address space, and that way we would have 4 GB for each. > : > :Greg > > No, the syscall overhead is way too high if we have to mess with MMU > context. This would work fine on certain cpus with hardware PID support, > such as the MIPS, but the entire TLB is wiped when you change the mmu > context on an Intel cpu. > > -Matt > Matthew Dillon > > > > 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 7 19: 7: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B791B14BCF; Wed, 7 Jul 1999 19:06:54 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA32652; Wed, 7 Jul 1999 19:06:49 -0700 (PDT) Date: Wed, 7 Jul 1999 19:06:48 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080159.KAA20622@rina.naklab.dnj.ynu.ac.jp> 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 uh... [phaser.whistle.com] 536 man 9 finetimer No entry for finetimer in section 9 of the manual On Thu, 8 Jul 1999, Seigo Tanimura wrote: > Another idea has come to my mind... > > > pca(4) currently uses acquire_timer0(), which changes the timer > frequency directly, breaking finetimer(9). I am considering to > move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4) > comes to work again. Furthermore, we can get rid of acquire_timer0() > and the related stuff in clkintr() to be much more simple than now. > > > Any comments? > > > Seigo Tanimura > > > 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 7 19:16: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 0460514BCD; Wed, 7 Jul 1999 19:15:56 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id LAA20789; Thu, 8 Jul 1999 11:15:45 +0900 (JST) Message-Id: <199907080215.LAA20789@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:06:48 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 11:15:45 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), Julian Elischer said: julian> uh... julian> [phaser.whistle.com] 536 man 9 finetimer julian> No entry for finetimer in section 9 of the manual Sorry, finetimer(9) is the new timer implemented in my latest midi driver. You can read the short paper describing the feature and principle in: Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> finetimer(9) has the same interface functions as timeout(9), so it should be easy to use it. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:19:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2CB8F15104; Wed, 7 Jul 1999 19:19:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA33562; Wed, 7 Jul 1999 19:18:58 -0700 (PDT) Date: Wed, 7 Jul 1999 19:18:57 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080215.LAA20789@rina.naklab.dnj.ynu.ac.jp> 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, 8 Jul 1999, Seigo Tanimura wrote: > On Wed, 7 Jul 1999 19:06:48 -0700 (PDT), > Julian Elischer said: > > julian> uh... > julian> [phaser.whistle.com] 536 man 9 finetimer > julian> No entry for finetimer in section 9 of the manual > > > Sorry, finetimer(9) is the new timer implemented in my latest midi driver. > You can read the short paper describing the feature and principle in: > > Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> how do I read that? > > finetimer(9) has the same interface functions as timeout(9), so it should > be easy to use it. > > > Seigo Tanimura > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:22:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6151814BCD; Wed, 7 Jul 1999 19:22:26 -0700 (PDT) (envelope-from intmktg@CAM.ORG) Received: from Ocean.CAM.ORG (Ocean.CAM.ORG [198.168.100.5]) by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP id WAA03843; Wed, 7 Jul 1999 22:22:23 -0400 (EDT) Date: Wed, 7 Jul 1999 22:22:24 -0400 (EDT) From: Marc Tardif To: freebsd-hackers@freebsd.org Cc: freebsd-fs@freebsd.org Subject: implementing a fs on a raw partition 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 As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:24:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 0DC5214BCD; Wed, 7 Jul 1999 19:24:17 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id LAA20834; Thu, 8 Jul 1999 11:24:15 +0900 (JST) Message-Id: <199907080224.LAA20834@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:18:57 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 11:24:15 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:18:57 -0700 (PDT), Julian Elischer said: >> Sorry, finetimer(9) is the new timer implemented in my latest midi driver. >> You can read the short paper describing the feature and principle in: >> >> Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp> julian> how do I read that? Ow, I thought it was in the mailing list archive, turned out not. I will attach the paper below. Sorry for a long mail. --- v --- cut here --- v --- Unlike 16550, MPU401 does not generate an interrupt on TX-ready. So we have to choose one of the following two options to drive MPU401: A. polling the status to wait until TX-ready, B. emulating a TX-ready interrupt by a timer. The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()), consumes most of syscall time to wait for MPU401 to come TX-ready. One byte of midi message takes 0.32ms to transmit. Some certain midi sequences contain continuous long sysexes summed up to 200 bytes or more, leaving a latency of 0.32 * 200 = 60ms or something like that. This latency results in an unstable tempo. I have chosen the option B to eliminate the latency on message transmission. In this case, the timer needs to be capable of a period less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s], which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems to shorten the period of timeout(9) enough, many parts of the kernel would be affected by this change, likely to end up with poor stability. To solve this problem, I propose a new *fine* callout mechanism. The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where (1 << hzmul) is the mutiplication ratio of hz. Although the ratio can be any natural number in theory, I have chosen the power of two to reduce the computational cost of the clock divider. (discussed later) As desceribed above, (for i386) clkintr() is called at (hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency. hardclock() has two elements in it: a callout detector and a clock divider. A callout detector traverses the callout list and makes a callout, as in softclock(), except that the IPL stays at splclock. A clock divider reduces the frequency to hz[Hz], to process the conventional hardclock(), which is now renamed to hardclock1(), and softclock(). Although dividing a clock tick generally involves a costing division operation of the dividor counter by (1 << hzmul), a ratio of 2^n allows us to replace the operation with a simple shift of (clkdiv >> hzmul), where clkdiv is the dividor counter incremented one by one on a hardclock(). Fig 1 shows the frequency and the IPL of the new timer handlers. Frequency IPL Timer ^ ^ Generator | | | | | v (hz * (1 << hzmul))[Hz] splclock clkintr() | | | | | v v v hardclock() -> Fine ________________________________________ | Callouts ^ ^ v | | hardclock1() | | | hz[Hz] splsoftclock v | | softclock() -> Conventional | | Callouts v v Fig 1: Call Frequency and IPL under New Timer Handling I have implemented the new fine callout system discussed above in the latest patch of my midi driver. hzmul is 6, to multiply the timer frequency to 6400Hz. The usage of the fine callout is the same as timeout(9), except for the prefix of fine-, and that the granularity of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done any quantitative evaluation yet, I played some midi sequences with sysex messages to show a picture on the LCD of my SC-88, recognizing no latency like VoxWare. This result states the effectiveness of my proposing fine callout system. The future works include porting to alpha and PC98, and tuning hzmul. --- ^ --- cut here --- ^ --- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:29:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 9D49F14CF9; Wed, 7 Jul 1999 19:29:33 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip145.houston3.tx.pub-ip.psi.net [38.12.169.145]) by leap.innerx.net (Postfix) with ESMTP id 6EAFC370BB; Wed, 7 Jul 1999 22:29:30 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id VAA43214; Wed, 7 Jul 1999 21:28:17 -0500 (CDT) (envelope-from chris) Date: Wed, 7 Jul 1999 21:28:16 -0500 From: Chris Costello To: Wes Peters Cc: Bill Fumerola , "Brian F. Feldman" , "Jordan K. Hubbard" , Doug , Alex Zepeda , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script Message-ID: <19990707212816.J41698@holly.dyndns.org> Reply-To: chris@calldei.com References: <37830CE9.480EF78A@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <37830CE9.480EF78A@softweyr.com>; from Wes Peters on Wed, Jul 07, 1999 at 02:16:41AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 7, 1999, Wes Peters wrote: > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. Wait until someone writes grtfm! GNOME support, panel applet, comes with Perl, C, C++, and Pascal bindings... > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) Most consumers are program designers. "I want it to control my printer and my modem and I want it done NOW." -- Chris Costello There are always at least two ways to program the same thing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:36:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id E839814BD8; Wed, 7 Jul 1999 19:36:15 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id MAA16726; Thu, 8 Jul 1999 12:36:01 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907080236.MAA16726@mycenae.ilion.eu.org> To: Greg Lehey Cc: Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-reply-to: Your message of "Thu, 08 Jul 1999 11:04:47 +0930." <19990708110446.P2340@freebie.lemis.com> Date: Thu, 08 Jul 1999 12:36:01 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why not put the kernel in a different address space? IIRC there's no > absolute requirement for the kernel and userland to be in the same > address space, and that way we would have 4 GB for each. Wouldn't that make system calls that need to share data between kernel and user spaces hopelessly inefficient? Things like sysctl() would need to introduce (temporary) memory mappings, and someone would have to keep track of these mappings and remove them as required, or the kernel would probably run out of address space in no time, given even with 4GB to spare. On top of that, every mapping established requires some messing arround with the TLB, which, at least on pentium, is rather expensive. Incidentally, someone already experimented with such "dual" address spaces on Linux, and the result was a 30% or so slow down. If you're interested, I can give you the relevant references (the scenario was somewhat different, but the source of the performance hit was the "dual" address space.) patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:46:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id 97D7614BD8; Wed, 7 Jul 1999 19:46:40 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id MAA16744; Thu, 8 Jul 1999 12:46:20 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907080246.MAA16744@mycenae.ilion.eu.org> To: Julian Elischer Cc: Matthew Dillon , Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-reply-to: Your message of "Wed, 07 Jul 1999 19:04:26 MST." Date: Thu, 08 Jul 1999 12:46:20 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this.... (%fs points to user space or something) ... as I've suggested a few days ago, and was told to shut up with a (rather irrelevant) reference to SASOS's. It can be done, in fact, it's already been done, with 50%+ performance improvement for tasks that rely heavily on IPC. (think client/server; email me for references.) However, it would involve a rather major redesign of the MMU and some redesign of the syscall stack. Further, one ends up restricting the size of the address space, which is fine until you start loading dynamic libraries. With something like libc, the working set may be small if all you need is a few system call stubs, but you end up with an extremely sparse address space which cannot be handled well with segmentation. Incidentally, you don't need to use FS to implement a tagged TLB using Liedtke's small address spaces. All you need is to modify CS, DS and SS; noone in the unix world relies on the values of ES and FS anyway; if they do, a quick-and-easy segmentation fault will teach them a lesson preaty fast. ;) patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 19:46:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9E17315132; Wed, 7 Jul 1999 19:46:42 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id TAA36196; Wed, 7 Jul 1999 19:46:40 -0700 (PDT) Date: Wed, 7 Jul 1999 19:46:38 -0700 (PDT) From: Julian Elischer To: Seigo Tanimura Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080224.LAA20834@rina.naklab.dnj.ynu.ac.jp> 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, 8 Jul 1999, Seigo Tanimura wrote: > > Ow, I thought it was in the mailing list archive, turned out not. > I will attach the paper below. Sorry for a long mail. > > > --- v --- cut here --- v --- > Unlike 16550, MPU401 does not generate an interrupt on TX-ready. > So we have to choose one of the following two options to drive [...] > alpha and PC98, and tuning hzmul. > --- ^ --- cut here --- ^ --- > > > Seigo Tanimura This is both more general and less general than aquire_timer0() aquiretimer0 assumes that there will only be one user of an elevated clock speed and produces a clock multiple of exactly the period that user requires. This allows us to generate a frequency of (for example) 16KHz. (not a power of 2) When it is not used it is turned off and there is no overhead. With your scheme the clock needs to be always running at elevated speed. Possibly you might have a startup routine that turns on the elevated frequency, (basically does an 'aquire_timer0()' ) I would say that you would have more success in implementing your finetimer() by using "aquiretimer0" than the other way around. a finetimer running at 16KHz (using aquire_timer0()) could allow the use of pca as well. (assuming we allowed 'reference counts on the timer to allow multiple clients that can use the same frequency.) Many people have thought about this. there are people who have run the system with Hz set to 1000 or more without great problems. We have always assumed in writing the code that hz may change so the code should be insulated from that change. The scheduling quantum is even done in uSecs and calculated against Hz. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 20: 3:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id 9D432151BE for ; Wed, 7 Jul 1999 20:03:39 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id XAA01115; Wed, 7 Jul 1999 23:03:32 -0400 (EDT) (envelope-from jay@oneway.com) Date: Wed, 7 Jul 1999 23:03:32 -0400 (EDT) From: Jay Kuri To: David Greenman Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-Reply-To: <199907072304.QAA23678@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 > >Large data transfers seem to cause the lockup. I know at least 1 netbsd > >person has reported similar problems with these new cards, (kern/7216). > > > >Has anyone seen problems like these? Any ideas? > > Hmmm...I've been using them in some machines here and haven't seen any > problems. Strange. Do all of your systems have similar motherboards and CPU? The only thing that I can identify as a common factor, is that the PCI slots are on a riser card. One type is an NLX-form factor motherboard. The other is an industrial system with a Single Board Computer (SBC) and a passive backplain. Aside from the riser card, these machines are completely different. (IDE vs. SCSI, no other PCI devices, SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in addition to the intel cards) vs nothing onboard...) However, we have at least one industrial-type system (with a different board/config) that works fine with these cards, though we didn't do the install with one. I'll try that tomorrow and report my findings. I doubt this is the case, but is the fxp driver different on the install floppy than on the post-install kernel / kernel-source? Any suggestions as to what I should look into? Thanks, Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 20: 4:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by hub.freebsd.org (Postfix) with ESMTP id A375315485 for ; Wed, 7 Jul 1999 20:04:18 -0700 (PDT) (envelope-from assar@sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id FAA22684; Thu, 8 Jul 1999 05:04:45 +0200 (CEST) To: Dag-Erling Smorgrav Cc: Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 08 Jul 1999 05:04:45 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "07 Jul 1999 23:01:13 +0200" Message-ID: <5lemij265u.fsf@assaris.sics.se> Lines: 25 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > > And besides, I really don't think this is a grep function but actually > > is useful for programs that don't have any strategy for handling out > > of memory errors and might as well die (with a descriptive error > > message, of course). Let's call it emalloc and let's put in somewhere > > where it can be used. > > Too simple to warrant that, and other programs will likely want to > handle the error differently. I don't agree. 1. this is a small function, but it's useful in lots of programs 2. that helps lazy programmers write code that actually checks for error returns instead of just ignoring them 3. it helps lots of programs that don't do anything intelligent (or for which there isn't much bright things to do) when allocating memory fails 4. having it in a library means it's more likely to be correct (i.e. sz == 0) but then again, I don't get to decide what goes in *BSD libc/libutil. In my library there's already a emalloc, ecalloc, and erealloc. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 20: 6:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id F2441151BE; Wed, 7 Jul 1999 20:06:53 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id UAA21280; Wed, 7 Jul 1999 20:06:33 -0700 (PDT) Message-Id: <199907080306.UAA21280@lestat.nas.nasa.gov> To: Matthew Dillon Cc: Julian Elischer , David Greenman , freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Heh heh, humorous lockup Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 07 Jul 1999 20:06:33 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 18:21:03 -0700 (PDT) Matthew Dillon wrote: > Now, I also believe that when UVM maps those pages, it makes them > copy-on-write so I/O can be initiated on the data without having to > stall anyone attempting to make further modifications to the VM object. > Is this correct? This is something I would like to throw into FreeBSD > at some point. It would get rid of all the freeze/bogus-page hacks > already in there and avoid a number of I/O blocking conditions that we > currently face. Um... In UVM+UBC, VOP_GETPAGES() and VOP_PUTPAGES() operate on pages marked w/ PG_BUSY. In the case of faulting a page in, the mapping isn't yet entered into the VA at which it will be accessed, and in the case of a page being paged out, the page has been deactivated (and thus has had all mappings removed) and marked PG_BUSY. Thus, if a fault which would reactivate the page occurs, the fault handler waits for PG_BUSY to clear before reentering the mapping at the VA where the page will be accessed. Now, while the fault handler is waiting for PG_BUSY to clear, something else can certainly modify the object... But in the case of faulting on the same page, the second thread will wait for PG_BUSY to clear, too, since the page has already been inserted into the object. The pager's KVA for the page is read/write, for obvious reasons[*]. [*] Mapping a faulting page *at all* is suboptimal, of course. You'd prefer to see if the device can handle a physical address (or a uio with physical addresses), and if so, use that. This is faster, and eliminates bad cache interactions on VAC systems. You really only want to map the page if you have to do PIO to/from it. This is all handled via the ubc_pager (which has a special fault routine, part of UVM's basic infrastructure). VOP_GETPAGES() and VOP_PUTPAGES() are basically helper routines for the ubc_pager (effectively turning the file systems themselves into "pagers"). > However, I do not like the idea of taking page faults in kernel mode, > which I believe UVM also does -- but I think the above could be > implemented in FreeBSD without taking page faults. Taking page faults in kernel mode is a perfectly reasonable thing to do, if you don't need to access those addresses in interrupt context. What is the reason for your aversion to pageable mappings in the kernel? > Well, I do not like the "nuke the object chains" part of UVM. From what > I can tell UVM is doing a considerable amount of extra work to avoid the > object chain stuff, but only saving a small amount of overhead on > vm_fault's ( though, compared to the original Mach stuff the UVM stuff is > much, much better ). We've made a considerable number of improvements > to our vm_object's in the last few months. But I do like the idea > of a VM-specific substructure for vnodes and I do agree that embedding > the master VM object in the vnode is a good idea. Nuking object chains actually made things *simpler*. The locking protocol, in the face of object chains, is nighmareish. With amap-on-top-object-on- bottom, it's simple, makes fault handling quite fast, and eliminates all the complexity otherwise necessary in collasping those nasty object chains (where the various objects in the chain may be referenced by more than one map entry). ...and, in some cases, it's NOT a "small amount of overhead". Whereas the Mach object chains may be of arbitrary length (think about a program which forks often), involving a potentially hash computation for each object in the chain, the UVM case is always, at the most, two layers (in the current amap implementation, the lookup is always a direct index into an array, and the object underneath is a hash lookup). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 20:10:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C4CFA14BD0; Wed, 7 Jul 1999 20:10:48 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id UAA37956; Wed, 7 Jul 1999 20:10:31 -0700 (PDT) Date: Wed, 7 Jul 1999 20:10:30 -0700 (PDT) From: Julian Elischer To: Patryk Zadarnowski Cc: Greg Lehey , Peter Jeremy , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-Reply-To: <199907080236.MAA16726@mycenae.ilion.eu.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, 8 Jul 1999, Patryk Zadarnowski wrote: > > > Why not put the kernel in a different address space? IIRC there's no > > absolute requirement for the kernel and userland to be in the same > > address space, and that way we would have 4 GB for each. > > Wouldn't that make system calls that need to share data between kernel > and user spaces hopelessly inefficient? Things like sysctl() would > need to introduce (temporary) memory mappings, and someone would have > to keep track of these mappings and remove them as required, or the > kernel would probably run out of address space in no time, given even > with 4GB to spare. On top of that, every mapping established requires > some messing arround with the TLB, which, at least on pentium, is > rather expensive. All user data is imported and exported to the kernel using special calls anyhow, as we've always thought that we may want to go back to the separate address spaces that we asarted out with on the 11-40 and 11-45 (etc.) so technically it wouldn't make too much work as far as altering the kernel. I guess however, having thought about it, that we'd have to reload CR3 on a syscall and that'd flush the TLBs which would be a pain.. > > Incidentally, someone already experimented with such "dual" address > spaces on Linux, and the result was a 30% or so slow down. If you're > interested, I can give you the relevant references (the scenario was > somewhat different, but the source of the performance hit was the > "dual" address space.) > > patryk. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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 7 20:23:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aha.ru (h250.zenon.net [195.2.83.119]) by hub.freebsd.org (Postfix) with ESMTP id C4C0814D1C for ; Wed, 7 Jul 1999 20:23:13 -0700 (PDT) (envelope-from mikhram@dataforce.net) Received: from [195.42.160.143] (HELO ramendik) by aha.ru (CommuniGate Pro SMTP 3.1b2) with SMTP id 4176112 for freebsd-hackers@freebsd.org; Thu, 08 Jul 1999 07:23:11 +0400 Message-ID: <003d01bec8f9$feeadf90$8fa02ac3@ramendik> From: "Mikhail Ramendik" To: Subject: Clipboard Daemon - thinking of writing one :) Date: Thu, 8 Jul 1999 07:22:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I am new to FreeBSD and Unix, but not new to programming and TCP/IP. I have noticed that there is no good clipboard system in FreeBSD. X has only a rudimentary clipboard, and outside X there is no clipboard that would be shared between programs... All this while Windows has a very interesting clipboard system that allows to paste as different types. I am thinking of writing a Clipboard Demon (of course, free and documented and source and all) to try and tackle this problem. It's going to be a daemon working over IP, it will allow "named clipboards" so that by default each user has one clipboard, but a user can start several clipboards and/or share one over a network (ok, insecure, at least in first releases - but then, it can be nonsensitive info over a LAN). It will allow a program to export data into the clipboard in one or _several_ formats (MIME, of course), and then it will allow the importing program to choose the format it wants (a la Windows, but no OLE stuff here) and get the data in it. For example, a GUI text editor can export the text as native format, text, formatted text (RTF?), vector graphics (unsure what format would replace WMF here), bitmap. This same editor will paste the native by default, another editor will use the formatted text by default, etc. Note that it will work independently of X. So I can copy in Joe then paste to GIMP (as text), if both support the clipboard. I will probably have time for actual coding in August or September. But I want to work out the specs first, and to make sure it's needed at all ;) So, my questions are: - Whether this thing is, in your opinion, needed - Whether a similar solution already exists in the freenix world (perhaps in Linux?) - How to handle "big" data? If a program exports a big graphic in several formats, that's a lot of data... Well, it can not actually send the data but only indicate it's available - but then we'd have to "call back" to receive the data, so the program would need to have a permanent connection with the daemon and "listen" to it, and the availability of data would cease when the program quits. Should I nevertheless include this behaviour as an option, to be decided by the exporting program? Now the newbie questions: - Where can I read a good text on writing FreeBSD daemons? - How can I choose a guaranteed free TCP port? Yours in Christ, Mikhail Ramendik Moscow, Russia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 20:49:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D1E2714CA1 for ; Wed, 7 Jul 1999 20:49:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id UAA40632; Wed, 7 Jul 1999 20:49:43 -0700 (PDT) Date: Wed, 7 Jul 1999 20:49:42 -0700 (PDT) From: Julian Elischer To: Mikhail Ramendik Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Clipboard Daemon - thinking of writing one :) In-Reply-To: <003d01bec8f9$feeadf90$8fa02ac3@ramendik> 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 hard part is going to be the applications to co-operate. good luck. it's be nice. especially if it worked with the syscons cut-n-paste. julian On Thu, 8 Jul 1999, Mikhail Ramendik wrote: > Hello! > > I am new to FreeBSD and Unix, but not new to programming and TCP/IP. > > I have noticed that there is no good clipboard system in FreeBSD. X has only > a rudimentary clipboard, and outside X there is no clipboard that would be > shared between programs... All this while Windows has a very interesting > clipboard system that allows to paste as different types. > > I am thinking of writing a Clipboard Demon (of course, free and documented > and source and all) to try and tackle this problem. It's going to be a > daemon working over IP, it will allow "named clipboards" so that by default > each user has one clipboard, but a user can start several clipboards and/or > share one over a network (ok, insecure, at least in first releases - but > then, it can be nonsensitive info over a LAN). It will allow a program to > export data into the clipboard in one or _several_ formats (MIME, of > course), and then it will allow the importing program to choose the format > it wants (a la Windows, but no OLE stuff here) and get the data in it. > > For example, a GUI text editor can export the text as native format, text, > formatted text (RTF?), vector graphics (unsure what format would replace WMF > here), bitmap. This same editor will paste the native by default, another > editor will use the formatted text by default, etc. > > Note that it will work independently of X. So I can copy in Joe then paste > to GIMP (as text), if both support the clipboard. > > I will probably have time for actual coding in August or September. But I > want to work out the specs first, and to make sure it's needed at all ;) So, > my questions are: > > - Whether this thing is, in your opinion, needed > > - Whether a similar solution already exists in the freenix world (perhaps in > Linux?) > > - How to handle "big" data? If a program exports a big graphic in several > formats, that's a lot of data... Well, it can not actually send the data but > only indicate it's available - but then we'd have to "call back" to receive > the data, so the program would need to have a permanent connection with the > daemon and "listen" to it, and the availability of data would cease when the > program quits. Should I nevertheless include this behaviour as an option, to > be decided by the exporting program? > > Now the newbie questions: > > - Where can I read a good text on writing FreeBSD daemons? > > - How can I choose a guaranteed free TCP port? > > Yours in Christ, Mikhail Ramendik > Moscow, Russia > > > > > 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 7 21:34:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from noc.demon.net (server.noc.demon.net [193.195.224.4]) by hub.freebsd.org (Postfix) with ESMTP id C5F0014D2A for ; Wed, 7 Jul 1999 21:34:17 -0700 (PDT) (envelope-from fanf@demon.net) Received: by noc.demon.net; id FAA01853; Thu, 8 Jul 1999 05:34:16 +0100 (BST) Received: from fanf.noc.demon.net(195.11.55.83) by inside.noc.demon.net via smap (3.2) id xmaa01836; Thu, 8 Jul 99 05:34:05 +0100 Received: from fanf by fanf.noc.demon.net with local (Exim 3.02 #13) id 1125st-0001e1-00 for hackers@freebsd.org; Thu, 08 Jul 1999 05:34:07 +0100 To: hackers@freebsd.org From: Tony Finch Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: References: Message-Id: Date: Thu, 08 Jul 1999 05:34:07 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > >Don't use err() indiscriminately after a malloc() failure; malloc() >doesn't set errno. When I looked at malloc(3) I decided that it relied on sbrk(2) to set errno if it returned 0. Is this wrong? i.e. can it return 0 without a failed syscall? Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 21:35:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from demai02.mw.mediaone.net (demai02.mw.mediaone.net [24.131.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 2E95114D2A for ; Wed, 7 Jul 1999 21:35:26 -0700 (PDT) (envelope-from mtaylor@cybernet.com) Received: from cybernet.com (nic-c12-205.mw.mediaone.net [24.131.12.205]) by demai02.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id AAA10615; Thu, 8 Jul 1999 00:33:31 -0400 (EDT) Message-ID: <37842A66.7AFE0FEC@cybernet.com> Date: Thu, 08 Jul 1999 00:34:46 -0400 From: "Mark J. Taylor" Organization: Cybernet Systems Corp. X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Wes Peters , hackers@freebsd.org Subject: Re: 'rtfm' script References: <37830CE9.480EF78A@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Put it in the ".login" or /etc/csh.login (etc.) file. They'll see it every time they log in. -Mark Taylor NetMAX Developer mtaylor@cybernet.com http://www.netmax.com/ Wes Peters wrote: > > Bill Fumerola wrote: > > > > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > > > Thanks! But still, I don't think rtfm is very appropriate... Can we look > > > for something better, more obvious? Or perhaps it would be in the motd > > > like /stand/sysinstall is.... people would need to be aware of this. > > > > it can be called anything. the new user isn't going to know it unless > > refered to it. (or unless there is a question mark to click) > > Now there's an idea! Someone wanna code up wmrtfm real quick? It should > start an rxvt (if available) or xterm running rtfm on strings that are > dropped onto or pasted into the dock icon. > > You know, being a program designer is a WHOLE lot easier than being a > programmer. ;^) > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > http://softweyr.com/ wes@softweyr.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 Wed Jul 7 21:40:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from argus.tfs.net (host1-155.birch.net [216.212.1.155]) by hub.freebsd.org (Postfix) with ESMTP id 6801614D2A for ; Wed, 7 Jul 1999 21:40:26 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id XAA37702; Wed, 7 Jul 1999 23:40:16 -0500 (CDT) From: Jim Bryant Message-Id: <199907080440.XAA37702@argus.tfs.net> Subject: Re: Someone want to add support for computer radio scaners? In-Reply-To: <19990708011740.82314.qmail@hotmail.com> from Mike Del at "Jul 8, 99 01:17:40 am" To: repenting@hotmail.com (Mike Del) Date: Wed, 7 Jul 1999 23:40:15 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-To: jbryant@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 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 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: > Hello All, > > I was just looking at http://www.winradio.com/ and was thinking > that it would be a nice addition to FreeBSD. I don't own one of the > cards, otherwise I would have started to see what I could do. But if > anyone out there has one/has access to one, it would be interesting > to add into FreeBSD. They also supply information for programming > use of the device (http://www.winradio.com/home/developer.htm). > > Well thats all for now, > Mike what they supply is a dog/winblowz sdk. the api is documented, but the libraries are provided in binary form, and there is no register level documentation. it might be a fair assumption that these "radios" are dumber than people think from the dynamic range and other crucial numbers, these radios pretty much suck. you would get better performance out of a direct conversion or trf receiver, honestly. 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 Wed Jul 7 21:56: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from noc.demon.net (server.noc.demon.net [193.195.224.4]) by hub.freebsd.org (Postfix) with ESMTP id 570EA154A4 for ; Wed, 7 Jul 1999 21:56:02 -0700 (PDT) (envelope-from fanf@demon.net) Received: by noc.demon.net; id FAA03830; Thu, 8 Jul 1999 05:56:02 +0100 (BST) Received: from fanf.noc.demon.net(195.11.55.83) by inside.noc.demon.net via smap (3.2) id xma003808; Thu, 8 Jul 99 05:55:57 +0100 Received: from fanf by fanf.noc.demon.net with local (Exim 3.02 #13) id 1126E3-0001fB-00 for hackers@freebsd.org; Thu, 08 Jul 1999 05:55:59 +0100 To: hackers@freebsd.org From: Tony Finch Subject: Re: Berkeley DB question In-Reply-To: <199907072028.NAA21795@monk.via.net> Message-Id: Date: Thu, 08 Jul 1999 05:55:59 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG User Joe wrote: > >Is the berkeley db (or any other small db) multi user safe? Are there >locks to maintain coherency of multiple processes access the same database files? The web pages for Berkeley DB 2 claim that it does (note version 2, not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 22: 8:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 44517154A4; Wed, 7 Jul 1999 22:08:12 -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 WAA23074; Wed, 7 Jul 1999 22:08:07 -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 WAA00991; Wed, 7 Jul 1999 22:08:06 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA15006; Wed, 7 Jul 1999 22:08:04 -0700 (PDT) From: Don Lewis Message-Id: <199907080508.WAA15006@salsa.gv.tsc.tdk.com> Date: Wed, 7 Jul 1999 22:08:04 -0700 In-Reply-To: "Jonathan M. Bresler" "Re: Pictures from USENIX" (Jul 4, 5:35pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jonathan M. Bresler" , grog@lemis.com Subject: Re: Pictures from USENIX Cc: billf@chc-chimes.com, nugget@slacker.com, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 4, 5:35pm, "Jonathan M. Bresler" wrote: } Subject: Re: Pictures from USENIX } beards are great...women love them, getting fluffed is much } better than getting scratched....kids love them. brush the beard } whenever you brush your hair. dont hae to deal with a buzzing razor, } very unkind to newly awoken folk. dont ahve to wield a blade across } you neck in a fogged monring stupor. } } jmb--i aint shaved in 18 years. I've got you beat by 4.5 years ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 23: 2:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 1D4F214DFC for ; Wed, 7 Jul 1999 23:02:39 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id XAA25090; Wed, 7 Jul 1999 23:01:26 -0700 (PDT) Message-Id: <199907080601.XAA25090@implode.root.com> To: Jay Kuri Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-reply-to: Your message of "Wed, 07 Jul 1999 23:03:32 EDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Jul 1999 23:01:26 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >Large data transfers seem to cause the lockup. I know at least 1 netbsd >> >person has reported similar problems with these new cards, (kern/7216). >> > >> >Has anyone seen problems like these? Any ideas? >> >> Hmmm...I've been using them in some machines here and haven't seen any >> problems. Strange. Do all of your systems have similar motherboards and CPU? > > The only thing that I can identify as a common factor, is that the >PCI slots are on a riser card. One type is an NLX-form factor >motherboard. The other is an industrial system with a Single Board >Computer (SBC) and a passive backplain. Aside from the riser card, these >machines are completely different. (IDE vs. SCSI, no other PCI devices, >SCSI pci device, pentium vs pentium-II... onboard video/ethernet(in >addition to the intel cards) vs nothing onboard...) > > However, we have at least one industrial-type system (with a >different board/config) that works fine with these cards, though we didn't >do the install with one. I'll try that tomorrow and report my findings. > >I doubt this is the case, but is the fxp driver different on the install >floppy than on the post-install kernel / kernel-source? Same driver on floppy and installed kernel. >Any suggestions as to what I should look into? It sounds like a motherboard chipset problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 7 23:17:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id C0E0E14E3B; Wed, 7 Jul 1999 23:17:10 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id PAA23884; Thu, 8 Jul 1999 15:17:08 +0900 (JST) Message-Id: <199907080617.PAA23884@rina.naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 7 Jul 1999 19:46:38 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 15:17:07 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), Julian Elischer said: julian> With your scheme the clock needs to be always running at elevated speed. julian> Possibly you might have a startup routine that turns on the elevated julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you julian> would have more success in implementing your finetimer() by using julian> "aquiretimer0" than the other way around. I agree that acquire_timer0() would give more freedom to the ticks to callout. Then I tried figuring out how to manage multiple callouts using acquire_timer0(), which is something like below. Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing though the queue to update the time tags on the callouts. (footnote: I'd better write in TeX :-<) Queueing a new callout c' to be made in t' involves a problem to find the maximum j (which is an integer, j >= 0) satisfying a constraint t' > \sum_(k=0)^(j) dt_rem(c_k) where the right hand side of the inequality is the time span after which the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is the difference of callout times, so they need not be updated on every clkintr(). Although the computational cost in clkintr() is generaly O(1), the queueing cost is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) How does it sound? Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 23:52:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 2767514EFF for ; Wed, 7 Jul 1999 23:52:17 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA18044; Thu, 8 Jul 1999 09:47:33 +0300 (EEST) (envelope-from will) To: julian@whistle.com (Julian Elischer) Cc: hackers@freebsd.org Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) References: <199907080137.SAA95818@apollo.backplane.com> From: Ville-Pertti Keinonen Date: 08 Jul 1999 09:47:32 +0300 In-Reply-To: julian@whistle.com's message of "8 Jul 1999 05:07:12 +0300" Message-ID: <86oghnr62j.fsf@not.demophon.com> Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG julian@whistle.com (Julian Elischer) writes: > we already use the gs register for SMP now.. > what about the fs register? > I vaguely remember that the different segments could be used to achieve > this.... (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 23:57: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id F0319154CE for ; Wed, 7 Jul 1999 23:57:00 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id XAA48153; Wed, 7 Jul 1999 23:55:37 -0700 (PDT) Date: Wed, 7 Jul 1999 23:55:36 -0700 (PDT) From: Julian Elischer To: Ville-Pertti Keinonen Cc: hackers@freebsd.org Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-Reply-To: <86oghnr62j.fsf@not.demophon.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 yeah I remembered how it all worked after I wrote that.. You'd think they'd eventually get the idea of letting the kernel have it's own 'cr3' and some TLBs eh? listenning intel? On 8 Jul 1999, Ville-Pertti Keinonen wrote: > > julian@whistle.com (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this.... (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 7 23:59:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id E3B8414D21 for ; Wed, 7 Jul 1999 23:59:47 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id QAA17097; Thu, 8 Jul 1999 16:59:16 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907080659.QAA17097@mycenae.ilion.eu.org> To: Ville-Pertti Keinonen Cc: julian@whistle.com (Julian Elischer), hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) In-reply-to: Your message of "08 Jul 1999 09:47:32 +0300." <86oghnr62j.fsf@not.demophon.com> Date: Thu, 08 Jul 1999 16:59:16 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > julian@whistle.com (Julian Elischer) writes: > > > we already use the gs register for SMP now.. > > what about the fs register? > > I vaguely remember that the different segments could be used to achieve > > this.... (%fs points to user space or something) > > You can't extend the address space that way, segments are all parts of > the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 0: 4: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 6214015273 for ; Thu, 8 Jul 1999 00:03:56 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA18054; Thu, 8 Jul 1999 09:59:17 +0300 (EEST) (envelope-from will) To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@freebsd.org Subject: Re: Heh heh, humorous lockup References: <199907080003.RAA95132@apollo.backplane.com> From: Ville-Pertti Keinonen Date: 08 Jul 1999 09:59:17 +0300 In-Reply-To: dillon@apollo.backplane.com's message of "8 Jul 1999 03:05:23 +0300" Message-ID: <86n1x7r5iy.fsf@not.demophon.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dillon@apollo.backplane.com (Matthew Dillon) writes: > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). Actually the vnode structure can be reduced in size quite a bit without affecting behavior. I analyzed this in a private mail to phk a few months ago, I can get the list of necessary changes out again if anyone is actually interested. The idea was to reduce the size to 128 bytes (on i386) so that the kernel malloc would do a reasonable job allocating the vnodes without too much overhead. IIRC it was very close. I had written code that allocated and deallocated vnodes dynamically (see http://www.hut.fi/~will/freebsd_vnfree0.diff for a non-malloc version with parameters adjusted to exercise the behavior quite heavily). It didn't seem like a very useful feature, though, because of fragmentation (even with the 'optimizing' zone allocator in the patch). Even if the kernel malloc would be usable, the only other common object that would typically use that memory would be ffs inodes, which are allocated and deallocated along with vnodes... This reminds me - the small patch I submitted to fix the v_id references still hasn't been commited (phk, if you're reading this, is there any specific reason for this?). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 0:11: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 3E7FA154DF for ; Thu, 8 Jul 1999 00:11:00 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id KAA18066; Thu, 8 Jul 1999 10:06:11 +0300 (EEST) (envelope-from will) To: patrykz@mycenae.ilion.eu.org (Patryk Zadarnowski) Cc: hackers@freebsd.org Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) References: <86oghnr62j.fsf@not.demophon.com> <199907080659.QAA17097@mycenae.ilion.eu.org> From: Ville-Pertti Keinonen Date: 08 Jul 1999 10:06:11 +0300 In-Reply-To: patrykz@mycenae.ilion.eu.org's message of "8 Jul 1999 10:00:15 +0300" Message-ID: <86lncrr57g.fsf@not.demophon.com> Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG patrykz@mycenae.ilion.eu.org (Patryk Zadarnowski) writes: > > You can't extend the address space that way, segments are all parts of > > the single 4GB address space described by the page mapping. > True, but you can reserve a part of the 4GB address space (say 128MB of it) > for partitioning into tiny (say 8MB) address spaces (which are still flat, > just small), for use by small processes, the idea being that all those small > processes will than share a single page table without compromising on memory > protection (the GDT is under full OS's control anyway), or the simplicity of > a flat address space (virtual addresses still start at 0 and continue till > the top of address space; the scheme is totally transparent.) Yeah, I know, I've read Liedtke's original paper where he described the optimization in L3, that's fine for that specific purpose, but that wasn't what the thread was about. Unless I totally missed the point. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 1: 1:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apb.iafrica.com (apb.iafrica.com [196.31.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 1D79A14C93 for ; Thu, 8 Jul 1999 01:01:10 -0700 (PDT) (envelope-from apb@iafrica.com) Received: from localhost (localhost [[UNIX: localhost]]) by apb.iafrica.com (8.8.8/8.8.8) with SMTP id KAA04344; Thu, 8 Jul 1999 10:00:52 +0200 (SAST) X-Authentication-Warning: apb.iafrica.com: apb owned process doing -bs Date: Thu, 8 Jul 1999 10:00:50 +0200 (SAST) From: Alan Barrett To: Jamie Howard Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) 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 Wed, 7 Jul 1999, Jamie Howard wrote: > The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: > > Grep understands two different versions of regular expression > syntax: ``basic'' and ``extended.'' In GNU grep, there is > no difference in available functionality using either syntax. > > Is this inaccurate or am I reading it wrong? I think that you are reading it wrong. It means "If you have a task that can be performed in GNU grep using a regexp in one syntax, then the same task can also be performed in GNU grep using a regexp in the other syntax". It does not also mean "... and the regexps in the two syntaxes will be identical". For example, if your task is "find lines that contain the characters " then you can use the basic RE '(X)' or the extended RE '\(X\)'. You can get the same functionality using either syntax, but the way you get that functionality will depend on which syntax you are using. --apb (Alan Barrett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 1:24:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 1CB8014E8D for ; Thu, 8 Jul 1999 01:24:14 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1129SU-000PJm-00; Thu, 08 Jul 1999 10:23:06 +0200 From: Sheldon Hearn To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. In-reply-to: Your message of "Thu, 08 Jul 1999 00:03:10 +0100." <19990708000310.A37390@catkin.nothing-going-on.org> Date: Thu, 08 Jul 1999 10:23:06 +0200 Message-ID: <97325.931422186@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 08 Jul 1999 00:03:10 +0100, Nik Clayton wrote: > I have done. As far as I can tell, the submitter is saying "Yes, the > information I was looking for was in the manual page, but it (specifically, > that the "root" account doesn't use the "default" entry) is buried as > a throw away comment at the end of a long paragraph." No. The PR suggests a fix to a completely different paragraph, describing a different function. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 1:55:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id DE872151ED; Thu, 8 Jul 1999 01:55:02 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA25055; Thu, 8 Jul 1999 09:54:42 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 8 Jul 1999 09:54:42 +0100 (BST) From: Doug Rabson To: Seigo Tanimura Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080617.PAA23884@rina.naklab.dnj.ynu.ac.jp> 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, 8 Jul 1999, Seigo Tanimura wrote: > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), > Julian Elischer said: > > julian> With your scheme the clock needs to be always running at elevated speed. > julian> Possibly you might have a startup routine that turns on the elevated > julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you > julian> would have more success in implementing your finetimer() by using > julian> "aquiretimer0" than the other way around. > > I agree that acquire_timer0() would give more freedom to the ticks > to callout. Then I tried figuring out how to manage multiple > callouts using acquire_timer0(), which is something like below. > > > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing > though the queue to update the time tags on the callouts. > > (footnote: I'd better write in TeX :-<) > > Queueing a new callout c' to be made in t' involves a problem to find the > maximum j (which is an integer, j >= 0) satisfying a constraint > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > where the right hand side of the inequality is the time span after which > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is > the difference of callout times, so they need not be updated on every clkintr(). > > > Although the computational cost in clkintr() is generaly O(1), the queueing cost > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) > > > How does it sound? If I understand this correctly, you are suggesting that we program timer0 so that we only take interrupts when a finetimer is due to fire? If so, then it sounds very good. The idea of taking 6000+ interrupts/sec made me uneasy, even though most would return without doing any work. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 2: 9:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web1005.mail.yahoo.com (web1005.mail.yahoo.com [128.11.23.95]) by hub.freebsd.org (Postfix) with SMTP id 8960315266 for ; Thu, 8 Jul 1999 02:09:28 -0700 (PDT) (envelope-from hae_geza@yahoo.com) Message-ID: <19990708090927.13666.rocketmail@web1005.mail.yahoo.com> Received: from [198.240.212.30] by web1005.mail.yahoo.com; Thu, 08 Jul 1999 02:09:27 PDT Date: Thu, 8 Jul 1999 02:09:27 -0700 (PDT) From: Geza Fodor Reply-To: geza.fodor@usa.net Subject: need a better solution as callback To: freebsd-hackers@freebsd.org Cc: freebsd-questions@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 hi to all, i have a freebsd installed with internet connection on my desktop pc and on my laptop as well. because i am traveling a lot between two countries, i'd like to make followings. - laptop dials to my desktop pc - laptop sends some command - desktop hangs up and dials to local isp - laptop dials also to a local isp - desktop sends a mail to me that means it is online (sends an ip address as well) - laptop logs in is it too much? any idea? thx geza _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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 8 2:22:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 51E88152E2; Thu, 8 Jul 1999 02:22:34 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id SAA05548; Thu, 8 Jul 1999 18:52:26 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199907080922.SAA05548@gizmo.internode.com.au> Subject: Re: need a better solution as callback To: geza.fodor@usa.net Date: Thu, 8 Jul 1999 18:52:26 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-Reply-To: <19990708090927.13666.rocketmail@web1005.mail.yahoo.com> from "Geza Fodor" at Jul 8, 99 02:09:27 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 Geza Fodor wrote: > i have a freebsd installed with internet connection on > my desktop pc and on my laptop as well. because i am > traveling a lot between two countries, i'd like to > make followings. You should be able to write some scripts which do this; theoretically, the "some commands to my desktop pc" bit can be an invocation of a background script which time-delays then initiates a PPP connection. - mark > - laptop dials to my desktop pc > - laptop sends some command > - desktop hangs up and dials to local isp > - laptop dials also to a local isp > - desktop sends a mail to me that means it is online > (sends an ip address as well) > - laptop logs in > > is it too much? any idea? ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 2:40:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 36FD214C14; Thu, 8 Jul 1999 02:40:39 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id SAA26649; Thu, 8 Jul 1999 18:40:23 +0900 (JST) Message-Id: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 09:54:42 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 18:40:23 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson said: dfr> If I understand this correctly, you are suggesting that we program timer0 dfr> so that we only take interrupts when a finetimer is due to fire? If so, dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr> uneasy, even though most would return without doing any work. Yes, that is what I am doing now. And some further discussion... > t' > \sum_(k=0)^(j) dt_rem(c_k) > > where the right hand side of the inequality is the time span after which > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). If t' is less than dt_rem(c_0) then we have no feasible j. This is the case in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), so that c_1 can be armed later. There is one problem in this method. acquire_timer0() is only implemented for i386. We would need to write something equivalent for alpha... Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 2:58:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C001914C14 for ; Thu, 8 Jul 1999 02:58:50 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA17727; Thu, 8 Jul 1999 05:58:39 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 8 Jul 1999 05:58:39 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mikhail Ramendik Cc: freebsd-hackers@freebsd.org Subject: Re: Clipboard Daemon - thinking of writing one :) In-Reply-To: <003d01bec8f9$feeadf90$8fa02ac3@ramendik> 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, 8 Jul 1999, Mikhail Ramendik wrote: > Hello! > > I am new to FreeBSD and Unix, but not new to programming and TCP/IP. > > I have noticed that there is no good clipboard system in FreeBSD. X has > only a rudimentary clipboard, and outside X there is no clipboard that > would be shared between programs... All this while Windows has a very > interesting clipboard system that allows to paste as different types. Retrofitting this kind of thing will almost certainly be hard: Microsoft has the advantage of writing the toolkits used by their application developers, and getting to change the rules at any point in time. Similarly, Microsoft hasn't delivered the network services that you describe below, either. :) Microsoft also has the advantage of being able to liberally mix the operating system and application space. In UNIX-land, the entire windowing system and toolkits on top are replaceable, meaning that there is more flexibility, but fewer standards other than de-facto standards. Consider instead placing your work in the context of an object system (see below) such as GNOME or KDE. > I am thinking of writing a Clipboard Demon (of course, free and > documented and source and all) to try and tackle this problem. It's > going to be a daemon working over IP, it will allow "named clipboards" > so that by default each user has one clipboard, but a user can start > several clipboards and/or share one over a network (ok, insecure, at > least in first releases - but then, it can be nonsensitive info over a > LAN). It will allow a program to export data into the clipboard in one > or _several_ formats (MIME, of course), and then it will allow the > importing program to choose the format it wants (a la Windows, but no > OLE stuff here) and get the data in it. Security will be an issue here. The traditional way to do this kind of thing is in the context of an existing distributed system of some kind, relying in its services for connection management, data format management, etc. A few considerations you might want to examine would be single-host security (who owns what data, when can different things be copied, pasted -- xterm runs as root, your shell runs as you, your X server runs as root, etc, etc), multi-host security (cryptography, mapping users between systems, existing distributed authentication schemes (kerberos, for example), etc), and access control -- will you have shared clipboards? > For example, a GUI text editor can export the text as native format, > text, formatted text (RTF?), vector graphics (unsure what format would > replace WMF here), bitmap. This same editor will paste the native by > default, another editor will use the formatted text by default, etc. > > Note that it will work independently of X. So I can copy in Joe then > paste to GIMP (as text), if both support the clipboard. > > I will probably have time for actual coding in August or September. But > I want to work out the specs first, and to make sure it's needed at all > ;) So, my questions are: > > - Whether this thing is, in your opinion, needed It sounds extremely useful. Network support is something that would be very nice to have, although you may be replicating work in distributed file systems. It might be worthwhile to consider whether an existing distributed file system might be a better time investment (Coda, AFS/Arla, etc) because it would provide a decent transport with a namespace, authentication, ACLs, etc. > - Whether a similar solution already exists in the freenix world > (perhaps in Linux?) Might want to look into the various distributed object models being considered (don't both the KDE and GNOME people have some interest in this?). I don't know much about them (KDE uses CORBA maybe?), but the chances are they have at least begun to address some of the complicated issues that you would need to look at. > - How to handle "big" data? If a program exports a big graphic in several > formats, that's a lot of data... Well, it can not actually send the data but > only indicate it's available - but then we'd have to "call back" to receive > the data, so the program would need to have a permanent connection with the > daemon and "listen" to it, and the availability of data would cease when the > program quits. Should I nevertheless include this behaviour as an option, to > be decided by the exporting program? > > Now the newbie questions: > > - Where can I read a good text on writing FreeBSD daemons? > > - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority > Yours in Christ, Mikhail Ramendik > Moscow, Russia Your project sounds interesting, but I suspect that you may want to reconsider your approach. It might make more sense to have a distributed database or network accessible database capable of managing typed data, access control, authentication, etc, and then a local daemon that communicates with it, as well as to library hooks in applications via file system socket capable of passing local credentials for authomatic local authentication. You could have a small X program that hooks the current X selection space (for easy interaction with existing text X applications), and then a library that could be linked into more complex applications that would provide some standard clipboard services by connecting to the local clipboard management daemon. I suspect however, this is not an easy project, and looking at existing distributed object systems may be a better way to go, along with a little adapter application that works with the X selection to provide legacy application support. Sounds fun. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 3: 1: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 4BD851514C; Thu, 8 Jul 1999 03:00:55 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA88985; Thu, 8 Jul 1999 11:00:25 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 8 Jul 1999 11:00:24 +0100 (BST) From: Doug Rabson To: Seigo Tanimura Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) In-Reply-To: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> 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, 8 Jul 1999, Seigo Tanimura wrote: > On Thu, 8 Jul 1999 09:54:42 +0100 (BST), > Doug Rabson said: > > dfr> If I understand this correctly, you are suggesting that we program timer0 > dfr> so that we only take interrupts when a finetimer is due to fire? If so, > dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me > dfr> uneasy, even though most would return without doing any work. > > > Yes, that is what I am doing now. And some further discussion... > > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > > > where the right hand side of the inequality is the time span after which > > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > If t' is less than dt_rem(c_0) then we have no feasible j. This is the case > in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) > is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), > so that c_1 can be armed later. > > > There is one problem in this method. acquire_timer0() is only implemented > for i386. We would need to write something equivalent for alpha... The timer hardware on the alpha is essentially the same but the interrupts are wired up differently. I'm not sure how hard it would be to get timer0 working but I think it should be possible. The alphas tend to run the main clock quite fast (typically 1024hz) so the granularity of timing is better but probably not good enough for midi or pca. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 4:20:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id E5CEE14D1C; Thu, 8 Jul 1999 04:20:06 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id UAA28709; Thu, 8 Jul 1999 20:19:18 +0900 (JST) Message-Id: <199907081119.UAA28709@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 11:00:24 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 08 Jul 1999 20:19:18 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999 11:00:24 +0100 (BST), Doug Rabson said: >> There is one problem in this method. acquire_timer0() is only implemented >> for i386. We would need to write something equivalent for alpha... dfr> The timer hardware on the alpha is essentially the same but the interrupts dfr> are wired up differently. I'm not sure how hard it would be to get timer0 dfr> working but I think it should be possible. I see. Then I can work on i386 first, and later on alpha. dfr> The alphas tend to run the main clock quite fast (typically 1024hz) so the dfr> granularity of timing is better but probably not good enough for midi or dfr> pca. I agree. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 6:39: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from traveler.e-scape.net (sentry.e-scape.net [207.245.48.254]) by hub.freebsd.org (Postfix) with SMTP id DD1271530B for ; Thu, 8 Jul 1999 06:38:54 -0700 (PDT) (envelope-from stefanos@traveler.e-scape.net) Received: by traveler.e-scape.net (NX5.67e/NX3.0M) id AA00657; Thu, 8 Jul 99 09:38:02 -0400 Message-Id: <9907081338.AA00657@traveler.e-scape.net> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b5) Received: by NeXT.Mailer (1.118.2) From: Kiakas Date: Thu, 8 Jul 99 09:38:00 -0400 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Clipboard Daemon - thinking of writing one :) Cc: mikhram@dataforce.net Reply-To: stefanos@traveler.e-scape.net References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You might also want to look a GNUstep ( www.gnustep.org ) as well. stef You wrote: > > - Whether a similar solution already exists in the freenix world > > (perhaps in Linux?) > > Might want to look into the various distributed object models being > considered (don't both the KDE and GNOME people have some interest in > this?). I don't know much about them (KDE uses CORBA maybe?), but the > chances are they have at least begun to address some of the complicated > issues that you would need to look at. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 8:28: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id E214E1530A; Thu, 8 Jul 1999 08:27:59 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id BAA04078; Fri, 9 Jul 1999 01:27:14 +1000 Date: Fri, 9 Jul 1999 01:27:14 +1000 From: Bruce Evans Message-Id: <199907081527.BAA04078@godzilla.zeta.org.au> To: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, julian@whistle.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >dfr> If I understand this correctly, you are suggesting that we program timer0 >dfr> so that we only take interrupts when a finetimer is due to fire? If so, >dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >dfr> uneasy, even though most would return without doing any work. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 50000 (16000 for pcaudio + 3 * 11520 for sio's). >There is one problem in this method. acquire_timer0() is only implemented >for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 8:29: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id A348915512 for ; Thu, 8 Jul 1999 08:28:57 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 112G6Z-000BsJ-00 for hackers@freebsd.org; Thu, 08 Jul 1999 17:28:55 +0200 From: Sheldon Hearn To: hackers@freebsd.org Subject: /etc/skel vs /usr/share/skel Date: Thu, 08 Jul 1999 17:28:55 +0200 Message-ID: <45650.931447735@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Do we still need /etc/skel in the hier(7) manpage and in BSD.root.dist? It looks to me like an hysterical raisin that should be taken out and shot. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 8:33: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.41.238]) by hub.freebsd.org (Postfix) with ESMTP id B9CDA14D4C; Thu, 8 Jul 1999 08:33:03 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id RAA02665; Thu, 8 Jul 1999 17:31:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, julian@whistle.com Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) In-reply-to: Your message of "Fri, 09 Jul 1999 01:27:14 +1000." <199907081527.BAA04078@godzilla.zeta.org.au> Date: Thu, 08 Jul 1999 17:31:48 +0200 Message-ID: <2663.931447908@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Somebody should study the abilities of the on-cpu APIC for this for pentium ff. machines. In message <199907081527.BAA04078@godzilla.zeta.org.au>, Bruce Evans writes: >>dfr> If I understand this correctly, you are suggesting that we program timer0 >>dfr> so that we only take interrupts when a finetimer is due to fire? If so, >>dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >>dfr> uneasy, even though most would return without doing any work. > >6000+ interrupts/sec is not many, unless it is done all the time. A >486/33 can handle about 50000 (16000 for pcaudio + 3 * 11520 for sio's). > >>There is one problem in this method. acquire_timer0() is only implemented >>for i386. We would need to write something equivalent for alpha... > >This is a serious problem. acquire_timer0() is currently disabled even >for i386's when the i8254 is used for timecounting. This is not hard >to fix (the hooks into clkintr() work even better with timecounters >since it is not necessary to resynchronise clock interrupts after a >state change), but an i8254 interrupt frequency of 16000 Hz is too fast >to be used routinely if the i8254 is being used for timecounting (even >if the CPU can keep up with the interrupts, the overflow heuristics in >i8254_get_timecount() may break down). Other systems may have even >more limitations on the timecounters. > >Bruce > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 8:47:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 3E57314DDB for ; Thu, 8 Jul 1999 08:47:20 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from localhost (rminnich@localhost) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA220807 for ; Thu, 8 Jul 1999 09:47:19 -0600 (MDT) Date: Thu, 8 Jul 1999 09:47:19 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Clipboard Daemon - thinking of writing one :) In-Reply-To: <003d01bec8f9$feeadf90$8fa02ac3@ramendik> 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, 8 Jul 1999, Mikhail Ramendik wrote: > I have noticed that there is no good clipboard system in FreeBSD. X has only > a rudimentary clipboard, and outside X there is no clipboard that would be > shared between programs... All this while Windows has a very interesting > clipboard system that allows to paste as different types. This is why Private Name Spaces are a good thing. They act like a file system (because they are a file system), they can be backed by a file system or whatever you wish (i've got both memory servers and file system servers) and they allow processes to create shared, private data to support such things as a clipboard. You don't need to write a special daemon, you just need to get private name spaces working on freebsd. I have a first piece in the v9fs file system, which is a memory file system but which is intended to support private name spaces in the future. Note that private name spaces work just fine over a network. 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 8 9: 0:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3BFE414EF7 for ; Thu, 8 Jul 1999 09:00:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA40621; Thu, 8 Jul 1999 09:00:26 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 09:00:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081600.JAA40621@apollo.backplane.com> To: Julian Elischer Cc: Ville-Pertti Keinonen , hackers@FreeBSD.ORG Subject: Re: Bursting at the seams (was: Heh heh, humorous lockup) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :yeah I remembered how it all worked after I wrote that.. :You'd think they'd eventually get the idea of letting the kernel have it's :own 'cr3' and some TLBs eh? : :listenning intel? This is intel we are talking about. Their mmu/cache technology is always a few years behind the times. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 10:57: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 84A4C14F1E; Thu, 8 Jul 1999 10:56:52 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id MAA12332; Thu, 8 Jul 1999 12:58:07 -0500 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma012289; Thu, 8 Jul 99 12:57:10 -0500 Received: from stlabcexg004.anheuser-busch.com ([151.145.101.160]) by 151.145.101.130 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 08 Jul 1999 17:55:37 0000 (GMT) Received: by stlabcexg004.anheuser-busch.com with Internet Mail Service (5.5.2448.0) id <3P8GPMS6>; Thu, 8 Jul 1999 12:55:43 -0500 Message-ID: From: "Alton, Matthew" To: "'Marc Tardif'" , freebsd-hackers@freebsd.org, "'alton@plantnet.com'" , "'alton@van.accessus.net'" Cc: freebsd-fs@freebsd.org Subject: RE: implementing a fs on a raw partition Date: Thu, 8 Jul 1999 12:55:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If someone in the FS dept. would draw up a broad outline for FS implementation I hereby volunteer to flesh it out thoroughly and donate the end-product docs to the FreeBSD project. I am a professional UNIX (AIX/SOLARIS) programmer and fairly clueful kernel source peruser and tweaker, fully capable of producing professional quality technical documentation. I propose the following iterative process: 1) FS guru draws up broad scheme. 2) I flesh it out with resort to trial and error & research, trying very hard to figure everything out for myself but ask precisely worded usually Y/N questions when I get good and stumped. 3) I submit draft for inspection by FS people, receive feedback. 4) I repair draft & goto (2) Please refer only to 3.x & 4.x methodology in the broad scheme. We'll make this a baseline and allow any deprecated stuff to properly atrophy into mummy dust. The purpose of this exercise is to produce a definitive procedure for coding new filesystems for use in the FreeBSD kernel. Benefits include speed of porting of 'foreign' FSes and feedback to the core group on implementation issues. Please CC alton@plantnet.com and alton@van.accessus.net in replies. The wife is 10 days overdue to deliver a baby and I'll (God, hopefully) be on vacation all next week and in sleep deprivation hallucinatory mode. > -----Original Message----- > From: Marc Tardif [SMTP:intmktg@CAM.ORG] > Sent: Wednesday, July 07, 1999 9:22 PM > To: freebsd-hackers@freebsd.org > Cc: freebsd-fs@freebsd.org > Subject: implementing a fs on a raw partition > > As I reading on filesystem algorithms and principles [bach 86 and mckusick > 96], I am tempted to try my hand on a free partition. From my > understanding, I should be using the partition as a character device for > raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). > From that point, I've been using the code from /usr/src/sys/msdosfs in > order to get something going at first... but this has shown to be an > exhausting task. I keep running into dependencies and such which make it > seem impossible to implement. Perhaps I have taken a wrong turn at > Albuquerque, so I'd appreciate if anyone could give a hint to get me up > and running. > > Thanks in advance, > Marc > > [bach 86] The Design of the UNIX Operating System, Maurice J. Bach > [mckusick 96] The Design and Implementation of the 4.4BSD Operating > System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. > Quarterman > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" 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 8 11: 0:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-relay2.yahoo.com (mail-relay2.yahoo.com [206.251.17.77]) by hub.freebsd.org (Postfix) with ESMTP id 0A1FF15134 for ; Thu, 8 Jul 1999 11:00:20 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from borogove.yahoo.com (borogove.yahoo.com [205.216.162.65]) by mail-relay2.yahoo.com (8.9.3/8.9.3) with ESMTP id LAA20883 for ; Thu, 8 Jul 1999 11:00:19 -0700 (PDT) Received: from yahoo-inc.com (milk.yahoo.com [206.132.89.117]) by borogove.yahoo.com (8.9.3/8.9.3) with ESMTP id LAA26478 for ; Thu, 8 Jul 1999 11:00:17 -0700 (PDT) Message-ID: <3784E730.558785CC@yahoo-inc.com> Date: Thu, 08 Jul 1999 11:00:16 -0700 From: Jayanth Vijayaraghavan X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: mbuf shortages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If a system runs out of mbufs can memory be claimed from elsewhere or is the system pretty much dead especially for networking related allocations. jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11: 6:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id 16E7515521 for ; Thu, 8 Jul 1999 11:06:35 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id OAA08212; Thu, 8 Jul 1999 14:06:32 -0400 (EDT) (envelope-from jay@oneway.com) Date: Thu, 8 Jul 1999 14:06:32 -0400 (EDT) From: Jay Kuri To: David Greenman Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-Reply-To: <199907080601.XAA25090@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 > > However, we have at least one industrial-type system (with a > >different board/config) that works fine with these cards, though we didn't > >do the install with one. I'll try that tomorrow and report my findings. Though the cards seem to work post-install, they fail in the install program. I can transfer files to my hearts content using the ftp program... but if I go into the installer and try to transfer a distribution , it fails, locking in the same way. I'm talking with Intel to see if they have had similar problems. I read something in the source about the reciever has locked after garbage in the syncronization bits... could it be a similar problem with the new chip, perhaps exposed by certain types of equipment? > >Any suggestions as to what I should look into? > It sounds like a motherboard chipset problem. It's a standard intel chipset... I'm getting a replacement BIOS to see if that makes a difference. Thanks, Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11: 8:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thneed.ubergeeks.com (thneed.ubergeeks.com [206.205.41.245]) by hub.freebsd.org (Postfix) with ESMTP id EAF6D152F9 for ; Thu, 8 Jul 1999 11:08:21 -0700 (PDT) (envelope-from adrian@ubergeeks.com) Received: from localhost (adrian@localhost) by thneed.ubergeeks.com (8.9.3/8.9.3) with ESMTP id OAA00752; Thu, 8 Jul 1999 14:08:02 -0400 (EDT) (envelope-from adrian@ubergeeks.com) X-Authentication-Warning: thneed.ubergeeks.com: adrian owned process doing -bs Date: Thu, 8 Jul 1999 14:08:02 -0400 (EDT) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: Sheldon Hearn Cc: Nik Clayton , hackers@FreeBSD.ORG Subject: Re: docs/12377: doc patch for login_cap. In-Reply-To: <93215.931241186@axl.noc.iafrica.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 Nope, I did read the docs, hence the patch to the manpage to make it stand out more clearly. I still am of the opinion that "default" should mean "default" for everyone. AFIK, there are no other fields in passwd that have different interpretations/defaults depending upon the UID. This is why I made my remarks about this being a violation of the principle of least surprise. My PR took the very conservative approach of just amplifying the documentation rather than making any funictional changes whatsoever. If a patch that make "default" the true default for all user and then explicitly set root's default class to 'root' would be accepted, I am willing to provide one. IMHO, this would be cleaner. The semantics of multiple default values boggles my mind. cheers, Adrian -- [ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] On Tue, 6 Jul 1999, Sheldon Hearn wrote: > > > On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: > > > I'm unfamiliar with the ins and outs of the login_cap system. Could > > someone who is versed in it please take a look at this PR (text included) > > and let me know whether or not the suggested patch is correct. > > Quite often, we receive requests to improve documentation that are born > out of a failure to read that documentation correctly. I think this PR > might be one of those cases. Have a look at the login_cap(3) manpage, > into which I suspect the submitter may not have dug deeply enough: > > The functions login_getpwclass(), login_getclass() and > login_getuserclass() retrieve the applicable login class > record for the user's passwd entry or class name by calling > login_getclassbyname(). On failure, NULL is returned. The > difference between these functions is that login_getuserclass() > includes the user's overriding .login_conf that exists in the > user's home directory, login_getpwclass,() and login_getclass() > restricts loookup only to the system login class database > in /etc/login.conf. login_getpwclass() only differs from > login_getclass() in that it allows the default class for user > 'root' as "root" if none has been specified in the password > database. Otherwise, if the passwd pointer is NULL, or the user > record has no login class, then the system "default" entry is > retrieved. > > Regards, > Sheldon. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Adrian -- [ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.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 8 11: 8:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 13B9A155B4 for ; Thu, 8 Jul 1999 11:08:47 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id LAA29051; Thu, 8 Jul 1999 11:08:12 -0700 (PDT) Message-Id: <199907081808.LAA29051@implode.root.com> To: Jay Kuri Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-reply-to: Your message of "Thu, 08 Jul 1999 14:06:32 EDT." From: David Greenman Reply-To: dg@root.com Date: Thu, 08 Jul 1999 11:08:11 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > However, we have at least one industrial-type system (with a >> >different board/config) that works fine with these cards, though we didn't >> >do the install with one. I'll try that tomorrow and report my findings. > > Though the cards seem to work post-install, they fail in the >install program. I can transfer files to my hearts content using the ftp >program... but if I go into the installer and try to transfer a >distribution , it fails, locking in the same way. I'm talking with Intel >to see if they have had similar problems. I read something in the source >about the reciever has locked after garbage in the syncronization bits... >could it be a similar problem with the new chip, perhaps exposed by >certain types of equipment? What's the cable plugged into? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.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 8 11:18:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id A0F8B14D7C for ; Thu, 8 Jul 1999 11:18:46 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id OAA08307; Thu, 8 Jul 1999 14:18:44 -0400 (EDT) (envelope-from jay@oneway.com) Date: Thu, 8 Jul 1999 14:18:43 -0400 (EDT) From: Jay Kuri To: David Greenman Cc: hackers@FreeBSD.ORG Subject: Re: Problem with fxp driver and 82559 cards In-Reply-To: <199907081808.LAA29051@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 > >program... but if I go into the installer and try to transfer a > >distribution , it fails, locking in the same way. I'm talking with Intel > >to see if they have had similar problems. I read something in the source > >about the reciever has locked after garbage in the syncronization bits... > >could it be a similar problem with the new chip, perhaps exposed by > >certain types of equipment? > > What's the cable plugged into? > We have tried: ATI switch (centrecom 3124tr) 10bT 3com SuperStack II (10/100) SMC TigerSwitch 10bT Same results on all of them. We've also tried setting media type to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11:24:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8D6D914F1E; Thu, 8 Jul 1999 11:24:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA70100; Thu, 8 Jul 1999 11:23:43 -0700 (PDT) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) From: Julian Elischer To: Doug Rabson Cc: Seigo Tanimura , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) 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 this is problematic. you cannot add a new element before the pending firing because you can't tell how far into the present trigger you are. On Thu, 8 Jul 1999, Doug Rabson wrote: > On Thu, 8 Jul 1999, Seigo Tanimura wrote: > > > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), > > Julian Elischer said: > > > > julian> With your scheme the clock needs to be always running at elevated speed. > > julian> Possibly you might have a startup routine that turns on the elevated > > julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you > > julian> would have more success in implementing your finetimer() by using > > julian> "aquiretimer0" than the other way around. > > > > I agree that acquire_timer0() would give more freedom to the ticks > > to callout. Then I tried figuring out how to manage multiple > > callouts using acquire_timer0(), which is something like below. > > > > > > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as > > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and > > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing > > though the queue to update the time tags on the callouts. > > > > (footnote: I'd better write in TeX :-<) > > > > Queueing a new callout c' to be made in t' involves a problem to find the > > maximum j (which is an integer, j >= 0) satisfying a constraint > > > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > > > where the right hand side of the inequality is the time span after which > > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > > > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then > > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is > > the difference of callout times, so they need not be updated on every clkintr(). > > > > > > Although the computational cost in clkintr() is generaly O(1), the queueing cost > > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) > > > > > > How does it sound? > > If I understand this correctly, you are suggesting that we program timer0 > so that we only take interrupts when a finetimer is due to fire? If so, > then it sounds very good. The idea of taking 6000+ interrupts/sec made me > uneasy, even though most would return without doing any work. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11:26:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E586514D7C; Thu, 8 Jul 1999 11:26:46 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA70394; Thu, 8 Jul 1999 11:26:43 -0700 (PDT) Date: Thu, 8 Jul 1999 11:26:43 -0700 (PDT) From: Julian Elischer To: geza.fodor@usa.net Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: need a better solution as callback In-Reply-To: <19990708090927.13666.rocketmail@web1005.mail.yahoo.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 Hi! I saw your posting on the HU list and was actually able to understand the Subject: line! (I guess it wasn't that difficult) It's fun to se the 'correct translation' so I could compare.. julian On Thu, 8 Jul 1999, Geza Fodor wrote: > hi to all, > > i have a freebsd installed with internet connection on > my desktop pc and on my laptop as well. because i am > traveling a lot between two countries, i'd like to > make followings. > > - laptop dials to my desktop pc > - laptop sends some command > - desktop hangs up and dials to local isp > - laptop dials also to a local isp > - desktop sends a mail to me that means it is online > (sends an ip address as well) > - laptop logs in > > is it too much? any idea? > > thx > geza > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.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 Thu Jul 8 11:35:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 3DD9515512; Thu, 8 Jul 1999 11:35:27 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA27042; Thu, 8 Jul 1999 11:35:24 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Thu, 8 Jul 1999 11:35:23 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Alex Zepeda Cc: "Brian F. Feldman" , Chris Costello , hackers@FreeBSD.ORG Subject: Re: 'rtfm' script 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, 6 Jul 1999, Alex Zepeda wrote: > On Tue, 6 Jul 1999, Brian F. Feldman wrote: > > > RTFM isn't a newby-apparent term. Name it help(1). > > Sure it is. Some hapless newbie wanders into #FreeBDS on efnet, and asks > an already answered question. Aside from a kick, and a possible ban, > they're likely to be met with a chorus of "rtfm", which in all likelyhood > would prompt the inquisitive newbie to try and run rtfm. So the whole script is the punch line to a bad joke? I'm all for improving user documentation, but I keep getting mixed answers as to what this script is for. One answer is that it's so people will have something to do when they are so new and foolish as to believe that 'rtfm' is a command, the other answer is that this script/program/whatever is designed to do a bunch of help file searching that the user could (and probably should be) do themselves. I'd like to make a suggestion which might help both goals, and save some time. Instead of making a program to do the searching for the user, why not write a man page for 'rtfm' that describes the many resources available and how to use them? Then the actual rtfm command could be a short program that just calls up the man page. It's not as glamorous, but IMO it will be more useful. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11:42:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F56215502 for ; Thu, 8 Jul 1999 11:42:06 -0700 (PDT) (envelope-from justin@rhapture.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAA38802 for ; Thu, 8 Jul 1999 11:41:57 -0700 Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Thu, 08 Jul 1999 11:36:21 -0700 Received: from rhapture.apple.com (rhapture.apple.com [17.202.40.59]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id LAA34578 for ; Thu, 8 Jul 1999 11:36:20 -0700 Received: by rhapture.apple.com (8.9.1/8.9.1) id LAA00694 for hackers@FreeBSD.ORG; Thu, 8 Jul 1999 11:36:20 -0700 (PDT) Message-Id: <199907081836.LAA00694@rhapture.apple.com> To: hackers@freebsd.org Subject: Re: Problem with fxp driver and 82559 cards In-Reply-To: <199907081808.LAA29051@implode.root.com> Date: Thu, 8 Jul 1999 11:36:19 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Jay Kuri > Date: 1999-07-08 11:19:01 -0700 > To: David Greenman > Subject: Re: Problem with fxp driver and 82559 cards > Cc: hackers@FreeBSD.ORG > In-reply-to: <199907081808.LAA29051@implode.root.com> > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > > > >program... but if I go into the installer and try to transfer a > > >distribution , it fails, locking in the same way. I'm talking with Intel > > >to see if they have had similar problems. I read something in the source > > >about the reciever has locked after garbage in the syncronization bits... > > >could it be a similar problem with the new chip, perhaps exposed by > > >certain types of equipment? > > > > What's the cable plugged into? > > > > We have tried: > > ATI switch (centrecom 3124tr) 10bT > 3com SuperStack II (10/100) > SMC TigerSwitch 10bT > > Same results on all of them. We've also tried setting media type > to 10baseT/UTP in the 'ifconfig options' in sysinstall... no difference. Some off-the-wall thoughts. I haven't followed this closely, but noticed the last few messages. Apologies if this is in the wrong ballpark. Have you tried a hub or a switch configured to stick with half-duplex? Also, some switches "go dark" when there's a change in port status, as might happen if a driver reinitializes the link. The switches are executing a spanning tree algorithm on the new port, looking for loops. If the switches can be configured to not do this (only needed for switch-switch connection), you might try that as well. (I'm not sure if the install issue is occuring soon after a boot, or is something else). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 11:51: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id C81ED14C8F for ; Thu, 8 Jul 1999 11:51:06 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA07171; Thu, 8 Jul 1999 11:50:43 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Luigi Rizzo Cc: billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-reply-to: Your message of "Sun, 04 Jul 1999 20:31:24 +0200." <199907041831.UAA17298@labinfo.iet.unipi.it> Date: Thu, 08 Jul 1999 11:50:43 -0700 Message-ID: <7168.931459843@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > just collecting URLs for people home pages might be an easier task > perhaps ? It needs to look better than that. A list of URL's would not look like a staff page, it would look like a cheesy, uninteresting page of links. :) - 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 8 11:59:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 314EC1551E for ; Thu, 8 Jul 1999 11:59:19 -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 SAA29209; Thu, 8 Jul 1999 18:29:11 +0200 From: Luigi Rizzo Message-Id: <199907081629.SAA29209@labinfo.iet.unipi.it> Subject: Re: Pictures from USENIX To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Thu, 8 Jul 1999 18:29:11 +0200 (MET DST) Cc: billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG In-Reply-To: <7168.931459843@zippy.cdrom.com> from "Jordan K. Hubbard" at Jul 8, 99 11:50:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 821 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > just collecting URLs for people home pages might be an easier task > > perhaps ? > > It needs to look better than that. A list of URL's would not look > like a staff page, it would look like a cheesy, uninteresting page of > links. :) still it can be a starting point. What success do you expect by asking people to prepare a resume! cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 12:35: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id 851DF1519D for ; Thu, 8 Jul 1999 12:34:58 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id VAA04808; Thu, 8 Jul 1999 21:30:33 +0200 (CEST) Message-Id: <199907081930.VAA04808@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: "Jordan K. Hubbard" Cc: Luigi Rizzo , billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX Reply-To: Gary Jennejohn In-reply-to: Your message of "Thu, 08 Jul 1999 11:50:43 PDT." <7168.931459843@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jul 1999 21:30:33 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" writes: >> just collecting URLs for people home pages might be an easier task >> perhaps ? > >It needs to look better than that. A list of URL's would not look >like a staff page, it would look like a cheesy, uninteresting page of >links. :) > besides, we don't all have, or even want to have, a home page. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.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 8 12:59:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fusion.qse.tohoku.ac.jp (saturn.qse.tohoku.ac.jp [130.34.70.56]) by hub.freebsd.org (Postfix) with ESMTP id 091EA150E6 for ; Thu, 8 Jul 1999 12:59:54 -0700 (PDT) (envelope-from kueda@jupiter.qse.tohoku.ac.jp) Received: from localhost (localhost [127.0.0.1]) by fusion.qse.tohoku.ac.jp (8.9.3/8.9.3) with ESMTP id EAA01344; Fri, 9 Jul 1999 04:59:53 +0900 (JST) (envelope-from kueda@jupiter.qse.tohoku.ac.jp) To: hackers@FreeBSD.ORG Subject: HELP!! Slice info disappeared From: Kazukiyo UEDA X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-fingerprint: 8F 5E EB B1 89 A9 83 A0 CF 6B 62 13 DE 02 F5 DA X-URL: http://jupiter.qse.tohoku.ac.jp/security/pgp/kueda.pgp Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990709045953J.kueda@jupiter.qse.tohoku.ac.jp> Date: Fri, 09 Jul 1999 04:59:53 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi hackers, I need your helps, please. I have two IDE drives. They have two slices for FreeBSD and Windows on each. Last night I tried to install Windows 95 on the first IDE drive where FreeBSD 3.1.0-Stable has installed. I executed fdisk program on MS-DOS and created an active slice to make it "C:" on the first drive. I successfully installed windows, and then rebooted FreeBSD. It's the beginning of my nightmare. On the boot time, kernel said there were no disklabel on the second IDE drive or something like that (sorry, I was so in panic that I didn't write them down on paper), and the system fall into single user mode. I checked the information for slices written on the second IDE, but it was almost the same as the first one. That is, each slices on second IDE have the same size on the first one. I didn't know what happened but I guess fdisk program changed the slice info not only for first IDE, but also the second one. I suppose (or wish) that the only slice information on the second IDE was overwritten, and the data on the second IDE are still there without any changes. Is there any way to retrieve the slice info? Any help is much appreciated. Thanks in advance, -- Kazukiyo UEDA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 13:11:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 7367A152FD for ; Thu, 8 Jul 1999 13:11:24 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id QAA25395 for ; Thu, 8 Jul 1999 16:11:21 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA21248; Thu, 8 Jul 1999 16:10:51 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id QAA06869 for freebsd-hackers@freebsd.org; Thu, 8 Jul 1999 16:10:51 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907082010.QAA06869@bb01f39.unx.sas.com> Subject: Strange select/poll behaviour [EBADF inconsistancy] To: freebsd-hackers@freebsd.org Date: Thu, 8 Jul 1999 16:10:51 -0400 (EDT) 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 Hi, The following program returns an inconsistant rc/errno value. Setting a bit corresponding to filedescriptor which is not open is only found when it is less than 20. ie: Some example output follows along with the program. This is being run on a -current system. If I open a file on fd 1023 then I receive EBADF all the way through which is what I expect. Our product depends on this behaviour (no, don't ask)... The man page specfies: The first nfds descriptors are checked in each set; i.e., the descriptors from 0 through nfds-1 in the descriptor sets are examined. I've seen that select seems to call poll, but I haven't trace all the way through poll yet. Any comments, critiques, or stupid user pointers are appreciated. Thanks! John [ 3] : Bad file descriptor [ 4] : Bad file descriptor [ 5] : Bad file descriptor [ 6] : Bad file descriptor [ 7] : Bad file descriptor [ 8] : Bad file descriptor [ 9] : Bad file descriptor [ 10] : Bad file descriptor [ 11] : Bad file descriptor [ 12] : Bad file descriptor [ 13] : Bad file descriptor [ 14] : Bad file descriptor [ 15] : Bad file descriptor [ 16] : Bad file descriptor [ 17] : Bad file descriptor [ 18] : Bad file descriptor [ 19] : Bad file descriptor [ 20] Timeout [ 21] Timeout [ 22] Timeout [ 23] Timeout [ 24] Timeout [ 25] Timeout #include #include #include #include #include #include static struct timeval nowait_s = {0, 0}; /* poll, no wait */ static struct timeval wait_s = {0, 100}; /* poll, wait 1 sec*/ fd_set local_rfd; fd_set local_wfd; main() { int n; struct timeval *tp; int max_fd = -1; int count; int bytes; int wait_time; int i; char * p; char buffer[256]; fprintf(stderr,"FD_SETSIZE = %d\n",FD_SETSIZE); for(i=3;i<40;++i) close(i); for(i=3;i<40;i++) { bzero(&local_rfd,sizeof(local_rfd)); bzero(&local_wfd,sizeof(local_wfd)); FD_SET(i,&local_rfd); tp = &wait_s; n = select (200,&local_rfd, 0, 0, tp); if (n < 0 ) { sprintf(buffer,"[%5d] ",i); perror(buffer); continue; } if (n == 0 ) { printf("[%5d] Timeout\n",i); } if (n > 0) { if ( FD_ISSET(0, &local_rfd) ) { printf("[ 0] READ\n"); } if ( FD_ISSET(i, &local_rfd) ) { printf("[%5d] READ\n",i); } } } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 13:23:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id E22D5151A3 for ; Thu, 8 Jul 1999 13:23:15 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id UAA91932; Thu, 8 Jul 1999 20:59:59 +0100 (BST) (envelope-from nik) Date: Thu, 8 Jul 1999 20:59:58 +0100 From: Nik Clayton To: Sheldon Hearn Cc: Nik Clayton , hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. Message-ID: <19990708205958.A91668@catkin.nothing-going-on.org> References: <19990708000310.A37390@catkin.nothing-going-on.org> <97325.931422186@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <97325.931422186@axl.noc.iafrica.com>; from Sheldon Hearn on Thu, Jul 08, 1999 at 10:23:06AM +0200 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon, On Thu, Jul 08, 1999 at 10:23:06AM +0200, Sheldon Hearn wrote: > > I have done. As far as I can tell, the submitter is saying "Yes, the > > information I was looking for was in the manual page, but it (specifically, > > that the "root" account doesn't use the "default" entry) is buried as > > a throw away comment at the end of a long paragraph." > > No. The PR suggests a fix to a completely different paragraph, > describing a different function. OK. I've looked at this in more detail, and it seems as though two functions are being described in the manual page: There's login_getpwclass(). This function will use the "root" entry for the root user if it exists, before falling back to "default". This is documented as such in the man page, so there are no problems there. In addition, there is login_getuserclass(). According to the PR, this also uses the "root" entry for the root user, if it exists, before falling back to "default" if it doesn't. Having now looked at (but not run) the code in src/lib/libutil/login_cap.c, I'm not convinced this last assertion in the PR is actually the case. It looks as if the code to use "root" instead of "default" first is in login_getpwclass(), but *not* in login_getuserclass(). So the PR is actually wrong about the text to add. That's fair enough. However, IMHO, the man page could be a bit clearer. Specifically, we have a paragraph that explains how defaults are looked up, and explicitly mentions the "default" class. We then have four intervening paragraphs, which do not relate to looking up the "default" entry. Finally, at the end of the fifth paragraph, is the information that login_getpwclass() will use a "root" entry first, before trying for "default" if the user being looked up is "root". This last piece of information really belongs with the earlier paragraph (although it can be repeated later on). With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? --- login_cap.3.org Thu Jul 8 13:15:35 1999 +++ login_cap.3 Thu Jul 8 13:22:00 1999 @@ -147,6 +147,11 @@ with that name returned in the .Ar lc_class field. +In addition, if the referenced user has a UID of 0 (normally, +"root", although the user name is not considered) then +.Fn login_getpwclass +will search for a record with an id of "root" before it searches +for the record with the id of "default". .Pp The .Ar lc_cap @@ -231,6 +236,7 @@ .Fn login_getclass restricts loookup only to the system login class database in .Pa /etc/login.conf . +As explained previously, .Fn login_getpwclass only differs from .Fn login_getclass N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 13:45:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 0FFB714FF9 for ; Thu, 8 Jul 1999 13:45:34 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA07613; Thu, 8 Jul 1999 13:44:20 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Luigi Rizzo Cc: billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX In-reply-to: Your message of "Thu, 08 Jul 1999 18:29:11 +0200." <199907081629.SAA29209@labinfo.iet.unipi.it> Date: Thu, 08 Jul 1999 13:44:20 -0700 Message-ID: <7610.931466660@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not asking any of you to prepare a resume - we're starting JUST with the core team bios and pictures here. :) - Jordan > > > just collecting URLs for people home pages might be an easier task > > > perhaps ? > > > > It needs to look better than that. A list of URL's would not look > > like a staff page, it would look like a cheesy, uninteresting page of > > links. :) > > still it can be a starting point. What success do you expect by asking > people to prepare a resume! > > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > ==== First International Workshop on Networked Group Communication ==== > -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 13:50: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 9608414FF9 for ; Thu, 8 Jul 1999 13:49:49 -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 UAA29454; Thu, 8 Jul 1999 20:19:31 +0200 From: Luigi Rizzo Message-Id: <199907081819.UAA29454@labinfo.iet.unipi.it> Subject: Re: Pictures from USENIX To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Thu, 8 Jul 1999 20:19:30 +0200 (MET DST) Cc: billf@chc-chimes.com, wilko@yedi.iaf.nl, wjw@iae.nl, grog@lemis.com, hackers@FreeBSD.ORG In-Reply-To: <7610.931466660@zippy.cdrom.com> from "Jordan K. Hubbard" at Jul 8, 99 01:44:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 186 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not asking any of you to prepare a resume - we're starting JUST with > the core team bios and pictures here. :) ^^^^ i knew you were not humans... cheers 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 8 14:28:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id F0D4814E4C for ; Thu, 8 Jul 1999 14:28:41 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA17507; Thu, 8 Jul 1999 16:28:38 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id QAA25077; Thu, 8 Jul 1999 16:28:37 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id QAA00631; Thu, 8 Jul 1999 16:28:37 -0500 (CDT) Date: Thu, 8 Jul 1999 16:28:37 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907082128.QAA00631@free.pcs> To: jwd@unx.sas.com, hackers@freebsd.org Subject: Re: Strange select/poll behaviour [EBADF inconsistancy] X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Hi, > > The following program returns an inconsistant rc/errno value. >Setting a bit corresponding to filedescriptor which is not open >is only found when it is less than 20. ie: This is because initially, only 20 descriptors are allocated, and the system is quietly ignoring any descriptors over the allocated amount: if (uap->nd > p->p_fd->fd_nfiles) uap->nd = p->p_fd->fd_nfiles; /* forgiving; slightly wrong */ This should be: if (uap->nd > p->p_fd->fd_nfiles) return (EBADF); -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 14:33:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9999914E4C for ; Thu, 8 Jul 1999 14:33:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA43126; Thu, 8 Jul 1999 14:33:19 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 14:33:19 -0700 (PDT) From: Matthew Dillon Message-Id: <199907082133.OAA43126@apollo.backplane.com> To: Jonathan Lemon Cc: jwd@unx.sas.com, hackers@FreeBSD.ORG Subject: Re: Strange select/poll behaviour [EBADF inconsistancy] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :This is because initially, only 20 descriptors are allocated, and :the system is quietly ignoring any descriptors over the allocated :amount: : : if (uap->nd > p->p_fd->fd_nfiles) : uap->nd = p->p_fd->fd_nfiles; /* forgiving; slightly wrong */ : :This should be: : : if (uap->nd > p->p_fd->fd_nfiles) : return (EBADF); : :-- :Jonathan Not unless you want to blow up virtually every program that uses select!!! Passing an nd parameter that is greater then the current number of descriptors is perfectly valid. It's setting a bit in the bitmask for one of those descriptors that should return EBADF! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 14:38:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 141FD15143 for ; Thu, 8 Jul 1999 14:38:35 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA17544; Thu, 8 Jul 1999 16:38:29 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id QAA26484; Thu, 8 Jul 1999 16:38:28 -0500 Message-ID: <19990708163828.36990@right.PCS> Date: Thu, 8 Jul 1999 16:38:28 -0500 From: Jonathan Lemon To: Matthew Dillon Cc: jwd@unx.sas.com, hackers@FreeBSD.ORG Subject: Re: Strange select/poll behaviour [EBADF inconsistancy] References: <199907082133.OAA43126@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199907082133.OAA43126@apollo.backplane.com>; from Matthew Dillon on Jul 07, 1999 at 02:33:19PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1999 at 02:33:19PM -0700, Matthew Dillon wrote: > Not unless you want to blow up virtually every program that uses select!!! > > Passing an nd parameter that is greater then the current number of > descriptors is perfectly valid. It's setting a bit in the bitmask for > one of those descriptors that should return EBADF! Hmm, you're right. Arguably, it could return EINVAL. Actually, the man page documents this behavior, although it gets the 256 number wrong. If nfds is greater than the number of open files, select() is not guaran- teed to examine the unused file descriptors. For historical reasons, select() will always examine the first 256 descriptors. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 14:45:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4E07C14EBE for ; Thu, 8 Jul 1999 14:45:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA43211; Thu, 8 Jul 1999 14:45:36 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 14:45:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199907082145.OAA43211@apollo.backplane.com> To: Jonathan Lemon Cc: jwd@unx.sas.com, hackers@FreeBSD.ORG Subject: Re: Strange select/poll behaviour [EBADF inconsistancy] References: <199907082133.OAA43126@apollo.backplane.com> <19990708163828.36990@right.PCS> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hmm, you're right. Arguably, it could return EINVAL. Actually, the :man page documents this behavior, although it gets the 256 number wrong. : : If nfds is greater than the number of open files, select() is not guaran- : teed to examine the unused file descriptors. For historical reasons, : select() will always examine the first 256 descriptors. : :-- :Jonathan This piece of the manual is justifying the fact that select() is not currently checking past the current number of open files -- which is how select() works now. The second part of that manual entry is just plain wrong: If you pass an nd value less then 256 it will only check that number of descriptors, it no longer examines a minimum of 256. It would definitely not be appropriate to return EINVAL. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 14:49: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 0F766150B8 for ; Thu, 8 Jul 1999 14:48:59 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA56531; Thu, 8 Jul 1999 17:48:47 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 8 Jul 1999 17:48:47 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Jonathan Lemon , jwd@unx.sas.com, hackers@FreeBSD.org Subject: Re: Strange select/poll behaviour [EBADF inconsistancy] In-Reply-To: <199907082145.OAA43211@apollo.backplane.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, 8 Jul 1999, Matthew Dillon wrote: > :Hmm, you're right. Arguably, it could return EINVAL. Actually, the > :man page documents this behavior, although it gets the 256 number wrong. > : > : If nfds is greater than the number of open files, select() is not guaran- > : teed to examine the unused file descriptors. For historical reasons, > : select() will always examine the first 256 descriptors. > : > :-- > :Jonathan > > This piece of the manual is justifying the fact that select() is not > currently checking past the current number of open files -- which > is how select() works now. The second part of that manual entry is just > plain wrong: If you pass an nd value less then 256 it will only check that > number of descriptors, it no longer examines a minimum of 256. So shouldn't someone correct it? I'll do it if noone else wants to. > > It would definitely not be appropriate to return EINVAL. I concur. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 Thu Jul 8 16:11:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D67214EB6 for ; Thu, 8 Jul 1999 16:10:58 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id WAA02643 for hackers@freebsd.org; Thu, 8 Jul 1999 22:22:48 +0100 (BST) (envelope-from nik) Date: Thu, 8 Jul 1999 22:22:47 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: dbm_* manpages for review Message-ID: <19990708222247.A2280@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -hackers, Tim Singletary has written some man pages for the dbm_* functions in libc, which are currently undocumented -- we know they are written in terms of dbopen(), but it's nice to have them documented anyway. Could anyone who knows anything about DBM take a look at docs/12557 and let me know if they are correct? If they are, I'll commit them. Cheers, N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 16:57:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 27001151D5 for ; Thu, 8 Jul 1999 16:57:18 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id TAA10527; Thu, 8 Jul 1999 19:57:14 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id TAA16948; Thu, 8 Jul 1999 19:57:12 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id TAA74127; Thu, 8 Jul 1999 19:57:09 -0400 (EDT) Date: Thu, 8 Jul 1999 19:57:09 -0400 (EDT) From: Thomas David Rivers Message-Id: <199907082357.TAA74127@lakes.dignus.com> To: brdean@unx.sas.com, peter@netplex.com.au Subject: Re: support for i386 hardware debug watch points Cc: freebsd-hackers@FreeBSD.ORG, rivers@dignus.com In-Reply-To: <199907041453.KAA03044@dean.pc.sas.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would "have it" - and the programs that "used it" wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - 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 8 17:16:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-98.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.98]) by hub.freebsd.org (Postfix) with ESMTP id BD8AA1553F; Thu, 8 Jul 1999 17:16:32 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA09813; Fri, 9 Jul 1999 01:06:57 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA64930; Fri, 9 Jul 1999 01:06:57 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907090006.BAA64930@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: geza.fodor@usa.net Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: need a better solution as callback In-reply-to: Your message of "Thu, 08 Jul 1999 02:09:27 PDT." <19990708090927.13666.rocketmail@web1005.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 01:06:57 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > hi to all, > > i have a freebsd installed with internet connection on > my desktop pc and on my laptop as well. because i am > traveling a lot between two countries, i'd like to > make followings. > > - laptop dials to my desktop pc > - laptop sends some command > - desktop hangs up and dials to local isp > - laptop dials also to a local isp > - desktop sends a mail to me that means it is online > (sends an ip address as well) > - laptop logs in > > is it too much? any idea? You can do better. Make the mgetty+sendfax port and run vgetty instead of mgetty. Set up your voice stuff (you'll need to copy the vgetty example config manually) and then create a dtmf.sh script. You can then dial your home machine on a handset, type in the correct DTMF sequence and have your machine connect to the 'net - you don't need to have direct dial access from your laptop :-) Ppp happily does this if you just give it a reasonable redial period & frequency. > thx > geza -- 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 Thu Jul 8 17:17:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 9767B155A8 for ; Thu, 8 Jul 1999 17:17:50 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA10566; Thu, 8 Jul 1999 17:15:36 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA10969; Thu, 8 Jul 1999 17:15:35 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA25049; Thu, 8 Jul 99 17:15:31 PDT Message-Id: <37853F23.39FAAF6D@softweyr.com> Date: Thu, 08 Jul 1999 18:15:31 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Dag-Erling Smorgrav Cc: Assar Westerlund , Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Assar Westerlund writes: > > Dag-Erling Smorgrav writes: > > > + realpat = grep_malloc(strlen(pattern) + sizeof("^(") > > > + + sizeof(")$") + 1); > > Why not just use asprintf? > > Doesn't matter, thsis code is gone in the latest version. You though > the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep > of the minute' :) You guys need the infamous two-headed-editor from 'Dave-n-Val the two- headed programmer' at Weber State. It allows two programmers to edit the same file on two terminals; it displays the line of code the OTHER user's cursor is on in red and won't let your cursor on that line. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 8 18:26:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ftp.dns.ne.jp (ftp.dns.ne.jp [210.155.3.5]) by hub.freebsd.org (Postfix) with ESMTP id 6D07B14E02; Thu, 8 Jul 1999 18:26:45 -0700 (PDT) (envelope-from tanimura@sakuramail.com) Received: from silver.carrots (yksk0124.ppp.infoweb.ne.jp [210.131.91.88]) by ftp.dns.ne.jp (8.9.2/8.8.5) with ESMTP id KAA16514; Fri, 9 Jul 1999 10:26:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by silver.carrots (8.9.3+3.2W/3.7W) with ESMTP id KAA70669; Fri, 9 Jul 1999 10:26:15 +0900 (JST) To: julian@whistle.com Cc: dfr@nlsystems.com, tanimura@naklab.dnj.ynu.ac.jp, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 11:23:42 -0700 (PDT)" References: X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990709102615A.tanimura@sakuramail.com> Date: Fri, 09 Jul 1999 10:26:15 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Julian Elischer Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) Message-ID: julian> this is problematic. julian> you cannot add a new element before the pending firing because you can't julian> tell how far into the present trigger you are. The workaround below would help it. The time elapsed since the last aquire_timer0() can be determined by latching the timer counter. From: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) Date: Thu, 08 Jul 1999 18:40:23 +0900 Message-ID: <199907080940.SAA26649@rina.naklab.dnj.ynu.ac.jp> tanimura> > t' > \sum_(k=0)^(j) dt_rem(c_k) tanimura> > tanimura> > where the right hand side of the inequality is the time span after which tanimura> > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) tanimura> > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). tanimura> tanimura> If t' is less than dt_rem(c_0) then we have no feasible j. This is the case tanimura> in which we must reaquire_timer0() using t'. Then, after interting c', dt_rem(c_1) tanimura> is updated to be (dt_rem(c_1) - (time elapsed since the last aquire_timer0())), tanimura> so that c_1 can be armed later. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 18:37:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sol (cs1-gw.cs.binghamton.edu [128.226.171.72]) by hub.freebsd.org (Postfix) with SMTP id 41EBC1511F for ; Thu, 8 Jul 1999 18:37:15 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from localhost (zzhang@localhost) by sol (SMI-8.6/8.6.9) with SMTP id VAA23545 for ; Thu, 8 Jul 1999 21:25:01 -0400 Date: Thu, 8 Jul 1999 21:25:01 -0400 (EDT) From: Zhihui Zhang To: freebsd-hackers@freebsd.org Subject: Wrong comment in VM code? 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 the beginning of the file vm_object.c, we have the following comment: The only items within the object structure which are modified after time of creation are: reference count locked by object's lock pager routine locked by object's lock But at the end of vnode_pager_setsize(), we modify the size field. So at least three items can be modified after creation. Am I right? Thanks for any help. -------------------------------------------------- Zhihui Zhang. Please visit 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 Thu Jul 8 18:52:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 858A415541 for ; Thu, 8 Jul 1999 18:52:38 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA08850; Thu, 8 Jul 1999 18:52:41 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Greg Lehey Cc: Matthew Dillon , Aaron Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Simplifying Vinum (was: ufs/ffs resize?) In-reply-to: Your message of "Sun, 27 Jun 1999 13:57:36 +0930." <19990627135736.F427@freebie.lemis.com> Date: Thu, 08 Jul 1999 18:52:41 -0700 Message-ID: <8846.931485161@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think you'll find, once you get that far, that things are anything > but trivial. I'm certainly open to suggestions, but consider: > > vinum -i /dev/something volumename > > Where does it insert it? What if the volume has more than one plex, > which it will in the case of a mirror? OK, perhaps I was getting a little carried away here. :) > Not if they're done well. I'm open to suggestions. Here are couple > of possibilities: add commands "cat", "stripe" and "mirror": > > vinum cat /dev/da1h /dev/da2h > vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h > vinum mirror /dev/da1h /dev/da2h > vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h These sound just fine to me! > And what about the names? It seems tacky to have to write down the > name that Vinum chooses. How about adding a name parameter, either > implicitly or explicitly? For example, > > vinum cat myvol /dev/da1h /dev/da2h > vinum cat -n myvol /dev/da1h /dev/da2h I also think that's a better proposal than mine, yes. - 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 8 19: 0: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id CAEA114C93 for ; Thu, 8 Jul 1999 18:59:57 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id VAA10163; Thu, 8 Jul 1999 21:59:35 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA08796; Thu, 8 Jul 1999 21:59:04 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id VAA24535; Thu, 8 Jul 1999 21:59:01 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907090159.VAA24535@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <199907082357.TAA74127@lakes.dignus.com> from Thomas David Rivers at "Jul 8, 1999 07:57:09 pm" To: rivers@dignus.com (Thomas David Rivers) Date: Thu, 8 Jul 1999 21:59:01 -0400 (EDT) Cc: peter@netplex.com.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 > From: Thomas David Rivers > > I just wondered if this should be integrated into ptrace(), so > the various debuggers wouldn't have to know about it. > > It seems that would be the proper abstraction - hardware that supports > it would "have it" - and the programs that "used it" wouldn't have to > know anything special. > > > I only have a passing knowledge of ptrace() - so, I may be totally wrong... > > - Dave Rivers - I think 'ptrace()' provides a natural interface for doing this. Under the covers, the 'ptrace()' calls are actually mapped to the corresponding procfs filesystem calls. While it is certainly possible to get at the registers using the more direct /proc/$pid/dbregs file, for historical reasons, the 'ptrace()' interface is probably the more expected method, and does not require issuing an open(), read(), write(), close() sequence. I've studied the code for 'gdb', and specifically the Linux support for their hardware debug registers. They use: ptrace (6, pid, offsetof (struct user, u_debugreg[DR_CONTROL]), debug_control_mirror); ptrace (6, pid, offsetof (struct user, u_debugreg[free_debug_register]), addr); Why they've hardcoded a '6' there I can't fathom, but it represents the PT_WRITE_U request to write directly into the child's user structure. Not only does this method require knowledge of x86 debug registers, but it also requires some knowledge of Linux internals. By providing a PT_[GET/SET]DBREGS request to 'ptrace()' in FreeBSD, which not by accident works identically to the existing PT_GET/SETREGS, and PT_GET/SETFPREG for getting/setting the general purpose and floating point processor registers, debuggers can focus on the hardware architecture, without having to be too concerned with obscure offsets of data within system data structures. In this respect, it actually results in less information that the programmer has to be aware of or keep track of. As far as providing a higher layer of abstraction, I must argue that these registers are primarily used only by debuggers, which must possess a very detailed kowledge of the underlying hardware by default. Thus, hiding the debug registers does not offer that much, however, exposing them to the debugger for complete control, can result in the complete debug support that is provided by the target architecture, as opposed to the subset that is supported across multiple architectures, that a higher level of abstraction implies. I suppose that in my view, I don't really see any difference in accessing the debug registers as accessing the general purpose registers or floating point registers, which is the model I used for this implementation. Also, this implementation currenly supports only those features that are available all the way back to the i386. Sorry for being so wordy. I should have provided some explanation for some of the design decisions that I made for this implementation when I posted my patches. I certainly hope that this work will be committed, because I think it adds a nice feature (once gdb supports it), especially for anyone who does non-trivial software development and debugging. Also, I must compliment the FreeBSD kernel folks ... the well designed internals of FreeBSD allowed a very clean implementation of this support. I did not have to do anything tricky to make it work. The framework was essentially there, I just had to "plug in" at the appropriate places in the kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 19:21:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 58D2015181 for ; Thu, 8 Jul 1999 19:21:22 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA17862; Fri, 9 Jul 1999 11:51:20 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA11723; Fri, 9 Jul 1999 11:51:18 +0930 (CST) Date: Fri, 9 Jul 1999 11:51:18 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: Matthew Dillon , Aaron Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Simplifying Vinum (was: ufs/ffs resize?) Message-ID: <19990709115118.T6035@freebie.lemis.com> References: <19990627135736.F427@freebie.lemis.com> <8846.931485161@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <8846.931485161@zippy.cdrom.com>; from Jordan K. Hubbard on Thu, Jul 08, 1999 at 06:52:41PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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, 8 July 1999 at 18:52:41 -0700, Jordan K. Hubbard wrote: >> I think you'll find, once you get that far, that things are anything >> but trivial. I'm certainly open to suggestions, but consider: >> >> vinum -i /dev/something volumename >> >> Where does it insert it? What if the volume has more than one plex, >> which it will in the case of a mirror? > > OK, perhaps I was getting a little carried away here. :) > >> Not if they're done well. I'm open to suggestions. Here are couple >> of possibilities: add commands "cat", "stripe" and "mirror": >> >> vinum cat /dev/da1h /dev/da2h >> vinum stripe /dev/da1h /dev/da2h /dev/da3h /dev/da4h >> vinum mirror /dev/da1h /dev/da2h >> vinum mirror /dev/da1h /dev/da2h /dev/da3h /dev/da4h > > These sound just fine to me! > >> And what about the names? It seems tacky to have to write down the >> name that Vinum chooses. How about adding a name parameter, either >> implicitly or explicitly? For example, >> >> vinum cat myvol /dev/da1h /dev/da2h >> vinum cat -n myvol /dev/da1h /dev/da2h > > I also think that's a better proposal than mine, yes. OK. This goes back to a message I wrote a long time ago. It's been a week since I committed the changes. Here's what we have (from vinum(8)): concat [-f] [-n name] [-v] drives Create a concatenated volume from the specified drives. mirror [-f] [-n name] [-s] [-v] drives Create a mirrored volume from the specified drives. stripe [-f] [-n name] [-v] drives Create a striped volume from the specified drives. The -s flag to mirror states whether to create concatenated or striped plexes for the mirror. Striped plexes always have stripes of 256 kB. For more details, RTFM. Greg -- See complete headers for address, home page 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 8 20:28:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id CD17114ECE for ; Thu, 8 Jul 1999 20:28:33 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id MAA08098 for hackers@freebsd.org; Fri, 9 Jul 1999 12:58:30 +0930 (CST) (envelope-from newton) Date: Fri, 9 Jul 1999 12:58:30 +0930 (CST) From: Mark Newton Message-Id: <199907090328.MAA08098@gizmo.internode.com.au> To: hackers@freebsd.org Subject: matcd on an SB16 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been following a local Linux mailing list, and a couple of the users there have been trying FreeBSD ('cos I'm giving a presentation on it at a Linux user group meeting next month :-) One of them has an SB16 with a CD-ROM drive. His attempts at installing FreeBSD from that CD-ROM have met with abysmal failure: $ Next came an install on my Pentium 60 (previously running Caldera-2.2) $ - A total disaster.... no way despite 12 attempts to install, could I $ get FreeBSD to actually initialise the sbpcd (freebsd calls it matcdc) $ despite changing IO's, entering the manual configuration option etc $ etc... it would not & could not, find the cdrom & so I had to abort the $ install every time!! Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone have any estimate of the amount of effort that'd be required to fix it? - mark Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone have any estimate of the amount of effort that'd be required to fix it? - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 21: 7:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 881AD14D64 for ; Thu, 8 Jul 1999 21:07:12 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id AAA15079 for ; Fri, 9 Jul 1999 00:07:11 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA13987; Fri, 9 Jul 1999 00:06:40 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id AAA10435 for freebsd-hackers@freebsd.org; Fri, 9 Jul 1999 00:06:40 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907090406.AAA10435@bb01f39.unx.sas.com> Subject: sigaction inconsistancy (here I go again) To: freebsd-hackers@freebsd.org Date: Fri, 9 Jul 1999 00:06:40 -0400 (EDT) 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 Hi, Running -current... I'm trying to verify SIGFPE handling and am finding some interesting issues. In the following test program, a divide by zero is done and the SIGFPE delivered. $ ./fp sig == 8 code== 0 z has the value 1.000000 It seems that from the value of code should have been: /* codes for SIGFPE/ARITHTRAP */ #define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */ ie: 3 and not 0. Also, I haven't gone into the code yet, but the floating point registers are not saved into the sigcontext so that they can be inspected and modified as appropriate. Thanks, John ps: I also noted that SA_RESTART is not documented in the man page with the other mask bits, but instead is mentioned in a follow-on statement. Just slightly misleading. -------------------------------------------------------------------------- #include #include #include void fphand(int sig, int code, struct sigcontext *scp) { fprintf(stderr,"sig == %d\n",sig); fprintf(stderr,"code== %d\n",code); return; } void setup() { int rc; struct sigaction act, oact; act.sa_handler = &fphand; act.sa_mask = 0; act.sa_flags = SA_RESTART; /* not doc'd in man page */ rc = sigaction(SIGFPE, &act, &oact); if (rc) { perror("sigaction"); exit(1); } return; } double doit(double x, double y) { return(x / y); } int main() { double x,y,z; fp_except_t mask = FP_X_DZ; setup(); fpsetmask(mask); x = 1.0; y = 0.0; z = doit(x,y); printf("z has the value %f\n",z); return((int) z); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 21:30:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 27FF214FAA for ; Thu, 8 Jul 1999 21:30:35 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id VAA11913; Thu, 8 Jul 1999 21:29:58 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id VAA24362; Thu, 8 Jul 1999 21:29:58 -0700 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA06979; Thu, 8 Jul 99 21:29:48 PDT Message-Id: <37857ABB.F18C896@softweyr.com> Date: Thu, 08 Jul 1999 22:29:47 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Tony Finch Cc: hackers@freebsd.org Subject: Re: Berkeley DB question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > > User Joe wrote: > > > >Is the berkeley db (or any other small db) multi user safe? Are there > >locks to maintain coherency of multiple processes access the same database files? > > The web pages for Berkeley DB 2 claim that it does (note version 2, > not 1.85 as shipped with FreeBSD). http://www.sleepycat.com/. Also note the non-Berkeley license, if you're planning a contribution to FreeBSD. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 8 23:32: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (Postfix) with ESMTP id B703D14E59 for ; Thu, 8 Jul 1999 23:31:58 -0700 (PDT) (envelope-from klein@KryptoKom.DE) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id KAA27313 for ; Fri, 9 Jul 1999 10:29:34 +0200 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa27311; Fri Jul 09 10:29:28 1999 Received: from borg.kryptokom.de (borg.Kryptokom.DE [192.168.6.132]) by Cirdan.KryptoKom.DE (8.8.8/8.8.8) with ESMTP id IAA20352 for ; Fri, 9 Jul 1999 08:40:02 +0200 Received: from kryptokom.de (localhost [127.0.0.1]) by borg.kryptokom.de (8.8.8/8.8.8) with ESMTP id IAA04619 for ; Fri, 9 Jul 1999 08:54:10 +0200 (CEST) (envelope-from klein@kryptokom.de) Message-ID: <37859C90.322349BD@kryptokom.de> Date: Fri, 09 Jul 1999 08:54:08 +0200 From: Thomas Klein X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-19980804-SNAP i386) X-Accept-Language: de, en MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: question: delay of a context - switch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Dose anyone know how long a the kernel is busy with context switching (beetween two processes) ? Has anyone tested this yet? I estimate of about 7 usec duration for that, (on a Pentium 400) but I think that's to long. Regards Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 8 23:36:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hydrogen.fircrest.net (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 3AB091519C for ; Thu, 8 Jul 1999 23:36:05 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.fircrest.net (8.9.1/8.8.7) id XAA08360; Thu, 8 Jul 1999 23:35:51 -0700 (PDT) Message-ID: <19990708233550.16994@hydrogen.fircrest.net> Date: Thu, 8 Jul 1999 23:35:50 -0700 From: John-Mark Gurney To: Adrian Filipi-Martin Cc: hackers@FreeBSD.ORG Subject: Re: Lizard... References: <14205.24876.313315.658481@avalon.east> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Adrian Filipi-Martin on Sun, Jul 04, 1999 at 08:16:01PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adrian Filipi-Martin scribbled this message on Jul 4: > On Fri, 2 Jul 1999, Anthony Kimball wrote: > > > > > Lizard has a tetris game built in for those long waits... > > Now THAT is cool. > > Using the "holistic emergency shell" on vty4 when doing a network > install is more fun. At the very least it has been useful during > evangelical installations. yeh, the only problem is how long it takes before /usr/libexec/ld-elf.so.1 which is needed for all the really good apps to run... :( -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 0:28:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2FCF214D18 for ; Fri, 9 Jul 1999 00:28:27 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id QAA24679; Fri, 9 Jul 1999 16:28:18 +0900 (JST) Message-ID: <37859151.349BF7DA@newsguy.com> Date: Fri, 09 Jul 1999 15:06:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Kelly Yancey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: new loader question / module question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, ok, this message is a few months old, but better late than never, right? (<-- retorical question, no need to actually answer... ;) Kelly Yancey wrote: > > I was working on a module and need to be able to pass parameters to the > module (preferably without having to compile them in). I noticed that the > splash module does this (sort of) by having you load the image to display > and specifying a "tag" for it so that the module can scan for the tag and > find the image. I need to be able to pass more than a single configuration > option though. I am considering putting all of the configuration options > into a single config file, having that loaded into memory by the boot > loader (much the way the splash module loads it's image) and then when the > module loads it can scan memory for the configuration information and > parse it. Is there a better way? It might not be better, but it's an alternative way. Loader saves any arguments passed to a module at load time under the tag MODINFO_ARGS, which can be retrieved (I suppose -- if the kernel does not junk it somewhere) with preload_search_info(). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 1: 8: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 2D3E214C19 for ; Fri, 9 Jul 1999 01:07:54 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA01325; Fri, 9 Jul 1999 11:03:00 +0300 (EEST) (envelope-from will) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: hackers@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) References: <199907081527.BAA04078@godzilla.zeta.org.au> <2663.931447908@critter.freebsd.dk> From: Ville-Pertti Keinonen Date: 09 Jul 1999 11:03:00 +0300 In-Reply-To: phk@critter.freebsd.dk's message of "8 Jul 1999 18:35:19 +0300" Message-ID: <86k8sajlmz.fsf@not.demophon.com> Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG phk@critter.freebsd.dk (Poul-Henning Kamp) writes: > Somebody should study the abilities of the on-cpu APIC for this > for pentium ff. machines. The local APIC would work very nicely, but I'm not sure that you can enable it reliably in a non-SMP configuration. AFAIK most BIOSes don't provide an MP config at all unless you have multiple CPUs present. If you don't have an MP config, you can't set up the redirection tables. And if you have a non-SMP chipset, you can't route interrupts at all, since you won't have an APIC bus on your motherboard or an I/O APIC for the real interrupts. It's been a while since I looked at the documentation, but it *might* be possible that the local APIC timers would work without using APIC interrupt routing. IIRC the timers are simply programmed with the IDT vector number to generate as an interrupt. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 1:12:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6E8C514C19 for ; Fri, 9 Jul 1999 01:12:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id KAA02233; Fri, 9 Jul 1999 10:10:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ville-Pertti Keinonen Cc: hackers@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) In-reply-to: Your message of "09 Jul 1999 11:03:00 +0300." <86k8sajlmz.fsf@not.demophon.com> Date: Fri, 09 Jul 1999 10:10:37 +0200 Message-ID: <2231.931507837@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But shouldn't you still be able to use the timer in the local apic ? In message <86k8sajlmz.fsf@not.demophon.com>, Ville-Pertti Keinonen writes: > >phk@critter.freebsd.dk (Poul-Henning Kamp) writes: > >> Somebody should study the abilities of the on-cpu APIC for this >> for pentium ff. machines. > >The local APIC would work very nicely, but I'm not sure that you can >enable it reliably in a non-SMP configuration. AFAIK most BIOSes >don't provide an MP config at all unless you have multiple CPUs >present. If you don't have an MP config, you can't set up the >redirection tables. > >And if you have a non-SMP chipset, you can't route interrupts at all, >since you won't have an APIC bus on your motherboard or an I/O APIC >for the real interrupts. > >It's been a while since I looked at the documentation, but it *might* >be possible that the local APIC timers would work without using APIC >interrupt routing. IIRC the timers are simply programmed with the IDT >vector number to generate as an interrupt. > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 1:29:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 4F5FA14DD6 for ; Fri, 9 Jul 1999 01:29:19 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA01377; Fri, 9 Jul 1999 11:24:09 +0300 (EEST) (envelope-from will) To: zzhang@cs.binghamton.edu (Zhihui Zhang) Cc: hackers@freebsd.org Subject: Re: Wrong comment in VM code? References: From: Ville-Pertti Keinonen Date: 09 Jul 1999 11:24:09 +0300 In-Reply-To: zzhang@cs.binghamton.edu's message of "9 Jul 1999 04:37:52 +0300" Message-ID: <86iu7ujknq.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG zzhang@cs.binghamton.edu (Zhihui Zhang) writes: > At the beginning of the file vm_object.c, we have the following comment: > > The only items within the object structure which are modified after time > of creation are: > > reference count locked by object's lock > pager routine locked by object's lock > > But at the end of vnode_pager_setsize(), we modify the size field. So at > least three items can be modified after creation. Am I right? The comment is wrong (it's probably supposed to mean something other than it seems to), the only field in a vm_object that *isn't* modified after creation is 'id'. The comment is also wrong in that there are no vm_object locks in FreeBSD (they've been ripped out). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 1:30: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 90F2215545 for ; Fri, 9 Jul 1999 01:29:45 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40359>; Fri, 9 Jul 1999 18:11:48 +1000 Date: Fri, 9 Jul 1999 18:29:33 +1000 From: Peter Jeremy Subject: Re: Clipboard Daemon - thinking of writing one :) To: hackers@FreeBSD.ORG Message-Id: <99Jul9.181148est.40359@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: >> - How can I choose a guaranteed free TCP port? > >www.iana.org >IANA -- Internat Assigned Numbers Authority This is fine in theory, but doesn't work quite as well in practice. I spent several years (unsuccessfully) trying to convince a sister company that allocating TCP ports starting at 6001 for an application was not a good idea (the system _did_ include an X-server, but not multi-headed, luckily). It made using ssh quite a pain at times. Orbix (IONA's CORBA implementation) uses a number of TCP ports - none of which seem to be registered. Closer to home, there's the recent problems with the RADIUS ports. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 1:35:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 3A86915296 for ; Fri, 9 Jul 1999 01:35:46 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA01386; Fri, 9 Jul 1999 11:30:53 +0300 (EEST) (envelope-from will) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: hackers@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) References: <86k8sajlmz.fsf@not.demophon.com> <2231.931507837@critter.freebsd.dk> From: Ville-Pertti Keinonen Date: 09 Jul 1999 11:30:53 +0300 In-Reply-To: phk@critter.freebsd.dk's message of "9 Jul 1999 11:13:07 +0300" Message-ID: <86hfnejkci.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG phk@critter.freebsd.dk (Poul-Henning Kamp) writes: > But shouldn't you still be able to use the timer in the local apic ? Did you read the last paragraph in my message? Here it is again: > >It's been a while since I looked at the documentation, but it *might* > >be possible that the local APIC timers would work without using APIC > >interrupt routing. IIRC the timers are simply programmed with the IDT > >vector number to generate as an interrupt. I haven't tried it, I don't know what would happen. If someone else knows (or has a chance to try it soon), please comment. Even if it works, using the feature would probably have to rely on undocumented behavior. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 2: 1:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 321B91552A for ; Fri, 9 Jul 1999 02:01:35 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id KAA89425; Fri, 9 Jul 1999 10:01:16 +0100 (BST) (envelope-from joe) Date: Fri, 9 Jul 1999 10:01:16 +0100 From: Josef Karthauser To: Kazukiyo UEDA Cc: hackers@FreeBSD.ORG, niall@pobox.com Subject: re: HELP!! Slice info disappeared Message-ID: <19990709100116.G50525@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Kazukiyo, This is certainly possible. I've enclosed a hack from Niall Smart that should generated enough information to for you to reconstruct it. I'm working on a general solution to this for inclusion FreeBSD as shipped, but it's at home and I'm at work, that said it's Niall's basic code saved my harddisk a few weeks ago :) Joe ----- Forwarded message from Niall Smart ----- Date: Mon, 21 Jun 1999 13:48:45 +0000 From: Niall Smart Organization: Trinity Commerce X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en To: Josef Karthauser CC: hackers@freebsd.org Subject: Re: [DISKLABEL FRAGGED] Clues requested... ;) Josef Karthauser wrote: > > Guess what... I've got a disk where the partition table and the disklabel has > mysteriously disappeared! Oops. > > I've reconstructed the partition table, and now need to partition the disklabel. Wow, you're probably the first person ever to do that, unlucky you. Out of sympathy I've written you this findsb program which of course I've never had to use myself. Its not the most efficiently written program ever and since FreeBSD swap partitions don't have magic numbers it may be slow, but it seems to work, however I draw your attention to the disclaimer in the C file. ;) Regards, Niall niall% disklabel wd0s2 | sed -n '/fstype/,$p' # size offset fstype [fsize bsize bps/cpg] a: 131072 0 4.2BSD 0 0 0 # (Cyl. 0 - 8*) b: 262144 131072 swap # (Cyl. 8*- 24*) c: 4192965 0 unused 0 0 # (Cyl. 0 - 260) e: 819200 393216 4.2BSD 0 0 0 # (Cyl. 24*- 75*) f: 2980549 1212416 4.2BSD 0 0 0 # (Cyl. 75*- 260*) niall% ./findsb /dev/wd0s2 0 found superblock: offset=16384, fs_size=65536, fs_fsmnt=/ suggested disklabel entry: size offset fstype 131072 0 4.2BSD found superblock: offset=24576, fs_size=65536, fs_fsmnt= suggested disklabel entry: size offset fstype 131072 16 4.2BSD ^C niall% ./findsb /dev/wd0s2 $[393216 * 512 - 8192 * 10] skipping 201244672 bytes found superblock: offset=201342976, fs_size=409600, fs_fsmnt=/home suggested disklabel entry: size offset fstype 819200 393216 4.2BSD found superblock: offset=201351168, fs_size=409600, fs_fsmnt= suggested disklabel entry: size offset fstype 819200 393232 4.2BSD ^C PROG = findsb CFLAGS = -aout -static -W -Wall -Wmissing-prototypes -Wstrict-prototypes MAN1 = .include /* * Copyright (c) 1999 Niall Smart. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by Niall Smart, niall@pobox.com. * * THIS SOFTWARE IS PROVIDED BY NIALL SMART ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL NIALL SMART BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include #include #include #include #include #include #include #include #include int main(int argc, char** argv) { int fd; int ret; off_t offset; u_quad_t skip; char* ptr; char buf[SBSIZE]; struct fs* fs = (struct fs*)buf; if (argc != 3) { fprintf(stderr, "usage: %s device skip\n", argv[0]); exit(1); } if ( (fd = open(argv[1], O_RDONLY)) < 0) { perror("open"); exit(1); } if ( (skip = strtouq(argv[2], &ptr, 0)) == QUAD_MAX || *ptr != '\0') { fprintf(stderr, "bad seek value: %s\n", argv[2]); exit(1); } if ( (skip % SBOFF) != 0) fprintf(stderr, "warning: %qu is not a multiple of SBOFF (%d)\n", skip, (int)SBOFF);; if (skip > 0) { fprintf(stderr, "skipping %qu bytes\n", skip); lseek(fd, skip, SEEK_SET); } while (1) { ret = read(fd, buf, sizeof(buf)); if (ret < 0) { perror("read"); exit(1); } /* * based on checks in /sys/ufs/ffs/ffs_vfsops.c, line 478 */ if (fs->fs_magic == FS_MAGIC && fs->fs_bsize <= MAXBSIZE && fs->fs_bsize >= (int32_t)sizeof(struct fs)) { offset = lseek(fd, 0, SEEK_CUR); printf("found superblock: offset=%qd, fs_size=%d, fs_fsmnt=%.*s\n", offset, fs->fs_size, MAXMNTLEN, fs->fs_fsmnt); printf("suggested disklabel entry:\n\n"); printf(" size offset fstype\n"); printf("%8d %8qd 4.2BSD\n\n", fs->fs_size * 2, (offset - 16384) / 512); } } printf("%d:%d\n", sizeof(struct fs), offsetof(struct fs, fs_magic)); return 0; } ----- End forwarded message ----- -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 2:39:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 5221E14DC0 for ; Fri, 9 Jul 1999 02:39:53 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 112X86-000N0C-00; Fri, 09 Jul 1999 11:39:38 +0200 From: Sheldon Hearn To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. In-reply-to: Your message of "Thu, 08 Jul 1999 20:59:58 +0100." <19990708205958.A91668@catkin.nothing-going-on.org> Date: Fri, 09 Jul 1999 11:39:38 +0200 Message-ID: <88423.931513178@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: > With that in mind, how about this patch (in conjunction with the patch to > login.conf in the original PR, which just updates a comment)? This looks much better. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 4:34:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 96293154DF; Fri, 9 Jul 1999 04:34:48 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA14655; Fri, 9 Jul 1999 21:34:38 +1000 Date: Fri, 9 Jul 1999 21:34:38 +1000 From: Bruce Evans Message-Id: <199907091134.VAA14655@godzilla.zeta.org.au> To: dfr@nlsystems.com, julian@whistle.com Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, tanimura@naklab.dnj.ynu.ac.jp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >this is problematic. > >you cannot add a new element before the pending firing because you can't >tell how far into the present trigger you are. This is not a problem for readable counters like the i8254. The problem for the i8254 is that reading and writing it takes a long time (perhaps 5 usec each). Every write to it will decrease its accuracy (perhaps by 1 usec after careful calibration). Thus if the i8254 is used for generating non-periodic interrupts with an average period of 333 usec, it may take 15/333 of the CPU (estimate another 5 usec for interrupt handling), and if it is also used for timecounting then it may drift by 333 usec/second. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 5:14:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 753C814E23 for ; Fri, 9 Jul 1999 05:14:43 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id IAA20592; Fri, 9 Jul 1999 08:14:40 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id IAA18041; Fri, 9 Jul 1999 08:14:38 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id IAA75654; Fri, 9 Jul 1999 08:14:38 -0400 (EDT) Date: Fri, 9 Jul 1999 08:14:38 -0400 (EDT) From: Thomas David Rivers Message-Id: <199907091214.IAA75654@lakes.dignus.com> To: freebsd-hackers@FreeBSD.ORG, jwd@unx.sas.com Subject: Re: sigaction inconsistancy (here I go again) In-Reply-To: <199907090406.AAA10435@bb01f39.unx.sas.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Also, I haven't gone into the code yet, but the floating point > registers are not saved into the sigcontext so that they can be > inspected and modified as appropriate. > > Thanks, > John If I recall correctly - I think there's a discussion of why this is the case in the -hackers mail archive. - 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 9 6:52:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id A5880155BB; Fri, 9 Jul 1999 06:52:38 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id JAA17580; Fri, 9 Jul 1999 09:52:38 -0400 (EDT) (envelope-from jay@oneway.com) Date: Fri, 9 Jul 1999 09:52:38 -0400 (EDT) From: Jay Kuri To: hackers@freebsd.org, questions@freebsd.org Subject: 10/100 highly reliable supported ethernet cards? 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 Hello, Recently, I've had some problems with the new 10/100 Management adapters from intel (they don't seem to work properly in my hardware) Can anyone recommend some good stable 10/100 PCI NIC? I've used the Dec-Ethernet chipset 2x44x but only on on-board ethernet... can anyone direct me to some PCI cards using this chipset? Thanks in advance, Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 9:19:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home2.ecore.net (home2.ecore.net [212.63.128.224]) by hub.freebsd.org (Postfix) with ESMTP id B96AF14E1C for ; Fri, 9 Jul 1999 09:19:16 -0700 (PDT) (envelope-from sold@cheasy.de) Received: from kiste.cheasy.de [212.63.145.88] by home2.ecore.net with ESMTP (SMTPD32-5.04) id A1034E0A0514; Fri, 09 Jul 1999 18:19:15 +0200 Received: (from sold@localhost) by kiste.cheasy.de (8.9.2/8.9.2) id SAA02091; Fri, 9 Jul 1999 18:18:25 +0200 (CEST) (envelope-from sold) From: Christoph Sold Date: Fri, 9 Jul 1999 18:18:25 +0200 (CEST) To: hackers@FreeBSD.ORG Reply-To: darwin@cheasy.de Subject: Anybody porting =?ISO-8859-1?Q?Apple=B4s?= Darwin Streaming Server back to FreeBSD? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14214.8171.832724.864993@kiste.cheasy.de> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Folks, the subject says it all: does anybody work on porting Apple=B4s Darwin Streaming Server to FreeBSD? I do not want to duplicate the process... Thanks -Christoph Sold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 9:36: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id C8E7914FC4; Fri, 9 Jul 1999 09:35:59 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id JAA17121; Fri, 9 Jul 1999 09:35:25 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA27858; Fri, 9 Jul 1999 09:35:25 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA10901; Fri, 9 Jul 99 09:35:22 PDT Message-Id: <378624CB.D3396516@softweyr.com> Date: Fri, 09 Jul 1999 10:35:23 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Jay Kuri Cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: 10/100 highly reliable supported ethernet cards? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jay Kuri wrote: > > Hello, > > Recently, I've had some problems with the new 10/100 Management > adapters from intel (they don't seem to work properly in my hardware) > > Can anyone recommend some good stable 10/100 PCI NIC? I've used > the Dec-Ethernet chipset 2x44x but only on on-board ethernet... can anyone > direct me to some PCI cards using this chipset? We have a bunch of the Linksys EtherFast cards around here. They use the PNIC, which is a follow-on to (or clone of) the 21140 series, and Bill Paul's driver seems to perform quite well. The EtherExpress Pro is probably the most respected card around these days. Perhaps working with DG to identify and solve your problems might be the best tack? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 9 10:17:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 671E314E1C for ; Fri, 9 Jul 1999 10:17:52 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id KAA17917; Fri, 9 Jul 1999 10:17:00 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA29491; Fri, 9 Jul 1999 10:17:01 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA13096; Fri, 9 Jul 99 10:16:57 PDT Message-Id: <37862E8B.6C21684D@softweyr.com> Date: Fri, 09 Jul 1999 11:16:59 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Mark Newton Cc: hackers@FreeBSD.ORG Subject: Re: matcd on an SB16 References: <199907090328.MAA08098@gizmo.internode.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Newton wrote: > > One of them has an SB16 with a CD-ROM drive. His attempts at installing > FreeBSD from that CD-ROM have met with abysmal failure: > > $ Next came an install on my Pentium 60 (previously running Caldera-2.2) > $ - A total disaster.... no way despite 12 attempts to install, could I > $ get FreeBSD to actually initialise the sbpcd (freebsd calls it matcdc) > $ despite changing IO's, entering the manual configuration option etc > $ etc... it would not & could not, find the cdrom & so I had to abort the > $ install every time!! > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > have any estimate of the amount of effort that'd be required to fix it? Sorry, I have no help to offer, but I vaguely remember writing something recently about support of bizarre hardware devices in Linux vs. FreeBSD. An IDE CD-ROM is completely beyond his reach? Send me his address, I'll go buy one of the cheapo USDrive 24x models they're selling around here for $24 and mail it to him. It will, of course, cost him AU$40 to receive it. ;^( -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 9 11:53:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from daedal.oneway.com (daedal.oneway.com [205.252.89.49]) by hub.freebsd.org (Postfix) with ESMTP id D114815626; Fri, 9 Jul 1999 11:53:54 -0700 (PDT) (envelope-from jay@oneway.com) Received: from localhost (jay@localhost) by daedal.oneway.com (8.9.1/8.9.1) with ESMTP id OAA20003; Fri, 9 Jul 1999 14:53:46 -0400 (EDT) (envelope-from jay@oneway.com) Date: Fri, 9 Jul 1999 14:53:46 -0400 (EDT) From: Jay Kuri To: Wes Peters Cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: 10/100 highly reliable supported ethernet cards? In-Reply-To: <378624CB.D3396516@softweyr.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 > We have a bunch of the Linksys EtherFast cards around here. They use > the PNIC, which is a follow-on to (or clone of) the 21140 series, and > Bill Paul's driver seems to perform quite well. Thanks, I'll look into that. > The EtherExpress Pro is probably the most respected card around these > days. Perhaps working with DG to identify and solve your problems might > be the best tack? That's a good Idea. Right now I'm talking with Intel. Apparantly this is a problem that is occurring on other OS's, and probably has little to do with the freebsd driver. They have asked me to loan them some machines that are having this problem so that they can investigate it. I will probably do so in the next few days. Perhaps they can either find out what is wrong with the cards and fix it for future revisions, or tell us what we need to do to get around the problem in software. *crossing fingers* Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 12: 0:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 5765415626 for ; Fri, 9 Jul 1999 12:00:28 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA11165; Fri, 9 Jul 1999 20:50:01 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00896; Fri, 9 Jul 1999 19:30:25 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907091730.TAA00896@yedi.iaf.nl> Subject: Re: Lizard... In-Reply-To: <19990708233550.16994@hydrogen.fircrest.net> from John-Mark Gurney at "Jul 8, 1999 11:35:50 pm" To: gurney_j@resnet.uoregon.edu Date: Fri, 9 Jul 1999 19:30:25 +0200 (CEST) Cc: adrian@ubergeeks.com, hackers@FreeBSD.ORG 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+ 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 As John-Mark Gurney wrote ... > Adrian Filipi-Martin scribbled this message on Jul 4: > > On Fri, 2 Jul 1999, Anthony Kimball wrote: > > > > > > > > Lizard has a tetris game built in for those long waits... > > > Now THAT is cool. > > > > Using the "holistic emergency shell" on vty4 when doing a network holographic... -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl 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 Fri Jul 9 12: 0:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 3BF00156AD for ; Fri, 9 Jul 1999 12:00:54 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA07047 for ; Fri, 9 Jul 1999 12:00:52 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 9 Jul 1999 12:00:52 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: freebsd-hackers@freebsd.org Subject: more amd hangs 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 my continuing efforts to get this freebsd box into shape for web hosting at my company (where it relies exclusively on NFS for retrieving customer data) I've been making progress thanks to some recent commits by Peter. Now I can run the heavy duty NFS access script and it completes its mission about 2 out of 3 times. Also, now when it fails it doesn't lock the whole box, just amd. Still not where I want it to be, but it is definitely big progress. :) What happens when it hangs is that amd becomes totally wedged. I cannot do 'df' or 'ls /' at all (the amd mountpoints are on /), and killing the amd process is no help; I have to reboot the box. Ktrace'ing amd at this point gets me nothing. The ktrace process just dies and leaves a 0 byte ktrace.out file. (BTW, I am also still having problems with ktrace exiting while the process is still running when I actually get it to attach, if anyone cares.) The one thing that I was able to do recently was to get amq to dump a core file. I tried running amq while the amd process was wedged and when it didn't return I killed it with a ^\ command. The trace was kind of interesting: Core was generated by `amq'. Program terminated with signal 3, Quit. Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. #0 0x28098f3c in select () from /usr/lib/libc.so.3 (gdb) where #0 0x28098f3c in select () from /usr/lib/libc.so.3 #1 0x280afd33 in clnttcp_create () from /usr/lib/libc.so.3 #2 0x280b4eb0 in xdrrec_endofrecord () from /usr/lib/libc.so.3 #3 0x280b4efc in xdrrec_endofrecord () from /usr/lib/libc.so.3 #4 0x280b4f63 in xdrrec_endofrecord () from /usr/lib/libc.so.3 #5 0x280b4a91 in xdrrec_create () from /usr/lib/libc.so.3 #6 0x280b49d7 in xdrrec_create () from /usr/lib/libc.so.3 #7 0x280b8b6c in xdr_u_int32_t () from /usr/lib/libc.so.3 #8 0x280b539b in xdr_replymsg () from /usr/lib/libc.so.3 #9 0x280af90e in clnttcp_create () from /usr/lib/libc.so.3 #10 0x804a189 in xdr_u_short () #11 0x8049aba in xdr_u_short () #12 0x8049209 in xdr_u_short () I'm not sure exactly what that means, but I still have the core file so if anyone wants to look into this I'll be glad to do what I can. The amd conf files are below, any insights or suggestions welcome. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers amd.conf: [ global ] # Only search for maps of this type map_type = file # Search this path for maps search_path = /etc # Use this directory for amd's private mount points auto_dir = /usr/amdmount # How long the mounts should live, in seconds #cache_duration = 1800 # Log all activity to syslog (daemon) log_file = syslog:local7 log_options = all # Check /etc/hosts for hostnames normalize_hostnames = yes # Lock the amd process into memory, improves perf. plock = yes # Use the special /default entry in maps selectors_on_default = yes # DEFINE AN AMD MOUNT POINT [ /Interfaces ] map_name = amd.Interfaces [ /Hold ] map_name = amd.Hold amd.Interfaces: /defaults type:=nfs;opts:=rw,vers=2,intr,proto=udp,noconn * rhost:=IP${key};rfs:=/Space/${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 9 12:10:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.go2france.com (go2france.com [209.51.193.70]) by hub.freebsd.org (Postfix) with SMTP id 7A13A156BD for ; Fri, 9 Jul 1999 12:10:28 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from superviseur [62.161.63.210] by mail.go2france.com with ESMTP (SMTPD32-4.03) id A4C66F01B2; Fri, 09 Jul 1999 13:43:34 EDT Message-Id: <4.2.0.56.19990709210857.02250b30@go2france.com> X-Sender: lconrad@go2france.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Fri, 09 Jul 1999 21:10:17 +0200 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Ariel RS2000 card Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this card a candidate for support in fbsd? There is support for Linux. www.ariel.com Len To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 13:11:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from console.prisa.com (gatekeeper.prisa.com [204.94.67.66]) by hub.freebsd.org (Postfix) with SMTP id 1754114CEB for ; Fri, 9 Jul 1999 13:11:09 -0700 (PDT) (envelope-from nschein@prisa.com) Received: from nschein ([172.16.129.137]) by console.prisa.com (8.6.12/8.6.12) with SMTP id NAA20045 for ; Fri, 9 Jul 1999 13:12:47 -0700 From: "Nathaniel Schein" To: Subject: FW: NIS, + in the passwd file Date: Fri, 9 Jul 1999 13:15:37 -0700 Message-ID: <001301beca47$cf2304a0$898110ac@nschein.prisa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----Original Message----- From: Nathaniel Schein [mailto:nschein@prisa.com] Sent: Friday, July 09, 1999 12:54 PM To: Owner-Freebsd-Questions Subject: FW: NIS, + in the passwd file -----Original Message----- From: Nathaniel Schein [mailto:nschein@prisa.com] Sent: Friday, July 09, 1999 12:49 PM To: Owner-Freebsd-Questions Subject: NIS, + in the passwd file I am trying to set up NIS with FreeBSD. On bootup ypbind has no problem and if I do a `ypwhich` it will show the NIS master. Moreover, when I do a `ypcat passwd` the passwd list is displayed. When I try to use `vipw` to place a '+' at the end of the passwd file, the consistancy checks do not allow me. Must I edit the passwd file directly and use `pwd_mkdb` to resolve this problem, or is there another solution? Also, when I do a `ypwhich -x` not all the maps held by the NIS master are shown. Does somebody know why? By the way the NIS master running FreeBSD 2.11 and the client is running v.3.2. The master is correctly configured and integrated with an IRIX network. Nathaniel Schein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 14:27:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id D089B14E2C; Fri, 9 Jul 1999 14:27:16 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA08697; Fri, 9 Jul 1999 14:26:52 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 9 Jul 1999 14:26:52 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Warner Losh Cc: mjacob@feral.com, Peter Wemm , Matt Jacob , hackers@FreeBSD.ORG Subject: FreeBSD for mips In-Reply-To: <199907091945.NAA21253@harmony.village.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 Fri, 9 Jul 1999, Warner Losh wrote: > In message Matthew Jacob writes: > : I don't know- it's very platform specific. I just wanted my kernels to > : compile again. I think it's probably appropriate to not conditionalize the > : procfs code because that information probably there, in a platform > : specific manner, for many platforms. > > I believe that I recall seeing similar functionality in at least one > of the MIPS processor handbooks that has crossed my desk in the last > few years. I'd just like to offer a hearty hi-ho for a MIPS version of freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we have round here to a wholesome purpose. :) Of course doing the install would be a lot of fun with no floppy disk.... Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 14:36:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id A5BF614CB0; Fri, 9 Jul 1999 14:36:25 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id WAA80418; Fri, 9 Jul 1999 22:36:19 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 9 Jul 1999 22:36:19 +0100 (BST) From: Doug Rabson To: Doug Cc: Warner Losh , mjacob@feral.com, Peter Wemm , Matt Jacob , hackers@freebsd.org Subject: Re: FreeBSD for mips 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 Fri, 9 Jul 1999, Doug wrote: > On Fri, 9 Jul 1999, Warner Losh wrote: > > > In message Matthew Jacob writes: > > : I don't know- it's very platform specific. I just wanted my kernels to > > : compile again. I think it's probably appropriate to not conditionalize the > > : procfs code because that information probably there, in a platform > > : specific manner, for many platforms. > > > > I believe that I recall seeing similar functionality in at least one > > of the MIPS processor handbooks that has crossed my desk in the last > > few years. > > I'd just like to offer a hearty hi-ho for a MIPS version of > freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we > have round here to a wholesome purpose. :) Of course doing the install > would be a lot of fun with no floppy disk.... Do they netboot? Netbooting sysinstall would be a good way to install things like this. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 14:41: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 9A3F814CB0 for ; Fri, 9 Jul 1999 14:41:04 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA21925; Fri, 9 Jul 1999 14:40:31 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA08854; Fri, 9 Jul 1999 14:40:31 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA27000; Fri, 9 Jul 99 14:40:30 PDT Message-Id: <37866C4E.A4D873E0@softweyr.com> Date: Fri, 09 Jul 1999 15:40:30 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Nathaniel Schein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FW: NIS, + in the passwd file References: <001301beca47$cf2304a0$898110ac@nschein.prisa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nathaniel Schein wrote: > > I am trying to set up NIS with FreeBSD. On bootup ypbind has no problem and > if I do a `ypwhich` it will show the NIS master. Moreover, when I do a > `ypcat passwd` the passwd list is displayed. When I try to use `vipw` to > place a '+' at the end of the passwd file, the consistancy checks do not > allow me. Must I edit the passwd file directly and use `pwd_mkdb` to resolve > this problem, or is there another solution? Edit the passwd database with vipw. Append the following line to the end: +::::::::: That's 9 colons there, anything else will not do. > Also, when I do a `ypwhich -x` not all the maps held by the NIS master are > shown. Does somebody know why? By the way the NIS master running FreeBSD > 2.11 and the client is running v.3.2. The master is correctly configured and > integrated with an IRIX network. FreeBSD 2.11? Never heard of such a beast. Do you mean 2.1.1? Ugh! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 9 15:26:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id ED2F014C9E for ; Fri, 9 Jul 1999 15:26:06 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA24246 for freebsd-hackers@FreeBSD.ORG; Sat, 10 Jul 1999 00:26:03 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 858D3885F; Fri, 9 Jul 1999 23:59:37 +0200 (CEST) (envelope-from roberto) Date: Fri, 9 Jul 1999 23:59:37 +0200 From: Ollivier Robert To: "FreeBSD Hackers' list" Subject: Re: Sony Z505S [was: USB floppy & booting] Message-ID: <19990709235937.B8602@keltia.freenix.fr> Mail-Followup-To: FreeBSD Hackers' list References: <19990703174459.A57506@keltia.freenix.fr> <85vhbwq8o0.fsf@stiegl.niksun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <85vhbwq8o0.fsf@stiegl.niksun.com>; from Andrew Heybey on Wed, Jul 07, 1999 at 08:36:47PM -0400 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5443 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Andrew Heybey: > I also have my eye on one of these (or possibly the Z505SX: P-II/366 + > 128M). Anyone know what kind of ethernet card is built in? What Someone -- I don't remember where -- mentionned it was an Intel InterExpress (fxp driver) so we know it will work. > about the modem? These are new enough that a web search did not The modem, provided they didn't changed it, is a regular V.90 modem, not a Winmodem... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 15:36:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 7395C14C9E for ; Fri, 9 Jul 1999 15:36:29 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA07224 for hackers@freebsd.org; Fri, 9 Jul 1999 18:38:44 -0400 From: Bill Paul Message-Id: <199907092238.SAA07224@skynet.ctr.columbia.edu> Subject: PCCARD and Vpp voltage To: hackers@freebsd.org Date: Fri, 9 Jul 1999 18:38:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2908 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today I started experimenting with the Aironet 4800 series 11Mbps wireless networking cards. Aironet makes PCMCIA, ISA and PCI adapters. I happen to have the PCMCIA and ISA ones. Like the Lucent WaveLAN/IEEE cards, the ISA and PCI cards are really PCMCIA cards fitted into a bridge adapter. Unlike the WaveLAN/IEEE cards, the bridge adapters look like real ISA or PCI devices to the host, so you don't need PCCARD support to use them. (The Lucent WaveLAN/IEEE ISA card requires PCCARD support in order to work.) Anyway, that's not why I'm here. My problem is the PCMCIA adapter. I'm testing it on a Dell Latitude Cpi D300XT, which has both LoseNT 4.0 and FreeBSD 3.2 installed. I decided to install the PCMCIA card in the laptop using the LoseNT drivers so that I could have a known working machine with which to generate traffic so that I could properly test the ISA card. However much to my surprise (well, not really), LoseNT failed to detect the card. The 'PC Card (PCMCIA)' icon in the control shows the PCMCIA modem in slot 1, but shows slot 0 as empty. Naturally, the drivers from Aironet fail to attach the card. So I decided to boot FreeBSD instead. Unfortunately, it didn't detect the card either. After reading the Aironet manual (which I don't really have -- shhhh), I found in the section on starting the card that you have to "Enable power (VCC) to the socket and also set VPP1, VPP2 = 5V." Looking in /sys/pccard/pccard.c:insert(), I found the following code: /* * Enable 5V to the card so that the CIS can be read. */ slt->pwr.vcc = 50; slt->pwr.vpp = 0; So, I changed this to slt->pwr.vcc = 50; slt->pwr.vpp = 50; And now pccardc dumpcis shows all of the proper CIS information, pccardd finds the card and life is good. (Frankly, I was stunned that I figured this out; I'm not really that bright, you know.) Apparently, the Aironet card wants VPP turned on before it will let you read the CIS table. So, here are my questions: - Why is the vpp voltage alwats left at 0? - Is it safe for me to change the code so that it's set to 5 volts? Obviously I'm going to need this change in order to make the Aironet PCMCIA cards work. - If it's not safe to default vpp to 5 volts, is there a safe way to detect when it needs to be turned on and do it only for those cards that need it? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 15:45:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id 1408A14E10 for ; Fri, 9 Jul 1999 15:45:44 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 11346 invoked by uid 1001); 9 Jul 1999 23:00:48 -0000 Date: Fri, 9 Jul 1999 19:00:48 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: FreeBSD Hackers List Subject: Adding a PCMCIA modem to pccard.conf (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 posted this to fbsd questions but got no response and was hoping someone here could help me. Thanks in advance, Wayne ---------- Forwarded message ---------- Date: Wed, 7 Jul 1999 13:41:20 -0400 (EDT) From: Wayne Cuddy To: FreeBSD Questions Subject: Adding a PCMCIA modem to pccard.conf I have a Lucent Venus 56k pcmcia modem. I have been attempting to get it working under FreeBSD 3.1R. I have added an entry to /etc/pccard.conf and found the correct "config index" (i think) using "pccardc dumpcis". After resolving all the resource allocation errors I believe i was able to get the driver allocated. When pccardd is started I now see this error message. sio1: type 16450? with a bogus IIR_TXRDY register I can then do a stty -f /dev/cuaa1 and I can see some basic settings. However, when I try to use the modem the computer locks up. This modem works great under linux but I would rather use FreeBSD on my laptop... Can anyone help me resolve this problem. Is there some support needed on pccardd that is not there? Thanks, Wayne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 16:22:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 6A91014D9E for ; Fri, 9 Jul 1999 16:22:04 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id E2135F818; Fri, 9 Jul 1999 19:22:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id D40F79B15; Fri, 9 Jul 1999 19:22:02 -0400 (EDT) Date: Fri, 9 Jul 1999 19:22:02 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Wayne Cuddy Cc: FreeBSD Hackers List Subject: Re: Adding a PCMCIA modem to pccard.conf (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 Fri, 9 Jul 1999, Wayne Cuddy wrote: > I have a Lucent Venus 56k pcmcia modem. I have been attempting to get it > working under FreeBSD 3.1R. I have added an entry to /etc/pccard.conf and > found the correct "config index" (i think) using "pccardc dumpcis". After > resolving all the resource allocation errors I believe i was able to get the > driver allocated. > You are welcome to try my config: card "LUCENT-VENUS" "PCMCIA 56K DataFax" config 0x27 "sio2" 10 reset 1000 insert logger -s Lucent-Venus Modem inserted remove logger -s Lucent-Venus Modem removed I found that the 'reset 1000' stopped the system from locking up when you try to access the serial device. Also, change sio2 and irq 10 to whatever your system is configured for. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 16:23:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1AC5B14CF6 for ; Fri, 9 Jul 1999 16:23:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA06043; Fri, 9 Jul 1999 17:23:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA22242; Fri, 9 Jul 1999 17:21:15 -0600 (MDT) Message-Id: <199907092321.RAA22242@harmony.village.org> To: Doug Subject: Re: FreeBSD for mips Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 09 Jul 1999 14:26:52 PDT." References: Date: Fri, 09 Jul 1999 17:21:15 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug writes: : I'd just like to offer a hearty hi-ho for a MIPS version of : freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we : have round here to a wholesome purpose. :) Of course doing the install : would be a lot of fun with no floppy disk.... If nothing else, a program that wrote a custom kernel into / of the current Linux partition might be one way of getting bootstrapped on these machines. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 16:30:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 58DF114EB5 for ; Fri, 9 Jul 1999 16:30:10 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA09268; Fri, 9 Jul 1999 16:30:05 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 9 Jul 1999 16:30:05 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Doug Rabson Cc: hackers@freebsd.org Subject: Re: FreeBSD for mips 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 Fri, 9 Jul 1999, Doug Rabson wrote: > On Fri, 9 Jul 1999, Doug wrote: > > I'd just like to offer a hearty hi-ho for a MIPS version of > > freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we > > have round here to a wholesome purpose. :) Of course doing the install > > would be a lot of fun with no floppy disk.... > > Do they netboot? Netbooting sysinstall would be a good way to install > things like this. Yes, in fact that's how we do all the upgrades/wipes/reinstalls/etc. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 16:58: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 48FE914D72 for ; Fri, 9 Jul 1999 16:57:47 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id AAA80858; Sat, 10 Jul 1999 00:57:56 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 10 Jul 1999 00:57:56 +0100 (BST) From: Doug Rabson To: Doug Cc: hackers@freebsd.org Subject: Re: FreeBSD for mips 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 Fri, 9 Jul 1999, Doug wrote: > On Fri, 9 Jul 1999, Doug Rabson wrote: > > > On Fri, 9 Jul 1999, Doug wrote: > > > > I'd just like to offer a hearty hi-ho for a MIPS version of > > > freebsd. I'd love to be able to put some of these !*#@$* Cobalt Raqs we > > > have round here to a wholesome purpose. :) Of course doing the install > > > would be a lot of fun with no floppy disk.... > > > > Do they netboot? Netbooting sysinstall would be a good way to install > > things like this. > > Yes, in fact that's how we do all the > upgrades/wipes/reinstalls/etc. Well, it seems like you need to talk to Warner Losh and start bootstrapping the kernel... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 18:11:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from isis.aye.net (isis.aye.net [206.185.8.77]) by hub.freebsd.org (Postfix) with ESMTP id 957CD14DD6 for ; Fri, 9 Jul 1999 18:11:48 -0700 (PDT) (envelope-from axis@isis.aye.net) Received: from localhost (axis@localhost) by isis.aye.net (8.9.2/8.9.2) with ESMTP id VAA24833 for ; Fri, 9 Jul 1999 21:13:02 -0400 (EDT) (envelope-from axis@isis.aye.net) Date: Fri, 9 Jul 1999 21:13:02 -0400 (EDT) From: Axis To: hackers@FreeBSD.org Subject: hardware 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 have been using *BSD* for around 3 years now. My problem is thatI have always used the console for system administration duties. I really want to put a kick *** system together to run X with all of the luxuries. I have noticed there is not that much support for sound cards andvideo display adapters. Given your experience, Could you please inform me of which sound card and video display adapter works best with FreeBSD. Thanxs Axis FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity; They are all better than LINUX or (Like Its Not UNIX). :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 18:52: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from phobos.illtel.denver.co.us (dsl-206.169.4.82.wenet.com [206.169.4.82]) by hub.freebsd.org (Postfix) with ESMTP id C58F01510F for ; Fri, 9 Jul 1999 18:52:07 -0700 (PDT) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.9.1a/8.6.9) with SMTP id SAA27439; Fri, 9 Jul 1999 18:52:31 -0700 Date: Fri, 9 Jul 1999 18:52:31 -0700 (PDT) From: Alex Belits To: Axis Cc: hackers@FreeBSD.ORG Subject: Re: hardware 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 Fri, 9 Jul 1999, Axis wrote: > I have been using *BSD* for around 3 years now. My problem is thatI have > always used the console for system administration duties. I really want to > put a kick *** system together to run X with all of the luxuries. > I have noticed there is not that much support for sound cards andvideo > display adapters. > Given your experience, Could you please inform me of which sound card and > video display adapter works best with FreeBSD. This became more complex recently when a lot of new stuff appeared in XFree86, but without that much of kicking ***es, Matrox Millennium G200 AGP and SB AWE64 ("Gold" or "Value") is a cheap and decently supported combination. 3D features of G200 are currently unsupported, but 1. you probably don't need them anyway, 2. it's expected that this will be one of the first 3D-accelerated cards, natively supported with GLX in XFree86. > > FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity; > They are all better than LINUX or (Like Its Not UNIX). :) [flame skipped]. -- Alex ---------------------------------------------------------------------- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 19:10:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from balsam.methow.com (balsam.methow.com [206.107.156.5]) by hub.freebsd.org (Postfix) with SMTP id EBA7E14D72 for ; Fri, 9 Jul 1999 19:10:36 -0700 (PDT) (envelope-from tcole@balsam.methow.com) Received: (qmail 16294 invoked by uid 535); 10 Jul 1999 02:10:35 -0000 Message-ID: <19990709191034.A16191@wcug.wwu.edu> Date: Fri, 9 Jul 1999 19:10:34 -0700 From: Travis Cole To: Axis , hackers@FreeBSD.org Subject: Re: hardware References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: ; from Axis on Fri, Jul 09, 1999 at 09:13:02PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 09, 1999 at 09:13:02PM -0400, Axis wrote: > I have been using *BSD* for around 3 years now. My problem is thatI have > always used the console for system administration duties. I really want to > put a kick *** system together to run X with all of the luxuries. > I have noticed there is not that much support for sound cards andvideo > display adapters. > Given your experience, Could you please inform me of which sound card and > video display adapter works best with FreeBSD. I have a Nvidia RivaTNT that works great in FreeBSD. And with the patches from Nvidia I have hardware accelerated OpenGL working. I say go even better and get a TNT2 for video. Its not supported out of the box yet but its pretty easy to patch the XFree86 sources to make it work and I think XFree86 3.3.4 should have support for it. -- --Travis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 19:19:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 45C2C14D72 for ; Fri, 9 Jul 1999 19:19:13 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 4E94B1F05; Fri, 9 Jul 1999 19:19:13 -0700 (PDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Belits Cc: hackers@FreeBSD.ORG Subject: Re: hardware In-reply-to: Your message of "Fri, 09 Jul 1999 18:52:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 19:19:13 -0700 From: Jake Burkholder Message-Id: <19990710021913.4E94B1F05@io.yi.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Given your experience, Could you please inform me of which sound card and > > video display adapter works best with FreeBSD. There seems to be good support for the Nvidia RivaTNT chipset, and lots of cheap 16 meg cards based on them. If I were to get a new sound card soon, I'd probably get a soundblaster 64 PCI; any PCI card based on the es1370 chipset. (I believe es1371 is also supported.) > 3D features of G200 are currently unsupported, but 1. you probably don't > need them anyway, 2. it's expected that this will be one of the first > 3D-accelerated cards, natively supported with GLX in XFree86. Nvidia cards are already supported. The GL xlock savers look awesome. -- we are but packets in the internet of life To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 9 20:31: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DF43914EAD for ; Fri, 9 Jul 1999 20:31:00 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA86430; Fri, 9 Jul 1999 23:30:46 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 9 Jul 1999 23:30:46 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Axis Cc: hackers@FreeBSD.org Subject: Re: hardware 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 Fri, 9 Jul 1999, Axis wrote: > I have been using *BSD* for around 3 years now. My problem is thatI have > always used the console for system administration duties. I really want to > put a kick *** system together to run X with all of the luxuries. > I have noticed there is not that much support for sound cards andvideo > display adapters. > Given your experience, Could you please inform me of which sound card and > video display adapter works best with FreeBSD. I suggest a nice TNT or TNT2 (Ultra too)-based card for video. They have nice 2D acceleration and okay 3D acceleration. The 3D acceleration is great, but limited by the slow architecture of the current X/GL/GLX implementation. I get very nice, but nowhere near current Windoze-driver-speed, 3D accel using this baby (just don't expect to play much Quake 3 with it in FreeBSD yet.) As for sound cards, I use a SB16. These are very well-supported and run nicely with either sound driver. Mine is an old SB16 4.13 (full-length ISA, software configured (not PnP)), and works perfectly. If you want something newer (more expensive too), other people than I will point you on your way. > > Thanxs > Axis > > FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity; > They are all better than LINUX or (Like Its Not UNIX). :) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 10 0:58: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id F3C3B151C2; Sat, 10 Jul 1999 00:57:53 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA02446; Sat, 10 Jul 1999 08:58:05 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 10 Jul 1999 08:58:05 +0100 (BST) From: Doug Rabson To: "Brian F. Feldman" Cc: Axis , hackers@freebsd.org Subject: Re: hardware 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 Fri, 9 Jul 1999, Brian F. Feldman wrote: > On Fri, 9 Jul 1999, Axis wrote: > > > I have been using *BSD* for around 3 years now. My problem is thatI have > > always used the console for system administration duties. I really want to > > put a kick *** system together to run X with all of the luxuries. > > I have noticed there is not that much support for sound cards andvideo > > display adapters. > > Given your experience, Could you please inform me of which sound card and > > video display adapter works best with FreeBSD. > > I suggest a nice TNT or TNT2 (Ultra too)-based card for video. They have > nice 2D acceleration and okay 3D acceleration. The 3D acceleration is great, > but limited by the slow architecture of the current X/GL/GLX implementation. > I get very nice, but nowhere near current Windoze-driver-speed, 3D accel > using this baby (just don't expect to play much Quake 3 with it in FreeBSD > yet.) The Nvidia binaries for the TNT glx don't work with q3test. If you rebuild them from the current CVS sources with bleeding edge Mesa sources, it works fine but its much slower than voodoo2 due to the limitations of XFree86 3.3. I expect 4.0 to have excellent 3D performance. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 7:23:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 2A23F14E87 for ; Sat, 10 Jul 1999 07:23:21 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id HAA24880; Sat, 10 Jul 1999 07:22:41 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id HAA07857; Sat, 10 Jul 1999 07:22:41 -0700 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA11232; Sat, 10 Jul 99 07:22:38 PDT Message-Id: <3787572D.30D82B56@softweyr.com> Date: Sat, 10 Jul 1999 08:22:37 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Bill Paul Cc: hackers@FreeBSD.ORG Subject: Re: PCCARD and Vpp voltage References: <199907092238.SAA07224@skynet.ctr.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Paul wrote: > > Today I started experimenting with the Aironet 4800 series 11Mbps > wireless networking cards. Aironet makes PCMCIA, ISA and PCI adapters. > I happen to have the PCMCIA and ISA ones. Like the Lucent WaveLAN/IEEE > cards, the ISA and PCI cards are really PCMCIA cards fitted into a > bridge adapter. Unlike the WaveLAN/IEEE cards, the bridge adapters > look like real ISA or PCI devices to the host, so you don't need > PCCARD support to use them. (The Lucent WaveLAN/IEEE ISA card requires > PCCARD support in order to work.) > > Anyway, that's not why I'm here. My problem is the PCMCIA adapter. > I'm testing it on a Dell Latitude Cpi D300XT, which has both LoseNT 4.0 > and FreeBSD 3.2 installed. I decided to install the PCMCIA card in the > laptop using the LoseNT drivers so that I could have a known working > machine with which to generate traffic so that I could properly test > the ISA card. However much to my surprise (well, not really), LoseNT > failed to detect the card. The 'PC Card (PCMCIA)' icon in the control > shows the PCMCIA modem in slot 1, but shows slot 0 as empty. Naturally, > the drivers from Aironet fail to attach the card. > > So I decided to boot FreeBSD instead. Unfortunately, it didn't detect > the card either. After reading the Aironet manual (which I don't really > have -- shhhh), I found in the section on starting the card that you > have to "Enable power (VCC) to the socket and also set VPP1, VPP2 = 5V." > Looking in /sys/pccard/pccard.c:insert(), I found the following code: > > /* > * Enable 5V to the card so that the CIS can be read. > */ > slt->pwr.vcc = 50; > slt->pwr.vpp = 0; > > So, I changed this to > > slt->pwr.vcc = 50; > slt->pwr.vpp = 50; > > And now pccardc dumpcis shows all of the proper CIS information, pccardd > finds the card and life is good. (Frankly, I was stunned that I figured > this out; I'm not really that bright, you know.) Apparently, the Aironet > card wants VPP turned on before it will let you read the CIS table. > > So, here are my questions: > > - Why is the vpp voltage alwats left at 0? > - Is it safe for me to change the code so that it's set to 5 volts? > Obviously I'm going to need this change in order to make the Aironet > PCMCIA cards work. > - If it's not safe to default vpp to 5 volts, is there a safe way to > detect when it needs to be turned on and do it only for those cards > that need it? I took a quick look through "CardBus System Architecture" (MindShare Inc., ISBN 0-201-40997-6) in the chapter that reviews the PCCard architecture. In "The Power-UP Sequence," pp 57-58, it says: 6. CS notifies socket services (SS) of the initial Vcc requirements. SS then loads the appropriate register within the bridge, causing it to apply the specified Vcc and Vpp values. (Vcc, Vpp1, and Vpp2 must all be initially powered to the voltage specified by the CVS[2:1]# pins. It appears that if the card asks for 5V, all three voltages should be initialized to 5V. It would be nice if we handled 3.3V cards also; I don't want to know what happens to a 3.3V card when you stick it in your FreeBSD machine and it dumbly applies 5V to it. Looks like the inserted() routine needs some serious help. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 10 8:28: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by hub.freebsd.org (Postfix) with ESMTP id 196EA1530B; Sat, 10 Jul 1999 08:27:46 -0700 (PDT) (envelope-from s.mitchell@computer.org) Received: from modem-101.tellurium.dialup.pol.co.uk ([62.136.25.229] helo=valis.goatsucker.org) by mail5.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 112z2X-0006t2-00; Sat, 10 Jul 1999 16:27:45 +0100 Received: (from scott@localhost) by valis.goatsucker.org (8.8.8/8.8.7) id QAA02148; Sat, 10 Jul 1999 16:27:31 +0100 (BST) (envelope-from scott) Message-ID: <19990710162730.60563@goatsucker.org> Date: Sat, 10 Jul 1999 16:27:30 +0100 From: Scott Mitchell To: Poul-Henning Kamp , freebsd-xircom@lovett.com Cc: hackers@FreeBSD.ORG, mobile@FreeBSD.ORG, "David O'Brien" Subject: Reading CIS from kernel? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i X-Operating-System: FreeBSD 2.2.6-RELEASE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, The Xircom ethernet driver needs to read/write PCCARD attribute memory from its probe routine, in order to identify the type of card and to beat brain-damaged CEM56 cards into shape :-) Currently this is done by way of 'fake' calls to read() and write() on the appropriate /dev/cardXX device. However, if we look at the version of the driver that David O'Brien has kindly committed to the repository (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pccard/if_xe.c) we see: =================================================================== RCS file: /home/ncvs/src/sys/dev/pccard/if_xe.c,v retrieving revision 1.2 retrieving revision 1.3 diff -p -u -r1.2 -r1.3 --- src/sys/dev/pccard/if_xe.c 1999/05/14 04:18:24 1.2 +++ /home/ncvs/src/sys/dev/pccard/if_xe.c 1999/05/31 11:24:51 1.3 @@ -352,7 +352,11 @@ xe_memwrite(struct pccard_devinfo *devi, uios.uio_rw = UIO_WRITE; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_write(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } @@ -373,7 +377,11 @@ xe_memread(struct pccard_devinfo *devi, uios.uio_rw = UIO_READ; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]->d_read(makedev(CARD_MAJOR, devi->slt->slotnum), &uios, 0); +#else + return (-1); +#endif } Now I'll grant you that it probably *is* bogus, but when I first started writing the driver it was the least ugly solution proposed. So, since I can't do it that way anymore, are there any suggestions for an 'approved' way of reading/writing PCCARD attribute memory from inside the kernel? If it's just the use of cdevsw[] that's problematic, then making crdread() and crdwrite() (in /sys/pccard/pccard.c) non-static and calling them directly from the driver code would be an easy workaround. Alternatively, I could export pccard_mem and pccard_kmem from the same file and do the reads and writes myself, but that seems a bit dangerous. Any other approach would seem to involve duplicating more of the PCCARD code than I care to, expecially considering that it's all being redone in the newbus-ification of -CURRENT. I'd appreciate some advice from the powers-that-be as to what will and won't get stomped on here, as both David and I would like to see a *working* version of this code in the tree... Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" s.mitchell@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 8:50: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 0577D14C11 for ; Sat, 10 Jul 1999 08:50:00 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id LAA00476 for ; Sat, 10 Jul 1999 11:50:02 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sat, 10 Jul 1999 11:50:01 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: hackers@FreeBSD.org Subject: a BSD identd 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 Is it worth it to write an identd for FreeBSD? With one sysctl added, it's trivial to implement. If an identd would be desired, then should I make a separate one, or rewrite the current inetd's internal identd shim? I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 10 9:41:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 717F014C37; Sat, 10 Jul 1999 09:40:58 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1130BN-000EaC-00; Sat, 10 Jul 1999 18:40:57 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 11:50:01 -0400." Date: Sat, 10 Jul 1999 18:40:57 +0200 Message-ID: <56059.931624857@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999 11:50:01 -0400, "Brian F. Feldman" wrote: > I don't see a reason for pidentd when we could have an identd built in > by me fixing inetd up, and it would all take up less space. Hi Brian, If you do end up messing with inetd's existing ident service, please make sure that the default behaviour remains the same and that the operator must do something to enable an ident service that reports more than just "UNKNOWN-ERROR". Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 9:44:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 0D2A714C37 for ; Sat, 10 Jul 1999 09:44:48 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1130Ev-000Ed1-00; Sat, 10 Jul 1999 18:44:37 +0200 From: Sheldon Hearn To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs In-reply-to: Your message of "Fri, 09 Jul 1999 12:00:52 MST." Date: Sat, 10 Jul 1999 18:44:36 +0200 Message-ID: <56234.931625076@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 09 Jul 1999 12:00:52 MST, Doug wrote: > The amd conf files are below, any insights or suggestions welcome. I can't remember whether it was you or someone else to whom I offered this advice not so recently, so forgive me if I've suggested this to you before. I've found that AMD exacerbates NFS-related problems. Since I moved away from AMD toward using proper NFS mounts (soft, interruptible, bg), the hassles I was having with NFS have gone away completely. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 9:54: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nightfly.apk.net (nightfly.apk.net [207.54.149.151]) by hub.freebsd.org (Postfix) with SMTP id 3731914CA3 for ; Sat, 10 Jul 1999 09:54:04 -0700 (PDT) (envelope-from rme@nightfly.apk.net) Received: (qmail 4166 invoked by uid 1000); 10 Jul 1999 16:56:41 -0000 To: freebsd-hackers@freebsd.org Subject: Re: more amd hangs References: <56234.931625076@axl.noc.iafrica.com> X-Attribution: rme From: rme@nightfly.apk.net (R. Matthew Emerson) Date: 10 Jul 1999 12:56:41 -0400 In-Reply-To: Sheldon Hearn's message of "Sat, 10 Jul 1999 18:44:36 +0200" Message-ID: <87u2rcqw8m.fsf@nightfly.apk.net> Lines: 10 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > I've found that AMD exacerbates NFS-related problems. Since I moved away > from AMD toward using proper NFS mounts (soft, interruptible, bg), the > hassles I was having with NFS have gone away completely. I thought that it was almost never proper to soft-mount rw filesytems. Am I mistaken about this? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 10: 6:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 8B8FC14C05 for ; Sat, 10 Jul 1999 10:06:40 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id NAA01709; Sat, 10 Jul 1999 13:06:34 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sat, 10 Jul 1999 13:06:33 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <56059.931624857@axl.noc.iafrica.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 Sat, 10 Jul 1999, Sheldon Hearn wrote: > > > On Sat, 10 Jul 1999 11:50:01 -0400, "Brian F. Feldman" wrote: > > > I don't see a reason for pidentd when we could have an identd built in > > by me fixing inetd up, and it would all take up less space. > > Hi Brian, > > If you do end up messing with inetd's existing ident service, please > make sure that the default behaviour remains the same and that the > operator must do something to enable an ident service that reports more > than just "UNKNOWN-ERROR". > > Thanks, > Sheldon. > I don't see a point to that. However, I am finished. Please go to http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. =) Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 10 10:13:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 105F914C05; Sat, 10 Jul 1999 10:13:01 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA13461; Sat, 10 Jul 1999 19:12:59 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907101712.TAA13461@gratis.grondar.za> To: "Brian F. Feldman" Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sat, 10 Jul 1999 19:12:58 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is it worth it to write an identd for FreeBSD? With one sysctl added, it's > trivial to implement. If an identd would be desired, then should I make a > separate one, or rewrite the current inetd's internal identd shim? I > don't see a reason for pidentd when we could have an identd built in by > me fixing inetd up, and it would all take up less space. There is the question - what for? identd is of questionable use at best. The best use of identd I have seen is crypted cookies that would allow an attackee to identify an attacker in a non-privacy-invasive manner. In 3 years of running this at an ISP, I have never seen it used in anger. Under normal circumstances (${BIGNUM} Wintendo boxes running IRC clients), the info given is completely useless. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 10 10:13:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 646AF151E8; Sat, 10 Jul 1999 10:13:19 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1130gf-000Ev1-00; Sat, 10 Jul 1999 19:13:17 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 13:06:33 -0400." Date: Sat, 10 Jul 1999 19:13:17 +0200 Message-ID: <57350.931626797@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999 13:06:33 -0400, "Brian F. Feldman" wrote: > I don't see a point to that. I'm not sure whether you don't see the point in the existing behaviour, or whether you don't see the point in doing as I ask and supporting consistent behaviour in FreeBSD. The existing ident implementation is designed to answer queries without answering with any information. This is done so that services MTA's and irc daemons don't end up waiting for ages for the ident request to time out. Why do I want you to work your changes in as an extension that isn't turned on by default? The Principle Of Least Astonishment. If I have a system that hasn't been giving out local usernames in answser to ident queries, I sure as hell don't want it to suddenly start doing so without my telling it to. > However, I am finished. Please go to http://www.FreeBSD.org/~green/ > and get getcred.patch and inetd_ident.patch. I'll look at your inetd-related patches on Sunday evening or Monday and get back to you on Monday, but I do hope you see the light in what I've said above. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 10:27:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 560D414D0A; Sat, 10 Jul 1999 10:27:30 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1130uP-000F3W-00; Sat, 10 Jul 1999 19:27:29 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 19:13:17 +0200." <57350.931626797@axl.noc.iafrica.com> Date: Sat, 10 Jul 1999 19:27:29 +0200 Message-ID: <57877.931627649@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999 19:13:17 +0200, Sheldon Hearn wrote: > The existing ident implementation is designed to answer queries without > answering with any information. This is done so that services MTA's and > irc daemons don't end up waiting for ages for the ident request to time > out. The above paragraph was presented with a tone of more authority than warranted -- this is the way it looks to me, but I don't know for a fact why inetd's existing auth service operates the way it does. Regardless, my comments about folks relying on its existing behaviour still apply. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 12:30:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id AF86D14A13 for ; Sat, 10 Jul 1999 12:30:06 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA32238 for FreeBSD-hackers@freebsd.org; Sat, 10 Jul 1999 21:21:21 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA00520 for FreeBSD-hackers@freebsd.org; Sat, 10 Jul 1999 21:12:49 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907101912.VAA00520@yedi.iaf.nl> Subject: 3.2-STABLE not stable but panicy? To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Sat, 10 Jul 1999 21:12:49 +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+ 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 Is it just me/my machine or has 3.2-STABLE become rather unstable and panic stricken (sp)? Whether it has any correlation I don't know, but it seems to have started when I got in the the RC5DES project a couple of days ago. Yesterday I got a panic like: (no debugging symbols found)... IdlePTD 3174400 initial pcb at 28e864 panicstr: lockmgr: unknown locktype request 0 panic messages: --- panic: lockmgr: unknown locktype request 0 syncing disks... 160 159 139 113 80 32 done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc01594ff in boot () (kgdb) bt #0 0xc01594ff in boot () #1 0xc0159784 in at_shutdown () #2 0xc01555c4 in lockmgr () #3 0xc017ba88 in vop_stdlock () #4 0xc01f7e19 in ufs_vnoperate () #5 0xc0184863 in vn_lock () #6 0xc017e40b in vget () #7 0xc017a55b in vfs_cache_lookup () #8 0xc01f7e19 in ufs_vnoperate () #9 0xc017cb45 in lookup () #10 0xc017c618 in namei () #11 0xc0180969 in change_dir () #12 0xc01808c7 in chdir () #13 0xc021cf63 in syscall () #14 0xc0213cec in Xint0x80_syscall () #15 0x804919f in ?? () #16 0x804af96 in ?? () #17 0x804904d in ?? () (kgdb) I decided to cvsup the latest -STABLE sources and with a kernel based on yesterdays -STABLE I just got (again during a RC5DES run, approx 15 minutes after starting it): (no debugging symbols found)... IdlePTD 3239936 initial pcb at 29e914 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3ff02585 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02078b4 stack pointer = 0x10:0xc6a158b4 frame pointer = 0x10:0xc6a158c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 973 (cron) interrupt mask = net tty bio cam trap number = 12 panic: page fault syncing disks... done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 1 8 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0159e07 in boot () (kgdb) bt #0 0xc0159e07 in boot () #1 0xc015a08c in at_shutdown () #2 0xc021e089 in trap_fatal () #3 0xc021dd67 in trap_pfault () #4 0xc021da0a in trap () #5 0xc02078b4 in zalloci () #6 0xc021ac12 in get_pv_entry () #7 0xc021ada7 in pmap_insert_entry () #8 0xc021b589 in pmap_enter_quick () #9 0xc021b7aa in pmap_object_init_pt () #10 0xc0149c77 in elf_load_section () #11 0xc014a2ae in exec_elf_imgact () #12 0xc01534ff in execve () #13 0xc021e2cb in syscall () #14 0xc0214ecc in Xint0x80_syscall () Cannot access memory at address 0xbfbfd7d8. (kgdb) Before someone asks: yes, I checked the CPU fan.. dmesg: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sat Jul 10 10:49:28 CEST 1999 wilko@yedi.iaf.nl:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 261958495 Hz CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping = 2 Features=0x8001bf AMD Features=0x400<> real memory = 100663296 (98304K bytes) avail memory = 94621696 (92404K bytes) Preloaded elf kernel "kernel" at 0xc0305000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.9.0 xl0: Ethernet address: 00:60:08:09:b8:f1 xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) vga0: rev 0x00 int a irq 14 on pci0.10.0 Qlogic ISP Driver, FreeBSD CAM Version 0.992, Core Version 1.9 isp0: rev 0x05 int a irq 9 on pci0.11.0 isp0: set PCI line size to 16 isp0: set PCI latency to 64 isp0: Ultra Mode Capable isp0: Board Revision 1040B, loaded F/W Revision 7.63.0 isp0: Last F/W revision was 4.53.0 ncr0: rev 0x02 int a irq 11 on pci0.12.0 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x1a0-0x1a7 flags 0x501 on isa sio2: type 16550A (multiport) sio3 at 0x1a8-0x1af flags 0x501 on isa sio3: type 16550A (multiport) sio4 at 0x1b0-0x1b7 flags 0x501 on isa sio4: type 16550A (multiport) sio5 at 0x1b8-0x1bf irq 5 flags 0x501 on isa sio5: type 16550A (multiport master) fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port isic0 at 0xd80 irq 15 flags 0x3 on isa isic0: Teles S0/16.3 isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x960) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x160, AddrB=0x560) vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging i4b: ISDN call control device attached i4bisppp: 2 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4btrc: 2 ISDN trace device(s) attached Waiting 3 seconds for SCSI devices to settle isp0: driver initiated bus reset of bus 0 changing root device to da0s2a da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17365MB (35565080 512 byte sectors: 255H 63S/T 2213C) WARNING: / was not properly dismounted da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) cd0 at isp0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: cd present [1289068 x 512 byte records] cd1 at isp0 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 8) cd1: Attempt to query device size failed: NOT READY, Medium not present ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates Comments invited, I'll build and boot a kernel with debugging symbols in the meantime. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl 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 10 12:34:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (unknown [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 8E33714BDB; Sat, 10 Jul 1999 12:34:18 -0700 (PDT) (envelope-from ben@penelope.skunk.org) Received: from localhost (ben@localhost) by penelope.skunk.org (8.9.3/8.9.3) with ESMTP id TAA16963; Sat, 10 Jul 1999 19:33:09 GMT Date: Sat, 10 Jul 1999 19:33:09 +0000 (GMT) From: Ben Rosengart To: Mark Murray Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-Reply-To: <199907101712.TAA13461@gratis.grondar.za> 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 Sat, 10 Jul 1999, Mark Murray wrote: > There is the question - what for? identd is of questionable use at best. I used to run a public shell machine, and one of my users cracked someone else's site. Identd made it much easier to figure out who the problem user was. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 12:50:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 60F9B15194; Sat, 10 Jul 1999 12:50:29 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA14008; Sat, 10 Jul 1999 21:49:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907101949.VAA14008@gratis.grondar.za> To: Ben Rosengart Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sat, 10 Jul 1999 21:49:12 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 10 Jul 1999, Mark Murray wrote: > > > There is the question - what for? identd is of questionable use at best. > > I used to run a public shell machine, and one of my users cracked > someone else's site. Identd made it much easier to figure out who the > problem user was. That represents tiny percentage of identd use. The rest is noise. Pidentd+DES _is_ useful in the situation you mention above. It is on average useless to most security folk, as it can also be used to obfuscate the problem. Crack root on the box, and identd is no longer trustworthy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 10 12:58:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id A295114C05; Sat, 10 Jul 1999 12:58:13 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id 01A61374DF; Sat, 10 Jul 1999 15:58:10 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id OAA64818; Sat, 10 Jul 1999 14:56:41 -0500 (CDT) (envelope-from chris) Date: Sat, 10 Jul 1999 14:56:40 -0500 From: Chris Costello To: Mark Murray Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Message-ID: <19990710145640.B57198@holly.dyndns.org> Reply-To: chris@calldei.com References: <199907101949.VAA14008@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <199907101949.VAA14008@gratis.grondar.za>; from Mark Murray on Sat, Jul 10, 1999 at 09:49:12PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 10, 1999, Mark Murray wrote: > > I used to run a public shell machine, and one of my users cracked > > someone else's site. Identd made it much easier to figure out who the > > problem user was. > > That represents tiny percentage of identd use. The rest is noise. > > Pidentd+DES _is_ useful in the situation you mention above. It is > on average useless to most security folk, as it can also be used > to obfuscate the problem. Crack root on the box, and identd is no > longer trustworthy. You have an interesting point, however, once a user gains root access, nothing on the machine should be considered trustworthy. -- Chris Costello If a train station is where the train stops, what is a work station? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 13:51:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 914FE14D9B; Sat, 10 Jul 1999 13:50:55 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id WAA14139; Sat, 10 Jul 1999 22:48:55 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907102048.WAA14139@gratis.grondar.za> To: chris@calldei.com Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sat, 10 Jul 1999 22:48:53 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Pidentd+DES _is_ useful in the situation you mention above. It is > > on average useless to most security folk, as it can also be used > > to obfuscate the problem. Crack root on the box, and identd is no > > longer trustworthy. > > You have an interesting point, however, once a user gains root > access, nothing on the machine should be considered trustworthy. Right - but ident is an "after the fact" tool; one which at the time you really need results is at its least trustworthy. I need that like an extra hole in the head. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.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 10 13:59: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 3860314E0C; Sat, 10 Jul 1999 13:58:57 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id ADD0637096; Sat, 10 Jul 1999 16:58:53 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA64961; Sat, 10 Jul 1999 15:57:27 -0500 (CDT) (envelope-from chris) Date: Sat, 10 Jul 1999 15:57:21 -0500 From: Chris Costello To: Mark Murray Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Message-ID: <19990710155721.C57198@holly.dyndns.org> Reply-To: chris@calldei.com References: <199907102048.WAA14139@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <199907102048.WAA14139@gratis.grondar.za>; from Mark Murray on Sat, Jul 10, 1999 at 10:48:53PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 10, 1999, Mark Murray wrote: > > > Pidentd+DES _is_ useful in the situation you mention above. It is > > > on average useless to most security folk, as it can also be used > > > to obfuscate the problem. Crack root on the box, and identd is no > > > longer trustworthy. > > > > You have an interesting point, however, once a user gains root > > access, nothing on the machine should be considered trustworthy. > > Right - but ident is an "after the fact" tool; one which at the time > you really need results is at its least trustworthy. I need that like > an extra hole in the head. :-) The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. -- Chris Costello Sure it's user-friendly...if you know what you're doing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 14:50:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D591814CB7; Sat, 10 Jul 1999 14:50:40 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA10558; Sat, 10 Jul 1999 15:50:37 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA33143; Sat, 10 Jul 1999 15:48:44 -0600 (MDT) Message-Id: <199907102148.PAA33143@harmony.village.org> To: Sheldon Hearn Subject: Re: a BSD identd Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Jul 1999 18:40:57 +0200." <56059.931624857@axl.noc.iafrica.com> References: <56059.931624857@axl.noc.iafrica.com> Date: Sat, 10 Jul 1999 15:48:43 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <56059.931624857@axl.noc.iafrica.com> Sheldon Hearn writes: : If you do end up messing with inetd's existing ident service, please : make sure that the default behaviour remains the same and that the : operator must do something to enable an ident service that reports more : than just "UNKNOWN-ERROR". Yes. I'd love to replace my perl script: #!/usr/local/bin/perl ($a, $b) = split(/[,\n\r ]+/,<>); print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; with something a little less heavy-weight. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 14:51:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 328AF14CB7; Sat, 10 Jul 1999 14:51:51 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA10565; Sat, 10 Jul 1999 15:51:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA33167; Sat, 10 Jul 1999 15:50:04 -0600 (MDT) Message-Id: <199907102150.PAA33167@harmony.village.org> To: Sheldon Hearn Subject: Re: a BSD identd Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Jul 1999 19:13:17 +0200." <57350.931626797@axl.noc.iafrica.com> References: <57350.931626797@axl.noc.iafrica.com> Date: Sat, 10 Jul 1999 15:50:04 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : > I don't see a point to that. Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 14:57:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9399814CB7; Sat, 10 Jul 1999 14:57:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA10578; Sat, 10 Jul 1999 15:57:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA33197; Sat, 10 Jul 1999 15:55:44 -0600 (MDT) Message-Id: <199907102155.PAA33197@harmony.village.org> To: Ben Rosengart Subject: Re: a BSD identd Cc: Mark Murray , "Brian F. Feldman" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Jul 1999 19:33:09 -0000." References: Date: Sat, 10 Jul 1999 15:55:43 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Ben Rosengart writes: : I used to run a public shell machine, and one of my users cracked : someone else's site. Identd made it much easier to figure out who the : problem user was. Unfortunately, I've seen the dark side of identd which makes me *HATE* it with a passion. There have been several places that I worked that ran identd, but from which I never sent mail from. The spammers started hitting me there.... They got the address from the ident replies.... From this, I'm *NEVER* going to run a identd that gives out real names.... Hence "Warm-Fuzzy" in my fake script. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 15: 0:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 65B9214CB7; Sat, 10 Jul 1999 15:00:32 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4120278; Sun, 11 Jul 1999 06:00:31 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: Sheldon Hearn , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 15:48:43 CST." <199907102148.PAA33143@harmony.village.org> Date: Sun, 11 Jul 1999 06:00:31 +0800 From: Peter Wemm Message-Id: <19990710220031.4120278@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <56059.931624857@axl.noc.iafrica.com> Sheldon Hearn writes: > : If you do end up messing with inetd's existing ident service, please > : make sure that the default behaviour remains the same and that the > : operator must do something to enable an ident service that reports more > : than just "UNKNOWN-ERROR". > > Yes. I'd love to replace my perl script: > > #!/usr/local/bin/perl > ($a, $b) = split(/[,\n\r ]+/,<>); > print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; > > with something a little less heavy-weight. Come on guys! identd is one of those topics that also comes under the banner of "religion", and no one solution works for everyone. It is often abused, has too much credibility placed on it at times that it is really meaningless, and it *does* have legitimate uses. It all depends on the circumstances. I just wish that the inetd builtins could take arguments to allow selection of behavior according to what the the person using needs or wants. (ie: real, fake, "unknown error", "piss off", etc results). I also like pidentd's DES encrypted cookie as it is a nice solution to the forgery problem. (I actually had this happen once, a long time ago). Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 15: 2: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7C0B114CB7 for ; Sat, 10 Jul 1999 15:02:03 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA10601; Sat, 10 Jul 1999 16:01:55 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA33239; Sat, 10 Jul 1999 16:00:03 -0600 (MDT) Message-Id: <199907102200.QAA33239@harmony.village.org> Subject: Re: a BSD identd To: hackers@FreeBSD.ORG Cc: chris@calldei.com In-reply-to: Your message of "Sat, 10 Jul 1999 15:57:21 CDT." <19990710155721.C57198@holly.dyndns.org> References: <19990710155721.C57198@holly.dyndns.org> <199907102048.WAA14139@gratis.grondar.za> Date: Sat, 10 Jul 1999 16:00:02 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990710155721.C57198@holly.dyndns.org> Chris Costello writes: : The whole point of ident was -- and still is -- to : authenticate or verify who created a specific TCP connection. NO. The IDENT protocol was never intended to authenticate who was on the other end. *NEVER*. People ABUSED it as such, but its value is only as good as the person providing the information. : If : the machine is untouched (i.e., has not had the root account : compromised), then ident responses are usually trustworthy : enough. It is generally not applicable to single user operating : systems like Windows, Mac OS, or DOS. FALSE. If I can hit the remote side faster than the machine that is untouched with a response (by sniffing the packets on a network and heavily loading the machine that I'm attacking from, but haven't penetrated root), then the information is bogus as well. At best, the information provides who might be on the other end of the end of the link... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 15:11:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 0685D14D72; Sat, 10 Jul 1999 15:11:41 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1135Ks-000HYT-00; Sun, 11 Jul 1999 00:11:06 +0200 From: Sheldon Hearn To: chris@calldei.com Cc: Mark Murray , Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 15:57:21 EST." <19990710155721.C57198@holly.dyndns.org> Date: Sun, 11 Jul 1999 00:11:06 +0200 Message-ID: <67484.931644666@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999 15:57:21 EST, Chris Costello wrote: > The whole point of ident was -- and still is -- to > authenticate or verify who created a specific TCP connection. Crhis, as Warner's already pointed out, you're wrong. :-) Ident's intended purpose is for me to give you something to report back to me when you think someone on my box is screwing around. Ident responses are not useful to anyone but the owner of the box issuing them, and even then they're only useful until the box is penetrated. This is all silliness. The service has a place, it's just mostly misunderstood, and none of this has anything to do with Brian Feldman's original mail. I _will_ have a problem with anyone changing inetd to provide real usernames in response to auth (ident) service requests, where it did not do so before. I don't have a problem with inetd being _able_ to do so if it's given some extra option, so long as that doesn't become a new default for existing configurations. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 15:14:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A2C8114D72 for ; Sat, 10 Jul 1999 15:14:28 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA10638; Sat, 10 Jul 1999 16:14:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA33353; Sat, 10 Jul 1999 16:12:41 -0600 (MDT) Message-Id: <199907102212.QAA33353@harmony.village.org> To: Bill Paul Subject: Re: PCCARD and Vpp voltage Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 09 Jul 1999 18:38:43 EDT." <199907092238.SAA07224@skynet.ctr.columbia.edu> References: <199907092238.SAA07224@skynet.ctr.columbia.edu> Date: Sat, 10 Jul 1999 16:12:41 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907092238.SAA07224@skynet.ctr.columbia.edu> Bill Paul writes: : - Why is the vpp voltage alwats left at 0? I think that is what the standard suggested. Since I've not yet recieved the standard, I can't look it up. : - Is it safe for me to change the code so that it's set to 5 volts? : Obviously I'm going to need this change in order to make the Aironet : PCMCIA cards work. : - If it's not safe to default vpp to 5 volts, is there a safe way to : detect when it needs to be turned on and do it only for those cards : that need it? I'm not sure. There are low voltage cards and I'm not sure how they would like having 5V applied to Vpp to them. Again, I've not looked up the standards.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 16:23: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 1ED2F14C59 for ; Sat, 10 Jul 1999 16:22:58 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id 3EAF43E857; Sat, 10 Jul 1999 19:05:35 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id SAA65356; Sat, 10 Jul 1999 18:04:09 -0500 (CDT) (envelope-from chris) Date: Sat, 10 Jul 1999 18:04:07 -0500 From: Chris Costello To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd Message-ID: <19990710180407.D57198@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990710155721.C57198@holly.dyndns.org> <199907102048.WAA14139@gratis.grondar.za> <19990710155721.C57198@holly.dyndns.org> <199907102200.QAA33239@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <199907102200.QAA33239@harmony.village.org>; from Warner Losh on Sat, Jul 10, 1999 at 04:00:02PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 10, 1999, Warner Losh wrote: > In message <19990710155721.C57198@holly.dyndns.org> Chris Costello writes: > : The whole point of ident was -- and still is -- to > : authenticate or verify who created a specific TCP connection. > > NO. The IDENT protocol was never intended to authenticate who was on > the other end. *NEVER*. People ABUSED it as such, but its value is > only as good as the person providing the information. I was only specifying what I gathered from the RFC. What was ident actually intended for, then? -- Chris Costello You might have mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 16:34:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0278114CCA for ; Sat, 10 Jul 1999 16:34:30 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA10796; Sat, 10 Jul 1999 17:34:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA33544; Sat, 10 Jul 1999 17:32:42 -0600 (MDT) Message-Id: <199907102332.RAA33544@harmony.village.org> To: chris@calldei.com Subject: Re: a BSD identd Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Jul 1999 18:04:07 CDT." <19990710180407.D57198@holly.dyndns.org> References: <19990710180407.D57198@holly.dyndns.org> <19990710155721.C57198@holly.dyndns.org> <199907102048.WAA14139@gratis.grondar.za> <19990710155721.C57198@holly.dyndns.org> <199907102200.QAA33239@harmony.village.org> Date: Sat, 10 Jul 1999 17:32:42 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990710180407.D57198@holly.dyndns.org> Chris Costello writes: : I was only specifying what I gathered from the RFC. What was : ident actually intended for, then? It was at best a way to track back malicious connections for log files after the fact. Only after the initial standard came out did people try to abuse it for authentication... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 17: 1: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw01.execpc.com (mailgw01.execpc.com [169.207.2.78]) by hub.freebsd.org (Postfix) with ESMTP id 54FBA14D01; Sat, 10 Jul 1999 17:00:49 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (kronos-2-54.mdm.mkt.execpc.com [169.207.85.182]) by mailgw01.execpc.com (8.9.1) id TAA25155; Sat, 10 Jul 1999 19:00:46 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 381BD1E1; Sat, 10 Jul 1999 16:25:50 -0500 (CDT) To: Mark Murray Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sat, 10 Jul 1999 21:49:12 +0200." <199907101949.VAA14008@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Jul 1999 16:25:50 -0500 From: Jon Hamilton Message-Id: <19990710212550.381BD1E1@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907101949.VAA14008@gratis.grondar.za>, Mark Murray wrote: } > On Sat, 10 Jul 1999, Mark Murray wrote: } > } > > There is the question - what for? identd is of questionable use at best. } > } > I used to run a public shell machine, and one of my users cracked } > someone else's site. Identd made it much easier to figure out who the } > problem user was. } } That represents tiny percentage of identd use. The rest is noise. } } Pidentd+DES _is_ useful in the situation you mention above. It is } on average useless to most security folk, as it can also be used } to obfuscate the problem. Crack root on the box, and identd is no } longer trustworthy. Just because it's useless in some situations doesn't mean it's not useful in others. Yours is an argument against _misusing_ identd, not an argument against _using_ it. -- Jon Hamilton hamilton@pobox.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 10 19: 1:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 14D5D14BF3 for ; Sat, 10 Jul 1999 19:01:35 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-200.bellatlantic.net [151.198.117.200]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id WAA03737 for ; Sat, 10 Jul 1999 22:01:31 -0400 (EDT) Message-ID: <3787FB9D.3CDF0839@bellatlantic.net> Date: Sat, 10 Jul 1999 22:04:13 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Proposed substitution for ACLs 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 want to propose a simple substitution for ACLs. No, here is no patch yet but I'm ready and willing to do it. The reason why I want to discuss it first is that this is a Political Thing. And if the Core Team decides that it's a Bad Thing, I suppose it will never get commited to the system. Because of this I would like to see some encouraging signs from the Core Team before implementing it. Now to the issue itself. ACLs are a popular thing nowadays and as far as I know FreeBSD does not have it yet. But although everyone boasts with their ACL support I think nobody is really using it (and if somebody is using it then I think it's often not the best decision). ACLs have obvious drawbacks: - they are not supported by the standard file formats like tar or cpio - they need lots of ugly flags for the commands like chown or ls, and some new ugly commands - they are just by themselves difficult to show clearly in ls - they are a mess and promote ad-hoc assignment of permissions For example, Netware suports ACLs and I have seen by myself what mess the sysadmins who have head problems are able to create with them. But in fact the classic Unix permissions seem to have only one real problem: sometimes it's neccessary to give read permissions to one group of users and read-write permissions to another group of users. But Unix permissions support permissions for only one group and that makes the problem. A simple solution would be to add the second group but this would also break the compatibility. I propose to re-use the "uid" field to held the permissions for the second group. Suppose we do the following: 1. Add a sysctl flag enabling or disabling (by default) the extended permissions. That should completely cover the compatibility issues. 2. Sysadmin uses unique IDs for the users and groups in the common ID space. Say, if there is a user with ID=2000 then there must be no group with ID=2000 (except a special case described later). Traditionally there is such overlapping in the low IDs, so let's enable the new behavior only for IDs > 1000 (or some other number, possibly another sysctl parameter). 3. Implement the following semantics (a simple and straightforward addition to ufs_access() ): if the new behavior is enabled and the file owner's ID is over 1000 (or a sysctl parameter) then in addition to comparing the process'es UID with the file owner ID we compare all process'es group IDs with the file owner ID and if any of them matches we use the "owner" permissions for this process. So, in effect we consider the file owner ID as both user and group number, and the described problem with two groups with different permissions is solved. 4. The described semantics is used only for file access but not modification of the access rights, the "owner group" can't modify the permissions of the file. And here we come to the special case mentioned in p.2: if there is an user with UID equal to the GID of the "owner group" such user can modify the permissions. This user may be a pseudo-user created together with the group. If we want to give the "owner group" the right to change all permissions of its files we can just do something like (suppose whe have user `mygrp' and group `mygrp' with the same ID): # cp /bin/chmod /usr/local/bin/mygrpchmod # chown mygrp /usr/local/bin/mygrpchmod # chmod 500 /usr/local/bin/mygrpchmod # chmod u+s /usr/local/bin/mygrpchmod The same thing may be ised for chown. In result all the group members will be able to execute mygrpchmod, and when it will be executed it will assume the EUID of the user mygrp and will be able the file permissions. Or we can do `chmod 050' and give the permission to modify all the permissions of this "owner group" to another group of users. Having a pseudo-user with the same ID as a group also gives for free `ls' showing the right symbolic owner name. 5. If this behavior is wanted on NFS, that can be done too. Probably, with a separate sysctl flag. These additions give essentially the same flexibility as ACLs give but without any change in the i-node format, ls and tar/cpio formats, don't really need any special programs nor flags to manipulate them. Though a few user-level additions may be added for convenience, such as automatic addition of a pseudo-user for each defined group, check for user/group ID conflicts, multi-level groups, additional programs to give better granularity of control over file permissions. That's all. I think the idea is rather simple and clean. Any comments are welcome. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 21:50: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B6936150AC for ; Sat, 10 Jul 1999 21:50:05 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA16657; Sun, 11 Jul 1999 13:48:46 +0900 (JST) Message-ID: <37882150.87A93451@newsguy.com> Date: Sun, 11 Jul 1999 13:45:04 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Sergey Babkin Cc: hackers@FreeBSD.ORG Subject: Re: Proposed substitution for ACLs References: <3787FB9D.3CDF0839@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > > I want to propose a simple substitution for ACLs. No, here > is no patch yet but I'm ready and willing to do it. The reason > why I want to discuss it first is that this is a Political Thing. > And if the Core Team decides that it's a Bad Thing, I suppose > it will never get commited to the system. Because of this I > would like to see some encouraging signs from the Core Team > before implementing it. Do whatever you want: as a fs layer. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 22:43:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 7187114CC1; Sat, 10 Jul 1999 22:43:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA29700; Sat, 10 Jul 1999 23:42:55 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37882EDD.1003BD9E@softweyr.com> Date: Sat, 10 Jul 1999 23:42:53 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Sheldon Hearn , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd References: <56059.931624857@axl.noc.iafrica.com> <199907102148.PAA33143@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > Yes. I'd love to replace my perl script: > > #!/usr/local/bin/perl > ($a, $b) = split(/[,\n\r ]+/,<>); > print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; > > with something a little less heavy-weight. OK, here's roughly the same thing as a stand-alone server in C (for the absolute fastest lies in the west. ;^) It's been a while since I've done any programming above the guts of the IP level, so feel free to critique the bejabbers out of this. I don't think I'm leaking any memory or file descriptors, or otherwise doing something stupid, but I spent about 10 minutes on this code. Purists will note that the parsing of the client request is REALLY SIMPLE. ;^) /* * Copyright (c) 1999 Softweyr LLC. All rights reserved. * * identd: a simple server for RFC1413 Identification Service that refuses * to give away critical system information. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notices, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above * copyright notices, this list of conditions and the following * disclaimer in the documentation and/or other materials provided * with the distribution. * * THIS SOFTWARE IS PROVIDED BY SOFTWEYR LLC AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SOFTWEYR LLC OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. * * $Id$ */ #include #include #include #include #include #include #define IDENT_PORT 113 char *pname; const int STARS_SHINE = 1; int main(int argc, char *argv[]) { int serv_sock, client_sock, cli_len; size_t iolen; struct sockaddr_in cli_addr, serv_addr; char iobuf[BUFSIZ], *ioptr; pname = argv[0]; /* * Create a TCP socket and bind it to the ident port. */ serv_sock = socket(AF_INET, SOCK_STREAM, 0); if (serv_sock < 0) { perror("opening server socket"); return -1; } bzero((char *) &serv_addr, sizeof (serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(IDENT_PORT); if (bind(serv_sock, (struct sockaddr *) &serv_addr, sizeof (serv_addr)) < 0) { perror("binding server socket to ident port"); return -1; } listen(serv_sock, 5); while (STARS_SHINE) { /* * Gather host connections and answer them immediately. */ cli_len = sizeof (cli_addr); bzero((char *) &cli_addr, sizeof (cli_addr)); client_sock = accept(serv_sock, (struct sockaddr *) &cli_addr, &cli_len); if (client_sock < 0) { perror("accepting connection on server socket"); break; } if ((iolen = read(client_sock, iobuf, BUFSIZ)) < 0) { perror("reading from client"); close(client_sock); break; } iobuf[iolen] = '\0'; ioptr = strchr(iobuf, '\r'); if (ioptr == NULL) { perror("invalid client request"); close(client_sock); break; } iolen = ioptr - iobuf; strncpy(ioptr, " : USERID : UNIX : Warm-Fuzzy\r\n", BUFSIZ - iolen); if (write(client_sock, iobuf, strlen(iobuf)) < strlen(iobuf)) { perror("writing response to client"); } close(client_sock); } /* * Not normally reached, but those stars may go out some day... */ close(serv_sock); return 0; } -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.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 10 22:50: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (unknown [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 8699D14CC1; Sat, 10 Jul 1999 22:50:03 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id AAA11611; Sun, 11 Jul 1999 00:49:59 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907110549.AAA11611@celery.dragondata.com> Subject: Re: a BSD identd In-Reply-To: <199907101712.TAA13461@gratis.grondar.za> from Mark Murray at "Jul 10, 1999 07:12:58 pm" To: mark@grondar.za (Mark Murray) Date: Sun, 11 Jul 1999 00:49:59 -0500 (CDT) Cc: green@FreeBSD.ORG (Brian F. Feldman), hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 > > Is it worth it to write an identd for FreeBSD? With one sysctl added, it's > > trivial to implement. If an identd would be desired, then should I make a > > separate one, or rewrite the current inetd's internal identd shim? I > > don't see a reason for pidentd when we could have an identd built in by > > me fixing inetd up, and it would all take up less space. > > There is the question - what for? identd is of questionable use at best. > > The best use of identd I have seen is crypted cookies that would allow > an attackee to identify an attacker in a non-privacy-invasive manner. > In 3 years of running this at an ISP, I have never seen it used in anger. > > Under normal circumstances (${BIGNUM} Wintendo boxes running IRC > clients), the info given is completely useless. > Just to add a counter-point here, I run an ISP that offers shell accounts. We get idiot customers using IRC for all sorts of nasty things at times, and identd is the only method I have for knowing who did it when I get complaints. However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 10 22:50:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id D9E6F14E3D for ; Sat, 10 Jul 1999 22:50:10 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id BAA13783; Sun, 11 Jul 1999 01:49:59 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 01:49:59 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Wes Peters Cc: Warner Losh , Sheldon Hearn , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <37882EDD.1003BD9E@softweyr.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 inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. Then the user can select one of two lines for a real ident service or a fake one. I should probably take the FAKEID stuff out, or make sure that noone can fake another user with it. Hmm... I'll fix that in the next few minutes, I guess. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | 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 10 23:31:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 72A3514C82 for ; Sat, 10 Jul 1999 23:31:18 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id CAA14598; Sun, 11 Jul 1999 02:30:52 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 02:30:51 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Kevin Day Cc: Mark Murray , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <199907110549.AAA11611@celery.dragondata.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 Sun, 11 Jul 1999, Kevin Day wrote: > > > Is it worth it to write an identd for FreeBSD? With one sysctl added, it's > > > trivial to implement. If an identd would be desired, then should I make a > > > separate one, or rewrite the current inetd's internal identd shim? I > > > don't see a reason for pidentd when we could have an identd built in by > > > me fixing inetd up, and it would all take up less space. > > > > There is the question - what for? identd is of questionable use at best. > > > > The best use of identd I have seen is crypted cookies that would allow > > an attackee to identify an attacker in a non-privacy-invasive manner. > > In 3 years of running this at an ISP, I have never seen it used in anger. > > > > Under normal circumstances (${BIGNUM} Wintendo boxes running IRC > > clients), the info given is completely useless. > > > > Just to add a counter-point here, I run an ISP that offers shell accounts. > We get idiot customers using IRC for all sorts of nasty things at times, and > identd is the only method I have for knowing who did it when I get > complaints. > > However, pidentd is rather buggy of late, and tends to freak out a lot. If > we could have an 'official' identd, I'd like it. :) Go ahead and try out mine then! You'll need the following patches from http://www.FreeBSD.org/~green/ : socred.patch (not necessary for 4.0; some parts require manual attention in 3.X, as it won't patch perfectly; this is already applied in 4.0) getcred.patch inetd_ident.patch Patch them in in order, making sure they apply correctly. Then make includes, rebuild the kernel, rebuild modules, install kernel and modules, rebuild inetd, edit inetd.conf to enable the built-in "auth" service, and reboot. Let me know how it goes. I hope to make this standard as part of 4.0 :) > > Kevin > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message