From owner-freebsd-hackers Sun Jul 25 0:33:10 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 98689150A6 for ; Sun, 25 Jul 1999 00:33:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA37426; Sun, 25 Jul 1999 00:30:44 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jul 1999 00:30:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199907250730.AAA37426@apollo.backplane.com> To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: mbuf leak found... for real this time. References: <199907241935.PAA13884@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> between NFSv2 and NFSv3. :Yes, I concur with your patch whole-heartedly. Apparently last night I :was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) : :I alas will not be able to test it. The machine is up and stable with 3k :mbufs in reserve.. maybe later :) : :As an aside, what about getting rid of that mbuf leak if a nfs-service :routine returns with error!=0? : :-- :David Cross | email: crossd@cs.rpi.edu Well, theoretically we just free the mbuf in the error case within nfs_syscalls.c/nfssvc_nfsd(), around line 661 (STABLE), or 650 (CURRENT). Realistically every single nfs server procedure would need to be audited to make sure that a non-NULL *mreq is valid in all error cases - not something I particularly want to do without commit privs from a crediting point of view. -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 Sun Jul 25 1:56:57 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 BFF2414DC0; Sun, 25 Jul 1999 01:56:55 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id RAA16465; Sun, 25 Jul 1999 17:55:54 +0900 (JST) Message-ID: <379AD104.18E2A64A@newsguy.com> Date: Sun, 25 Jul 1999 17:55:32 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Dillon , Matthew Jacob , Guido van Rooij , freebsd-hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: Holy cow - path component freeing a mess? (was Re: D'oh!) 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 Julian Elischer wrote: > > talk to terry on this topic :-) > He has a set of patches that straighten all this out You know, I almost made that comment. But I'd rather not have Terry started again. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Your usefulness to my realm ended the day you made it off Hustaing alive." -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 8: 2: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from redbox.venux.net (redbox.venux.net [216.47.238.10]) by hub.freebsd.org (Postfix) with ESMTP id 77FC515183 for ; Sun, 25 Jul 1999 08:02:08 -0700 (PDT) (envelope-from matthew@venux.net) Received: from thunder (net177138.hcv.com [209.153.177.138]) by redbox.venux.net (Postfix) with SMTP id 7507D2E20B; Sun, 25 Jul 1999 11:02:10 -0400 (EDT) Message-Id: <4.1.19990725105802.00a12af0@mail.venux.net> X-Sender: mhagerty@mail.venux.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 25 Jul 1999 11:00:39 -0400 To: Matthew Dillon , Mike Smith From: Matthew Hagerty Subject: Re: Missing ld.so in 3.2? SOLVED, Thank you! Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199907232340.QAA28389@apollo.backplane.com> References: <199907232330.QAA01283@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Installing compat22 did it, thank you! Matthew At 04:40 PM 7/23/99 -0700, Matthew Dillon wrote: >:Install the compat22 dist; you have an old a.out binary there. >: >:> Greetings, >:> >:> I have a 3.2 install from CD-ROM and I am trying to run a commerical >:> program, i.e. I don't have the source, and it is giving me the following >error: >:> >:> [Fri Jul 23 16:47:48 1999] [error] [client 216.47.238.65] malformed >header from >:> script. Bad header=Couldn't open /usr/libexec/ld.so >:... > > Btw, the netscape4.5.us port needs this too, along with half a dozen > libraries in /usr/lib/aout/. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 10:53:25 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 E9F7D15200 for ; Sun, 25 Jul 1999 10:53:20 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip234.houston3.tx.pub-ip.psi.net [38.12.169.234]) by leap.innerx.net (Postfix) with ESMTP id 573AD37082; Sun, 25 Jul 1999 13:52:45 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id MAA79042; Sun, 25 Jul 1999 12:53:35 -0500 (CDT) (envelope-from chris) Date: Sun, 25 Jul 1999 12:53:34 -0500 From: Chris Costello To: Wes Peters Cc: Matthew Dillon , Nick Hibma , "Matthew D. Fuller" , Len Conrad , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD: the stealth OS? Message-ID: <19990725125334.A79022@holly.dyndns.org> Reply-To: chris@calldei.com References: <199907231606.JAA25968@apollo.backplane.com> <3798B2B4.9BB398AE@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <3798B2B4.9BB398AE@softweyr.com>; from Wes Peters on Fri, Jul 23, 1999 at 12:21:40PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 23, 1999, Wes Peters wrote: > > Do I get a discount for having the same first name? > > Nope, you get charged double for attempting to share in the Matt-light. I've got you _all_ beat. Both of their first names is my middle name. I get through free! -- |Chris Costello |Controlling complexity is the essence of computer programming. - Kernigan `-------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 10:59:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 32F9815216 for ; Sun, 25 Jul 1999 10:59:38 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id KAA11816 for ; Sun, 25 Jul 1999 10:59:24 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379B507E.1A595947@gorean.org> Date: Sun, 25 Jul 1999 10:59:26 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: [Fwd: wd0 DMA errors] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No answer on -current, any help appreciated. Doug -------- Original Message -------- My boxes at work are -current from 7/16. They both use IDE disks since other than system stuff the disk I/O for the real work is all NFS. In the daily logs this morning I see this: > wd0: interrupt timeout (status 58 error 0) > wd0: wdtimeout() DMA status 4 Can anyone shed some light on what that is, and how bad it is? I won't have access to the box itself till monday, but it would be nice to have some answers ready when I go in. Thanks, Doug 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 Sun Jul 25 10:59:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from exit-gw.power.net (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 42F6E15213 for ; Sun, 25 Jul 1999 10:59:36 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.8.8/8.8.8) with ESMTP id KAA02172 for ; Sun, 25 Jul 1999 10:48:58 -0700 (PDT) (envelope-from frank@tinker.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.2/8.9.1) id KAA00680 for hackers@freebsd.org; Sun, 25 Jul 1999 10:48:57 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199907251748.KAA00680@realtime.exit.com> Subject: Upgrading from 2.2.8 to 3.2-stable... To: hackers@freebsd.org Date: Sun, 25 Jul 1999 10:48:57 -0700 (PDT) Reply-To: frank@exit.com 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 Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar frank@exit.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 25 11: 2: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from phoenix.welearn.com.au (phoenix.welearn.com.au [139.130.44.81]) by hub.freebsd.org (Postfix) with ESMTP id 6465514F86; Sun, 25 Jul 1999 11:02:01 -0700 (PDT) (envelope-from sue@phoenix.welearn.com.au) Received: (from sue@localhost) by phoenix.welearn.com.au (8.9.3/8.9.3) id EAA19921; Mon, 26 Jul 1999 04:02:38 +1000 (EST) (envelope-from sue) Date: Mon, 26 Jul 1999 04:02:36 +1000 From: Sue Blake To: freebsd-hackers@freebsd.org Cc: freebsd-doc@freebsd.org Subject: sandbox?? Message-ID: <19990726040233.E7349@welearn.com.au> Mail-Followup-To: freebsd-hackers@freebsd.org, freebsd-doc@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi clever people Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: > In article <19990719212431.D300@welearn.com.au>, > Sue Blake wrote: > : Could someone tell me what is a sandbox, what does it do, how does it > : work, how do I use it, or where is it documented? > : named(8) and security(8) seem to assume one already knows. > > It's a generic term. It refers to a restricted environment in > which something is to be done. Exactly how a sandbox is > implemented depends on the specific application. As you see it is far from the complete 4-5 part answer I need. The problem that I see is that our named.conf refers to this sandbox thing, implies that it is actually the default method for BIND in FreeBSD (I don't think it is though), and directs the user to man pages which don't provide the necessary info to be able to confidently (un)implement it. If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone who they teach (me if really necessary) needs to document it so that anyone seriously interested can figure it out on thier own (or at least accept the defaults with confidence), and then change at least the named.conf to point to that info. It sounds like a good idea, worth giving people the resources to use it. (Email cc would be appreciated) -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 11:10: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 4BAFD150DE for ; Sun, 25 Jul 1999 11:10: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 118ShD-000GCw-00; Sun, 25 Jul 1999 20:08:23 +0200 From: Sheldon Hearn To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: wd0 DMA errors] In-reply-to: Your message of "Sun, 25 Jul 1999 10:59:26 MST." <379B507E.1A595947@gorean.org> Date: Sun, 25 Jul 1999 20:08:23 +0200 Message-ID: <62305.932926103@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > No answer on -current, any help appreciated. We're probably all sitting here thinking "I'm sure this was asked and answered recently. He can read his CURRENT mail like the rest of us." For the terminally lazy, this was a bug in the pci code, introduced a week or so ago and fixed in CURRENT and reverted in STABLE some time in the last few days. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 11:23:42 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 43E1B14EAB; Sun, 25 Jul 1999 11:23:37 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA01438; Mon, 26 Jul 1999 03:22:58 +0900 (JST) Message-ID: <379B55C3.433B71B0@newsguy.com> Date: Mon, 26 Jul 1999 03:21:55 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? References: <19990726040233.E7349@welearn.com.au> 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 Sue Blake wrote: > > Nobody seems to be confident about the answer to my post to -questions. > Below is the only public answer. It is typical of many private answers > I received from otherwise knowledgeable people willing to make a > partial educated guess but not willing to expose their ignorance > publicly. They're all keen to know whatever I can find out :-) :-) > On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: > > In article <19990719212431.D300@welearn.com.au>, > > Sue Blake wrote: > > : Could someone tell me what is a sandbox, what does it do, how does it > > : work, how do I use it, or where is it documented? > > : named(8) and security(8) seem to assume one already knows. > > > > It's a generic term. It refers to a restricted environment in > > which something is to be done. Exactly how a sandbox is > > implemented depends on the specific application. Without having read the references in the files you mentioned, here is my own take on sandbox. In some firewall books I have read, sandbox is used to refer to a machine connected to the net in a "protected" way. Basically, all packets to and from that machine go through a firewall. The machine, though inside the firewall, is isolated from the rest of the internal network. The sandbox can then be used to provide services in a more or less secure way. It cannot threat the internal network, because it can reach it even if breached, and it is not as exposed as it would be outside the firewall. If *think* this definition was given in the book by the TIS people, but, alas, I haven't read about firewalls in two years, and my firewall books are 12 thousand km away. And notice, too, that I'm *not* refering to the hacker's trap, whose name I can't recall right now. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 11:37: 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 CBEE714BF2; Sun, 25 Jul 1999 11:37:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA41121; Sun, 25 Jul 1999 11:36:49 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jul 1999 11:36:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199907251836.LAA41121@apollo.backplane.com> To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? References: <19990726040233.E7349@welearn.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A sandbox is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to "play" inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a userid, for example. This is the definition used in the security and named man pages. Take the 'ntalk' service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox desiegned to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id. * A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. "/" for that process is this directory, not the real "/" of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A UNIX process is owned by a patricular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. -Matt Matthew Dillon :Hi clever people : :Nobody seems to be confident about the answer to my post to -questions. :Below is the only public answer. It is typical of many private answers :I received from otherwise knowledgeable people willing to make a :partial educated guess but not willing to expose their ignorance :publicly. They're all keen to know whatever I can find out :-) : :On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: :> In article <19990719212431.D300@welearn.com.au>, :> Sue Blake wrote: :> : Could someone tell me what is a sandbox, what does it do, how does it :> : work, how do I use it, or where is it documented? :> : named(8) and security(8) seem to assume one already knows. :> :> It's a generic term. It refers to a restricted environment in :> which something is to be done. Exactly how a sandbox is :> implemented depends on the specific application. : :As you see it is far from the complete 4-5 part answer I need. The :problem that I see is that our named.conf refers to this sandbox thing, :implies that it is actually the default method for BIND in FreeBSD (I :don't think it is though), and directs the user to man pages which :don't provide the necessary info to be able to confidently :(un)implement it. : :If nobody understands how this sandbox thing works, we should change :the named.conf that we supply. If somebody does, then they or someone :who they teach (me if really necessary) needs to document it so that :anyone seriously interested can figure it out on thier own (or at least :accept the defaults with confidence), and then change at least the :named.conf to point to that info. It sounds like a good idea, worth :giving people the resources to use it. : :(Email cc would be appreciated) : :-- : :Regards, : -*Sue*- : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 11:39:12 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 4129414BF2; Sun, 25 Jul 1999 11:38:26 -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 UAA63806; Sun, 25 Jul 1999 20:35:34 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907251835.UAA63806@gratis.grondar.za> To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? Date: Sun, 25 Jul 1999 20:35:20 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sue Blake wrote: > > Nobody seems to be confident about the answer to my post to -questions. > Below is the only public answer. It is typical of many private answers > I received from otherwise knowledgeable people willing to make a > partial educated guess but not willing to expose their ignorance > publicly. They're all keen to know whatever I can find out :-) The usual use of the term "sandbox" means "restricted environment". A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term "sandbox" in inetd.conf refers to a "su - ; chroot ; " environment (I think) so that cannot do any damage even if compromised. 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 Sun Jul 25 11:48:57 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 DD1BC15214; Sun, 25 Jul 1999 11:48:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA41278; Sun, 25 Jul 1999 11:46:56 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jul 1999 11:46:56 -0700 (PDT) From: Matthew Dillon Message-Id: <199907251846.LAA41278@apollo.backplane.com> To: Mark Murray Cc: Sue Blake , freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? References: <199907251835.UAA63806@gratis.grondar.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Speaking of jail() ... it might be a good idea to change the int32 being passed for the IP address to something a little more portable or it will not be useable when IPV6 goes in. Perhaps a pointer and a length instead of an int32, or even pass a structural pointer and a length (which can remain backwards compatible by checking the passed length). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 12:57: 8 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 8823A14C15 for ; Sun, 25 Jul 1999 12:56:58 -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 NAA62053; Sun, 25 Jul 1999 13:55: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 NAA35141; Sun, 25 Jul 1999 13:56:24 -0600 (MDT) Message-Id: <199907251956.NAA35141@harmony.village.org> To: "David E. Cross" Subject: Re: mbuf leakage Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 24 Jul 1999 00:05:18 EDT." <199907240405.AAA04539@cs.rpi.edu> References: <199907240405.AAA04539@cs.rpi.edu> Date: Sun, 25 Jul 1999 13:56:24 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907240405.AAA04539@cs.rpi.edu> "David E. Cross" writes: : Any-who, is there a way I can get a look at the raw mbuf/mbuf-clusters? : I have a feeling that seeing the data in them would speak volumes of : information. Preferably a way to see them without DDB/panic would be ideal. I've also seen problems with amd with huge links on 3.2 Release.... The whole system hangs until the link is done, then it starts working again. Can't help you with looking at the mbuf stuff, however. 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 25 12:59:53 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 F3D2114D9E for ; Sun, 25 Jul 1999 12:59:46 -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 NAA62064; Sun, 25 Jul 1999 13:59:43 -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 OAA35177; Sun, 25 Jul 1999 14:00:35 -0600 (MDT) Message-Id: <199907252000.OAA35177@harmony.village.org> To: chris@calldei.com Subject: Re: Mentioning RFC numbers in /etc/services Cc: Sheldon Hearn , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 24 Jul 1999 08:25:55 CDT." <19990724082555.A40344@holly.dyndns.org> References: <19990724082555.A40344@holly.dyndns.org> <56928.932821629@axl.noc.iafrica.com> Date: Sun, 25 Jul 1999 14:00:34 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990724082555.A40344@holly.dyndns.org> Chris Costello writes: : Are you going to be listing all the RFCs that apply? For : example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. DNS is also 1123 and a few others in the 2xxx range. Then again, a lot are 1123 :-) NNTP should just list 977, however, since it obsoletes earlier RFCs. The net news format RFC isn't relevant to /etc/services, much like RFC 822 wouldn't be the one to list for smtp (since it describes the message format, not the protocol for smtp). For smtp, one of the RFCs would be RFC 823. (I just hope that I've not accidentally reversed those two RFCs). 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 25 16:21:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id 32E8114D12; Sun, 25 Jul 1999 16:21:01 -0700 (PDT) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) id QAA17211; Sun, 25 Jul 1999 16:18:40 -0700 (PDT) Message-ID: <19990725161839.A16546@best.com> Date: Sun, 25 Jul 1999 16:18:39 -0700 From: "Jan B. Koum " To: Matthew Dillon , Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? Mail-Followup-To: Matthew Dillon , Sue Blake , freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG References: <19990726040233.E7349@welearn.com.au> <199907251836.LAA41121@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199907251836.LAA41121@apollo.backplane.com>; from Matthew Dillon on Sun, Jul 25, 1999 at 11:36:49AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon wrote: > A sandbox is a security term. It can mean two things: > [...] > > UNIX implements two core sanboxes. One is at the process level, and one > is at the userid level. > > Every UNIX process is completely firewalled off from every other UNIX > process. One process can modify the address space of another. This is ^^^^ Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 16:21:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from snafu.adept.org (adsl-63-193-112-19.dsl.snfc21.pacbell.net [63.193.112.19]) by hub.freebsd.org (Postfix) with ESMTP id 3ACE515266; Sun, 25 Jul 1999 16:21:42 -0700 (PDT) (envelope-from mike@snafu.adept.org) Received: from localhost (mike@localhost) by snafu.adept.org (8.9.3/8.9.3) with ESMTP id QAA24805; Sun, 25 Jul 1999 16:20:50 -0700 (PDT) Date: Sun, 25 Jul 1999 16:20:50 -0700 (PDT) From: Mike Hoskins To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? In-Reply-To: <19990726040233.E7349@welearn.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 Mon, 26 Jul 1999, Sue Blake wrote: > If nobody understands how this sandbox thing works, we should change > the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 17:20:33 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 9BA3714CCD for ; Sun, 25 Jul 1999 17:20:19 -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 XAA80192; Sun, 25 Jul 1999 23:08:17 +0100 (BST) (envelope-from nik) Date: Sun, 25 Jul 1999 23:08:14 +0100 From: Nik Clayton To: "Ronald G. Minnich" Cc: hackers@FreeBSD.ORG Subject: Re: InterMezzo: Project for kernel/FS hackers Message-ID: <19990725230814.A78813@catkin.nothing-going-on.org> References: <19990722211946.A31641@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Ronald G. Minnich on Thu, Jul 22, 1999 at 04:47:15PM -0600 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 22, 1999 at 04:47:15PM -0600, Ronald G. Minnich wrote: > I'm working with intermezzo now. It's interesting. > > Note that the VFS is quite simple, and defines a simple kernel-user > channel which maps VFS ops to requests on an IPC channel. The > possibilities are endless ... > > A freebsd port would be nice. Maybe you could use v9fs as a starting > point. Ah, there's that "you" word again. Had everything gone to plan a few years ago, I'd have used FreeBSD to kickstart my Unix FS knowledge, and might be in a position to do that. Somehow I got sidetracked on to the Doc. Proj., which is kind of where I've stayed :-) 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 Sun Jul 25 17:27:43 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 6D2A214D3E for ; Sun, 25 Jul 1999 17:27:40 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id BAA88652; Mon, 26 Jul 1999 01:27:34 +0100 (BST) (envelope-from joe) Date: Mon, 26 Jul 1999 01:27:34 +0100 From: Josef Karthauser To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: VMWare plug/quickie tests. Message-ID: <19990726012734.A88472@pavilion.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Jaye Mathisen on Thu, Jul 15, 1999 at 07:14:03PM -0700 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 Thu, Jul 15, 1999 at 07:14:03PM -0700, Jaye Mathisen wrote: > > > I could grow to like it. > I just wish that it was the other way around. I'd actually run NT if I could get it in a VMWare compartment under FreeBSD. Until that happens, I might just have to be content with slagging it off, NT that is, not VMWare ;b. 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 Sun Jul 25 18:55:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id CC9B315258 for ; Sun, 25 Jul 1999 18:55:26 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3BD931E015; Sun, 25 Jul 1999 21:54:44 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA10573; Sun, 25 Jul 1999 21:54:43 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA18221; Sun, 25 Jul 1999 18:54:42 -0700 (PDT) Message-Id: <199907260154.SAA18221@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dillon@apollo.backplane.com Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c Cc: papezik@pvt.net, hackers@freebsd.org References: <37976C03.A4A797A7@pvt.net> <199907222056.NAA87639@apollo.backplane.com> Date: Sun, 25 Jul 1999 18:54:42 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think committing this would be beneficial. Would someone w/ commit > privs care to review and then commit this bit? I wrote it in rev 1.41 and gave it to the squid folks; it turned out to cause X to fail in unexplained ways so we reverted it. Then I added PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem. Let's please not put the hack back in; if PRUS_MORETOCOME is broken let's fix it instead. Is this an observed problem on recent FreeBSD versions, or just something read in the Squid FAQ? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 19:15:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 1FF1514BE5 for ; Sun, 25 Jul 1999 19:15:46 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3E0381E028; Sun, 25 Jul 1999 22:14:29 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA10974; Sun, 25 Jul 1999 22:14:25 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id TAA18397; Sun, 25 Jul 1999 19:14:24 -0700 (PDT) Message-Id: <199907260214.TAA18397@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mjung@npc.net Subject: Re: > arpresolve: can't allocate llinfo for 255.255.255.0rt Cc: freebsd-hackers@freebsd.org Date: Sun, 25 Jul 1999 19:14:24 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Can anyone explain how or where the "199.15.32&0xc70f22" entry could >have come from? I've been unable to remove it ... Have you tried route -delete 199.15.32.0 -netmask 199.15.34.0? (I'm guessing at the .0 part; it got truncated. "netstat -nrA" might help figure out what it really is) (I can't explain where it came from, other than maybe an oddly typo'd command; maybe a "route add" instead of an "ifconfig"?) Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 19:21:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id A457514BE5 for ; Sun, 25 Jul 1999 19:21:37 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id TAA14476; Sun, 25 Jul 1999 19:21:25 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379BC627.4A370FB2@gorean.org> Date: Sun, 25 Jul 1999 19:21:27 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: wd0 DMA errors] References: <62305.932926103@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > > > No answer on -current, any help appreciated. > > We're probably all sitting here thinking "I'm sure this was asked and > answered recently. He can read his CURRENT mail like the rest of us." I have indeed read my -current mail. Several bugs in the PCI and DMA code have been mentioned in the past week, but frankly I don't have enough expertise in either to know for sure that the bugs mentioned would produce the error messages I saw. A simple, "yes, those were the bugs fixed recently" is all that was needed. Thank you, 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 25 20: 4:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from snowflake.apdata.com.au (app3022-2.gw.connect.com.au [203.63.119.4]) by hub.freebsd.org (Postfix) with ESMTP id B0F6B14FB2 for ; Sun, 25 Jul 1999 20:04:09 -0700 (PDT) (envelope-from kirk@apdata.com.au) Received: from apdata.com.au (arial.apdata.com.au [192.168.255.26]) by snowflake.apdata.com.au (Postfix) with ESMTP id D009B76260 for ; Mon, 26 Jul 1999 12:34:07 +0930 (CST) Message-ID: <379BD029.23B1D995@apdata.com.au> Date: Mon, 26 Jul 1999 12:34:09 +0930 From: Kirk McDonald X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Wavelan-WavepointII Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I am wondering if anyone has had success running bridging only between a wavelan IEEE802.11 in a BSD machine and a WavepointII using an IEEE802.11 card. I have had great succes using purely wavelan/BSD. Kirk McDonald To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 20: 9: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 8731B1503A for ; Sun, 25 Jul 1999 20:09:02 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id UAA14588; Sun, 25 Jul 1999 20:08:56 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379BD149.19255E4@gorean.org> Date: Sun, 25 Jul 1999 20:08:57 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Poy , hackers@FreeBSD.ORG Subject: Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vincent Poy wrote: > > On Thu, 22 Jul 1999, Doug wrote: > > > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > > > Greetings everyone, > > > > > > What are the current good motherboards for FreeBSD for the pentium > > > II and III? I know on the Pentium, it was the ASUS board but for the > > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > > it matter if it's Slot 1 or PPGA based? Thanks. > > > > At work we're having good results with an Intel N440BX > > motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It > > also has the ability to redirect all console output (like boot/bios > > messages, etc.) to a serial console. It comes with a built in Etherexpress > > Pro 100+ as well. > > Cool... I thought the Intel motherboards weren't that good > compared to other brands.. Hrrmm... what about them would be "not good," and how would I test it? I don't know enough about SMP hardware to know what to compare, but I do know that these are working fine for us, and at the speed the cpu's are running at I'm not sure that a few percentage points difference would be noticable. Also, the serial console option got me big points with the boss, since we have all sorts of remote console stuff set up in the office and the more that can be seen while booting a troubled box the better. > > I have an Asus P2B at home that I've run my Celeron 300A > > overclocked to 450 since the first of the year with no problems (and BIG > > fans). > > Hmmm, what kinda fans did you use and where can one get those? Is > the 300A overclocked as fast as a regular PII 450Mhz? I got the fans from the store that sold me the CPU. It's a double fan with a big heat sink in the middle. http://www.thechipmerchant.com/ should do you up. As for speed, as far as I can tell on the few benchmarks I've run, yes, it's just as fast. Some things are actually faster since the onboard cache for the 300A runs at full speed. The old celerons without cache are dogs though, even if you do overclock them. If RC5 is any indication I can do 1.2Mkeys per second when there is no other load on the system. HTH, 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 25 20:47:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from exit-gw.power.net (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 7F09814FF6 for ; Sun, 25 Jul 1999 20:47:31 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.8.8/8.8.8) with ESMTP id UAA06007 for ; Sun, 25 Jul 1999 20:38:55 -0700 (PDT) (envelope-from frank@tinker.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.2/8.9.1) id UAA01435 for freebsd-hackers@freebsd.org; Sun, 25 Jul 1999 20:38:54 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <199907260338.UAA01435@realtime.exit.com> Subject: Upgrading from 2.2.8 to 3.2-stable... To: freebsd-hackers@freebsd.org Date: Sun, 25 Jul 1999 20:38:54 -0700 (PDT) Reply-To: frank@exit.com 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 Apologies if this appears twice. The first attempt didn't appear to work. Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar frank@exit.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 25 21:23:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 1D1171526D for ; Sun, 25 Jul 1999 21:23:28 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id VAA81110; Sun, 25 Jul 1999 21:22:14 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sun, 25 Jul 1999 21:22:14 -0700 (PDT) From: Vincent Poy To: Doug Cc: hackers@FreeBSD.ORG Subject: Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's In-Reply-To: <379BD149.19255E4@gorean.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, 25 Jul 1999, Doug wrote: > Vincent Poy wrote: > > > > On Thu, 22 Jul 1999, Doug wrote: > > > > > On Wed, 21 Jul 1999, Vincent Poy wrote: > > > > > > > Greetings everyone, > > > > > > > > What are the current good motherboards for FreeBSD for the pentium > > > > II and III? I know on the Pentium, it was the ASUS board but for the > > > > PII/PIII, is the Abit the better board? Also, I was wondering what is the > > > > fastest Celeron chip that can be overclocked to run at 100Mhz FSB? Does > > > > it matter if it's Slot 1 or PPGA based? Thanks. > > > > > > At work we're having good results with an Intel N440BX > > > motherboard. It's a dual cpu board, running 2 PIII 500's like a champ. It > > > also has the ability to redirect all console output (like boot/bios > > > messages, etc.) to a serial console. It comes with a built in Etherexpress > > > Pro 100+ as well. > > > > Cool... I thought the Intel motherboards weren't that good > > compared to other brands.. > > Hrrmm... what about them would be "not good," and how would I test it? I > don't know enough about SMP hardware to know what to compare, but I do know > that these are working fine for us, and at the speed the cpu's are running > at I'm not sure that a few percentage points difference would be noticable. > Also, the serial console option got me big points with the boss, since we > have all sorts of remote console stuff set up in the office and the more > that can be seen while booting a troubled box the better. I am not sure about the exact problems but I remember that Rodney Grimes of FreeBSD Inc. recommended the ASUS boards over the Intel boards for a reason. How does the serial console option work exactly? > > > I have an Asus P2B at home that I've run my Celeron 300A > > > overclocked to 450 since the first of the year with no problems (and BIG > > > fans). > > > > Hmmm, what kinda fans did you use and where can one get those? Is > > the 300A overclocked as fast as a regular PII 450Mhz? > > I got the fans from the store that sold me the CPU. It's a double fan with > a big heat sink in the middle. http://www.thechipmerchant.com/ should do > you up. As for speed, as far as I can tell on the few benchmarks I've run, > yes, it's just as fast. Some things are actually faster since the onboard > cache for the 300A runs at full speed. The old celerons without cache are > dogs though, even if you do overclock them. If RC5 is any indication I can > do 1.2Mkeys per second when there is no other load on the system. Cool... We're actually running a Celeron 266 that is overclocked to 400 (4.0x100Mhz) and it's fast but I wonder what level of a PII is it comparable to since it doesn't have cache. Does Chip Merchant let you specify a date for the CPU's so you don't get anything earlier than that date? Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 21:52:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C8D291526D; Sun, 25 Jul 1999 21:52:41 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA10559; Sun, 25 Jul 1999 21:50:55 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Date: Sun, 25 Jul 1999 21:50:55 -0700 (PDT) From: Message-Id: <199907260450.VAA10559@freefall.freebsd.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams Cc: freebsd-hackers@freebsd.org, jkoshy@freebsd.org Subject: Re: deny ktrace without read permissions? In-Reply-To: Your message of "Sat, 24 Jul 1999 11:24:39 CST." <199907241724.LAA13835@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jk> The intent of this change is to prevent a user from seeing how an jk> executable with '--x--x--x' perms works by ktrace'ing its execution. jk> My question to -hackers is: is this a useful semantic? Would it break jk> anything if added? nw> If we make kernel auditing based upon KTRACE (which may or may not nw> happen), this is not a useful change since we need to be able to 'audit' nw> system calls regardless of whether or not KTRACE is used. If this kind This particular change should not affect the future auditing tool. The [execve] system call will still be logged as having been attempted; the control flow remains the same as for the current ``no execute perms'' case but with a stricter check if KTRACE'ing is on for the process. nw> If security is an issue, KTRACE shouldn't be in the system. Yes, but /if/ KTRACE is present, today's code allows you to bypass the lack of read permissions on an executable. That shouldn't be allowed. The current behaviour could be regarded as a security hole actually :). Part of the confusion comes from the meaning of the 'x' bit when KTRACE'ing is also permitted. Ordinarily the 'x' bit determines if a user can execute a file. But should execute permissions also imply the ability to trace the execution of the process? If so, the value of a permission mask like '--x--x--x' is weakened because although you cannot read the file, you can 'see inside' it, indirectly. The PR proposes (and the patch given earlier implements) tighter security on the premise that security in the presence of KTRACE should be at least as tight as without KTRACE. It achieves this by requiring read permissions on an executable before it can be KTRACE'd. Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 21:59:43 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 DF14415291; Sun, 25 Jul 1999 21:59:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA42863; Sun, 25 Jul 1999 21:59:33 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jul 1999 21:59:33 -0700 (PDT) From: Matthew Dillon Message-Id: <199907260459.VAA42863@apollo.backplane.com> To: Mike Hoskins Cc: Sue Blake , freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Understanding a sandbox only requires the ability to read on the part of :the user (something anyone in charge of named administration has hopefully :learned, else they don't need to be administrating anything). : :As for the current named.conf format... I agree that it should be :changed. Rc.conf currently references the fact that 'it may be possible :to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a :sandbox'. Saying FreeBSD does something one place while saying it may be :possible to do it in another is... silly. : :The actual use is up to the administrator, so it seems logical to have :named.conf examples for sandbox and non-sandbox configs. : :Mike Hoskins : The sandbox code for bind is not a novice exercise, which is why it is commented out by default. This is mainly because bind insists on doing things which make sandboxing difficult - you can't HUP it, for example, or bring interfaces down and up. The comment in the sample named.conf is wrong, it isn't on by default. Bind has a number of design faults that make it difficult to run outside of root. It would probably work in a jail(), though, if someone wants to work on that. The sandbox for the comsat and ntalk daemons does work and is on by default. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 22:15:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id 095F114CC2; Sun, 25 Jul 1999 22:15:36 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id WAA08897; Sun, 25 Jul 1999 22:13:33 -0700 (PDT) (envelope-from sef) Date: Sun, 25 Jul 1999 22:13:33 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199907260513.WAA08897@kithrup.com> To: jkoshy@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Reply-To: hackers@FreeBSD.ORG Subject: Re: deny ktrace without read permissions? References: Your message of "Sat, 24 Jul 1999 11:24:39 CST." <199907241724.LAA13835@mt.sri.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907260450.VAA10559.kithrup.freebsd.hackers@freefall.freebsd.org> you write: >Yes, but /if/ KTRACE is present, today's code allows you to bypass >the lack of read permissions on an executable. That shouldn't be >allowed. The current behaviour could be regarded as a security >hole actually :). No more so than core dumps do. I vote strongly against this change. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 22:16: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 8DC2E1528A for ; Sun, 25 Jul 1999 22:16:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA43000; Sun, 25 Jul 1999 22:15:29 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jul 1999 22:15:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907260515.WAA43000@apollo.backplane.com> To: Bill Fenner Cc: papezik@pvt.net, hackers@FreeBSD.ORG Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c References: <37976C03.A4A797A7@pvt.net> <199907222056.NAA87639@apollo.backplane.com> <199907260154.SAA18221@windsor.research.att.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I wrote it in rev 1.41 and gave it to the squid folks; it turned out :to cause X to fail in unexplained ways so we reverted it. Then I added :PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem. :Let's please not put the hack back in; if PRUS_MORETOCOME is broken :let's fix it instead. : :Is this an observed problem on recent FreeBSD versions, or just something :read in the Squid FAQ? : : Bill Looking at the PRUS_MORETOCOME code again I think it does solve this particular problem, albeit in a somewhat more complex fashion. I can see why the original patch failed - it set the atomic flag unconditionally and blew two cases in the loop. In general, I think it would have been cleaner to solve this sort of thing at the higher level. That is, correcting the original patch rather then introducing the comparitively greater complexity of PRUS_MORETOCOME. But since we would no longer be fixing a 'bug' it's up to you as the author to decide which solution you want. -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 Sun Jul 25 22:41:16 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 50F4E15291; Sun, 25 Jul 1999 22:41:06 -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 118dVZ-000Gs4-00; Mon, 26 Jul 1999 07:41:05 +0200 From: Sheldon Hearn To: jkoshy@FreeBSD.org Cc: Nate Williams , freebsd-hackers@freebsd.org Subject: Re: deny ktrace without read permissions? In-reply-to: Your message of "Sun, 25 Jul 1999 21:50:55 MST." <199907260450.VAA10559@freefall.freebsd.org> Date: Mon, 26 Jul 1999 07:41:05 +0200 Message-ID: <64855.932967665@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 25 Jul 1999 21:50:55 MST, jkoshy@FreeBSD.org wrote: > Yes, but /if/ KTRACE is present, today's code allows you to bypass > the lack of read permissions on an executable. That shouldn't be > allowed. The current behaviour could be regarded as a security > hole actually :). This doesn't look right. If I can execute a binary, I can have the system allocate memory to me and but the binary image in it. It's my memory. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 22:46:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0743A14C36; Sun, 25 Jul 1999 22:46:27 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id WAA13646; Sun, 25 Jul 1999 22:44:49 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Date: Sun, 25 Jul 1999 22:44:49 -0700 (PDT) From: Message-Id: <199907260544.WAA13646@freefall.freebsd.org> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Cc: sef@freebsd.org, jkoshy@FreeBSD.org Subject: Re: deny ktrace without read permissions? In-Reply-To: Your message of "Sun, 25 Jul 1999 22:13:33 MST." <199907260513.WAA08897@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG jk> Yes, but /if/ KTRACE is present, today's code allows you to bypass jk>the lack of read permissions on an executable. That shouldn't be jk>allowed. The current behaviour could be regarded as a security jk>hole actually :). sef> No more so than core dumps do. Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. sef> I vote strongly against this change. Noted, thanks. I will summarize the result of the discussion in a followup to kern/3546. Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 22:51:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (Postfix) with ESMTP id DF56D14C36; Sun, 25 Jul 1999 22:51:08 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id WAA10899; Sun, 25 Jul 1999 22:48:52 -0700 (PDT) (envelope-from sef) Date: Sun, 25 Jul 1999 22:48:52 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199907260548.WAA10899@kithrup.com> To: jkoshy@freebsd.org Subject: Re: deny ktrace without read permissions? Cc: hackers@freebsd.org Reply-To: hackers@freebsd.org In-Reply-To: <199907260544.WAA13646@freefall.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Yes, but an application can protect itself from an inadvertent core dump. >It can't (today) against being ktrace'd. You'd better fix ptrace and procfs then. Of course, that breaks everything that has always been true, but, hey, it's better to be wrong than right, I guess? if you care about security, you made the damned executable suid or sgid. Then ktrace, ptrace, truss, and core dumps do not work. Even if it simply does setuid(getruid()). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 25 23:20: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 0EEB0152AA for ; Sun, 25 Jul 1999 23:20:37 -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 AAA63222; Mon, 26 Jul 1999 00:18:59 -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 AAA37638; Mon, 26 Jul 1999 00:19:47 -0600 (MDT) Message-Id: <199907260619.AAA37638@harmony.village.org> To: frank@exit.com Subject: Re: Upgrading from 2.2.8 to 3.2-stable... Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 25 Jul 1999 20:38:54 PDT." <199907260338.UAA01435@realtime.exit.com> References: <199907260338.UAA01435@realtime.exit.com> Date: Mon, 26 Jul 1999 00:19:47 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907260338.UAA01435@realtime.exit.com> Frank Mayhar writes: : I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets : to libmytinfo. That's it. : : Any help or pointers would be greatly appreciated. Thanks. You might try to get a hold of 3.1 release, do a make upgrade to that, and then upgrade to 3.2-stable from there. As time marches forward, the make upgrade target tends to decay. I'm not saying that this isn't a bug, but might be more expedient than tracking down the actual problem. 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 25 23:21:11 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 99ED2152A6; Sun, 25 Jul 1999 23:21:08 -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 AAA63232; Mon, 26 Jul 1999 00:20:19 -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 AAA37661; Mon, 26 Jul 1999 00:21:15 -0600 (MDT) Message-Id: <199907260621.AAA37661@harmony.village.org> To: Sheldon Hearn Subject: Re: deny ktrace without read permissions? Cc: jkoshy@FreeBSD.ORG, Nate Williams , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 26 Jul 1999 07:41:05 +0200." <64855.932967665@axl.noc.iafrica.com> References: <64855.932967665@axl.noc.iafrica.com> Date: Mon, 26 Jul 1999 00:21:15 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <64855.932967665@axl.noc.iafrica.com> Sheldon Hearn writes: : This doesn't look right. If I can execute a binary, I can have the : system allocate memory to me and but the binary image in it. It's my : memory. :-) Also, one can use a custom libc to get around the readonly ness, since functions in libc can access the entire memory space (at least on intel). 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 25 23:23:26 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 63BD114ECB for ; Sun, 25 Jul 1999 23:23:20 -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 AAA63236 for ; Mon, 26 Jul 1999 00:22:53 -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 AAA37680 for ; Mon, 26 Jul 1999 00:23:50 -0600 (MDT) Message-Id: <199907260623.AAA37680@harmony.village.org> To: hackers@FreeBSD.ORG Subject: Re: deny ktrace without read permissions? In-reply-to: Your message of "Sun, 25 Jul 1999 22:48:52 PDT." <199907260548.WAA10899@kithrup.com> References: <199907260548.WAA10899@kithrup.com> Date: Mon, 26 Jul 1999 00:23:50 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907260548.WAA10899@kithrup.com> Sean Eric Fagan writes: : if you care about security, you made the damned executable suid or : sgid. Then ktrace, ptrace, truss, and core dumps do not work. Even : if it simply does setuid(getruid()). It also disables attacking the contents of the executable by LD_LIBRARY_PATH.... 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 26 1:25: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 42DC115159 for ; Mon, 26 Jul 1999 01:25:18 -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 118g4S-000HHr-00; Mon, 26 Jul 1999 10:25:16 +0200 From: Sheldon Hearn To: hackers@freebsd.org Cc: dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: file(1) Magdir candidate: wintendo Date: Mon, 26 Jul 1999 10:25:16 +0200 Message-ID: <66454.932977516@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I've had some interesting comments from David Bushong, motivating for inclusion of his Magdir candidate on PR 12554. He makes a strong case for a bloated file(1) Magdir. The only thing we're battling with is a filename for his submission. Just because a bloated file(1) magic database is good, doesn't mean we want a zillion files in the Magdir source, though. So I propose a new file wintendo, for all gaming file formats used on the MS Windows platform. Sensible objections? 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 26 3:32:20 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 469491517C; Mon, 26 Jul 1999 03:32:14 -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 GAA09984; Mon, 26 Jul 1999 06:31:14 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 26 Jul 1999 06:31:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: jkoshy@FreeBSD.org Cc: hackers@FreeBSD.org, sef@FreeBSD.org Subject: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) In-Reply-To: <199907260544.WAA13646@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another cool attack on this mechanism is if the binary uses shared libraries: modify LD_LIBRARY_PATH so that its favorite shared library is your own version of the library, that proceeds to dump the entire application to disk when executed. The challenge of adding additional sandbox/restrictions outside of the traditional uid boundaries in UNIX is challenging. The number of ways to influence a programs execution is quite sizable... On Sun, 25 Jul 1999 jkoshy@FreeBSD.org wrote: > > > jk> Yes, but /if/ KTRACE is present, today's code allows you to bypass > jk>the lack of read permissions on an executable. That shouldn't be > jk>allowed. The current behaviour could be regarded as a security > jk>hole actually :). > > sef> No more so than core dumps do. > > Yes, but an application can protect itself from an inadvertent core dump. > It can't (today) against being ktrace'd. > > sef> I vote strongly against this change. > > Noted, thanks. > > I will summarize the result of the discussion in a followup to kern/3546. > > Regards, > Koshy > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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 Mon Jul 26 3:40:36 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 0D2F314A09; Mon, 26 Jul 1999 03:40:33 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip234.houston3.tx.pub-ip.psi.net [38.12.169.234]) by leap.innerx.net (Postfix) with ESMTP id 0FCCD3708F; Mon, 26 Jul 1999 06:39:50 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id FAA81321; Mon, 26 Jul 1999 05:40:38 -0500 (CDT) (envelope-from chris) Date: Mon, 26 Jul 1999 05:40:37 -0500 From: Chris Costello To: Robert Watson Cc: jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG, sef@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) Message-ID: <19990726054037.D79022@holly.dyndns.org> Reply-To: chris@calldei.com References: <199907260544.WAA13646@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Robert Watson on Mon, Jul 26, 1999 at 06:31:14AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999, Robert Watson wrote: > > Another cool attack on this mechanism is if the binary uses shared > libraries: modify LD_LIBRARY_PATH so that its favorite shared library is > your own version of the library, that proceeds to dump the entire > application to disk when executed. > > The challenge of adding additional sandbox/restrictions outside of the > traditional uid boundaries in UNIX is challenging. The number of ways to > influence a programs execution is quite sizable... Perhaps an option when compiling the linker code to select whether to avoid or ignore LD_LIBRARY_PATH if a shared library it's looking for is in the default path. Another problem I've heard of in another OS is that if a suid root binary is dynamically linked, you could set LD_LIBRARY_PATH and make your own little libc which would, say, exec /bin/sh on something like printf. Options for both of those (or defaults) might be something to look into. Or is that second one fixed in FreeBSD? -- |Chris Costello |[Unix] is not necessarily evil, like OS/2. - Peter Norton `---------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 4: 1: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 720DA14BEE for ; Mon, 26 Jul 1999 04:01:20 -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 MAA05096; Mon, 26 Jul 1999 12:59:58 +0200 (CEST) (envelope-from des) To: Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <56928.932821629@axl.noc.iafrica.com> From: Dag-Erling Smorgrav Date: 26 Jul 1999 12:59:57 +0200 In-Reply-To: Sheldon Hearn's message of "Sat, 24 Jul 1999 15:07:09 +0200" Message-ID: Lines: 114 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > I plan to mention in the comments for each service in /etc/services, the > latest RFC describing the service. Good idea. > I also plan to mention in the manpage > for services(5) the e-mail address to which requests for "How do I get > the RFCs" should be sent. Don't. Instead, put it in a separate rfc(7) man page which you refer to in the services(5) man page. While you're at it, search all the other man pages for the string "RFC" and add a reference to rfc(7) to every page that lists an RFC as reference (e.g. fetch(3)). des@des ~/yes% current -l RFC | grep '\.[0-9]' src/contrib/amd/scripts/expn.1 src/contrib/bind/doc/man/dig.1 src/contrib/bind/doc/man/dnskeygen.1 src/contrib/bind/doc/man/getnetent.3 src/contrib/bind/doc/man/hostname.7 src/contrib/bind/doc/man/mailaddr.7 src/contrib/bind/doc/man/named-xfer.8 src/contrib/bind/doc/man/named.8 src/contrib/bind/doc/man/nslookup.8 src/contrib/bind/doc/man/resolver.3 src/contrib/bind/doc/misc/FAQ.1of2 src/contrib/bind/doc/misc/FAQ.2of2 src/contrib/egcs/libio/dbz/dbz.1 src/contrib/egcs/libio/dbz/dbz.3z src/contrib/ipfilter/ipsend/ipresend.1 src/contrib/ipfilter/ipsend/ipsend.5 src/contrib/ipfilter/man/ipftest.1 src/contrib/isc-dhcp/client/dhclient.conf.5 src/contrib/isc-dhcp/client/dhclient.leases.5 src/contrib/isc-dhcp/common/dhcp-options.5 src/contrib/libpam/doc/man/pam.8 src/contrib/libpam/doc/man/pam_authenticate.3 src/contrib/libpam/doc/man/pam_chauthtok.3 src/contrib/libpam/doc/man/pam_fail_delay.3 src/contrib/libpam/doc/man/pam_open_session.3 src/contrib/libpam/doc/man/pam_setcred.3 src/contrib/libpam/doc/man/pam_start.3 src/contrib/libpam/doc/man/pam_strerror.3 src/contrib/libpam/doc/specs/rfc86.0.txt src/contrib/opie/opie.4 src/contrib/opie/opieftpd.8 src/contrib/patch/patch.1 src/contrib/perl5/Changes5.004 src/contrib/sendmail/src/sendmail.8 src/contrib/tcp_wrappers/hosts_access.5 src/contrib/tcp_wrappers/hosts_options.5 src/contrib/tcp_wrappers/tcpd.8 src/contrib/tcpdump/tcpdump.1 src/crypto/telnet/telnetd/telnetd.8 src/gnu/usr.bin/rcs/co/co.1 src/lib/libc/net/getnetent.3 src/lib/libc/net/resolver.3 src/lib/libc/rpc/rpc.3 src/lib/libc/rpc/rpc_secure.3 src/lib/libc/sys/rfork.2 src/lib/libc/xdr/xdr.3 src/lib/libfetch/fetch.3 src/lib/libmd/mdX.3 src/lib/libradius/libradius.3 src/lib/libradius/radius.conf.5 src/lib/libz/zlib.3 src/libexec/bootpd/bootpd.8 src/libexec/bootpd/bootptab.5 src/libexec/bootpd/tools/bootpef/bootpef.8 src/libexec/bootpd/tools/bootptest/bootptest.8 src/libexec/fingerd/fingerd.8 src/libexec/ftpd/ftpd.8 src/libexec/telnetd/telnetd.8 src/libexec/tftpd/tftpd.8 src/sbin/i386/cxconfig/cxconfig.8 src/sbin/md5/md5.1 src/sbin/mount_nfs/mount_nfs.8 src/sbin/mountd/exports.5 src/sbin/mountd/mountd.8 src/sbin/nfsd/nfsd.8 src/sbin/routed/routed.8 src/sbin/routed/rtquery/rtquery.8 src/sbin/spppcontrol/spppcontrol.8 src/share/examples/mdoc/example.1 src/share/examples/mdoc/example.3 src/share/man/man4/ifmib.4 src/share/man/man4/ip.4 src/share/man/man4/sppp.4 src/share/man/man4/tcp.4 src/share/man/man4/ttcp.4 src/share/man/man5/rc.conf.5 src/share/man/man7/mailaddr.7 src/share/man/man9/MD5.9 src/usr.bin/fetch/fetch.1 src/usr.bin/finger/finger.1 src/usr.bin/ftp/ftp.1 src/usr.bin/showmount/showmount.8 src/usr.bin/whois/whois.1 src/usr.sbin/arp/arp.4 src/usr.sbin/atm/atmarpd/atmarpd.8 src/usr.sbin/atm/scspd/scspd.8 src/usr.sbin/inetd/inetd.8 src/usr.sbin/mrouted/mrouted.8 src/usr.sbin/ppp/ppp.8 src/usr.sbin/pppd/pppd.8 src/usr.sbin/rarpd/rarpd.8 src/usr.sbin/rndcontrol/random.4 src/usr.sbin/xntpd/doc/xntpd.8 src/usr.sbin/xntpd/doc/xntpdc.8 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 Mon Jul 26 4:17:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 052FF14E35; Mon, 26 Jul 1999 04:17:23 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA43920; Mon, 26 Jul 1999 04:16:28 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Date: Mon, 26 Jul 1999 04:16:28 -0700 (PDT) From: Message-Id: <199907261116.EAA43920@freefall.freebsd.org> X-Mailer: exmh version 2.0.2 2/24/98 To: chris@calldei.com Cc: hackers@freebsd.org Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) In-Reply-To: Your message of "Mon, 26 Jul 1999 05:40:37 EST." <19990726054037.D79022@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG c> heard of in another OS is that if a suid root binary is c> dynamically linked, you could set LD_LIBRARY_PATH and make your c> own little libc which would, say, exec /bin/sh on something like c> printf. Options for both of those (or defaults) might be c> something to look into. Or is that second one fixed in FreeBSD? LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables in FreeBSD. Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 4:32: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.shellnet.co.uk (smtp.shellnet.co.uk [194.129.209.14]) by hub.freebsd.org (Postfix) with ESMTP id 58E6A15307 for ; Mon, 26 Jul 1999 04:31:56 -0700 (PDT) (envelope-from flec@flec.co.uk) Received: from STEVENF (eth2-fw1.bolton.shellnet.co.uk [194.129.209.8]) by smtp.shellnet.co.uk (8.9.3/8.9.1-shellnet.stevenf) with SMTP id MAA02458 for ; Mon, 26 Jul 1999 12:31:02 +0100 (BST) Posted-Date: Mon, 26 Jul 1999 12:31:02 +0100 (BST) From: flec@flec.co.uk (Steven Fletcher) To: freebsd-hackers@freebsd.org Subject: FTPd authentication with PAM/MySQL Date: Mon, 26 Jul 1999 11:31:02 GMT Message-ID: <379d4139.331989024@194.129.209.14> X-Mailer: Forte Agent 1.5/32.452 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all. I'm hoping this is a good place to post, if not, please correct me :). We're doing an entire system based on a MySQL database, that's currently able to handle SMTP/POP3 and the dialup system. The next stage I need to get going however is the web/FTPd system. I've seen the PAM modules/libraries/etc for MySQL and noticed that the =46TPD Makefile has a Kerberos PAM option, and was wondering if anyone knows of a way to get FTPd talking to MySQL... or if it would work at all? Thanks for any responses; Steven Fletcher - steven@shellnet.co.uk / flec@flec.co.uk Shellnet - http://www.shellnet.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 26 5:27:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 3167E1532A; Mon, 26 Jul 1999 05:27:18 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 26 Jul 1999 13:21:41 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PJ2VDVTR; Mon, 26 Jul 1999 13:21:40 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 118jl7-000KPL-00; Mon, 26 Jul 1999 13:21:33 +0100 Date: Mon, 26 Jul 1999 13:21:33 +0100 To: jkoshy@FreeBSD.org Cc: chris@calldei.com, hackers@freebsd.org Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) Message-Id: <19990726132132.B78403@voodoo.pandhm.co.uk> References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <199907261116.EAA43920@freefall.freebsd.org>; from jkoshy@FreeBSD.org on Mon, Jul 26, 1999 at 04:16:28AM -0700 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999 at 04:16:28AM -0700, jkoshy@FreeBSD.org wrote: > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables > in FreeBSD. But the point being made is that they are not ignored for executables which have no read access. And from there, read access can be gained, because at that point, you have code running in the process's address space. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 5:49:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from musashi.et.bocholt.fh-ge.de (reserve.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) by hub.freebsd.org (Postfix) with ESMTP id 1186715076 for ; Mon, 26 Jul 1999 05:49:23 -0700 (PDT) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Received: from localhost (localhost.et.bocholt.fh-ge.de [127.0.0.1]) by musashi.et.bocholt.fh-ge.de (8.9.3/8.9.3) with ESMTP id OAA00394; Mon, 26 Jul 1999 14:46:40 +0200 (CEST) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Message-Id: <199907261246.OAA00394@musashi.et.bocholt.fh-ge.de> To: Warner Losh Cc: John Reynolds~ , freebsd-hackers@FreeBSD.ORG Subject: Re: SURVEY: Sound cards that work under FreeBSD In-reply-to: Your message of "Fri, 23 Jul 1999 11:59:34 MDT." <199907231759.LAA20011@harmony.village.org> Date: Mon, 26 Jul 1999 14:46:40 +0200 From: Dirk GOUDERS Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Warner, > : The only line I had to add to my kernel config file was: > : > : device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 > : > : (This causes a message "pcm0 not found" to appear at boot time but > : just ignoring it seems to be o.k. - allthough I would prefer > : not to see it, at all.) > > device pcm0 > > does the trick for me. I think that will work in 3.2. > > -current fixes the problem with psm0 not found. > Thanks for the hint! I got rid of the error message :-) What I still don't understand is the following message at boot time: pcm1: using I/O space register mapping at 0xe400 I am wondering why there is a message concerning pcm1 instead of pcm0... Dirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 7:24:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 7ACB7152EC for ; Mon, 26 Jul 1999 07:24:47 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id B9C094CE30; Mon, 26 Jul 1999 10:23:33 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA21506; Mon, 26 Jul 1999 10:23:32 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA21226; Mon, 26 Jul 1999 07:23:30 -0700 (PDT) Message-Id: <199907261423.HAA21226@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dillon@apollo.backplane.com Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c Cc: papezik@pvt.net, hackers@freebsd.org References: <37976C03.A4A797A7@pvt.net> <199907222056.NAA87639@apollo.backplane.com> <199907260154.SAA18221@windsor.research.att.com> <199907260515.WAA43000@apollo.backplane.com> Date: Mon, 26 Jul 1999 07:23:30 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem of writes between 100 and 208 bytes; however, it solves the more general problem of the Nagle/MTU interaction even when the MTU is larger than a cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and remove PRUS_MORETOCOME) with writes of 2049-2256 bytes on the loopback interface. Same with LOCAL-domain sockets (with the uipc_usrreq.c patch I sent you). Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 7:30:30 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 835DD152EC for ; Mon, 26 Jul 1999 07:30:27 -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 IAA64192; Mon, 26 Jul 1999 08:30:12 -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 IAA39394; Mon, 26 Jul 1999 08:31:13 -0600 (MDT) Message-Id: <199907261431.IAA39394@harmony.village.org> To: Dirk GOUDERS Subject: Re: SURVEY: Sound cards that work under FreeBSD Cc: John Reynolds~ , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 26 Jul 1999 14:46:40 +0200." <199907261246.OAA00394@musashi.et.bocholt.fh-ge.de> References: <199907261246.OAA00394@musashi.et.bocholt.fh-ge.de> Date: Mon, 26 Jul 1999 08:31:13 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907261246.OAA00394@musashi.et.bocholt.fh-ge.de> Dirk GOUDERS writes: : What I still don't understand is the following message at boot time: : pcm1: using I/O space register mapping at 0xe400 : I am wondering why there is a message concerning pcm1 instead of pcm0... Quirks in config system in -stable cause it to usually attach to pcm1 when it is on the pci bus. It is nothing to worry about, just be aware that things like /dev/mixer, et al, need to point to the 1 unit rather than the 0 unit. 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 26 7:37:41 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 0989E152EC for ; Mon, 26 Jul 1999 07:37:39 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from n04.acl.lanl.gov (rminnich@n04.acl.lanl.gov [128.165.147.201]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id IAA269428 for ; Mon, 26 Jul 1999 08:37:39 -0600 (MDT) Received: from localhost (rminnich@localhost) by n04.acl.lanl.gov (8.8.8/8.8.8) with ESMTP id IAA215232 for ; Mon, 26 Jul 1999 08:37:38 -0600 (MDT) X-Authentication-Warning: n04.acl.lanl.gov: rminnich owned process doing -bs Date: Mon, 26 Jul 1999 08:37:38 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem question... In-Reply-To: <199907241312.PAA16516@dorifer.heim3.tu-clausthal.de> 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, 24 Jul 1999, Oliver Fromme wrote: > Ronald G. Minnich wrote in list.freebsd-hackers: > > Or, let's say I don't have "appropriate access" to /tmp. Pick some other > > place. I mount my file system there for my files. Now everyone who wants > > can look for these user mounts and walk them at will. My private stuff is > > quite public. > > You own it, so you can set the permission appropriately, > so nobody else can access it if you don't want that. not really. You're assuming that you, as a remote user, trust root. That's not a good assumption in a distributed computing environment. Someone you don't know can become root, root can become anyone, then become you, then the permissions are a moot point. You're also assuming that the owner of the system is willing to let you "own" a file in the local file system. They may let you be willing to use their cycles, in trade for some of your cycles, but they may be a lot less willing to let you see their filesystems. These are both faulty assumptions in distributed computing environments. People have killed distributed computing in some organizations for these reasons. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 7:42: 1 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 DBBFB14D87 for ; Mon, 26 Jul 1999 07:41:56 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from n04.acl.lanl.gov (rminnich@n04.acl.lanl.gov [128.165.147.201]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id IAA277116 for ; Mon, 26 Jul 1999 08:40:04 -0600 (MDT) Received: from localhost (rminnich@localhost) by n04.acl.lanl.gov (8.8.8/8.8.8) with ESMTP id IAA222924 for ; Mon, 26 Jul 1999 08:40:03 -0600 (MDT) X-Authentication-Warning: n04.acl.lanl.gov: rminnich owned process doing -bs Date: Mon, 26 Jul 1999 08:40:03 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem question... In-Reply-To: <199907250237.MAA21069@gizmo.internode.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, 25 Jul 1999, Mark Newton wrote: > "Appropriate access" includes the idea that you need to own the mountpoint > directory. If you have a system that's so badly run that arbitrary users > own /tmp, then I'd say user mounts are the least of your problems :-) True. But the fact is, if I can mount arbitrary filesystems into a name space seen by all processes, I can really cause some trouble. > Correct (unless you want your private stuff to be private, and chmod > your mountpoint's parent directory accordingly). People seem to be far more trusting of root than I am ... OK, I'll grant you can protect it from J. Random User. Why do people feel so willing to believe that chmod solves the world's problems? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 7:44:50 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 B89BF14F4D for ; Mon, 26 Jul 1999 07:44:46 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from n04.acl.lanl.gov (rminnich@n04.acl.lanl.gov [128.165.147.201]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id IAA259765 for ; Mon, 26 Jul 1999 08:44:15 -0600 (MDT) Received: from localhost (rminnich@localhost) by n04.acl.lanl.gov (8.8.8/8.8.8) with ESMTP id IAA226506 for ; Mon, 26 Jul 1999 08:44:14 -0600 (MDT) X-Authentication-Warning: n04.acl.lanl.gov: rminnich owned process doing -bs Date: Mon, 26 Jul 1999 08:44:14 -0600 From: "Ronald G. Minnich" To: freebsd-hackers@FreeBSD.org Subject: Re: Filesystem question... 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 Sun, 25 Jul 1999, Brian F. Feldman wrote: > On Sun, 25 Jul 1999, Mark Newton wrote: > > > Ronald G. Minnich wrote: > > > But thanks for the note. I just now realized that if I add a private name > > > space to v9fs (which is easy), and then turn on user mounts, user > > > processes can have private name spaces on freebsd! > > I can't wait to see the security problems that causes when setuid executables > > assume that they only need to be worrying about one filesystem namespace. > > :-) > There shouldn't be any problems if mount enabled the flags for nosuid/nodev > etc. if suser(p) != 0. Actually, i'd expect far fewer problems for the private mounts than for user mounts which modify the name space for all processes ... ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 8:13:29 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 56F2D14BE2 for ; Mon, 26 Jul 1999 08:13:09 -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 118mQs-000Irq-00; Mon, 26 Jul 1999 17:12:50 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "26 Jul 1999 12:59:57 +0200." Date: Mon, 26 Jul 1999 17:12:50 +0200 Message-ID: <72529.933001970@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26 Jul 1999 12:59:57 +0200, Dag-Erling Smorgrav wrote: > Don't. Instead, put it in a separate rfc(7) man page which you refer > to in the services(5) man page. Cool! :-) 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 26 8:43:44 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 55816150AB for ; Mon, 26 Jul 1999 08:43:41 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA78319; Mon, 26 Jul 1999 08:41:24 -0700 (PDT) Date: Mon, 26 Jul 1999 08:41:24 -0700 (PDT) From: David Wolfskill Message-Id: <199907261541.IAA78319@pau-amma.whistle.com> To: hackers@FreeBSD.ORG, nik@nothing-going-on.demon.co.uk Subject: Re: InterMezzo: Project for kernel/FS hackers In-Reply-To: <19990722211946.A31641@catkin.nothing-going-on.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Thu, 22 Jul 1999 21:19:46 +0100 >From: Nik Clayton >Has anyone had the chance to look at InterMezzo, website at > http://www.inter-mezzo.org/ >.... >Coda (which already has a FreeBSD port) also does this, as well as a few >other things. However, Coda is much more heavyweight than InterMezzo, >and therefore easier to understand -- in particular, Coda seems to have >(according to one of the Coda developers) a marked preference for >exporting whole filesystems, InterMezzo allows you to export individual >directory trees. >Anyway, if any aspiring kernel hackers are looking for a project, that >might be a fun one. The only implementation at the moment is for Linux. FWIW, I believe BayLISA is planning/hoping to have a speaker at one of our monthly meetings soon. (That's SF Bay area: http://www.baylisa.org/. Anyone in the area at the time is welcome to attend -- no charge. Meetings are on the 3rd Thursday of the month, starting at 7:30 PM. They've been held in Santa Clara recently, though that's in a state of flux at the moment.) From the discussion surrounding the matter, I gathered that InterMezzo was (in some sense) a continuation of the Coda work -- that (some of) the same folks are involved, among other things. 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 Mon Jul 26 9: 6:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BA40D14E1C; Mon, 26 Jul 1999 09:05:50 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA27598; Mon, 26 Jul 1999 10:04:55 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA18839; Mon, 26 Jul 1999 10:04:54 -0600 Date: Mon, 26 Jul 1999 10:04:54 -0600 Message-Id: <199907261604.KAA18839@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jkoshy@FreeBSD.org Cc: Nate Williams , freebsd-hackers@FreeBSD.org Subject: Re: deny ktrace without read permissions? In-Reply-To: <199907260450.VAA10559@freefall.freebsd.org> References: <199907241724.LAA13835@mt.sri.com> <199907260450.VAA10559@freefall.freebsd.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > jk> The intent of this change is to prevent a user from seeing how an > jk> executable with '--x--x--x' perms works by ktrace'ing its execution. > > jk> My question to -hackers is: is this a useful semantic? Would it break > jk> anything if added? > > nw> If we make kernel auditing based upon KTRACE (which may or may not > nw> happen), this is not a useful change since we need to be able to 'audit' > nw> system calls regardless of whether or not KTRACE is used. If this kind > > This particular change should not affect the future auditing tool. The future audting tools may depend on KTRACE. > The [execve] system call will still be logged as having been > attempted; the control flow remains the same as for the current > ``no execute perms'' case but with a stricter check if KTRACE'ing > is on for the process. Right, but the system requires KTRACE as a pre-requisite for IDS, therefore we've changed the behavior of the system by adding IDS (which brings in KTRACE as a side-effect). What once was considered 'ok' previously is now not OK when IDS is added (exec'ing binaries that don't have the read permission on them..) > nw> If security is an issue, KTRACE shouldn't be in the system. > > Yes, but /if/ KTRACE is present, today's code allows you to bypass > the lack of read permissions on an executable. That shouldn't be > allowed. The current behaviour could be regarded as a security > hole actually :). Naw. You have to reverse engineer the entire piece of code to figure out what it's doing. Knowing the syscalls is not giving you a whole lot of information. > Part of the confusion comes from the meaning of the 'x' bit when > KTRACE'ing is also permitted. Ordinarily the 'x' bit determines > if a user can execute a file. But should execute permissions also > imply the ability to trace the execution of the process? Because 'execution' is almost the same thing as 'trace' (you can't have one w/out the other), then yes. > If so, the value of a permission mask like '--x--x--x' is weakened > because although you cannot read the file, you can 'see inside' it, > indirectly. Very indirectly. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 9: 7:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 18B7415356; Mon, 26 Jul 1999 09:07:38 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA27623; Mon, 26 Jul 1999 10:07:37 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA18859; Mon, 26 Jul 1999 10:07:37 -0600 Date: Mon, 26 Jul 1999 10:07:37 -0600 Message-Id: <199907261607.KAA18859@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jkoshy@FreeBSD.org Cc: Nate Williams , freebsd-hackers@FreeBSD.org Subject: Re: deny ktrace without read permissions? In-Reply-To: <199907260450.VAA10559@freefall.freebsd.org> References: <199907241724.LAA13835@mt.sri.com> <199907260450.VAA10559@freefall.freebsd.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The PR proposes (and the patch given earlier implements) tighter > security on the premise that security in the presence of KTRACE > should be at least as tight as without KTRACE. It achieves this > by requiring read permissions on an executable before it can be > KTRACE'd. As other have pointed out, if you're good enough to reverse engineer a program from just it's syscall, you're probably good enough to stick in a new shared library that allows you to 'reverse engineer' w/out requiring KTRACE. Again, security through obscurity is never a good solution, and this is just that wrapped in different clothes. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 9:54:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9FF5F15188; Mon, 26 Jul 1999 09:54:11 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA28218; Mon, 26 Jul 1999 10:52:40 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA19121; Mon, 26 Jul 1999 10:52:34 -0600 Date: Mon, 26 Jul 1999 10:52:34 -0600 Message-Id: <199907261652.KAA19121@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dominic Mitchell Cc: jkoshy@FreeBSD.ORG, chris@calldei.com, hackers@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) In-Reply-To: <19990726132132.B78403@voodoo.pandhm.co.uk> References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> <19990726132132.B78403@voodoo.pandhm.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables > > in FreeBSD. > > But the point being made is that they are not ignored for executables > which have no read access. And from there, read access can be gained, > because at that point, you have code running in the process's address > space. That's right. In other words, there really is no way of protecting executable files from being read if someone is motivated enough. And, in an open-source OS like FreeBSD, it's not a viable solution in any case.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 10: 1:11 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 4338314D83; Mon, 26 Jul 1999 10:01:05 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip47.houston3.tx.pub-ip.psi.net [38.12.169.47]) by leap.innerx.net (Postfix) with ESMTP id DB60E370C3; Mon, 26 Jul 1999 13:00:50 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id MAA86951; Mon, 26 Jul 1999 12:01:45 -0500 (CDT) (envelope-from chris) Date: Mon, 26 Jul 1999 12:01:44 -0500 From: Chris Costello To: Nate Williams Cc: Dominic Mitchell , jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) Message-ID: <19990726120144.E85663@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> <19990726132132.B78403@voodoo.pandhm.co.uk> <199907261652.KAA19121@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <199907261652.KAA19121@mt.sri.com>; from Nate Williams on Mon, Jul 26, 1999 at 10:52:34AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999, Nate Williams wrote: > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables > > > in FreeBSD. > > > > But the point being made is that they are not ignored for executables > > which have no read access. And from there, read access can be gained, > > because at that point, you have code running in the process's address > > space. > > That's right. In other words, there really is no way of protecting > executable files from being read if someone is motivated enough. > > And, in an open-source OS like FreeBSD, it's not a viable solution in > any case.... The only option, as I've mentined previously in this thread, that I can think of, would be to have an option when building various linker code to disable searching in $LD_LIBRARY_PATH if the library being looked for is in the standard library paths. -- |Chris Costello |Is reading in the bathroom considered Multi-Tasking? `---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 10: 6:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id CC20614BD4; Mon, 26 Jul 1999 10:06:24 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA28404; Mon, 26 Jul 1999 11:04:48 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA19285; Mon, 26 Jul 1999 11:04:47 -0600 Date: Mon, 26 Jul 1999 11:04:47 -0600 Message-Id: <199907261704.LAA19285@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: chris@calldei.com Cc: Nate Williams , Dominic Mitchell , jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) In-Reply-To: <19990726120144.E85663@holly.dyndns.org> References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> <19990726132132.B78403@voodoo.pandhm.co.uk> <199907261652.KAA19121@mt.sri.com> <19990726120144.E85663@holly.dyndns.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables > > > > in FreeBSD. > > > > > > But the point being made is that they are not ignored for executables > > > which have no read access. And from there, read access can be gained, > > > because at that point, you have code running in the process's address > > > space. > > > > That's right. In other words, there really is no way of protecting > > executable files from being read if someone is motivated enough. > > > > And, in an open-source OS like FreeBSD, it's not a viable solution in > > any case.... > > The only option, as I've mentined previously in this thread, > that I can think of, would be to have an option when building > various linker code to disable searching in $LD_LIBRARY_PATH if > the library being looked for is in the standard library paths. Except that's only *one* of the ways. There's still ptrace and /proc, so you'd have to hunt them down as well. However, assuming you've hunted them all down, you may be removing useful functionality from the system that is currently used, so it's not worth it. SEF's solution of doing a 'setuid(getuid());' is a good solution that solves the problems listed, and doesn't require any modifications to the system. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 10:13: 6 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 080F914D78; Mon, 26 Jul 1999 10:13:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA47502; Mon, 26 Jul 1999 10:12:25 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 10:12:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199907261712.KAA47502@apollo.backplane.com> To: Chris Costello Cc: Nate Williams , Dominic Mitchell , jkoshy@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? ) References: <19990726054037.D79022@holly.dyndns.org> <199907261116.EAA43920@freefall.freebsd.org> <19990726132132.B78403@voodoo.pandhm.co.uk> <199907261652.KAA19121@mt.sri.com> <19990726120144.E85663@holly.dyndns.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, Jul 26, 1999, Nate Williams wrote: :> > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables :> > > in FreeBSD. :> > :> > But the point being made is that they are not ignored for executables :> > which have no read access. And from there, read access can be gained, :> > because at that point, you have code running in the process's address :> > space. :> :> That's right. In other words, there really is no way of protecting :> executable files from being read if someone is motivated enough. :> :> And, in an open-source OS like FreeBSD, it's not a viable solution in :> any case.... : : The only option, as I've mentined previously in this thread, :that I can think of, would be to have an option when building :various linker code to disable searching in $LD_LIBRARY_PATH if :the library being looked for is in the standard library paths. : :-- :|Chris Costello LD_LIBRARY_PATH was a huge security hole when it was first introduced and you know what? It STILL IS! We are opening up a can of worms here. It's one of those things where we either have to make the decision to try to protect the binary that the owner decided to make execute-only, or to give up. * LD_LIBRARY_PATH? * core dumps for execute-only binaries? * ktrace for execute-only binaries? If I were to put my foot down I would say off with their heads! i.e. disallow all three if the non-root-run binary is execute-only. -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 26 11: 0:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tepsa.lame.pl (tepsa.lame.pl [195.117.126.177]) by hub.freebsd.org (Postfix) with ESMTP id 0FDFA14F54 for ; Mon, 26 Jul 1999 10:59:51 -0700 (PDT) (envelope-from cys@denied.cx) Received: from localhost (cys@localhost) by tepsa.lame.pl (8.9.3/+++ATH) with ESMTP id UAA55898 for ; Mon, 26 Jul 1999 20:01:22 +0200 (CEST) Date: Mon, 26 Jul 1999 20:01:22 +0200 (CEST) From: Krzysztof Krawczyk X-Sender: cys@tepsa.lame.pl To: freebsd-hackers@freebsd.org Subject: Pasting data between terminals 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 Maybe this is a wrong list, so tell me about it, but I think you can help me :) I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. Under ttyp1 I run a program. Now I need to transport big count of datas from terminal ttyp2 to ttyp1. When I do: echo "blah blah" >>/dev/ttyp1 text "blah blah" appear in virtual terminal ttyp1, but only as a text of "message". I need ttyp1 count those datas as a "command typed by hand", not just a text displayed in this term as info. I must transport lots of data between these terminals. Have you any ideas? Cys - Krzysztof Krawczyk IRC on DALnet: #polska #polcafe #wroclaw cys@for.lames.access.is.denied.cx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "What sane person could live in this world and not be crazy?" -- Ursula K. LeGuin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 11: 6:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 7AF7414E55 for ; Mon, 26 Jul 1999 11:06:37 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id OAA11469; Mon, 26 Jul 1999 14:05:31 -0400 (EDT) Date: Mon, 26 Jul 1999 14:05:31 -0400 (EDT) From: Jim Flowers To: Kirk McDonald Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Wavelan-WavepointII In-Reply-To: <379BD029.23B1D995@apdata.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 Yes, we have had good success with WaveLAN/IEEE Turbo cards using the wi driver in both ad-hoc mode and infrastructure mode with a WavepointII. NAT will work on the wi interface, SKIP will not. While we run IP routing instead of bridging, the underlying concept is bridging if you really mean that. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Mon, 26 Jul 1999, Kirk McDonald wrote: > Hello, > > I am wondering if anyone has had success running bridging only between a > wavelan IEEE802.11 in a BSD machine and a WavepointII using an > IEEE802.11 card. I have had great succes using purely wavelan/BSD. > > Kirk McDonald > > > 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 26 11:17:46 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 947E714E55 for ; Mon, 26 Jul 1999 11:17:44 -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 LAA37284; Mon, 26 Jul 1999 11:15:48 -0700 (PDT) Date: Mon, 26 Jul 1999 11:15:47 -0700 (PDT) From: Julian Elischer To: Doug Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.ORG Subject: Re: [Fwd: wd0 DMA errors] In-Reply-To: <379BC627.4A370FB2@gorean.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 not convinced that this is the same error.. the message is different.. On Sun, 25 Jul 1999, Doug wrote: > Sheldon Hearn wrote: > > > > On Sun, 25 Jul 1999 10:59:26 MST, Doug wrote: > > > > > No answer on -current, any help appreciated. > > > > We're probably all sitting here thinking "I'm sure this was asked and > > answered recently. He can read his CURRENT mail like the rest of us." > > I have indeed read my -current mail. Several bugs in the PCI and DMA code > have been mentioned in the past week, but frankly I don't have enough > expertise in either to know for sure that the bugs mentioned would produce > the error messages I saw. A simple, "yes, those were the bugs fixed > recently" is all that was needed. > > Thank you, > > Doug > > > 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 26 11:18:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 0EB1B14FB3; Mon, 26 Jul 1999 11:18:10 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA05470; Mon, 26 Jul 1999 13:16:57 -0500 (CDT) From: Joe Greco Message-Id: <199907261816.NAA05470@aurora.sol.net> Subject: securelevel and ipfw zero To: freebsd-hackers@freebsd.org Date: Mon, 26 Jul 1999 13:16:57 -0500 (CDT) Cc: freebsd-ipfw@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 Hello, So, I've a box that I have an ipfw ruleset on. The firewall should not be changeable during runtime, and the box runs at securelevel=3. In order to prevent DoS disk-fill attacks, I also have specified IPFW_VERBOSE_LIMIT. Now, the problem is, in securelevel 3, you cannot zero a rule's counter, so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT events and then you lose logging (ideally I'd zero nonzero rules once every N minutes). Comments? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 11:48:51 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 5B3C714D3E; Mon, 26 Jul 1999 11:48:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA48202; Mon, 26 Jul 1999 11:47:20 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 11:47:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199907261847.LAA48202@apollo.backplane.com> To: Joe Greco Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907261816.NAA05470@aurora.sol.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :------------------------------------------------------------------------------- :Joe Greco - Systems Administrator jgreco@ns.sol.net Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -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 26 12: 8:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id C000414CC2; Mon, 26 Jul 1999 12:08:40 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA08989; Mon, 26 Jul 1999 14:07:11 -0500 (CDT) From: Joe Greco Message-Id: <199907261907.OAA08989@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261847.LAA48202@apollo.backplane.com> from Matthew Dillon at "Jul 26, 1999 11:47:20 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 26 Jul 1999 14:07:10 -0500 (CDT) Cc: hackers@freebsd.org, freebsd-ipfw@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 > :Hello, > : > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > :changeable during runtime, and the box runs at securelevel=3. > : > :In order to prevent DoS disk-fill attacks, I also have specified > :IPFW_VERBOSE_LIMIT. > : > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > :events and then you lose logging (ideally I'd zero nonzero rules once every > :N minutes). > : > :Comments? > > Playing devil's advocate, someone might be using those counters for > accounting purposes. That's about as worse a scenario as I can think > of, and I can't imagine this sort of situation would be prevalient. > > I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Having a per-rule limit means that you actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit (assuming an attacker exploits multiple rules) rather than a limit of "IPFW_VERBOSE_LIMIT". It also makes it more difficult to code in a bunch of "log" rules, since your periodic "zero" script has to know the number of each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. I can deal with it (in code) if there is a per-rule log counter as well, but what you are telling me makes it sound more attractive to have a global logging counter. Comments? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 12:33: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25]) by hub.freebsd.org (Postfix) with SMTP id D0D1214F4C for ; Mon, 26 Jul 1999 12:32:54 -0700 (PDT) (envelope-from ShapiroS@MindSpring.NET) Received: (qmail 16837 invoked from network); 26 Jul 1999 19:18:27 -0000 Received: from nomis.ems.mindspring.net (HELO MindSpring.NET) (209.86.81.177) by sendero.simon-shapiro.org with SMTP; 26 Jul 1999 19:18:27 -0000 Message-ID: <379CB7B8.5E0E9C55@MindSpring.NET> Date: Mon, 26 Jul 1999 15:32:08 -0400 From: Simon Shapiro Organization: EMS, MindSpring Enterprises, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: DPT SmartRAID V (i2o) Status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Y'll Several of you ask, so here is a generic answer; I am actively working on i2o subsystem for FreeBSD. The reference card for this work is the DPT 5th Generation controllers. Status: Much of the work, particularly IRT DPT controllers is complete. All the mechanics and kernel modifications to allow recognition of i2o card and in particular DPT cards is in place. I am able, routinely to: * Detect the cards * Negotiate setup and configuration * Initialize the IOP * Build a list of all devices known * Query device attributes and capabilities * Notify the kernel of known devices * Accept block I/O requests, send to the IOP, return results. * Accept character (raw) device I/O requests, translate to Block I/O requests, process and reply. * Still to be done: * Complete debugging disklabel code. * Add fdisk slice code * Mature and stabilize error handling * Complete port of dptutil (RAID management. Most Helpful Help: Fdisk Slice, disklabel, and devfs code completion. Personal Note; I am so swamped with work that I have little time, if any, for participation in mailing list activities. This is NOT to say that I am not active in FreeBSD, or the i2o project. If you need me, or like to chat, drop me a line! -- Sincerely Yours, Simon Shapiro Research Fellow MindSpring Enterprises ShapiroS@mindspring.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 12:44:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8C64514EBD; Mon, 26 Jul 1999 12:44:24 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA00579; Mon, 26 Jul 1999 13:44:16 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA20897; Mon, 26 Jul 1999 13:44:16 -0600 Date: Mon, 26 Jul 1999 13:44:16 -0600 Message-Id: <199907261944.NAA20897@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: dillon@apollo.backplane.com (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261907.OAA08989@aurora.sol.net> References: <199907261847.LAA48202@apollo.backplane.com> <199907261907.OAA08989@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > :changeable during runtime, and the box runs at securelevel=3. > > : > > :In order to prevent DoS disk-fill attacks, I also have specified > > :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > :N minutes). > > : > > :Comments? > > > > Playing devil's advocate, someone might be using those counters for > > accounting purposes. That's about as worse a scenario as I can think > > of, and I can't imagine this sort of situation would be prevalient. > > > > I'd say that the counters should be clearable at high secure level. > > Then there should be a separate counter for logging purposes...? I do not > care if the accounting counters do not clear (ever), since things like MRTG > are designed to deal with that situation. MRTG? > However, it seems bad that you > would not be able to clear your counter for logging purposes, just in case > you actually _did_ mean that you want bad packets to be logged. *grin* > I will also note that it would be acceptable, to me at least, to maintain a > global (rather than per-rule) limit for the verbose limit. In general, I > would think that someone who uses the limit facility is trying to avoid a > DoS style disk-space attack. Agreed, see above. > Having a per-rule limit means that you > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > (assuming an attacker exploits multiple rules) rather than a limit of > "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. > It also makes it more difficult to code in a bunch > of "log" rules, since your periodic "zero" script has to know the number of > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > get a bunch of > > /kernel: ipfw: Entry rule1 cleared. > /kernel: ipfw: Entry rule2 cleared. > /kernel: ipfw: Entry rule3 cleared. > > each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. > I would rather see something like > > /kernel: ipfw: logging limit reached, suspending. > # /sbin/ipfw zerolog > /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 13:11: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 6902A14C4C; Mon, 26 Jul 1999 13:10:58 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id PAA13453; Mon, 26 Jul 1999 15:10:45 -0500 (CDT) From: Joe Greco Message-Id: <199907262010.PAA13453@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261944.NAA20897@mt.sri.com> from Nate Williams at "Jul 26, 1999 1:44:16 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 26 Jul 1999 15:10:45 -0500 (CDT) Cc: jgreco@ns.sol.net, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@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 > > > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > > :changeable during runtime, and the box runs at securelevel=3. > > > : > > > :In order to prevent DoS disk-fill attacks, I also have specified > > > :IPFW_VERBOSE_LIMIT. > > FWIW, as you pointed out below, this was put in specifically to avoid a > DoS attack. > > > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > > :N minutes). > > > : > > > :Comments? > > > > > > Playing devil's advocate, someone might be using those counters for > > > accounting purposes. That's about as worse a scenario as I can think > > > of, and I can't imagine this sort of situation would be prevalient. > > > > > > I'd say that the counters should be clearable at high secure level. > > > > Then there should be a separate counter for logging purposes...? I do not > > care if the accounting counters do not clear (ever), since things like MRTG > > are designed to deal with that situation. > > MRTG? multi-router traffic grapher. Put a SNMP interface between that and ipfw and wheeee instant traffic graphing. > > However, it seems bad that you > > would not be able to clear your counter for logging purposes, just in case > > you actually _did_ mean that you want bad packets to be logged. > > *grin* > > > I will also note that it would be acceptable, to me at least, to maintain a > > global (rather than per-rule) limit for the verbose limit. In general, I > > would think that someone who uses the limit facility is trying to avoid a > > DoS style disk-space attack. > > Agreed, see above. > > > Having a per-rule limit means that you > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > (assuming an attacker exploits multiple rules) rather than a limit of > > "IPFW_VERBOSE_LIMIT". > > I disagree. I have *tons* of firewall rules, and I don't want to have > to recompile my kernel if I modify my script at a later point and make > the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten "log" rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm an admin, I'm going to think "Well lets see, I want to store a month of bad packets in it. I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario." Now given 200 rules, I can fill his disk in substantially less than a day. I don't know what you mean by "make the rules 'more verbose'" but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > Case in point, I may at one time want to 'log' all connections to a > particular port, and then later ignore (no longer log) all the > connections to that port *except* to a particular host. Or, the reverse > may be true. In these cases, I don't want to have to recompile my > kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel < 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. What I am discussing does not affect this at all. If you are afraid of hitting the VERBOSE_LIMIT, that is why you would have an additional command such as "ipfw zerolog". > I think a 'per-rule' limit works best, instead of a global limit. This > also works well in the case of rootkit attempt breakins, since they tend > to hit one rule multiple times, and then another multiple times, etc... > > With a 'global' limit, I may end up 'limiting out' on the first rule, > and then miss all the rules hit later on with the attack. Yes, you might. But you might miss them anyways, and I can run you out of disk space quicker. > > It also makes it more difficult to code in a bunch > > of "log" rules, since your periodic "zero" script has to know the number of > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > get a bunch of > > > > /kernel: ipfw: Entry rule1 cleared. > > /kernel: ipfw: Entry rule2 cleared. > > /kernel: ipfw: Entry rule3 cleared. > > > > each time you do this. > > Or, you do like I do, and have a cronjob 'zero' out the entire log > ruleset everynight right after it sends the results to me to analyze. Interferes with your accounting counters. You need to be able to do them individually to avoid that. > However, at times (during breakins I happen to catch, or during ruleset > debugging sessions) I still want to have control over individual rules. > > > I would rather see something like > > > > /kernel: ipfw: logging limit reached, suspending. > > # /sbin/ipfw zerolog > > /kernel: ipfw: logging limit reset, resuming. > > This is essentially what I do. But, you can do 'ipfw zero' which > accomplishes the same thing. No, it nukes the accounting counters. > However, this is really a side-issue. The last thing I'll say is that I > think a 'global' counter is a bad idea, and this is from using IPFW for > years in a real/deployed FreeBSD firewall situation. It would cause me > more trouble than it's worth, and provide 'less' flexibility than > currently exists (which I use). Then your argument devolves down to one of wanting a per-rule counter and you don't care if it is the accounting one or a new one... And I've been using FreeBSD and IPFW in a real/deployed environment as well, and I keep hitting up against these goofy sorts of problems. It is much, much more usable than something like ipfw in 2.1R or earlier, but these little things still matter. > The real issue from your first email is '*should* ipfw rules be > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > administrator can't think of any bad things that could occur, but I can > imagine something bad happening if someone were allowed to do this, > although it's not completely concrete. I don't have the brain-cells to > dedicate to thinking about the full implications of a 'bad-guy' zeroing > out my rules. He interferes with whatever other features you've built into the system which rely on those accounting numbers. I agree - you probably don't want to do that. > On the other, the firewall administrator who actually has to use this > darn system is less worried about breakins and such, thinking that if > someone compromised my system at high securelevels, they could do more > damage to my system in other ways than by zeroing out my firewall > numbers. > > But, then again if we're in securelevel 3, we shouldn't let *anyone* do > anything to the system, since we're paranoid about anything negative > happening to my system. > > In other words, I'm not sure what is the 'right' thing to do here. Well, the 'right' thing is clear: pull the limit count out of the accounting count. This solves both the problem of zeroing accounting counters and potentially messing with other things, and also of letting people do anything 'negative' in securelevel 3. By pulling the limit count out into a separate entity, nothing 'negative' can happen (because stopping the logging process is definitely negative, and being able to restart it without messing with other stuff is positive). Now that we are agreed that the limit count needs to be divorced from the accounting count, we can debate whether it should be a per-rule or global limit. Maybe it could be sysctl'able... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 13:19:17 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 6FC9414C40 for ; Mon, 26 Jul 1999 13:19:10 -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 WAA22063; Mon, 26 Jul 1999 22:17:21 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907262017.WAA22063@gratis.grondar.za> To: Sheldon Hearn Cc: hackers@FreeBSD.ORG, dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: Re: file(1) Magdir candidate: wintendo Date: Mon, 26 Jul 1999 22:17:20 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So I propose a new file wintendo, for all gaming file formats used on > the MS Windows platform. "Wintendo" is a bad name for anything official. Try to find MS's official name for the format(s). 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 Mon Jul 26 13:25:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 564F514C40; Mon, 26 Jul 1999 13:25:08 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id WAA54302; Mon, 26 Jul 1999 22:23:42 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: TCP/IP hardening Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 26 Jul 1999 22:23:41 +0200 Message-ID: Lines: 238 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - des@yes.no Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions="NO" # Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES" # Kill dead TCP connections (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. Index: etc/rc.network =================================================================== RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + + if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null + fi + + if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null + fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null + fi + + if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null + fi + + if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFIN opt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT 1999/07/26 05:47:17 1.620 +++ LINT 1999/07/26 19:11:51 @@ -465,9 +465,23 @@ options IPDIVERT #divert sockets options IPFILTER #kernel ipfilter support options IPFILTER_LOG #ipfilter logging -#options IPFILTER_LKM #kernel support for ip_fil.o LKM options IPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM #kernel support for ip_fil.o LKM options TCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. +# +options TCP_RESTRICT_RST #restrict emission of TCP RST +options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from Index: sys/netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.34 diff -u -r1.34 ip_icmp.c --- ip_icmp.c 1999/03/06 23:10:42 1.34 +++ ip_icmp.c 1999/07/26 19:11:51 @@ -69,6 +69,14 @@ SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, ""); +static int logredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, logredirect, CTLFLAG_RW, + &logredirect, 0, ""); + +static int dropredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, dropredirect, CTLFLAG_RW, + &dropredirect, 0, ""); + #ifdef ICMP_BANDLIM /* @@ -462,6 +470,15 @@ return; case ICMP_REDIRECT: + if (logredirect) { + char from[4 * sizeof "123"], dst[4 * sizeof "123"]; + strcpy(from, inet_ntoa(ip->ip_src)); + strcpy(dst, inet_ntoa(icp->icmp_ip.ip_dst)); + printf("icmp_redirect from %s: %s => %s\n", + from, dst, inet_ntoa(icp->icmp_gwaddr)); + } + if (dropredirect) + break; if (code > 3) goto badcode; if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || Index: sys/netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.87 diff -u -r1.87 tcp_input.c --- tcp_input.c 1999/07/18 14:42:48 1.87 +++ tcp_input.c 1999/07/26 19:11:51 @@ -36,6 +36,7 @@ #include "opt_ipfw.h" /* for ipfw_fwd */ #include "opt_tcpdebug.h" +#include "opt_tcp_input.h" #include #include @@ -89,6 +90,18 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +#ifdef TCP_RESTRICT_RST +static int restrict_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, restrict_rst, CTLFLAG_RW, + &restrict_rst, 0, "Restrict RST emission"); +#endif + +#ifdef TCP_DROP_SYNFIN +static int drop_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, + &drop_synfin, 0, "Drop TCP packets with FIN+ACK set"); +#endif + u_long tcp_now; struct inpcbhead tcb; struct inpcbinfo tcbinfo; @@ -336,6 +349,18 @@ } tiflags = ti->ti_flags; +#ifdef TCP_DROP_SYNFIN + /* + * If the drop_synfin option is enabled, drop all packets with + * both the SYN and FIN bits set. This prevents e.g. nmap from + * identifying the TCP/IP stack. + * + * This is incompatible with RFC1644 extensions (T/TCP). + */ + if (drop_synfin && (tiflags & (TH_SYN|TH_FIN)) == TH_SYN|TH_FIN) + goto drop; +#endif + /* * Convert TCP protocol specific fields to host format. */ @@ -1764,6 +1789,10 @@ return; dropwithreset: +#ifdef TCP_RESTRICT_RST + if (restrict_rst) + goto drop; +#endif /* * Generate a RST, dropping incoming segment. * Make ACK acceptable to originator of segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 13:48:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id D1BA214FDD; Mon, 26 Jul 1999 13:48:26 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA01379; Mon, 26 Jul 1999 14:45:14 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA21485; Mon, 26 Jul 1999 14:45:13 -0600 Date: Mon, 26 Jul 1999 14:45:13 -0600 Message-Id: <199907262045.OAA21485@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262010.PAA13453@aurora.sol.net> References: <199907261944.NAA20897@mt.sri.com> <199907262010.PAA13453@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Having a per-rule limit means that you > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > "IPFW_VERBOSE_LIMIT". > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > to recompile my kernel if I modify my script at a later point and make > > the rules 'more verbose'. > > Huh? > > I think you completely missed what I said - or maybe the opposite. > > Right now, if you have ten "log" rules, I can make your system log up > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > again assuming I can generate appropriate violations. > > This eats up a grossly variable amount of disk space, which seems contrary > to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. > If I'm an admin, I'm going to think "Well lets see, I want to store a > month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the > I zero > my counters every five minutes and there is a limit of 100 per five mins, > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. > Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. > I don't know what you mean by "make the rules 'more verbose'" but what I > am advocating is not any change in what currently exists... I am talking > about limiting the number of entries possible in a manner that would seem > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) > > Case in point, I may at one time want to 'log' all connections to a > > particular port, and then later ignore (no longer log) all the > > connections to that port *except* to a particular host. Or, the reverse > > may be true. In these cases, I don't want to have to recompile my > > kernel to allow 'more logging' of the information. > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > 3, which is required regardless... you just delete the less restrictive > rule and replace it with a more restrictive rule. I want *both* rules, and I want *full* information disclosure since I want to know how I'm being attacked. See, knowing how I'm attacked is useful since it helps me avoid future attacks, as well as allow me potentially stock future attacks from happening by informing an ISP of the behavior of one of their users. Maybe that person will get on another ISP, or maybe he'll cleanup his act. Who knows, but sitting idle means nothing happens. > > I think a 'per-rule' limit works best, instead of a global limit. This > > also works well in the case of rootkit attempt breakins, since they tend > > to hit one rule multiple times, and then another multiple times, etc... > > > > With a 'global' limit, I may end up 'limiting out' on the first rule, > > and then miss all the rules hit later on with the attack. > > Yes, you might. But you might miss them anyways, and I can run you out of > disk space quicker. Sure, but you have to know alot about my box to do that, and if you have that kind of information, I can run your box out of disk space just as easily, it takes a bit longer. (And, it would take you months to run my box out of disk space in it's current setup, which is a engineering tradeoff for maximum information retrieval balanced with the history of attacks on my system, along with engineering paranoia about how a DoS attack could occur.) Again, IPFW_VERBOSE_LIMIT is *NOT* there to make for smaller logfiles, it's there to avoid a single kind of attack made on the system. These kinds of attacks 'tend' to focus on a single port and/or rule. Also, having a global count also leaves you 'wide-open' for doing a DoS attack, following by a real attack. You would no longer have any idea how the 'real' attack is occuring, so with the current implementation, the attacker must know your exact FW configuration in order to attack you well. (And, I would argue that *IF* they had my FW configuration and/or rulesets, my firewall would be almost useless since in any system, there are tradeoffs made for 'ease-of-use' vs. security.) > > > It also makes it more difficult to code in a bunch > > > of "log" rules, since your periodic "zero" script has to know the number of > > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > > get a bunch of > > > > > > /kernel: ipfw: Entry rule1 cleared. > > > /kernel: ipfw: Entry rule2 cleared. > > > /kernel: ipfw: Entry rule3 cleared. > > > > > > each time you do this. > > > > Or, you do like I do, and have a cronjob 'zero' out the entire log > > ruleset everynight right after it sends the results to me to analyze. > > Interferes with your accounting counters. You need to be able to do > them individually to avoid that. I'm not disagreeing. ipfw zero rule1 also interfers with your counters as well, but only on those rules. > > However, at times (during breakins I happen to catch, or during ruleset > > debugging sessions) I still want to have control over individual rules. > > > > > I would rather see something like > > > > > > /kernel: ipfw: logging limit reached, suspending. > > > # /sbin/ipfw zerolog > > > /kernel: ipfw: logging limit reset, resuming. > > > > This is essentially what I do. But, you can do 'ipfw zero' which > > accomplishes the same thing. > > No, it nukes the accounting counters. I've not argued that point. > > However, this is really a side-issue. The last thing I'll say is that I > > think a 'global' counter is a bad idea, and this is from using IPFW for > > years in a real/deployed FreeBSD firewall situation. It would cause me > > more trouble than it's worth, and provide 'less' flexibility than > > currently exists (which I use). > > Then your argument devolves down to one of wanting a per-rule counter and > you don't care if it is the accounting one or a new one... Correct. The existing infrastructure works for me. I don't use my FW for accounting purposes (that's what the wireless bridge is for), so I don't care if the counters are zero'd. But, I *don't* want to see the system modified to replace the per-rule counters with a global counter since it has some exteremely negative side-effects, the most obnoxious is to lose 'valid' breakin information, which is the point of having logging in the first place. > And I've been using FreeBSD and IPFW in a real/deployed environment as well, > and I keep hitting up against these goofy sorts of problems. It is much, > much more usable than something like ipfw in 2.1R or earlier, but these > little things still matter. The changes in 2.1 affected quite a bit, but all it required me to do was to rewrite my FW rules. I saw very little 'functionality' additions, just changes made that required me to re-write how I was doing things. Since the firewall is a 'side' job of mine, it was a pain in the butt to do it, but now that's (long) past. :) > > The real issue from your first email is '*should* ipfw rules be > > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > > administrator can't think of any bad things that could occur, but I can > > imagine something bad happening if someone were allowed to do this, > > although it's not completely concrete. I don't have the brain-cells to > > dedicate to thinking about the full implications of a 'bad-guy' zeroing > > out my rules. > > He interferes with whatever other features you've built into the system > which rely on those accounting numbers. I agree - you probably don't > want to do that. One could argue that accounting numbers in a firewall shouldn't be trusted, but I won't argue that point since the firewall is often the most 'natural' place to stick network accounting software. > Well, the 'right' thing is clear: pull the limit count out of the > accounting count. This solves both the problem of zeroing accounting > counters and potentially messing with other things, and also of letting > people do anything 'negative' in securelevel 3. Is it the 'right' thing to do? I think that someone messing with the 'logging' rule counts could be just as dangerous as someone messing with the accounting counts. Again, if you're paranoid enough to have securelevel 3, you've got to be paranoid enough to assume that someone *HAS* root access on your box, and is going to do anything nasty they could. > By pulling the limit count out into a separate entity, nothing > 'negative' can happen (because stopping the logging process is > definitely negative, and being able to restart it without messing with > other stuff is positive). I'm not sure this is an acceptable change either, but I'll leave that discussion to the networking folks. > Now that we are agreed that the limit count needs to be divorced from the > accounting count, we can debate whether it should be a per-rule or global > limit. Hold on to your horses, Hoss. I haven't agreed to that. Don't be putting words in my mouth. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 13:49: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 94ACF14FAA for ; Mon, 26 Jul 1999 13:49:06 -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 118rdo-000KAA-00; Mon, 26 Jul 1999 22:46:32 +0200 From: Sheldon Hearn To: Mark Murray Cc: hackers@FreeBSD.ORG, dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Mon, 26 Jul 1999 22:17:20 +0200." <199907262017.WAA22063@gratis.grondar.za> Date: Mon, 26 Jul 1999 22:46:31 +0200 Message-ID: <77509.933021991@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > "Wintendo" is a bad name for anything official. Try to find MS's > official name for the format(s). You're hoping for a standard name for file formats of games used on Microsoft platformat? There are two words in that question that one doesn't usually fine together in a sentence that doesn't contain the word "bastardize". :-) I'll try... 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 26 13:49:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id D6BC91512F for ; Mon, 26 Jul 1999 13:49:47 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 26 Jul 1999 21:49:47 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PJ2VDV9W; Mon, 26 Jul 1999 21:49:46 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 118rgp-0004R4-00; Mon, 26 Jul 1999 21:49:39 +0100 Date: Mon, 26 Jul 1999 21:49:39 +0100 To: Krzysztof Krawczyk Cc: freebsd-hackers@freebsd.org Subject: Re: Pasting data between terminals Message-Id: <19990726214939.B16979@voodoo.pandhm.co.uk> References: MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Krzysztof Krawczyk on Mon, Jul 26, 1999 at 08:01:22PM +0200 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999 at 08:01:22PM +0200, Krzysztof Krawczyk wrote: > Maybe this is a wrong list, so tell me about it, but I think you can help > me :) > > I have small problem. I own two virtual terminals, eg. ttyp1 and ttyp2. > Under ttyp1 I run a program. Now I need to transport big count of datas > from terminal ttyp2 to ttyp1. > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? 1) Try freebsd-questions in future. 2) Try expect. See http://expect.nist.gov/ . -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 13:55:35 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 ABDCC152A9 for ; Mon, 26 Jul 1999 13:55: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 118rkm-000Lu8-00; Mon, 26 Jul 1999 22:53:44 +0200 From: Sheldon Hearn To: Mark Murray Cc: hackers@FreeBSD.ORG, dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Mon, 26 Jul 1999 22:46:31 +0200." <77509.933021991@axl.noc.iafrica.com> Date: Mon, 26 Jul 1999 22:53:44 +0200 Message-ID: <84203.933022424@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 22:46:31 +0200, Sheldon Hearn wrote: > You're hoping for a standard name for file formats of games used on > Microsoft platformat? Duh, I'm being obtuse. Your question indicates that I've phrased my proposal in such a way as to suggest that this is for formats of Microsoft games. That's not what I meant. I meant games used on the Microsoft platforms. However, it occurs to me that this is stupid, since the same game may be available on multiple PC platforms, all using the same file format. So... how about pcgames as the name of the file? 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 26 14: 2:19 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 5BA8815046 for ; Mon, 26 Jul 1999 14:02:14 -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 XAA02366 for ; Mon, 26 Jul 1999 23:02:03 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m118rso-002ZjZC; Mon, 26 Jul 99 23:02 MET DST Received: from bert.kts.org([194.55.156.2]) (1206 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Mon, 26 Jul 1999 22:12:33 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #5 built 1999-Apr-19) Received: from localhost (756 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Mon, 26 Jul 1999 22:15:56 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: new PPP printer for tcpdump To: freebsd-hackers@freebsd.org (FreeBSD Hackers) Date: Mon, 26 Jul 1999 22:15:56 +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, i've put a new PPP decode/print routine print-ppp.c for tcpdump into my home dir on freefall. It would be good if someone could verify/review it. 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 Mon Jul 26 14:27:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id CB13314F4C for ; Mon, 26 Jul 1999 14:27:10 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA21706; Mon, 26 Jul 1999 14:27:08 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Mon, 26 Jul 1999 14:27:08 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: [Fwd: wd0 DMA errors] 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, 26 Jul 1999, Julian Elischer wrote: > I'm not convinced that this is the same error.. > the message is different.. *Nod* That's the other reason I wrote in about it. As soon as we get some other stuff cleared away I'm going to try building the world on those machines and see if the error resurfaces. Thanks, 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 Mon Jul 26 14:32:32 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 2F09614A09; Mon, 26 Jul 1999 14:32:27 -0700 (PDT) (envelope-from ambrisko@whistle.com) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA61399; Mon, 26 Jul 1999 14:29:32 -0700 (PDT) Received: (from ambrisko@localhost) by whistle.com (8.9.1/8.9.1) id OAA84337; Mon, 26 Jul 1999 14:29:31 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <199907262129.OAA84337@whistle.com> Subject: Etherboot 2.4 needs newer binutils To: hackers@FreeBSD.ORG, ports@FreeBSD.ORG Date: Mon, 26 Jul 1999 14:29:31 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL29 (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 need some wisdom on how to proceed. Since version 2 of Etherboot they are using the new data32 features of the Linux binutils. I know it works in binutils-2.9.1.0.25 which you can get from kernel.org or a mirror such as: http://kernel.stuph.org/pub/linux/devel/gcc I built it on -current after figuring the right host to pass to configure (it doesn't pick it up right without help). I installed the result as-new into /usr/local/bin and then modified the Etherboot Makefile to use it. Now I guess I have 2 questions: 1) When might this feature come into FreeBSD? Do we wait until this comes into the GNU release of binutils? 2) Do I make this a port so we can upgrade to the latest Etherboot release? Since they do a fair amount of active work I would like to track their latest stuff which currently we can't because our gas doesn't support "data32". Thanks, Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 14:33: 7 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 257D91514E for ; Mon, 26 Jul 1999 14:32:59 -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 XAA22405; Mon, 26 Jul 1999 23:30:09 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907262130.XAA22405@gratis.grondar.za> To: Sheldon Hearn Cc: hackers@FreeBSD.ORG, dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: Re: file(1) Magdir candidate: wintendo Date: Mon, 26 Jul 1999 23:30:08 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 26 Jul 1999 22:17:20 +0200, Mark Murray wrote: > > > "Wintendo" is a bad name for anything official. Try to find MS's > > official name for the format(s). > > You're hoping for a standard name for file formats of games used on > Microsoft platformat? There are two words in that question that one > doesn't usually fine together in a sentence that doesn't contain the > word "bastardize". :-) You could start with "WinEXE". 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 Mon Jul 26 14:34: 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 9171F14C1F for ; Mon, 26 Jul 1999 14:33: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 118sNR-00003y-00; Mon, 26 Jul 1999 23:33:41 +0200 From: Sheldon Hearn To: Mark Murray Cc: hackers@FreeBSD.ORG, dbushong@CSUA.Berkeley.EDU (David Bushong) Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Mon, 26 Jul 1999 23:30:08 +0200." <199907262130.XAA22405@gratis.grondar.za> Date: Mon, 26 Jul 1999 23:33:41 +0200 Message-ID: <245.933024821@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > You could start with "WinEXE". Save game file formats, not game executables. You think WinEXE tops my pcgames suggestion? 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 26 14:39:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id C2EA014A09; Mon, 26 Jul 1999 14:39:12 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id QAA19479; Mon, 26 Jul 1999 16:36:29 -0500 (CDT) From: Joe Greco Message-Id: <199907262136.QAA19479@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262045.OAA21485@mt.sri.com> from Nate Williams at "Jul 26, 1999 2:45:13 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 26 Jul 1999 16:36:28 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@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 > > > > Having a per-rule limit means that you > > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > > "IPFW_VERBOSE_LIMIT". > > > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > > to recompile my kernel if I modify my script at a later point and make > > > the rules 'more verbose'. > > > > Huh? > > > > I think you completely missed what I said - or maybe the opposite. > > > > Right now, if you have ten "log" rules, I can make your system log up > > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > > again assuming I can generate appropriate violations. > > > > This eats up a grossly variable amount of disk space, which seems contrary > > to the whole concept of IPFW_VERBOSE_LIMIT. > > If I'm getting attacked such that I'm logging data, I *want* as much > information on the attack as possible. I realize this when I setup my > IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. > > If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, > I'd like to see all of this. With a 'global' limit set to 100, I > wouldn't see these kinds of hits. > > Also, from analyzing attacks for years, most attacks have a pattern that > is *best* seen from seeing it hit a number of rules. By settin a > per-rule limit, you 'generally' can determine that an attack is going to > have a signature the same as the previous 'n' hits on that rule, but you > want to see the rest of the attack. > > I don't care to see a scan of the IMAP 1000 times when right after they > finish scanning it they also try to attack my POP3 port 1000 times. > Rather, I'd rather see the first 100 attempts on the IMAP port, then the > first 100 attempts on POP3, then the first 100 attempts on port 7, > etc... > > You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > month of bad packets in it. > > If you're an admin on today's internet, you'd realize that there is *NO* > way to get save a month worth of bad packets. Heck, at least once/week > I can't even store a day's worth of bad packets (I assume when we say > bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) > > I zero > > my counters every five minutes and there is a limit of 100 per five mins, > > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > > * 12 * 24 * 30 or 70MB for my worst case scenario." > > Not. If the attack is the same, then the syslog error reporting will > same something like (this is a real message, with IP addresses change to > protect the guilty..): > > Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 > Jun 29 16:43:44 ns last message repeated 3 times > > If you've got seperate attacks, then you've got too much stuff you're > logging. > > > Now given 200 rules, I can fill his disk in substantially less than a day. > > If you're logging that much information, then you're logging too much > information. In any case, you've got information overload, so adding a > global limit on the rules means you're losing as much (or more) > information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. > If you're worried about logging too much information, then don't reset > your counters every 5 minutes. Besides, you're losing information if > you're max'd out every 5 minutes anyway, so it really doesn't matter > when you zero out your counters. You just argued my point for me, thank you. I _want_ to see the things that I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the information is beyond the point of being useful. > > I don't know what you mean by "make the rules 'more verbose'" but what I > > am advocating is not any change in what currently exists... I am talking > > about limiting the number of entries possible in a manner that would seem > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > attacks don't hit the entire system on every rule in order to do a DoS > attack. Even so, each rule with eventually 'limit-out' and the system > will no longer log packets. This is a 'bad thing' from a security > standpoint, since at that point we are losing information. Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, and that's perfectly valid as well. > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > It's not there to make your logfiles small. If you want small logfiles, > turn of IPFW logging altogether. > > (I'm actually serious here.) Oh, that's a f'ing crock. What _I_ really want is to be able to GET the god damn information when the system is in securemode 3 and the damn IPFW has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in turning OFF IPFW logging? You're nuts if you think so. I need to be able to log a reasonable number of things without logging so many that it turns into a DoS attack. I'm trying to figure out how to do that while retaining (or increasing) intended functionality - because I've clearly spelled out a broken (but quite legitimate) situation. The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to reduce or eliminate the chance of a DoS attack. Now, the best way to eliminate the chance of a DoS attack is _algorithmically_. Giving someone a mechanism that allows them to determine the maximum resource commitment for a given scenario eliminates the chance for that DoS attack. Giving someone a mechanism that may use a variable quantity of resources is the typical programming practice that leads to a resource starvation DoS. In my own scenario, what I'm trying to do is to log a reasonable amount of stuff when something "odd" happens. I don't want someone to be able to take down my syslogd, but logging a hundred events every five minutes is not going to result in that. I can increase that number to whatever I feel is needed to make me "comfortable" that I will catch sufficient information about an incident. I also want to be able to catch multiple instances... so if someone attacks my server a half hour later, I need that counter to have been zero'ed (and I can presumably determine whether or not any new data is part of the previous attack or a new attack). I also want it to be completely automatic, so that if someone attacks my server while I'm asleep on the console, the machine does a reasonable job of trying to catch the information. What I absolutely need is a way to clear out the VERBOSE_LIMIT counter. If it is one counter, that is trivial. If it is a per-rule counter, I can at least write a C program to DTRT quickly via the ipfirewall ioctl interface. Just turning off logging is NOT a cool thing to suggest, unless you would not mind me suggesting that you don't need a firewall. > > > Case in point, I may at one time want to 'log' all connections to a > > > particular port, and then later ignore (no longer log) all the > > > connections to that port *except* to a particular host. Or, the reverse > > > may be true. In these cases, I don't want to have to recompile my > > > kernel to allow 'more logging' of the information. > > > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > > 3, which is required regardless... you just delete the less restrictive > > rule and replace it with a more restrictive rule. > > I want *both* rules, and I want *full* information disclosure since I > want to know how I'm being attacked. See, knowing how I'm attacked is > useful since it helps me avoid future attacks, as well as allow me > potentially stock future attacks from happening by informing an ISP of > the behavior of one of their users. Maybe that person will get on > another ISP, or maybe he'll cleanup his act. Who knows, but sitting > idle means nothing happens. Okay, so you put in both rules. It doesn't matter. What stops you from doing # sysctl -w net.inet.ip.fw.verbose_limit=0 net.inet.ip.fw.verbose_limit: 100 -> 0 to temporarily remove the limit entirely, thereby allowing both entries to log? > > > I think a 'per-rule' limit works best, instead of a global limit. This > > > also works well in the case of rootkit attempt breakins, since they tend > > > to hit one rule multiple times, and then another multiple times, etc... > > > > > > With a 'global' limit, I may end up 'limiting out' on the first rule, > > > and then miss all the rules hit later on with the attack. > > > > Yes, you might. But you might miss them anyways, and I can run you out of > > disk space quicker. > > Sure, but you have to know alot about my box to do that, and if you have > that kind of information, I can run your box out of disk space just as > easily, it takes a bit longer. > > (And, it would take you months to run my box out of disk space in it's > current setup, which is a engineering tradeoff for maximum information > retrieval balanced with the history of attacks on my system, along with > engineering paranoia about how a DoS attack could occur.) > > Again, IPFW_VERBOSE_LIMIT is *NOT* there to make for smaller logfiles, > it's there to avoid a single kind of attack made on the system. These > kinds of attacks 'tend' to focus on a single port and/or rule. Also, > having a global count also leaves you 'wide-open' for doing a DoS > attack, following by a real attack. You would no longer have any idea > how the 'real' attack is occuring, so with the current implementation, > the attacker must know your exact FW configuration in order to attack > you well. (And, I would argue that *IF* they had my FW configuration > and/or rulesets, my firewall would be almost useless since in any > system, there are tradeoffs made for 'ease-of-use' vs. security.) I'm not arguing for smaller logfiles. You don't tell a person with a several gigabyte /var about how they are arguing for smaller logfiles. I'm looking strictly at the intended purpose of IPFW_VERBOSE_LIMIT. > > > > It also makes it more difficult to code in a bunch > > > > of "log" rules, since your periodic "zero" script has to know the number of > > > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > > > get a bunch of > > > > > > > > /kernel: ipfw: Entry rule1 cleared. > > > > /kernel: ipfw: Entry rule2 cleared. > > > > /kernel: ipfw: Entry rule3 cleared. > > > > > > > > each time you do this. > > > > > > Or, you do like I do, and have a cronjob 'zero' out the entire log > > > ruleset everynight right after it sends the results to me to analyze. > > > > Interferes with your accounting counters. You need to be able to do > > them individually to avoid that. > > I'm not disagreeing. ipfw zero rule1 also interfers with your counters > as well, but only on those rules. I count on separate rules right now. :-/ > > > However, at times (during breakins I happen to catch, or during ruleset > > > debugging sessions) I still want to have control over individual rules. > > > > > > > I would rather see something like > > > > > > > > /kernel: ipfw: logging limit reached, suspending. > > > > # /sbin/ipfw zerolog > > > > /kernel: ipfw: logging limit reset, resuming. > > > > > > This is essentially what I do. But, you can do 'ipfw zero' which > > > accomplishes the same thing. > > > > No, it nukes the accounting counters. > > I've not argued that point. > > > > However, this is really a side-issue. The last thing I'll say is that I > > > think a 'global' counter is a bad idea, and this is from using IPFW for > > > years in a real/deployed FreeBSD firewall situation. It would cause me > > > more trouble than it's worth, and provide 'less' flexibility than > > > currently exists (which I use). > > > > Then your argument devolves down to one of wanting a per-rule counter and > > you don't care if it is the accounting one or a new one... > > Correct. The existing infrastructure works for me. I don't use my FW > for accounting purposes (that's what the wireless bridge is for), so I > don't care if the counters are zero'd. But, I *don't* want to see the > system modified to replace the per-rule counters with a global counter > since it has some exteremely negative side-effects, the most obnoxious > is to lose 'valid' breakin information, which is the point of having > logging in the first place. Well, you certainly lose it now, anyways, with securelevel >= 3 unless you happen to be made aware of the attack in some other manner, because once you hit IPFW_VERBOSE_LIMIT, the system just stops logging. You haven't provided any helpful suggestions about how to deal with this. You can argue that you want per-rule limits, and you've done so, but I think it is safe to say that both ways have merits. > > And I've been using FreeBSD and IPFW in a real/deployed environment as well, > > and I keep hitting up against these goofy sorts of problems. It is much, > > much more usable than something like ipfw in 2.1R or earlier, but these > > little things still matter. > > The changes in 2.1 affected quite a bit, but all it required me to do > was to rewrite my FW rules. I saw very little 'functionality' > additions, just changes made that required me to re-write how I was > doing things. Since the firewall is a 'side' job of mine, it was a pain > in the butt to do it, but now that's (long) past. :) > > > > The real issue from your first email is '*should* ipfw rules be > > > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > > > administrator can't think of any bad things that could occur, but I can > > > imagine something bad happening if someone were allowed to do this, > > > although it's not completely concrete. I don't have the brain-cells to > > > dedicate to thinking about the full implications of a 'bad-guy' zeroing > > > out my rules. > > > > He interferes with whatever other features you've built into the system > > which rely on those accounting numbers. I agree - you probably don't > > want to do that. > > One could argue that accounting numbers in a firewall shouldn't be > trusted, but I won't argue that point since the firewall is often the > most 'natural' place to stick network accounting software. If you can't trust something in the kernel, then you just can't trust anything at all. > > Well, the 'right' thing is clear: pull the limit count out of the > > accounting count. This solves both the problem of zeroing accounting > > counters and potentially messing with other things, and also of letting > > people do anything 'negative' in securelevel 3. > > Is it the 'right' thing to do? I think that someone messing with the > 'logging' rule counts could be just as dangerous as someone messing with > the accounting counts. It is no more dangerous, and somebody zeroing (the only thing they should be able to do!) the logging rule counts would result in additional logging going on... this might mess up any sort of deterministic disk space calculation that you had going on, but if it was really an issue, you could also set up a sysctl variable or kernel #define that would forbid even this - which lands you back right where we are, if you choose that, but gives everyone else who needs it the option to do automated logging. > Again, if you're paranoid enough to have securelevel 3, you've got to be > paranoid enough to assume that someone *HAS* root access on your box, > and is going to do anything nasty they could. Yes, but causing additional logging to happen is going to be something that is likely to _attract_ my attention. > > By pulling the limit count out into a separate entity, nothing > > 'negative' can happen (because stopping the logging process is > > definitely negative, and being able to restart it without messing with > > other stuff is positive). > > I'm not sure this is an acceptable change either, but I'll leave that > discussion to the networking folks. > > > Now that we are agreed that the limit count needs to be divorced from the > > accounting count, we can debate whether it should be a per-rule or global > > limit. > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > putting words in my mouth. :) :) Well, then, how do you "fix" this problem? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 15: 4:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 288C214BCF for ; Mon, 26 Jul 1999 15:04:36 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id RAA71958; Mon, 26 Jul 1999 17:02:05 -0500 (CDT) (envelope-from dan) Date: Mon, 26 Jul 1999 17:02:05 -0500 From: Dan Nelson To: Sheldon Hearn Cc: Mark Murray , hackers@FreeBSD.ORG, David Bushong Subject: Re: file(1) Magdir candidate: wintendo Message-ID: <19990726170205.B71445@dan.emsphone.com> References: <199907262130.XAA22405@gratis.grondar.za> <245.933024821@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <245.933024821@axl.noc.iafrica.com>; from "Sheldon Hearn" on Mon Jul 26 23:33:41 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jul 26), Sheldon Hearn said: > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops > my pcgames suggestion? What about multi-OS games, like Quake? How about just calling it "games" ? -- Dan Nelson dnelson@emsphone.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 26 15:29:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mbox.ttm.bg (mbox.ttm.bg [195.230.0.14]) by hub.freebsd.org (Postfix) with ESMTP id A78BF150B9 for ; Mon, 26 Jul 1999 15:29:39 -0700 (PDT) (envelope-from ian@bulinfo.net) Received: from cserv.oksys.bg (ipp-8-067-sofia.ttm.bg [195.230.8.67] (may be forged)) by mbox.ttm.bg (8.9.3/8.9.3) with ESMTP id BAA14752 for ; Tue, 27 Jul 1999 01:26:53 +0300 Received: from bulinfo.net (ian@localhost [127.0.0.1]) by cserv.oksys.bg (8.9.3/8.9.3) with ESMTP id BAA74499 for ; Tue, 27 Jul 1999 01:19:48 +0300 (EEST) (envelope-from ian@bulinfo.net) Message-ID: <379CDF04.334D0A6F@bulinfo.net> Date: Tue, 27 Jul 1999 01:19:48 +0300 From: Iani Brankov Organization: ok systems X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: hot-swapping ata disks Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). Or maybe i'm walking on a wrong way? --iani To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 16:20:14 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 08DB114E2F for ; Mon, 26 Jul 1999 16:20:10 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA15586; Mon, 26 Jul 1999 17:18:31 -0600 (MDT) (envelope-from ken) Message-Id: <199907262318.RAA15586@panzer.kdm.org> Subject: Re: hot-swapping ata disks In-Reply-To: <379CDF04.334D0A6F@bulinfo.net> from Iani Brankov at "Jul 27, 1999 01:19:48 am" To: ian@bulinfo.net (Iani Brankov) Date: Mon, 26 Jul 1999 17:18:31 -0600 (MDT) Cc: 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 [ I don't know about the IDE code, but I can say something about the SCSI code. ] Iani Brankov wrote... > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) Hot-swapping SCSI devices may or may not be risky. It really depends on your bus topology and whether your setup was designed for it. In general, it's best to only do it in a hot-swap chassis. You can also do it with more conventional cable layouts, provided you don't end up disabling termination or taking something off the bus while I/O is going to it, etc. I wrote a fair bit of the hot swap code with an external CDROM drive in the middle of a terminated external chain. The drive stayed on the chain at all times, but I turned it off and on to make it go away and come back between rescans. > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I dunno about the IDE code, although I'm sure Soren will have an answer. 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 Mon Jul 26 16:29:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from icg.interactivate.com (icg.interactivate.com [207.110.42.216]) by hub.freebsd.org (Postfix) with ESMTP id 405E614E1B for ; Mon, 26 Jul 1999 16:29:18 -0700 (PDT) (envelope-from lomion@cx47987-b.escnd1.sdca.home.com) Received: from cx47987-c (cx47987-c.escnd1.sdca.home.com [24.0.175.251]) by icg.interactivate.com (8.9.3/8.9.3) with ESMTP id QAA01864; Mon, 26 Jul 1999 16:29:02 -0700 (PDT) Message-Id: <4.2.0.56.19990726042128.00963f00@mail.interactivate.com> X-Sender: lomion@mail.anais-nin.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Mon, 26 Jul 1999 04:22:45 -0700 To: Dan Nelson , Sheldon Hearn From: lomion Subject: Re: file(1) Magdir candidate: wintendo Cc: Mark Murray , hackers@FreeBSD.ORG, David Bushong In-Reply-To: <19990726170205.B71445@dan.emsphone.com> References: <245.933024821@axl.noc.iafrica.com> <199907262130.XAA22405@gratis.grondar.za> <245.933024821@axl.noc.iafrica.com> 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 At 05:02 PM 7/26/99 -0500, Dan Nelson wrote: >In the last episode (Jul 26), Sheldon Hearn said: > > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > > You could start with "WinEXE". > > > > Save game file formats, not game executables. You think WinEXE tops > > my pcgames suggestion? > >What about multi-OS games, like Quake? How about just calling it >"games" ? How about the obvious: svgames --larry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 17:29:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 4AF2A14DA3 for ; Mon, 26 Jul 1999 17:29:24 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA23282 for ; Mon, 26 Jul 1999 17:29:22 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Mon, 26 Jul 1999 17:29:20 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-hackers@freebsd.org Subject: XFree 3.3.4 not on ftp.freebsd.org? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was trying in vain today to get X 3.3.4 installed on my new system and couldn't seem to make it happen using sysinstall, even after I rebuilt it. AFAICS, there is no XFree 3.3.4 package available on ftp.freebsd.org/pub/FreeBSD, but I may have missed something. Fortunately it is on wcarchive, so I just pulled down all the bits and installed it the "hard" way, however I know I'm going to run into trouble down the road when ports start looking for the X stuff in /var/db/pkg. Any comments 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 18: 0:52 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 921151503E for ; Mon, 26 Jul 1999 18:00: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 SAA00738; Mon, 26 Jul 1999 18:01:35 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Josef Karthauser Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: VMWare plug/quickie tests. In-reply-to: Your message of "Mon, 26 Jul 1999 01:27:34 BST." <19990726012734.A88472@pavilion.net> Date: Mon, 26 Jul 1999 18:01:35 -0700 Message-ID: <734.933037295@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I just wish that it was the other way around. I'd actually run > NT if I could get it in a VMWare compartment under FreeBSD. You would do well to pass these sentiments on to vmware; they're currently counting noses in FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 18:11: 4 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 D89C115177 for ; Mon, 26 Jul 1999 18:10:53 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp6493.on.bellglobal.com [206.172.208.85]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id VAA08653; Mon, 26 Jul 1999 21:11:03 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id VAA45724; Mon, 26 Jul 1999 21:09:51 -0400 (EDT) (envelope-from tim) Date: Mon, 26 Jul 1999 21:09:50 -0400 From: Tim Vanderhoek To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? Message-ID: <19990726210950.A45538@mad> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Doug on Mon, Jul 26, 1999 at 05:29:20PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999 at 05:29:20PM -0700, Doug wrote: > > and installed it the "hard" way, however I know I'm going to run into > trouble down the road when ports start looking for the X stuff in > /var/db/pkg. I seem to remember that you can get away with a simple "mkdir /var/db/pkg/xxx" to fake it. Alternatively, $ cd /usr/ports/x11/XFree86 ; make generate-plist fake-pkg should be a little more correct. -- 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 Mon Jul 26 18:16: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from web805.mail.yahoo.com (web805.mail.yahoo.com [128.11.23.65]) by hub.freebsd.org (Postfix) with SMTP id 4429915022 for ; Mon, 26 Jul 1999 18:15:59 -0700 (PDT) (envelope-from raysonlogin@yahoo.com) Message-ID: <19990727011825.11692.rocketmail@web805.mail.yahoo.com> Received: from [128.100.13.59] by web805.mail.yahoo.com; Mon, 26 Jul 1999 21:18:25 EDT Date: Mon, 26 Jul 1999 21:18:25 -0400 (EDT) From: Rayson Ho Subject: Free BSDI CD! To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am not sure whether this is known to this list or not, but here is the URL for ordering: http://www.bsdi.com/products/evalcd/ _________________________________________________________ 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 Mon Jul 26 19:58: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 797E414BEC; Mon, 26 Jul 1999 19:58:38 -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 WAA36713; Mon, 26 Jul 1999 22:56:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 22:56:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Joe Greco Cc: Matthew Dillon , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261907.OAA08989@aurora.sol.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) 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 26 20: 8:20 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 C1DD914BFF; Mon, 26 Jul 1999 20:08:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49737; Mon, 26 Jul 1999 20:07:38 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:07:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270307.UAA49737@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -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 26 20:15: 9 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 89F8114CF7; Mon, 26 Jul 1999 20:15:05 -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 XAA37091; Mon, 26 Jul 1999 23:12:37 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:12:37 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270307.UAA49737@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 Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. > > What we are really discussing here is the use of ipfw's counters in an > unsophisticated setup. The sophisticated setup is already handled. That doesn't mean we shouldn't allow people to have an unsophisticated setup, just because a sophisticated one is available. It would be useful to have a per-firewall-rule counter, decrement it on each match if logging and set, and be able to reset to something higher. > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" 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 Mon Jul 26 20:16:34 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 105CC1505D for ; Mon, 26 Jul 1999 20:16:28 -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 XAA37120; Mon, 26 Jul 1999 23:14:12 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:14:12 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: Mark Murray , hackers@FreeBSD.org, David Bushong Subject: Re: file(1) Magdir candidate: wintendo In-Reply-To: <245.933024821@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 Mon, 26 Jul 1999, Sheldon Hearn wrote: > > > On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote: > > > You could start with "WinEXE". > > Save game file formats, not game executables. You think WinEXE tops my > pcgames suggestion? No. How about "savegames"? The Quake 2 format in there would be nice, to distinguish between Q2 Windows version X.XX and Linux glibc, Linux libc5, etc... > > Ciao, > Sheldon. > > > 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 Mon Jul 26 20:16:46 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 0157115189; Mon, 26 Jul 1999 20:16:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49808; Mon, 26 Jul 1999 20:16:39 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:16:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270316.UAA49808@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -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 26 20:22:27 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 5278F14CF7 for ; Mon, 26 Jul 1999 20:22:23 -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 XAA37291; Mon, 26 Jul 1999 23:21:53 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:21:53 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Rayson Ho Cc: freebsd-hackers@FreeBSD.org Subject: Re: Free BSDI CD! In-Reply-To: <19990727011825.11692.rocketmail@web805.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 On Mon, 26 Jul 1999, Rayson Ho wrote: > Hi, > > I am not sure whether this is known to this list or > not, but here is the URL for ordering: > > http://www.bsdi.com/products/evalcd/ > But we can install from a single downloaded boot floppy, over the Internet, which is better. > > > _________________________________________________________ > 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 > 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 26 20:23: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 5A41014CF7; Mon, 26 Jul 1999 20:23:38 -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 XAA37317; Mon, 26 Jul 1999 23:22:25 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:22:24 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270316.UAA49808@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 Mon, 26 Jul 1999, Matthew Dillon wrote: > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Which is what I am advocating against. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" 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 Mon Jul 26 20:43: 0 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 E99EB151CC; Mon, 26 Jul 1999 20:42:56 -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 UAA82669; Mon, 26 Jul 1999 20:42:21 -0700 (PDT) Date: Mon, 26 Jul 1999 20:42:20 -0700 (PDT) From: Julian Elischer To: "Brian F. Feldman" Cc: Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero 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 like the ability at secure level 3 to only reset the counters forward.. It fits in with such things as the "append only" flag. Maybe a new keyword. "advance" julian On Mon, 26 Jul 1999, Brian F. Feldman wrote: > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > > > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > > :just because a sophisticated one is available. It would be useful to have > > :a per-firewall-rule counter, decrement it on each match if logging and > > :set, and be able to reset to something higher. > > : > > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > > > There may be some confusion here. I am advocating that we *allow* the > > zeroing of counters at secure level 3. > > Which is what I am advocating against. > > > > > -Matt > > Matthew Dillon > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-ipfw" 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 20:51: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 45DF1151CC; Mon, 26 Jul 1999 20:51:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49943; Mon, 26 Jul 1999 20:48:28 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:48:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270348.UAA49943@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> :> :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :> :just because a sophisticated one is available. It would be useful to have :> :a per-firewall-rule counter, decrement it on each match if logging and :> :set, and be able to reset to something higher. :> : :> : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ :> :> There may be some confusion here. I am advocating that we *allow* the :> zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 21: 4: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 99C6714D38; Mon, 26 Jul 1999 21:04:27 -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 WAA65739; Mon, 26 Jul 1999 22:03:43 -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 WAA50339; Mon, 26 Jul 1999 22:04:50 -0600 (MDT) Message-Id: <199907270404.WAA50339@harmony.village.org> To: "Brian F. Feldman" Subject: Re: Free BSDI CD! Cc: Rayson Ho , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 26 Jul 1999 23:21:53 EDT." References: Date: Mon, 26 Jul 1999 22:04:50 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : But we can install from a single downloaded boot floppy, over the : Internet, which is better. Is that still true? I thought we went back to two floppies to do this... 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 26 21: 9:39 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 5EAD714D38 for ; Mon, 26 Jul 1999 21:09:33 -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 AAA08348 for ; Tue, 27 Jul 1999 00:16:28 -0400 (EDT) Date: Tue, 27 Jul 1999 00:16:28 -0400 (EDT) From: Marc Nicholas X-Sender: marc@medulla.hippocampus.net To: freebsd-hackers@freebsd.org Subject: Re: Free BSDI CD! In-Reply-To: <199907270404.WAA50339@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 I needed a new drinks coaster... ;-) -marc ---------------------------------------------------------------- Marc Nicholas netSTOR Technologies, Inc. http://www.netstor.com 1.877.464.4776 416.979.9000 fax: 416.979.8223 cell: 416.346.9255 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 22:30:12 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 69F6714FA4 for ; Mon, 26 Jul 1999 22:30:06 -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 118zo9-000MdV-00; Tue, 27 Jul 1999 07:29:45 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: Doug , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-reply-to: Your message of "Mon, 26 Jul 1999 21:09:50 -0400." <19990726210950.A45538@mad> Date: Tue, 27 Jul 1999 07:29:45 +0200 Message-ID: <87016.933053385@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > I seem to remember that you can get away with a simple "mkdir > /var/db/pkg/xxx" to fake it. Can you think of any ports that test for the existance of XFree86 using the package system? They use USE_X_PREFIX or USE_X_LIB, both of which test for libX11, no? 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 26 22:37: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 7253D14FA4 for ; Mon, 26 Jul 1999 22:37:39 -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 118zva-000MfH-00; Tue, 27 Jul 1999 07:37:26 +0200 From: Sheldon Hearn To: Matthew Dillon Cc: hackers@freebsd.org Subject: securelevel too course-grained? In-reply-to: Your message of "Mon, 26 Jul 1999 20:48:28 MST." <199907270348.UAA49943@apollo.backplane.com> Date: Tue, 27 Jul 1999 07:37:26 +0200 Message-ID: <87126.933053846@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 20:48:28 MST, Matthew Dillon wrote: > Subject: Re: securelevel and ipfw zero > > However, it does not allow you to do it if you are sitting at secure > level 3. You don't think that this discussion highlights the growing inadequacy of the securelevel mechanism's lack of granularity? I have a feeling it'll be time soon enough for us to make each of the decisions that is normally affected by securelevel dependant on the value of sysctl knobs. Presumeably one or more of them would be "write-once" knobs. :-) How much existing software tests for kern.securelevel? And could we make its value dependant on the new knobs? I can't see it being too big a problem. 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 26 22:42:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id BE8E814FA4 for ; Mon, 26 Jul 1999 22:42:43 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id WAA25371; Mon, 26 Jul 1999 22:41:24 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379D4684.FE083FB@gorean.org> Date: Mon, 26 Jul 1999 22:41:24 -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: Sheldon Hearn Cc: Tim Vanderhoek , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? References: <87016.933053385@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 21:09:50 -0400, Tim Vanderhoek wrote: > > > I seem to remember that you can get away with a simple "mkdir > > /var/db/pkg/xxx" to fake it. > > Can you think of any ports that test for the existance of XFree86 using > the package system? They use USE_X_PREFIX or USE_X_LIB, both of which > test for libX11, no? Well, in an ideal world the ports that need parts of X would only test for the parts that they need. However right after 3.2-R came out there was a flurry of -questions mail about broken pkg dependencies because sysinstall wasn't properly registering the X install. If the port depending on the existence of /var/db/pkg/X* is actually an error I'll report what I find to the -ports list. Thanks, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 22:44:34 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 1AD88152B9 for ; Mon, 26 Jul 1999 22:44:25 -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 119020-000MgW-00; Tue, 27 Jul 1999 07:44:04 +0200 From: Sheldon Hearn To: Doug Cc: Tim Vanderhoek , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-reply-to: Your message of "Mon, 26 Jul 1999 22:41:24 MST." <379D4684.FE083FB@gorean.org> Date: Tue, 27 Jul 1999 07:44:04 +0200 Message-ID: <87203.933054244@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > However right after 3.2-R came out there was a flurry of -questions > mail about broken pkg dependencies because sysinstall wasn't properly > registering the X install. Is this a different problem from the broken compat22 installation? > If the port depending on the existence of /var/db/pkg/X* is actually > an error I'll report what I find to the -ports list. I'm pretty sure it constitutes "non-conformant" behaviour and I'd be happy to look at it. 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 26 22:53:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 73CEB14FA4 for ; Mon, 26 Jul 1999 22:53:19 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id WAA25425; Mon, 26 Jul 1999 22:51:21 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379D48D9.60D8E9DA@gorean.org> Date: Mon, 26 Jul 1999 22:51:21 -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: Sheldon Hearn Cc: Tim Vanderhoek , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? References: <87203.933054244@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 26 Jul 1999 22:41:24 MST, Doug wrote: > > > However right after 3.2-R came out there was a flurry of -questions > > mail about broken pkg dependencies because sysinstall wasn't properly > > registering the X install. > > Is this a different problem from the broken compat22 installation? Yes. > > If the port depending on the existence of /var/db/pkg/X* is actually > > an error I'll report what I find to the -ports list. > > I'm pretty sure it constitutes "non-conformant" behaviour and I'd be > happy to look at it. Hrrmm... come to think of it, I think that the problem actually amounted to the ports not being able to register after installation was done. In other words, (IIRC) after they were built and installed ports that depended on X were unable to insert their +REQUIRED_BY entries, so this would not constitute "broken." However, I'm a bit fuzzy on it, and I'm very tired so I'm not sure. If I find anything odd I'll report it. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 26 23:55:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id F2F8714F87 for ; Mon, 26 Jul 1999 23:54:50 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id OAA09742 for ; Tue, 27 Jul 1999 14:53:26 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id OAA16863 for ; Tue, 27 Jul 1999 14:54:43 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id OAA04847; Tue, 27 Jul 1999 14:54:43 +0800 Message-Id: <199907270654.OAA04847@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: Unpacking Debian packages on FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jul 1999 14:54:43 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to grope around inside a .deb file, which has been created on a debian Linux box. Do we have any nifty tools for this, like rpm2cpio? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0: 3:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (Postfix) with ESMTP id 1366B14FC2 for ; Tue, 27 Jul 1999 00:03:31 -0700 (PDT) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from dzeta.ms.mff.cuni.cz (mkop5230@dzeta.ms.mff.cuni.cz [195.113.16.101]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id JAA30908; Tue, 27 Jul 1999 09:01:26 +0200 Received: from localhost (mkop5230@localhost) by dzeta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with ESMTP id JAA34479; Tue, 27 Jul 1999 09:01:25 +0200 (MDT) Date: Tue, 27 Jul 1999 09:01:24 +0200 From: Milan Kopacka Reply-To: Milan Kopacka To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@FreeBSD.ORG Subject: Re: Unpacking Debian packages on FreeBSD In-Reply-To: <199907270654.OAA04847@ariadne.tensor.pgs.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, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I'd like to grope around inside a .deb file, which has been created on a > debian Linux box. Do we have any nifty tools for this, like rpm2cpio? You can use ar ar x package.deb Milan Kopacka To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0: 9:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id B939A14F64 for ; Tue, 27 Jul 1999 00:09:19 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id AAA01274; Tue, 27 Jul 1999 00:07:37 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Tue, 27 Jul 1999 00:07:37 -0700 Date: Tue, 27 Jul 1999 00:07:37 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: "Jordan K. Hubbard" Cc: Josef Karthauser , Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: VMWare plug/quickie tests. In-Reply-To: <734.933037295@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: jkh@zippy.cdrom.com,joe@pavilion.net,mrcpu@internetcds.com,hackers@FreeBSD.ORG X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there anyone in particular to whom we should write at VMWare? I agree with his sentiments. -Kip On Mon, 26 Jul 1999, Jordan K. Hubbard wrote: > > I just wish that it was the other way around. I'd actually run > > NT if I could get it in a VMWare compartment under FreeBSD. > > You would do well to pass these sentiments on to vmware; they're > currently counting noses in FreeBSD-land to see if it makes > market sense. All the techs there appear to be sold on the idea, > but it takes more than tech buy-in to get a project approved. :) > > - Jordan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0:28:32 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 E331E14DFA for ; Tue, 27 Jul 1999 00:28:26 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id JAA11713; Tue, 27 Jul 1999 09:28:09 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907270728.JAA11713@freebsd.dk> Subject: Re: hot-swapping ata disks In-Reply-To: <379CDF04.334D0A6F@bulinfo.net> from Iani Brankov at "Jul 27, 1999 1:19:48 am" To: ian@bulinfo.net (Iani Brankov) Date: Tue, 27 Jul 1999 09:28:09 +0200 (CEST) Cc: 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 Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) > > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0:32:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.axis.de (hermes.axis.de [194.163.241.7]) by hub.freebsd.org (Postfix) with SMTP id ADCCC14DFA for ; Tue, 27 Jul 1999 00:32:54 -0700 (PDT) (envelope-from maret@axis.de) Received: from erlangen01.axis.de by hermes.axis.de via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 27 Jul 1999 07:32:56 UT Received: (private information removed) Message-ID: <91DA20EC3C3DD211833400A0245A4EA9BA10A8@erlangen01.axis.de> From: Alexander Maret To: "'freebsd-hackers@freebsd.org'" Subject: Which /etc-files do I need until vinum is initialized? Date: Tue, 27 Jul 1999 09:32:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Regards, Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0:37:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1x.pvt.net (ns.pvt.net [194.149.105.18]) by hub.freebsd.org (Postfix) with ESMTP id 23B6914F7B for ; Tue, 27 Jul 1999 00:37:17 -0700 (PDT) (envelope-from papezik@pvt.net) Received: from mail1.pvt.net (news.pvtnet.cz [194.149.101.166]) by ns1x.pvt.net (8.9.3/8.9.3) with ESMTP id JAA10269 for ; Tue, 27 Jul 1999 09:34:14 +0200 Received: from pvt.net (papezik.pvt.net [194.149.103.213]) by mail1.pvt.net (8.9.3/8.9.3) with ESMTP id JAA87868; Tue, 27 Jul 1999 09:34:13 +0200 (CEST) Message-ID: <379D6112.A6BADAFE@pvt.net> Date: Tue, 27 Jul 1999 09:34:42 +0200 From: Papezik Milon X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: cs, cz, sk, en MIME-Version: 1.0 To: hackers@freebsd.org Subject: FibreChannel support ? Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, only simple question :-) Does FreeBSD support any FibreChannel controller or does body somebody writing a drive? For which card card? Thanks in advance. Milon -- papezik@pvt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 0:45:18 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 60AC81534B for ; Tue, 27 Jul 1999 00:45:12 -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 RAA20859; Tue, 27 Jul 1999 17:12:50 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id RAA64217; Tue, 27 Jul 1999 17:12:49 +0930 (CST) Date: Tue, 27 Jul 1999 17:12:49 +0930 From: Greg Lehey To: Alexander Maret Cc: freebsd-hackers@freebsd.org Subject: Re: Which /etc-files do I need until vinum is initialized? Message-ID: <19990727171249.X62218@freebie.lemis.com> References: <91DA20EC3C3DD211833400A0245A4EA9BA10A8@erlangen01.axis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <91DA20EC3C3DD211833400A0245A4EA9BA10A8@erlangen01.axis.de>; from Alexander Maret on Tue, Jul 27, 1999 at 09:32:51AM +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 Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: > Hi, > > I configured vinum (RAID 1) on a 3.2S System. As I want to mirror > as much as I need to keep the system running (in case of a drive 1 > failure) I mirrored /etc as well. At boot time (until vinum is > initialized) the system only has the following files: > > /etc/defaults/rc.conf > /etc/rc.conf > /etc/rc > /etc/fstab > /etc/gettytab > /etc/login.conf > /etc/ttys > > Do I need all of these files or can I put some of them away > (for example /etc/ttys or /etc/gettytab)? The files > would of course be available as soon as vinum is initialized > and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: > /etc/gettytab > /etc/login.conf > /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n "$vinum_drives" ]; then vinum read $vinum_drives mount /etc fi 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 Tue Jul 27 0:47:43 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 CCA6F15366 for ; Tue, 27 Jul 1999 00:47:28 -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 AAA20955; Tue, 27 Jul 1999 00:46:03 -0700 Date: Tue, 27 Jul 1999 00:45:55 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Papezik Milon Cc: hackers@FreeBSD.ORG Subject: Re: FibreChannel support ? In-Reply-To: <379D6112.A6BADAFE@pvt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Support exists for the Qlogic 2100 and 2200 FC-AL cards. On Tue, 27 Jul 1999, Papezik Milon wrote: > Hi all, > > only simple question :-) > > Does FreeBSD support any FibreChannel controller > or does body somebody writing a drive? > For which card card? > > Thanks in advance. > Milon > -- > papezik@pvt.net > > > 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 27 0:59:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy.sdf.se (proxy.sdf.se [195.84.137.231]) by hub.freebsd.org (Postfix) with ESMTP id B4D441533F for ; Tue, 27 Jul 1999 00:59:16 -0700 (PDT) (envelope-from ankan@sdf.se) Received: from traal.sdf.se (ankan@traal.sdf.se [192.168.1.16]) by proxy.sdf.se (8.9.3/8.9.3) with ESMTP id JAA78587 for ; Tue, 27 Jul 1999 09:58:14 +0200 (CEST) Received: from localhost by traal.sdf.se (8.9.1/8.9.1) with ESMTP id JAA21286 for ; Tue, 27 Jul 1999 09:58:11 +0200 (MET DST) Date: Tue, 27 Jul 1999 09:58:10 +0200 (MET DST) From: Anders Vidmark To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Im getting unreferenced inodes that fills up /. The box is running freebsd 2.2.6-release and sendmail 8.8.8 Sendmails databases are rebuilt once every half hour. It seems like the unref. inodes comes from spammers.db and domainalias.db. Is there a way to avoid this? Will it get better if I upgrade to freebsd 3.2? upgrade sendmail? TIA Anders Vidmark ankan@sdf.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 1: 0:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.axis.de (hermes.axis.de [194.163.241.7]) by hub.freebsd.org (Postfix) with SMTP id 17C9A152EA for ; Tue, 27 Jul 1999 01:00:30 -0700 (PDT) (envelope-from maret@axis.de) Received: from erlangen01.axis.de by hermes.axis.de via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 27 Jul 1999 08:00:31 UT Received: (private information removed) Message-ID: <91DA20EC3C3DD211833400A0245A4EA9BA10A9@erlangen01.axis.de> From: Alexander Maret To: 'Greg Lehey' Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Which /etc-files do I need until vinum is initialized? Date: Tue, 27 Jul 1999 09:59:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, thanks for your answer. I'll try and remove /etc/ttys and /etc/gettytab as well. I'm not so sure about /etc/login.conf because I already tried to remove it and at boottime the system began to whine about a missing class (daemon). Well, the system booted and all daemons were running but I'm not sure which effect the missing class has. Regards, Alex > -----Original Message----- > From: Greg Lehey [mailto:grog@lemis.com] > Sent: Dienstag, 27. Juli 1999 09:43 > To: Alexander Maret > Cc: freebsd-hackers@freebsd.org > Subject: Re: Which /etc-files do I need until vinum is initialized? > > > On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: > > Hi, > > > > I configured vinum (RAID 1) on a 3.2S System. As I want to mirror > > as much as I need to keep the system running (in case of a drive 1 > > failure) I mirrored /etc as well. At boot time (until vinum is > > initialized) the system only has the following files: > > > > /etc/defaults/rc.conf > > /etc/rc.conf > > /etc/rc > > /etc/fstab > > /etc/gettytab > > /etc/login.conf > > /etc/ttys > > > > Do I need all of these files or can I put some of them away > > (for example /etc/ttys or /etc/gettytab)? The files > > would of course be available as soon as vinum is initialized > > and /etc mounted. > > Interesting question. In view of the fact that I intend to make the > root file system bootable One Of These Days, I don't think you should > go to too much trouble here: after all, they're only a few kilobytes > each. But I think you could eliminate these ones: > > > /etc/gettytab > > /etc/login.conf > > /etc/ttys > > You might find it advantageous to modify /etc/rc to mount /etc (and > anything else you want) immediately after starting Vinum: > > if [ X$start_vinum = XYES ]; then > vinum start > mount /etc > elif [ -n "$vinum_drives" ]; then > vinum read $vinum_drives > mount /etc > fi > > 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 Tue Jul 27 1:32:58 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 F275814E83 for ; Tue, 27 Jul 1999 01:32:52 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id JAA24564; Tue, 27 Jul 1999 09:32:43 +0100 (BST) (envelope-from joe) Date: Tue, 27 Jul 1999 09:32:43 +0100 From: Josef Karthauser To: "Jordan K. Hubbard" Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: VMWare plug/quickie tests. Message-ID: <19990727093242.C18105@pavilion.net> References: <19990726012734.A88472@pavilion.net> <734.933037295@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <734.933037295@zippy.cdrom.com>; from Jordan K. Hubbard on Mon, Jul 26, 1999 at 06:01:35PM -0700 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 Mon, Jul 26, 1999 at 06:01:35PM -0700, Jordan K. Hubbard wrote: > > I just wish that it was the other way around. I'd actually run > > NT if I could get it in a VMWare compartment under FreeBSD. > > You would do well to pass these sentiments on to vmware; they're > currently counting noses in FreeBSD-land to see if it makes > market sense. All the techs there appear to be sold on the idea, > but it takes more than tech buy-in to get a project approved. :) > > - Jordan I _have_ written to them. If you look at the archives you'll see that I was one of the first :b. 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 27 2:44: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 CB8C115093 for ; Tue, 27 Jul 1999 02:44:48 -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 LAA36149; Tue, 27 Jul 1999 11:44:38 +0200 (CEST) (envelope-from des) To: Peter Jeremy Cc: will@iki.fi, hackers@FreeBSD.ORG Subject: Re: Proposal for new syscall to close files References: <99Jul21.211359est.40325@border.alcanet.com.au> From: Dag-Erling Smorgrav Date: 27 Jul 1999 11:44:37 +0200 In-Reply-To: Peter Jeremy's message of "Wed, 21 Jul 1999 21:32:22 +1000" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: > > If it ever gets > >committed (I don't think it's particularly useful myself), > That's 2 against, 1 (me) for. Three against. 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 27 3: 9: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 CC32F1539B for ; Tue, 27 Jul 1999 03:09:39 -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 MAA36662; Tue, 27 Jul 1999 12:07:25 +0200 (CEST) (envelope-from des) To: Jaye Mathisen Cc: Jason Young , Matthew Dillon , Papezik Milon , hackers@FreeBSD.ORG Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c References: From: Dag-Erling Smorgrav Date: 27 Jul 1999 12:07:24 +0200 In-Reply-To: Jaye Mathisen's message of "Thu, 22 Jul 1999 14:58:36 -0700 (PDT)" Message-ID: Lines: 8 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jaye Mathisen writes: > Maybe it could be made a sysctl knob... No, a socket option would be more appropriate. 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 27 3:10:29 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 17C811538A; Tue, 27 Jul 1999 03:09:50 -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 11949a-0000vl-00; Tue, 27 Jul 1999 12:08:10 +0200 From: Sheldon Hearn To: obrien@freebsd.org Cc: hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group Date: Tue, 27 Jul 1999 12:08:10 +0200 Message-ID: <3580.933070090@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi David, Your commit catalogued in the cvs log for newsyslog.c: revision 1.23 date: 1999/06/28 03:15:02; author: obrien; state: Exp; lines: +2 -2 Syntax for user/group is changed from "user.group" to "user:group" to be consistant with chown(8). This one raised a number of eyebrows and a few people asked you to hold on to legacy support for a single release. It's a reasonable request, given the obscure error message one gets for providing the previously supported syntax: newsyslog: error in config file; bad permissions: /var/log/exim/mainlog exim.mail 640 7 * 24 Z Is the reason you haven't re-instated legacy support because you are strongly opposed to it, or because you don't have time? If it's the latter, I'll do it. If the former, note that your commit message was broken, since chown(8) supports both periods and colons. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 3:34:22 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 715DD1538A for ; Tue, 27 Jul 1999 03:34:17 -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 GAA44635; Tue, 27 Jul 1999 06:32:28 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 06:32:28 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Warner Losh Cc: Rayson Ho , freebsd-hackers@FreeBSD.org Subject: Re: Free BSDI CD! In-Reply-To: <199907270404.WAA50339@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 Mon, 26 Jul 1999, Warner Losh wrote: > In message > "Brian > F. Feldman" writes: > : But we can install from a single downloaded boot floppy, over the > : Internet, which is better. > > Is that still true? I thought we went back to two floppies to do > this... It depends on the size of your disks. For me, it's LS-120s, so do you think that should take 2 of em? :) > > Warner > 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 27 3:54:52 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 08F9514ECA for ; Tue, 27 Jul 1999 03:54:44 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere ([206.172.130.88]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id GAA11775; Tue, 27 Jul 1999 06:57:26 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id GAA32821; Tue, 27 Jul 1999 06:54:32 -0400 (EDT) (envelope-from tim) Date: Tue, 27 Jul 1999 06:54:32 -0400 From: Tim Vanderhoek To: Doug Cc: Sheldon Hearn , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? Message-ID: <19990727065431.A32516@mad> References: <87016.933053385@axl.noc.iafrica.com> <379D4684.FE083FB@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <379D4684.FE083FB@gorean.org>; from Doug on Mon, Jul 26, 1999 at 10:41:24PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 26, 1999 at 10:41:24PM -0700, Doug wrote: > > the parts that they need. However right after 3.2-R came out there was a > flurry of -questions mail about broken pkg dependencies because sysinstall > wasn't properly registering the X install. If the port depending on the > existence of /var/db/pkg/X* is actually an error I'll report what I find to > the -ports list. You need to specify "port, eg. /usr/ports/x/y" or "package". I'd be surprised if you find any port that depends on /var/db/pkg/x. It used to be that packages would depend on X, but Sheldon reminded me (although I think it was accidental :-) that XFree86 was added to PACKAGE_IGNORE_DEPENDS to prevent this. Thus, only /usr/ports should depend on X. Few if any of these should be looking through ${PKG_DBDIR} for information. No packages should depend on X. -- 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 27 3:55:27 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 19A5315397 for ; Tue, 27 Jul 1999 03:55:24 -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 GAA45033; Tue, 27 Jul 1999 06:55:13 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 06:55:12 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@FreeBSD.org Subject: Re: Unpacking Debian packages on FreeBSD In-Reply-To: <199907270654.OAA04847@ariadne.tensor.pgs.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, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I'd like to grope around inside a .deb file, which has been created on a > debian Linux box. Do we have any nifty tools for this, like rpm2cpio? I would look for something called "alien", which supposedly can convert packages between formats. you should be able to find it on FreshMeat. > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > 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 27 3:57:31 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 442E514D25; Tue, 27 Jul 1999 03:57:25 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere ([206.172.130.88]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id HAA12178; Tue, 27 Jul 1999 07:00:42 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id GAA32834; Tue, 27 Jul 1999 06:57:50 -0400 (EDT) (envelope-from tim) Date: Tue, 27 Jul 1999 06:57:49 -0400 From: Tim Vanderhoek To: Sheldon Hearn Cc: obrien@freebsd.org, hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group Message-ID: <19990727065749.B32516@mad> References: <3580.933070090@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <3580.933070090@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 27, 1999 at 12:08:10PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 12:08:10PM +0200, Sheldon Hearn wrote: > > strongly opposed to it, or because you don't have time? If it's the > latter, I'll do it. If the former, note that your commit message was Consider also adding owner:group support to -stable in order to provide the longest change-over period possible. -- 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 27 3:57:33 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 4CCD514D46 for ; Tue, 27 Jul 1999 03:57:07 -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 1194uM-000145-00; Tue, 27 Jul 1999 12:56:30 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: Doug , freebsd-hackers@freebsd.org Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-reply-to: Your message of "Tue, 27 Jul 1999 06:54:32 -0400." <19990727065431.A32516@mad> Date: Tue, 27 Jul 1999 12:56:30 +0200 Message-ID: <4096.933072990@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 06:54:32 -0400, Tim Vanderhoek wrote: > It used to be that packages would depend on X, but Sheldon reminded me > (although I think it was accidental :-) that XFree86 was added to > PACKAGE_IGNORE_DEPENDS to prevent this. PKG_IGNORE_DEPENDS is what I had in mind. :-P Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 4:26:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 67A4714DF1; Tue, 27 Jul 1999 04:26:33 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id NAA55736; Tue, 27 Jul 1999 13:26:21 +0200 (CEST) (envelope-from des) To: net@freebsd.org Subject: TCP/IP hardening, take two Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 27 Jul 1999 13:26:21 +0200 Message-ID: Lines: 308 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cleaned up the previously posted patches, tested them a little more, and added a sysctl knob for logging SYN+FIN packets (before optionally dropping them). A FreeBSD 4.0-CURRENT machine with these patches and no firewall looks like this to nmap (with tcp.drop_synfin and tcp.restrict_rst enabled): | Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) | Interesting ports on destmp.follo.net (195.204.143.235): | (Not showing ports in state: filtered) | Port State Protocol Service | 22 open tcp ssh | | TCP Sequence Prediction: Class=random positive increments | Difficulty=38742 (Worthy challenge) | No OS matches for host (see http://www.insecure.org/cgi-bin/nmap-submit.cgi). | TCP/IP fingerprint: | TSeq(Class=RI%gcd=2%SI=1429) | TSeq(Class=RI%gcd=1%SI=1026) | TSeq(Class=RI%gcd=1%SI=9756) | T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M) | T2(Resp=N) | T3(Resp=N) | T4(Resp=N) | T5(Resp=N) | T6(Resp=N) | T7(Resp=N) | PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E) | | | Nmap run completed -- 1 IP address (1 host up) scanned in 75 seconds Note: The TCP sequence prediction difficulty rating is meaningless, Successive nmap runs show ratings from approx. 5000 to approx. 40000 for the same computer with the same software. DES -- Dag-Erling Smorgrav - des@yes.no Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/27 11:18:30 @@ -48,6 +48,12 @@ tcp_extensions="NO" # Set to Yes to turn on RFC1323 extensions. log_in_vain="NO" # Disallow bad connection logging (or YES). tcp_keepalive="YES" # Kill dead TCP connections (or NO). +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +tcp_log_synfin="NO" # Set to YES to log TCP packets with SYN+FIN +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +icmp_dropredirect="NO" # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. Index: etc/rc.network =================================================================== RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/27 11:18:30 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 >/dev/null fi + + if [ "X$icmp_dropredirect" = X"YES" ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 >/dev/null + fi + + if [ "X$icmp_logredirect" = X"YES" ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 >/dev/null + fi if [ "X$gateway_enable" = X"YES" ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,21 @@ if [ "X$tcp_keepalive" = X"YES" ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null + fi + + if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null + fi + + if [ "X$tcp_log_synfin" = X"YES" ]; then + echo -n ' log SYN+FIN packets=YES' + sysctl -w net.inet.tcp.log_synfin=1 >/dev/null + fi + + if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null fi if [ "X$ipxgateway_enable" = X"YES" ]; then Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/27 11:18:30 @@ -207,6 +207,8 @@ INET opt_inet.h IPDIVERT DUMMYNET opt_ipdn.h +IPFILTER opt_ipfilter.h +IPFILTER_LOG opt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h IPFIREWALL_VERBOSE_LIMIT opt_ipfw.h @@ -220,11 +222,11 @@ PPP_BSDCOMP opt_ppp.h PPP_DEFLATE opt_ppp.h PPP_FILTER opt_ppp.h +SLIP_IFF_OPTS opt_slip.h TCP_COMPAT_42 opt_compat.h TCPDEBUG -IPFILTER opt_ipfilter.h -IPFILTER_LOG opt_ipfilter.h -SLIP_IFF_OPTS opt_slip.h +TCP_DROP_SYNFIN opt_tcp_input.h +TCP_RESTRICT_RST opt_tcp_input.h # ATM (HARP version) ATM_CORE opt_atm.h Index: sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT 1999/07/26 05:47:17 1.620 +++ LINT 1999/07/27 11:18:30 @@ -469,6 +469,20 @@ options IPSTEALTH #support for stealth forwarding options TCPDEBUG +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN +options TCP_RESTRICT_RST #restrict emission of TCP RST + # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from # D.O.S. packet attacks. Index: sys/netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.34 diff -u -r1.34 ip_icmp.c --- ip_icmp.c 1999/03/06 23:10:42 1.34 +++ ip_icmp.c 1999/07/27 11:18:30 @@ -69,6 +69,14 @@ SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, ""); +static int logredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, logredirect, CTLFLAG_RW, + &logredirect, 0, ""); + +static int dropredirect = 0; +SYSCTL_INT(_net_inet_icmp, OID_AUTO, dropredirect, CTLFLAG_RW, + &dropredirect, 0, ""); + #ifdef ICMP_BANDLIM /* @@ -92,8 +100,8 @@ */ static int icmpbmcastecho = 0; -SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, &icmpbmcastecho, - 0, ""); +SYSCTL_INT(_net_inet_icmp, OID_AUTO, bmcastecho, CTLFLAG_RW, + &icmpbmcastecho, 0, ""); #ifdef ICMPPRINTFS @@ -462,6 +470,23 @@ return; case ICMP_REDIRECT: + if (logredirect) { + u_long src, dst, gw; + + src = ntohl(ip->ip_src.s_addr); + dst = ntohl(icp->icmp_ip.ip_dst.s_addr); + gw = ntohl(icp->icmp_gwaddr.s_addr); + printf("icmp_redirect from %d.%d.%d.%d: " + "%d.%d.%d.%d => %d.%d.%d.%d\n", + (int)(src >> 24), (int)((src & 0xff0000) >> 16), + (int)((src & 0xff00) >> 8), (int)(src & 0xff), + (int)(dst >> 24), (int)((dst & 0xff0000) >> 16), + (int)((dst & 0xff00) >> 8), (int)(dst & 0xff), + (int)(gw >> 24), (int)((gw & 0xff0000) >> 16), + (int)((gw & 0xff00) >> 8), (int)(gw & 0xff)); + } + if (dropredirect) + break; if (code > 3) goto badcode; if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || Index: sys/netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.87 diff -u -r1.87 tcp_input.c --- tcp_input.c 1999/07/18 14:42:48 1.87 +++ tcp_input.c 1999/07/27 11:18:30 @@ -36,6 +36,7 @@ #include "opt_ipfw.h" /* for ipfw_fwd */ #include "opt_tcpdebug.h" +#include "opt_tcp_input.h" #include #include @@ -78,7 +79,7 @@ struct tcpstat tcpstat; SYSCTL_STRUCT(_net_inet_tcp, TCPCTL_STATS, stats, CTLFLAG_RD, - &tcpstat , tcpstat, "TCP statistics (struct tcpstat, netinet/tcp_var.h)"); + &tcpstat, tcpstat, "TCP statistics (struct tcpstat, netinet/tcp_var.h)"); static int log_in_vain = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, log_in_vain, CTLFLAG_RW, @@ -89,6 +90,21 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +#ifdef TCP_RESTRICT_RST +static int restrict_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, restrict_rst, CTLFLAG_RW, + &restrict_rst, 0, "Restrict RST emission"); +#endif + +#ifdef TCP_DROP_SYNFIN +static int drop_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, + &drop_synfin, 0, "Drop TCP packets with SYN+FIN set"); +static int log_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, log_synfin, CTLFLAG_RW, + &log_synfin, 0, "Log TCP packets with SYN+FIN set"); +#endif + u_long tcp_now; struct inpcbhead tcb; struct inpcbinfo tcbinfo; @@ -336,6 +352,28 @@ } tiflags = ti->ti_flags; +#ifdef TCP_DROP_SYNFIN + /* + * If the drop_synfin option is enabled, drop all packets with + * both the SYN and FIN bits set. This prevents e.g. nmap from + * identifying the TCP/IP stack. + * + * This is incompatible with RFC1644 extensions (T/TCP). + */ + if (tiflags & TH_SYN && tiflags & TH_FIN) { + if (log_synfin) { + u_long src; + + src = ntohl(ti->ti_src.s_addr); + printf("SYN+FIN from %d.%d.%d.%d\n", + (int)(src >> 24), (int)((src & 0xff0000) >> 16), + (int)((src & 0xff00) >> 8), (int)(src & 0xff)); + } + if (drop_synfin) + goto drop; + } +#endif + /* * Convert TCP protocol specific fields to host format. */ @@ -1764,6 +1802,10 @@ return; dropwithreset: +#ifdef TCP_RESTRICT_RST + if (restrict_rst) + goto drop; +#endif /* * Generate a RST, dropping incoming segment. * Make ACK acceptable to originator of segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 4:38: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 643AA1532F; Tue, 27 Jul 1999 04:38:01 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id NAA55873; Tue, 27 Jul 1999 13:37:35 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: replacing grep(1) Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 27 Jul 1999 13:37:35 +0200 Message-ID: Lines: 17 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Howard (howardjp@wam.umd.edu), with a little help from yours truly, has written a BSD-licensed version of grep(1) which has all the functionality of our current (GPLed) implementation, plus a little more, in one seventh the source code and one fourth the binary code. What's more, the code is actually possible for mere mortals to read and understand. The source code is available for download from freefall: I move that we replace GNU grep in our source tree with this implementation, once it's been reviewed by all concerned parties. DES -- Dag-Erling Smorgrav - des@yes.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 27 4:44:31 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 1DF7914D71; Tue, 27 Jul 1999 04:43:55 -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 1195dt-0001FJ-00; Tue, 27 Jul 1999 13:43:33 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: obrien@freebsd.org, hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group In-reply-to: Your message of "Tue, 27 Jul 1999 06:57:49 -0400." <19990727065749.B32516@mad> Date: Tue, 27 Jul 1999 13:43:33 +0200 Message-ID: <4792.933075813@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 06:57:49 -0400, Tim Vanderhoek wrote: > Consider also adding owner:group support to -stable in order to > provide the longest change-over period possible. You have to read the CURRENT newsyslog(8) manpage before you realize that this is a lose-lose situation: COMPATIBILITY Previous versions of the chown utility used the dot (``.'') character to distinguish the group name. Begining with FreeBSD 4.0, this has been changed to be a colon (``:'') character so that user and group names may contain the dot character. If we don't offer backward compatibility, people will whine when they stub their toes. If we do, we break support for usernames which contain the dot (``.'') . I think David's chosen the lesser of two evils and I support his decision. However, I think we could at least introduce consistency with chown(8) by making dot-as-token support a compile-time option, -DSUPPORT_DOT which is turned _on_ by default. Later, -DSUPPORT_DOT can be removed from the Makefiles for chown(8) and newsyslog(8) and documented in src/Makefile.inc1 . Sorry for bringing this up without doing all my homework. Diffs in the pipeline. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 4:48: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 831A514D1A for ; Tue, 27 Jul 1999 04:48:21 -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 1195gZ-0001Fs-00; Tue, 27 Jul 1999 13:46:19 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) In-reply-to: Your message of "27 Jul 1999 13:37:35 +0200." Date: Tue, 27 Jul 1999 13:46:19 +0200 Message-ID: <4827.933075979@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote: > > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. When I committed the port (textproc/freegrep), Jamie assured me that he'd keep me updated on the progress of his software. That was the last I heard of it, and the port is still sitting at version 0.3 . Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 4:49:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 3F2A2153B8 for ; Tue, 27 Jul 1999 04:49:22 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id NAA55910; Tue, 27 Jul 1999 13:48:21 +0200 (CEST) (envelope-from des) To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: replacing grep(1) References: <4827.933075979@axl.noc.iafrica.com> Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 27 Jul 1999 13:48:21 +0200 In-Reply-To: Sheldon Hearn's message of "Tue, 27 Jul 1999 13:46:19 +0200" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > Version 0.3 broke port-building badly. Does version 0.7 make it through > a build of a whole stack of ports? Yes. DES -- Dag-Erling Smorgrav - des@yes.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 27 4:52:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mpp.pro-ns.net (mpp.pro-ns.net [208.200.182.72]) by hub.freebsd.org (Postfix) with ESMTP id 04AED153B8; Tue, 27 Jul 1999 04:52:39 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id GAA02583; Tue, 27 Jul 1999 06:51:58 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199907271151.GAA02583@mpp.pro-ns.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270348.UAA49943@apollo.backplane.com> from Matthew Dillon at "Jul 26, 1999 08:48:28 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 27 Jul 1999 06:51:58 -0500 (CDT) Cc: green@FreeBSD.org (Brian F. Feldman), jgreco@ns.sol.net (Joe Greco), hackers@FreeBSD.org, freebsd-ipfw@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 > :> There may be some confusion here. I am advocating that we *allow* the > :> zeroing of counters at secure level 3. > : > :Which is what I am advocating against. > > Let me put it a different way: > > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. But it might be hiding a real security threat/attack or a real breakin. Say I've spent all night trying to hack into your machine and finally get in. If I can reset all of ipfw's counters back to zero, and this is something your security checking scripts are checking, you might not think that anyone has even been trying to break into your machine, much less made it into the machine. If I have some inside information, I could probably even get the counters back into the range where you might expect them to be at. Hopefully if this were to happen, you might see some other console/syslog messages or something else that catches your eye, but then again, maybe not. Just to help out people running at higher security levels, you could always implement something that lets you reset the values to some higher value that is easy to do computations from. E.g. ipfw --increment_counters=20000 Which would bump all of the counters up to the value of "20000", assuming they are all still less than that value. That way if you are trying to do some testing/debugging/counting after setting the counters, at least you have a nice round number to subtract from the current values. -- Mike Pritchard mpp@FreeBSD.ORG or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 4:56:47 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 C2396153DD for ; Tue, 27 Jul 1999 04:55:52 -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 1195nf-0001HF-00; Tue, 27 Jul 1999 13:53:39 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) In-reply-to: Your message of "27 Jul 1999 13:48:21 +0200." Date: Tue, 27 Jul 1999 13:53:39 +0200 Message-ID: <4912.933076419@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27 Jul 1999 13:48:21 +0200, Dag-Erling Smorgrav wrote: > > Version 0.3 broke port-building badly. Does version 0.7 make it through > > a build of a whole stack of ports? > > Yes. Excellent. I'll nuke the port once you've merged the new grep to STABLE. :-) Later, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5: 1:57 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 3D191153DD for ; Tue, 27 Jul 1999 05:01:54 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id OAA01990; Tue, 27 Jul 1999 14:00:48 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907271200.OAA01990@freebsd.dk> Subject: Re: replacing grep(1) In-Reply-To: from Dag-Erling Smorgrav at "Jul 27, 1999 1:37:35 pm" To: des@yes.no (Dag-Erling Smorgrav) Date: Tue, 27 Jul 1999 14:00:48 +0200 (CEST) Cc: 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 Dag-Erling Smorgrav wrote: > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > > The source code is available for download from freefall: > > > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Go for it, the more GNU stuff we nuke the better :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5:21:11 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 B7AA7153F1 for ; Tue, 27 Jul 1999 05:20: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 IAA46490; Tue, 27 Jul 1999 08:19:38 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 08:19:38 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Soren Schmidt Cc: Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) In-Reply-To: <199907271200.OAA01990@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999, Soren Schmidt wrote: > It seems Dag-Erling Smorgrav wrote: > >=20 > > I move that we replace GNU grep in our source tree with this > > implementation, once it's been reviewed by all concerned parties. >=20 > Go for it, the more GNU stuff we nuke the better :) >=20 > -S=F8ren >=20 Geez, why don't we just write our own compiler and linker, assembler, and everything? Let's get every last bit of GNU out of our system, for no reason! This kind of NIH is not necessary, and only hurts us by misdirecting our energies. Seriously, I'd love for this to happen. Most GNU software is a hopeless, gruesome mess that should be dragged out and shot. Getting rid of as much as possible, gradually, is a Very Good Thing; this is how we get stability and performance improvements. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ =20 green@FreeBSD.org _ __ ___ | _ ) __| \=20 FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5:25:29 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 0B28E14BEB for ; Tue, 27 Jul 1999 05:25:26 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18369.on.bellglobal.com [206.172.130.49]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA04789; Tue, 27 Jul 1999 08:27:39 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id IAA33671; Tue, 27 Jul 1999 08:23:44 -0400 (EDT) (envelope-from tim) Date: Tue, 27 Jul 1999 08:23:44 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) Message-ID: <19990727082344.B33399@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 Tue, Jul 27, 1999 at 01:37:35PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote: > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Have you run your systems with J-grep as a replacement for GNU grep for a while (making sure nothing breaks)? There seems to be at least one dependency on GNU grep in /ports/Mk/bsd.port.mk where the -F argument is used. How's it compare in speed? [I'd test it myself, but see my private email...] -- 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 27 5:35:41 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 5D6A714D7A; Tue, 27 Jul 1999 05:34:50 -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 1196PE-0003HU-00; Tue, 27 Jul 1999 14:32:28 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) In-reply-to: Your message of "Tue, 27 Jul 1999 08:19:38 -0400." Date: Tue, 27 Jul 1999 14:32:28 +0200 Message-ID: <12615.933078748@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote: > Getting rid of as much as possible, gradually, is a Very Good Thing; > this is how we get stability and performance improvements. Only if the replacements are as stable and robust as their predecessors. In this case, the implementation we'll be introducing will introduce a performance loss, not a gain. As far as stability goes, there's a loss involved _if_ passing the GNU grep regression tests is important. Don't get me wrong. I'm all for replacing GNU software. Let's just be realistic and keep in mind that being non-GNU doesn't necessarily mean better. In this case, I'm all for the change, since I don't use grep for serious regex work and the readability gain outweighs any loss of performance. you probably feel the same way. Out opinions are those of developers, though. It's always worth remembering that. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5:41:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from news.itfs.nsk.su (news.itfs.nsk.su [212.20.32.45]) by hub.freebsd.org (Postfix) with ESMTP id 970D914D23 for ; Tue, 27 Jul 1999 05:41:14 -0700 (PDT) (envelope-from nnd@news.itfs.nsk.su) Received: (from nnd@localhost) by news.itfs.nsk.su (8.9.2/8.9.2) id TAA36462; Tue, 27 Jul 1999 19:39:05 +0700 (NSS) (envelope-from nnd) Date: Tue, 27 Jul 1999 19:39:05 +0700 (NSS) From: "Nickolay N. Dudorov" Message-Id: <199907271239.TAA36462@news.itfs.nsk.su> To: hackers@freebsd.org Subject: Re: replacing grep(1) In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.1-STABLE (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In Dag-Erling Smorgrav wrote: > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > The source code is available for download from freefall: > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Unfortunately abovementioned grep-0.7.tar.gz is broken. After making it on the CURRENT system I can only see: grep: filename: Undefined error: 0 for every filename. This caused by very "unusual" return values for 'grep_open' (and other '..._open') function which is declared as 'int' (and return int result) and compared with NULL ;-( I prefer not to include the patch for this because I am uncompatible with such trics as: return ((f = fopen(path, mode)) != NULL) - 1; N.Dudorov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5:49:42 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 BF06E14D23 for ; Tue, 27 Jul 1999 05:49:39 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 48400 invoked from network); 27 Jul 1999 12:49:22 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 27 Jul 1999 12:49:22 -0000 Date: Tue, 27 Jul 1999 07:49:22 -0500 (CDT) From: David Scheidt To: Sheldon Hearn Cc: "Brian F. Feldman" , Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) In-Reply-To: <12615.933078748@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, 27 Jul 1999, Sheldon Hearn wrote: > In this case, I'm all for the change, since I don't use grep for serious > regex work and the readability gain outweighs any loss of performance. > you probably feel the same way. Out opinions are those of developers, > though. It's always worth remembering that. Does any have numbers about how much slower the new grep is? I have been using the port (version 3) for my interactive grepping, and havedn't noticed a speed difference. I have been using it on zippy machines though, where 30% hit wouldn't be noticed. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 5:55: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 D8FB614CF1; Tue, 27 Jul 1999 05:55:02 -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 1196kl-0003U9-00; Tue, 27 Jul 1999 14:54:43 +0200 From: Sheldon Hearn To: David Scheidt Cc: "Brian F. Feldman" , Soren Schmidt , Dag-Erling Smorgrav , howardjp@wam.umd.edu, hackers@FreeBSD.org Subject: Re: replacing grep(1) In-reply-to: Your message of "Tue, 27 Jul 1999 07:49:22 EST." Date: Tue, 27 Jul 1999 14:54:43 +0200 Message-ID: <13400.933080083@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 07:49:22 EST, David Scheidt wrote: > Does any have numbers about how much slower the new grep is? Just by the way, if the latest version somehow uses mmap without my having noticed, then I've ontroduced a red herring. ;-) Version 0.3 certainly didn't use mmap. As I understand it, this means that the performance hit, whatever the magnitude, would be noticed with larger files. I've copied the author, who's probably in the best position to give you hard numbers. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 6: 7: 7 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 7459F14D72 for ; Tue, 27 Jul 1999 06:07:03 -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 JAA47310; Tue, 27 Jul 1999 09:05:46 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 09:05:46 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) In-Reply-To: <12615.933078748@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, 27 Jul 1999, Sheldon Hearn wrote: > > > On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote: > > > Getting rid of as much as possible, gradually, is a Very Good Thing; > > this is how we get stability and performance improvements. > > Only if the replacements are as stable and robust as their predecessors. Usually, when we get replacements, they are. > > In this case, the implementation we'll be introducing will introduce a > performance loss, not a gain. As far as stability goes, there's a loss > involved _if_ passing the GNU grep regression tests is important. Which it isn't unless they are truly correct in their assumptions of output behavior. > > Don't get me wrong. I'm all for replacing GNU software. Let's just be > realistic and keep in mind that being non-GNU doesn't necessarily mean > better. Not _necessarily_, but realistically... > > In this case, I'm all for the change, since I don't use grep for serious > regex work and the readability gain outweighs any loss of performance. > you probably feel the same way. Out opinions are those of developers, > though. It's always worth remembering that. That's true. I'd like to see the replacement grep do mmaping of the input files if it doesn't already, as that would speed it up. Anyway, I haven't tried it out yet because I haven't seen it hit 1.0 :) The only good pre-1.0 software I've seen has been the GIMP, XRacer, and some little utilities (like a program called stat(1)). That reminds me. I'd like to see something like stat(1) go into the source tree, but only if it were freely licensed, not GPL-infected. I could do it in a day, I suppose, if it were worth it. Worth it is here defined as "would be accepted to go in usr.bin." > > Ciao, > Sheldon. > 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 27 6:14:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.ham.muohio.edu (dragon.ham.muohio.edu [134.53.141.33]) by hub.freebsd.org (Postfix) with ESMTP id E8EFC14D72 for ; Tue, 27 Jul 1999 06:14:37 -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 IAA01466; Tue, 27 Jul 1999 08:17:58 -0400 X-Authentication-Warning: dragon.ham.muohio.edu: howardjp owned process doing -bs Date: Tue, 27 Jul 1999 08:17:58 -0400 (EDT) From: Jamie Howard X-Sender: howardjp@dragon.ham.muohio.edu To: "Nickolay N. Dudorov" Cc: hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-Reply-To: <199907271239.TAA36462@news.itfs.nsk.su> 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, 27 Jul 1999, Nickolay N. Dudorov wrote: > After making it on the CURRENT system I can only > see: > > grep: filename: Undefined error: 0 > > for every filename. Every file? > > This caused by very "unusual" return values for > 'grep_open' (and other '..._open') function which is declared > as 'int' (and return int result) and compared with NULL ;-( > > I prefer not to include the patch for this because > I am uncompatible with such trics as: > > return ((f = fopen(path, mode)) != NULL) - 1; This was done this way because the gzopen and fopen both return pointers of different types. Maybe the best thing would be to have grep_open() return a void pointer since procfile() doesn't keep track of what files are open and not. This is ugly and not very reusable, but then again how many programs need transparent access to both gzip'd and plaintext files? 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 27 6:26:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.ham.muohio.edu (dragon.ham.muohio.edu [134.53.141.33]) by hub.freebsd.org (Postfix) with ESMTP id 06F041540D; Tue, 27 Jul 1999 06:26:35 -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 IAA01500; Tue, 27 Jul 1999 08:30:16 -0400 X-Authentication-Warning: dragon.ham.muohio.edu: howardjp owned process doing -bs Date: Tue, 27 Jul 1999 08:30:16 -0400 (EDT) From: Jamie Howard X-Sender: howardjp@dragon.ham.muohio.edu To: "Brian F. Feldman" Cc: hackers@FreeBSD.ORG Subject: Re: replacing 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 Tue, 27 Jul 1999, Brian F. Feldman wrote: > That's true. I'd like to see the replacement grep do mmaping of the > input files if it doesn't already, as that would speed it up. Anyway, It does not use mmap right now. And this causes a significant perforamce hit on larger files. An older version (I'm thinking .4) would give equivalent performance on smaller files, <75k or so, occassionally faster. However, larger files really drag it down, often slower by 900%. > I haven't tried it out yet because I haven't seen it hit 1.0 :) The > only good pre-1.0 software I've seen has been the GIMP, XRacer, and > some little utilities (like a program called stat(1)). > > That reminds me. I'd like to see something like stat(1) go into the source > tree, but only if it were freely licensed, not GPL-infected. I could do > it in a day, I suppose, if it were worth it. Worth it is here defined as > "would be accepted to go in usr.bin." I once saw a version of stat that carried a public domain statement on an HP-UX software archive, I'll see if I can dig that up for you. 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 27 6:29:22 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 326A81540C for ; Tue, 27 Jul 1999 06:29:17 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18416.on.bellglobal.com [206.172.130.96]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id JAA02668; Tue, 27 Jul 1999 09:32:34 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id JAA34765; Tue, 27 Jul 1999 09:29:42 -0400 (EDT) (envelope-from tim) Date: Tue, 27 Jul 1999 09:29:41 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) Message-ID: <19990727092941.A34599@mad> References: <19990727082344.B33399@mad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990727082344.B33399@mad>; from Tim Vanderhoek on Tue, Jul 27, 1999 at 08:23:44AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote: > > How's it compare in speed? [I'd test it myself, but see my private > email...] Okay, following-up on myself, and indirectly Sheldon, It does seem a little too slow. I'm not sure that this is because it doesn't use mmap. Supposedly the merged buffer/vm means mmap doesn't make as large a difference as it used to. On a file with 100000+ lines, the speed difference is rather restrictive. Looking over the gprof output, I think its authors (or some other intrepid hacker) will find ways to speed it up. Only about 10% of the time is spend in procline(). There seems to be a lot of unnecessary strncpy() that could be _easily_ avoided if free() on util.c:130 was avoided, but I'll let the authors speak first. :-) -- 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 27 6:53:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 5B30214C8A for ; Tue, 27 Jul 1999 06:53:32 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00540 for ; Tue, 27 Jul 1999 09:52:29 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id JAA09275 for ; Tue, 27 Jul 1999 09:52:29 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199907271352.JAA09275@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: reserved/local ioctl values? Date: Tue, 27 Jul 1999 09:52:29 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'l looking at defining about a dozen ioctl calls for a local device driver. When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if there are any "reserved" or "local" values for the first parameter? In short, I'd hate to use a seemly unused value, just to suddenly be in conflict with a major set of ioctls (particularly terminal, as this is the type of driver it will be). Also, would it be wise to reuse an existing value? For instance, 'C' is used apparently by the SCSI system in /usr/include/cam/scsi/scsi_targetio.h, ISDN in /usr/include/machine/i4b_debug.h, and sound in /usr/include/machine/soundcard.h. In short, I want a value thats 'safe', in so far as I probably won't have to go back and redefine it later. I've been burned on thsi before (see majors.i386 in /usr/src/sys/i386/conf where 200-255 are now reserved... They weren't until post 2.2.6-ish when I spent 3 weeks doing tech support because one of the new device drivers in 2.2.8 conflicted with locally released code). Anyhow, good thoughts? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 7:17:57 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 1E9F714E06; Tue, 27 Jul 1999 07:17:42 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA27361; Tue, 27 Jul 1999 23:17:14 +0900 (JST) Message-ID: <379DBE1D.7E131B38@newsguy.com> Date: Tue, 27 Jul 1999 23:11:41 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Brian F. Feldman" Cc: Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing grep(1) 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 "Brian F. Feldman" wrote: > > Geez, why don't we just write our own compiler and linker, assembler, > and everything? Let's get every last bit of GNU out of our system, for > no reason! This kind of NIH is not necessary, and only hurts us by > misdirecting our energies. > > > Seriously, I'd love for this to happen. Most GNU software is a hopeless, > gruesome mess that should be dragged out and shot. Getting rid of as > much as possible, gradually, is a Very Good Thing; this is how we get > stability and performance improvements. In fact, I think the *greatest* advantage of this code is it's readability. Anyway, both versions exist, so it's not a question of NIH. It's a question of choosing. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 7:17:57 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 6160614CEB for ; Tue, 27 Jul 1999 07:17:44 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA27342; Tue, 27 Jul 1999 23:17:09 +0900 (JST) Message-ID: <379DBD19.1483476A@newsguy.com> Date: Tue, 27 Jul 1999 23:07:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: replacing grep(1) 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 Dag-Erling Smorgrav wrote: > > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > > The source code is available for download from freefall: > > > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. I'm concerned about performance. Grep performance is relevant to some. Now, while I don't care if this grep is slower than what we are using right now, I do care if it's _complexity_ is greater. So, please, could you make sure the algorithmic complexity is not greater, either by benchmark comparision, or by examining the code? I would do it, if I had time. But right now I don't, and there is no need to keep this waiting. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 7:18:45 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 ADA0F14DFA; Tue, 27 Jul 1999 07:18:41 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA27774; Tue, 27 Jul 1999 23:18:39 +0900 (JST) Message-ID: <379DBFA6.BEAB73E8@newsguy.com> Date: Tue, 27 Jul 1999 23:18:14 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Brian F. Feldman" Cc: Sheldon Hearn , Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing grep(1) 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 "Brian F. Feldman" wrote: > > That reminds me. I'd like to see something like stat(1) go into the source > tree, but only if it were freely licensed, not GPL-infected. I could do > it in a day, I suppose, if it were worth it. Worth it is here defined as > "would be accepted to go in usr.bin." May I discreetly open a can of worms and remind everyone of a very nice little utility one Matthew Dillon once offered for /bin? I still think it's worth, and, as I recall, I wasn't the only one. (In fact, I think I didn't even voice my opinion at the time...) I'm talking about cpdup, which can be found in http://www.backplane.com/FreeBSD/. Someone posted a port at the time, but I don't know if anyone ever committed the port. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 7:23:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 2DA8914BEC; Tue, 27 Jul 1999 07:23:32 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id JAA90029; Tue, 27 Jul 1999 09:22:36 -0500 (CDT) From: Joe Greco Message-Id: <199907271422.JAA90029@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: from "Brian F. Feldman" at "Jul 26, 1999 11:12:37 pm" To: green@FreeBSD.org (Brian F. Feldman) Date: Tue, 27 Jul 1999 09:22:36 -0500 (CDT) Cc: dillon@apollo.backplane.com, jgreco@ns.sol.net, hackers@FreeBSD.org, freebsd-ipfw@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 > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > > :whatever the limit was) > > : > > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > > > The way I see it either some piece of software is monitor the counters, > > in which case the sysad does not need to clear them and does not need to > > look at log messages, or the sysad is monitoring the stuff manually and > > using the log messages. In the one case the counters don't need to be > > cleared (and, indeed, should not be), in the other case the sysad may > > want to clear them due to the manual monitoring. > > > > What we are really discussing here is the use of ipfw's counters in an > > unsophisticated setup. The sophisticated setup is already handled. > > That doesn't mean we shouldn't allow people to have an unsophisticated setup, > just because a sophisticated one is available. It would be useful to have > a per-firewall-rule counter, decrement it on each match if logging and > set, and be able to reset to something higher. This doesn't work the way you say. If there was a single global VERBOSE_LIMIT counter, yes, it'd be trivial to monitor for it to max out and then raise the limit. However, with the current design, what will happen is ... let's say you have ten log rules. Your intruder spends a few days puttering and in the meantime gets your auto monitoring system to raise the limit to 100,000 in 100-increment steps, by beating on Rule #1. Now, all of a sudden, Rule #2's counter is still at 0 and the limit is at 100,000... do you see the potential for damage, or need I point out #3-9? What you describe would be fine if there was a single global VERBOSE_LIMIT, but in that event I'm not sure what difference there would be between doing this limit-raise thing and just resetting the counter. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 8:11:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 91B2915023 for ; Tue, 27 Jul 1999 08:11:24 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-88.ucdavis.edu [169.237.16.88]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA01502; Tue, 27 Jul 1999 08:10:52 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id IAA65077; Tue, 27 Jul 1999 08:10:50 -0700 (PDT) (envelope-from obrien) Date: Tue, 27 Jul 1999 08:10:47 -0700 From: "David O'Brien" To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group Message-ID: <19990727081046.B46030@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <3580.933070090@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <3580.933070090@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 27, 1999 at 12:08:10PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This one raised a number of eyebrows and a few people asked you to hold > on to legacy support for a single release. It's a reasonable request, > given the obscure error message one gets for providing the previously > supported syntax: > > newsyslog: error in config file; bad permissions: > /var/log/exim/mainlog exim.mail 640 7 * 24 Z I will be adding the ":" syntax to -STABLE before 3.3-R, and it will accept both ":" and ".". It was a one character fix in -CURRENT and I don't see any reason to ugly the code with supporting both syntaxes in -CURRENT. The change will be documented in 4.0-R's release notes. If people don't read that, then they will be in trouble in many other ways. Anyway, it has been only ":" in -CURRENT for a while now, and I haven't received any death threats, so people must not be tripping over this on a daily basis. :-) The problem with printing out warnings is ``newsyslog'' is usually run from cron(8), and anything printed out will often not be seen as I am of the opinion many do not read root's mail. -- -- David (obrien@NUXI.com -or- obrien@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 27 8:12:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 619A61537E for ; Tue, 27 Jul 1999 08:12:48 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-88.ucdavis.edu [169.237.16.88]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA01516; Tue, 27 Jul 1999 08:12:46 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id IAA65089; Tue, 27 Jul 1999 08:12:44 -0700 (PDT) (envelope-from obrien) Date: Tue, 27 Jul 1999 08:12:42 -0700 From: "David O'Brien" To: Sheldon Hearn Cc: Tim Vanderhoek , hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group Message-ID: <19990727081242.C46030@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990727065749.B32516@mad> <4792.933075813@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4792.933075813@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 27, 1999 at 01:43:33PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > COMPATIBILITY > Previous versions of the chown utility used the dot (``.'') > character to distinguish the group name. Begining with FreeBSD > 4.0, this has been changed to be a colon (``:'') character so that > user and group names may contain the dot character. Hum... I think I should change this text slightly. I should not refer to chown(8) so strongly. It's on my list now. :-) -- -- David (obrien@NUXI.com -or- obrien@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 27 8:16: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 5EA6F153D2; Tue, 27 Jul 1999 08:12: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 1198tR-00058e-00; Tue, 27 Jul 1999 17:11:49 +0200 From: Sheldon Hearn Cc: Tim Vanderhoek , obrien@freebsd.org, hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group In-reply-to: Your message of "Tue, 27 Jul 1999 13:43:33 +0200." <4792.933075813@axl.noc.iafrica.com> Date: Tue, 27 Jul 1999 17:11:49 +0200 Message-ID: <19755.933088309@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 13:43:33 +0200, Sheldon Hearn wrote: > Sorry for bringing this up without doing all my homework. Diffs in the > pipeline. :-) Ha! Diffs that produce a win in the midst of an apparent lose-lose. We now continue to support the dot as a separator without breaking user- and groupnames which include dots. I took my lead from chown(8). Ciao, Sheldon. Index: Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/newsyslog/Makefile,v retrieving revision 1.6 diff -u -d -r1.6 Makefile --- Makefile 1999/01/22 19:38:39 1.6 +++ Makefile 1999/07/27 15:04:37 @@ -1,7 +1,7 @@ # $Id: Makefile,v 1.6 1999/01/22 19:38:39 wollman Exp $ PROG= newsyslog - +CFLAGS+=-DSUPPORT_DOT MAN8= newsyslog.8 .include Index: newsyslog.8 =================================================================== RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.8,v retrieving revision 1.19 diff -u -d -r1.19 newsyslog.8 --- newsyslog.8 1999/06/28 03:15:01 1.19 +++ newsyslog.8 1999/07/27 14:18:12 @@ -275,12 +275,12 @@ .Pp Copyright 1987, Massachusetts Institute of Technology .Sh COMPATIBILITY -Previous versions of the chown utility used the dot (``.'') character to -distinguish the group name. -Begining with -.Fx 4.0 , -this has been changed to be a colon (``:'') character so that user and group -names may contain the dot character. +Previous versions of the +.Nm +utility used the dot (``.'') character to distinguish the group name. +This has been changed to the colon (``:'') character so that user and group +names may contain the dot character. Future versions may not provide +backward compatibility. .Sh "SEE ALSO" .Xr gzip 1 , .Xr syslog 3 , Index: newsyslog.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v retrieving revision 1.23 diff -u -d -r1.23 newsyslog.c --- newsyslog.c 1999/06/28 03:15:02 1.23 +++ newsyslog.c 1999/07/27 15:06:24 @@ -286,7 +286,13 @@ if (!*parse) errx(1, "malformed line (missing fields):\n%s", errline); *parse = '\0'; +#ifdef SUPPORT_DOT + /* Older configurations used '.' between user and group */ + if ((group = strchr(q, ':')) != NULL || + (group = strchr(q, '.')) != NULL) { +#else if ((group = strchr(q, ':')) != NULL) { +#endif *group++ = '\0'; if (*q) { if (!(isnumber(*q))) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 8:27:34 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 066FC151B6 for ; Tue, 27 Jul 1999 08:25:42 -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 11996Z-0005AC-00; Tue, 27 Jul 1999 17:25:23 +0200 From: Sheldon Hearn To: obrien@NUXI.com Cc: hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group In-reply-to: Your message of "Tue, 27 Jul 1999 08:10:47 MST." <19990727081046.B46030@dragon.nuxi.com> Date: Tue, 27 Jul 1999 17:25:23 +0200 Message-ID: <19851.933089123@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Brian, Okay, your mail quoted below came around the same time I sent my diffs. This entire response assumes that you don't like the diffs. On Tue, 27 Jul 1999 08:10:47 MST, "David O'Brien" wrote: > It was a one character fix in -CURRENT and I don't see any reason to ugly > the code with supporting both syntaxes in -CURRENT. All I can offer in response is "because it's not _that_ ugly and there's no reason to leave concrete blocks on the upgrade path, even if you are supposed to walk it in steel-capped boots". :-) > The change will be documented in 4.0-R's release notes. If people > don't read that, then they will be in trouble in many other ways. > > Anyway, it has been only ":" in -CURRENT for a while now, and I > haven't received any death threats, so people must not be tripping > over this on a daily basis. :-) Judging by the number of PRs I've dealt with concerning the built-in tcp_wrappers included in 3.2, I have to say that this argument gives me the willies. There were _no_ complaints about inetd and built-in wrappers -- until it hits STABLE. :-) Jordan once told me that we do as much as (but no more than) we can to make the upgrade path as smooth as possible. I don't think that the extra line of code is more than we can do. :-) I'm acting out of self-preservation here. If a line of code can save me 5 PR's on 4.0-RELEASE, I'll take the line. *snort* > The problem with printing out warnings is ``newsyslog'' is usually run > from cron(8), and anything printed out will often not be seen as I am of > the opinion many do not read root's mail. Oh, I wasn't suggesting that you should do anything about the warnings. I was trying to point out that the wallies who don't read the release notes are _definitely_ going to come crying to us. :-) Later, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 8:40: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 20C4915078 for ; Tue, 27 Jul 1999 08:37:07 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 0BDE01911; Tue, 27 Jul 1999 17:37:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 0884849D4; Tue, 27 Jul 1999 17:37:01 +0200 (CEST) Date: Tue, 27 Jul 1999 17:37:01 +0200 (CEST) From: Andrzej Bialecki To: Anders Vidmark Cc: freebsd-hackers@freebsd.org Subject: Re: your mail 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, 27 Jul 1999, Anders Vidmark wrote: > Hi Hej, :-) > > Im getting unreferenced inodes that fills up /. > The box is running freebsd 2.2.6-release and sendmail 8.8.8 > Sendmails databases are rebuilt once every half hour. > It seems like the unref. inodes comes from spammers.db and > domainalias.db. > > Is there a way to avoid this? Will it get better if I upgrade to > freebsd 3.2? upgrade sendmail? This could be due to filesystem corruption, either because of crashes or for some other reasons. You can try fsck -y on a quiet system (i.e. in single-user mode). 2.2.6-R is ancient, and it contained well known security holes. The same goes for your version of sendmail. You should definitely upgrade your server. 3.2-STABLE is officially recommended version, but if you're afraid of too many changes (ELF, bootloader, changed VM) you should at least upgrade to the latest 2.2-STABLE. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 8:44:38 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 9D04B1591C for ; Tue, 27 Jul 1999 08:41:32 -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 1199L5-0005C5-00; Tue, 27 Jul 1999 17:40:23 +0200 From: Sheldon Hearn To: "Daniel C. Sobral" Cc: dillon@backplane.com, hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-reply-to: Your message of "Tue, 27 Jul 1999 23:18:14 +0900." <379DBFA6.BEAB73E8@newsguy.com> Date: Tue, 27 Jul 1999 17:40:22 +0200 Message-ID: <19968.933090022@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 23:18:14 +0900, "Daniel C. Sobral" wrote: > I'm talking about cpdup, which can be found in > http://www.backplane.com/FreeBSD/. Someone posted a port at the > time, but I don't know if anyone ever committed the port. I'll commit a port in the next few days. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 9: 7:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id A5DA0153BF for ; Tue, 27 Jul 1999 09:07:48 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-88.ucdavis.edu [169.237.16.88]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id JAA01794; Tue, 27 Jul 1999 09:07:38 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA65487; Tue, 27 Jul 1999 09:07:36 -0700 (PDT) (envelope-from obrien) Date: Tue, 27 Jul 1999 09:07:34 -0700 From: "David O'Brien" To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group Message-ID: <19990727090734.H46030@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990727081046.B46030@dragon.nuxi.com> <19851.933089123@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19851.933089123@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 27, 1999 at 05:25:23PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 05:25:23PM +0200, Sheldon Hearn wrote: > > Hi Brian, To paraphase Bill Paul: Grrrr that's part of my last name. -- -- David (obrien@NUXI.com -or- obrien@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 27 9:11:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id BA6F514BEC for ; Tue, 27 Jul 1999 09:11:37 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.8) with ESMTP id MAA22084; Tue, 27 Jul 1999 12:09:42 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <19990727092941.A34599@mad> References: <19990727082344.B33399@mad>; from Tim Vanderhoek on Tue, Jul 27, 1999 at 08:23:44AM -0400 <19990727082344.B33399@mad> Date: Tue, 27 Jul 1999 12:09:35 -0400 To: Tim Vanderhoek , Dag-Erling Smorgrav From: Garance A Drosihn Subject: Re: replacing grep(1) Cc: hackers@FreeBSD.ORG, howardjp@wam.umd.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:29 AM -0400 7/27/99, Tim Vanderhoek wrote: > On a file with 100000+ lines, the speed difference is rather > restrictive. [...] Only about 10% of the time is spend in > procline(). There seems to be a lot of unnecessary strncpy() > that could be _easily_ avoided if free() on util.c:130 was > avoided, but I'll let the authors speak first. :-) Hmm, strncpy? Are these calls which really want strncpy for what it was originally designed for, or are they just trying to prevent buffer overruns? If it's the buffer-overrun answer, then maybe this would be a good test case for using strlcpy instead of strncpy, and see if it makes a performance difference (since the code won't waste it's time nulling-out bytes that don't need to be nulled-out). --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 9:12:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mgate09.so-net.ne.jp (mgate09.so-net.ne.jp [210.132.247.58]) by hub.freebsd.org (Postfix) with ESMTP id 7D67A15289 for ; Tue, 27 Jul 1999 09:12:30 -0700 (PDT) (envelope-from aladdin@kb3.so-net.ne.jp) Received: from mail.kb3.so-net.ne.jp (mail.kb3.so-net.ne.jp [210.132.247.109]) by mgate09.so-net.ne.jp (8.8.8+3.0Wbeta9/3.6W99072721) with ESMTP id BAA25428; Wed, 28 Jul 1999 01:11:18 +0900 (JST) Received: from mebius2 (p84b683.sng4.ap.so-net.ne.jp [210.132.182.131]) by mail.kb3.so-net.ne.jp (8.8.8+3.0Wbeta9/3.7W99040113) with SMTP id BAA23518; Wed, 28 Jul 1999 01:11:17 +0900 (JST) Message-ID: <012301bed84a$dc3b35c0$0101a8c0@aladdin.jp> From: "aladdin" To: , "freebsd net" , , "biginer" Cc: , Subject: =?iso-2022-jp?B?Rnc6IGhlbHAbJEIhIRsoQm1lGyRCISEbKEJmcm9tIHBhbmljIG1hbg==?= Date: Wed, 28 Jul 1999 01:12:43 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>$B#N#T#T#S"~#F#T%F%l%3%`;v6HIt(B $B!!!!!!!!!!!!!!!!!!!!(B >>> >>> $B!!!!!!!!!!!!!!!!!!!!!!(B $B!!!!!!(B >>> >>>$B?9ED(B $BFuO:(B mailto:morita@jts.ntts.co.jp $B!!!!!!!!!!!!!!!!(B >>> >>> $B!!!!!!!!!!!!!!!!!!(B $B!!!!!!!!(B >>> >>>$B2#IM;TCf6h;32>> >>>TEL:045-212-7990 FAX:045-212-9800 $B!!!!!!!!!!(B >>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----- Original Message ----- $BAw?. $B08@h(B : ; freebsd net ; ; $BAw?.F|;~(B : 1999$BG/(B7$B7n(B28$BF|(B 1:09 $B7oL>(B : help$B!!(Bme$B!!(Bfrom panic man $B!!$3$s$K$A$O$_$J$5$s!#!!?9ED$H?=$7$^$9!#(B $B!!(BGood afternoon everyone. $B!!(BIt is called Morita. $B#1!!$I$J$?$+!"(BRADIUS$B%5!<%P!<$N<-=q$rB>$N(BRADIUS$B%5!<%P!<$N<-=q$X(B $BE>Aw$7$?J}$$$^$9$+!)(B 1$B!!(BIs there the one that anyone, the dictionary of the RADIUS server were transferred to the dictionary of other RADIUS servers? $B#2!!$=$l$+$i!"$b$&$R$H$D rev 0x41 int a irq 5 on pci0.5.0 $B$H$J$C$F$[$7$$$H$3$m$,!"(Bint a irq 255 $B$HI=<($7$F;H$($J$$$N$G$9$,!)(B 3 It is the last question. de0 : Do you indicate it with int a irq 255, and can't you use the place where it wants it to be Digital 21143 Fast Ethernet rev 0x41 int a irq 5 on pci0.5.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 27 9:18:24 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 8B68214D92 for ; Tue, 27 Jul 1999 09:18:05 -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 1199v0-0006NP-00; Tue, 27 Jul 1999 18:17:30 +0200 From: Sheldon Hearn To: obrien@NUXI.com Cc: hackers@freebsd.org Subject: Re: newsyslog owner.group -> owner:group In-reply-to: Your message of "Tue, 27 Jul 1999 09:07:34 MST." <19990727090734.H46030@dragon.nuxi.com> Date: Tue, 27 Jul 1999 18:17:30 +0200 Message-ID: <24514.933092250@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 09:07:34 MST, "David O'Brien" wrote: > To paraphase Bill Paul: > > Grrrr that's part of my last name. Noooo! I was chatting to a buddy about this just after I sent you the diffs and actually mentioned to him that I thought I might have made this mistake again. Since the first time, I've been quite careful about obrien and brian. Apologies and stuff. :-) Later, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 9:26:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from c2-10-dbn.dial-up.net (c2-10-dbn.dial-up.net [196.34.155.138]) by hub.freebsd.org (Postfix) with ESMTP id 8D02C14BEC for ; Tue, 27 Jul 1999 09:26:24 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by c2-10-dbn.dial-up.net (8.8.7/8.6.12) id SAA05638; Tue, 27 Jul 1999 18:25:45 +0200 (SAST) From: Robert Nordier Message-Id: <199907271625.SAA05638@c2-10-dbn.dial-up.net> Subject: Re: replacing grep(1) In-Reply-To: from Dag-Erling Smorgrav at "Jul 27, 1999 01:37:35 pm" To: des@yes.no (Dag-Erling Smorgrav) Date: Tue, 27 Jul 1999 18:25:43 +0200 (SAST) Cc: 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 > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. A couple of general problems: o Too many diagnostics have "Undefined error: 0" appended. Particularly in the case of "err(2, re_error)" in file.c, you probably want to look at using errx() instead. o Errors other than "no match" need to return a exit status of 2: some in file.c and util.c are returning 1. A more general concern is whether Henry Spencer's regex routines -- at least in our present "alpha-quality" version -- are up to supporting a grep without much further debugging. I don't recall many of the problems I found when I last looked at these, though here are two, after 5 minutes playing: echo xx | grep '\(x\{1,2\}\)\1' echo x | grep '[--x]' -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 9:38: 3 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 62BB314DB7; Tue, 27 Jul 1999 09:37:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA54522; Tue, 27 Jul 1999 09:37:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 09:37:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271637.JAA54522@apollo.backplane.com> To: Mike Pritchard Cc: green@FreeBSD.ORG (Brian F. Feldman), jgreco@ns.sol.net (Joe Greco), hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907271151.GAA02583@mpp.pro-ns.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :But it might be hiding a real security threat/attack or a real breakin. :Say I've spent all night trying to hack into your machine and finally get in. :If I can reset all of ipfw's counters back to zero, and this is :something your security checking scripts are checking, you might not :think that anyone has even been trying to break into your machine, much :less made it into the machine. If I have some inside information, :I could probably even get the counters back into the range where you :might expect them to be at. : :Hopefully if this were to happen, you might see some other console/syslog :messages or something else that catches your eye, but then again, :maybe not. : :Just to help out people running at higher security levels, you could :always implement something that lets you reset the values to some :... :Mike Pritchard I find this scenario highly unlikely. I can think of a thousand things. Well, a dozen anyway, that said hacker could do to the machine that are far more serious then clearing ipfw counters. And for that reason, I don't really consider it a realistic scenario. The hacker isn't going to give a damn about the ipfw counters. -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 Tue Jul 27 9:51: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 7BDBF14D0E for ; Tue, 27 Jul 1999 09:51:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA54626; Tue, 27 Jul 1999 09:48:30 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 09:48:30 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271648.JAA54626@apollo.backplane.com> To: Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: securelevel too course-grained? References: <87126.933053846@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Subject: Re: securelevel and ipfw zero :> :> However, it does not allow you to do it if you are sitting at secure :> level 3. : :You don't think that this discussion highlights the growing inadequacy :of the securelevel mechanism's lack of granularity? :Ciao, :Sheldon. It would be interesting to see it turn into a bitmask, where setting it to '-1' secures everything. But I think the original intent was to make it more user-friendly in concept. It is simply a matter of relative merit. If a high securelevel still allows most files to be modified, it might as well allow clearing of the ipfw counters. Ultimately the only way to do securelevel properly is with capabilities. The system gives init all the major capabilities and init passes them on as appropriate. A system-wide secure level for a feature is created simply by globally destroying a particular capability. It would also be possible to destroy all instances of a capability except in the specific processes that need it - though in that case you wouldn't be able to restart the process in question. -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 Tue Jul 27 9:52:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C5C2E1522F; Tue, 27 Jul 1999 09:52:33 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA15209; Tue, 27 Jul 1999 10:52:23 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA25747; Tue, 27 Jul 1999 10:52:22 -0600 Date: Tue, 27 Jul 1999 10:52:22 -0600 Message-Id: <199907271652.KAA25747@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262136.QAA19479@aurora.sol.net> References: <199907262045.OAA21485@mt.sri.com> <199907262136.QAA19479@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You get *better* information on per-rule limits than on a global limit. > > No, you simply get a finer-grained ability to select. Which is almost always better. > > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > > month of bad packets in it. > > > > If you're an admin on today's internet, you'd realize that there is *NO* > > way to get save a month worth of bad packets. Heck, at least once/week > > I can't even store a day's worth of bad packets (I assume when we say > > bad packets, we're talking about the > > If I'm an admin on today's internet (and I am), of course I realize that > I'm not going to save a month worth of all bad packets, but I _can_ choose > to hold onto a reasonable amount of logging information, which is what we > are discussing. Sure, but you can't call 'tossing 4/5 of the information that I receive in a totally arbritary manner' useful logging information. A global count would allow you to log information in a totally arbitrary manner. In that case, why have separate log rules? You may not ever get to see them if the limits are hit, so why not just one single rule to catch everything you want to log, since there's no guarantee that you'll see any logged information from the other rules. You might get something, but it's totally arbitrary and based upon known 'scripts' on what information is logged. Finer grained logging gives you *better* information, since it's more detailed. If you don't care about details, then why are you logging at all? > That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it > allows you to sample the beginning of each 5 minute period, and you > ought to be able to calculate the space required in a manner that > allows you to guarantee that you have sufficient space. I can't speak for the author, but as one of those involved in the discussion this wasn't even on the radar screen. The purpose of the option was to make DoS attacks less likely. It wasn't intended to provide you a good 'sampling' of attack packets on your system. Security is not effectively done by sampling. Sampling is too easy to thwart, and too often misses intrusions that are easily done by not doing sampling. :) And, because IPFW is so low-cost, there is very little reason to do sampling. Sampling is often done when 'real-time' monitoring is too expensive. What I'm hearing is that you want to change FreeBSD from doing 'real-time' monitoring to doing polling. The latter can be implemented from the former, but not vice-versa. We would be losing flexibility and usefulness by moving towards a 'polling' model. My advice to you is to quit 'polling' for packets (because as you've implied, you're not interested in the most of the information anyway), and use a *MUCH* smaller limit on your rules, and limit the number of rules you have, and you'll have almost the same result. > Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, > and you reset the counter every 5 minutes, you still _ought_ to be able to > determine that you require 2GB of disk space per day to keep those records. Great, but why even log data when you *plan* on throwing much of it away, in a totally arbitrary fashion. Why even bother? > (And if you're getting 100K rejectable packets every 5 minutes, something > is seriously wrong) Rejectable != log it. I reject alot of packets (most of them) and I don't care to log them. People do stupid things that aren't worthy of being logged, and there are alot of stupid people on the net doing things that aren't malicious that I don't care about. And, if you've got 100K 'logged' packets every 5 mins, then you better plan on having 2GB of disk-space/day if you care about saving them. Otherwise, if you don't have that much disk space, then don't reset every 5 minutes, since you can't keep the information. Either way you throw away information. With per-rule limits you have a much better idea on what kinds of information you are throwing away. (Fine-grained control). > > If you're logging that much information, then you're logging too much > > information. In any case, you've got information overload, so adding a > > global limit on the rules means you're losing as much (or more) > > information than you're logging, which is just as bad (or worse). > > No. You're not necessarily logging too much information. I do log a whole > bunch of shouldn't-happen scenarios, because if they do happen, it means > something is either horribly broken or somebody is doing something horribly > wrong. You might not see that happening since you're global rule was hit in the first 30 seconds by someone doing a POP3 scan of your entire network, followed by a breakin you missed. > I don't want an event such as an outbound source 10-net address to > happen... in theory it can't because I filter at my borders and use no > 10-net stuff internally. But I damn well want to know if it happens > ANYWAYS. You will have a very small chance of noticing it with a global limit. If you're truly concerned that you can generate 100K/sec of logging and want 5 minute resets (or whatever), then build your system with 18GB of disk and live with it. Otherwise, > > If you're worried about logging too much information, then don't reset > > your counters every 5 minutes. Besides, you're losing information if > > you're max'd out every 5 minutes anyway, so it really doesn't matter > > when you zero out your counters. > > You just argued my point for me, thank you. I _want_ to see the things that > I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the > information is beyond the point of being useful. True, but the information you gather that you are losing is totally arbitrary with a global counter. With individual counters, you tend to lose information on similar attacks, and in a DoS attack the information is mostly redundant. > > > I don't know what you mean by "make the rules 'more verbose'" but what I > > > am advocating is not any change in what currently exists... I am talking > > > about limiting the number of entries possible in a manner that would seem > > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > > attacks don't hit the entire system on every rule in order to do a DoS > > attack. Even so, each rule with eventually 'limit-out' and the system > > will no longer log packets. This is a 'bad thing' from a security > > standpoint, since at that point we are losing information. > > Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, > and that's perfectly valid as well. That's not what I said. You *must* have this to avoid DoS attacks. > > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > > > It's not there to make your logfiles small. If you want small logfiles, > > turn of IPFW logging altogether. > > > > (I'm actually serious here.) > > Oh, that's a f'ing crock. What _I_ really want is to be able to GET the > god damn information when the system is in securemode 3 and the damn IPFW > has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in > turning OFF IPFW logging? Yes, I think you are. You expect to lose information, and you don't care to know what kind of information you are losing. With per-rule counters, at least I know what kind of information I'm losing. > The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to > reduce or eliminate the chance of a DoS attack. Now, the best way to > eliminate the chance of a DoS attack is _algorithmically_. Giving someone > a mechanism that allows them to determine the maximum resource commitment > for a given scenario eliminates the chance for that DoS attack. Giving > someone a mechanism that may use a variable quantity of resources is the > typical programming practice that leads to a resource starvation DoS. Let's see. 1) You know your IPFW rule limits 2) You know how many rules log 3) You know how often your counters are zero'd. Therefore, you can algorithmically determine how many resources are required (worst case) to not fill up your disks. No problem. You have everything you need to do the job. We haven't done anything different with a global counter *EXCEPT* make the kind of information you lose in a DoS attack totally arbitrary. And, in most DoS attacks, they tend to hit a single rule. You're still able to gather information on subsequent attacks that are unrelated to the first attack. A win-win situation. In any case, you aren't going to convince me that a global counter is better than a per-rule counter. No way, no how, so I'm going to drop the discussion. > What I absolutely need is a way to clear out the VERBOSE_LIMIT > counter. I've not argued for/against this ability at securelevel 3. I'm of two minds. There are valid arguments both ways, and without more feedback from others, I'm certainly not going to code up something or apply patches that I don't feel comfortable with. But, I'm interested in the results, since this is an issue that I face on a regular basis, hence my postings. Somehow, a discussion about zero-ing out firewall counters degenerated into a global vs. per-rule counter argument, and that's 'counter' to the original problem. :) :) > > One could argue that accounting numbers in a firewall shouldn't be > > trusted, but I won't argue that point since the firewall is often the > > most 'natural' place to stick network accounting software. > > If you can't trust something in the kernel, then you just can't trust > anything at all. It isn't the kernel that's zero'ing the counters. :) > > > Well, the 'right' thing is clear: pull the limit count out of the > > > accounting count. This solves both the problem of zeroing accounting > > > counters and potentially messing with other things, and also of letting > > > people do anything 'negative' in securelevel 3. > > > > Is it the 'right' thing to do? I think that someone messing with the > > 'logging' rule counts could be just as dangerous as someone messing with > > the accounting counts. > > It is no more dangerous Agreed. But it's 'just as dangerous', and letting people mess with the counters in securelevel == 3 *IS* the issue. Should it be allowed? Yes, it's nice to do. But, the point of high securelevel is to avoid *ANYTHING* (even useful things) that might compromise the integrity of the system. And, the IPFW counters constitute part of the integrity of the system. Is it part of the system that should be modifiable? I don't know, there are issues on both sides of the argument. Neither side is compelling enough (in my mind) to change the existing behavior. I, and somebody zeroing (the only thing they should > > Again, if you're paranoid enough to have securelevel 3, you've got to be > > paranoid enough to assume that someone *HAS* root access on your box, > > and is going to do anything nasty they could. > > Yes, but causing additional logging to happen is going to be something that > is likely to _attract_ my attention. If they've got root, they can also mess with your logfiles. > > > By pulling the limit count out into a separate entity, nothing > > > 'negative' can happen (because stopping the logging process is > > > definitely negative, and being able to restart it without messing with > > > other stuff is positive). > > > > I'm not sure this is an acceptable change either, but I'll leave that > > discussion to the networking folks. > > > > > Now that we are agreed that the limit count needs to be divorced from the > > > accounting count, we can debate whether it should be a per-rule or global > > > limit. > > > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > > putting words in my mouth. :) :) > > Well, then, how do you "fix" this problem? I don't know if it's a problem that should be fixed. The side-effects of the fix are potentially as bad as the existing problem. It's not a bug, it's a feature. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:12:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id EEB3314DE1; Tue, 27 Jul 1999 10:12:48 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15478; Tue, 27 Jul 1999 11:12:26 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25861; Tue, 27 Jul 1999 11:12:25 -0600 Date: Tue, 27 Jul 1999 11:12:25 -0600 Message-Id: <199907271712.LAA25861@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270307.UAA49737@apollo.backplane.com> References: <199907270307.UAA49737@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. How do you figure? Currently, the kernel will quit 'logging' denied packets when the counter reaches a specific (compiled-in) number. Once that number is hit, you get 'hits', but no details as to what the signature of the hits are. The current 'signature' includes all of the IP information and such, which is invaluable (necessary?) for determing who's doing bad things (or not). This is in the kernel, and currently there is no way of modifying the counters in high securelevels. It doesn't matter if it's a human or a computer monitoring them, once the limit is reached alot of useful information is lost since the kernel no longer produces this information. # ipfw add 110 deny log tcp from any to any 110 via ed0 in Once the compiled in limit is reached, the kernel only says that we've got a hit, but it doesn't tell me who/when this happened. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:13:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id ADC7615069; Tue, 27 Jul 1999 10:13:41 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15485; Tue, 27 Jul 1999 11:13:30 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25874; Tue, 27 Jul 1999 11:13:29 -0600 Date: Tue, 27 Jul 1999 11:13:29 -0600 Message-Id: <199907271713.LAA25874@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270316.UAA49808@apollo.backplane.com> References: <199907270316.UAA49808@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Sorry Matt, I missed that in my previous posting as well.... Ignore my previous followup. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:15:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 181E4152C5; Tue, 27 Jul 1999 10:15:16 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15513; Tue, 27 Jul 1999 11:15:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25892; Tue, 27 Jul 1999 11:15:11 -0600 Date: Tue, 27 Jul 1999 11:15:11 -0600 Message-Id: <199907271715.LAA25892@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I like the ability at secure level 3 to only reset the counters forward.. > It fits in with such things as the "append only" flag. Then we'd have to implement per-rule counters that default to IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very different setup than what we currently have. (Another thing I just thought of is that this could cause DoS attacks on the system if a user compromised root and then set the limit to a very high number.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:18:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7729214E10; Tue, 27 Jul 1999 10:18:27 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15551; Tue, 27 Jul 1999 11:18:03 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25910; Tue, 27 Jul 1999 11:18:02 -0600 Date: Tue, 27 Jul 1999 11:18:02 -0600 Message-Id: <199907271718.LAA25910@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270348.UAA49943@apollo.backplane.com> References: <199907270348.UAA49943@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. I just thought of a bad thing. If you allowed the counters to be zero'd (or advanced) at securelevel == 3, then a 'malicious user' could write a cronjob to continually reset them and cause a DoS attack on the system (or in the case of advance, reset them to ridiculously high values), thus filling up the disk. However, one could argue that *IF* they have root, they could just as easily fill the disk with garbage and cause the same attack, ie; # dd if=/dev/zero of=/var/log/misc > The discussion should simply be about that. Not all this garbage > about adding new features. There's a feature that does not seem > to impact security, secure level disallows it, why? I'm not convinced there aren't other security implications from zero'ing (or advancing) the counters. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:25: 5 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 24E28151FC; Tue, 27 Jul 1999 10:24:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA54897; Tue, 27 Jul 1999 10:24:47 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 10:24:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271724.KAA54897@apollo.backplane.com> To: Nate Williams Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907270348.UAA49943@apollo.backplane.com> <199907271718.LAA25910@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I just thought of a bad thing. If you allowed the counters to be zero'd :(or advanced) at securelevel == 3, then a 'malicious user' could write a :cronjob to continually reset them and cause a DoS attack on the system :(or in the case of advance, reset them to ridiculously high values), :thus filling up the disk. : :However, one could argue that *IF* they have root, they could just as :easily fill the disk with garbage and cause the same attack, ie; : :# dd if=/dev/zero of=/var/log/misc The hacker w/ root would have to be a complete bozo to write a cron job or loop to clear the ipfw counters rather then do something else that really blows the machine away! It isn't a scenario that fills me with fear. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:27:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6D96514DE1 for ; Tue, 27 Jul 1999 10:27:41 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15649; Tue, 27 Jul 1999 11:24:33 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25938; Tue, 27 Jul 1999 11:24:32 -0600 Date: Tue, 27 Jul 1999 11:24:32 -0600 Message-Id: <199907271724.LAA25938@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dag-Erling Smorgrav Cc: Peter Jeremy , will@iki.fi, hackers@FreeBSD.ORG Subject: Re: Proposal for new syscall to close files In-Reply-To: References: <99Jul21.211359est.40325@border.alcanet.com.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Peter Jeremy writes: > > > If it ever gets > > >committed (I don't think it's particularly useful myself), > > That's 2 against, 1 (me) for. > > Three against. 4 against. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:32:51 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 D9BC515235 for ; Tue, 27 Jul 1999 10:32:41 -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 KAA02994; Tue, 27 Jul 1999 10:32:40 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Doug Cc: Sheldon Hearn , Tim Vanderhoek , freebsd-hackers@FreeBSD.ORG Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-reply-to: Your message of "Mon, 26 Jul 1999 22:41:24 PDT." <379D4684.FE083FB@gorean.org> Date: Tue, 27 Jul 1999 10:32:40 -0700 Message-ID: <2990.933096760@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > the parts that they need. However right after 3.2-R came out there was a > flurry of -questions mail about broken pkg dependencies because sysinstall > wasn't properly registering the X install. If the port depending on the Just to clear up a misconception; this isn't actually a sysinstall problem. This is a ports bug which Satoshi or somebody introduced when they added a dependency on the XFree86 port very prematurely. It was premature because no actual package exists for XFree86 yet and yet it's part of the dependancy chain now for a lot of packages, resulting in severe dysfunction unless it's removed by hand from the INDEX you use for package adding. - 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 27 10:35: 7 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 0F12C152E9; Tue, 27 Jul 1999 10:35:05 -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 KAA03018; Tue, 27 Jul 1999 10:35:39 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Brian F. Feldman" Cc: Rayson Ho , freebsd-hackers@FreeBSD.ORG Subject: Re: Free BSDI CD! In-reply-to: Your message of "Mon, 26 Jul 1999 23:21:53 EDT." Date: Tue, 27 Jul 1999 10:35:39 -0700 Message-ID: <3014.933096939@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > But we can install from a single downloaded boot floppy, over the > Internet, which is better. 1. Irrelevant, since most people who want to try BSD/OS out probably aren't concerned about how FreeBSD installs itself; they're simply different products. 2. Incorrect, since we don't install off a single floppy either. In other words, "you lose, but thanks for playing and here's a copy of our home game." - 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 27 10:35:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 8DBC7152E3; Tue, 27 Jul 1999 10:35:01 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id TAA74620; Tue, 27 Jul 1999 19:33:49 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 19:33:49 +0200 From: Achim Patzner To: Nate Williams Cc: Matthew Dillon , "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727193349.K58970@bnc.net> References: <199907270307.UAA49737@apollo.backplane.com> <199907271712.LAA25861@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271712.LAA25861@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 11:12:25AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 11:12:25AM -0600, Nate Williams wrote: > How do you figure? Currently, the kernel will quit 'logging' denied > packets when the counter reaches a specific (compiled-in) number. ^^^^^^^^^^^^^ Then what is net.inet.ip.fw.verbose_limit: 0 made for and why does it help changing it? 8-) It might also be nicer to give it its own facility for syslog... Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:37:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B171215235; Tue, 27 Jul 1999 10:37:10 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15796; Tue, 27 Jul 1999 11:35:22 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26067; Tue, 27 Jul 1999 11:35:20 -0600 Date: Tue, 27 Jul 1999 11:35:20 -0600 Message-Id: <199907271735.LAA26067@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Achim Patzner Cc: Nate Williams , Matthew Dillon , "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <19990727193349.K58970@bnc.net> References: <199907270307.UAA49737@apollo.backplane.com> <199907271712.LAA25861@mt.sri.com> <19990727193349.K58970@bnc.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > How do you figure? Currently, the kernel will quit 'logging' denied > > packets when the counter reaches a specific (compiled-in) number. > ^^^^^^^^^^^^^ > Then what is > > net.inet.ip.fw.verbose_limit: 0 Well I'll be. You learn something new everyday. :) > made for and why does it help changing it? 8-) Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule counters, when in fact you may only want to change a single counter. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:44:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 99BFA152B7; Tue, 27 Jul 1999 10:44:34 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id TAA74659; Tue, 27 Jul 1999 19:42:45 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 19:42:45 +0200 From: Achim Patzner To: Nate Williams Cc: Julian Elischer , "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727194245.L58970@bnc.net> References: <199907271715.LAA25892@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271715.LAA25892@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 11:15:11AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 11:15:11AM -0600, Nate Williams wrote: > Then we'd have to implement per-rule counters that default to > IPFW_VERBOSE_LIMIT but that could be changed to anything. *falling on my knees* If you're going to do that what would it cost me (in chocolate bars or sushi) to get you to implement a second set of counters that will be filled by zeroing the first set (so I was able to read out counters and reset them without losing accounting information)? Or at least make zeroing printing out the contents before clearing them? Oh and while we're at it.... *runs away and tries hiding* > (Another thing I just thought of is that this could cause DoS attacks on > the system if a user compromised root and then set the limit to a very > high number.) If you have someone going berzerk as "root" on a firewall you're definitely going to have a completely different set of headaches. Why should someone start DoS attacks after capturing a firewall? It's like painting the fingernails before amputating the hand. Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 10:54: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6EA421532F; Tue, 27 Jul 1999 10:54:02 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA16057; Tue, 27 Jul 1999 11:53:42 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26248; Tue, 27 Jul 1999 11:53:41 -0600 Date: Tue, 27 Jul 1999 11:53:41 -0600 Message-Id: <199907271753.LAA26248@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Achim Patzner Cc: Nate Williams , Julian Elischer , "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <19990727194245.L58970@bnc.net> References: <199907271715.LAA25892@mt.sri.com> <19990727194245.L58970@bnc.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > If you have someone going berzerk as "root" on a firewall you're definitely > going to have a completely different set of headaches. Why should someone > start DoS attacks after capturing a firewall? It's like painting the > fingernails before amputating the hand. So it was a bad example. If I had enough brain cells to boil a cup of water for my soup I'd be able to come up with more 'viable' issues where modifying the counters is a bad thing. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 11:32:45 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 E743214DB7; Tue, 27 Jul 1999 11:32:36 -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 ESMTP id LAA09190; Tue, 27 Jul 1999 11:31:27 -0700 (PDT) Date: Tue, 27 Jul 1999 11:31:27 -0700 (PDT) From: Julian Elischer To: "Brian F. Feldman" Cc: Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999, Brian F. Feldman wrote: > On Tue, 27 Jul 1999, Soren Schmidt wrote: > > > It seems Dag-Erling Smorgrav wrote: > > > > > > I move that we replace GNU grep in our source tree with this > > > implementation, once it's been reviewed by all concerned parties. > > > > Go for it, the more GNU stuff we nuke the better :) > > > > -Søren > > > > Geez, why don't we just write our own compiler and linker, assembler, > and everything? Let's get every last bit of GNU out of our system, for > no reason! This kind of NIH is not necessary, and only hurts us by > misdirecting our energies. > Actually there is a difference between grep and gcc. you wouldn't ship cc on a binray -only embedded system. but you might want to ship grep (so that control scripts an use it). > > Seriously, I'd love for this to happen. Most GNU software is a hopeless, > gruesome mess that should be dragged out and shot. Getting rid of as > much as possible, gradually, is a Very Good Thing; this is how we get > stability and performance improvements. > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 11:58:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 5B52C14BFF; Tue, 27 Jul 1999 11:58:15 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA09504; Tue, 27 Jul 1999 13:56:55 -0500 (CDT) From: Joe Greco Message-Id: <199907271856.NAA09504@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271652.KAA25747@mt.sri.com> from Nate Williams at "Jul 27, 1999 10:52:22 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 13:56:55 -0500 (CDT) Cc: hackers@freebsd.org, freebsd-ipfw@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 > > > You get *better* information on per-rule limits than on a global limit. > > > > No, you simply get a finer-grained ability to select. > > Which is almost always better. > > > > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > > > month of bad packets in it. > > > > > > If you're an admin on today's internet, you'd realize that there is *NO* > > > way to get save a month worth of bad packets. Heck, at least once/week > > > I can't even store a day's worth of bad packets (I assume when we say > > > bad packets, we're talking about the > > > > If I'm an admin on today's internet (and I am), of course I realize that > > I'm not going to save a month worth of all bad packets, but I _can_ choose > > to hold onto a reasonable amount of logging information, which is what we > > are discussing. > > Sure, but you can't call 'tossing 4/5 of the information that I receive > in a totally arbritary manner' useful logging information. A global > count would allow you to log information in a totally arbitrary manner. No, it would give me complete control - up to the point where I've decided that further information is not useful. > In that case, why have separate log rules? You may not ever get to see > them if the limits are hit, so why not just one single rule to catch > everything you want to log, since there's no guarantee that you'll see > any logged information from the other rules. There's no guarantee either way. As long as you specify some limit at all, you risk losing data. Hell, you risk losing data if syslogd can't keep up with the kernel message buffer, or if your disk fills... > You might get something, but it's totally arbitrary and based upon known > 'scripts' on what information is logged. > > Finer grained logging gives you *better* information, since it's more > detailed. If you don't care about details, then why are you logging at > all? Because I want to know when Bad Things Happen. > > That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it > > allows you to sample the beginning of each 5 minute period, and you > > ought to be able to calculate the space required in a manner that > > allows you to guarantee that you have sufficient space. > > I can't speak for the author, but as one of those involved in the > discussion this wasn't even on the radar screen. The purpose of the > option was to make DoS attacks less likely. It wasn't intended to > provide you a good 'sampling' of attack packets on your system. > > Security is not effectively done by sampling. Sampling is too easy to > thwart, and too often misses intrusions that are easily done by not > doing sampling. :) > > And, because IPFW is so low-cost, there is very little reason to do > sampling. Sampling is often done when 'real-time' monitoring is too > expensive. So.... what are you saying? I'm saying that you can set the limit as high as you feel necessary to be comfortable that you are getting sufficient data from the filter. In the event that you exceed the limit, I'm also saying that further data becomes largely irrelevant and/or a liability, and that it should be dropped. I'm not saying I just want to "sample" the first packet I get every five minutes. However, if I'm getting more than a thousand, the additional detail is useless. > What I'm hearing is that you want to change FreeBSD from doing > 'real-time' monitoring to doing polling. The latter can be implemented > from the former, but not vice-versa. We would be losing flexibility and > usefulness by moving towards a 'polling' model. No, nobody except you used the word "polling". You can continue to monitor in realtime. I'm merely looking for a way to restart monitoring after the system has clamped down (VERBOSE_LIMIT) on excessive logging, and I'm also questioning if there is a better way to implement the VERBOSE_LIMIT. > My advice to you is to quit 'polling' for packets (because as you've > implied, you're not interested in the most of the information anyway), Bull f****ng s#!+ I'm not interested in the information! However, I'm probably not interested in (or going to look at) more than 1000 entries per five minute period. > and use a *MUCH* smaller limit on your rules, and limit the number of > rules you have, and you'll have almost the same result. I am _not_ about to reduce the number of rules I feel are necessary to have. They are all there for a good reason. Paranoia. :-) > > Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, > > and you reset the counter every 5 minutes, you still _ought_ to be able to > > determine that you require 2GB of disk space per day to keep those records. > > Great, but why even log data when you *plan* on throwing much of it > away, in a totally arbitrary fashion. Why even bother? So you argue for getting rid of the IPFW_VERBOSE_LIMIT function, then? Well then fine, just be quiet, don't define it in the first place, and abstain from participating in this discussion. Otherwise, you are clearly *planning* to throw away data at some point, so your argument becomes internally inconsistent! > > (And if you're getting 100K rejectable packets every 5 minutes, something > > is seriously wrong) > > Rejectable != log it. I reject alot of packets (most of them) and I > don't care to log them. People do stupid things that aren't worthy of > being logged, and there are alot of stupid people on the net doing > things that aren't malicious that I don't care about. And I do. > And, if you've got 100K 'logged' packets every 5 mins, then you better > plan on having 2GB of disk-space/day if you care about saving them. > > Otherwise, if you don't have that much disk space, then don't reset > every 5 minutes, since you can't keep the information. Either way you > throw away information. With per-rule limits you have a much better > idea on what kinds of information you are throwing away. (Fine-grained > control). You're now arguing that it is OK to throw away information. Talk about fighting whatever side is convenient at the time. > > > If you're logging that much information, then you're logging too much > > > information. In any case, you've got information overload, so adding a > > > global limit on the rules means you're losing as much (or more) > > > information than you're logging, which is just as bad (or worse). > > > > No. You're not necessarily logging too much information. I do log a whole > > bunch of shouldn't-happen scenarios, because if they do happen, it means > > something is either horribly broken or somebody is doing something horribly > > wrong. > > You might not see that happening since you're global rule was hit in the > first 30 seconds by someone doing a POP3 scan of your entire network, > followed by a breakin you missed. > > > I don't want an event such as an outbound source 10-net address to > > happen... in theory it can't because I filter at my borders and use no > > 10-net stuff internally. But I damn well want to know if it happens > > ANYWAYS. > > You will have a very small chance of noticing it with a global limit. That's odd. I see them when they happen. Maybe it is because I'm busy making sure that this kind of stuff doesn't propagate that far into my network in the first place. > If you're truly concerned that you can generate 100K/sec of logging and > want 5 minute resets (or whatever), then build your system with 18GB of > disk and live with it. Otherwise, > > > > If you're worried about logging too much information, then don't reset > > > your counters every 5 minutes. Besides, you're losing information if > > > you're max'd out every 5 minutes anyway, so it really doesn't matter > > > when you zero out your counters. > > > > You just argued my point for me, thank you. I _want_ to see the things that > > I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the > > information is beyond the point of being useful. > > True, but the information you gather that you are losing is totally > arbitrary with a global counter. With individual counters, you tend to > lose information on similar attacks, and in a DoS attack the information > is mostly redundant. Okay, so again you are arguing to lose data. > > > > I don't know what you mean by "make the rules 'more verbose'" but what I > > > > am advocating is not any change in what currently exists... I am talking > > > > about limiting the number of entries possible in a manner that would seem > > > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > > > > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > > > attacks don't hit the entire system on every rule in order to do a DoS > > > attack. Even so, each rule with eventually 'limit-out' and the system > > > will no longer log packets. This is a 'bad thing' from a security > > > standpoint, since at that point we are losing information. > > > > Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, > > and that's perfectly valid as well. > > That's not what I said. You *must* have this to avoid DoS attacks. It _is_ what you said above. > > > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > > > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > > > > > It's not there to make your logfiles small. If you want small logfiles, > > > turn of IPFW logging altogether. > > > > > > (I'm actually serious here.) > > > > Oh, that's a f'ing crock. What _I_ really want is to be able to GET the > > god damn information when the system is in securemode 3 and the damn IPFW > > has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in > > turning OFF IPFW logging? > > Yes, I think you are. You expect to lose information, and you don't > care to know what kind of information you are losing. With per-rule > counters, at least I know what kind of information I'm losing. > > > The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to > > reduce or eliminate the chance of a DoS attack. Now, the best way to > > eliminate the chance of a DoS attack is _algorithmically_. Giving someone > > a mechanism that allows them to determine the maximum resource commitment > > for a given scenario eliminates the chance for that DoS attack. Giving > > someone a mechanism that may use a variable quantity of resources is the > > typical programming practice that leads to a resource starvation DoS. > > Let's see. > > 1) You know your IPFW rule limits > 2) You know how many rules log > 3) You know how often your counters are zero'd. > > Therefore, you can algorithmically determine how many resources are > required (worst case) to not fill up your disks. > > No problem. You have everything you need to do the job. We haven't > done anything different with a global counter *EXCEPT* make the kind of > information you lose in a DoS attack totally arbitrary. > > And, in most DoS attacks, they tend to hit a single rule. You're still > able to gather information on subsequent attacks that are unrelated to > the first attack. > > A win-win situation. > > In any case, you aren't going to convince me that a global counter is > better than a per-rule counter. No way, no how, so I'm going to drop > the discussion. Fine. > > What I absolutely need is a way to clear out the VERBOSE_LIMIT > > counter. > > I've not argued for/against this ability at securelevel 3. I'm of two > minds. There are valid arguments both ways, and without more feedback > from others, I'm certainly not going to code up something or apply > patches that I don't feel comfortable with. > > But, I'm interested in the results, since this is an issue that I face > on a regular basis, hence my postings. > > Somehow, a discussion about zero-ing out firewall counters degenerated > into a global vs. per-rule counter argument, and that's 'counter' to the > original problem. :) :) Yes. > > > One could argue that accounting numbers in a firewall shouldn't be > > > trusted, but I won't argue that point since the firewall is often the > > > most 'natural' place to stick network accounting software. > > > > If you can't trust something in the kernel, then you just can't trust > > anything at all. > > It isn't the kernel that's zero'ing the counters. :) Accounting numbers in a kernel firewall _should_ be trustable, and on that basis, one can clearly make an argument for separating the logging count from the accounting count - which should never be zero'ed, at least in securemode. I'm not saying your desire for per-rule counters is invalid, I'm just not of that same mindset. But it does seem clear that it would be useful to have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT throttle. > > > > Well, the 'right' thing is clear: pull the limit count out of the > > > > accounting count. This solves both the problem of zeroing accounting > > > > counters and potentially messing with other things, and also of letting > > > > people do anything 'negative' in securelevel 3. > > > > > > Is it the 'right' thing to do? I think that someone messing with the > > > 'logging' rule counts could be just as dangerous as someone messing with > > > the accounting counts. > > > > It is no more dangerous > > Agreed. But it's 'just as dangerous', and letting people mess with the > counters in securelevel == 3 *IS* the issue. Should it be allowed? This counter's only function would be to turn off logging after a limit was reached. Therefore, the question of resetting a counter is not the issue... it needs to be "would turning on logging after the kernel stopped it be an issue". I feel the answer is no. > Yes, it's nice to do. But, the point of high securelevel is to avoid > *ANYTHING* (even useful things) that might compromise the integrity of > the system. And, the IPFW counters constitute part of the integrity of > the system. Is it part of the system that should be modifiable? I > don't know, there are issues on both sides of the argument. Neither > side is compelling enough (in my mind) to change the existing behavior. > > I, and somebody zeroing (the only thing they should > > > > Again, if you're paranoid enough to have securelevel 3, you've got to be > > > paranoid enough to assume that someone *HAS* root access on your box, > > > and is going to do anything nasty they could. > > > > Yes, but causing additional logging to happen is going to be something that > > is likely to _attract_ my attention. > > If they've got root, they can also mess with your logfiles. > > > > > By pulling the limit count out into a separate entity, nothing > > > > 'negative' can happen (because stopping the logging process is > > > > definitely negative, and being able to restart it without messing with > > > > other stuff is positive). > > > > > > I'm not sure this is an acceptable change either, but I'll leave that > > > discussion to the networking folks. > > > > > > > Now that we are agreed that the limit count needs to be divorced from the > > > > accounting count, we can debate whether it should be a per-rule or global > > > > limit. > > > > > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > > > putting words in my mouth. :) :) > > > > Well, then, how do you "fix" this problem? > > I don't know if it's a problem that should be fixed. The side-effects > of the fix are potentially as bad as the existing problem. No, because the fix (putting in a separate logging counter) would not allow the accounting counters to be tampered with. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 11:59:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 9B2EC14BEE; Tue, 27 Jul 1999 11:59:26 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA09676; Tue, 27 Jul 1999 13:59:16 -0500 (CDT) From: Joe Greco Message-Id: <199907271859.NAA09676@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271715.LAA25892@mt.sri.com> from Nate Williams at "Jul 27, 1999 11:15:11 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 13:59:16 -0500 (CDT) Cc: julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, jgreco@ns.sol.net, hackers@FreeBSD.ORG, freebsd-ipfw@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 > > I like the ability at secure level 3 to only reset the counters forward.. > > It fits in with such things as the "append only" flag. > > Then we'd have to implement per-rule counters that default to > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > different setup than what we currently have. > > (Another thing I just thought of is that this could cause DoS attacks on > the system if a user compromised root and then set the limit to a very > high number.) This is already possible via sysctl, the VERBOSE_LIMIT variable may be altered. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12: 4:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 83A771535E; Tue, 27 Jul 1999 12:04:27 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA09915; Tue, 27 Jul 1999 14:02:19 -0500 (CDT) From: Joe Greco Message-Id: <199907271902.OAA09915@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271735.LAA26067@mt.sri.com> from Nate Williams at "Jul 27, 1999 11:35:20 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:02:19 -0500 (CDT) Cc: ap@bnc.net, nate@mt.sri.com, dillon@apollo.backplane.com, green@FreeBSD.ORG, jgreco@ns.sol.net, hackers@FreeBSD.ORG, freebsd-ipfw@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 > > > How do you figure? Currently, the kernel will quit 'logging' denied > > > packets when the counter reaches a specific (compiled-in) number. > > ^^^^^^^^^^^^^ > > Then what is > > > > net.inet.ip.fw.verbose_limit: 0 > > Well I'll be. You learn something new everyday. :) > > > made for and why does it help changing it? 8-) > > Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule > counters, when in fact you may only want to change a single counter. The _problem_ with this (and it is FINE for doing interactive work on the system as far as I am concerned) is that in a production environment with machines with 800 day uptimes and securelevel 3, once you pass the VERBOSE_LIMIT, you _can_ disable VERBOSE_LIMIT by setting this to 0, but you then become vulnerable to the DoS attacks we have all been arguing about. In other words, it simply disables VERBOSE_LIMIT. Useful, as I said, if you have a low VERBOSE_LIMIT and you are getting some attack that you want to monitor firsthand in more detail... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:12:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 94E9615260 for ; Tue, 27 Jul 1999 12:12:38 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA01392; Tue, 27 Jul 1999 12:10:58 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 27 Jul 1999 12:10:58 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: "Jordan K. Hubbard" Cc: Tim Vanderhoek , freebsd-hackers@FreeBSD.ORG Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-Reply-To: <2990.933096760@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, 27 Jul 1999, Jordan K. Hubbard wrote: > > the parts that they need. However right after 3.2-R came out there was a > > flurry of -questions mail about broken pkg dependencies because sysinstall > > wasn't properly registering the X install. If the port depending on the > > Just to clear up a misconception; this isn't actually a sysinstall > problem. Okey dokey. As long as y'all are aware of it I'm happy, I just hadn't seen it mentioned. Thanks for clarifying, 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 27 12:17: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 44C5B1522A; Tue, 27 Jul 1999 12:16:49 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17154; Tue, 27 Jul 1999 13:15:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA26782; Tue, 27 Jul 1999 13:15:11 -0600 Date: Tue, 27 Jul 1999 13:15:11 -0600 Message-Id: <199907271915.NAA26782@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271856.NAA09504@aurora.sol.net> References: <199907271652.KAA25747@mt.sri.com> <199907271856.NAA09504@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > One could argue that accounting numbers in a firewall shouldn't be > > > > trusted, but I won't argue that point since the firewall is often the > > > > most 'natural' place to stick network accounting software. > > > > > > If you can't trust something in the kernel, then you just can't trust > > > anything at all. > > > > It isn't the kernel that's zero'ing the counters. :) > > Accounting numbers in a kernel firewall _should_ be trustable, and on that > basis, one can clearly make an argument for separating the logging count > from the accounting count - which should never be zero'ed, at least in > securemode. One could argue that 'logging counters' in a firewall _should_ be trustable as well. You've argued against it, but I'm not convinced that your opinion (or mine) is enough to consider it a 'bug'. > I'm not saying your desire for per-rule counters is invalid, I'm just not > of that same mindset. But it does seem clear that it would be useful to > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT > throttle. It would be useful. But, is it's usefulness more important than being able to rely on 'logging counters' being valid? (You argue no, but I'm not convinced...) Again, it's not a fix, it's a feature. Not being able to mess with counters (logging or otherwise) is a feature. It may be a feature that you can do without, but that decision is not to be made lightly. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:18:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8D9BC1527A; Tue, 27 Jul 1999 12:18:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17187; Tue, 27 Jul 1999 13:17:05 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA26828; Tue, 27 Jul 1999 13:17:05 -0600 Date: Tue, 27 Jul 1999 13:17:05 -0600 Message-Id: <199907271917.NAA26828@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271859.NAA09676@aurora.sol.net> References: <199907271715.LAA25892@mt.sri.com> <199907271859.NAA09676@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I like the ability at secure level 3 to only reset the counters forward.. > > > It fits in with such things as the "append only" flag. > > > > Then we'd have to implement per-rule counters that default to > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > > different setup than what we currently have. > > > > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > This is already possible via sysctl, the VERBOSE_LIMIT variable may be > altered. Can this be altered in securelevel==3? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:31:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by hub.freebsd.org (Postfix) with ESMTP id 36C691527A for ; Tue, 27 Jul 1999 12:31:33 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id OAA04718; Tue, 27 Jul 1999 14:28:35 -0500 (CDT) Received: from sji-ca4-70.ix.netcom.com(205.186.212.198) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma004655; Tue Jul 27 14:27:32 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id MAA38591; Tue, 27 Jul 1999 12:27:24 -0700 (PDT) Date: Tue, 27 Jul 1999 12:27:24 -0700 (PDT) Message-Id: <199907271927.MAA38591@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: jkh@zippy.cdrom.com Cc: Doug@gorean.org, sheldonh@uunet.co.za, vanderh@ecf.utoronto.ca, freebsd-hackers@FreeBSD.ORG In-reply-to: <2990.933096760@zippy.cdrom.com> (jkh@zippy.cdrom.com) Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <2990.933096760@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: "Jordan K. Hubbard" * Just to clear up a misconception; this isn't actually a sysinstall * problem. This is a ports bug which Satoshi or somebody introduced * when they added a dependency on the XFree86 port very prematurely. It * was premature because no actual package exists for XFree86 yet and yet * it's part of the dependancy chain now for a lot of packages, You are entitled to you opinion, but please don't misrepresent the facts. They are not part of the dependency chain for any *packages*. * resulting * in severe dysfunction unless it's removed by hand from the INDEX you * use for package adding. True, but all the INDEX files *I* make for package sets (and those are the only ones you ought to be using, since those are the only ones truly synced with the time of package builds) have the XFree86 stuff stripped. :) -PW To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:49:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 8225F151BF; Tue, 27 Jul 1999 12:49:36 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13262; Tue, 27 Jul 1999 14:49:12 -0500 (CDT) From: Joe Greco Message-Id: <199907271949.OAA13262@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271915.NAA26782@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:15:11 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:49:12 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@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 > > > > > One could argue that accounting numbers in a firewall shouldn't be > > > > > trusted, but I won't argue that point since the firewall is often the > > > > > most 'natural' place to stick network accounting software. > > > > > > > > If you can't trust something in the kernel, then you just can't trust > > > > anything at all. > > > > > > It isn't the kernel that's zero'ing the counters. :) > > > > Accounting numbers in a kernel firewall _should_ be trustable, and on that > > basis, one can clearly make an argument for separating the logging count > > from the accounting count - which should never be zero'ed, at least in > > securemode. > > One could argue that 'logging counters' in a firewall _should_ be > trustable as well. You've argued against it, but I'm not convinced that > your opinion (or mine) is enough to consider it a 'bug'. > > > I'm not saying your desire for per-rule counters is invalid, I'm just not > > of that same mindset. But it does seem clear that it would be useful to > > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT > > throttle. > > It would be useful. But, is it's usefulness more important than being > able to rely on 'logging counters' being valid? (You argue no, but I'm > not convinced...) > > Again, it's not a fix, it's a feature. Not being able to mess with > counters (logging or otherwise) is a feature. It may be a feature that > you can do without, but that decision is not to be made lightly. I'm _saying_ to create a completely separate counter which has nothing to do with accounting. The counter which you "trust" for any purposes can be the accounting counter, which nobody can mess with in securemode. The logging counter is merely to allow VERBOSE_LIMIT whether or not the logging throttle should be engaged, and therefore you can EITHER: 1) Set a global VERBOSE_LIMIT mechanism and: a) allow your logging counter to be reset, or b) allow your limit to be raised to re-enable logging 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's logging counter to be reset. So, what's your vote? (I'm wondering if maybe we can do a combined 1a and 2 of some sort) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:51:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7A0A615392; Tue, 27 Jul 1999 12:51:19 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17620; Tue, 27 Jul 1999 13:51:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA27049; Tue, 27 Jul 1999 13:51:11 -0600 Date: Tue, 27 Jul 1999 13:51:11 -0600 Message-Id: <199907271951.NAA27049@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271949.OAA13262@aurora.sol.net> References: <199907271915.NAA26782@mt.sri.com> <199907271949.OAA13262@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Again, it's not a fix, it's a feature. Not being able to mess with > > counters (logging or otherwise) is a feature. It may be a feature that ^^^^^^^^^^^^^^^^^^^^ > > you can do without, but that decision is not to be made lightly. > > I'm _saying_ to create a completely separate counter which has nothing to > do with accounting. See above. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:52:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4D1E614DD6; Tue, 27 Jul 1999 12:52:00 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13451; Tue, 27 Jul 1999 14:51:34 -0500 (CDT) From: Joe Greco Message-Id: <199907271951.OAA13451@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271917.NAA26828@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:17: 5 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:51:34 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@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 > > > > I like the ability at secure level 3 to only reset the counters forward.. > > > > It fits in with such things as the "append only" flag. > > > > > > Then we'd have to implement per-rule counters that default to > > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > > > different setup than what we currently have. > > > > > > (Another thing I just thought of is that this could cause DoS attacks on > > > the system if a user compromised root and then set the limit to a very > > > high number.) > > > > This is already possible via sysctl, the VERBOSE_LIMIT variable may be > > altered. > > Can this be altered in securelevel==3? # sysctl -a|grep secur kern.securelevel: 3 # sysctl -a|grep verbo net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 0 # sysctl -w net.inet.ip.fw.verbose_limit=999 net.inet.ip.fw.verbose_limit: 0 -> 999 "Any more questions?" :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 12:56:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 80E481544F; Tue, 27 Jul 1999 12:56:24 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13811; Tue, 27 Jul 1999 14:56:18 -0500 (CDT) From: Joe Greco Message-Id: <199907271956.OAA13811@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271951.NAA27049@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:51:11 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:56:17 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@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 > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > counters (logging or otherwise) is a feature. It may be a feature that > ^^^^^^^^^^^^^^^^^^^^ > > > you can do without, but that decision is not to be made lightly. > > > > I'm _saying_ to create a completely separate counter which has nothing to > > do with accounting. > > See above. I did see above. If the sole purpose of a counter is to turn _off_ a feature to prevent DoS attacks, and it is clearly desirable that the admin (or a representative entity such as a monitoring system) would want to be able to re-enable the logging under those same terms at some admin-specified interval, how exactly would you choose to implement this? Please, be specific. If zeroing a counter whose sole purpose in life is to control logging output presents a problem for you, perhaps some other alternative is possible. I'm not quite sure what it would be. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 13: 0:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 137BA15489; Tue, 27 Jul 1999 13:00:01 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17738; Tue, 27 Jul 1999 13:59:59 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA27155; Tue, 27 Jul 1999 13:59:58 -0600 Date: Tue, 27 Jul 1999 13:59:58 -0600 Message-Id: <199907271959.NAA27155@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271956.OAA13811@aurora.sol.net> References: <199907271951.NAA27049@mt.sri.com> <199907271956.OAA13811@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > > counters (logging or otherwise) is a feature. It may be a feature that > > ^^^^^^^^^^^^^^^^^^^^ > > > > you can do without, but that decision is not to be made lightly. > > > > > > I'm _saying_ to create a completely separate counter which has nothing to > > > do with accounting. > > > > See above. > > I did see above. If the sole purpose of a counter is to turn _off_ a > feature to prevent DoS attacks, and it is clearly desirable that the > admin (or a representative entity such as a monitoring system) would > want to be able to re-enable the logging under those same terms at some > admin-specified interval, how exactly would you choose to implement this? What was originally intended and what it's used for now are two different things. I'd like to see people other than you, I, and Matt discussing this. Other people who use this feature of IPFW that have an opinion one way or the other should speak up. A group of two very opinionated people doesn't make a consensus, or necessarily the 'right' decision. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 13: 5:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4FF891522C; Tue, 27 Jul 1999 13:05:36 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id PAA14464; Tue, 27 Jul 1999 15:05:11 -0500 (CDT) From: Joe Greco Message-Id: <199907272005.PAA14464@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271959.NAA27155@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:59:58 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 15:05:11 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@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 > > > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > > > counters (logging or otherwise) is a feature. It may be a feature that > > > ^^^^^^^^^^^^^^^^^^^^ > > > > > you can do without, but that decision is not to be made lightly. > > > > > > > > I'm _saying_ to create a completely separate counter which has nothing to > > > > do with accounting. > > > > > > See above. > > > > I did see above. If the sole purpose of a counter is to turn _off_ a > > feature to prevent DoS attacks, and it is clearly desirable that the > > admin (or a representative entity such as a monitoring system) would > > want to be able to re-enable the logging under those same terms at some > > admin-specified interval, how exactly would you choose to implement this? > > What was originally intended and what it's used for now are two > different things. I agree; the function of verbose log limiting was overloaded onto the existing accounting counter. That is why I am saying that this really, really should be made into a separate log counter, whose sole function in life is counting for the purpose of determining VERBOSE_LIMIT excesses. I am not sure why you seem to have a problem with that. If I have a mechanism that exists for _one_ purpose and one purpose alone, why is it unacceptable to perform operation "X" (where X == zero it) on said device when that is an action that will cause it to work in a desired manner? > I'd like to see people other than you, I, and Matt discussing this. > Other people who use this feature of IPFW that have an opinion one way > or the other should speak up. > > A group of two very opinionated people doesn't make a consensus, or > necessarily the 'right' decision. :) :) :) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 13: 6:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 43E0714DF0 for ; Tue, 27 Jul 1999 13:06:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA01632; Tue, 27 Jul 1999 13:06:15 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 27 Jul 1999 13:06:15 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Kip Macy Cc: "Jordan K. Hubbard" , Josef Karthauser , Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: VMWare plug/quickie tests. 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, 27 Jul 1999, Kip Macy wrote: > Is there anyone in particular to whom we should write at VMWare? > I agree with his sentiments. I picked a likely looking name from the "contact us" page. Make sure that you only write if you are willing to pay for the product if they make it, and then be sure to tell them that if you are. When I responded to their standard "we have no plans for a freebsd port" response with some reasonable, calm information about market share, demographics, etc. the sales droid actually responded with something to the effect of, "Hmmm.. I wasn't aware of that, I'll have to pass that on." So perhaps there is hope, but I'm still not holding my breath. 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 27 13:11: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 A9FF114E2C; Tue, 27 Jul 1999 13:11: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 NAA01865; Tue, 27 Jul 1999 13:08:25 -0700 (PDT) Date: Tue, 27 Jul 1999 13:08:24 -0700 (PDT) From: Julian Elischer To: Joe Greco Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271949.OAA13262@aurora.sol.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG a system wide limit and each rule's logging counter individually resetable back to 0. On Tue, 27 Jul 1999, Joe Greco wrote: > > 1) Set a global VERBOSE_LIMIT mechanism and: > a) allow your logging counter to be reset, or > b) allow your limit to be raised to re-enable logging > 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's > logging counter to be reset. > > So, what's your vote? > > (I'm wondering if maybe we can do a combined 1a and 2 of some sort) > > ... Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 13:24:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id BFC9015481; Tue, 27 Jul 1999 13:23:45 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id WAA75174; Tue, 27 Jul 1999 22:20:33 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 22:20:33 +0200 From: Achim Patzner To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727222033.A75086@bnc.net> References: <199907271951.NAA27049@mt.sri.com> <199907271956.OAA13811@aurora.sol.net> <199907271959.NAA27155@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271959.NAA27155@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 01:59:58PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to see people other than you, I, and Matt discussing this. > Other people who use this feature of IPFW that have an opinion one way > or the other should speak up. I must admit being a bad boy - I'm using ipfw for firewalling and accounting: "log" rules for catching bad guys (and I'm not caring for a limit there as I'm preferring a DoS by crashing the firewall over someone getting through unnoticed) and the counters for accounting (that's why I'd like to have some "read and reset" function so I can milk them without dripping too much). Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 13:28:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id E2B5F153BE for ; Tue, 27 Jul 1999 13:28:46 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA01769; Tue, 27 Jul 1999 13:28:13 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 27 Jul 1999 13:28:13 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing 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 27 Jul 1999, Dag-Erling Smorgrav wrote: > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. First, I'm all for this idea, and applaud you and Jamie for taking it on. I do have a few questions. Does POSIX say anything about grep, and if so, is this version compliant? Also, I'd like to put in another vote for full GNU grep feature compliance, since while having our own code is a good thing, I am against introducing gratuitous differences since I have enough of those to deal with already. I think ports building is a good test, but has anyone tested it with RCS yet? IIRC RCS is heavily dependant on GNU grep, diff and patch. I don't think CVS is dependant on external programs anymore though. I use grep heavily in day to day administration tasks so I look forward to giving this a try. 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 27 13:48:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (Postfix) with ESMTP id B04A01523E for ; Tue, 27 Jul 1999 13:48:55 -0700 (PDT) (envelope-from w@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id WAA10573; Tue, 27 Jul 1999 22:48:46 +0200 (CEST) (envelope-from w@panke.de.freebsd.org) Received: (from w@localhost) by paula.panke.de.freebsd.org (8.9.3/8.8.8) id WAA04703; Tue, 27 Jul 1999 22:42:03 +0200 (CEST) (envelope-from w) Message-ID: <19990727224202.25160@panke.de.freebsd.org> Date: Tue, 27 Jul 1999 22:42:02 +0200 From: Wolfram Schneider To: Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Dag-Erling Smorgrav on Tue, Jul 27, 1999 at 01:37:35PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-07-27 13:37:35 +0200, Dag-Erling Smorgrav wrote: > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > > The source code is available for download from freefall: > > > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. It is 25 times slower than GNU grep ;-((((((( $ time /usr/bin/grep foobar /var/tmp/mailbox >/dev/null 0.90 real 0.78 user 0.12 sys $ time /usr/local/bin/grep foobar /var/tmp/mailbox >/dev/null 24.31 real 22.36 user 1.69 sys (/var/tmp/mailbox is 81MB large). I often use grep for large data (in main memory). I don't care about the GNU license. I care about poor performance. -- Wolfram Schneider http://wolfram.schneider.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 27 13:49: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.ham.muohio.edu (dragon.ham.muohio.edu [134.53.141.33]) by hub.freebsd.org (Postfix) with ESMTP id 5B5B31535F for ; Tue, 27 Jul 1999 13:48:53 -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 PAA02300; Tue, 27 Jul 1999 15:52:26 -0400 X-Authentication-Warning: dragon.ham.muohio.edu: howardjp owned process doing -bs Date: Tue, 27 Jul 1999 15:52:26 -0400 (EDT) From: Jamie Howard X-Sender: howardjp@dragon.ham.muohio.edu To: Doug Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing 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 Tue, 27 Jul 1999, Doug wrote: > First, I'm all for this idea, and applaud you and Jamie for taking > it on. I do have a few questions. Does POSIX say anything about grep, and > if so, is this version compliant? Also, I'd like to put in another vote > for full GNU grep feature compliance, since while having our own code is a > good thing, I am against introducing gratuitous differences since I have > enough of those to deal with already. I do not have a copy of POSIX, but I do have Unix98 which is a superset of POSIX. Right now, excluding bugs, it is Unix 98 and therefore POSIX compliant except for -e. -e should permit multiple patterns and it never occured to me that anyone would want to do this. When used with -F, multiple patterns are accepted. > I use grep heavily in day to day administration tasks so I look > forward to giving this a try. Cool, d/l it and post a bug-list :) 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 27 14: 1:56 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 2E0A114C4F for ; Tue, 27 Jul 1999 14:01:52 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18348.on.bellglobal.com [206.172.130.28]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id RAA08706; Tue, 27 Jul 1999 17:03:15 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id RAA37628; Tue, 27 Jul 1999 17:02:10 -0400 (EDT) (envelope-from tim) Date: Tue, 27 Jul 1999 17:02:09 -0400 From: Tim Vanderhoek To: "Jordan K. Hubbard" Cc: Doug , Sheldon Hearn , freebsd-hackers@FreeBSD.ORG Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? Message-ID: <19990727170209.B37558@mad> References: <379D4684.FE083FB@gorean.org> <2990.933096760@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <2990.933096760@zippy.cdrom.com>; from Jordan K. Hubbard on Tue, Jul 27, 1999 at 10:32:40AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 10:32:40AM -0700, Jordan K. Hubbard wrote: > > Just to clear up a misconception; this isn't actually a sysinstall > problem. This is a ports bug which Satoshi or somebody introduced > when they added a dependency on the XFree86 port very prematurely. It I can claim a bit of the responsibility. It was done after Sue Blake complained that there was no way to distinguish packages requiring X from those that didn't. I wrote some extended message discussing different types of dependencies, and then Satoshi wrote the change. However, my archives show I pointed-out the problem (with possible solutions) from the start. Perhaps I would have been more urgent if I'd forseen the future, but it's one of those things you look at and figure "ah, it's so Freaking obvious that someone will fix it". The change was made long before the release and there was plenty of time to fix any breakage. It was just never fixed. -- 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 27 14: 7:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 2176914C4F for ; Tue, 27 Jul 1999 14:07:48 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA01965; Tue, 27 Jul 1999 14:07:39 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 27 Jul 1999 14:07:39 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Jamie Howard Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing 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 Tue, 27 Jul 1999, Jamie Howard wrote: > I do not have a copy of POSIX, but I do have Unix98 which is a superset of > POSIX. Right now, excluding bugs, it is Unix 98 and therefore POSIX > compliant Good news, thanks for addressing this concern. > except for -e. -e should permit multiple patterns and it never > occured to me that anyone would want to do this. Ah, well, if the world were limited to just what I could imagine, how boring would that be? The more complete the feature set, the better off we are for my money. 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 27 14:17:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.veriguard.com (relay.securify.com [207.5.63.61]) by hub.freebsd.org (Postfix) with ESMTP id 1309D14EB3 for ; Tue, 27 Jul 1999 14:17:15 -0700 (PDT) (envelope-from kdl@securify.com) Received: by relay.veriguard.com; id OAA03725; Tue, 27 Jul 1999 14:15:58 -0700 (PDT) Received: from unknown(10.5.63.6) by relay.veriguard.com via smap (4.1) id xma003675; Tue, 27 Jul 99 14:15:19 -0700 Received: from securify.com (psyche.securify.com [10.5.63.231]) by dude.veriguard.com (8.8.7/8.8.7) with ESMTP id OAA21937 for ; Tue, 27 Jul 1999 14:15:17 -0700 Message-ID: <379E2139.E26E6780@securify.com> Date: Tue, 27 Jul 1999 14:14:33 -0700 From: "Kelly D. Lucas" Organization: Kroll-O'Gara X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hackers@hub.freebsd.org Subject: SMC 1211TX Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? thanks, kdl -- Kelly D. Lucas | Kroll-O'Gara Security Consultant | Information Security Group kdl@securify.com | 650-812-9400 x 117 "Any opinions that I state are my own, and not Kroll-O'Gara's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 14:28:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 69BAD14F72 for ; Tue, 27 Jul 1999 14:28:32 -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 OAA01811; Tue, 27 Jul 1999 14:26:06 -0700 (PDT) Message-Id: <199907272126.OAA01811@lestat.nas.nasa.gov> To: "Kelly D. Lucas" Cc: hackers@hub.freebsd.org Subject: Re: SMC 1211TX Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 27 Jul 1999 14:26:05 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 14:14:33 -0700 "Kelly D. Lucas" wrote: > Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? As far as I can tell, this is a RealTek 8139 board. -- 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 Tue Jul 27 14:41:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bantu.cl.msu.edu (bantu.cl.msu.edu [35.8.3.18]) by hub.freebsd.org (Postfix) with ESMTP id 0AAF614EBF for ; Tue, 27 Jul 1999 14:41:30 -0700 (PDT) (envelope-from dervish@bantu.cl.msu.edu) Received: (from dervish@localhost) by bantu.cl.msu.edu (8.9.3/8.9.3) id RAA00449; Tue, 27 Jul 1999 17:40:17 -0400 (EDT) (envelope-from dervish) Date: Tue, 27 Jul 1999 17:40:17 -0400 From: bush doctor To: "Kelly D. Lucas" Cc: hackers@freebsd.org Subject: Re: SMC 1211TX Message-ID: <19990727174017.A410@bantu.cl.msu.edu> References: <379E2139.E26E6780@securify.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <379E2139.E26E6780@securify.com>; from Kelly D. Lucas on Tue, Jul 27, 1999 at 02:14:33PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT i386 X-PGP-Fingerprint: 35 95 F8 63 DA 5B 32 51 8F A9 AC 3C B4 74 F3 BA WWW-Home-Page: http://www.msu.edu/~ikhala Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Out of da blue Kelly D. Lucas aka (kdl@securify.com) said: > Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? Yes it's the real tek driver. device rl0 # RealTek 8129/8139 > > thanks, > > kdl > > -- > Kelly D. Lucas | Kroll-O'Gara > Security Consultant | Information Security Group > kdl@securify.com | 650-812-9400 x 117 > "Any opinions that I state are my own, and not Kroll-O'Gara's" > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message #:^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 15: 0: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 C6BB315386 for ; Tue, 27 Jul 1999 15:00:09 -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 RAA57855; Tue, 27 Jul 1999 17:59:44 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 17:59:43 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: Rayson Ho , freebsd-hackers@FreeBSD.org Subject: Re: Free BSDI CD! In-Reply-To: <3014.933096939@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, 27 Jul 1999, Jordan K. Hubbard wrote: > > But we can install from a single downloaded boot floppy, over the > > Internet, which is better. > > 1. Irrelevant, since most people who want to try BSD/OS out probably > aren't concerned about how FreeBSD installs itself; they're > simply different products. That compete for the same market. > > 2. Incorrect, since we don't install off a single floppy either. Feh, depends on the floppy size. Anyway, we still install off two then :P > > In other words, "you lose, but thanks for playing and here's a copy of > our home game." My point was that it's not a very important thing to do to give out FreeBSD CDs like BSD/OS gives out trial versions of their wares. > > - 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 27 15:34:54 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 B16C914E62 for ; Tue, 27 Jul 1999 15:34:46 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac9.wam.umd.edu (root@rac9.wam.umd.edu [128.8.10.149]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id SAA16903; Tue, 27 Jul 1999 18:33:05 -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 SAA04557; Tue, 27 Jul 1999 18:33:04 -0400 (EDT) Received: from localhost by rac9.wam.umd.edu (8.9.3/8.9.3) with ESMTP id SAA04553; Tue, 27 Jul 1999 18:33:04 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: howardjp owned process doing -bs Date: Tue, 27 Jul 1999 18:33:03 -0400 (EDT) From: James Howard To: Doug Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: replacing 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 Tue, 27 Jul 1999, Doug wrote: > Ah, well, if the world were limited to just what I could imagine, > how boring would that be? The more complete the feature set, the better > off we are for my money. You misinterpretted, I didn't know you could do that therefore I didn't implement that. I certainly understand why you would want to :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 15:41:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 0AFE514F2F for ; Tue, 27 Jul 1999 15:41:44 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id AAA07292; Wed, 28 Jul 1999 00:37:33 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id AAA28942; Wed, 28 Jul 1999 00:36:41 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id AAA08098; Wed, 28 Jul 1999 00:37:33 +0200 (CEST) (envelope-from ticso) Date: Wed, 28 Jul 1999 00:37:32 +0200 From: Bernd Walter To: Greg Lehey Cc: Alexander Maret , freebsd-hackers@FreeBSD.ORG Subject: Re: Which /etc-files do I need until vinum is initialized? Message-ID: <19990728003731.A8075@cicely8.cicely.de> References: <91DA20EC3C3DD211833400A0245A4EA9BA10A8@erlangen01.axis.de> <19990727171249.X62218@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990727171249.X62218@freebie.lemis.com>; from Greg Lehey on Tue, Jul 27, 1999 at 05:12:49PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 05:12:49PM +0930, Greg Lehey wrote: > each. But I think you could eliminate these ones: > > > /etc/gettytab > > /etc/login.conf > > /etc/ttys > I'm not shure on /etc/ttys - init reads it already for singleuser-mode to check if /dev/console is secure. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 15:46:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 6E0DE14ED8 for ; Tue, 27 Jul 1999 15:46:30 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: from localhost (billf@localhost) by jade.chc-chimes.com (8.9.3/8.9.3) with ESMTP id OAA13528; Tue, 27 Jul 1999 14:08:20 -0400 (EDT) (envelope-from billf@jade.chc-chimes.com) Date: Tue, 27 Jul 1999 14:08:20 -0400 (EDT) From: Bill Fumerola To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.org Subject: Re: replacing 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 27 Jul 1999, Dag-Erling Smorgrav wrote: > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Normally I don't post "me too" messages. I'll make an exception. Me too. -- - 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 Tue Jul 27 16: 4:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by hub.freebsd.org (Postfix) with ESMTP id 1573F14F37 for ; Tue, 27 Jul 1999 16:04:43 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id SAA22226; Tue, 27 Jul 1999 18:02:41 -0500 (CDT) Received: from sji-ca4-70.ix.netcom.com(205.186.212.198) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma022186; Tue Jul 27 18:02:20 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id QAA39262; Tue, 27 Jul 1999 16:02:10 -0700 (PDT) Date: Tue, 27 Jul 1999 16:02:10 -0700 (PDT) Message-Id: <199907272302.QAA39262@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: vanderh@ecf.utoronto.ca Cc: jkh@zippy.cdrom.com, Doug@gorean.org, sheldonh@uunet.co.za, freebsd-hackers@FreeBSD.ORG In-reply-to: <19990727170209.B37558@mad> (message from Tim Vanderhoek on Tue, 27 Jul 1999 17:02:09 -0400) Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <379D4684.FE083FB@gorean.org> <2990.933096760@zippy.cdrom.com> <19990727170209.B37558@mad> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Tim Vanderhoek * I can claim a bit of the responsibility. It was done after Sue Blake * complained that there was no way to distinguish packages requiring X * from those that didn't. I wrote some extended message discussing * different types of dependencies, and then Satoshi wrote the change. * * However, my archives show I pointed-out the problem (with possible * solutions) from the start. Perhaps I would have been more urgent if * I'd forseen the future, but it's one of those things you look at and * figure "ah, it's so Freaking obvious that someone will fix it". * * The change was made long before the release and there was plenty of * time to fix any breakage. It was just never fixed. Ok, but also note that there aren't any dependencies left in packages anymore. I intend to ressurect those when the XFree86 port is broken up into more manageable chunks, but until then, the packages will ship with no XFree86 dependencies. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 16:14:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 741D414D88 for ; Tue, 27 Jul 1999 16:14:05 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA03781; Tue, 27 Jul 1999 16:12:57 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 27 Jul 1999 16:12:56 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: James Howard Cc: hackers@FreeBSD.ORG Subject: Re: replacing 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 Tue, 27 Jul 1999, James Howard wrote: > On Tue, 27 Jul 1999, Doug wrote: > > > Ah, well, if the world were limited to just what I could imagine, > > how boring would that be? The more complete the feature set, the better > > off we are for my money. > > You misinterpretted, I didn't know you could do that therefore I didn't > implement that. I certainly understand why you would want to :) Ah, gotcha. Even better. :) 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 27 18: 8: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 AAFF714CA4; Tue, 27 Jul 1999 18:07:01 -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 KAA25402; Wed, 28 Jul 1999 10:34:50 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA67327; Wed, 28 Jul 1999 10:34:49 +0930 (CST) Date: Wed, 28 Jul 1999 10:34:49 +0930 From: Greg Lehey To: Sue Blake Cc: FreeBSD Hackers Subject: Re: adding to periodic/weekly Message-ID: <19990728103449.I66861@freebie.lemis.com> References: <19990728030422.I7349@welearn.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990728030422.I7349@welearn.com.au>; from Sue Blake on Wed, Jul 28, 1999 at 03:04:25AM +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 Wednesday, 28 July 1999 at 3:04:25 +1000, Sue Blake wrote: > I want to add some maintenance tasks to be run weekly (maybe daily ones too). > There seem to be at least five ways to do this: > > Just add it to the system crontab > - Can run at a different time, if necessary. Leaves periodic unmolested. > - Separates it from other weeklies, could become lost or confusing. > Add it to /etc/periodic/weekly/999.local > - This might be what the file is intended for. > - Maybe I shouldn't clutter that file. > Create /etc/weekly.local and put it in there > - It's tempting because 999.local picks it up if present. > - Comment says this is only for backward compatibility. > Add another file /etc/periodic/weekly/.whatever > - Can keep it away from existing sequence, or insert if necessary > - Future upgrades might add files using the numbers I choose > Put it in a numbered file under /usr/local/etc/periodic/weekly/ > - This seems to be what it's intended for, but nobody said I could > - Path is already in rc.conf but doesn't exist, not sure why not used > - Can't find doc on its use, e.g. run in path order? unique numbers required? > > Which method is generally best, and why? > Are any of these methods really naughty? Interesting question. I don't have any personal preferences, though I put my stuff in /etc/crontab or my private crontab out of habit. But this is probably material for -hackers, so I'm forwarding it there. 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 Tue Jul 27 18:47: 3 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 9062914CD0 for ; Tue, 27 Jul 1999 18:46:56 -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 0ED881C9E; Wed, 28 Jul 1999 09:44:03 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: "Kelly D. Lucas" , hackers@hub.freebsd.org Subject: Re: SMC 1211TX In-reply-to: Your message of "Tue, 27 Jul 1999 14:26:05 MST." <199907272126.OAA01811@lestat.nas.nasa.gov> Date: Wed, 28 Jul 1999 09:44:03 +0800 From: Peter Wemm Message-Id: <19990728014403.0ED881C9E@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > On Tue, 27 Jul 1999 14:14:33 -0700 > "Kelly D. Lucas" wrote: > > > Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? > > As far as I can tell, this is a RealTek 8139 board. Oh my, SMC must be really lowering their standards... Cheers, -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 27 18:53: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from forty-two.egroups.net (teapot.findmail.com [206.16.70.98]) by hub.freebsd.org (Postfix) with ESMTP id 6653814F59 for ; Tue, 27 Jul 1999 18:53:00 -0700 (PDT) (envelope-from gsutter@forty-two.egroups.net) Received: (from gsutter@localhost) by forty-two.egroups.net (8.9.3/8.9.2) id SAA35115; Tue, 27 Jul 1999 18:49:53 -0700 (PDT) (envelope-from gsutter) Date: Tue, 27 Jul 1999 18:49:53 -0700 From: Gregory Sutter To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990727184953.B391@forty-two.egroups.net> 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 Tue, Jul 27, 1999 at 01:37:35PM +0200 Organization: Zer0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote: > Jamie Howard (howardjp@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. This implementation's performance on large files will have to be radically improved before it is an adequate substitute for GNU grep. One-seventh the source and one-fourth the binary is great, as long as it has full functionality. Greg -- Gregory S. Sutter Mostly Harmless mailto:gsutter@pobox.com http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 19:50: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 4F12914C1A; Tue, 27 Jul 1999 19:50:20 -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 WAA67212; Tue, 27 Jul 1999 22:48:46 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 22:48:46 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271915.NAA26782@mt.sri.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 If it will get ALL of you to give it a rest, how about: per-rule logging limits logging limit raising logging limit resetting Which would all NOT affect the statistics? I am, yes, suggesting I will implement it. 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 27 20:28:59 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 D4796153DA for ; Tue, 27 Jul 1999 20:28:39 -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 VAA68747; Tue, 27 Jul 1999 21:28:04 -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 VAA68348; Tue, 27 Jul 1999 21:29:24 -0600 (MDT) Message-Id: <199907280329.VAA68348@harmony.village.org> To: Sheldon Hearn Subject: Re: securelevel too course-grained? Cc: Matthew Dillon , hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Jul 1999 07:37:26 +0200." <87126.933053846@axl.noc.iafrica.com> References: <87126.933053846@axl.noc.iafrica.com> Date: Tue, 27 Jul 1999 21:29:24 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <87126.933053846@axl.noc.iafrica.com> Sheldon Hearn writes: : I have a feeling it'll be time soon enough for us to make each of the : decisions that is normally affected by securelevel dependant on the : value of sysctl knobs. Presumeably one or more of them would be : "write-once" knobs. :-) Yes. That's what I favor. : How much existing software tests for kern.securelevel? And could we : make its value dependant on the new knobs? I can't see it being too big : a problem. I don't think we should eliminate secure levels. However, I think at high secure levels, one can no longer change the value of some sysctls. Ideally, each sysctl would have the highest level that it can be changed at encoded into it. Less ideally, there would be a flag bit that said that it can't be change at secure levels > 0. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 20:34:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 1558C15396 for ; Tue, 27 Jul 1999 20:34:11 -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 UAA05885; Tue, 27 Jul 1999 20:31:37 -0700 (PDT) Message-Id: <199907280331.UAA05885@lestat.nas.nasa.gov> To: Peter Wemm Cc: "Kelly D. Lucas" , hackers@hub.freebsd.org Subject: Re: SMC 1211TX Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 27 Jul 1999 20:31:36 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999 09:44:03 +0800 Peter Wemm wrote: > > As far as I can tell, this is a RealTek 8139 board. > > Oh my, SMC must be really lowering their standards... The SMC9432TX is still an EPIC/100. The newer revs of that board are bug-free (unlike earlier models). I've had quite a lot of success with those boards under NetBSD; they perform *quite* well. -- 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 Tue Jul 27 20:41: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 7FDC415396; Tue, 27 Jul 1999 20:40:23 -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 VAA68776; Tue, 27 Jul 1999 21:39:14 -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 VAA68413; Tue, 27 Jul 1999 21:40:34 -0600 (MDT) Message-Id: <199907280340.VAA68413@harmony.village.org> To: Sheldon Hearn Subject: Re: newsyslog owner.group -> owner:group Cc: Tim Vanderhoek , obrien@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Jul 1999 17:11:49 +0200." <19755.933088309@axl.noc.iafrica.com> References: <19755.933088309@axl.noc.iafrica.com> Date: Tue, 27 Jul 1999 21:40:34 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19755.933088309@axl.noc.iafrica.com> Sheldon Hearn writes: : +#ifdef SUPPORT_DOT : + /* Older configurations used '.' between user and group */ : + if ((group = strchr(q, ':')) != NULL || : + (group = strchr(q, '.')) != NULL) { : +#else : if ((group = strchr(q, ':')) != NULL) { : +#endif : *group++ = '\0'; A better patch would check to see if the text to the right of the '.' is a valid group... However, the above will still parse fred.jones:fred.jones in the most desirable way, so I suppose the validity checking is overkill. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 21:22:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 1530D14DC3 for ; Tue, 27 Jul 1999 21:22:18 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-74.ucdavis.edu [169.237.16.74]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id VAA05095; Tue, 27 Jul 1999 21:21:30 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id VAA66779; Tue, 27 Jul 1999 21:21:29 -0700 (PDT) (envelope-from obrien) Date: Tue, 27 Jul 1999 21:21:26 -0700 From: "David O'Brien" To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: newsyslog owner.group -> owner:group Message-ID: <19990727212126.E66569@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19755.933088309@axl.noc.iafrica.com> <199907280340.VAA68413@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199907280340.VAA68413@harmony.village.org>; from Warner Losh on Tue, Jul 27, 1999 at 09:40:34PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A better patch would check to see if the text to the right of the '.' > is a valid group... However, the above will still parse > > fred.jones:fred.jones > > in the most desirable way, so I suppose the validity checking is > overkill. This is what I plan to commit (w/in minutes): - if ((group = strchr(q, ':')) != NULL) { + if ((group = strchr(q, ':')) != NULL || + (group = strrchr(q, '.')) != NULL) { It the becomes [almost totally] non-ambigitous (since the separator is required) and allows "david.obrien.staff". In my mind more people use dots in usernames than group names. Anyay, it is documented to use :, and I am just trying to be "liberal in what is accepted" (w/o obfuscating the code). -- -- David (obrien@NUXI.com -or- obrien@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 27 21:35:59 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 BE14C14CF5 for ; Tue, 27 Jul 1999 21:35:50 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac9.wam.umd.edu (root@rac9.wam.umd.edu [128.8.10.149]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA26439 for ; Wed, 28 Jul 1999 00:35:47 -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 AAA21806 for ; Wed, 28 Jul 1999 00:35:46 -0400 (EDT) Received: from localhost by rac9.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA21802 for ; Wed, 28 Jul 1999 00:35:46 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: howardjp owned process doing -bs Date: Wed, 28 Jul 1999 00:35:45 -0400 (EDT) From: James Howard To: freebsd-hackers@freebsd.org Subject: Re: replacing 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 Due to the discussion of speed, I have been looking at it and it is really slow. Even slower than I thought and I was thinking it was pretty slow. So using gprof, I have discovered that it seems to spend a whole mess of time in grep_malloc() and free(). So I pulled all the references to malloc inside the main loop (the copy for ln.dat and removed queueing). This stills leaves us with a grep that is about ~6x slower than GNU. Before that, it ran closer to 80x. After this, gprof says it spends around 53% of its time in procline(). Now, Tim Vanderhoek originally pointed this out and suggested that there was a whole lot of unnecessary string copying and mallocing going on. He was right. The file name also gets copied back and forth and I don't think this is required either. Now, it seems to me that the queue could be sped up significantly using an array-based implementation. The queue is never going to be larger than Bflag entries in size so a one time malloc at initqueue() would remove a lot of the malloc/free combos from the program. Good idea/bad idea? The pointer returned from fgetln is valid only until the next IO call, so perhaps the string as returned from fgetln should be passed directly to procline() and only copied if -B has been given. This will speed up grep in the common case of no leading context needing to be printed. Trailing context is not affected by this. Unfortunetly, this does nothing for zgrep, but I have not benchmarked zgrep yet. I don't even want to think about it, gzfgetln() reallocs on every byte read. One thing that concerns me is the lack of consistant timings. Using time, sometimes I get real times up to 100% apart on consecutive runs. If I do GNU grep, it is never off by more than 5% or so. What could be causing this? Since it will still be slower than GNU, but quite a bit, at least 6x, does anyone else see ways to cut some fat? 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 27 21:46:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 5050314C28 for ; Tue, 27 Jul 1999 21:46:49 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-4-17.ucdavis.edu [169.237.17.145]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id VAA05168; Tue, 27 Jul 1999 21:44:54 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id VAA67108; Tue, 27 Jul 1999 21:44:52 -0700 (PDT) (envelope-from obrien) Date: Tue, 27 Jul 1999 21:44:51 -0700 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) Message-ID: <19990727214451.A66970@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Dag-Erling Smorgrav on Tue, Jul 27, 1999 at 01:37:35PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Before importing, it must display a version number of 1.0 (or drop the version number). This is not Linux where everything is version 0.xy. -- -- David (obrien@NUXI.com -or- obrien@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 27 21:50:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 75C2D14DC3; Tue, 27 Jul 1999 21:50:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA24109; Tue, 27 Jul 1999 22:49:03 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA29417; Tue, 27 Jul 1999 22:49:02 -0600 Date: Tue, 27 Jul 1999 22:49:02 -0600 Message-Id: <199907280449.WAA29417@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907271915.NAA26782@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If it will get ALL of you to give it a rest, how about: > per-rule logging limits > logging limit raising > logging limit resetting > Which would all NOT affect the statistics? We need more input from people who use the code, to make sure they don't depend on the current 'features', or can live with changes to them. Implementing it is the easy part, making sure it's the right thing to do is the hard part. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 22:11:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C589214C08 for ; Tue, 27 Jul 1999 22:11:11 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id WAA05330; Tue, 27 Jul 1999 22:09:15 -0700 (PDT) (envelope-from obrien) Message-ID: <19990727220915.A5283@nuxi.com> Date: Tue, 27 Jul 1999 22:09:15 -0700 From: "David O'Brien" To: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from James Howard on Wed, Jul 28, 1999 at 12:35:45AM -0400 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG $ uname -a $ grep foo NONEXIST Segmentation fault (core dumped) $ gdb /usr/bin/grep grep.core ... (no debugging symbols found)... Core was generated by `grep'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.3...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x280a8538 in ftello (fp=0x0) at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76 76 if (fp->_seek == NULL) { (gdb) where #0 0x280a8538 in ftello (fp=0x0) at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76 #1 0x280a84e1 in ftell (fp=0x0) at /FBSD/src/lib/libc/../libc/stdio/ftell.c:59 #2 0x80490b7 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089 #3 0x80499f1 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089 #4 0x804968b in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089 #5 0x8048d3d in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089 (gdb) -- -- David (obrien@NUXI.com -or- obrien@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 27 22:11:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 8F71114C08 for ; Tue, 27 Jul 1999 22:11:20 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id WAA05345; Tue, 27 Jul 1999 22:10:17 -0700 (PDT) (envelope-from obrien) Message-ID: <19990727221017.B5283@nuxi.com> Date: Tue, 27 Jul 1999 22:10:17 -0700 From: "David O'Brien" To: Robert Nordier Cc: hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Reply-To: obrien@FreeBSD.ORG References: <199907271625.SAA05638@c2-10-dbn.dial-up.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199907271625.SAA05638@c2-10-dbn.dial-up.net>; from Robert Nordier on Tue, Jul 27, 1999 at 06:25:43PM +0200 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A more general concern is whether Henry Spencer's regex routines > -- at least in our present "alpha-quality" version -- are up to I spoke to Henry at USENIX and he said he has a new version of his regex library. I have added it to my plate of things to update. -- -- David (obrien@NUXI.com -or- obrien@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 27 22:23:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 146FB1502A for ; Tue, 27 Jul 1999 22:23:25 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id WAA05403; Tue, 27 Jul 1999 22:20:40 -0700 (PDT) (envelope-from obrien) Message-ID: <19990727222040.E5283@nuxi.com> Date: Tue, 27 Jul 1999 22:20:40 -0700 From: "David O'Brien" To: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo Reply-To: obrien@FreeBSD.ORG References: <66454.932977516@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <66454.932977516@axl.noc.iafrica.com>; from Sheldon Hearn on Mon, Jul 26, 1999 at 10:25:16AM +0200 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've had some interesting comments from David Bushong, motivating for > inclusion of his Magdir candidate on PR 12554. He makes a strong case > for a bloated file(1) Magdir. The only thing we're battling with is a > filename for his submission. My advice would be to submit his PR to Chris Demtrito(sp?), file's maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Thus we see what Chris calls it, and we stay in sync with the offical distribution. ...something on my list of things to update in src/contrib/ over the summer. -- -- David (obrien@NUXI.com -or- obrien@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 27 22:36:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id E35C11502A for ; Tue, 27 Jul 1999 22:36:34 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id WAA05456; Tue, 27 Jul 1999 22:36:19 -0700 (PDT) (envelope-from obrien) Message-ID: <19990727223619.G5283@nuxi.com> Date: Tue, 27 Jul 1999 22:36:19 -0700 From: "David O'Brien" To: Osokin Sergey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Missing ld.so in 3.2? Reply-To: obrien@FreeBSD.ORG References: <4.1.19990723173616.009fb3e0@mail.venux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Osokin Sergey on Sat, Jul 24, 1999 at 02:07:33AM +0400 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think u must read following: > http://www.freebsd.org/releases/3.2R/errata.html There is nothing on the 3.2 errata that addresses this. -- -- David (obrien@NUXI.com -or- obrien@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 27 23: 0:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 49EC31502A for ; Tue, 27 Jul 1999 23:00:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id WAA05518; Tue, 27 Jul 1999 22:58:08 -0700 (PDT) (envelope-from obrien) Message-ID: <19990727225808.H5283@nuxi.com> Date: Tue, 27 Jul 1999 22:58:08 -0700 From: "David O'Brien" To: "Jordan K. Hubbard" , itojun@iijlab.net Cc: hackers@FreeBSD.ORG Subject: Re: Will FreeBSD ever see native IPv6 ?? Reply-To: obrien@FreeBSD.ORG References: <9128.932724101@coconut.itojun.org> <71662.932744033@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <71662.932744033@zippy.cdrom.com>; from Jordan K. Hubbard on Fri, Jul 23, 1999 at 08:33:53AM -0700 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > various researchers and early-adopters, all of which can go to the > KAME site and grab the patches to 3.2-stable if they want to play now, > today. If we haven't done a good enough job of making that clear and > are suffering from defections to other *BSDs because of this, then we > just need to get the word out better. :-) Since KAME is probably closest to unified, I think we need to point people to the "offical" IPv6 patch set. The problem is the IPv6 wanting user does not know which of the available stacks to go with. It is easy to feel one would have to download 3 different stacks and experiement with all to determine which one works well. Lets help these people out. How about adding this to 3.3's RELEASE notes and a pointer from our website? (maybe also http://www.freebsd.org/handbook/install.html) -- -- David (obrien@NUXI.com -or- obrien@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 27 23:12:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vipunen.hut.fi (vipunen-a.hut.fi [130.233.249.7]) by hub.freebsd.org (Postfix) with ESMTP id 5734714FB9 for ; Tue, 27 Jul 1999 23:12:39 -0700 (PDT) (envelope-from kuparine@vipunen.hut.fi) Received: from vipunen-a.hut.fi (vipunen-a.hut.fi [130.233.249.7]) by vipunen.hut.fi (8.9.3/8.9.3) with ESMTP id JAA514494; Wed, 28 Jul 1999 09:10:15 +0300 Date: Wed, 28 Jul 1999 09:10:14 +0300 (EET DST) From: Martti Kuparinen To: hackers@FreeBSD.ORG Cc: snap-users@kame.net Subject: FreeBSD and native IPv6 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 have created a script to integrate FreBSD 3.2, KAME and PAO. As a result I have the following source trees: - FREEBSD+KAME ("make world" is working :-) - FREEBSD+PAO (haven't tested yet, no conflicts) - FREEBSD+KAME+PAO (haven't tested yet, 2 minor conflicts) Once I have everything working I'll send detailed instructions how to do it :-) I expect (or must) finish this by Friday as I going to holiday trip on Saturday morning... Martti To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 27 23:20:36 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 395C815416; Tue, 27 Jul 1999 23:20:29 -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 CAA71895; Wed, 28 Jul 1999 02:19:06 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 02:19:06 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907280449.WAA29417@mt.sri.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, 27 Jul 1999, Nate Williams wrote: > > If it will get ALL of you to give it a rest, how about: > > per-rule logging limits > > logging limit raising > > logging limit resetting > > Which would all NOT affect the statistics? > > We need more input from people who use the code, to make sure they don't > depend on the current 'features', or can live with changes to them. > > Implementing it is the easy part, making sure it's the right thing to do > is the hard part. Well, the easy part is done, except for raising limits. Look: ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: limit 2 reached on rule #1 ipfw: Entry 1 logging count reset. ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: limit 2 reached on rule #1 Nice? :) I think this feature should DEFINITELY go in. I'm going to clean it up some (ip_fw.c itself), and then make a set of diffs for this feature. > > > Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" 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 Wed Jul 28 0:31: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 3CA7B15442; Wed, 28 Jul 1999 00:30:51 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id JAA57654; Wed, 28 Jul 1999 09:29:17 +0200 (CEST) (envelope-from des) To: "Brian F. Feldman" Cc: Sheldon Hearn , Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) References: Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 28 Jul 1999 09:29:17 +0200 In-Reply-To: "Brian F. Feldman"'s message of "Tue, 27 Jul 1999 09:05:46 -0400 (EDT)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" writes: > That's true. I'd like to see the replacement grep do mmaping of the > input files if it doesn't already, as that would speed it up. Shouldn't be too hard to implement, the way file operations are abstracted. Patches? :) DES -- Dag-Erling Smorgrav - des@yes.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 28 0:31:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 59F5415434; Wed, 28 Jul 1999 00:30:39 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id JAA57650; Wed, 28 Jul 1999 09:27:14 +0200 (CEST) (envelope-from des) To: Sheldon Hearn Cc: "Brian F. Feldman" , Soren Schmidt , Dag-Erling Smorgrav , hackers@FreeBSD.org Subject: Re: replacing grep(1) References: <12615.933078748@axl.noc.iafrica.com> Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 28 Jul 1999 09:27:13 +0200 In-Reply-To: Sheldon Hearn's message of "Tue, 27 Jul 1999 14:32:28 +0200" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > In this case, the implementation we'll be introducing will introduce a > performance loss, not a gain. Can you document that? > As far as stability goes, there's a loss > involved _if_ passing the GNU grep regression tests is important. Do you mean that Jamie's implementation doesn't pass those regression tests? If they don't, we can fix it before importing it into the tree. DES -- Dag-Erling Smorgrav - des@yes.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 28 0:31:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id C560C15481 for ; Wed, 28 Jul 1999 00:31:28 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id JAA57687; Wed, 28 Jul 1999 09:30:58 +0200 (CEST) (envelope-from des) To: Tim Vanderhoek Cc: Dag-Erling Smorgrav , hackers@freebsd.org Subject: Re: replacing grep(1) References: <19990727082344.B33399@mad> Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 28 Jul 1999 09:30:58 +0200 In-Reply-To: Tim Vanderhoek's message of "Tue, 27 Jul 1999 08:23:44 -0400" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Vanderhoek writes: > Have you run your systems with J-grep as a replacement for GNU grep > for a while (making sure nothing breaks)? Yes. > There seems to be at least one dependency on GNU grep in > /ports/Mk/bsd.port.mk where the -F argument is used. -F is implemented. DES -- Dag-Erling Smorgrav - des@yes.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 28 1:34: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id F07681510C for ; Wed, 28 Jul 1999 01:33:18 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id LAA26557 for hackers@freebsd.org; Wed, 28 Jul 1999 11:34:04 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id LAA01609 for hackers@freebsd.org; Wed, 28 Jul 1999 11:27:04 +0400 (MSD) Message-Id: <199907280727.LAA01609@scorpion.crimea.ua> Subject: /usr/share/man/man?/{i386|alpha} To: hackers@freebsd.org Date: Wed, 28 Jul 1999 11:27:03 +0400 (MSD) From: "Alexey M. Zelkin" X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello ! I am interesting about idea of directories man?/{i386|alpha}. By their names I can understand that they are directories there platform specific man pages for certain man section will be stored. As I see there are only hard-linked manpages in man?/i386 directories. But it's interesting -- will these directories be used in future for storing unique (not hard-linked with other man pages) man pages ? If so, then I can add some patches for makewhatis(1)/catman(1) while I am working with internationalization support for this stuff. PS: Yes, these utilities not contain functionality to understand subdirectories in man directories. -- Sincerely Yours, | phantom@crimea.edu (primary) Alexey Zelkin | phantom@scorpion.crimea.ua (home) | ICQ: #6196584, FIDO: 2:460/12.26 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 1:38: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 94BA315450; Wed, 28 Jul 1999 01:38:05 -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 119PD6-0007o6-00; Wed, 28 Jul 1999 10:37:12 +0200 From: Sheldon Hearn To: obrien@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Tue, 27 Jul 1999 22:20:40 MST." <19990727222040.E5283@nuxi.com> Date: Wed, 28 Jul 1999 10:37:12 +0200 Message-ID: <30013.933151032@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > My advice would be to submit his PR to Chris Demtrito(sp?), file's > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Hmmm. So file(1) is a contrib candidate? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 2: 9:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id ABE2415434 for ; Wed, 28 Jul 1999 02:09:32 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id EAA07996 for hackers@freebsd.org; Wed, 28 Jul 1999 04:08:48 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907280908.EAA07996@celery.dragondata.com> Subject: Replace/rewrite reverse.c for tail(1) To: hackers@freebsd.org Date: Wed, 28 Jul 1999 04:08:48 -0500 (CDT) 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 An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 4: 4:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dns0.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id D7D1514CB3; Wed, 28 Jul 1999 04:04:28 -0700 (PDT) (envelope-from ad@netbsd.org) Message-ID: <379EE37D.18EF245D@netbsd.org> Date: Wed, 28 Jul 1999 12:03:25 +0100 From: Andy Doran X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: Sheldon Hearn Cc: obrien@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo References: <30013.933151032@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote: > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > maintainer. Then import NetBSD's file (Chris is a NetBSD guy). You may want to verify this. I'm pretty sure that Christos Zoulas (another NetBSD guy) maintains file(1): christos@zoulas.com. - ad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 4: 8:16 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 EC1E714CCB; Wed, 28 Jul 1999 04:07:44 -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 119RWc-0009EV-00; Wed, 28 Jul 1999 13:05:30 +0200 From: Sheldon Hearn To: Andy Doran Cc: obrien@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Wed, 28 Jul 1999 12:03:25 +0100." <379EE37D.18EF245D@netbsd.org> Date: Wed, 28 Jul 1999 13:05:30 +0200 Message-ID: <35494.933159930@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote: > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): christos@zoulas.com. Confirmed. Other than the mistaken name, I think David obsoleted further discussion, since it really is the best approach. :-) Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 4:56: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10]) by hub.freebsd.org (Postfix) with ESMTP id 2DC9414F22 for ; Wed, 28 Jul 1999 04:55:12 -0700 (PDT) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.9.0/8.9.0) id NAA00418 for freebsd-hackers@freebsd.org; Wed, 28 Jul 1999 13:57:21 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199907281157.NAA00418@oskar.nanoteq.co.za> Subject: newaliases and 256 tun devices To: freebsd-hackers@freebsd.org Date: Wed, 28 Jul 1999 13:57:18 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ... I previously mailed the same error ... and then I thought it was a "miss-corrolation" between kernel sources and userland. Since then I built a SNAP of 990726 sources and tried the same thing and the error occured again . Same sources used for the compile of the kernel and userlevel binaries. I've now traced the following down ... it has something todo with the changes in net/if_dl.h (the entries added for source routing and the fact that my kernel has pseudo-device tun 255 in the config. Setup. PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards. When I do a "ifconfig fxp0 delete" and then a newaliases the newaliases exits with a segmentation failt. If I reconfig the device or up the device ... newaliases works ok. I then built a kernel with only 200 tun devices. Then newaliases works everytime. It seems that gated also suffers from the same problem in that if no device is configured it exits on signal 6 (core dumped) Just for reference this works fine on a 2.2.7/8 FreeBSD without any problems ... The problem seems to be in conf.c of sendmail round line 4429 if there is 255 tun devices the for loop below only gets to 234 +/- and then doesn't check anything further and crashes (but only if the working interface is deleted) gdb shows that the pointer *sa points to somewhere wonderful :) It must have something todo with the moving of this pointer through the list ??? Was anything changed for the amount of tun devices allowed ?? for (i = 0; i < ifc.ifc_len; ) { struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i]; SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr; struct in_addr ia; #ifdef SIOCGIFFLAGS struct ifreq ifrf; #endif char ip_addr[256]; extern char *inet_ntoa(); #ifdef BSD4_4_SOCKADDR if (sa->sa.sa_len > sizeof ifr->ifr_addr) i += sizeof ifr->ifr_name + sa->sa.sa_len; else #endif i += sizeof *ifr; if (tTd(0, 20)) printf("%s\n", anynet_ntoa(sa)); Thanx Reinier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 5:26: 9 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 7E20514BFE; Wed, 28 Jul 1999 05:26:00 -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 OAA72457; Wed, 28 Jul 1999 14:25:57 +0200 (CEST) (envelope-from des) To: "Brian F. Feldman" Cc: "Jordan K. Hubbard" , Rayson Ho , freebsd-hackers@FreeBSD.ORG Subject: Re: Free BSDI CD! References: From: Dag-Erling Smorgrav Date: 28 Jul 1999 14:25:57 +0200 In-Reply-To: "Brian F. Feldman"'s message of "Tue, 27 Jul 1999 17:59:43 -0400 (EDT)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" writes: > My point was that it's not a very important thing to do to give out > FreeBSD CDs like BSD/OS gives out trial versions of their wares. Yes, it is. Try doing an FTP install across a 28k8 or 33k6 modem some time. 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 28 5:29:43 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 5B75D14CD1 for ; Wed, 28 Jul 1999 05:29:39 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18411.on.bellglobal.com [206.172.130.91]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA02388; Wed, 28 Jul 1999 08:28:59 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id IAA01672; Wed, 28 Jul 1999 08:27:35 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 08:27:35 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: hackers@freebsd.org Subject: Re: replacing grep(1) Message-ID: <19990728082735.A1591@mad> References: <19990727082344.B33399@mad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Dag-Erling Smorgrav on Wed, Jul 28, 1999 at 03:30:58AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote: > > > There seems to be at least one dependency on GNU grep in > > /ports/Mk/bsd.port.mk where the -F argument is used. > > -F is implemented. I saw that, but had assumed the semantics were different. I should have read the read the manpages more closely: they're not. Sorry. -- 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 Wed Jul 28 5:42:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nic.mmc.net.ge (nic.mmc.net.ge [212.72.145.2]) by hub.freebsd.org (Postfix) with ESMTP id D7F1615472 for ; Wed, 28 Jul 1999 05:42:41 -0700 (PDT) (envelope-from dima@mmc.net.ge) Received: from mmc.net.ge (giovanni.mmc.net.ge [212.72.145.5]) by nic.mmc.net.ge (8.9.3/8.9.3) with ESMTP id RAA17655 for ; Wed, 28 Jul 1999 17:41:15 +0500 (GET) Message-ID: <379F089E.57DC7E59@mmc.net.ge> Date: Wed, 28 Jul 1999 17:41:50 +0400 From: Dima X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: /usr/src/sys/i386/boot/netboot problem during compile 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 a problem compiling of files needed for network boot on a FreeBSD 3.2-Release. As it was writen in handbook, I have to compile nb8390.com, nb3c509.com, nb8390.rom, nb3c509.rom files to perform boot over network. But during compile a I get the following error: /usr/src/sys/i386/boot/netboot > make Warning: Object directory not changed from original /usr/src/sys/i386/boot/netboot ln -s /usr/src/sys/i386/boot/netboot/../../include /usr/src/sys/i386/boot/netboot/machine cc -O2 -DNFS -DROMSIZE=16384 -DRELOC=0x90000 -DPCI -DPCI_VENDOR=0x10ec -DPCI_DEVICE=0x8029 -DPCI_CLASS=0x02,0x00,0x00 -DASK_BOOT -aout -I/usr/src/sys/i386/boot/ netboot/../../.. -I/usr/src/sys/i386/boot/netboot -DROMSIZE=16384 -static -o makerom /usr/src/sys/i386/boot/netboot/makerom.c ld: scrt0.o: No such file or directory *** Error code 1 as I understand I need this file (scrt0.o) because netboot makes *com files only from a.out files, not from ELF. In sources I found where is this file compiled - /usr/src/lib/csu. But it will only compile if I manually set flag FREEBSD_AOUT. And even after this, compiling netboot gives me: ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) *** Error code 1 Please write me what I am doing wrong, and how can I get this *.com and *.rom files neede for network boot????? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 6: 8:29 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 F1A161547C for ; Wed, 28 Jul 1999 06:08: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 PAA73390; Wed, 28 Jul 1999 15:06:41 +0200 (CEST) (envelope-from des) To: Andrew Gordon Cc: hackers@FreeBSD.ORG Subject: Re: Linear buffers in VESA screen modes References: From: Dag-Erling Smorgrav Date: 28 Jul 1999 15:06:41 +0200 In-Reply-To: Andrew Gordon's message of "Sun, 25 Jul 1999 00:41:52 +0100 (BST)" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Gordon writes: > The application for which I need this is to support capture from the bktr > driver onto the screen (ie. so that you can watch TV without X). With the > above hack and a small (100-line) program it works very nicely - far > tidier than installing X just for this purpose on some embedded systems > where I need this capability. Might one persuade you to release that 100-line program? :) 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 28 6:52:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from c2-5-dbn.dial-up.net (c2-5-dbn.dial-up.net [196.34.155.133]) by hub.freebsd.org (Postfix) with ESMTP id D790814C27 for ; Wed, 28 Jul 1999 06:52:17 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by c2-5-dbn.dial-up.net (8.8.7/8.6.12) id PAA15372; Wed, 28 Jul 1999 15:49:59 +0200 (SAST) From: Robert Nordier Message-Id: <199907281349.PAA15372@c2-5-dbn.dial-up.net> Subject: Re: /usr/src/sys/i386/boot/netboot problem during compile In-Reply-To: <379F089E.57DC7E59@mmc.net.ge> from Dima at "Jul 28, 1999 05:41:50 pm" To: dima@mmc.net.ge (Dima) Date: Wed, 28 Jul 1999 15:49:54 +0200 (SAST) 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 Dima wrote: > I have a problem compiling of files needed for network boot on a FreeBSD > 3.2-Release. > as I understand I need this file (scrt0.o) because netboot makes *com > files only from a.out files, not from ELF. In sources I found where is > this file compiled - /usr/src/lib/csu. But it will only compile if I > manually set flag FREEBSD_AOUT. And even after this, compiling netboot > gives me: > ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) > *** Error code 1 > > Please write me what I am doing wrong, and how can I get this *.com and > *.rom files neede for network boot????? This is legacy code which is being kept around until loader(8) supports equivalent functionality. For now, I suggest you use "etherboot" in the ports collection. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 7: 5: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from prontomail9.prontomail.com (prontomail9.prontomail.com [209.185.149.109]) by hub.freebsd.org (Postfix) with ESMTP id E65A014F25 for ; Wed, 28 Jul 1999 07:04:55 -0700 (PDT) (envelope-from avi@imail.ru) Received: from avi (209.185.149.237) by prontomail9.prontomail.com (NPlex 2.0.123) for hackers@freebsd.org; Wed, 28 Jul 1999 07:00:03 -0700 From: "Andrei Iltchenko" Message-Id: <199907280700213@avi.imail.ru> Date: Wed, 28 Jul 1999 18:06:47 +0400 X-Priority: Normal Content-Type: text/plain; charset=koi8-r To: hackers@freebsd.org Subject: POSIX threads question X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG HI everybody. I'm having a problem writing a multi-threaded application. As I understand from the mans, calls to read and write are synchronized through file-locks. Having looked through the source for libc_r I noticed that calls to printf and fprintf are also synchronized. The question is - why I am still having a problem calling fprintf(stderr, ... from multiple threads, the output is simply not written until I make a socond or a third call to fprintf. I have disabled buffering for stderr with setvbuf. Thank you in advance. ------------------------------------------- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:14:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 0F53E14D85; Wed, 28 Jul 1999 08:14:21 -0700 (PDT) (envelope-from hvoers@anp.nl) Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by ns.anp.nl (8.9.1/8.9.1) with SMTP id RAA16166; Wed, 28 Jul 1999 17:11:36 +0200 Date: Wed, 28 Jul 1999 17:11:36 +0200 (cest) From: Henk van Oers To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero 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, 28 Jul 1999, Brian F. Feldman wrote: > > > If it will get ALL of you to give it a rest, how about: > > > per-rule logging limits > > > logging limit raising > > > logging limit resetting > > > Which would all NOT affect the statistics? Separate statistics/logging counters is fine, but i don't need per-rule limits, a global limit is ok --> sysctl -w for raising and ipfw zerolog (or reset) for resetting. And then ... securelevel == 3 I think it is better NOT to permit 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile faster to avoid DoS > > > > We need more input from people who use the code, to make sure they don't > > depend on the current 'features', or can live with changes to them. If you can keep the foot print small i can live with it. > > > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. Right! > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > I think this feature should DEFINITELY go in. I'm going to clean it up some > (ip_fw.c itself), and then make a set of diffs for this feature. > Nice? :) Nice? Depends on the diffs AND the man page ;-) Henk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:18:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id AFF5614D85 for ; Wed, 28 Jul 1999 08:18:39 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id QAA01800; Wed, 28 Jul 1999 16:17:59 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id QAA03664; Wed, 28 Jul 1999 16:18:33 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199907281518.QAA03664@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Reinier Bezuidenhout Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: newaliases and 256 tun devices In-reply-to: Your message of "Sat, 28 Jul 1999 13:57:18 +0200." <199907281157.NAA00418@oskar.nanoteq.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jul 1999 16:18:33 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If it's of any use, I have 300 tun devices in my home development machine and have no problems with sendmail, but I have a tulip card (de) rather than an Intel and haven't every ``ifconfig delete''d it. > Hi ... > > > I previously mailed the same error ... and then I thought > it was a "miss-corrolation" between kernel sources and > userland. Since then I built a SNAP of 990726 sources > and tried the same thing and the error occured again . > > Same sources used for the compile of the kernel and userlevel > binaries. > > I've now traced the following down ... it has something todo > with the changes in net/if_dl.h (the entries added for > source routing and the fact that my kernel has > pseudo-device tun 255 > in the config. > > Setup. > PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards. > > When I do a "ifconfig fxp0 delete" and then a newaliases > the newaliases exits with a segmentation failt. > If I reconfig the device or up the device ... newaliases works > ok. > > I then built a kernel with only 200 tun devices. Then newaliases > works everytime. It seems that gated also suffers from the same > problem in that if no device is configured it exits on signal 6 > (core dumped) > > Just for reference this works fine on a 2.2.7/8 FreeBSD without > any problems ... > > The problem seems to be in conf.c of sendmail round line 4429 > if there is 255 tun devices the for loop below only gets to > 234 +/- and then doesn't check anything further and crashes > (but only if the working interface is deleted) > gdb shows that the pointer *sa points to somewhere wonderful :) > It must have something todo with the moving of this pointer > through the list ??? > > Was anything changed for the amount of tun devices allowed ?? > > for (i = 0; i < ifc.ifc_len; ) > { > struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i]; > SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr; > struct in_addr ia; > #ifdef SIOCGIFFLAGS > struct ifreq ifrf; > #endif > char ip_addr[256]; > extern char *inet_ntoa(); > > #ifdef BSD4_4_SOCKADDR > if (sa->sa.sa_len > sizeof ifr->ifr_addr) > i += sizeof ifr->ifr_name + sa->sa.sa_len; > else > #endif > i += sizeof *ifr; > > if (tTd(0, 20)) > printf("%s\n", anynet_ntoa(sa)); > > > > Thanx > Reinier -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:19:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FBBF14FDA; Wed, 28 Jul 1999 08:19:54 -0700 (PDT) (envelope-from hvoers@anp.nl) Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by ns.anp.nl (8.9.1/8.9.1) with SMTP id RAA19051; Wed, 28 Jul 1999 17:16:04 +0200 Date: Wed, 28 Jul 1999 17:16:04 +0200 (cest) From: Henk van Oers To: Julian Elischer Cc: Joe Greco , Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero 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, 27 Jul 1999, Julian Elischer wrote: > a system wide limit and each rule's logging counter individually resetable > back to 0. > > So, what's your vote? > > ... Joe I vote for this too. Henk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:27:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id A1E2B15480 for ; Wed, 28 Jul 1999 08:27:37 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Jul 1999 09:27:34 -0600 Message-ID: <64003B21ECCAD11185C500805F31EC030378660F@houston.matchlogic.com> From: Charles Randall To: hackers@freebsd.org Cc: Kevin Day Subject: RE: Replace/rewrite reverse.c for tail(1) Date: Wed, 28 Jul 1999 09:27:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd suggest that you use "tac" from GNU textutils. Charles -----Original Message----- From: Kevin Day [mailto:toasty@dragondata.com] Sent: Wednesday, July 28, 1999 3:09 AM To: hackers@freebsd.org Subject: Replace/rewrite reverse.c for tail(1) An application I use quite often requires me to reverse the lines in the file to get the desired output. 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's the entire file in, which encourages the kernel to swap out the rest of the system to keep pages of the input file in memory. 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail Out of 128M of ram, it's swapped nearly everything else out to keep 85M of this 400M file in ram, even though it will never touch it again. :) I see two possible fixes for this. One could be madvise'ing periodically with MADV_DONTNEED. If I understand correctly, this would help a bit, right? Or, mmap smaller regions of the file, and keep moving the buffer. This would also help with files exceeding mmap's limits. Any thoughts? Kevin 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 28 8:36:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from exchange1.autotote.com (exchange1.autotote.com [209.118.1.225]) by hub.freebsd.org (Postfix) with ESMTP id 2377114DFD for ; Wed, 28 Jul 1999 08:36:13 -0700 (PDT) (envelope-from tom@wact.net) Received: from wact.net (IPROXY [209.118.1.227]) by exchange1.autotote.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P1AZ09LZ; Wed, 28 Jul 1999 11:17:51 -0400 Message-ID: <379F1F72.1BB1565B@wact.net> Date: Wed, 28 Jul 1999 11:19:14 -0400 From: Tom Uffner Reply-To: tom@wact.net X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Krzysztof Krawczyk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Pasting data between terminals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Krzysztof Krawczyk wrote: > When I do: > echo "blah blah" >>/dev/ttyp1 > text "blah blah" appear in virtual terminal ttyp1, but only as a text of > "message". I need ttyp1 count those datas as a "command typed by hand", > not just a text displayed in this term as info. I must transport lots of > data between these terminals. Have you any ideas? have you tried using a pseudo-terminal? see pty(4) -- Tom Uffner tom@wact.net Themes were useless! Destiny was here and the foot pedals were bleeding! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:39:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 4AAED15521; Wed, 28 Jul 1999 08:39:34 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA01528; Wed, 28 Jul 1999 09:38:21 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA01258; Wed, 28 Jul 1999 09:38:20 -0600 Date: Wed, 28 Jul 1999 09:38:20 -0600 Message-Id: <199907281538.JAA01258@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Henk van Oers Cc: "Brian F. Feldman" , Nate Williams , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And then ... securelevel == 3 I think it is better NOT to permit > 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile > faster to avoid DoS The real issue we are dealing with is what happens at securelevel == 3. What you are saying is that people shouldn't be allowed to modify *anything* at securelevel == 3, correct? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:40:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BAB00154D0; Wed, 28 Jul 1999 08:40:48 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA01548; Wed, 28 Jul 1999 09:39:45 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA01265; Wed, 28 Jul 1999 09:39:44 -0600 Date: Wed, 28 Jul 1999 09:39:44 -0600 Message-Id: <199907281539.JAA01265@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907280449.WAA29417@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > Nice? :) Depends on how it effects the speed of the system and if it makes the code too complex. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 8:41:57 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 42A43154B4; Wed, 28 Jul 1999 08:41:45 -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 JAA70348; Wed, 28 Jul 1999 09:41:26 -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 JAA70689; Wed, 28 Jul 1999 09:42:51 -0600 (MDT) Message-Id: <199907281542.JAA70689@harmony.village.org> To: obrien@FreeBSD.ORG Subject: Re: replacing grep(1) Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Jul 1999 21:44:51 PDT." <19990727214451.A66970@dragon.nuxi.com> References: <19990727214451.A66970@dragon.nuxi.com> Date: Wed, 28 Jul 1999 09:42:51 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990727214451.A66970@dragon.nuxi.com> "David O'Brien" writes: : Before importing, it must display a version number of 1.0 (or drop the : version number). This is not Linux where everything is version 0.xy. For a long time the new boot loader was in the tree with a version 0.xx... 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 28 9:53:41 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 14E4D14D70 for ; Wed, 28 Jul 1999 09:53:34 -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 119Wx0-0009yI-00 for hackers@freebsd.org; Wed, 28 Jul 1999 18:53:06 +0200 From: Sheldon Hearn To: hackers@freebsd.org Subject: Re: bin/12852: Non-standard behavior of fread(3) Date: Wed, 28 Jul 1999 18:53:06 +0200 Message-ID: <38333.933180786@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Could someone have a look at the patch proposed on PR 12852? I understand the motivation, since it seems reasonable to me that ferror() should return EBADF after an attempt to read from stdout. At the moment, ferror() returns 0 after an attempt to read from stdout. Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 9:57:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9F42614E8E for ; Wed, 28 Jul 1999 09:57:10 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-71.ucdavis.edu [169.237.16.71]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id JAA07885 for ; Wed, 28 Jul 1999 09:55:27 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA64286 for hackers@FreeBSD.ORG; Wed, 28 Jul 1999 09:55:25 -0700 (PDT) (envelope-from obrien) Date: Wed, 28 Jul 1999 09:55:24 -0700 From: "David O'Brien" To: hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo Message-ID: <19990728095524.K66569@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <30013.933151032@axl.noc.iafrica.com> <379EE37D.18EF245D@netbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <379EE37D.18EF245D@netbsd.org>; from Andy Doran on Wed, Jul 28, 1999 at 12:03:25PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): christos@zoulas.com. My major Duh!! If Christos sees this thread, my apologies. There is no excuse for me not checking the source to make sure I was accurate before opening my mouth. -- -- David (obrien@NUXI.com -or- obrien@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 28 10: 3:29 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 B608714D70 for ; Wed, 28 Jul 1999 10:03:26 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA26170; Thu, 29 Jul 1999 02:03:01 +0900 (JST) Message-ID: <379F3701.F79E10DF@newsguy.com> Date: Thu, 29 Jul 1999 01:59:45 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: James Howard Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) 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 James Howard wrote: > > Due to the discussion of speed, I have been looking at it and it is really > slow. Even slower than I thought and I was thinking it was pretty slow. > > So using gprof, I have discovered that it seems to spend a whole mess of > time in grep_malloc() and free(). So I pulled all the references to > malloc inside the main loop (the copy for ln.dat and removed queueing). > This stills leaves us with a grep that is about ~6x slower than GNU. > Before that, it ran closer to 80x. After this, gprof says it spends > around 53% of its time in procline(). Sorry, but a simplistic analysis like that just won't cut for grep. The algorithmic complexity is highly relevant here. Try this: generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by concatenating that first file. Benchmark yours and GNU grep a number of times to get the average for each file. Now compare the *proportions* between the different sized files. Are they the same? Next, try different sized patterns on the 50 Mb file on both yours and GNU grep. Again, compare the proportion. Next, compare patterns with different number of "wildcards", patterns with things like [acegikmoqsuvxz] vs [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. Either that, or do a complexity analysis of the algorithms. :-) (In case anyone reading this discussion wants to know more about complexity of algorithms, I recommend Computer Algorithms, Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a 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 28 11: 3:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rothko.bestweb.net (rothko.bestweb.net [209.94.100.160]) by hub.freebsd.org (Postfix) with ESMTP id E9A4D14C3F for ; Wed, 28 Jul 1999 11:03:08 -0700 (PDT) (envelope-from mark@suarez.bestweb.net) Received: from kandinsky (kandinsky.bestweb.net [209.94.100.35]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id NAA12850 for ; Wed, 28 Jul 1999 13:39:53 -0400 (EDT) Message-ID: <012801bed920$99256c20$23645ed1@bestweb.net> Reply-To: "Mark Dickey" From: "Mark Dickey" To: References: <379F3701.F79E10DF@newsguy.com> Subject: Re: replacing grep(1) Date: Wed, 28 Jul 1999 13:42:43 -0400 Organization: BestWeb Corporation 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 I expect that there is a very good reason why this shouldn't be done, but could it be possible to implement two different algorithms/code dependant on the size of the file being grepped? Mark Dickey mark@bestweb.net Daniel C. Sobral wrote: > James Howard wrote: > > > > Due to the discussion of speed, I have been looking at it and it is really > > slow. Even slower than I thought and I was thinking it was pretty slow. > > > > So using gprof, I have discovered that it seems to spend a whole mess of > > time in grep_malloc() and free(). So I pulled all the references to > > malloc inside the main loop (the copy for ln.dat and removed queueing). > > This stills leaves us with a grep that is about ~6x slower than GNU. > > Before that, it ran closer to 80x. After this, gprof says it spends > > around 53% of its time in procline(). > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: > generate a 1 Mb file, and then generate 10 Mb and 50 Mb files by > concatenating that first file. Benchmark yours and GNU grep a number > of times to get the average for each file. Now compare the > *proportions* between the different sized files. Are they the same? > > Next, try different sized patterns on the 50 Mb file on both yours > and GNU grep. Again, compare the proportion. > > Next, compare patterns with different number of "wildcards", > patterns with things like [acegikmoqsuvxz] vs > [acegikmoqsuvxzACEGIKMOQSUVXZ], etc. > > Either that, or do a complexity analysis of the algorithms. :-) > > (In case anyone reading this discussion wants to know more about > complexity of algorithms, I recommend Computer Algorithms, > Introduction to Design and Analysis, by Sara Baase, Addison Wesley.) > > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > > "Is it true that you're a millionaire's son who never worked a day > in your life?" > "Yeah, I guess so." > "Lemme tell you, son, you ain't missed a thing." > > > > 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 28 11:14:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m2-2-dbn.dial-up.net (m2-2-dbn.dial-up.net [196.34.155.66]) by hub.freebsd.org (Postfix) with ESMTP id 6B5B914FD7 for ; Wed, 28 Jul 1999 11:14:40 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by m2-2-dbn.dial-up.net (8.8.7/8.6.12) id UAA17849; Wed, 28 Jul 1999 20:13:20 +0200 (SAST) From: Robert Nordier Message-Id: <199907281813.UAA17849@m2-2-dbn.dial-up.net> Subject: Re: bin/12852: Non-standard behavior of fread(3) In-Reply-To: <38333.933180786@axl.noc.iafrica.com> from Sheldon Hearn at "Jul 28, 1999 06:53:06 pm" To: sheldonh@uunet.co.za (Sheldon Hearn) Date: Wed, 28 Jul 1999 20:13:18 +0200 (SAST) Cc: 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 Sheldon Hearn wrote: > Could someone have a look at the patch proposed on PR 12852? I > understand the motivation, since it seems reasonable to me that ferror() > should return EBADF after an attempt to read from stdout. At the moment, > ferror() returns 0 after an attempt to read from stdout. There's no question this needs changing. An ISO example actually reads along the lines of: while (!feof(fp) && !ferror(fp)) fscanf(fp, ...); with no further provision for error-detection. Applied to stdout, this never terminates. The SVID wording is more definite than ISO in discussing this ("less than nitems only if a read error or end-of-file is encountered"), but mostly the present behavior just conflicts with sense and practice. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 11:51:24 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 DFF781510C for ; Wed, 28 Jul 1999 11:51:16 -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 OAA92072; Wed, 28 Jul 1999 14:51:10 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 14:51:10 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Dag-Erling Smorgrav Cc: "Jordan K. Hubbard" , Rayson Ho , freebsd-hackers@FreeBSD.org Subject: Re: Free BSDI CD! 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 28 Jul 1999, Dag-Erling Smorgrav wrote: > "Brian F. Feldman" writes: > > My point was that it's not a very important thing to do to give out > > FreeBSD CDs like BSD/OS gives out trial versions of their wares. > > Yes, it is. Try doing an FTP install across a 28k8 or 33k6 modem some > time. Those are the only times I have. It's much faster than, say, downloading an NT service pack and hotfixes, or "windos updating", if that's who we're supposed to be competing with in the server market. > > 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 > 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 28 12:14:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 404C414CF3; Wed, 28 Jul 1999 12:14:42 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA11893; Wed, 28 Jul 1999 12:12:29 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 28 Jul 1999 12:12:28 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero 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, 27 Jul 1999, Brian F. Feldman wrote: > If it will get ALL of you to give it a rest, how about: > per-rule logging limits This has been needed for some time now. Also, please don't forget the oft-repeated request to have seperate accounting and logging counters so that you can zero one, but not the other. > logging limit raising > logging limit resetting I'd say that these are good knobs to have (I assume you're talking sysctl's?) but I'd also like to suggest a knob that allows you to toggle whether these can be changed at securelevel > 1, which knob is not resettable at securelevel > 1. I think that this would answer the needs of all parties concerned. > Which would all NOT affect the statistics? Oh good, you didn't forget. :) > I am, yes, suggesting I will implement it. Coolio. And inre the request to hear from the users of the code, I am one, have been for years, and deploy it in many different environments (including natd, basic security, etc.). These would be very welcome additions assuming that the performance hit is negligible. Thanks, 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 Wed Jul 28 12:35: 1 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 8E1181556B; Wed, 28 Jul 1999 12:34: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 PAA92882; Wed, 28 Jul 1999 15:33:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 15:33:34 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907281539.JAA01265@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > > Implementing it is the easy part, making sure it's the right thing to do > > > is the hard part. > > > > Well, the easy part is done, except for raising limits. Look: > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > ipfw: Entry 1 logging count reset. > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > > > Nice? :) > > Depends on how it effects the speed of the system and if it makes the > code too complex. :) None and no. > > > Nate > 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 28 12:38:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 08E9114FEE; Wed, 28 Jul 1999 12:38:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA04448; Wed, 28 Jul 1999 13:37:18 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA02547; Wed, 28 Jul 1999 13:37:17 -0600 Date: Wed, 28 Jul 1999 13:37:17 -0600 Message-Id: <199907281937.NAA02547@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907281539.JAA01265@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Implementing it is the easy part, making sure it's the right thing to do > > > > is the hard part. > > > > > > Well, the easy part is done, except for raising limits. Look: > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > ipfw: Entry 1 logging count reset. > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > > > > Nice? :) > > > > Depends on how it effects the speed of the system and if it makes the > > code too complex. :) > > None and no. Beauty is in the eye of the beholder. Let's suspend judgement on it until we actually get a chance to review it, pride in your work not withstanding. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 12:47:18 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 B2396153FF for ; Wed, 28 Jul 1999 12:47:04 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (homer.louisville.edu [136.165.1.20]) by unix1.it-datacntr.louisville.edu (8.8.8/8.8.7) with ESMTP id PAA07746 for ; Wed, 28 Jul 1999 15:46:55 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id PAA27532 for freebsd-hackers@freebsd.org; Wed, 28 Jul 1999 15:46:54 -0400 (EDT) Message-ID: <19990728154654.A26747@homer.louisville.edu> Date: Wed, 28 Jul 1999 15:46:54 -0400 From: Keith Stevenson To: freebsd-hackers@freebsd.org Subject: Was someone looking for a BSD licensed stat(1)? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I hacked this together last night. The only GNU code I looked at was the Linux stat(1u) man page. (A man page is forthcoming, especially if there is some interest in using this implementation.) The code is also available at http://www.kagekaze.org/stat.c 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 /* stat.c: Human readable interface to stat(2) system call */ /*- * Copyright (c) 1999 Keith Stevenson * 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. * * $Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $ */ #ifndef lint static const char copyright[] = "Copyright (c) 1999\nKeith Stevenson. All rights reserved.\n"; static const char rcsid[] = "$Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $"; #endif /* not lint */ #include #include #include #include #include #include #include #include #include /* stat: Display the contents of an inode in a human friendly format. */ int main(int argc, char *argv[]) { char ftype[20]; char fmode[11]; int count; struct group *gp; struct passwd *pw; struct stat inode; struct tm *atime, *mtime, *ctime; for (count = 1; count < argc; count++) { if (lstat(argv[count], &inode) != -1) { /* Initialize */ memset(fmode, '-', sizeof(fmode)); fmode[10] = '\0'; /* Interpret file type */ switch (inode.st_mode & S_IFMT) { case S_IFIFO: strncpy(ftype, "FIFO", sizeof(ftype)); fmode[0] = 'p'; break; case S_IFCHR: strncpy(ftype, "Character Special", sizeof(ftype)); fmode[0] = 'c'; break; case S_IFDIR: strncpy(ftype, "Directory", sizeof(ftype)); fmode[0] = 'd'; break; case S_IFBLK: strncpy(ftype, "Block Special", sizeof(ftype)); fmode[0] = 'b'; break; case S_IFREG: strncpy(ftype, "Regular", sizeof(ftype)); break; case S_IFLNK: strncpy(ftype, "Symbolic Link", sizeof(ftype)); fmode[0] = 'l'; break; case S_IFSOCK: strncpy(ftype, "Socket", sizeof(ftype)); fmode[0] = 's'; break; case S_IFWHT: strncpy(ftype, "Whiteout", sizeof(ftype)); fmode[0] = '?'; break; default: strncpy(ftype, "Unknown", sizeof(ftype)); fmode[0] = '?'; break; } /* Interpret file mode */ if (inode.st_mode & S_IRUSR) fmode[1] = 'r'; if (inode.st_mode & S_IWUSR) fmode[2] = 'w'; if (inode.st_mode & S_IXUSR) fmode[3] = 'x'; if (inode.st_mode & S_ISUID) { if (inode.st_mode & S_IXUSR) fmode[3] = 's'; else fmode[3] = 'S'; } if (inode.st_mode & S_IRGRP) fmode[4] = 'r'; if (inode.st_mode & S_IWGRP) fmode[5] = 'w'; if (inode.st_mode & S_IXGRP) fmode[6] = 'x'; if (inode.st_mode & S_ISGID) { if (inode.st_mode & S_IXGRP) fmode[6] = 's'; else fmode[6] = 'S'; } if (inode.st_mode & S_IROTH) fmode[7] = 'r'; if (inode.st_mode & S_IWOTH) fmode[8] = 'w'; if (inode.st_mode & S_IXOTH) fmode[9] = 'x'; if (inode.st_mode & S_ISVTX) { if (inode.st_mode & S_IXOTH) fmode[9] = 't'; else fmode[9] = 'T'; } /* Get ownerships and times */ pw = getpwuid(inode.st_uid); gp = getgrgid(inode.st_gid); atime = localtime(&inode.st_atime); mtime = localtime(&inode.st_mtime); ctime = localtime(&inode.st_ctime); /* Pretty print it*/ printf("File: \"%s\"\n", argv[count]); printf("Size: %qu\t", inode.st_size); printf("Allocated Blocks: %qd\t", inode.st_blocks); printf("Filetype: %s\n", ftype); printf("Mode: (%.4o/%s)\t", (inode.st_mode & 07777), fmode); if (pw != NULL) printf("Uid: (%hu/%s)\t", inode.st_uid, pw->pw_name); else printf("Uid: (%hu/%hu)\t", inode.st_uid, inode.st_uid); if (gp != NULL) printf("Gid: (%hu/%s)\n", inode.st_gid, gp->gr_name); else printf("Gid: (%hu/%hu)\n", inode.st_gid, inode.st_gid); printf("Device: %u\t", inode.st_dev); printf("Inode: %u\t", inode.st_ino); printf("Links: %hu\n", inode.st_nlink); printf("Access: %s", asctime(atime)); printf("Modify: %s", asctime(mtime)); printf("Change: %s\n", asctime(ctime)); } else { switch(errno) { case ENOTDIR: case ENAMETOOLONG: case ELOOP: fprintf(stderr, "Invalid file name specified.\n"); exit(EX_SOFTWARE); break; case ENOENT: fprintf(stderr, "File not found.\n"); exit(EX_SOFTWARE); break; case EACCES: fprintf(stderr, "Permission denied.\n"); exit(EX_NOPERM); break; case EFAULT: fprintf(stderr, "Can't stat file.\n"); exit(EX_SOFTWARE); break; case EIO: fprintf(stderr, "Can't stat file.\n"); exit(EX_OSERR); break; default: fprintf(stderr, "Can't stat file.\n"); exit(EX_SOFTWARE); break; } /* Not Reached */ exit(EX_SOFTWARE); } } exit(EX_OK); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 12:57:30 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 B05D015033; Wed, 28 Jul 1999 12:57: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 PAA93305; Wed, 28 Jul 1999 15:54:55 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 15:54:55 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907281937.NAA02547@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When someone will do that, it will be Ready :) But I've attached it! Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ Index: src/sbin/ipfw/ipfw.8 =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v retrieving revision 1.54 diff -u -r1.54 ipfw.8 --- ipfw.8 1999/06/19 18:43:18 1.54 +++ ipfw.8 1999/07/28 19:35:31 @@ -50,6 +50,7 @@ .Op Ar number .Ar action .Op log +.Op Ar logamount Ar number .Ar proto from .Ar src Index: src/sbin/ipfw/ipfw.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.c,v retrieving revision 1.71 diff -u -r1.71 ipfw.c --- ipfw.c 1999/06/19 18:43:15 1.71 +++ ipfw.c 1999/07/28 06:15:08 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -247,8 +248,11 @@ errx(EX_OSERR, "impossible"); } - if (chain->fw_flg & IP_FW_F_PRN) + if (chain->fw_flg & IP_FW_F_PRN) { printf(" log"); + if (chain->fw_logamount) + printf(" logamount %d", chain->fw_logamount); + } pe = getprotobynumber(chain->fw_prot); if (pe) @@ -599,12 +603,13 @@ " [pipe] list [number ...]\n" " [pipe] show [number ...]\n" " zero [number ...]\n" +" resetlog [number ...]\n" " pipe number config [pipeconfig]\n" " rule: action proto src dst extras...\n" " action:\n" " {allow|permit|accept|pass|deny|drop|reject|unreach code|\n" " reset|count|skipto num|divert port|tee port|fwd ip|\n" -" pipe num} [log]\n" +" pipe num} [log [logamount count]]\n" " proto: {ip|tcp|udp|icmp|}\n" " src: from [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" " dst: to [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" @@ -1164,6 +1169,18 @@ if (ac && !strncmp(*av,"log",strlen(*av))) { rule.fw_flg |= IP_FW_F_PRN; av++; ac--; } + if (ac && !strncmp(*av,"logamount",strlen(*av))) { + if (!(rule.fw_flg & IP_FW_F_PRN)) + show_usage("``logamount'' not valid without ``log''"); + ac--; av++; + if (!ac) + show_usage("``logamount'' requires argument"); + rule.fw_logamount = atoi(*av); + if (rule.fw_logamount <= 0) + show_usage("``logamount'' argument must be greater " + "than 0"); + ac--; av++; + } /* protocol */ if (ac == 0) @@ -1385,7 +1402,18 @@ if (rule.fw_nports) show_usage("can't mix 'frag' and port specifications"); } - + if (rule.fw_flg & IP_FW_F_PRN) { + if (!rule.fw_logamount) { + size_t len = sizeof(int); + + if (sysctlbyname("net.inet.ip.fw.verbose_limit", + &rule.fw_logamount, &len, NULL, 0) == -1) + errx(1, "sysctlbyname(\"%s\")", + "net.inet.ip.fw.verbose_limit"); + } + rule.fw_loghighest = rule.fw_logamount; + } + if (!do_quiet) show_ipfw(&rule, 10, 10); i = setsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule); @@ -1432,6 +1460,45 @@ } } +static void +resetlog (ac, av) + int ac; + char **av; +{ + av++; ac--; + + if (!ac) { + /* clear all entries */ + if (setsockopt(s,IPPROTO_IP,IP_FW_RESETLOG,NULL,0)<0) + err(EX_UNAVAILABLE, "setsockopt(%s)", "IP_FW_RESETLOG"); + if (!do_quiet) + printf("Logging counts reset.\n"); + } else { + struct ip_fw rule; + int failed = EX_OK; + + memset(&rule, 0, sizeof rule); + while (ac) { + /* Rule number */ + if (isdigit(**av)) { + rule.fw_number = atoi(*av); av++; ac--; + if (setsockopt(s, IPPROTO_IP, + IP_FW_RESETLOG, &rule, sizeof rule)) { + warn("rule %u: setsockopt(%s)", rule.fw_number, + "IP_FW_RESETLOG"); + failed = EX_UNAVAILABLE; + } + else if (!do_quiet) + printf("Entry %d logging count reset\n", + rule.fw_number); + } else + show_usage("invalid rule number ``%s''", *av); + } + if (failed != EX_OK) + exit(failed); + } +} + static int ipfw_main(ac,av) int ac; @@ -1527,6 +1594,8 @@ } } else if (!strncmp(*av, "zero", strlen(*av))) { zero(ac,av); + } else if (!strncmp(*av, "resetlog", strlen(*av))) { + resetlog(ac,av); } else if (!strncmp(*av, "print", strlen(*av))) { list(--ac,++av); } else if (!strncmp(*av, "list", strlen(*av))) { Index: src/sys/netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.114 diff -u -r1.114 ip_fw.c --- ip_fw.c 1999/06/19 18:43:28 1.114 +++ ip_fw.c 1999/07/28 06:29:07 @@ -106,6 +106,7 @@ static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); static int zero_entry __P((struct ip_fw *)); +static int resetlog_entry __P((struct ip_fw *)); static int check_ipfw_struct __P((struct ip_fw *m)); static __inline int iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, @@ -184,8 +185,8 @@ /* check for matching type in the bitmap */ if (type < IP_FW_ICMPTYPES_MAX && - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & - (1U << (type % (8 * sizeof(unsigned)))))) + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & + (1U << (type % (sizeof(unsigned) * NBBY))))) return(1); return(0); /* no match */ @@ -302,14 +303,15 @@ struct ifnet *rif, struct ifnet *oif) { if (ip) { + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); static u_int64_t counter; - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); - int count; + u_int64_t count; count = f ? f->fw_pcnt : ++counter; - if (fw_verbose_limit != 0 && count > fw_verbose_limit) + if ((f == NULL && fw_verbose_limit != 0 && count > fw_verbose_limit) || + (f && f->fw_logamount != 0 && count > f->fw_loghighest)) return; /* Print command name */ @@ -406,12 +408,13 @@ printf(" out via %s%d", oif->if_name, oif->if_unit); else if (rif) printf(" in via %s%d", rif->if_name, rif->if_unit); - if ((ip->ip_off & IP_OFFMASK)) - printf(" Fragment = %d",ip->ip_off & IP_OFFMASK); + if (ip->ip_off & IP_OFFMASK) + printf(" Fragment = %d", ip->ip_off & IP_OFFMASK); printf("\n"); - if (fw_verbose_limit != 0 && count == fw_verbose_limit) - printf("ipfw: limit reached on rule #%d\n", - f ? f->fw_number : -1); + if ((f ? f->fw_logamount != 0 : 1) && + count == (f ? f->fw_loghighest : fw_verbose_limit)) + printf("ipfw: limit %d reached on rule #%d\n", + f ? f->fw_logamount : fw_verbose_limit, f ? f->fw_number : -1); } } @@ -1108,6 +1111,55 @@ } static int +resetlog_entry(struct ip_fw *frwl) +{ + struct ip_fw_chain *fcp; + int s, cleared; + + if (frwl == 0) { + s = splnet(); + for (fcp = LIST_FIRST(&ip_fw_chain); fcp; fcp = LIST_NEXT(fcp, chain)) + fcp->rule->fw_loghighest = fcp->rule->fw_pcnt + + fcp->rule->fw_logamount; + splx(s); + } + else { + cleared = 0; + + /* + * It's possible to insert multiple chain entries with the + * same number, so we don't stop after finding the first + * match if zeroing a specific entry. + */ + for (fcp = LIST_FIRST(&ip_fw_chain); fcp; fcp = LIST_NEXT(fcp, chain)) + if (frwl->fw_number == fcp->rule->fw_number) { + s = splnet(); + while (fcp && frwl->fw_number == fcp->rule->fw_number) { + fcp->rule->fw_loghighest = + fcp->rule->fw_pcnt + + fcp->rule->fw_logamount; + fcp = LIST_NEXT(fcp, chain); + } + splx(s); + cleared = 1; + break; + } + if (!cleared) /* we didn't find any matching rules */ + return (EINVAL); + } + + if (fw_verbose) { + if (frwl) + printf("ipfw: Entry %d logging count reset.\n", + frwl->fw_number); + else + printf("ipfw: All logging counts cleared.\n"); + } + + return (0); +} + +static int check_ipfw_struct(struct ip_fw *frwl) { /* Check for invalid flag bits */ @@ -1320,6 +1372,17 @@ } break; + case IP_FW_RESETLOG: + if (sopt->sopt_val != 0) { + error = sooptcopyin(sopt, &frwl, sizeof frwl, + sizeof frwl); + if (error || (error = resetlog_entry(&frwl))) + break; + } else { + error = resetlog_entry(0); + } + break; + default: printf("ip_fw_ctl invalid option %d\n", sopt->sopt_name); error = EINVAL ; @@ -1373,7 +1436,7 @@ if (fw_verbose_limit == 0) printf("unlimited logging\n"); else - printf("logging limited to %d packets/entry\n", + printf("logging limited to %d packets/entry by default\n", fw_verbose_limit); #endif } Index: src/sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.38 diff -u -r1.38 ip_fw.h --- ip_fw.h 1999/06/19 18:43:30 1.38 +++ ip_fw.h 1999/07/28 05:08:07 @@ -75,14 +75,18 @@ struct sockaddr_in fu_fwd_ip; } fw_un; u_char fw_prot; /* IP protocol */ - u_char fw_nports; /* N'of src ports and # of dst ports */ - /* in ports array (dst ports follow */ - /* src ports; max of 10 ports in all; */ - /* count of 0 means match all ports) */ - void *pipe_ptr; /* Pipe ptr in case of dummynet pipe */ - void *next_rule_ptr ; /* next rule in case of match */ + u_char fw_nports; /* + * N'of src ports and # of dst ports + * in ports array (dst ports follow + * src ports; max of 10 ports in all; + * count of 0 means match all ports) + */ + void *pipe_ptr; /* pipe ptr in case of dummynet pipe */ + void *next_rule_ptr; /* next rule in case of match */ uid_t fw_uid; /* uid to match */ gid_t fw_gid; /* gid to match */ + int fw_logamount; /* amount to log */ + u_int64_t fw_loghighest; /* highest number packet to log */ }; #define IP_FW_GETNSRCP(rule) ((rule)->fw_nports & 0x0f) Index: src/sys/netinet/in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.42 diff -u -r1.42 in.h --- in.h 1999/05/08 14:28:52 1.42 +++ in.h 1999/07/28 05:46:20 @@ -322,6 +322,7 @@ #define IP_FW_FLUSH 52 /* flush firewall rule chain */ #define IP_FW_ZERO 53 /* clear single/all firewall counter(s) */ #define IP_FW_GET 54 /* get entire firewall rule chain */ +#define IP_FW_RESETLOG 55 /* reset logging counters */ #define IP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */ #define IP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */ Index: src/sys/netinet/raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.59 diff -u -r1.59 raw_ip.c --- raw_ip.c 1999/05/03 23:57:30 1.59 +++ raw_ip.c 1999/07/28 06:07:59 @@ -293,6 +293,7 @@ case IP_FW_DEL: case IP_FW_FLUSH: case IP_FW_ZERO: + case IP_FW_RESETLOG: if (ip_fw_ctl_ptr == 0) error = ENOPROTOOPT; else To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13: 1:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 30F7415033; Wed, 28 Jul 1999 13:01:25 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA04762; Wed, 28 Jul 1999 14:00:07 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA02728; Wed, 28 Jul 1999 14:00:06 -0600 Date: Wed, 28 Jul 1999 14:00:06 -0600 Message-Id: <199907282000.OAA02728@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907281937.NAA02547@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Index: src/sys/netinet/ip_fw.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > retrieving revision 1.114 > diff -u -r1.114 ip_fw.c > --- ip_fw.c 1999/06/19 18:43:28 1.114 > +++ ip_fw.c 1999/07/28 06:29:07 > @@ -106,6 +106,7 @@ > static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); > static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); > static int zero_entry __P((struct ip_fw *)); > +static int resetlog_entry __P((struct ip_fw *)); > static int check_ipfw_struct __P((struct ip_fw *m)); > static __inline int > iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, > @@ -184,8 +185,8 @@ > > /* check for matching type in the bitmap */ > if (type < IP_FW_ICMPTYPES_MAX && > - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & > - (1U << (type % (8 * sizeof(unsigned)))))) > + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & > + (1U << (type % (sizeof(unsigned) * NBBY))))) > return(1); > > return(0); /* no match */ These are good bugfixes, and should be committed seperately. > @@ -302,14 +303,15 @@ > struct ifnet *rif, struct ifnet *oif) > { > if (ip) { > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > static u_int64_t counter; > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > - int count; > + u_int64_t count; These are mostly change for changes sake, and make it difficult to see the functional changes. Please limit your changes to changes, and not just to add stylistic differences. While I may agree with them, they detract from the review process. [ Rest deleted ] Can you resend them to me in private email after you remove the white-space/stylistic changes? Thanks! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13: 1:57 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 1C7AA153FA for ; Wed, 28 Jul 1999 13:01:54 -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 QAA93458; Wed, 28 Jul 1999 16:01:10 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:01:10 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Keith Stevenson Cc: freebsd-hackers@FreeBSD.org Subject: Re: Was someone looking for a BSD licensed stat(1)? In-Reply-To: <19990728154654.A26747@homer.louisville.edu> 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 Since you've got it in RCS, you shouldn't have any problem adding new features. How about a selectable display of fields, and ability to put them in machine-readable (read: no cut required) form? I'd suggest having a function that would printf "%s: whatever", arg1 for humans and "whatever" for machines, selectable by something like a -c "compact output flag." Here's the GPLd stat I have: {"/usr"}# stat stat [-cihsv] [-o opts] [-f file] [filename ...] -h this help -v verbose output -c compact output -i ignore errors -s stop on error -f read filenames to be stat-ed from file (- means stdin) -d dereference symbolic links. -o opts output options (case insensitive): a access time c creation time d device g group i inode l links m mode n file name o modification time s size t type u owner 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 28 13: 4:44 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 2A43B153FF for ; Wed, 28 Jul 1999 13:04:39 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA66629 for ; Wed, 28 Jul 1999 20:56:08 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id RAA48822 for hackers@freebsd.org; Wed, 28 Jul 1999 17:01:20 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Wed, 28 Jul 1999 17:01:19 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: Documenting writev(2) ENOBUFS error Message-ID: <19990728170119.A47890@kilt.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, Could someone who knows write/writev(2) take a quick look at docs/10512. In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR) if you "exhaust writev'able buffer space". This doesn't mean a great deal to me, and I'm hoping one of you can take a look at come up with a phrasing suitable for a man page. 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 Wed Jul 28 13: 5:26 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 8A93F155C1 for ; Wed, 28 Jul 1999 13:05:16 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA66639 for ; Wed, 28 Jul 1999 20:56:10 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id PAA40456 for hackers@freebsd.org; Wed, 28 Jul 1999 15:38:12 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Wed, 28 Jul 1999 15:38:12 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: Including isa/isareg.h in sys/i386/boot/biosboot/serial.S Message-ID: <19990728153811.A39313@kilt.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, In the kernel config file you can use symbolic names for the various COM ports, IO_COM1, IO_COM2, and so on. These seem be defined in sys/isa/isareg.h. If you want to configure FreeBSD to boot from a serial console you have to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the defines here, you have to use 0x3F8, 0x2F8, and so on. As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down to sys/i386/boot/biosboot/serial.S. So, why not apply the following trivial patch to serial.S, so that /etc/make.conf can instead contain BOOT_COMCONSOLE_PORT= IO_COM2 which is just slightly friendlier? I'm not what you'd call a kernel hacker, so this might be a stupid idea. . . N Index: serial.S =================================================================== RCS file: /home/ncvs/src/sys/i386/boot/biosboot/serial.S,v retrieving revision 1.12 diff -u -1 -r1.12 serial.S --- serial.S 1999/04/22 21:02:44 1.12 +++ serial.S 1999/07/28 14:30:54 @@ -70,2 +70,3 @@ #include +#include #include "asm.h" -- [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 28 13: 6:56 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 BDB9E15420; Wed, 28 Jul 1999 13:05:54 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA66648; Wed, 28 Jul 1999 20:56:11 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id RAA52541; Wed, 28 Jul 1999 17:31:30 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Wed, 28 Jul 1999 17:31:30 +0100 From: Nik Clayton To: "David O'Brien" Cc: "Jordan K. Hubbard" , itojun@iijlab.net, hackers@FreeBSD.ORG Subject: Re: Will FreeBSD ever see native IPv6 ?? Message-ID: <19990728173129.A52425@kilt.nothing-going-on.org> References: <9128.932724101@coconut.itojun.org> <71662.932744033@zippy.cdrom.com> <19990727225808.H5283@nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990727225808.H5283@nuxi.com>; from David O'Brien on Tue, Jul 27, 1999 at 10:58:08PM -0700 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 27, 1999 at 10:58:08PM -0700, David O'Brien wrote: > Lets help these people out. How about adding this to 3.3's RELEASE notes > and a pointer from our website? (maybe also > http://www.freebsd.org/handbook/install.html) If you can give me text, I'll mark it up and add it. 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 28 13: 7:38 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 8EDCD15647; Wed, 28 Jul 1999 13:07:23 -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 QAA93553; Wed, 28 Jul 1999 16:05:53 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:05:53 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282000.OAA02728@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > Index: src/sys/netinet/ip_fw.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > > retrieving revision 1.114 > > diff -u -r1.114 ip_fw.c > > --- ip_fw.c 1999/06/19 18:43:28 1.114 > > +++ ip_fw.c 1999/07/28 06:29:07 > > @@ -106,6 +106,7 @@ > > static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); > > static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); > > static int zero_entry __P((struct ip_fw *)); > > +static int resetlog_entry __P((struct ip_fw *)); > > static int check_ipfw_struct __P((struct ip_fw *m)); > > static __inline int > > iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, > > @@ -184,8 +185,8 @@ > > > > /* check for matching type in the bitmap */ > > if (type < IP_FW_ICMPTYPES_MAX && > > - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & > > - (1U << (type % (8 * sizeof(unsigned)))))) > > + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & > > + (1U << (type % (sizeof(unsigned) * NBBY))))) > > return(1); > > > > return(0); /* no match */ > > These are good bugfixes, and should be committed seperately. Yes, this specific part shouldn't go in the same commit. > > > @@ -302,14 +303,15 @@ > > struct ifnet *rif, struct ifnet *oif) > > { > > if (ip) { > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > > static u_int64_t counter; > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > > - int count; > > + u_int64_t count; > > These are mostly change for changes sake, and make it difficult to see > the functional changes. Please limit your changes to changes, and not > just to add stylistic differences. While I may agree with them, they > detract from the review process. These were changes that were necessary to make ipfw readable enough that I could work with it in this area. They aren't just to clean it up, or just for change's sake. They need to stay in. > > [ Rest deleted ] > > Can you resend them to me in private email after you remove the > white-space/stylistic changes? Thanks! > > > > Nate > 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 28 13: 9:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 2A12D154B1; Wed, 28 Jul 1999 13:09:38 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA04881; Wed, 28 Jul 1999 14:08:50 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA02877; Wed, 28 Jul 1999 14:08:49 -0600 Date: Wed, 28 Jul 1999 14:08:49 -0600 Message-Id: <199907282008.OAA02877@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282000.OAA02728@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > @@ -302,14 +303,15 @@ > > > struct ifnet *rif, struct ifnet *oif) > > > { > > > if (ip) { > > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > > > static u_int64_t counter; > > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > > > - int count; > > > + u_int64_t count; > > > > These are mostly change for changes sake, and make it difficult to see > > the functional changes. Please limit your changes to changes, and not > > just to add stylistic differences. While I may agree with them, they > > detract from the review process. > > These were changes that were necessary to make ipfw readable enough that > I could work with it in this area. They aren't just to clean it up, or > just for change's sake. They need to stay in. C'mon now, re-ording the lines is *certainly* not necessary to work. *rant on* Brian, FreeBSD isn't your private playground for playing around, this is a group project, and you gotta follow the rules, or you don't get to play with the rest of the folks.... *rant off* Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:18: 8 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 0F474153FA; Wed, 28 Jul 1999 13:17:55 -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 QAA93827; Wed, 28 Jul 1999 16:17:57 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:17:57 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282008.OAA02877@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > I could work with it in this area. They aren't just to clean it up, or > > just for change's sake. They need to stay in. > > C'mon now, re-ording the lines is *certainly* not necessary to work. That's true. I sure didn't do that. > > *rant on* > Brian, FreeBSD isn't your private playground for playing around, this is > a group project, and you gotta follow the rules, or you don't get to > play with the rest of the folks.... The rules don't say "leave the code that you work with in a bigger mess than when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be done to get work done, very often. You have to learn to deal with that. > *rant off* > > > > > Nate > 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 28 13:24:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E6A7114D42; Wed, 28 Jul 1999 13:24:26 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05134; Wed, 28 Jul 1999 14:24:25 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03102; Wed, 28 Jul 1999 14:24:24 -0600 Date: Wed, 28 Jul 1999 14:24:24 -0600 Message-Id: <199907282024.OAA03102@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282008.OAA02877@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. Sure looks like you did. There are white-space and re-ordering modifications in the diffs you sent out. If you didn't do them, who did? > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. No, cleanups occur *separately* from code additions. The code is *very* readable now, and just because you have stylistic differences doesn't mean you get to change them because you like them. In particular, the changes I pointed out are not 'cleanups', but style changes. I repeat, this isn't your personal playground. Play by the rules or don't play at all. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:25: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from unix2.it-datacntr.louisville.edu (unix2.it-datacntr.louisville.edu [136.165.4.28]) by hub.freebsd.org (Postfix) with ESMTP id 7E3AA1544B; Wed, 28 Jul 1999 13:24:55 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (homer.louisville.edu [136.165.1.20]) by unix2.it-datacntr.louisville.edu (8.8.8/8.8.8) with ESMTP id QAA27140; Wed, 28 Jul 1999 16:23:57 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id QAA02269; Wed, 28 Jul 1999 16:24:36 -0400 (EDT) Message-ID: <19990728162436.D29649@homer.louisville.edu> Date: Wed, 28 Jul 1999 16:24:36 -0400 From: Keith Stevenson To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Was someone looking for a BSD licensed stat(1)? References: <19990728154654.A26747@homer.louisville.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Brian F. Feldman on Wed, Jul 28, 1999 at 04:01:10PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote: > Since you've got it in RCS, you shouldn't have any problem adding new > features. How about a selectable display of fields, and ability to put > them in machine-readable (read: no cut required) form? I'd suggest > having a function that would printf "%s: whatever", arg1 for humans > and "whatever" for machines, selectable by something like a -c > "compact output flag." Here's the GPLd stat I have: > Sure, I can work on that. It would be helpful if you could include a few sample outputs that I could work from. The current version already solves my problems, but I'll be happy to hack away at it if you are interested in including it in FreeBSD in some way. 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 Wed Jul 28 13:33: 9 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 2E16714C3C; Wed, 28 Jul 1999 13:32:53 -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 QAA14034; Wed, 28 Jul 1999 16:32:59 -0400 (EDT) Date: Wed, 28 Jul 1999 16:32:58 -0400 (EDT) From: Alfred Perlstein Reply-To: Alfred Perlstein To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero 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, 28 Jul 1999, Brian F. Feldman wrote: > On Wed, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. > > > > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. > > > *rant off* and so it should remain, changes that provide readability to code should be committed, the only time documentation of code is wrong is when it it is incorrect. Increasing the size of the cvs repo is not a consideration when worthwhile docs can be incorperated, especially when the person who needs to maintain it requires changess for readability. Is there a point to hindering the maintainer's ongoing work? -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:41: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 2E2A014C38; Wed, 28 Jul 1999 13:41:05 -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 QAA94340; Wed, 28 Jul 1999 16:39:30 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:39:29 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282024.OAA03102@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > > > I could work with it in this area. They aren't just to clean it up, or > > > > just for change's sake. They need to stay in. > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > That's true. I sure didn't do that. > > Sure looks like you did. There are white-space and re-ordering > modifications in the diffs you sent out. If you didn't do them, who > did? I refuse to justify putting variables in a function I changed in the right place. > > > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks.... > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > No, cleanups occur *separately* from code additions. The code is *very* > readable now, and just because you have stylistic differences doesn't > mean you get to change them because you like them. Stylistic differences my ass. This module (ip_fw) breaks style(9) in so many ways, it's not funny. It's sad. > > In particular, the changes I pointed out are not 'cleanups', but style > changes. When you make code readable, it's a cleanup. > > I repeat, this isn't your personal playground. Play by the rules or > don't play at all. "Follow KNF or stay out of the kernel code." > > > Nate > 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 28 13:41:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id D912C14C56; Wed, 28 Jul 1999 13:41:08 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05371; Wed, 28 Jul 1999 14:40:20 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03306; Wed, 28 Jul 1999 14:40:19 -0600 Date: Wed, 28 Jul 1999 14:40:19 -0600 Message-Id: <199907282040.OAA03306@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: "Brian F. Feldman" , Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks.... > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > > > > *rant off* > > and so it should remain, changes that provide readability to > code should be committed, the only time documentation of code > is wrong is when it it is incorrect. The changes pointed out do *NOT* make the code more readable. They just move statements around for no reason, and change whitespace. > Increasing the size of the cvs repo is not a consideration when > worthwhile docs can be incorperated, especially when the person > who needs to maintain it requires changess for readability. Brian is *NOT* the maintainer, he is the author of a patch to it. Doesn't anyone care for keeping the source code consistant *AND* maintainable for multiple people, as well as maintaining a history of *CHANGES* for people to review in the future? Or is this Linux, where we don't give a rip and whatever the current patch does to the rest of the tree is fine, since the more code we have the better? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:43:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9E4D414C56; Wed, 28 Jul 1999 13:43:20 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05403; Wed, 28 Jul 1999 14:42:35 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03370; Wed, 28 Jul 1999 14:42:35 -0600 Date: Wed, 28 Jul 1999 14:42:35 -0600 Message-Id: <199907282042.OAA03370@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282024.OAA03102@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > These were changes that were necessary to make ipfw readable enough that > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > just for change's sake. They need to stay in. > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > That's true. I sure didn't do that. > > > > Sure looks like you did. There are white-space and re-ordering > > modifications in the diffs you sent out. If you didn't do them, who > > did? > > I refuse to justify putting variables in a function I changed in the > right place. This and other obnoxious responses to valid responses makes me want to ask for your commit privileges. You obviously don't care what anyone else has done. > > In particular, the changes I pointed out are not 'cleanups', but style > > changes. > > When you make code readable, it's a cleanup. The code is *NO* more readable by you re-ordering lines and changes whitespace. Grow up and quit acting like a child who doesn't wanna follow the rules. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:46:59 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 1DEBA14C56; Wed, 28 Jul 1999 13:46:54 -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 QAA94554; Wed, 28 Jul 1999 16:46:22 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:46:21 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Alfred Perlstein , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org, bde@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282040.OAA03306@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > > > *rant on* > > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > > a group project, and you gotta follow the rules, or you don't get to > > > > play with the rest of the folks.... > > > > > > The rules don't say "leave the code that you work with in a bigger mess than > > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > > done to get work done, very often. You have to learn to deal with that. > > > > > > > *rant off* > > > > and so it should remain, changes that provide readability to > > code should be committed, the only time documentation of code > > is wrong is when it it is incorrect. > > The changes pointed out do *NOT* make the code more readable. They just > move statements around for no reason, and change whitespace. It makes it more readable if you understand and use KNF instead of try to bastardize everyone else's code. > > > Increasing the size of the cvs repo is not a consideration when > > worthwhile docs can be incorperated, especially when the person > > who needs to maintain it requires changess for readability. > > Brian is *NOT* the maintainer, he is the author of a patch to it. I'm one of the people who actively works on it. Who are you? > > Doesn't anyone care for keeping the source code consistant *AND* > maintainable for multiple people, as well as maintaining a history of > *CHANGES* for people to review in the future? What do you think KNF is about? I'll bring out the big guns now (BDE). > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? > You have no idea what you're talking about, WRT FreeBSD. > > > Nate > 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 28 13:52:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m2-36-dbn.dial-up.net (m2-36-dbn.dial-up.net [196.34.155.100]) by hub.freebsd.org (Postfix) with ESMTP id 124D315511 for ; Wed, 28 Jul 1999 13:52:41 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id WAA20811; Wed, 28 Jul 1999 22:50:42 +0200 (SAST) From: Robert Nordier Message-Id: <199907282050.WAA20811@ceia.nordier.com> Subject: Re: Including isa/isareg.h in sys/i386/boot/biosboot/serial.S In-Reply-To: <19990728153811.A39313@kilt.nothing-going-on.org> from Nik Clayton at "Jul 28, 1999 03:38:12 pm" To: nik@nothing-going-on.demon.co.uk (Nik Clayton) Date: Wed, 28 Jul 1999 22:50:40 +0200 (SAST) Cc: 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 > In the kernel config file you can use symbolic names for the various > COM ports, IO_COM1, IO_COM2, and so on. > > These seem be defined in sys/isa/isareg.h. > > If you want to configure FreeBSD to boot from a serial console you have > to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the > defines here, you have to use 0x3F8, 0x2F8, and so on. > > As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down > to sys/i386/boot/biosboot/serial.S. > > So, why not apply the following trivial patch to serial.S, so that > /etc/make.conf can instead contain > > BOOT_COMCONSOLE_PORT= IO_COM2 > > which is just slightly friendlier? I'm not what you'd call a kernel > hacker, so this might be a stupid idea. . . The sys/i386/boot/biosboot code is going away shortly. The corresponding non-legacy code is sys/boot/i386/boot2, though there are various other places in the new boot code this is used as well: kgzldr and libi386, for the i386. A suggestion similar to yours was discussed off the lists around seven months ago, but the majority view was that the perceived advantages didn't completely justify the required changes and potential confusion. Since the boot code works with the BIOS, the early binding of COM2 to 0x2f8 is probably not justified. COM2 could -- and maybe should -- mean "the port BIOS is using for COM2" which may be something quite different than 0x2f8. There's actually a fairly loose coupling between the kernel and the boot code, and making use of kernel configuration conventions, where the semantics may end up being just slightly different, is probably a less useful idea than it seems. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 13:59:49 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 125BE154EF; Wed, 28 Jul 1999 13:59:40 -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 RAA16033; Wed, 28 Jul 1999 17:00:25 -0400 (EDT) Date: Wed, 28 Jul 1999 17:00:23 -0400 (EDT) From: Alfred Perlstein To: Nate Williams Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282042.OAA03370@mt.sri.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, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough that > > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > > just for change's sake. They need to stay in. > > > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > > > That's true. I sure didn't do that. > > > > > > Sure looks like you did. There are white-space and re-ordering > > > modifications in the diffs you sent out. If you didn't do them, who > > > did? > > > > I refuse to justify putting variables in a function I changed in the > > right place. > > This and other obnoxious responses to valid responses makes me want to > ask for your commit privileges. You obviously don't care what anyone > else has done. > > > > In particular, the changes I pointed out are not 'cleanups', but style > > > changes. > > > > When you make code readable, it's a cleanup. > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. This is so very objective. > > Grow up and quit acting like a child who doesn't wanna follow the rules. quit acting like and old fart that fears change. (*) afaik, Brian is the mainter of ipfw, it should be noted so, so that if his changes break something it comes down on his head. Trust me to say something if that occurs. I'm no big friend of Brian, however changes to correct readability should be welcome especially to the maintainer. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ (*) if you don't like "old fart" then choose to play the age card with a bit more thought, there are many other commiters that fall under your catagorization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 14: 8:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 440A815509; Wed, 28 Jul 1999 14:08:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA05753; Wed, 28 Jul 1999 15:07:50 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA03686; Wed, 28 Jul 1999 15:07:49 -0600 Date: Wed, 28 Jul 1999 15:07:49 -0600 Message-Id: <199907282107.PAA03686@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: Nate Williams , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282042.OAA03370@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > In particular, the changes I pointed out are not 'cleanups', but style > > > > changes. > > > > > > When you make code readable, it's a cleanup. > > > > The code is *NO* more readable by you re-ordering lines and changes > > whitespace. > > This is so very objective. That's why it considered a 'stylistic' change, and not a functional change. And, that's why stylistic changes are not allowed to be mixed with functional changes. I quote from a recent article involving Brian early last week. ---------------------------------------------------------------------- From: "Jordan K. Hubbard" Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Date: Fri, 23 Jul 1999 19:25:26 -0700 > > I realize that stack space is not really an issue. Do you think I care > > about the possible savings of a few bytes? The issue is that variables > > should be declared _in_the_proper_places_, so that's where they go in > > my code. And yes, this is my code. I didn't appreciate Sheldon "restyling" > > it, because that makes it harder for /me/ to maintain. > > Having your own private coding style is arguably OK; using it > in other's code is definitely not. Please stick to the coding style > of the module you are editing. Actually, I hadn't even considered that point but Mark's entirely correct. You don't get to pick your own style in the middle of code that someone else has written, you stick to the SAME style even if it's totally style(9) non-conformant and icky in the extreme. .... ---------------------------------------------------------------------- You don't get to change styles even if it's non-conformant. > > Grow up and quit acting like a child who doesn't wanna follow the rules. > > quit acting like and old fart that fears change. (*) Fears change? Not quite. I was willing to write the necessary changes myself if necessary (see previous email on this thread), but I wanted to make sure it was both desirable (beyond one's person POV), as well as it wouldn't negatively effect other users of the system. > afaik, Brian is the mainter of ipfw, it should be noted so, so that > if his changes break something it comes down on his head. Trust > me to say something if that occurs. Brian is *NOT* the maintainer of IPFW, and thinking that is silliness. If you think that, then you're confused. Being the last person to commit something doesn't make you the committer, and even more so committing one change to the code doesn't make you the committer. I've committed two things to it, so I win by default in that case. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 14:17:34 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 SMTP id C200C154F9 for ; Wed, 28 Jul 1999 14:17:29 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40334>; Thu, 29 Jul 1999 06:55:37 +1000 Date: Thu, 29 Jul 1999 07:14:32 +1000 From: Peter Jeremy Subject: Re: replacing grep(1) To: hackers@FreeBSD.ORG Message-Id: <99Jul29.065537est.40334@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote: > The more complete the feature set, the better >off we are for my money. Someone offering money? Quick, who's got the donations hat... :-) 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 28 14:58: 4 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 C2AE214C1B for ; Wed, 28 Jul 1999 14:58:01 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id GAA17757; Thu, 29 Jul 1999 06:54:26 +0900 (JST) Message-ID: <379F7BF6.A763B681@newsguy.com> Date: Thu, 29 Jul 1999 06:53:58 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: Man pages for review References: <3759798A.A5A13C83@softweyr.com> 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 Wes Peters wrote: > > I have written man pages for aio_write, aio_error, aio_return, > aio_cancel, aio_suspend, and lio_listio. They are in my ~ on > freefall if anyone would like to review them. I have also edited > aio_read.2 and aio.h to correct minor problems, if you would like > to review those as well. While I cannot review them, I wish to nominate you for Hero of the Week. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a 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 28 16:10: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from FreeBSD.ORG (ppp27-besancon.isdnet.net [195.154.11.234]) by hub.freebsd.org (Postfix) with ESMTP id 0329214D1B for ; Wed, 28 Jul 1999 16:10:04 -0700 (PDT) (envelope-from jmz@FreeBSD.ORG) Received: (from jmz@localhost) by qix.jmz.org (8.9.3/8.9.3) id BAA20526; Thu, 29 Jul 1999 01:10:19 +0200 (MET DST) (envelope-from jmz@FreeBSD.ORG) Date: Thu, 29 Jul 1999 01:10:19 +0200 (MET DST) Message-Id: <199907282310.BAA20526@qix.jmz.org> From: Jean-Marc Zucconi To: freebsd-hackers@FreeBSD.ORG Subject: interesting bug in /usr/bin/cmp X-Mailer: Emacs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc -- Jean-Marc Zucconi PGP Key: finger jmz@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 28 16:10:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 6D7A814E3B for ; Wed, 28 Jul 1999 16:10:08 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id TAA94518 for ; Wed, 28 Jul 1999 19:07:41 -0400 (EDT) Message-Id: <199907282307.TAA94518@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: userfs help needed. Date: Wed, 28 Jul 1999 19:07:41 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am wading through the portalfs and nullfs source, but I am desperately lost. I would love to be able to find out who would be willing to help out with questions. I feel I would be spamming far too many people by just sending to -hackers. Some of the topics I am curious about are general fs-style questions, what the various vop/vfs calls do. Also I would like to know how to setup a shared memory segment between kernel and user space (as matt dillon suggested). Finally I would like to know how the buffer-cache interacts with the filesystem layer. Thanks -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 16:16:58 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 27E5914FD6 for ; Wed, 28 Jul 1999 16:16:45 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18328.on.bellglobal.com [206.172.130.8]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA07497; Wed, 28 Jul 1999 19:18:39 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA00380; Wed, 28 Jul 1999 19:15:31 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 19:15:31 -0400 From: Tim Vanderhoek To: "Daniel C. Sobral" Cc: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990728191531.A318@mad> References: <379F3701.F79E10DF@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <379F3701.F79E10DF@newsguy.com>; from Daniel C. Sobral on Thu, Jul 29, 1999 at 01:59:45AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote: > > Sorry, but a simplistic analysis like that just won't cut for grep. > The algorithmic complexity is highly relevant here. Try this: Algorithmic complexity!?! It's a freaking grep application. There is no freaking algorithmic complexity. At least not outside of our regex library, anyways. The test you suggested doesn't show anything about that algorithmic complexity, though. If we have a slow regex library, though, I would consider that a separate problem from a slow grep. -- 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 Wed Jul 28 16:17:13 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 0F6DB154EF; Wed, 28 Jul 1999 16:17:04 -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 TAA09123; Wed, 28 Jul 1999 19:16:36 -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 TAA08909; Wed, 28 Jul 1999 19:16:35 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id TAA63434; Wed, 28 Jul 1999 19:16:34 -0400 (EDT) Date: Wed, 28 Jul 1999 19:16:34 -0400 (EDT) From: Thomas David Rivers Message-Id: <199907282316.TAA63434@lakes.dignus.com> To: freebsd-hackers@FreeBSD.ORG, jmz@FreeBSD.ORG Subject: Re: interesting bug in /usr/bin/cmp In-Reply-To: <199907282310.BAA20526@qix.jmz.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If someone is interested to solve a problem: > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null > $ cp a b > $ cmp a b 0 0x300 > Segmentation fault (core dumped) > $ cmp a b 0 0x200 > cmp: EOF on b > $ cmp a b 0x300 0 > cmp: EOF on a > > Jean-Marc > I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. What makes me think so is that cmp would declare the files on a CDROM and the files on a disk drive were different, (well, it would dump core as in your example) - while cat'ing the file from the CDROM to a temp place on the same disk and doing the cmp there would indicate there are no differences.... The speculation was that there was some problem with the SCSI CDROM... but... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 16:24:26 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 C509814C3C; Wed, 28 Jul 1999 16:24:16 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18328.on.bellglobal.com [206.172.130.8]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA02378; Wed, 28 Jul 1999 19:25:49 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA00407; Wed, 28 Jul 1999 19:24:26 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 19:24:25 -0400 From: Tim Vanderhoek To: Nate Williams Cc: "Brian F. Feldman" , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero Message-ID: <19990728192425.C318@mad> References: <199907282024.OAA03102@mt.sri.com> <199907282042.OAA03370@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907282042.OAA03370@mt.sri.com>; from Nate Williams on Wed, Jul 28, 1999 at 02:42:35PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote: > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. It's white! No, dammit, it's beige! Fuck you, I said it's white! Beige! White! I dunno, I guess for some people the distinction's actually meaningful, but for myself, I was never good with colours. Colours and such aside, I will have to explain the word "politic" to Brian, someday, though. -- 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 Wed Jul 28 16:31:14 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 DEA1B1533B for ; Wed, 28 Jul 1999 16:31:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64309; Wed, 28 Jul 1999 16:31:04 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:31:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282331.QAA64309@apollo.backplane.com> To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. References: <199907282307.TAA94518@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I am wading through the portalfs and nullfs source, but I am desperately :lost. I would love to be able to find out who would be willing to help out :with questions. I feel I would be spamming far too many people by just sending :to -hackers. Some of the topics I am curious about are general fs-style :questions, what the various vop/vfs calls do. Also I would like to know how :to setup a shared memory segment between kernel and user space (as matt :dillon suggested). Finally I would like to know how the buffer-cache interacts :with the filesystem layer. : :Thanks :-- :David Cross | email: crossd@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Ouch. I don't think anyone understands the VOP stuff completely. It's a big mess -- which is why it's going to be rewritten later this year. Your best bet is to study the implementation of the UFS/FFS filesystem. It may also help to study a more recent filesystem such as coda. Specifically, ufs/ufs/ufs_vfsops.c ufs/ufs/ufs_vnops.c ufs/ffs/ffs_vfsops.c ufs/ffs/ffs_vnops.c coda/coda_vfsops.c coda/coda_vnops.c What I recommend is that you implement a skeleton that essentially returns an error for all the call entries and does a kernel printf(), and then implement the routines one at a time. The various VOP calls have different locking requirements and resource freeing requirements. The most difficult resource to deal with in the entire subsystem is the struct componentname structure used for lookup and related ops - all related to namei. That is, the code that deals with path elements. Generally speaking the VOP code is required to free a pathname component before returning, but not in all cases. It's a really odd set of rules and I'd have to review them myself to be able to explain them. -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 28 16:41:48 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 F265D15274; Wed, 28 Jul 1999 16:40:10 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18328.on.bellglobal.com [206.172.130.8]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA05969; Wed, 28 Jul 1999 19:40:17 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA00451; Wed, 28 Jul 1999 19:38:50 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 19:38:45 -0400 From: Tim Vanderhoek To: Nate Williams Cc: Alfred Perlstein , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990728193845.D318@mad> References: <199907282040.OAA03306@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907282040.OAA03306@mt.sri.com>; from Nate Williams on Wed, Jul 28, 1999 at 02:40:19PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote: > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? Nate, you know damn well that's not true. You're complaining about three lines in a large patch. Further, those three lines of the patch fix excessively long (+80 char) lines. Yes, you're right that those are non-functional changes and that ideally non-functional changes are placed in separate commits. You've also been around long enough to know that you're right and to be able to say so with an air of authority without a sense of insecurity, ending any debate about it after a mere 2 or 3 curt exchanges. Further, your communication skills should be sufficiently advanced to have noticed what appears (to me, at least) to have been the subtle miscommunication that occurred between message-id <199907282000.OAA02728@mt.sri.com> and message-id which lead to the stupid place you two are now sitting in. -- 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 Wed Jul 28 16:51: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 C9BC914F9C; Wed, 28 Jul 1999 16:51:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64420; Wed, 28 Jul 1999 16:48:43 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:48:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282348.QAA64420@apollo.backplane.com> To: Tim Vanderhoek Cc: Nate Williams , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907282024.OAA03102@mt.sri.com> <199907282042.OAA03370@mt.sri.com> <19990728192425.C318@mad> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The code is *NO* more readable by you re-ordering lines and changes :> whitespace. :... :.... :..... Sounds like one of many arguments I've had with various people who insist on nitpicking and critiqing to death tiny little itsy bitsy inconsistancies that no normal person would care about, in a commit that may have taken the author hours of work to make happen. Gee, someone getting a little hot under the collar? Why am I not surprised. It's one thing when the style's clash badly, quite another when the differences are minor -- things like blank lines (or lack of). I'll tell you something, folks, we don't need that kind of aggravation when the style differences are minor. If people want to insist on nitpicking the code, I recommend a rules change: Such people have to wait a month first, and then offer to make the style fix FOR the author rather then badger the author of the patch to do it. After all, the author of the patch is simply trying to fix the code, and spending a considerable amount of his own time doing so. The nitpicker, on the otherhand, is acting like a spoiled brat who can't be bothered to make the change himself after asking for (and almost certainly getting) permission. After a month, when the code in question is less likely to be under active development and the patch won't mess up the developers own tracking of the work, the nitpicker can offer to make the style commit. That strikes me as being quite fair. I also take exception to people trying to use KNF as a defense for their nitpicking. KNF is all well and fine, but it is not possible to lock any style in stone for years and years. You don't get new blood into a project that way, and only the few originals left in the crew wind up being comfortable with it. For example, take the evolution of procedural prototypes. When procedures were initially prototyped a lot of work went into the __P() style to allow compilation with and without prototypes. But in the last few years a significant portion of the code no longer bothers with __P() --- because the code is *expected* to be prototyped and *expected* to be compiled with a compiler that understands them. I am sick and tired of standards which are unable to evolve with the times and I am sick and tired of people who try to enforce standards yet are unwilling to allow them to evolve in any meaningful fashion. -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 28 16:57:52 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 2AADC1547E for ; Wed, 28 Jul 1999 16:57:47 -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 RAA406796; Wed, 28 Jul 1999 17:55:55 -0600 (MDT) Date: Wed, 28 Jul 1999 17:55:55 -0600 From: "Ronald G. Minnich" To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. In-Reply-To: <199907282331.QAA64309@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, 28 Jul 1999, Matthew Dillon wrote: > Ouch. I don't think anyone understands the VOP stuff completely. It's > a big mess -- which is why it's going to be rewritten later this year. > > Your best bet is to study the implementation of the UFS/FFS filesystem. well, i'd do v9fs before studying ufs. I tried studying ufs, but I think v9fs is easier. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 17: 2:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id B45911547E for ; Wed, 28 Jul 1999 17:02:22 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.78 (dialup-8.rebel.net.au [203.20.69.78]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id JAA13083 for ; Thu, 29 Jul 1999 09:30:44 +0930 Received: (qmail 2589 invoked from network); 29 Jul 1999 00:00:38 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 29 Jul 1999 00:00:38 -0000 Date: Thu, 29 Jul 1999 09:30:38 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. In-Reply-To: <199907282307.TAA94518@cs.rpi.edu> 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, 28 Jul 1999, David E. Cross wrote: > I am wading through the portalfs and nullfs source, but I am desperately > lost. I would love to be able to find out who would be willing to help out > with questions. I feel I would be spamming far too many people by just sending > to -hackers. Might I suggest the freebsd-fs mailing list? I'll be reading this thread with great interest :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 17:11: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 1A10C154C3 for ; Wed, 28 Jul 1999 17:11:00 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with SMTP id BAA15322; Thu, 29 Jul 1999 01:10:26 +0100 (BST) (envelope-from arg@arg1.demon.co.uk) Date: Thu, 29 Jul 1999 01:10:26 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: Linear buffers in VESA screen modes 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 28 Jul 1999, Dag-Erling Smorgrav wrote: > Andrew Gordon writes: > > The application for which I need this is to support capture from the bktr > > driver onto the screen (ie. so that you can watch TV without X). With the > > above hack and a small (100-line) program it works very nicely - far > > tidier than installing X just for this purpose on some embedded systems > > where I need this capability. > > Might one persuade you to release that 100-line program? :) Sure. It's rather crude at present, but I've put it up at: http://www.arg1.demon.co.uk/vesatv.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 17:56:51 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 2EABA1529E; Wed, 28 Jul 1999 17:56:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA65104; Wed, 28 Jul 1999 17:55:58 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 17:55:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907290055.RAA65104@apollo.backplane.com> To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, 28 Jul 1999, Nate Williams wrote: :> > :> > These were changes that were necessary to make ipfw readable enough that :> > I could work with it in this area. They aren't just to clean it up, or :> > just for change's sake. They need to stay in. :> :> C'mon now, re-ording the lines is *certainly* not necessary to work. : :That's true. I sure didn't do that. : :> :> *rant on* :> Brian, FreeBSD isn't your private playground for playing around, this is :> a group project, and you gotta follow the rules, or you don't get to :> play with the rest of the folks.... : :The rules don't say "leave the code that you work with in a bigger mess than :when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be :done to get work done, very often. You have to learn to deal with that. : :> *rant off* :> :> Nate :> : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ Side note: I do the same thing: clean up certain portions of the code in order to make them more readable while I'm working on the module. And while I tend to agree that it would be nice to commit the bug fixes separately, it just isn't practical most of the time because one might have already spent too big a chunk of one's own time to do the work in the first place. And I get the same sort of crap from certain core members, too. It's truely annoying when you've spent the time ( sometimes a whole LOT of time ) and trouble to fix something and all some people can do is complain about extremely trivial elements of the work. -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 28 18: 2:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 71EC714F5B for ; Wed, 28 Jul 1999 18:02:13 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA15402; Wed, 28 Jul 1999 17:59:29 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 28 Jul 1999 17:59:29 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Dag-Erling Smorgrav Cc: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services 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 26 Jul 1999, Dag-Erling Smorgrav wrote: > Sheldon Hearn writes: > > I plan to mention in the comments for each service in /etc/services, the > > latest RFC describing the service. > > Good idea. Hmmmm... I'm not sure what this gets us. Wouldn't it be better to place this kind of information in the man page that you suggest below? As often as /etc/services gets read, do we really want to bloat it with non-functional information? > Don't. Instead, put it in a separate rfc(7) man page which you refer > to in the services(5) man page. Good suggestions all the way around. I'd also like to throw in this link, which is the best RFC repository I've seen on the basis of speed, reliability, and cross-indexing: http://www.cis.ohio-state.edu/hypertext/information/rfc.html. If you really want to improve /etc/services, the first commit should be to delete all the extraneous whitespace at the end of the lines. 23$ grep -c ' $' /etc/services 173 25$ grep -c '^I$' /etc/services 97 Next it would be nice if we added entries for things in our system that don't have them. (Hint: what's listening on ports 1022 and 1023?) Then, someone either needs to fix getserv*() so that they accept port ranges like 6000-6063/tcp (much preferred) or roll out those port numbers in /etc/services (yuck). It would also be nice if someone would take another look at bringing our /etc/services file more up to date with IANA (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe someone has a PR open on this... :) David O'Brien and I were working on it for a while, but we both got busy working on other things. I had a pretty good set of scripts going to produce a workable file in services format from the IANA list, but what I should really do is write one perl script to do it. I fear however that the chance of the file being updated on that kind of scale would be very small (it always meets a lot of resistance) so I'm not sure it would be worth it. Ideas? Comments? Finally I want to urge a lot of caution to anyone who tampers with the file. I learned from painful experience that very small errors can lead to big problems in very unexpected ways. For instance, my ipfw firewall went totally nutso at one point because I had some comments in /etc/services in the wrong format back when I was playing around with it. This is not something to be tampered with lightly. 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 Wed Jul 28 18: 8: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 B34641551E for ; Wed, 28 Jul 1999 18:08:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA65216; Wed, 28 Jul 1999 18:07:45 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 18:07:45 -0700 (PDT) From: Matthew Dillon Message-Id: <199907290107.SAA65216@apollo.backplane.com> To: Doug Cc: Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Sheldon Hearn writes: :> > I plan to mention in the comments for each service in /etc/services, the :> > latest RFC describing the service. :> :> Good idea. : : Hmmmm... I'm not sure what this gets us. Wouldn't it be better to :place this kind of information in the man page that you suggest below? As :often as /etc/services gets read, do we really want to bloat it with :non-functional information? :... :Doug I kinda like the idea of putting the RFC numbers in comments in /etc/services. It makes the comments more meaningful. : If you really want to improve /etc/services, the first commit :should be to delete all the extraneous whitespace at the end of the lines. : :23$ grep -c ' $' /etc/services :173 : :25$ grep -c '^I$' /etc/services :97 :... It would be nice if we DBM'd /etc/services. /etc/services is 61KB+ now, I think DBMing it in a manner similar to how some of the other system files which are DBM'd would be worthwhile. -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 28 18:14:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by hub.freebsd.org (Postfix) with ESMTP id C197615547 for ; Wed, 28 Jul 1999 18:14:45 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-212.s21.as3.hgt.md.dialup.rcn.com [207.172.143.212]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id VAA27141; Wed, 28 Jul 1999 21:14:51 -0400 (EDT) Message-Id: <199907290114.VAA27141@smtp2.erols.com> 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: Wed, 28 Jul 1999 21:13:42 -0400 (EDT) From: John Baldwin To: Andrew Gordon Subject: Re: Linear buffers in VESA screen modes Cc: hackers@FreeBSD.ORG, Dag-Erling Smorgrav Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Jul-99 Andrew Gordon wrote: > On 28 Jul 1999, Dag-Erling Smorgrav wrote: > >> Andrew Gordon writes: >> > The application for which I need this is to support capture from the bktr >> > driver onto the screen (ie. so that you can watch TV without X). With the >> > above hack and a small (100-line) program it works very nicely - far >> > tidier than installing X just for this purpose on some embedded systems >> > where I need this capability. >> >> Might one persuade you to release that 100-line program? :) > > Sure. It's rather crude at present, but I've put it up at: > > http://www.arg1.demon.co.uk/vesatv.c My wincast tv card seemed to work w/o your patch to vesa.c. Although I don't think it set the resolution right. I need to get to somewhere that I can get to more than just static though. :) Once I do, I may try and add some support for changing channels and what not, if you don't mind. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use 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 28 19:41: 5 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 8E1111550F for ; Wed, 28 Jul 1999 19:40:52 -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 EAA01408 for freebsd-hackers@FreeBSD.org; Thu, 29 Jul 1999 04:40:49 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 8BD9D87AE; Thu, 29 Jul 1999 00:37:51 +0200 (CEST) (envelope-from roberto) Date: Thu, 29 Jul 1999 00:37:51 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.org Subject: Re: Was someone looking for a BSD licensed stat(1)? Message-ID: <19990729003751.A41102@keltia.freenix.fr> Mail-Followup-To: freebsd-hackers@FreeBSD.org References: <19990728154654.A26747@homer.louisville.edu> <19990728162436.D29649@homer.louisville.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <19990728162436.D29649@homer.louisville.edu>; from Keith Stevenson on Wed, Jul 28, 1999 at 04:24:36PM -0400 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5468 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Keith Stevenson: > Sure, I can work on that. It would be helpful if you could include a few > sample outputs that I could work from. You may also want to look at the builtin stat(1) function in zsh too. 3.1.5+ only, I don't think 3.1.4 had it. BTW 3.1.6 now pretty close to release. stat [ -gnNlLtTrs ] [ -f fd ] [ -H hash ] [ -A array ] [ -F fmt ] [ +element ] [ file ... ] The command acts as a front end to the stat system call (see stat(2)). If the stat call fails, the appropriate system error message printed and status 1 is returned. The fields of struct stat give information about the files provided as arguments to the command. In addition to those available from the stat call, an extra element `link' is pro- vided. These elements are: device The number of the device on which the file resides. inode The unique number of the file on this device (`inode' number). mode The mode of the file; that is, the file's type and access permissions. With the -s option, this will be returned as a string corresponding to the first column in the display of the ls -l command. nlink The number of hard links to the file. uid The user ID of the owner of the file. With the -s option, this is displayed as a user name. gid The group ID of the file. With the -s option, this is displayed as a group name. rdev The raw device number. This is only useful for special devices. size The size of the file in bytes. atime mtime ctime The last access, modification and inode change times of the file, respectively, as the number of seconds since midnight GMT on 1st January, 1970. With the -s option, these are printed as strings for the local time zone; the format can be altered with the -F option, and with the -g option the times are in GMT. blksize The number of bytes in one allocation block on the device on which the file resides. block The number of disk blocks used by the file. link If the file is a link and the -L option is in effect, this contains the name of the file linked to, otherwise it is empty. Note that if this element is selected (``stat +link'') then the -L option is automatically used. A particular element may be selected by including its name preceded by a `+' in the option list; only one element is allowed. The element may be short- ened to any unique set of leading characters. Oth- erwise, all elements will be shown for all files. Options: -A array Instead of displaying the results on stan- dard output, assign them to an array, one struct stat element per array element for each file in order. In this case neither the name of the element nor the name of the files is provided unless the -t or -n options are provided, respectively. In the former case the element name appears as a prefix to the appropriate array element and in the latter case the file name appears as a separate array element preceding all the others. Other formatting options are respected. -H hash Similar to -A, but instead assign the values to hash. The keys are the elements listed above. If the -n option is provided then the name of the file is included in the hash with key name. -f fd Use the file on file descriptor fd instead of named files; no list of file names is allowed in this case. -F fmt Supplies a strftime (see strftime(3)) string for the formatting of the time elements. The -s option is implied. -g Show the time elements in the GMT time zone. The -s option is implied. -l List the names of the type elements (to standard output or an array as appropriate) and return immediately; options other than -A and arguments are ignored. -L Perform an lstat (see lstat(2)) rather than a stat system call. In this case, if the file is a link, information about the link itself rather than the target file is returned. This option is required to make the link element useful. -n Always show the names of files. Usually these are only shown when output is to stan- dard output and there is more than one file in the list. -N Never show the names of files. -r Print raw data (the default format) along- side string data (the -s format); the string data appears in parentheses after the raw data. -s Print mode, uid, gid and the three time ele- ments as strings instead of numbers. In each case the format is like that of ls -l. -t Always show the type names for the elements of struct stat. Usually these are only shown when output is to standard output and no individual element has been selected. -T Never show the type names of the struct stat elements. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 20:39: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id D0CA314CBF for ; Wed, 28 Jul 1999 20:39:02 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id WAA95155; Wed, 28 Jul 1999 22:39:11 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907290339.WAA95155@celery.dragondata.com> Subject: Re: Replace/rewrite reverse.c for tail(1) In-Reply-To: <64003B21ECCAD11185C500805F31EC030378660F@houston.matchlogic.com> from Charles Randall at "Jul 28, 1999 09:27:28 am" To: crandall@matchlogic.com (Charles Randall) Date: Wed, 28 Jul 1999 22:39:11 -0500 (CDT) Cc: hackers@FreeBSD.ORG, toasty@dragondata.com (Kevin Day) 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 Because of licensing restrictions in our product, we are unable to ship with any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I saw tac, and agree that it is faster for this specific use) Any VM people wanna pipe up and make a suggestion so that I may make up a patch? Kevin [Charset iso-8859-1 unsupported, filtering to ASCII...] > I'd suggest that you use "tac" from GNU textutils. > > Charles > > -----Original Message----- > From: Kevin Day [mailto:toasty@dragondata.com] > Sent: Wednesday, July 28, 1999 3:09 AM > To: hackers@freebsd.org > Subject: Replace/rewrite reverse.c for tail(1) > > An application I use quite often requires me to reverse the lines in the > file to get the desired output. > > 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's > the entire file in, which encourages the kernel to swap out the rest of the > system to keep pages of the input file in memory. > > 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail > > Out of 128M of ram, it's swapped nearly everything else out to keep 85M of > this 400M file in ram, even though it will never touch it again. :) > > I see two possible fixes for this. One could be madvise'ing periodically > with MADV_DONTNEED. If I understand correctly, this would help a bit, right? > > Or, mmap smaller regions of the file, and keep moving the buffer. This would > also help with files exceeding mmap's limits. > > > Any thoughts? > > > Kevin > > > 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 Wed Jul 28 21:16:55 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 43C821546E for ; Wed, 28 Jul 1999 21:16:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA66114; Wed, 28 Jul 1999 21:16:18 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 21:16:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199907290416.VAA66114@apollo.backplane.com> To: Kevin Day Cc: crandall@matchlogic.com (Charles Randall), hackers@FreeBSD.ORG, toasty@dragondata.com (Kevin Day) Subject: Re: Replace/rewrite reverse.c for tail(1) References: <199907290339.WAA95155@celery.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Because of licensing restrictions in our product, we are unable to ship with :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I :saw tac, and agree that it is faster for this specific use) : :Any VM people wanna pipe up and make a suggestion so that I may make up a :patch? : :Kevin I don't think madvise()ing it MADV_DONTNEED will work right now. The madvise() calls only work with OBJT_DEFAULT and OBJT_SWAP objects -- i.e. swap-backed memory. They will not do anything to pages owned by file mmaps. We could fix vm/vm_object.c/vm_object_madvise() to handle MADV_DONTNEED for other objects. It would not be too difficult to do, actually, since we would be doing nothing more then moving the (must be clean) page to VM cache to get it to be reused more quickly. This is a fix I could make to CURRENT without too much trouble. -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 28 21:39:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 105AD14D60 for ; Wed, 28 Jul 1999 21:39:46 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id XAA69977; Wed, 28 Jul 1999 23:39:32 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907290439.XAA69977@celery.dragondata.com> Subject: Re: Replace/rewrite reverse.c for tail(1) In-Reply-To: <199907290416.VAA66114@apollo.backplane.com> from Matthew Dillon at "Jul 28, 1999 09:16:18 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 28 Jul 1999 23:39:32 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), crandall@matchlogic.com (Charles Randall), 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 > > :Because of licensing restrictions in our product, we are unable to ship with > :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I > :saw tac, and agree that it is faster for this specific use) > : > :Any VM people wanna pipe up and make a suggestion so that I may make up a > :patch? > : > :Kevin > > I don't think madvise()ing it MADV_DONTNEED will work right now. The > madvise() calls only work with OBJT_DEFAULT and OBJT_SWAP objects -- i.e. > swap-backed memory. They will not do anything to pages owned by > file mmaps. > > We could fix vm/vm_object.c/vm_object_madvise() to handle > MADV_DONTNEED for other objects. It would not be too difficult to > do, actually, since we would be doing nothing more then moving the > (must be clean) page to VM cache to get it to be reused more quickly. > This is a fix I could make to CURRENT without too much trouble. > > -Matt > Wow, that's interesting. While I never looked at the code, I *thought* I was able to measure a speed boost in a certain large embedded application I'm working on, with adding some madvise()'s in to mmap'ed files. (Streaming video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it may have been insignificant) This is a problem I've run into a few times before, actually. One-time use data that will shove the entire system out of ram, and no convenient way to tell the kernel that it shouldn't bother holding on to it. I believe dg ran into this too, and had some fix he was using on ftp.cdrom.com. In my application, when I play a movie, it'd be nice to be able to specify a priority. "Try to keep this, even if it means possibly swapping" (current behavior) or "Don't swap out anything for this object, it's far too large to bother with trying to hold on to it and/or it will only be used once." Granted 'large' is one of those fuzzy terms, but when you do know that the 900M file you're reading is being done sequentially from start to finish, swapping things out to try to keep more of it in swap is probably bad. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 28 21:45:45 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 4742B15584 for ; Wed, 28 Jul 1999 21:45:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA66252; Wed, 28 Jul 1999 21:45:40 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 21:45:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907290445.VAA66252@apollo.backplane.com> To: Kevin Day Cc: toasty@dragondata.com (Kevin Day), crandall@matchlogic.com (Charles Randall), hackers@FreeBSD.ORG Subject: Re: Replace/rewrite reverse.c for tail(1) References: <199907290439.XAA69977@celery.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Wow, that's interesting. While I never looked at the code, I *thought* I was :able to measure a speed boost in a certain large embedded application I'm :working on, with adding some madvise()'s in to mmap'ed files. (Streaming :video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it :may have been insignificant) MADV_SEQUENTIAL *WILL* work. It changes the page fault read-behind/read-ahead. Normally the VM system reads behind a bit as well as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing read-ahead, and it does more of it. The madvise() types that just flag the VM object work on any type of object. The madvise() types that actually mess with VM pages currently only work on swap-backed pages. MADV_WILLNEED scans for VM pages in object MADV_DONTNEED scans for VM pages in object MADV_FREE scans for VM pages in object MADV_SEQUENTIAL just flags the object MADV_RANDOM just flags the object MADV_NORMAL just flags the object :Granted 'large' is one of those fuzzy terms, but when you do know that the :900M file you're reading is being done sequentially from start to finish, :swapping things out to try to keep more of it in swap is probably bad. :) : :Kevin I agree completely. When you run through the filesystem these pages will be reused more quickly. When you run through the VM system these pages are considered to be more 'active'. I think it makes sense to have madvise() MADV_WILLNEED and MADV_DONTNEED operate on file mmaps. There is a slight security concern with MADV_DONTNEED (i.e. if you loop running it on a system file that is used a lot, like /etc/group), but after thinking about it a bit I do not think it is a big deal. -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 28 21:52:32 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 7E14214ED2; Wed, 28 Jul 1999 21:52:29 -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 AAA03975; Thu, 29 Jul 1999 00:52:27 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 29 Jul 1999 00:52:27 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Thomas David Rivers Cc: freebsd-hackers@FreeBSD.org, jmz@FreeBSD.org Subject: Re: interesting bug in /usr/bin/cmp In-Reply-To: <199907282316.TAA63434@lakes.dignus.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, 28 Jul 1999, Thomas David Rivers wrote: > > > > If someone is interested to solve a problem: > > > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null > > $ cp a b > > $ cmp a b 0 0x300 > > Segmentation fault (core dumped) > > $ cmp a b 0 0x200 > > cmp: EOF on b > > $ cmp a b 0x300 0 > > cmp: EOF on a > > > > Jean-Marc > > > > I've seen a similar problem when doing cmp with CD-ROM > devices (I believe I entered a PR on it.) > > I think the problem has to do with cmp's use of mmap(), and > potential issues there... But, that's just a guess on my part. It has to do with mmap(), but not any specific issues with mmap(), just a bug in its use. If noone has any objections, I will commit this and MFC it in a week or so. --- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 @@ -57,7 +57,7 @@ off_t skip1, len1, skip2, len2; { u_char ch, *p1, *p2; - off_t byte, length, line; + off_t byte, length, line, mlength; int dfound; off_t pagemask, off1, off2; @@ -76,17 +76,18 @@ off2 = ROUNDPAGE(skip2); length = MIN(len1, len2); - if (length > SIZE_T_MAX) + mlength = MAX(len1, len2); + if (mlength > SIZE_T_MAX) return (c_special(fd1, file1, skip1, fd2, file2, skip2)); if ((p1 = (u_char *)mmap(NULL, - (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) + (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) err(ERR_EXIT, "%s", file1); - madvise(p1, length, MADV_SEQUENTIAL); + madvise(p1, mlength, MADV_SEQUENTIAL); if ((p2 = (u_char *)mmap(NULL, - (size_t)length, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) + (size_t)mlength, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) err(ERR_EXIT, "%s", file2); - madvise(p2, length, MADV_SEQUENTIAL); + madvise(p2, mlength, MADV_SEQUENTIAL); dfound = 0; p1 += skip1 - off1; 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 29 0:18:51 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 E2CC614E53; Thu, 29 Jul 1999 00:18:47 -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 BAA72348; Thu, 29 Jul 1999 01:17:15 -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 BAA74680; Thu, 29 Jul 1999 01:18:49 -0600 (MDT) Message-Id: <199907290718.BAA74680@harmony.village.org> To: "Brian F. Feldman" Subject: Re: interesting bug in /usr/bin/cmp Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 29 Jul 1999 00:52:27 EDT." References: Date: Thu, 29 Jul 1999 01:18:48 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : if ((p1 = (u_char *)mmap(NULL, : - (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) : + (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) : err(ERR_EXIT, "%s", file1); This would be a good candiate for different line breaks for clarity if ((p1 = (u_char *)mmap(NULL, (size_t)mlength, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) would be more readable and not violate the 80 column rule. Since the call to mmap is already split and you are already changing it, I don't think this would be a problem. While I do try to minimize stylistic changes, I think this one makes good sense.... : - (size_t)length, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) : + (size_t)mlength, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) : err(ERR_EXIT, "%s", file2); See above :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 0:37:22 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 9BF4715535; Thu, 29 Jul 1999 00:37:20 -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 AAA01875; Thu, 29 Jul 1999 00:37:24 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: Doug@gorean.org, sheldonh@uunet.co.za, vanderh@ecf.utoronto.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? In-reply-to: Your message of "Tue, 27 Jul 1999 12:27:24 PDT." <199907271927.MAA38591@silvia.hip.berkeley.edu> Date: Thu, 29 Jul 1999 00:37:24 -0700 Message-ID: <1871.933233844@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * it's part of the dependancy chain now for a lot of packages, > > You are entitled to you opinion, but please don't misrepresent the > facts. They are not part of the dependency chain for any *packages*. Sorry if the english I used was ambiguous - I should have said "to install packages using sysinstall, and possibly the pkg_add tool as well in the future, the INDEX file is part of the dependency chain." This is indisputably true and if you'd care to argue the point, I'll be happy to point you at the relevant source code. > True, but all the INDEX files *I* make for package sets (and those are > the only ones you ought to be using, since those are the only ones > truly synced with the time of package builds) have the XFree86 stuff > stripped. :) This point is irrelevant for a number of reasons, only several of which I will list here: 1. I'm hardly the only one who splits up package sets and/or makes FreeBSD ISO images and it's possible to derive an otherwise perfectly reasonable INDEX file from multiple sources. It shouldn't be necessary to put a note on the file saying "go ask Satoshi if you want a sanitized INDEX file to use" and the very concept would violate POLA anyway. 2. Your INDEX files can frequently be out of date with the ports collection and someone should be able to do their own "make index" when that happens. 3. The assumption has always been that the dependency lists in the INDEX file will reflect one's best-effort attempt at providing all the packages so referenced in whatever package [sub]collection you're providing to someone. In order to qualify for inclusion in this file, the XFree86 port should therefore be generating suitable packages and that is simply not [yet] the case. The INDEX file certainly isn't for the ports - they already get the dependency information out of the Makefiles - it's for the packages and for rudimentary search features. And I think I am on fairly safe ground when I tell you what the INDEX file is for because I was the one to add it in the first place back in 1995, as the cvs log entry for ports/Makefile will cheerfully tell you: ---------------------------- revision 1.8 date: 1995/01/14 11:27:06; author: jkh; state: Exp; lines: +7 -1 1. Make an index rule 2. Commit an INDEX file containing information on the various ports. ---------------------------- I know when and why I added INDEX files and I know when and why you added breakage to this mechanism, breakage you have been seemingly unwilling to simply fix, preferring to back patch the end-product instead of fixing the generation script OR providing the XFree86-3.3.4 meta-port which goes and loads the appropriate subcomponents and makes the INDEX file entries "true" again. To put it another way, consider me as Bruce and this as a really egregious style(9) bug on your part. You can argue about it forever, but it won't make you any less wrong in the end. :) - 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 29 1: 5:42 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 0FEF414C3F for ; Thu, 29 Jul 1999 01:05:37 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id JAA99359; Thu, 29 Jul 1999 09:04:21 +0100 (BST) (envelope-from joe) Date: Thu, 29 Jul 1999 09:04:20 +0100 From: Josef Karthauser To: Doug Cc: Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services Message-ID: <19990729090420.A98489@pavilion.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Doug on Wed, Jul 28, 1999 at 05:59:29PM -0700 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 Wed, Jul 28, 1999 at 05:59:29PM -0700, Doug wrote: > On 26 Jul 1999, Dag-Erling Smorgrav wrote: > > It would also be nice if someone would take another look at > bringing our /etc/services file more up to date with IANA > (http://www.isi.edu/in-notes/iana/assignments/port-numbers). I believe > someone has a PR open on this... :) David O'Brien and I were working on it > for a while, but we both got busy working on other things. I had a pretty > good set of scripts going to produce a workable file in services format > from the IANA list, but what I should really do is write one perl script > to do it. I fear however that the chance of the file being updated on that > kind of scale would be very small (it always meets a lot of resistance) so > I'm not sure it would be worth it. Ideas? Comments? > A question that always baffled me (I'm fairly easy to baffle) is why we've got some numbers defined as both udp and tcp when the service type is only one or the other. Does anyone know? 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 Thu Jul 29 1:27:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 1D9A215034; Thu, 29 Jul 1999 01:27:43 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id KAA80825; Thu, 29 Jul 1999 10:27:30 +0200 (CEST) (envelope-from ap) Date: Thu, 29 Jul 1999 10:27:30 +0200 From: Achim Patzner To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990729102730.B75233@bnc.net> References: <199907282008.OAA02877@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Brian F. Feldman on Wed, Jul 28, 1999 at 04:17:57PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 04:17:57PM -0400, Brian F. Feldman wrote: > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. I don't see _removing_ white space improving readability (but I started out as a programmer working for a company where reviewers had to check if at least 40% of the sources were _meaningfull_ comments, all closing } had a comment telling what the block was good for and where goto and break (except in case statements) were completely forbidden). If you two can't settle your arguments you might send the patches to the Bruce-machine... Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 2: 6:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dyson.iquest.net. (iq-ind-dns003-90.iquest.net [198.70.149.90]) by hub.freebsd.org (Postfix) with ESMTP id 522D6155A1 for ; Thu, 29 Jul 1999 02:05:50 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from toor@localhost) by dyson.iquest.net. (8.9.3/8.9.3) id EAA57212; Thu, 29 Jul 1999 04:04:04 -0500 (EST) (envelope-from toor) Message-Id: <199907290904.EAA57212@dyson.iquest.net.> Subject: Re: Replace/rewrite reverse.c for tail(1) In-Reply-To: <64003B21ECCAD11185C500805F31EC030378660F@houston.matchlogic.com> from Charles Randall at "Jul 28, 1999 09:27:28 am" To: crandall@matchlogic.com (Charles Randall) Date: Thu, 29 Jul 1999 04:04:04 -0500 (EST) Cc: hackers@freebsd.org, toasty@dragondata.com (Kevin Day) From: "John S. Dyson" Reply-To: dyson@iquest.net 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 Charles Randall said: > > Out of 128M of ram, it's swapped nearly everything else out to keep 85M of > this 400M file in ram, even though it will never touch it again. :) > > I see two possible fixes for this. One could be madvise'ing periodically > with MADV_DONTNEED. If I understand correctly, this would help a bit, right? > > Or, mmap smaller regions of the file, and keep moving the buffer. This would > also help with files exceeding mmap's limits. > > > Any thoughts? > Unless the ability has been removed recently, setting the physical memory soft limit can help a very little bit also: bash> ulimit -m 16384 can make a program a little more friendly to it's neighbors. The soft (in both senses) limit is mushy, but provides some hints when paging ensues. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 2:10:55 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 EEDDD155A3 for ; Thu, 29 Jul 1999 02:10:42 -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 119mCW-000Aqx-00; Thu, 29 Jul 1999 11:10:08 +0200 From: Sheldon Hearn To: Robert Nordier Cc: hackers@FreeBSD.ORG Subject: Re: bin/12852: Non-standard behavior of fread(3) In-reply-to: Your message of "Wed, 28 Jul 1999 20:13:18 +0200." <199907281813.UAA17849@m2-2-dbn.dial-up.net> Date: Thu, 29 Jul 1999 11:10:08 +0200 Message-ID: <41722.933239408@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999 20:13:18 +0200, Robert Nordier wrote: > There's no question this needs changing. An ISO example actually > reads along the lines of: The question, though, is whether it needs changing _now_, or whether this'll break a number of critical utilities that rely on the broken behaviour. I can't imagine the latter case being true, but I thought it safe to put to question before folks with more experience. :-) 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 29 2:16:19 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 0BF0B15595 for ; Thu, 29 Jul 1999 02:16:08 -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 119mGa-000As0-00; Thu, 29 Jul 1999 11:14:20 +0200 From: Sheldon Hearn To: Josef Karthauser Cc: hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Thu, 29 Jul 1999 09:04:20 +0100." <19990729090420.A98489@pavilion.net> Date: Thu, 29 Jul 1999 11:14:20 +0200 Message-ID: <41787.933239660@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 09:04:20 +0100, Josef Karthauser wrote: > A question that always baffled me (I'm fairly easy to baffle) is why > we've got some numbers defined as both udp and tcp when the service > type is only one or the other. Does anyone know? Probably because this question isn't accompanied by a list of offenders. :-) By the way, I originally said I'd have this done in a week. I can only imagine how many of the die-hards giggled in the background, since it involves quite a bit of reading. And then there are all the useful suggestions I've received. Let's leave this alone until I have diffs to show y'all? 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 29 2:38: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 EC31114C85 for ; Thu, 29 Jul 1999 02:38:50 -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 119mdh-000B2T-00; Thu, 29 Jul 1999 11:38:13 +0200 From: Sheldon Hearn To: obrien@NUXI.com Cc: hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo In-reply-to: Your message of "Wed, 28 Jul 1999 09:55:24 MST." <19990728095524.K66569@dragon.nuxi.com> Date: Thu, 29 Jul 1999 11:38:13 +0200 Message-ID: <42436.933241093@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote: > My major Duh!! If Christos sees this thread, my apologies. Hehe, now you know how it feels to be the guy who calls you Brian. :-) 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 29 3: 1:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id E6C32155DE for ; Thu, 29 Jul 1999 03:01:41 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 29 Jul 1999 11:01:35 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PJ2VDX7Y; Thu, 29 Jul 1999 11:01:34 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 119n0F-000DGF-00; Thu, 29 Jul 1999 11:01:31 +0100 Date: Thu, 29 Jul 1999 11:01:31 +0100 To: Josef Karthauser Cc: Doug , Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services Message-Id: <19990729110131.A50938@voodoo.pandhm.co.uk> References: <19990729090420.A98489@pavilion.net> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <19990729090420.A98489@pavilion.net>; from Josef Karthauser on Thu, Jul 29, 1999 at 09:04:20AM +0100 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote: > A question that always baffled me (I'm fairly easy to baffle) is why we've > got some numbers defined as both udp and tcp when the service type is only > one or the other. Does anyone know? Probably because the IANA specifies them that way. I think that they try to keep both UDP and TCP ports the same, "just in case". There might be a better explanation in rfc1700 (assigned numbers), or whatever it's latest edition is. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 3:52:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dns0.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id 7E44E155B6 for ; Thu, 29 Jul 1999 03:52:08 -0700 (PDT) (envelope-from ad@netbsd.org) Message-ID: <37A03218.422FFF83@netbsd.org> Date: Thu, 29 Jul 1999 11:51:04 +0100 From: Andy Doran X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: obrien@NUXI.com Cc: hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo References: <42436.933241093@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999 09:55:24 MST, "David O'Brien" wrote: > My major Duh!! If Christos sees this thread, my apologies. David, I was trying to be helpful; sorry if my msg came across wrong. - ad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 4: 0:36 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 2D17214FEE; Thu, 29 Jul 1999 04:00:17 -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 119nv1-000BKq-00; Thu, 29 Jul 1999 13:00:11 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: Thomas David Rivers , freebsd-hackers@FreeBSD.org, jmz@FreeBSD.org Subject: Re: interesting bug in /usr/bin/cmp In-reply-to: Your message of "Thu, 29 Jul 1999 00:52:27 -0400." Date: Thu, 29 Jul 1999 13:00:10 +0200 Message-ID: <43575.933246010@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote: > If noone has any objections, I will commit this and MFC it in a week or so. > > --- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 > +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 |--- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 |+++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 -------------------------- Patching file regular.c using Plan A... Hunk #1 succeeded at 57. Hunk #2 failed at 76. 1 out of 2 hunks failed--saving rejects to regular.c.rej Hmm... Ignoring the trailing garbage. done What's up? :-) 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 29 4: 5: 0 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 24D1F15443; Thu, 29 Jul 1999 04:04:55 -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 HAA15012; Thu, 29 Jul 1999 07:03: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 HAA09965; Thu, 29 Jul 1999 07:03:35 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id HAA68156; Thu, 29 Jul 1999 07:03:34 -0400 (EDT) Date: Thu, 29 Jul 1999 07:03:34 -0400 (EDT) From: Thomas David Rivers Message-Id: <199907291103.HAA68156@lakes.dignus.com> To: green@FreeBSD.ORG, rivers@dignus.com Subject: Re: interesting bug in /usr/bin/cmp Cc: freebsd-hackers@FreeBSD.ORG, jmz@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > > If someone is interested to solve a problem: > > > > > > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null > > > $ cp a b > > > $ cmp a b 0 0x300 > > > Segmentation fault (core dumped) > > > $ cmp a b 0 0x200 > > > cmp: EOF on b > > > $ cmp a b 0x300 0 > > > cmp: EOF on a > > > > > > Jean-Marc > > > > > > > I've seen a similar problem when doing cmp with CD-ROM > > devices (I believe I entered a PR on it.) > > > > I think the problem has to do with cmp's use of mmap(), and > > potential issues there... But, that's just a guess on my part. > > It has to do with mmap(), but not any specific issues with mmap(), just a > bug in its use. > > If noone has any objections, I will commit this and MFC it in a week or so. When I get into work today, I can apply your change and see if it fixes my problem as well. If it works, then, we can close the PR I entered on it... (kern/11969). - 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 29 4:41:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102]) by hub.freebsd.org (Postfix) with ESMTP id 8E93614D5F for ; Thu, 29 Jul 1999 04:41:21 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew53p32.ozemail.com.au [203.108.150.172]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id VAA13420; Thu, 29 Jul 1999 21:39:49 +1000 (EST) Message-ID: <37A03D05.49A89869@atlas.newcastle.edu.au> Date: Thu, 29 Jul 1999 21:37:41 +1000 From: "Jacob A. Hart" X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: John Reynolds~ Cc: freebsd-hackers@freebsd.org Subject: Re: SURVEY: Sound cards that work under FreeBSD References: <14231.33937.454645.22076@hip186.ch.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Reynolds~ wrote: > Survey: > ------- > > 1) The sound card make and model/chipset. Please be as specific as you can with > board rev numbers if possible. Please include wether the card is ISA or PCI. The card is an ISA Creative Labs AWE64. > 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD for > which you can verify that the sound card does/doesn't work (don't include > -BETA or -SNAP releases but dates on -STABLE and -CURRENT branches are > welcome). This card works with 3.1-RELEASE through 3.2-STABLE, and works fine under 4.0-CURRENT too. > 3) Appropriate lines from your kernel config file / PNP setup. i.e. what did > you have to do to get this card working? Did you need patches not committed > to a particular branch (if so URLs would be welcome)? Do you use OSS drivers > instead? I've only ever used the VOXWARE drivers. Kernel options: controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device awe0 at isa? port 0x620 device opl0 at isa? port 0x388 From /boot/kernel.conf: pnp 1 0 os enable irq0 5 drq0 1 drq1 5 port0 0x220 port1 0x330 port2 0x388 pnp 1 1 os disable pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 pnp 1 3 os disable quit > 4) Sample dmesg output for properly configured device. Show the world what > boot messages relate to the device after properly configured. config> pnp 1 0 os enable irq0 5 drq0 1 drq1 5 port0 0x220 port1 0x330 port2 0x388 config> pnp 1 1 os disable config> pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 config> pnp 1 3 os disable config> quit sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: sb0: interrupting at irq 5 sbxvi0 at drq 5 on isa0 snd0: sbmidi0 at port 0x330 on isa0 snd0: awe0 at port 0x620 on isa0 awe0: opl0 at port 0x388 on isa0 snd0: > 5) Miscellaneous notes. State anything "not obvious" to the casual FreeBSD > user. Good examples might be, "volume is 0 by default, use mixer(1) to > adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, not snd0." The default volume/gain settings are *waaay* too high by default. It peaks the input signal on my amplifier and sounds awful. To fix it, I apply the following diff in /usr/src/sys/i386/isa/sound (4.0-CURRENT): *** sb_mixer.h Fri Jan 1 19:18:08 1999 --- sb_mixer.h.new Wed May 5 00:40:34 1999 *************** *** 192,211 **** static unsigned short levels[SOUND_MIXER_NRDEVICES] = { ! 0x5a5a, /* Master Volume */ ! 0x4b4b, /* Bass */ ! 0x4b4b, /* Treble */ ! 0x4b4b, /* FM */ ! 0x4b4b, /* PCM */ ! 0x4b4b, /* PC Speaker */ ! 0x4b4b, /* Ext Line */ 0x1010, /* Mic */ ! 0x4b4b, /* CD */ ! 0x4b4b, /* Recording monitor */ ! 0x4b4b, /* SB PCM */ ! 0x4b4b, /* Recording level */ ! 0x4b4b, /* Input gain */ ! 0x4b4b, /* Input gain */ ! 0x4b4b}; /* Output gain */ #endif /* SM_GAMES */ static unsigned char sb16_recmasks_L[SOUND_MIXER_NRDEVICES] = --- 192,211 ---- static unsigned short levels[SOUND_MIXER_NRDEVICES] = { ! 0x4b4b, /* Master Volume */ ! 0x3232, /* Bass */ ! 0x3232, /* Treble */ ! 0x3232, /* FM */ ! 0x3232, /* PCM */ ! 0x3232, /* PC Speaker */ ! 0x3232, /* Ext Line */ 0x1010, /* Mic */ ! 0x3232, /* CD */ ! 0x0000, /* Recording monitor */ ! 0x3232, /* SB PCM */ ! 0x3232, /* Recording level */ ! 0x3232, /* Input gain */ ! 0x3232}; /* Output gain */ #endif /* SM_GAMES */ static unsigned char sb16_recmasks_L[SOUND_MIXER_NRDEVICES] = > 6) Is it OK to publish your e-mail address / name as the contributor of this > information? You may type in an anti-spam version of your e-mail address > below if you would like that option instead. Yep, that's fine by me. Please note, though, that the PNP configuration in section (3) was information gained through the lists. I can't remember the poster's name, unfortunately. > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | John Reynolds CEG, CCE, Next Generation Flows, HLA | > | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 868-6512 | > | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au 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 29 5: 6:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 3397815590 for ; Thu, 29 Jul 1999 05:06:28 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with SMTP id NAA16479; Thu, 29 Jul 1999 13:05:00 +0100 (BST) (envelope-from arg@arg1.demon.co.uk) Date: Thu, 29 Jul 1999 13:04:59 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: John Baldwin Cc: hackers@FreeBSD.ORG Subject: Re: Linear buffers in VESA screen modes In-Reply-To: <199907290114.VAA27141@smtp2.erols.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, 28 Jul 1999, John Baldwin wrote: > On 29-Jul-99 Andrew Gordon wrote: > > > > Sure. It's rather crude at present, but I've put it up at: > > > > http://www.arg1.demon.co.uk/vesatv.c > > My wincast tv card seemed to work w/o your patch to vesa.c. Although I don't > think it set the resolution right. I need to get to somewhere that I can get > to more than just static though. :) Are you running -current? It was pointed out to me that -current already contains code equivalent to my patch for -stable (I must have been blind when I looked at the cvs diff and didn't see it). On your 'resolution' problem, did you change it for NTSC? My code is hard-wired for PAL and the WEUROPE channel set on the tuner - changes for NTSC should be obvious. > Once I do, I may try and add some support for changing channels and what not, > if you don't mind. Do whatever you like! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 5:20: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 267AB1547B for ; Thu, 29 Jul 1999 05:20:36 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id VAA17554; Thu, 29 Jul 1999 21:20:03 +0900 (JST) Message-ID: <37A04635.59E74FF6@newsguy.com> Date: Thu, 29 Jul 1999 21:16:53 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Tim Vanderhoek Cc: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <379F3701.F79E10DF@newsguy.com> <19990728191531.A318@mad> 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 Tim Vanderhoek wrote: > > On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote: > > > > Sorry, but a simplistic analysis like that just won't cut for grep. > > The algorithmic complexity is highly relevant here. Try this: > > Algorithmic complexity!?! Yup. > It's a freaking grep application. There is no freaking algorithmic > complexity. Pattern matching is one of the prime examples of algorithmic complexity. You can add complexity very trivially. > At least not outside of our regex library, anyways. I had not looked at the source, so I didn't know exactly how the application did it's stuff. Now I did, and I'll comment. Let's say the number of patterns is N, and the total number of characters to be examined is S. Let's call the "unmodified" complexity C, just for the sake of simplifying comparision using a dangerous simplification. First, the new grep uses fgetln(). fgetln() searches for a new line. So each character is examined (at least) twice. That's C+S*read already. GNU Grep uses mmap() (or read(), but not in FreeBSD), so it doesn't incur in this additional complexity. Also, fgetln() will copy the line buffer from time to time, though that's not a simple computation, and probably of little significance. In addition to that, the new grep copies the fgrepln() result each time. Add S*copy to C. Next, the new grep tests the lines against each pattern separately! GNU grep doesn't. That's just *outside* the regexp library. Now, whether the complexity is inside or outside the regexp library, I don't care. It's complexity all the same. So it *must* be factored in. > The test you > suggested doesn't show anything about that algorithmic complexity, > though. Yeah? Try to back that with the results of the tests I suggested. > If we have a slow regex library, though, I would consider that a > separate problem from a slow grep. If the f*cking grep is f*cking slow, I don't give a f*ck where the problem is located! It just *IS*. GNU grep uses gnu regexp library, the new grep uses our own. If changing greps means changing to a library whose algorithm complexity is greater, then that *DOES* count against the change. For instance, a quick browse over GNU greps shows the gnu regexp library can factor in multiple patterns. That is not being done by the new grep. Does our regexp library support that? Now, here is a quick and dirty fix for the repeated malloc()/free(). Notice that this is what fgetln() does, in fact. I'm afraid, though, that's this is not anywhere near what would be needed by far to put the new grep anywhere near the league of GNU grep. I like the idea of a readable code, I like the idea of a BSD license, but it would be damn silly to replace a clearly superior grep, and that's where the thing stands right now. --- util.c.orig Thu Jul 29 19:14:17 1999 +++ util.c Thu Jul 29 20:49:16 1999 @@ -107,6 +107,8 @@ ln.file = fn; ln.line_no = 0; + ln.bufsize = 81; /* Magical constants, yeah! */ + ln.dat = grep_malloc(81); linesqueued = 0; if (Bflag > 0) @@ -115,11 +117,14 @@ ln.off = grep_tell(); if ((tmp = grep_getln(&ln.len)) == NULL) break; - ln.dat = grep_malloc(ln.len + 1); + if (ln.bufsize < ln.len + 1) + ln.dat = grep_realloc(ln.dat, ln.len + 1); memcpy(ln.dat, tmp, ln.len); - ln.dat[ln.len] = 0; if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') ln.dat[--ln.len] = 0; + else + ln.dat[ln.len] = 0; + ln.line_no++; z = tail; @@ -127,9 +132,9 @@ enqueue(&ln); linesqueued++; } - free(ln.dat); c += t; } + free(ln.dat); if (Bflag > 0) clearqueue(); grep_close(); --- grep.h.orig Thu Jul 29 20:47:52 1999 +++ grep.h Thu Jul 29 20:48:34 1999 @@ -35,6 +35,7 @@ typedef struct { size_t len; + size_t bufsize; int line_no; int off; char *file; -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 5:56:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10]) by hub.freebsd.org (Postfix) with ESMTP id 5F1DC14DD3; Thu, 29 Jul 1999 05:56:17 -0700 (PDT) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.9.0/8.9.0) id OAA05610; Thu, 29 Jul 1999 14:57:58 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199907291257.OAA05610@oskar.nanoteq.co.za> Subject: if.c and ifconf() possible error ? To: freebsd-hackers@freebsd.org Date: Thu, 29 Jul 1999 14:57:52 +0200 (SAT) Cc: phk@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ... When a program calls the SIOCGIFCONF ioctl and the function ifconf in sys/net/if.c is executed, the value that is returned in ifc.ifc_len, is that the value of the amount of data filled in ... or can it be larger ?? Example ... The calling process sends 1000 as the size of the buffer. ifconf loops through the number of interfaces and sees that there are more interfaces than can fit into this buffer. It then fills the buffer to 960 bytes fulle and the one of the checks fail ... should ifconf return the value 960 in ifc.ifc_len or should it return 1000 ?? The reason I ask .. it seems like it returns 1000 rather than 960 ... this causes sendmail to think that there is still another device in the list ... it tries to read this ... and it gets a structure with a lot of zero's (because ifconf rightly so didn't fill it in) but the next one causes a segmentation fault in sendmails conf.c in the function load_if_names. This ONLY happens with sendmail and if you have more than 230 odd onterfaces configured in your kernel AND NO interfaces are ifconfiged e.g. all are deleted. If you increase the value given by sendmail to the SIOCGIFCONF call (a bigger buffer) everything works fine. If it is the job of the ifconf function to return the correct value in ifc.ifc_len, I've included a patch below which causes the ifconf function to return only how much it filled into the buffer and nothing more. It fixes the problem with sendmail (actually newaliases). Please check the changes as I haven't tested every possible senario. Thanx Reinier *** if.c.orig Thu Jul 29 14:30:11 1999 --- if.c Thu Jul 29 14:34:45 1999 *************** *** 814,820 **** register struct ifnet *ifp = ifnet.tqh_first; register struct ifaddr *ifa; struct ifreq ifr, *ifrp; ! int space = ifc->ifc_len, error = 0; ifrp = ifc->ifc_req; for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) { --- 814,820 ---- register struct ifnet *ifp = ifnet.tqh_first; register struct ifaddr *ifa; struct ifreq ifr, *ifrp; ! int space = ifc->ifc_len, error = 0, unused = 0; ifrp = ifc->ifc_req; for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) { *************** *** 857,862 **** --- 857,864 ---- sizeof (ifr)); ifrp++; } else { + /* keep the value of unused space so far */ + unused = space; space -= sa->sa_len - sizeof(*sa); if (space < sizeof (ifr)) break; *************** *** 871,879 **** if (error) break; space -= sizeof (ifr); } } ! ifc->ifc_len -= space; return (error); } --- 873,883 ---- if (error) break; space -= sizeof (ifr); + /* reset the unused space to zero */ + unused = 0; } } ! ifc->ifc_len -= space + unused; return (error); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 6: 9:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from grisu.bik-gmbh.de (grisu.bik-gmbh.de [194.233.237.82]) by hub.freebsd.org (Postfix) with ESMTP id 69CA614D60 for ; Thu, 29 Jul 1999 06:05:43 -0700 (PDT) (envelope-from cracauer@counter.bik-gmbh.de) Received: from counter.bik-gmbh.de (counter.bik-gmbh.de [194.233.237.131]) by grisu.bik-gmbh.de (8.8.8/8.6.9) with ESMTP id PAA21951; Thu, 29 Jul 1999 15:04:50 +0200 (MEST) Received: (from cracauer@localhost) by counter.bik-gmbh.de (8.9.3/8.8.8) id PAA09886; Thu, 29 Jul 1999 15:03:57 +0200 (CEST) (envelope-from cracauer) Date: Thu, 29 Jul 1999 15:03:56 +0200 From: Martin Cracauer To: Rayson Ho Cc: freebsd-hackers@FreeBSD.ORG Subject: BSDI Pthread + gdb (Re: Free BSDI CD!) Message-ID: <19990729150356.A9848@cons.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Rayson Ho on Tue, Jul 27, 1999 at 03:07:01PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In , Rayson Ho wrote: > Hi, > > I am not sure whether this is known to this list or > not, but here is the URL for ordering: > > http://www.bsdi.com/products/evalcd/ The thing that gets my attention is the gdb with threads support. Surely they need to provide source for the GPL gdb. Anyone knows what kind of Pthread library/kernel support they have? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer/ "Where do you want to do today?" Hard to tell running your calendar program on a junk operating system, eh? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 6:19:21 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 92A7C150CF for ; Thu, 29 Jul 1999 06:19:06 -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 119q5F-000BaF-00 for hackers@freebsd.org; Thu, 29 Jul 1999 15:18:53 +0200 From: Sheldon Hearn To: hackers@freebsd.org Subject: No MAXUID ? Date: Thu, 29 Jul 1999 15:18:51 +0200 Message-ID: <44527.933254331@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I've come up empty-handed hunting for a constant that defines the maximum UID supported by the system. I'm working on our passwd and pwd_mkdb stuff and want to get rid of the artificial limitation of 65535 (USHRT_MAX) imposed in (at least) pwd_mkdb. Have I missed a useful define, or should I add one? If I should add one, does it go in pwd.h, types.h or syslimits.h? Thanks, 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 29 7:24:35 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 C7F7A155C0 for ; Thu, 29 Jul 1999 07:24:33 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA14680; Thu, 29 Jul 1999 23:23:40 +0900 (JST) Message-ID: <37A05F22.5AA2D27D@newsguy.com> Date: Thu, 29 Jul 1999 23:03:14 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: MADV_SEQUENTIAL and GNU Grep References: <199907290439.XAA69977@celery.dragondata.com> <199907290445.VAA66252@apollo.backplane.com> 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 Matthew Dillon wrote: > > MADV_SEQUENTIAL *WILL* work. It changes the page fault > read-behind/read-ahead. Normally the VM system reads behind a bit as well > as reads ahead. If you set MADV_SEQUENTIAL it shifts to just doing > read-ahead, and it does more of it. So it works, then? GNU grep has this #ifdef'ed out, with a comment about it impacting negatively on performance on BSD 4.1. I recall some rants on this subject a couple of years ago... If it is working, I'd like to change that 0 to 1 in our tree. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 7:26: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 2C82414E4E; Thu, 29 Jul 1999 07:26: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 KAA13939; Thu, 29 Jul 1999 10:25:31 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 29 Jul 1999 10:25:31 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: Thomas David Rivers , freebsd-hackers@FreeBSD.org, jmz@FreeBSD.org Subject: Re: interesting bug in /usr/bin/cmp In-Reply-To: <43575.933246010@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 Thu, 29 Jul 1999, Sheldon Hearn wrote: > > > On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote: > > > If noone has any objections, I will commit this and MFC it in a week or so. > > > > --- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 > > +++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 > > |--- src/usr.bin/cmp/regular.c.orig Thu Jul 29 00:43:50 1999 > |+++ src/usr.bin/cmp/regular.c Thu Jul 29 00:44:54 1999 > -------------------------- > Patching file regular.c using Plan A... > Hunk #1 succeeded at 57. > Hunk #2 failed at 76. > 1 out of 2 hunks failed--saving rejects to regular.c.rej > Hmm... Ignoring the trailing garbage. > done > > What's up? :-) > I have a better version. It's much more proper. Index: src/usr.bin/cmp/regular.c =================================================================== RCS file: /home/ncvs/src/usr.bin/cmp/regular.c,v retrieving revision 1.6 diff -u -r1.6 regular.c --- regular.c 1999/04/25 22:37:57 1.6 +++ regular.c 1999/07/29 14:20:23 @@ -60,6 +60,7 @@ off_t byte, length, line; int dfound; off_t pagemask, off1, off2; + size_t pagesize; if (sflag && len1 != len2) exit(1); @@ -71,7 +72,8 @@ eofmsg(file2); len2 -= skip2; - pagemask = (off_t)getpagesize() - 1; + pagesize = getpagesize(); + pagemask = (off_t)pagesize - 1; off1 = ROUNDPAGE(skip1); off2 = ROUNDPAGE(skip2); @@ -79,15 +81,15 @@ if (length > SIZE_T_MAX) return (c_special(fd1, file1, skip1, fd2, file2, skip2)); - if ((p1 = (u_char *)mmap(NULL, - (size_t)length, PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) + if ((p1 = (u_char *)mmap(NULL, (size_t)len1 + skip1 % pagesize, + PROT_READ, MAP_SHARED, fd1, off1)) == (u_char *)MAP_FAILED) err(ERR_EXIT, "%s", file1); - madvise(p1, length, MADV_SEQUENTIAL); - if ((p2 = (u_char *)mmap(NULL, - (size_t)length, PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) + madvise(p1, len1 + skip1 % pagesize, MADV_SEQUENTIAL); + if ((p2 = (u_char *)mmap(NULL, (size_t)len2 + skip2 % pagesize, + PROT_READ, MAP_SHARED, fd2, off2)) == (u_char *)MAP_FAILED) err(ERR_EXIT, "%s", file2); - madvise(p2, length, MADV_SEQUENTIAL); + madvise(p2, len2 + skip2 % pagesize, MADV_SEQUENTIAL); dfound = 0; p1 += skip1 - off1; > Ciao, > Sheldon. > > > 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 29 7:57: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id BC7FD14E98 for ; Thu, 29 Jul 1999 07:56:48 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.224] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 119rbI-0004GF-00; Thu, 29 Jul 1999 08:56:07 -0600 Message-ID: <37A06B6B.B5BF74CF@softweyr.com> Date: Thu, 29 Jul 1999 08:55: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: Nik Clayton Cc: hackers@FreeBSD.ORG Subject: Re: Documenting writev(2) ENOBUFS error References: <19990728170119.A47890@kilt.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > > -hackers, > > Could someone who knows write/writev(2) take a quick look at docs/10512. > > In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR) > if you "exhaust writev'able buffer space". This doesn't mean a great > deal to me, and I'm hoping one of you can take a look at come up with a > phrasing suitable for a man page. How does this look: [ENOBUFS] Insufficient system buffer space exists to complete the op- eration. Here's the patch against -current: --- write.2 Tue Jul 13 06:53:41 1999 +++ /home/wes/src/write.2 Thu Jul 29 08:49:54 1999 @@ -242,6 +242,8 @@ values in the .Fa iov array overflowed a 32-bit integer. +.It Bq Er ENOBUFS +Insufficient system buffer space exists to complete the operation. .El .Pp The -- "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 29 8:40:35 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 0C79E14C8F for ; Thu, 29 Jul 1999 08:40:26 -0700 (PDT) (envelope-from eT@KryptoKom.DE) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id TAA06032 for ; Thu, 29 Jul 1999 19:39:54 +0200 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa06026; Thu Jul 29 19:39:31 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 RAA16355 for ; Thu, 29 Jul 1999 17:45:58 +0200 Received: from kryptokom.de (localhost [127.0.0.1]) by borg.kryptokom.de (8.8.8/8.8.8) with ESMTP id SAA29642 for ; Thu, 29 Jul 1999 18:07:54 +0200 (CEST) (envelope-from eT@kryptokom.de) Message-ID: <37A07C58.D7E97962@kryptokom.de> Date: Thu, 29 Jul 1999 18:07:53 +0200 From: eT X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-19980804-SNAP i386) X-Accept-Language: en MIME-Version: 1.0 To: Hackers FreeBSD Subject: Changing Interface IP address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to change the IP address (netmask, gateway etc.) of an Interface (eg. fxp0) from within my C source code. 1. Is this possible to do without the SIOC ioctl call? (i am already in the kernel). 2. Which structure and which member should I write the new information to (ifaddr?)? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 8:52: 9 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 F1A851509C for ; Thu, 29 Jul 1999 08:51:58 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id KAA16257; Thu, 29 Jul 1999 10:53:30 -0500 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma015954; Thu, 29 Jul 99 10:52:23 -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, 29 Jul 1999 15:45:51 0000 (GMT) Received: by stlabcexg004.anheuser-busch.com with Internet Mail Service (5.5.2448.0) id ; Thu, 29 Jul 1999 10:45:41 -0500 Message-ID: From: "Alton, Matthew" To: "'Matthew Dillon'" , "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: DOC volunteer WAS:RE: userfs help needed. Date: Thu, 29 Jul 1999 10:45:51 -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 I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought. > -----Original Message----- > From: Matthew Dillon [SMTP:dillon@apollo.backplane.com] > Sent: Wednesday, July 28, 1999 6:31 PM > To: David E. Cross > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: userfs help needed. > > :I am wading through the portalfs and nullfs source, but I am desperately > :lost. I would love to be able to find out who would be willing to help out > :with questions. I feel I would be spamming far too many people by just > sending > :to -hackers. Some of the topics I am curious about are general fs-style > :questions, what the various vop/vfs calls do. Also I would like to know how > :to setup a shared memory segment between kernel and user space (as matt > :dillon suggested). Finally I would like to know how the buffer-cache > interacts > :with the filesystem layer. > : > :Thanks > :-- > :David Cross | email: crossd@cs.rpi.edu > :Systems Administrator/Research Programmer | Web: > http://www.cs.rpi.edu/~crossd > > Ouch. I don't think anyone understands the VOP stuff completely. It's > a big mess -- which is why it's going to be rewritten later this year. > > Your best bet is to study the implementation of the UFS/FFS filesystem. > It may also help to study a more recent filesystem such as coda. > Specifically, > > ufs/ufs/ufs_vfsops.c > ufs/ufs/ufs_vnops.c > ufs/ffs/ffs_vfsops.c > ufs/ffs/ffs_vnops.c > coda/coda_vfsops.c > coda/coda_vnops.c > > What I recommend is that you implement a skeleton that essentially > returns an error for all the call entries and does a kernel printf(), > and then implement the routines one at a time. > > The various VOP calls have different locking requirements and resource > freeing requirements. The most difficult resource to deal with in > the entire subsystem is the struct componentname structure used for > lookup and related ops - all related to namei. That is, the code that > deals with path elements. Generally speaking the VOP code is required > to free a pathname component before returning, but not in all cases. It's > a really odd set of rules and I'd have to review them myself to be able > to explain them. > > -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 Thu Jul 29 9:16:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id ACE9414D6E for ; Thu, 29 Jul 1999 09:16:54 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-87.ucdavis.edu [169.237.16.87]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id JAA22971; Thu, 29 Jul 1999 09:15:57 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA05535; Thu, 29 Jul 1999 09:15:55 -0700 (PDT) (envelope-from obrien) Date: Thu, 29 Jul 1999 09:15:53 -0700 From: "David O'Brien" To: Andy Doran Cc: hackers@FreeBSD.ORG Subject: Re: file(1) Magdir candidate: wintendo Message-ID: <19990729091553.A87213@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <42436.933241093@axl.noc.iafrica.com> <37A03218.422FFF83@netbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37A03218.422FFF83@netbsd.org>; from Andy Doran on Thu, Jul 29, 1999 at 11:51:04AM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My major Duh!! If Christos sees this thread, my apologies. > > David, I was trying to be helpful; sorry if my msg came across wrong. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not in the least. I was being stupid and that's all. I'm certainly not mad about anything. (1) I don't like it when people just toss "facts" off the top of their head w/o making sure they are facts. I went against this. (2) people often get my name wrong, which is slightly irritating, and here I did it to someone else. -- -- David (obrien@NUXI.com -or- obrien@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 29 9:27:52 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 7666514C2D for ; Thu, 29 Jul 1999 09:27:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA74429; Thu, 29 Jul 1999 09:26:12 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 09:26:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291626.JAA74429@apollo.backplane.com> To: "Daniel C. Sobral" Cc: hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907290439.XAA69977@celery.dragondata.com> <199907290445.VAA66252@apollo.backplane.com> <37A05F22.5AA2D27D@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :So it works, then? GNU grep has this #ifdef'ed out, with a comment :about it impacting negatively on performance on BSD 4.1. I recall :some rants on this subject a couple of years ago... If it is :working, I'd like to change that 0 to 1 in our tree. : :-- :Daniel C. Sobral (8-DCS) Yes, it will work. Oops. I do see one problem though... if you do this the underlying file object will be marked for sequential operation even after the grep (in this case) exits. That is, an madvise() of MADV_NORMAL, SEQUENTIAL, or RANDOM appears to have a permanent effect on the object. This is probably not correct behavior. We could probably fix this by moving this particular flag from the object to the vm_entry. -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 29 9:51:49 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 D54C1155D3 for ; Thu, 29 Jul 1999 09:51:36 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA12804; Fri, 30 Jul 1999 01:50:58 +0900 (JST) Message-ID: <37A08653.C43E3AD1@newsguy.com> Date: Fri, 30 Jul 1999 01:50:28 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907290439.XAA69977@celery.dragondata.com> <199907290445.VAA66252@apollo.backplane.com> <37A05F22.5AA2D27D@newsguy.com> <199907291626.JAA74429@apollo.backplane.com> 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 Matthew Dillon wrote: > > Yes, it will work. Oops. I do see one problem though... if you do > this the underlying file object will be marked for sequential operation > even after the grep (in this case) exits. That is, an madvise() of > MADV_NORMAL, SEQUENTIAL, or RANDOM appears to have a permanent effect > on the object. This is probably not correct behavior. We could probably > fix this by moving this particular flag from the object to the vm_entry. .... Could you please elaborate on "permanent"? To what structure the information is currently attached, and what, if anything, can make that structure "go away", short of a reboot? Of course, we could MADV_NORMAL afterwards, though that would require changing more than one character. I'm not sure I'm ready for so much coding... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 10: 0:16 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 EE2C715101 for ; Thu, 29 Jul 1999 10:00:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA74615; Thu, 29 Jul 1999 09:59:25 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 09:59:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291659.JAA74615@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291655.JAA29585@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Fri, 30 Jul 1999 01:50:28 +0900 : "Daniel C. Sobral" wrote: : : > Could you please elaborate on "permanent"? To what structure the : > information is currently attached, and what, if anything, can make : > that structure "go away", short of a reboot? : :As permanent as the object ... i.e. as long as the object persists. : : > Of course, we could MADV_NORMAL afterwards, though that would : > require changing more than one character. I'm not sure I'm ready for : > so much coding... :-) : :No, it's not appropriate to work around a kernel bug in this fashion. : : -- Jason R. Thorpe I'm willing to fix it. If NetBSD has moved it to the map entry then I can move it here without core screaming at me too much, though every time I do any work I have to balance the fun against the frustration of not being able to commit it myself. -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 29 10:22: 2 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 0D6FA150C3 for ; Thu, 29 Jul 1999 10:21:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA75509; Thu, 29 Jul 1999 10:21:52 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 10:21:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291721.KAA75509@apollo.backplane.com> To: Matthew Dillon Cc: Jason Thorpe , "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291655.JAA29585@lestat.nas.nasa.gov> <199907291659.JAA74615@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shoot, it barely took 10 minutes for me to move the behavior field from the object to the vm map entry. I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to make them work on files in a reasonable way). This will be current-only, though I suppose the map changes could be backported to stable if someone really wanted to. -Matt Matthew Dillon ::On Fri, 30 Jul 1999 01:50:28 +0900 :: "Daniel C. Sobral" wrote: :: :: > Could you please elaborate on "permanent"? To what structure the :: > information is currently attached, and what, if anything, can make :: > that structure "go away", short of a reboot? :: ::As permanent as the object ... i.e. as long as the object persists. :: :: > Of course, we could MADV_NORMAL afterwards, though that would :: > require changing more than one character. I'm not sure I'm ready for :: > so much coding... :-) :: ::No, it's not appropriate to work around a kernel bug in this fashion. :: :: -- Jason R. Thorpe : : I'm willing to fix it. If NetBSD has moved it to the map entry then : I can move it here without core screaming at me too much, though every : time I do any work I have to balance the fun against the frustration of : not being able to commit it myself. : -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 10:52:31 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 1FC5C15118 for ; Thu, 29 Jul 1999 10:52:28 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA76835; Thu, 29 Jul 1999 10:52:02 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 10:52:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291752.KAA76835@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291741.KAA00195@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM): : : DONTNEED: deactivate pages There are some medium sized problems with doing this under FreeBSD, mainly that this will cause the pages to recycle through the inactive and cache queues. Without anything to bump the page daemon you can get into a silly-recycle state when the inactive and cache page queues are too small. For example, if you have 64MB of main memory, 50MB active, 5MB inactive, and 8MB cache, and you scan a 16MB file. This file would trivially fit into main memory but the silly-recycle problem causes it to essentially be completely flushed. We also have another problem: By recycling the pages into the inactive queue we essentially flush the inactive & cache queues when scanning very large objects even though it is a complete waste of memory to do so since the whole of the object will go down the drain anyway... it would have been much, much better to cycle the cache in that case and leave the inactive queue intact. I am working on a solution that attempts to slowly balance the paging queues while at the same time optimizing which queue the madvised page is moved to. If we do it right, it should be possible to scan very large objects without destroying the rest of the VM cache. : FREE: don't clean dirty pages, free all pages in range : :It was fairly straightforward in NetBSD. Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects. We do not do this for file objects... it would make me rather nervous if we did :-) : -- Jason R. Thorpe -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 29 11: 5:58 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 7DD7F15106 for ; Thu, 29 Jul 1999 11:05:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA76909; Thu, 29 Jul 1999 11:05:46 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 11:05:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291805.LAA76909@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291756.KAA00408@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Thu, 29 Jul 1999 10:52:02 -0700 (PDT) : Matthew Dillon wrote: : : > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects. : > We do not do this for file objects... it would make me rather nervous : > if we did :-) : :Why? I can think of at least one instance where this is useful: using :a file in the file system as a shared memory handle. I was thinking of adding a flag to mmap() for that, to prevent unnecessary paging. Right now any shared file map will be synced to disk every 30 seconds or so no matter what. I'm not against the idea, but it isn't front and center for me yet, at least not until we fix the syncing problem. There are several people who have already requested a solution to the syncing problem that are currently being forced to use SysV shared memory (and hating it). :Seems as if the programmer erroneously MADV_FREE's a file, well ... you :only supplied the rope. : : -- Jason R. Thorpe -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 29 11:11: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 9EF74150DA for ; Thu, 29 Jul 1999 11:11:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA77015; Thu, 29 Jul 1999 11:11:18 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 11:11:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291811.LAA77015@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291742.KAA00237@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) : Matthew Dillon wrote: : : > Shoot, it barely took 10 minutes for me to move the behavior field from : > the object to the vm map entry. : :...make sure the map entries are clipped properly. It's easy to miss this :in the most common test case of advising the entire mapping. : : -- Jason R. Thorpe I believe the code is doing the right thing. Here is an excerpt from vm_map_madvise() in vm_map.c (with the behavior moved to the map entry): for(current = entry; (current != &map->header) && (current->start < end); current = current->next) { vm_size_t size; if (current->eflags & MAP_ENTRY_IS_SUB_MAP) { continue; } vm_map_clip_end(map, current, end); size = current->end - current->start; ... current->behavior = ... ... -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 29 11:55:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 63E5714BC9 for ; Thu, 29 Jul 1999 11:55:43 -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 KAA00408; Thu, 29 Jul 1999 10:56:25 -0700 (PDT) Message-Id: <199907291756.KAA00408@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 29 Jul 1999 10:56:24 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 10:52:02 -0700 (PDT) Matthew Dillon wrote: > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects. > We do not do this for file objects... it would make me rather nervous > if we did :-) Why? I can think of at least one instance where this is useful: using a file in the file system as a shared memory handle. Seems as if the programmer erroneously MADV_FREE's a file, well ... you only supplied the rope. -- 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 Thu Jul 29 11:55:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id EE08114D37 for ; Thu, 29 Jul 1999 11:55:43 -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 KAA00237; Thu, 29 Jul 1999 10:42:46 -0700 (PDT) Message-Id: <199907291742.KAA00237@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 29 Jul 1999 10:42:45 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) Matthew Dillon wrote: > Shoot, it barely took 10 minutes for me to move the behavior field from > the object to the vm map entry. ...make sure the map entries are clipped properly. It's easy to miss this in the most common test case of advising the entire mapping. -- 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 Thu Jul 29 11:56: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 267EC14D52 for ; Thu, 29 Jul 1999 11:55:43 -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 KAA00195; Thu, 29 Jul 1999 10:41:20 -0700 (PDT) Message-Id: <199907291741.KAA00195@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 29 Jul 1999 10:41:20 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) Matthew Dillon wrote: > I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to > make them work on files in a reasonable way). When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM): DONTNEED: deactivate pages FREE: don't clean dirty pages, free all pages in range It was fairly straightforward in NetBSD. -- 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 Thu Jul 29 11:56: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 3855215185 for ; Thu, 29 Jul 1999 11:55:43 -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 JAA29585; Thu, 29 Jul 1999 09:55:40 -0700 (PDT) Message-Id: <199907291655.JAA29585@lestat.nas.nasa.gov> To: "Daniel C. Sobral" Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 29 Jul 1999 09:55:39 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 01:50:28 +0900 "Daniel C. Sobral" wrote: > Could you please elaborate on "permanent"? To what structure the > information is currently attached, and what, if anything, can make > that structure "go away", short of a reboot? As permanent as the object ... i.e. as long as the object persists. > Of course, we could MADV_NORMAL afterwards, though that would > require changing more than one character. I'm not sure I'm ready for > so much coding... :-) No, it's not appropriate to work around a kernel bug in this fashion. -- 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 Thu Jul 29 11:56: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id D25031560B for ; Thu, 29 Jul 1999 11:55:43 -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 JAA29492; Thu, 29 Jul 1999 09:48:58 -0700 (PDT) Message-Id: <199907291648.JAA29492@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 29 Jul 1999 09:48:57 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999 09:26:12 -0700 (PDT) Matthew Dillon wrote: > Yes, it will work. Oops. I do see one problem though... if you do > this the underlying file object will be marked for sequential operation > even after the grep (in this case) exits. That is, an madvise() of > MADV_NORMAL, SEQUENTIAL, or RANDOM appears to have a permanent effect > on the object. This is probably not correct behavior. We could probably > fix this by moving this particular flag from the object to the vm_entry. In NetBSD, we store advice in the map entry, specifically because two different processes may wish to have different access patterns on the same object. Just a data point. -- 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 Thu Jul 29 11:56:59 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 8BFB71562F for ; Thu, 29 Jul 1999 11:56:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA77471; Thu, 29 Jul 1999 11:56:07 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 11:56:07 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291856.LAA77471@apollo.backplane.com> To: Alan Cox , David Greenman Cc: hackers@FreeBSD.ORG Subject: patch for behavior changes and madvise MADV_DONTNEED References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have tested this on both small and large files and it appears to work extremely well. So well, in fact, that I can have a program which mmap()'s a large file and continuously scans it - generating 4MB/sec of network traffic, with virtually no effect to the rest of the system. I am not finished testing. I will be running buildworlds and other related tests overnight to ensure that no previously fixed bugs have been reintroduced. This patch will probably become the commit candidate tomorrow. There are several things in this patch: * minor readability fix in pmap.c * vm_page_undirty() * madvise() has, in general, been extended to operate on files (except for MADV_FREE) * madvise(... MADV_DONTNEED) has been implemented to avoid starving the VM page queues while at the same time enforcing a slow balancing to deal with both the small-file and the large-file case. If we wanted to we could further optimize this code by modifying vm_page_dontneed(). For example, we could have it ignore pages whos act_count are too large. * #if 0'ing out of apparently unnecessary ufs code (if it winds up being necessary I recommend removing it anyway and making the required changes to vm_fault.c instead). -Matt Matthew Dillon Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.242 diff -u -r1.242 pmap.c --- pmap.c 1999/07/21 18:01:40 1.242 +++ pmap.c 1999/07/21 20:43:00 @@ -3188,7 +3188,7 @@ pte = pmap_pte_quick(pv->pv_pmap, pv->pv_va); - if (pte && *pte & PG_A) { + if (pte && (*pte & PG_A)) { *pte &= ~PG_A; pmap_TLB_invalidate(pv->pv_pmap, pv->pv_va); Index: miscfs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/devfs/devfs_vnops.c,v retrieving revision 1.75 diff -u -r1.75 devfs_vnops.c --- devfs_vnops.c 1999/06/26 02:46:17 1.75 +++ devfs_vnops.c 1999/07/08 22:20:29 @@ -2005,13 +2005,13 @@ if (nextoff <= nread) { m->valid = VM_PAGE_BITS_ALL; - m->dirty = 0; + vm_page_undirty(m); } else if (toff < nread) { int nvalid = ((nread + DEV_BSIZE - 1) - toff) & ~(DEV_BSIZE - 1); vm_page_set_validclean(m, 0, nvalid); } else { m->valid = 0; - m->dirty = 0; + vm_page_undirty(m); } if (i != ap->a_reqpage) { Index: miscfs/specfs/spec_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v retrieving revision 1.90 diff -u -r1.90 spec_vnops.c --- spec_vnops.c 1999/07/20 09:47:45 1.90 +++ spec_vnops.c 1999/07/21 05:50:06 @@ -860,7 +860,7 @@ if (nextoff <= nread) { m->valid = VM_PAGE_BITS_ALL; - m->dirty = 0; + vm_page_undirty(m); } else if (toff < nread) { /* * Since this is a VM request, we have to supply the @@ -870,7 +870,7 @@ vm_page_set_validclean(m, 0, nread - toff); } else { m->valid = 0; - m->dirty = 0; + vm_page_undirty(m); } if (i != ap->a_reqpage) { Index: nfs/nfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_bio.c,v retrieving revision 1.74 diff -u -r1.74 nfs_bio.c --- nfs_bio.c 1999/06/26 02:46:29 1.74 +++ nfs_bio.c 1999/07/08 22:21:48 @@ -185,7 +185,7 @@ * Read operation filled an entire page */ m->valid = VM_PAGE_BITS_ALL; - m->dirty = 0; + vm_page_undirty(m); } else if (size > toff) { /* * Read operation filled a partial page. @@ -313,7 +313,7 @@ int nwritten = round_page(count - uio.uio_resid) / PAGE_SIZE; for (i = 0; i < nwritten; i++) { rtvals[i] = VM_PAGER_OK; - pages[i]->dirty = 0; + vm_page_undirty(pages[i]); } if (must_commit) nfs_clearcommit(vp->v_mount); Index: ufs/ufs/ufs_readwrite.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_readwrite.c,v retrieving revision 1.61 diff -u -r1.61 ufs_readwrite.c --- ufs_readwrite.c 1999/07/25 02:07:16 1.61 +++ ufs_readwrite.c 1999/07/29 17:40:14 @@ -591,6 +591,7 @@ if (firstindex == 0) vp->v_lastr = 0; +#if 0 if (((obj->behavior != OBJ_RANDOM) && (firstindex != 0) && (firstindex <= vp->v_lastr) && ((firstindex + pcount) > vp->v_lastr)) || @@ -652,6 +653,7 @@ vm_page_zero_invalid(mreq, TRUE); return VM_PAGER_OK; } +#endif /* * foff is the file offset of the required page @@ -670,7 +672,7 @@ if (reqblkno == -1) { if ((mreq->flags & PG_ZERO) == 0) vm_page_zero_fill(mreq); - mreq->dirty = 0; + vm_page_undirty(mreq); mreq->valid = VM_PAGE_BITS_ALL; return VM_PAGER_OK; } else { Index: vm/swap_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.121 diff -u -r1.121 swap_pager.c --- swap_pager.c 1999/07/16 05:11:35 1.121 +++ swap_pager.c 1999/07/29 18:24:33 @@ -1631,7 +1631,7 @@ pmap_clear_modify(VM_PAGE_TO_PHYS(m)); m->valid = VM_PAGE_BITS_ALL; - m->dirty = 0; + vm_page_undirty(m); vm_page_flag_clear(m, PG_ZERO); /* @@ -1656,7 +1656,7 @@ */ vm_page_protect(m, VM_PROT_READ); pmap_clear_modify(VM_PAGE_TO_PHYS(m)); - m->dirty = 0; + vm_page_undirty(m); vm_page_io_finish(m); } } Index: vm/vm_fault.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_fault.c,v retrieving revision 1.103 diff -u -r1.103 vm_fault.c --- vm_fault.c 1999/07/20 05:46:56 1.103 +++ vm_fault.c 1999/07/29 17:43:07 @@ -386,7 +386,7 @@ int reqpage; int ahead, behind; - if (fs.first_object->behavior == OBJ_RANDOM) { + if (fs.entry->behavior == BEHAV_RANDOM) { ahead = 0; behind = 0; } else { @@ -400,7 +400,7 @@ } if ((fs.first_object->type != OBJT_DEVICE) && - (fs.first_object->behavior == OBJ_SEQUENTIAL)) { + (fs.entry->behavior == BEHAV_SEQUENTIAL)) { vm_pindex_t firstpindex, tmppindex; if (fs.first_pindex < 2*(VM_FAULT_READ_BEHIND + VM_FAULT_READ_AHEAD + 1)) Index: vm/vm_map.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_map.c,v retrieving revision 1.173 diff -u -r1.173 vm_map.c --- vm_map.c 1999/07/21 18:02:27 1.173 +++ vm_map.c 1999/07/29 17:44:43 @@ -1051,13 +1051,13 @@ switch (advise) { case MADV_NORMAL: - current->object.vm_object->behavior = OBJ_NORMAL; + current->behavior = BEHAV_NORMAL; break; case MADV_SEQUENTIAL: - current->object.vm_object->behavior = OBJ_SEQUENTIAL; + current->behavior = BEHAV_SEQUENTIAL; break; case MADV_RANDOM: - current->object.vm_object->behavior = OBJ_RANDOM; + current->behavior = BEHAV_RANDOM; break; /* * Right now, we could handle DONTNEED and WILLNEED with common code. Index: vm/vm_map.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_map.h,v retrieving revision 1.43 diff -u -r1.43 vm_map.h --- vm_map.h 1999/07/10 18:16:08 1.43 +++ vm_map.h 1999/07/29 17:41:46 @@ -89,6 +89,10 @@ struct vm_map *sub_map; /* belongs to another map */ }; +#define BEHAV_NORMAL 0x0 /* default behavior */ +#define BEHAV_SEQUENTIAL 0x1 /* expect sequential accesses */ +#define BEHAV_RANDOM 0x2 /* expect random accesses */ + /* * Address map entries consist of start and end addresses, * a VM object (or sharing map) and offset into that object, @@ -102,6 +106,8 @@ vm_offset_t end; /* end address */ vm_offset_t avail_ssize; /* amt can grow if this is a stack */ union vm_map_object object; /* object I point to */ + u_short behavior; /* fault behavior */ + u_short unused3; /* (filler) */ vm_ooffset_t offset; /* offset into object */ u_char eflags; /* map entry flags */ /* Only in task maps: */ Index: vm/vm_object.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_object.c,v retrieving revision 1.160 diff -u -r1.160 vm_object.c --- vm_object.c 1999/07/16 05:11:36 1.160 +++ vm_object.c 1999/07/29 17:19:05 @@ -154,7 +154,9 @@ object->flags = 0; if ((object->type == OBJT_DEFAULT) || (object->type == OBJT_SWAP)) vm_object_set_flag(object, OBJ_ONEMAPPING); +#if 0 object->behavior = OBJ_NORMAL; +#endif object->paging_in_progress = 0; object->resident_page_count = 0; object->shadow_count = 0; @@ -735,12 +737,22 @@ * vm_object_madvise: * * Implements the madvise function at the object/page level. + * + * MADV_WILLNEED (any map) + * + * Force activation of the page if it is found in-core + * + * MADV_DONTNEED (any map) + * + * Deactivate or cache the page as appropriate. * - * Currently, madvise() functions are limited to the default and - * swap object types only, and also limited to only the unshared portions - * of a process's address space. MADV_FREE, certainly, could never be - * run on anything else. The others are more flexible and the code could - * be adjusted in the future to handle expanded cases for them. + * MADV_FREE (OBJT_DEFAULT or OBJT_SWAP maps, OBJ_ONEMAPPING only) + * + * essentially free the underlying storage. We mark the storage + * clean but do not unmap it from the process, allowing the process + * to reuse the storage (by dirtying it again) as well as allowing + * the VM system to reuse it for other purpose, turning it back into + * zero-fill. */ void vm_object_madvise(object, pindex, count, advise) @@ -768,20 +780,26 @@ tpindex = pindex; shadowlookup: - if (tobject->type != OBJT_DEFAULT && - tobject->type != OBJT_SWAP - ) { - continue; - } + /* + * MADV_FREE only operates OBJT_DEFAULT or OBJT_SWAP pages + * and those pages must be OBJ_ONEMAPPING. + */ - if ((tobject->flags & OBJ_ONEMAPPING) == 0) - continue; + if (advise == MADV_FREE) { + if ((tobject->type != OBJT_DEFAULT && + tobject->type != OBJT_SWAP) || + (tobject->type & OBJ_ONEMAPPING) == 0 + ) { + continue; + } + } m = vm_page_lookup(tobject, tpindex); if (m == NULL) { /* - * There may be swap even if there is no backing page + * There may be swap in an intermediate object even + * if there is no backing page, deal with it here. */ if (advise == MADV_FREE && tobject->type == OBJT_SWAP) swap_pager_freespace(tobject, tpindex, 1); @@ -813,9 +831,17 @@ goto relookup; if (advise == MADV_WILLNEED) { + /* + * Activate the page early to reduce the chance of + * it being reused before the program accesses it. + */ vm_page_activate(m); } else if (advise == MADV_DONTNEED) { - vm_page_deactivate(m); + /* + * Deactivate, cache, or do nothing to the page + * as appropriate. + */ + vm_page_dontneed(m); } else if (advise == MADV_FREE) { /* * Mark the page clean. This will allow the page @@ -833,7 +859,7 @@ * it. */ pmap_clear_modify(VM_PAGE_TO_PHYS(m)); - m->dirty = 0; + vm_page_undirty(m); m->act_count = 0; vm_page_deactivate(m); if (tobject->type == OBJT_SWAP) Index: vm/vm_object.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_object.h,v retrieving revision 1.58 diff -u -r1.58 vm_object.h --- vm_object.h 1999/07/16 05:11:37 1.58 +++ vm_object.h 1999/07/29 17:13:33 @@ -98,7 +98,7 @@ u_short flags; /* see below */ u_short pg_color; /* color of first page in obj */ u_short paging_in_progress; /* Paging (in or out) so don't collapse or destroy */ - u_short behavior; /* see below */ + u_short unused13; int resident_page_count; /* number of resident pages */ struct vm_object *backing_object; /* object that I'm a shadow of */ vm_ooffset_t backing_object_offset;/* Offset in backing object */ @@ -148,10 +148,6 @@ #define OBJ_CLEANING 0x0200 #define OBJ_OPT 0x1000 /* I/O optimization */ #define OBJ_ONEMAPPING 0x2000 /* One USE (a single, non-forked) mapping flag */ - -#define OBJ_NORMAL 0x0 /* default behavior */ -#define OBJ_SEQUENTIAL 0x1 /* expect sequential accesses */ -#define OBJ_RANDOM 0x2 /* expect random accesses */ #define IDX_TO_OFF(idx) (((vm_ooffset_t)(idx)) << PAGE_SHIFT) #define OFF_TO_IDX(off) ((vm_pindex_t)(((vm_ooffset_t)(off)) >> PAGE_SHIFT)) Index: vm/vm_page.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_page.c,v retrieving revision 1.134 diff -u -r1.134 vm_page.c --- vm_page.c 1999/07/01 19:53:42 1.134 +++ vm_page.c 1999/07/29 18:29:35 @@ -862,6 +862,10 @@ m->busy = 0; m->valid = 0; m->dirty = 0; +#if 0 + /* FUTURE */ + KASSERT(m->dirty == 0, ("vm_page_alloc: free/cache page %p was dirty", m)); +#endif m->queue = PQ_NONE; /* @@ -997,6 +1001,8 @@ * vm_page_activate: * * Put the specified page on the active list (if appropriate). + * Ensure that act_count is at least ACT_INIT but do not otherwise + * mess with it. * * The page queues must be locked. * This routine may not block. @@ -1119,6 +1125,7 @@ } m->valid = 0; + vm_page_undirty(m); if (m->wire_count != 0) { #if !defined(MAX_PERF) @@ -1347,6 +1354,67 @@ } /* + * vm_page_dontneed + * + * Cache, deactivate, or do nothing as appropriate. This routine + * is typically used by madvise() MADV_DONTNEED. + * + * Generally speaking we want to move the page into the cache so + * it gets reused quickly. However, this can result in a silly syndrome + * due to the page recycling too quickly. Small objects will not be + * fully cached. On the otherhand, if we move the page to the inactive + * queue we wind up with a problem whereby very large objects + * unnecessarily blow away our inactive and cache queues. + * + * The solution is to move the pages based on a fixed weighting. We + * either leave them alone, deactivate them, or move them to the cache, + * where moving them to the cache has the highest weighting. + * By forcing some pages into other queues we eventually force the + * system to balance the queues, potentially recovering other unrelated + * space from active. The idea is to not force this to happen too + * often. + */ + +void +vm_page_dontneed(m) + vm_page_t m; +{ + static int dnweight; + int dnw; + + dnw = ++dnweight; + + /* + * Just adjust act_count and do not otherwise mess with the page + * if it is already on the inactive or cache queues, and for one + * page out of every 32. + */ + + if ((dnw & 31) == 0 || + m->queue == PQ_INACTIVE || + m->queue - m->pc != PQ_CACHE + ) { + if (m->act_count > 0) + --m->act_count; + return; + } + + vm_page_test_dirty(m); + + if ((dnw & 7) == 0 || m->dirty) { + /* + * Deactivate the page 3 times out of 32. + */ + vm_page_deactivate(m); + } else { + /* + * Cache the page 28 times out of every 32. + */ + vm_page_cache(m); + } +} + +/* * Grab a page, waiting until we are waken up due to the page * changing state. We keep on waiting, if the page continues * to be in the object. If the page doesn't exist, allocate it. @@ -1778,6 +1846,10 @@ m->valid = VM_PAGE_BITS_ALL; m->flags = 0; m->dirty = 0; +#if 0 + /* future */ + KASSERT(m->dirty == 0, ("ctgmalloc1: page %p was dirty", m)); +#endif m->wire_count = 0; m->busy = 0; m->queue = PQ_NONE; Index: vm/vm_page.h =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_page.h,v retrieving revision 1.63 diff -u -r1.63 vm_page.h --- vm_page.h 1999/07/22 06:04:17 1.63 +++ vm_page.h 1999/07/29 06:38:23 @@ -376,6 +376,7 @@ vm_page_t vm_page_alloc __P((vm_object_t, vm_pindex_t, int)); vm_page_t vm_page_grab __P((vm_object_t, vm_pindex_t, int)); void vm_page_cache __P((register vm_page_t)); +void vm_page_dontneed __P((register vm_page_t)); static __inline void vm_page_copy __P((vm_page_t, vm_page_t)); static __inline void vm_page_free __P((vm_page_t)); static __inline void vm_page_free_zero __P((vm_page_t)); @@ -555,6 +556,18 @@ { KASSERT(m->queue - m->pc != PQ_CACHE, ("vm_page_dirty: page in cache!")); m->dirty = VM_PAGE_BITS_ALL; +} + +/* + * vm_page_undirty: + * + * Set page to not be dirty. Note: does not clear pmap modify bits + */ + +static __inline void +vm_page_undirty(vm_page_t m) +{ + m->dirty = 0; } static __inline vm_page_t Index: vm/vm_pageout.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v retrieving revision 1.144 diff -u -r1.144 vm_pageout.c --- vm_pageout.c 1999/07/04 00:25:37 1.144 +++ vm_pageout.c 1999/07/13 05:47:33 @@ -425,7 +425,7 @@ * worked. */ pmap_clear_modify(VM_PAGE_TO_PHYS(mt)); - mt->dirty = 0; + vm_page_undirty(mt); break; case VM_PAGER_ERROR: case VM_PAGER_FAIL: Index: vm/vnode_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v retrieving revision 1.112 diff -u -r1.112 vnode_pager.c --- vnode_pager.c 1999/07/01 19:53:43 1.112 +++ vnode_pager.c 1999/07/08 22:27:33 @@ -511,7 +511,7 @@ vm_pager_unmap_page(kva); } pmap_clear_modify(VM_PAGE_TO_PHYS(m)); - m->dirty = 0; + vm_page_undirty(m); vm_page_flag_clear(m, PG_ZERO); if (!error) m->valid = VM_PAGE_BITS_ALL; @@ -773,7 +773,7 @@ * Read filled up entire page. */ mt->valid = VM_PAGE_BITS_ALL; - mt->dirty = 0; + vm_page_undirty(mt); /* should be an assert? XXX */ pmap_clear_modify(VM_PAGE_TO_PHYS(mt)); } else { /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 11:59:20 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 8298815114 for ; Thu, 29 Jul 1999 11:59:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA77496; Thu, 29 Jul 1999 11:58:24 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 11:58:24 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291858.LAA77496@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: MADV_SEQUENTIAL and GNU Grep References: <199907291756.KAA00408@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Why? I can think of at least one instance where this is useful: using :a file in the file system as a shared memory handle. : :Seems as if the programmer erroneously MADV_FREE's a file, well ... you :only supplied the rope. : : -- Jason R. Thorpe My main worry here, putting it into words, is that malloc() uses MADV_FREE all over the place. If a program gets corrupted due to bugs in the program and winds up corrupting malloc, I worry that the result could be bogus madvise() calls that destroy mmap()'d files that the program happens to be using at the time. It may not be a justifiable worry, but it is enough that I am not gung-ho about implementing MADV_FREE on file mmaps. -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 29 12:10: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 2664615685 for ; Thu, 29 Jul 1999 12:10:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA77624; Thu, 29 Jul 1999 12:09:42 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 12:09:42 -0700 (PDT) From: Matthew Dillon Message-Id: <199907291909.MAA77624@apollo.backplane.com> To: Alan Cox , David Greenman , hackers@FreeBSD.ORG Subject: Re: patch for behavior changes and madvise MADV_DONTNEED References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : extremely well. So well, in fact, that I can have a program which : mmap()'s a large file and continuously scans it - generating 4MB/sec of : network traffic, with virtually no effect to the rest of the system. Oh, clarification: continuously scans it but also calls madvise(... MADV_DONTNEED) on the pages once it is through, that is. If you mmap and scan a file without any madvise's it still loads the system down just like it always has. The program below simulates scanning a file sequentially via a mmap which also uses the MADV_DONTNEED feature. I did find one disadvantage to my patch - easily fixed (not enough to generate a new patch before this one goes in) - and that is by moving pages to the cache a lot of unnecessary page faults can be incurred. What we want to do, in fact, is for the pages we would normally move to the cache we instead move to the *head* of the inactive list (rather then the tail, which is what normally happens). This disadvantage becomes apparent when you run the below program on a small file that easily fits in main memory. -Matt #include #include #include #include #include #include #include #include volatile char c; int main(int ac, char **av) { int fd; int i; int j; int pgsize = getpagesize(); int pgmask = pgsize - 1; char *ptr; struct stat st; if (ac == 1) { printf("%s filename\n", av[0]); exit(1); } if ((fd = open(av[1], O_RDONLY)) < 0) { perror("open"); exit(1); } fstat(fd, &st); ptr = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0); madvise(ptr, st.st_size & ~pgmask, MADV_SEQUENTIAL); if (ptr == (char *)-1) { perror("mmap"); exit(1); } for (i = j = 0; i < (int)st.st_size; (i += pgsize), ++j) { c = ptr[i]; if (i && (j & 7) == 0) madvise(ptr + i - pgsize * 8, pgsize * 8, MADV_DONTNEED); } madvise(ptr, st.st_size & ~pgmask, MADV_DONTNEED); return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 12:12:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id C3A6D15650 for ; Thu, 29 Jul 1999 12:12:07 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA23623; Thu, 29 Jul 1999 12:11:40 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37A0A76B.F09E9AF1@gorean.org> Date: Thu, 29 Jul 1999 12:11:39 -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: Dominic Mitchell Cc: Josef Karthauser , Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <19990729090420.A98489@pavilion.net> <19990729110131.A50938@voodoo.pandhm.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dominic Mitchell wrote: > > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote: > > A question that always baffled me (I'm fairly easy to baffle) is why we've > > got some numbers defined as both udp and tcp when the service type is only > > one or the other. Does anyone know? > > Probably because the IANA specifies them that way. I think that they > try to keep both UDP and TCP ports the same, "just in case". There > might be a better explanation in rfc1700 (assigned numbers) Nope, that is the official reason. Cheesy-poofs for you. :) Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 12:41:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id B660F155D5 for ; Thu, 29 Jul 1999 12:41:00 -0700 (PDT) (envelope-from reichert@numachi.com) Received: (qmail 11909 invoked by uid 1001); 29 Jul 1999 19:40:43 -0000 Date: Thu, 29 Jul 1999 15:40:43 -0400 From: Brian Reichert To: hackers@FreeBSD.ORG Subject: state of NFSv3 under 3.2-RELEASE Message-ID: <19990729154043.K10828@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've lost track of things: - are there a set of patches for 3.2-RELEASE that stabilize the NFS issues? - if not, should I drop back to 3.1-RELEASE, or grab a more current snapshot? This is for a production environment. I appreciate the feedback... -- Brian 'you Bastard' Reichert reichert@numachi.com 37 Crystal Ave. #303 Daytime number: (781) 899-7484 x704 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 13: 5:34 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 D59E7155F5 for ; Thu, 29 Jul 1999 13:05:29 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id VAA22888; Thu, 29 Jul 1999 21:04:26 +0100 (BST) (envelope-from joe) Date: Thu, 29 Jul 1999 21:04:26 +0100 From: Josef Karthauser To: Doug Cc: Dominic Mitchell , Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services Message-ID: <19990729210425.A21377@pavilion.net> References: <19990729090420.A98489@pavilion.net> <19990729110131.A50938@voodoo.pandhm.co.uk> <37A0A76B.F09E9AF1@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37A0A76B.F09E9AF1@gorean.org>; from Doug on Thu, Jul 29, 1999 at 12:11:39PM -0700 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 Thu, Jul 29, 1999 at 12:11:39PM -0700, Doug wrote: > Dominic Mitchell wrote: > > > > On Thu, Jul 29, 1999 at 09:04:20AM +0100, Josef Karthauser wrote: > > > A question that always baffled me (I'm fairly easy to baffle) is why we've > > > got some numbers defined as both udp and tcp when the service type is only > > > one or the other. Does anyone know? > > > > Probably because the IANA specifies them that way. I think that they > > try to keep both UDP and TCP ports the same, "just in case". There > > might be a better explanation in rfc1700 (assigned numbers) > > Nope, that is the official reason. Cheesy-poofs for you. :) Ok - but it's a bit misleading having both values in /etc/services.. Shouldn't be: http 80/tcp www www-http #World Wide Web HTTP http 80/udp www www-http #World Wide Web HTTP Should be: http 80/tcp www www-http #World Wide Web HTTP http 80/udp #[not used] Don't you think? At least that way you don't have to read all of the rfcs to construct a firewall ;). 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 Thu Jul 29 13:12:26 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 2FC2714F98 for ; Thu, 29 Jul 1999 13:12:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA78387; Thu, 29 Jul 1999 13:12:06 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 13:12:06 -0700 (PDT) From: Matthew Dillon Message-Id: <199907292012.NAA78387@apollo.backplane.com> To: Brian Reichert Cc: hackers@FreeBSD.ORG Subject: Re: state of NFSv3 under 3.2-RELEASE References: <19990729154043.K10828@numachi.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've lost track of things: : :- are there a set of patches for 3.2-RELEASE that stabilize the NFS issues? : :- if not, should I drop back to 3.1-RELEASE, or grab a more current : snapshot? This is for a production environment. : :I appreciate the feedback... : :-- :Brian 'you Bastard' Reichert reichert@numachi.com :37 Crystal Ave. #303 Daytime number: (781) 899-7484 x704 Your best bet, if you are tracking the 3.x releases, is to stick to FreeBSD-stable (i.e. the latest 3.x tree). 3.1 is hopelessly broken. I would not even consider going back to it. There are items fixed in CURRENT that cannot be fixed in STABLE, mostly related to esoteric mmap() issues that you will probably never encounter, and heavy-use issues that you will also probably not encounter with a typical server installation. -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 29 13:19:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id E9A4E14F1F for ; Thu, 29 Jul 1999 13:19:02 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA24353; Thu, 29 Jul 1999 13:18:25 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37A0B711.DA388A27@gorean.org> Date: Thu, 29 Jul 1999 13:18:25 -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: Josef Karthauser Cc: Dominic Mitchell , Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <19990729090420.A98489@pavilion.net> <19990729110131.A50938@voodoo.pandhm.co.uk> <37A0A76B.F09E9AF1@gorean.org> <19990729210425.A21377@pavilion.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Josef Karthauser wrote: > Ok - but it's a bit misleading having both values in /etc/services.. > > Shouldn't be: > http 80/tcp www www-http #World Wide Web HTTP > http 80/udp www www-http #World Wide Web HTTP > > Should be: > http 80/tcp www www-http #World Wide Web HTTP > http 80/udp #[not used] > > Don't you think? At least that way you don't have to read all of the > rfcs to construct a firewall ;). You should probably add them both anyway, but that's beside the point. I'm not sure if adding comments like that would be worth it, however I tend to think that it is better to just leave it as is since that way if something changes in the future, we're already set. Also, "not used" might lead someone to believe that they could use that UDP port for their own little project. I suggested that we add the link to the IANA page way back when, but there are still some people that believe that our services list contains all the information they need. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 14:19:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zeus.directhost.net (ip126.directhost.net [209.67.132.126]) by hub.freebsd.org (Postfix) with ESMTP id AF53214CF5 for ; Thu, 29 Jul 1999 14:19:32 -0700 (PDT) (envelope-from rode@directhost.net) Received: from ip012 (ip012.directhost.net [209.67.132.12]) by zeus.directhost.net (8.9.1/8.9.1) with SMTP id OAA19752 for ; Thu, 29 Jul 1999 14:17:59 -0700 (PDT) (envelope-from rode@directhost.net) Message-ID: <006001beda07$1e24b160$0c8443d1@ip012.directhost.net> From: "Rod Ebrahimi" To: Subject: Port install trouble Date: Thu, 29 Jul 1999 14:12:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The port system is great, however I have been running into trouble on one particular machine. I receive this error when I enter the "make install" command. # make install "/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open /usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cannot continue I have tried working with the permissions and adjusting the location of the .mk files referenced by the Makefile. Thank you in advanced... Rod -- Rod Ebrahimi v:714.897.4444 DirectHOST Internet p:714.806.1367 http://www.directhost.net/ rode@directhost.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 14:28:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from snafu.adept.org (adsl-63-193-112-19.dsl.snfc21.pacbell.net [63.193.112.19]) by hub.freebsd.org (Postfix) with ESMTP id CF34714DE9 for ; Thu, 29 Jul 1999 14:28:11 -0700 (PDT) (envelope-from mike@snafu.adept.org) Received: from localhost (mike@localhost) by snafu.adept.org (8.9.3/8.9.3) with ESMTP id OAA42521; Thu, 29 Jul 1999 14:27:58 -0700 (PDT) Date: Thu, 29 Jul 1999 14:27:58 -0700 (PDT) From: Mike Hoskins To: Rod Ebrahimi Cc: hackers@FreeBSD.ORG Subject: Re: Port install trouble In-Reply-To: <006001beda07$1e24b160$0c8443d1@ip012.directhost.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999, Rod Ebrahimi wrote: > # make install > "/usr/ports/Mk/bsd.port.subdir.mk", line 0: Cannot open > /usr/ports/Mk/bsd.port.subdir.mk make: fatal errors encountered -- cannot > continue How old is the ports collection? Is it complete? Have you tried re-sup'ing your collection? Later, --mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 14:56: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 7FEBC151AC for ; Thu, 29 Jul 1999 14:56:04 -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 QAA76504; Thu, 29 Jul 1999 16:33:55 -0400 (EDT) Date: Thu, 29 Jul 1999 16:33:55 -0400 (EDT) From: Ben Rosengart To: Josef Karthauser Cc: Doug , Dominic Mitchell , Dag-Erling Smorgrav , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-Reply-To: <19990729210425.A21377@pavilion.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999, Josef Karthauser wrote: > Ok - but it's a bit misleading having both values in /etc/services.. > > Shouldn't be: > http 80/tcp www www-http #World Wide Web HTTP > http 80/udp www www-http #World Wide Web HTTP > > Should be: > http 80/tcp www www-http #World Wide Web HTTP > http 80/udp #[not used] > > Don't you think? At least that way you don't have to read all of the > rfcs to construct a firewall ;). And the output of netstat (trafshow, etc.) would be considerably easier to read. -- 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 Thu Jul 29 15: 7:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by hub.freebsd.org (Postfix) with ESMTP id 36FBD15612 for ; Thu, 29 Jul 1999 15:07:08 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-219.s28.as3.hgt.md.dialup.rcn.com [207.172.143.219]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id SAA01973; Thu, 29 Jul 1999 18:07:08 -0400 (EDT) Message-Id: <199907292207.SAA01973@smtp2.erols.com> 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: Thu, 29 Jul 1999 18:06:01 -0400 (EDT) From: John Baldwin To: Andrew Gordon Subject: Re: Linear buffers in VESA screen modes Cc: hackers@FreeBSD.ORG, John Baldwin Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Jul-99 Andrew Gordon wrote: > On Wed, 28 Jul 1999, John Baldwin wrote: >> On 29-Jul-99 Andrew Gordon wrote: >> > >> > Sure. It's rather crude at present, but I've put it up at: >> > >> > http://www.arg1.demon.co.uk/vesatv.c >> >> My wincast tv card seemed to work w/o your patch to vesa.c. Although I >> don't >> think it set the resolution right. I need to get to somewhere that I can >> get >> to more than just static though. :) > > Are you running -current? It was pointed out to me that -current already > contains code equivalent to my patch for -stable (I must have been blind > when I looked at the cvs diff and didn't see it). # uname -a FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1 21:08:59 EDT 1999 root@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386 > On your 'resolution' problem, did you change it for NTSC? My code is > hard-wired for PAL and the WEUROPE channel set on the tuner - changes > for NTSC should be obvious. Nope. :) That helped a lot. However, it seems to be displaying 640x400 in a 640x480 window. Ahh.. I found the problem, my mode 0x112 is 32bpp instead of 24bpp. A little quick hacking fixed that. Works perfect! >> Once I do, I may try and add some support for changing channels and what >> not, >> if you don't mind. > > Do whatever you like! It looks like I'll also be adding code to auto-detect the color depth and adjust accordingly. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use 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 29 15:25: 4 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 A7C13150F3 for ; Thu, 29 Jul 1999 15:24:56 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (Hamilton-ppp44858.sympatico.ca [206.172.76.51]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA07041; Thu, 29 Jul 1999 18:26:00 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA24675; Thu, 29 Jul 1999 18:22:29 -0400 (EDT) (envelope-from tim) Date: Thu, 29 Jul 1999 18:22:29 -0400 From: Tim Vanderhoek To: "Daniel C. Sobral" Cc: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990729182229.E24296@mad> References: <379F3701.F79E10DF@newsguy.com> <19990728191531.A318@mad> <37A04635.59E74FF6@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <37A04635.59E74FF6@newsguy.com>; from Daniel C. Sobral on Thu, Jul 29, 1999 at 09:16:53PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote: > > > > > > Sorry, but a simplistic analysis like that just won't cut for grep. > > > The algorithmic complexity is highly relevant here. Try this: > > > > Algorithmic complexity!?! > > Yup. I'm sorry. I've read your message and have decided that you're wrong. Outside of the regexp library, algorithmic complexity is not a factor here. It would take a beanbag to write anything other than an O(N) algorithm. The proposed grep is slow, very slow, and I've sent a long message to James outlining how to make it much faster, but algorithmic complexity is not an issue. > Also, fgetln() will copy the line buffer from time to time, though > that's not a simple computation, and probably of little fgetln() does a complete copy of the line buffer whenever an excessively long line is found. On this point, it's hard to do better without using mmap(), but mmap() has its own disadvantages. My last suggestion to James was to assume a worst case for long lines and mark the worst worst case with an XXX "this is unfortunate". > > The test you suggested doesn't show anything about that algorithmic > > complexity, though. > > Yeah? Try to back that with the results of the tests I suggested. No, it's not even worth my time. Now look. You've gotten me so upset I actually went and did a simple test. The test showed I'm right and you're wrong. Catting X number of copies of /etc/termcap into longfile causes the time grep uses to pass longfile searching for all occurrences of "printer" causes it to use an extra 0.03 seconds for every repetition of /etc/termcap in longfile. Gee, linear complexity wrt to file length. Who could've guessed!? What'ya bet GNU grep also exhibits linear complexity? :) Admit it, you jumped in with some bullshit about complexity when had you taken the time to look into what James meant when he said "it now spends 50% of its time in procline()" you would have kept quiet, realizing that he was talking about a constant factor in the complexity analysis, an subject where comments such as "it now spends 50% of its time in procline()" are relevent. :-) [Never mind that it should be spending near 100% of its time in procline...that just means he's still got work to do... :-] -- 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 Thu Jul 29 16: 7: 1 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 73D6E14DBC for ; Thu, 29 Jul 1999 16:06:47 -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 TAA11767; Thu, 29 Jul 1999 19:05:58 -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 TAA12613; Thu, 29 Jul 1999 19:05:57 -0400 (EDT) Received: from localhost by rac9.wam.umd.edu (8.9.3/8.9.3) with ESMTP id TAA12609; Thu, 29 Jul 1999 19:05:57 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: howardjp owned process doing -bs Date: Thu, 29 Jul 1999 19:05:57 -0400 (EDT) From: James Howard To: Tim Vanderhoek Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-Reply-To: <19990729182229.E24296@mad> 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, 29 Jul 1999, Tim Vanderhoek wrote: > fgetln() does a complete copy of the line buffer whenever an > excessively long line is found. On this point, it's hard to do better > without using mmap(), but mmap() has its own disadvantages. My last > suggestion to James was to assume a worst case for long lines and mark > the worst worst case with an XXX "this is unfortunate". DES tells me he has a new version (0.10) which mmap()s. It supposedly cuts the run time down significantly, I do not have the numbers in front of me. Unfortunetly he has not posted this version yet so I cannot download it and run it myself. He also says that if mmap fails, he drops back to stdio. This should only happen in the NFS case, the > 2G case, etc. > [Never mind that it should be spending near 100% of its time in > procline...that just means he's still got work to do... :-] I'd rather see it spending 100% of its time in regexec(), then I can just blame Henry Spencer :) Someone said there was new regex code out, is this true? Can anyone with a copy test grep with it? Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 16:24:28 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 32B3815644 for ; Thu, 29 Jul 1999 16:24:20 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (Hamilton-ppp44858.sympatico.ca [206.172.76.51]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA20751; Thu, 29 Jul 1999 19:26:30 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA26021; Thu, 29 Jul 1999 19:23:31 -0400 (EDT) (envelope-from tim) Date: Thu, 29 Jul 1999 19:23:30 -0400 From: Tim Vanderhoek To: James Howard Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990729192330.B25978@mad> References: <19990729182229.E24296@mad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from James Howard on Thu, Jul 29, 1999 at 07:05:57PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote: > > > > DES tells me he has a new version (0.10) which mmap()s. It supposedly > cuts the run time down significantly, I do not have the numbers in front > of me. I do. Still far too slow. I'll work on this tomorrow, since that seems the only way to convince people that mmap is not such a big win. :-( Hmm... Maybe I'll even turn-out to be wrong. ;-) I really believe mmap falls into the category of "might be nice, but not necessary and does complicate things..." -- 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 Thu Jul 29 16:26: 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 0609A15680 for ; Thu, 29 Jul 1999 16:25:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA80121; Thu, 29 Jul 1999 16:25:12 -0700 (PDT) (envelope-from dillon) Date: Thu, 29 Jul 1999 16:25:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907292325.QAA80121@apollo.backplane.com> To: James Howard Cc: Tim Vanderhoek , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :of me. Unfortunetly he has not posted this version yet so I cannot :download it and run it myself. He also says that if mmap fails, he drops :back to stdio. This should only happen in the NFS case, the > 2G case, :etc. It should only be the > 2G case or the pipe case. mmap() works just fine over NFS. I would not expect a huge speed increase using mmap over read. mmap() tends to be a lot harder on the system then read() (though we are working on that), especially if you are scanning large files. Avoiding buffer copies is good, but keep in mind that the cost of accessing a location in memory is essentially 0 if the memory is already in the L1 cache. So while you may get an improvement going from read() to mmap(), which avoids large buffer copies, you will not see much of an improvement removing redundancy from the line scan. -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 29 16:37:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 66B0215609 for ; Thu, 29 Jul 1999 16:37:40 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id RAA09378; Thu, 29 Jul 1999 17:36:40 -0600 (MDT) Received: (from danderse@localhost) by torrey.cs.utah.edu (8.9.3/8.9.1) id RAA46417; Thu, 29 Jul 1999 17:36:40 -0600 (MDT) (envelope-from danderse@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 Jul 1999 17:36:40 -0600 (MDT) From: "David G. Andersen" To: Kevin Day Cc: crandall@matchlogic.com (Charles Randall), hackers@FreeBSD.ORG Subject: Re: Replace/rewrite reverse.c for tail(1) In-Reply-To: Kevin Day's message of Wed, July 28 1999 <199907290339.WAA95155@celery.dragondata.com> References: <64003B21ECCAD11185C500805F31EC030378660F@houston.matchlogic.com> <199907290339.WAA95155@celery.dragondata.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14240.58569.149071.866632@torrey.cs.utah.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Er, the original TAC was a BSD utility which was rewritten by Jay Lepreau at Utah (who also happens to be my boss)... The source for it that I have sitting around (1986) doesn't actually list a copyright, but I'm fairly sure that we're in control of the copyright for that version. The authors are listed as "Unknown off the net long ago, and Jay Lepreau". :) It's likely to not be as fast as the newer gnu version, of course, but if you'd like, I can check on the copyright issue and plop you the source if it's OK. -Dave Lo and Behold, Kevin Day said: > > Because of licensing restrictions in our product, we are unable to ship with > any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I > saw tac, and agree that it is faster for this specific use) > > Any VM people wanna pipe up and make a suggestion so that I may make up a > patch? > > Kevin > > > > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > I'd suggest that you use "tac" from GNU textutils. > > > > Charles > > > > -----Original Message----- > > From: Kevin Day [mailto:toasty@dragondata.com] > > Sent: Wednesday, July 28, 1999 3:09 AM > > To: hackers@freebsd.org > > Subject: Replace/rewrite reverse.c for tail(1) > > > > An application I use quite often requires me to reverse the lines in the > > file to get the desired output. > > > > 'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's > > the entire file in, which encourages the kernel to swap out the rest of the > > system to keep pages of the input file in memory. > > > > 58350 root 54 0 412M 85244K RUN 0:14 19.78% 19.19% tail > > > > Out of 128M of ram, it's swapped nearly everything else out to keep 85M of > > this 400M file in ram, even though it will never touch it again. :) > > > > I see two possible fixes for this. One could be madvise'ing periodically > > with MADV_DONTNEED. If I understand correctly, this would help a bit, right? > > > > Or, mmap smaller regions of the file, and keep moving the buffer. This would > > also help with files exceeding mmap's limits. > > > > > > Any thoughts? > > > > > > Kevin > > > > > > 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 -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah CS Department http://www.angio.net/ "If you haul a geek up a crack, you will bloody their fingers for a day... If you teach a geek to climb, you will bloody their fingers for life." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 16:45:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 2AC2E1564E for ; Thu, 29 Jul 1999 16:45:50 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id QAA24077; Thu, 29 Jul 1999 16:45:33 -0700 (PDT) Message-ID: <19990729164533.36798@hydrogen.fircrest.net> Date: Thu, 29 Jul 1999 16:45:33 -0700 From: John-Mark Gurney To: James Howard Cc: Tim Vanderhoek , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=69ThD9tjz6Eq5Ldr X-Mailer: Mutt 0.69 In-Reply-To: ; from James Howard on Thu, Jul 29, 1999 at 07:05:57PM -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 --69ThD9tjz6Eq5Ldr Content-Type: text/plain; charset=us-ascii James Howard scribbled this message on Jul 29: > On Thu, 29 Jul 1999, Tim Vanderhoek wrote: > > > fgetln() does a complete copy of the line buffer whenever an > > excessively long line is found. On this point, it's hard to do better > > without using mmap(), but mmap() has its own disadvantages. My last > > suggestion to James was to assume a worst case for long lines and mark > > the worst worst case with an XXX "this is unfortunate". > > > > DES tells me he has a new version (0.10) which mmap()s. It supposedly > cuts the run time down significantly, I do not have the numbers in front > of me. Unfortunetly he has not posted this version yet so I cannot > download it and run it myself. He also says that if mmap fails, he drops > back to stdio. This should only happen in the NFS case, the > 2G case, > etc. > > > > > [Never mind that it should be spending near 100% of its time in > > procline...that just means he's still got work to do... :-] > > I'd rather see it spending 100% of its time in regexec(), then I can just > blame Henry Spencer :) > > Someone said there was new regex code out, is this true? Can anyone with > a copy test grep with it? ok, I just made a patch to eliminate the copy that was happening in procfile, and it sped up a grep of a 5meg termcap from about 2.9sec down to .6 seconds... this includes time spent profiling the program.. GNU grep w/o profiling only takes .15sec so we ARE getting closer to GNU grep... it was VERY simple to do... and attached is the patch... this uses the option REG_STARTEND to do what the copy was trying to do... all of the code to use REG_STARTEND was already there, it just needed to be enabled.. enjoy! -- 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 --69ThD9tjz6Eq5Ldr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="grep.patch" diff -u grep-0.10.orig/util.c grep-0.10/util.c --- grep-0.10.orig/util.c Thu Jul 29 05:00:15 1999 +++ grep-0.10/util.c Thu Jul 29 16:38:06 1999 @@ -93,7 +93,6 @@ file_t *f; str_t ln; int c, t, z; - char *tmp; if (fn == NULL) { fn = "(standard input)"; @@ -119,13 +118,8 @@ initqueue(); for (c = 0; !(lflag && c);) { ln.off = grep_tell(f); - if ((tmp = grep_fgetln(f, &ln.len)) == NULL) + if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL) break; - ln.dat = grep_malloc(ln.len + 1); - memcpy(ln.dat, tmp, ln.len); - ln.dat[ln.len] = 0; - if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') - ln.dat[--ln.len] = 0; ln.line_no++; z = tail; @@ -133,7 +127,6 @@ enqueue(&ln); linesqueued++; } - free(ln.dat); c += t; } if (Bflag > 0) @@ -174,7 +167,8 @@ pmatch.rm_so = 0; pmatch.rm_eo = l->len; for (c = i = 0; i < patterns; i++) { - r = regexec(&r_pattern[i], l->dat, 0, &pmatch, eflags); + r = regexec(&r_pattern[i], l->dat, 0, &pmatch, + eflags | REG_STARTEND); if (r == REG_NOMATCH && t == 0) continue; if (wflag && r == 0) { --69ThD9tjz6Eq5Ldr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 16:53: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 9DB7E1564E for ; Thu, 29 Jul 1999 16:52:58 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with SMTP id AAA18350; Fri, 30 Jul 1999 00:52:37 +0100 (BST) (envelope-from arg@arg1.demon.co.uk) Date: Fri, 30 Jul 1999 00:52:37 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: John Baldwin Cc: hackers@FreeBSD.ORG, John Baldwin Subject: Re: Linear buffers in VESA screen modes In-Reply-To: <199907292207.SAA01973@smtp2.erols.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, 29 Jul 1999, John Baldwin wrote: > > On 29-Jul-99 Andrew Gordon wrote: > > On Wed, 28 Jul 1999, John Baldwin wrote: > >> On 29-Jul-99 Andrew Gordon wrote: > >> > > >> > Sure. It's rather crude at present, but I've put it up at: > >> > > >> > http://www.arg1.demon.co.uk/vesatv.c > >> > >> My wincast tv card seemed to work w/o your patch to vesa.c. Although I > >> don't > >> think it set the resolution right. I need to get to somewhere that I can > >> get > >> to more than just static though. :) > > > > Are you running -current? It was pointed out to me that -current already > > contains code equivalent to my patch for -stable (I must have been blind > > when I looked at the cvs diff and didn't see it). > > # uname -a > FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1 21:08:59 > EDT 1999 root@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386 Maybe your hardware has the windowed and linear buffer access modes active simultaneously, rather than needing to be switched by the BIOS. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 29 16:56:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id CC1801564E for ; Thu, 29 Jul 1999 16:56:14 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id QAA24194; Thu, 29 Jul 1999 16:54:58 -0700 (PDT) Message-ID: <19990729165458.29326@hydrogen.fircrest.net> Date: Thu, 29 Jul 1999 16:54:58 -0700 From: John-Mark Gurney To: Tim Vanderhoek Cc: James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729192330.B25978@mad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19990729192330.B25978@mad>; from Tim Vanderhoek on Thu, Jul 29, 1999 at 07:23:30PM -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 Tim Vanderhoek scribbled this message on Jul 29: > On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote: > > > > > > > > DES tells me he has a new version (0.10) which mmap()s. It supposedly > > cuts the run time down significantly, I do not have the numbers in front > > of me. > > I do. Still far too slow. I'll work on this tomorrow, since that > seems the only way to convince people that mmap is not such a big > win. :-( I just managed to get a five time speed increase by removing an uncessary copy... and now, grep spends 50% of it's time in regexc, 37.2% of it's time in mmfgetln, and this is because of the scanning for a new line character... > Hmm... Maybe I'll even turn-out to be wrong. ;-) I really believe > mmap falls into the category of "might be nice, but not necessary and > does complicate things..." I think it is a big win... it shaved off around a half second from 3 seconds down to 2 and a half seconds... -- 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 Thu Jul 29 17:10:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by hub.freebsd.org (Postfix) with ESMTP id E796E14D70 for ; Thu, 29 Jul 1999 17:10:33 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-219.s28.as3.hgt.md.dialup.rcn.com [207.172.143.219]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id UAA05017; Thu, 29 Jul 1999 20:08:58 -0400 (EDT) Message-Id: <199907300008.UAA05017@smtp4.erols.com> 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: Thu, 29 Jul 1999 20:08:57 -0400 (EDT) From: John Baldwin To: Andrew Gordon Subject: Re: Linear buffers in VESA screen modes Cc: John Baldwin , hackers@FreeBSD.ORG, John Baldwin Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-Jul-99 Andrew Gordon wrote: >> # uname -a >> FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1 >> 21:08:59 >> EDT 1999 root@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386 > > Maybe your hardware has the windowed and linear buffer access modes active > simultaneously, rather than needing to be switched by the BIOS. I dunno, it's a run of the mill Matrox G200 AGP card. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use 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 29 22: 6:11 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 4518C14DF4 for ; Thu, 29 Jul 1999 22:06:07 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id AAA07963; Fri, 30 Jul 1999 00:05:28 -0500 (CDT) Date: Fri, 30 Jul 1999 00:05:28 -0500 From: Alan Cox To: Matthew Dillon Cc: David Greenman , hackers@freebsd.org Subject: Re: patch for behavior changes and madvise MADV_DONTNEED Message-ID: <19990730000528.L10860@cs.rice.edu> References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <199907291856.LAA77471@apollo.backplane.com>; from Matthew Dillon on Thu, Jul 29, 1999 at 11:56:07AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Your new "behavior" flag isn't known by vm_map_simply_entry, so map simplification could drop the behavior setting on the floor. I would prefer that the behavior is folded into eflags. Overall, I agree with the direction. Behavior is correctly a map attribute rather than an object attribute. Alan P.S. The MADV_FREE's by malloc/free were disabled by default in -CURRENT and -STABLE prior to the release of 3.2. They were a performance pessimization, slowing down "make world" by ~2%. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 0:54:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles548.castles.com [208.214.165.112]) by hub.freebsd.org (Postfix) with ESMTP id 6FABF15690 for ; Fri, 30 Jul 1999 00:54:35 -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 AAA01140; Fri, 30 Jul 1999 00:49:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907300749.AAA01140@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: eT Cc: Hackers FreeBSD Subject: Re: Changing Interface IP address In-reply-to: Your message of "Thu, 29 Jul 1999 18:07:53 +0200." <37A07C58.D7E97962@kryptokom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 00:49:52 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I would like to change the IP address (netmask, gateway etc.) of an Interface > (eg. fxp0) from within my C source code. > > 1. Is this possible to do without the SIOC ioctl call? (i am already in the > kernel). Make the call from within the kernel. > 2. Which structure and which member should I write the new information to > (ifaddr?)? Call the ioctl, which will do whatever needs to be done. -- \\ 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 Fri Jul 30 0:59:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles548.castles.com [208.214.165.112]) by hub.freebsd.org (Postfix) with ESMTP id CF83E1568E for ; Fri, 30 Jul 1999 00:59:21 -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 AAA01190; Fri, 30 Jul 1999 00:53:56 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907300753.AAA01190@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: No MAXUID ? In-reply-to: Your message of "Thu, 29 Jul 1999 15:18:51 +0200." <44527.933254331@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 00:53:56 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've come up empty-handed hunting for a constant that defines the > maximum UID supported by the system. I'm working on our passwd and > pwd_mkdb stuff and want to get rid of the artificial limitation of 65535 > (USHRT_MAX) imposed in (at least) pwd_mkdb. > > Have I missed a useful define, or should I add one? If I should add one, > does it go in pwd.h, types.h or syslimits.h? It probably belongs in param.h, and you can probably safely calculate it as (uid_t)0 - 1; -- \\ 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 Fri Jul 30 1:11:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles548.castles.com [208.214.165.112]) by hub.freebsd.org (Postfix) with ESMTP id A3A0415692 for ; Fri, 30 Jul 1999 01:11:24 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id BAA01302; Fri, 30 Jul 1999 01:05:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907300805.BAA01302@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian McGovern Cc: hackers@freebsd.org Subject: Re: reserved/local ioctl values? In-reply-to: Your message of "Tue, 27 Jul 1999 09:52:29 EDT." <199907271352.JAA09275@bmcgover-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 01:05:52 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'l looking at defining about a dozen ioctl calls for a local device driver. > When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if > there are any "reserved" or "local" values for the first parameter? Not really, as such. > In short, I'd hate to use a seemly unused value, just to suddenly be in > conflict with a major set of ioctls (particularly terminal, as this is the > type of driver it will be). Also, would it be wise to reuse an existing value? If you want to add private ioctls to a given subsystem, either pick an arbitrarily high function number, or another letter that's not commonly associated with that subsystem. Eg. I would probably pick 'z' if I were going to add a local ioctl to the tty subsystem. -- \\ 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 Fri Jul 30 1:25:15 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 94744150F4 for ; Fri, 30 Jul 1999 01:24:37 -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 JAA22686; Fri, 30 Jul 1999 09:28:13 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 30 Jul 1999 09:28:13 +0100 (BST) From: Doug Rabson To: Martin Cracauer Cc: Rayson Ho , freebsd-hackers@freebsd.org Subject: Re: BSDI Pthread + gdb (Re: Free BSDI CD!) In-Reply-To: <19990729150356.A9848@cons.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, 29 Jul 1999, Martin Cracauer wrote: > In , Rayson Ho wrote: > > Hi, > > > > I am not sure whether this is known to this list or > > not, but here is the URL for ordering: > > > > http://www.bsdi.com/products/evalcd/ > > The thing that gets my attention is the gdb with threads support. > Surely they need to provide source for the GPL gdb. > > Anyone knows what kind of Pthread library/kernel support they have? I have some patches to get our gdb to understand the uthread version of pthreads. It still needs a bit of work and I have been (extremely) busy with unrelated projects recently. I may be able to finish it after SIGGRAPH. -- 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 30 1:25:47 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 AB86D15125 for ; Fri, 30 Jul 1999 01:25:33 -0700 (PDT) (envelope-from eT@post.com) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id MAA12204; Fri, 30 Jul 1999 12:24:17 +0200 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa12196; Fri Jul 30 12:24:04 1999 Received: from fwd.kryptokom.de ([192.168.6.40]) by Cirdan.KryptoKom.DE (8.8.8/8.8.8) with ESMTP id KAA22806; Fri, 30 Jul 1999 10:30:33 +0200 Received: from post.com (localhost [127.0.0.1]) by fwd.kryptokom.de (8.9.2/8.9.2) with ESMTP id KAA02916; Fri, 30 Jul 1999 10:30:20 +0200 (CEST) (envelope-from eT@post.com) Message-ID: <37A1629A.7C7AF32F@post.com> Date: Fri, 30 Jul 1999 10:30:18 +0200 From: eT X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: Hackers FreeBSD Subject: Re: Changing Interface IP address References: <199907300749.AAA01140@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > I would like to change the IP address (netmask, gateway etc.) of an Interface > > (eg. fxp0) from within my C source code. > > > > 1. Is this possible to do without the SIOC ioctl call? (i am already in the > > kernel). > > Make the call from within the kernel. But I was under the impression that I can't do ioctl calls in the kernel? Which call should I then make from within the kernel? Thanks for the Help To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 1:33:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles548.castles.com [208.214.165.112]) by hub.freebsd.org (Postfix) with ESMTP id 4B8B8150EF for ; Fri, 30 Jul 1999 01:33:19 -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 BAA01520; Fri, 30 Jul 1999 01:28:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907300828.BAA01520@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: eT Cc: Mike Smith , Hackers FreeBSD Subject: Re: Changing Interface IP address In-reply-to: Your message of "Fri, 30 Jul 1999 10:30:18 +0200." <37A1629A.7C7AF32F@post.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 01:28:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > I would like to change the IP address (netmask, gateway etc.) of an Interface > > > (eg. fxp0) from within my C source code. > > > > > > 1. Is this possible to do without the SIOC ioctl call? (i am already in the > > > kernel). > > > > Make the call from within the kernel. > > But I was under the impression that I can't do ioctl calls in the kernel? Which call > should I then make from within the kernel? The current BSD kernel architecture does not well handle ABI calls from within kernel space, no. You will probably have to duplicate the code that handles the SIOC[AD]IFADDR in netinet/in.c in your module. -- \\ 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 Fri Jul 30 1:43:53 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 4BE8B1514B for ; Fri, 30 Jul 1999 01:43:17 -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 PAA39872; Fri, 30 Jul 1999 15:40:44 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Fri, 30 Jul 1999 15:40:44 +0700 (NSS) From: Max Khon To: Steven Fletcher Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FTPd authentication with PAM/MySQL In-Reply-To: <379d4139.331989024@194.129.209.14> 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, 26 Jul 1999, Steven Fletcher wrote: > I've seen the PAM modules/libraries/etc for MySQL and noticed that the > FTPD Makefile has a Kerberos PAM option, and was wondering if anyone > knows of a way to get FTPd talking to MySQL... or if it would work at > all? ftpd PAM patches (and other PAM stuff) are available at http://iclub.nsu.ru/~fjoe /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 2: 1:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from purveyor.dresdnerbank.de (purveyor.DresdnerBank.de [193.194.7.68]) by hub.freebsd.org (Postfix) with ESMTP id 64A5C156B8 for ; Fri, 30 Jul 1999 02:00:49 -0700 (PDT) (envelope-from Volker.Kuehn@dresdner-bank.com) Received: from ffz00egf.WWZ0ME.Mail.Dresdner.Net (unverified) by purveyor.dresdnerbank.de (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fr, 30 Jul 1999 10:57:49 +0200 Received: by FFZ00EGF.WWZ0ME.Mail.Dresdner.Net with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jul 1999 10:58:28 +0200 Message-Id: <9F5DA2D8E614D211A21100805FA72C3A031F53FA@DRKBFFTC0006> From: "Kuehn, Volker" To: "'hackers@FreeBSD.ORG'" Subject: RE: freebsd-hackers-digest V4 #565 Date: Fri, 30 Jul 1999 10:58:26 +0200 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 Sorry I know i should not mail to the mailinglist. But I can not unsubscribe Please help me To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 2: 8:34 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 BB25F151DE for ; Fri, 30 Jul 1999 02:08:29 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id MAA02172; Fri, 30 Jul 1999 12:01:42 +0300 (EEST) (envelope-from will) To: wes@softweyr.com (Wes Peters) Cc: hackers@freebsd.org Subject: Re: Documenting writev(2) ENOBUFS error References: <19990728170119.A47890@kilt.nothing-going-on.org> <37A06B6B.B5BF74CF@softweyr.com> From: Ville-Pertti Keinonen Date: 30 Jul 1999 12:01:42 +0300 In-Reply-To: wes@softweyr.com's message of "29 Jul 1999 17:58:06 +0300" Message-ID: <86yafy5x55.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 wes@softweyr.com (Wes Peters) writes: > [ENOBUFS] Insufficient system buffer space exists to complete the op- > eration. Do you know what kind of circumstances that error *really* occurs under? If it happened with files, that would be a bug and should be fixed. The call is supposed to block to wait for writes to be possible. This applies to stream sockets in most cases, as well. Based on a quick look at the code, out-of-band TCP data seems to be the only case where ENOBUFS might be returned for streams, and that obviously doesn't apply to write/writev. As I mentioned to Nik in private mail, for datagram sockets, the description in send(2) more or less applies. Programs should generally use send rather than write for such objects, anyhow. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 3:51:54 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 39C5A156BB for ; Fri, 30 Jul 1999 03:51:38 -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 11AAF5-000ETv-00; Fri, 30 Jul 1999 12:50:23 +0200 From: Sheldon Hearn To: Mike Smith Cc: hackers@freebsd.org Subject: Re: No MAXUID ? In-reply-to: Your message of "Fri, 30 Jul 1999 00:53:56 MST." <199907300753.AAA01190@dingo.cdrom.com> Date: Fri, 30 Jul 1999 12:50:23 +0200 Message-ID: <55670.933331823@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote: > It probably belongs in param.h, and you can probably safely calculate it > as (uid_t)0 - 1; Excellent. Another question I should have asked in my original mail is this: are there magical reasons why we should want pwd_mkdb to bleat for every encountered UID greater that 65535 ? Can you think of anything other than hysterical raisins why I shouldn't bump that artificial limit to the new MAX_UID when that arrives? Thanks, 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 30 4:38:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vipunen.hut.fi (vipunen-a.hut.fi [130.233.249.7]) by hub.freebsd.org (Postfix) with ESMTP id ED81A156C1 for ; Fri, 30 Jul 1999 04:38:11 -0700 (PDT) (envelope-from kuparine@vipunen.hut.fi) Received: from vipunen-a.hut.fi (vipunen-a.hut.fi [130.233.249.7]) by vipunen.hut.fi (8.9.3/8.9.3) with ESMTP id OAA429562; Fri, 30 Jul 1999 14:36:56 +0300 Date: Fri, 30 Jul 1999 14:36:56 +0300 (EET DST) From: Martti Kuparinen To: freebsd-hackers@freebsd.org, snap-users@kame.net, users@ipv6.org Subject: HOWTO: FreeBSD with integrated IPv6 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! As I promised earlier, here is some information how to integrate KAME and PAO into the FreeBSD 3.2-RELEASE source tree. The current status is: - FreeBSD+KAME - no conflicts during merge - "make world" is working - systems are up and running without any problems :-) - FreeBSD+PAO - no conflicts during merge - hasn't been tested (because I need IPv6) - FreeBSD+KAME+PAO - one conflict during merge (if_ed.c) but it's trivial to fix - hasn't been tested (I didn't have time to test this) - "make release" hasn't been tested (could some test this in FREEBSD+KAME and FREEBSD+KAME+PAO and report if it's not working) - disk usage is not optimized at all (current requirement with all the working files is about 1 GB !!) - we have been using this internally for awhile now and it seems to work quite well (although it's slow :-) The document, configuration files and scripts can be found at http://www.hut.fi/~kuparine/papers/kame/kame.html Comments, improvements, patches etc. are welcome. I'll be on vacation so I won't be reading my Ericsson mails until September 6th (but you can send email to my HUT-address). Have fun and welcome to the wonderful world of IPv6! Martti PS. Should we setup a cvsup server somewhere (not in the USA) which would have these branches? KAME people, what do you say of having such a service in one of your servers? --- Martti Kuparinen http://www.hut.fi/~kuparine/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 5:14:17 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 84F7115111 for ; Fri, 30 Jul 1999 05:14:13 -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 VAA22877; Fri, 30 Jul 1999 21:13:18 +0900 (JST) To: snap-users@kame.net Cc: freebsd-hackers@freebsd.org In-reply-to: kuparine's message of Fri, 30 Jul 1999 14:36:56 +0300. 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: (KAME-snap 936) HOWTO: FreeBSD with integrated IPv6 From: itojun@iijlab.net Date: Fri, 30 Jul 1999 21:13:18 +0900 Message-ID: <22875.933336798@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >PS. Should we setup a cvsup server somewhere (not in the USA) which would > have these branches? KAME people, what do you say of having such a > service in one of your servers? guys at imasy.or.jp has been doing it for FreeBSD228+KAME+PAO for a while, so please feel free to start (if you feel like so, of course). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 5:55:39 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 4FCFB1585F for ; Fri, 30 Jul 1999 05:55:32 -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 OAA55051; Fri, 30 Jul 1999 14:55:21 +0200 (CEST) (envelope-from des) To: Tim Vanderhoek Cc: James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729192330.B25978@mad> From: Dag-Erling Smorgrav Date: 30 Jul 1999 14:55:20 +0200 In-Reply-To: Tim Vanderhoek's message of "Thu, 29 Jul 1999 19:23:30 -0400" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tim Vanderhoek writes: > I do. Still far too slow. I'll work on this tomorrow, since that > seems the only way to convince people that mmap is not such a big > win. :-( mmap() gives a fourfold speed increase. I call that a big win. I have a few other ideas which will make 0.11 even faster. 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 Fri Jul 30 5:57: 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 A058E14E8F for ; Fri, 30 Jul 1999 05:56:59 -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 OAA55103; Fri, 30 Jul 1999 14:56:51 +0200 (CEST) (envelope-from des) To: James Howard Cc: Tim Vanderhoek , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: From: Dag-Erling Smorgrav Date: 30 Jul 1999 14:56:49 +0200 In-Reply-To: James Howard's message of "Thu, 29 Jul 1999 19:05:57 -0400 (EDT)" Message-ID: Lines: 18 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG James Howard writes: > DES tells me he has a new version (0.10) which mmap()s. It supposedly > cuts the run time down significantly, I do not have the numbers in front > of me. Unfortunetly he has not posted this version yet so I cannot > download it and run it myself. It's in the usual place (ftp://ftp.ofug.org/pub/grep/). > He also says that if mmap fails, he drops > back to stdio. This should only happen in the NFS case, the > 2G case, > etc. Any case in which a) the file is too large to mmap, b) the file is not a regular file, or c) mmap() fails (e.g. NFS). 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 Fri Jul 30 6:30: 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 D336D14ED1 for ; Fri, 30 Jul 1999 06:29:55 -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 PAA55842; Fri, 30 Jul 1999 15:27:20 +0200 (CEST) (envelope-from des) To: John-Mark Gurney Cc: James Howard , Tim Vanderhoek , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> From: Dag-Erling Smorgrav Date: 30 Jul 1999 15:27:20 +0200 In-Reply-To: John-Mark Gurney's message of "Thu, 29 Jul 1999 16:45:33 -0700" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John-Mark Gurney writes: > it was VERY simple to do... and attached is the patch... this uses the > option REG_STARTEND to do what the copy was trying to do... all of the > code to use REG_STARTEND was already there, it just needed to be enabled.. Funnily, I experience a near-doubling of running time with similar patches. 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 Fri Jul 30 6:31:26 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 A742215181 for ; Fri, 30 Jul 1999 06:31:23 -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 PAA55933; Fri, 30 Jul 1999 15:30:34 +0200 (CEST) (envelope-from des) To: Dag-Erling Smorgrav Cc: John-Mark Gurney , James Howard , Tim Vanderhoek , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> From: Dag-Erling Smorgrav Date: 30 Jul 1999 15:30:33 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "30 Jul 1999 15:27:20 +0200" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > John-Mark Gurney writes: > > it was VERY simple to do... and attached is the patch... this uses the > > option REG_STARTEND to do what the copy was trying to do... all of the > > code to use REG_STARTEND was already there, it just needed to be enabled.. > Funnily, I experience a near-doubling of running time with similar > patches. To be precise, I experience a 30% decrease in system time and a 100% increase in user time when I use RE_STARTEND and eliminate the malloc() / memcpy() calls in procfile(). 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 Fri Jul 30 6:38:49 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 D8C4814D7D for ; Fri, 30 Jul 1999 06:38:46 -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 PAA56133; Fri, 30 Jul 1999 15:38:31 +0200 (CEST) (envelope-from des) To: Sheldon Hearn Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? References: <55670.933331823@axl.noc.iafrica.com> From: Dag-Erling Smorgrav Date: 30 Jul 1999 15:38:30 +0200 In-Reply-To: Sheldon Hearn's message of "Fri, 30 Jul 1999 12:50:23 +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 Sheldon Hearn writes: > Another question I should have asked in my original mail is this: are > there magical reasons why we should want pwd_mkdb to bleat for every > encountered UID greater that 65535 ? How many times do I have to go through this? There is no "artificial limitation in pwd_mkdb". pwd_mkdb warns against UIDs larger than 65535 because legacy software that uses unsigned short instead of uid_t will break with large UIDs. There were even a few such cases in our tree that I fixed less than a year ago IIRC. 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 Fri Jul 30 6:50:27 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 945A114EA2 for ; Fri, 30 Jul 1999 06:50: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 11AD1H-000EtP-00; Fri, 30 Jul 1999 15:48:19 +0200 From: Sheldon Hearn To: Dag-Erling Smorgrav Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? In-reply-to: Your message of "30 Jul 1999 15:38:30 +0200." Date: Fri, 30 Jul 1999 15:48:19 +0200 Message-ID: <57250.933342499@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30 Jul 1999 15:38:30 +0200, Dag-Erling Smorgrav wrote: > How many times do I have to go through this? Until I stuff a comment in the source that explains this. :-) > There is no "artificial limitation in pwd_mkdb". pwd_mkdb warns > against UIDs larger than 65535 because legacy software that uses > unsigned short instead of uid_t will break with large UIDs. Would you be happy with changing things so that only one warning is generated? Something like "99999 > max_uid 65535: others may exist"? The current behaviour is quite annoying with large passwd files. :-) 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 30 7: 9:54 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 650C314D2A for ; Fri, 30 Jul 1999 07:09:46 -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 QAA56882; Fri, 30 Jul 1999 16:09:26 +0200 (CEST) (envelope-from des) To: Sheldon Hearn Cc: Dag-Erling Smorgrav , Mike Smith , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? References: <57250.933342499@axl.noc.iafrica.com> From: Dag-Erling Smorgrav Date: 30 Jul 1999 16:09:25 +0200 In-Reply-To: Sheldon Hearn's message of "Fri, 30 Jul 1999 15:48:19 +0200" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn writes: > Would you be happy with changing things so that only one warning is > generated? Something like "99999 > max_uid 65535: others may exist"? The > current behaviour is quite annoying with large passwd files. :-) Sure, and maybe modify the warning to say something like "legacy software may not support UIDs larger than 65535" 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 Fri Jul 30 7:47:31 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 9065E15166 for ; Fri, 30 Jul 1999 07:47:25 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA07119; Fri, 30 Jul 1999 23:46:43 +0900 (JST) Message-ID: <37A19050.D3ED6972@newsguy.com> Date: Fri, 30 Jul 1999 20:45:20 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: John-Mark Gurney Cc: James Howard , Tim Vanderhoek , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.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 John-Mark Gurney wrote: > > ok, I just made a patch to eliminate the copy that was happening in > procfile, and it sped up a grep of a 5meg termcap from about 2.9sec > down to .6 seconds... this includes time spent profiling the program.. > GNU grep w/o profiling only takes .15sec so we ARE getting closer to > GNU grep... Rather impressive. But... did you run these tests more than once, to account for vm caching? > it was VERY simple to do... and attached is the patch... this uses the > option REG_STARTEND to do what the copy was trying to do... all of the > code to use REG_STARTEND was already there, it just needed to be enabled.. Just for the record... :-) This eliminates one of the "added complexities" I pointed out. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 7:47:38 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 C47D0156D7 for ; Fri, 30 Jul 1999 07:47:27 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA07181; Fri, 30 Jul 1999 23:46:58 +0900 (JST) Message-ID: <37A1AF27.C5B9DB7D@newsguy.com> Date: Fri, 30 Jul 1999 22:56:55 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Tim Vanderhoek Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <379F3701.F79E10DF@newsguy.com> <19990728191531.A318@mad> <37A04635.59E74FF6@newsguy.com> <19990729182229.E24296@mad> 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 Tim Vanderhoek wrote: > > I'm sorry. I've read your message and have decided that you're wrong. Not that you did bother to counter the points I made. You only comment on the one thing I said was probably insignificant. Are you taking your clues from me? :-) > Outside of the regexp library, algorithmic complexity is not a factor > here. It would take a beanbag to write anything other than an O(N) > algorithm. I said that I did not care whether the thing is inside or outside the regexp library. And a N*search+N*copy, as opposed to N*search, *is* relevant. And that N*copy is outside regexp. And, just for the reference, GNU Grep uses a dfa to identify likely matches before letting gnuregexp work. > The proposed grep is slow, very slow, and I've sent a long message to > James outlining how to make it much faster, but algorithmic complexity > is not an issue. So you say without having checked. > > > The test you suggested doesn't show anything about that algorithmic > > > complexity, though. > > > > Yeah? Try to back that with the results of the tests I suggested. > > No, it's not even worth my time. > > Now look. You've gotten me so upset I actually went and did a simple > test. The test showed I'm right and you're wrong. Catting X number > of copies of /etc/termcap into longfile causes the time grep uses > to pass longfile searching for all occurrences of "printer" causes > it to use an extra 0.03 seconds for every repetition of /etc/termcap > in longfile. > > Gee, linear complexity wrt to file length. Who could've guessed!? That does not *begin* to cover the cases I outlined. > What'ya bet GNU grep also exhibits linear complexity? :) > > Admit it, you jumped in with some bullshit about complexity when had > you taken the time to look into what James meant when he said "it now > spends 50% of its time in procline()" you would have kept quiet, > realizing that he was talking about a constant factor in the > complexity analysis, an subject where comments such as "it now spends > 50% of its time in procline()" are relevent. Ok, here is the _DATA_ backing my "bullshit". First table: searching for non-existent patterns Tests: 1) grep -e 123 world.build 2) grep -e 123456 world.build 3) grep -e 123 124 world.build 4) grep -e 123 456 world.build These were made with GNU grep, the version 0.9 of the new grep, and that version with the patch I sent previously (this later was non-intended -- only after completing the test I realized the executable was the one with my patches). Each test was repeated five times after both the executable and the target file were cached. I show here the averages of the line "real" for time. The user and sys values were actually more interesting, but with much greater deviation. :-) GNU grep New grep Patched grep 1) 0.09945s 0.4460s 0.3870s 2) 0.07225s 0.4424s 0.3894s 3) 0.12200s 0.6352s 0.5814s 4) 0.18240s 0.6364s 0.5796s One can clearly see that GNU grep has a much better complexity in the cases of longer patterns or multiple patterns with common prefix. It also shows that the new grep spends a lot of time in an activity not related to the search itself, since it does multiple patterns by calling regexec() multiple times, but 2:1 is not the proportion you see up there. Also, the patch I introduced to eliminate N*(malloc()+free()), N being the number of lines searched, significantly reduces that overhead (overhead as in, *beyond* the time spent in regexec()). Second table: searching for existing patterns Tests: 1) grep -e net world.build >/dev/null 2) grep -e netipx world.build >/dev/null 3) grep -e netinet world.build >/dev/null 4) grep -e netinet -e netipx world.build >/dev/null GNU grep New grep 1) 0.10750s 0.57060s 2) 0.07575s 0.46375s 3) 0.07416s 0.46700s 4) 0.09950s 0.67440s Though these tests involve more factors because each has a different number of matches, it again shows very clearly that the new grep has increased complexity in the case of multiple patterns. See there, cases 1 and 4. The latter has *less* matches than the former. Third table: non-existing pattern on different sized files Tests: 1) grep 123 world.build 2) grep 123 world.build.2 (two times world.build) 3) grep 123 world.build.3 (three times world.build) 4) grep 123 world.build.4 (four times world.build) GNU grep New grep 1) 0.09600s 0.44750s 2) 0.16425s 0.89075s 3) 0.24760s 1.30850s 4) 0.31833s 1.75900s Linear, it would seem... but, alas, this is to be expected. Grep searches inside lines, and the above does not increase the size of a line, only the number of them. Still, it's a relief that the new grep does not have a worse performance in this most simple test. Fourth table: non-existing patterns on files with different line sizes. Tests: 1) grep abc line10 2) grep abc line20 3) grep 124 line10 4) grep 124 line20 Line10 and line20 have line sizes of 10 and 20, respectively. They are both around 1 Mb in size, and same size. The lines are 1234567890 and 12345678901234567890, so the first pattern is immediatly ignored, and the second has two matches before failing. GNU grep New grep 1) 0.03600s 0.41916s 2) 0.03520s 0.25828s 3) 0.03642s 0.43400s 4) 0.03783s 0.27442s These are very interesting numbers. First, it shows that new grep performs *better* when the line size decreases! This can only mean that a lot of the time spent on *each* line is spent *outside* regexec(). Just FYI, O(M+N) is a greater complexity than O(M). It would seem that GNU grep is superior in the case of partial matches without a full match too, but the standard deviation for the GNU grep case is too big for the relative differences in the GNU grep case have any meaning. Next time you "think" the complexity doesn't matter, do it with non-FreeBSD code. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 7:49:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from des.follo.net (des.follo.net [195.204.143.216]) by hub.freebsd.org (Postfix) with ESMTP id 79C3E156D3 for ; Fri, 30 Jul 1999 07:49:49 -0700 (PDT) (envelope-from des@des.follo.net) Received: (from des@localhost) by des.follo.net (8.9.3/8.9.3) id QAA00991; Fri, 30 Jul 1999 16:49:27 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: grep-0.11 Organization: Yes Interactive Visit-Us-At: http://www.yes.no/ From: Dag-Erling Smorgrav Date: 30 Jul 1999 16:49:26 +0200 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ftp://ftp.ofug.org/pub/grep/grep-0.11.tar.gz More (gprof-assisted) speedups. DES -- Dag-Erling Smorgrav - des@yes.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 7:57:30 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 48629156B8 for ; Fri, 30 Jul 1999 07:57:26 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA09517; Fri, 30 Jul 1999 23:56:56 +0900 (JST) Message-ID: <37A1BD1A.59DF842E@newsguy.com> Date: Fri, 30 Jul 1999 23:56:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.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 Dag-Erling Smorgrav wrote: > > To be precise, I experience a 30% decrease in system time and a 100% > increase in user time when I use RE_STARTEND and eliminate the > malloc() / memcpy() calls in procfile(). Could you please test my patch that removes malloc() but bot memcpy()? Here it is again, though against an old version: --- util.c.orig Thu Jul 29 19:14:17 1999 +++ util.c Thu Jul 29 20:49:16 1999 @@ -107,6 +107,8 @@ ln.file = fn; ln.line_no = 0; + ln.bufsize = 81; /* Magical constants, yeah! */ + ln.dat = grep_malloc(81); linesqueued = 0; if (Bflag > 0) @@ -115,11 +117,14 @@ ln.off = grep_tell(); if ((tmp = grep_getln(&ln.len)) == NULL) break; - ln.dat = grep_malloc(ln.len + 1); + if (ln.bufsize < ln.len + 1) + ln.dat = grep_realloc(ln.dat, ln.len + 1); memcpy(ln.dat, tmp, ln.len); - ln.dat[ln.len] = 0; if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') ln.dat[--ln.len] = 0; + else + ln.dat[ln.len] = 0; + ln.line_no++; z = tail; @@ -127,9 +132,9 @@ enqueue(&ln); linesqueued++; } - free(ln.dat); c += t; } + free(ln.dat); if (Bflag > 0) clearqueue(); grep_close(); --- grep.h.orig Thu Jul 29 20:47:52 1999 +++ grep.h Thu Jul 29 20:48:34 1999 @@ -35,6 +35,7 @@ typedef struct { size_t len; + size_t bufsize; int line_no; int off; char *file; -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 8: 1: 8 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 3E64E15180 for ; Fri, 30 Jul 1999 08:01:04 -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 QAA58110; Fri, 30 Jul 1999 16:59:53 +0200 (CEST) (envelope-from des) To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> <37A1BD1A.59DF842E@newsguy.com> From: Dag-Erling Smorgrav Date: 30 Jul 1999 16:59:53 +0200 In-Reply-To: "Daniel C. Sobral"'s message of "Fri, 30 Jul 1999 23:56:26 +0900" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > Dag-Erling Smorgrav wrote: > > To be precise, I experience a 30% decrease in system time and a 100% > > increase in user time when I use RE_STARTEND and eliminate the > > malloc() / memcpy() calls in procfile(). > Could you please test my patch that removes malloc() but bot > memcpy()? Here it is again, though against an old version: Yeah. You can do even better by declaring ln static and never free()ing it. 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 Fri Jul 30 8: 6:49 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 62AA8156E2 for ; Fri, 30 Jul 1999 08:06:28 -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 RAA58232; Fri, 30 Jul 1999 17:05:00 +0200 (CEST) (envelope-from des) To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> <37A1BD1A.59DF842E@newsguy.com> From: Dag-Erling Smorgrav Date: 30 Jul 1999 17:04:59 +0200 In-Reply-To: "Daniel C. Sobral"'s message of "Fri, 30 Jul 1999 23:56:26 +0900" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > Could you please test my patch that removes malloc() but bot > memcpy()? Here it is again, though against an old version: Bingo. REG_STARTEND is significantly more expensive than memcpy(). 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 Fri Jul 30 8:56:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id CDF0B14D7D for ; Fri, 30 Jul 1999 08:56:25 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.224] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11AEyp-000740-00; Fri, 30 Jul 1999 09:53:55 -0600 Message-ID: <37A1CA90.79820BB2@softweyr.com> Date: Fri, 30 Jul 1999 09:53:52 -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: Ville-Pertti Keinonen Cc: hackers@FreeBSD.ORG Subject: Re: Documenting writev(2) ENOBUFS error References: <19990728170119.A47890@kilt.nothing-going-on.org> <37A06B6B.B5BF74CF@softweyr.com> <86yafy5x55.fsf@not.demophon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen wrote: > > wes@softweyr.com (Wes Peters) writes: > > > [ENOBUFS] Insufficient system buffer space exists to complete the op- > > eration. > > Do you know what kind of circumstances that error *really* occurs > under? > > If it happened with files, that would be a bug and should be fixed. > The call is supposed to block to wait for writes to be possible. This > applies to stream sockets in most cases, as well. Based on a quick > look at the code, out-of-band TCP data seems to be the only case where > ENOBUFS might be returned for streams, and that obviously doesn't > apply to write/writev. The only way writev can pick up an ENOBUFS error is in the call to (*fp->f_ops->fo_write)(fp, &auio, fp->f_cred, 0) on line 447 (in -CURRENT). ENOBUFS can happen on any network object if the system is completely out of mbufs, right? So it could return ENOBUFS for any connected socket specified as the fd in a write or writev operation. -- "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 30 9:20:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles509.castles.com [208.214.165.73]) by hub.freebsd.org (Postfix) with ESMTP id 6A90F14C58 for ; Fri, 30 Jul 1999 09:20:09 -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 JAA03962; Fri, 30 Jul 1999 09:13:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907301613.JAA03962@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Sheldon Hearn Cc: Mike Smith , hackers@freebsd.org Subject: Re: No MAXUID ? In-reply-to: Your message of "Fri, 30 Jul 1999 12:50:23 +0200." <55670.933331823@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 09:13:52 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote: > > > It probably belongs in param.h, and you can probably safely calculate it > > as (uid_t)0 - 1; > > Excellent. > > Another question I should have asked in my original mail is this: are > there magical reasons why we should want pwd_mkdb to bleat for every > encountered UID greater that 65535 ? v2 NFS doesn't support UIDs > 65535, and UIDs around that number are magic to it as well. There are serious security issues here (files will appear to be owned by the wrong user). > Can you think of anything other than hysterical raisins why I shouldn't > bump that artificial limit to the new MAX_UID when that arrives? I think that the administrator should be forced to override the warning manually to indicate that they are aware of the issues they are getting themselves in for, or at the very least that there should be some very serious warnings placed in the relevant manpages (mount_nfs, passwd(5), vipw, etc) covering these issues.a -- \\ 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 Fri Jul 30 9:35: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 5D8C5151AA for ; Fri, 30 Jul 1999 09:35:32 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA91238; Fri, 30 Jul 1999 09:34:46 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 09:34:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907301634.JAA91238@apollo.backplane.com> To: Ville-Pertti Keinonen Cc: wes@softweyr.com (Wes Peters), hackers@FreeBSD.ORG Subject: Re: Documenting writev(2) ENOBUFS error References: <19990728170119.A47890@kilt.nothing-going-on.org> <37A06B6B.B5BF74CF@softweyr.com> <86yafy5x55.fsf@not.demophon.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :wes@softweyr.com (Wes Peters) writes: : :> [ENOBUFS] Insufficient system buffer space exists to complete the op- :> eration. : :Do you know what kind of circumstances that error *really* occurs :under? : :If it happened with files, that would be a bug and should be fixed. :The call is supposed to block to wait for writes to be possible. This I am almost certain that this error can only occur when writing to sockets, and only then of the network mbuf pool is completely exhausted. UDP is probably the most vulernable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 9:54:55 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 7F8F9151EB for ; Fri, 30 Jul 1999 09:54:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA91354; Fri, 30 Jul 1999 09:51:35 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 09:51:35 -0700 (PDT) From: Matthew Dillon Message-Id: <199907301651.JAA91354@apollo.backplane.com> To: Alan Cox Cc: David Greenman , hackers@freebsd.org Subject: Re: patch for behavior changes and madvise MADV_DONTNEED References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> <19990730000528.L10860@cs.rice.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Your new "behavior" flag isn't known by vm_map_simply_entry, so :map simplification could drop the behavior setting on the floor. :I would prefer that the behavior is folded into eflags. : :Overall, I agree with the direction. Behavior is correctly a map :attribute rather than an object attribute. : : Alan : :P.S. The MADV_FREE's by malloc/free were disabled by default in -CURRENT :and -STABLE prior to the release of 3.2. They were a performance :pessimization, slowing down "make world" by ~2%. No problem, I think the behavior can easily be folded into eflags, which deals with the map simplification code as well. I'll work up a new patch. - I'm not sure I see how MADV_FREE could slow performance down unless, perhaps, it is the overhead of the system call itself. e.g. if malloc is calling it on a page-by-page basis and not implementing any hysteresis. 2% isn't a big deal. MADV_FREE theoretically makes a big impact on paging performance in a heavily loaded & paging system. If your tests were run on a system that wasn't paging, you weren't testing the right thing. -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 Fri Jul 30 10:28: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 0784014D04 for ; Fri, 30 Jul 1999 10:27:56 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id KAA10966; Fri, 30 Jul 1999 10:27:26 -0700 (PDT) Message-ID: <19990730102726.34286@hydrogen.fircrest.net> Date: Fri, 30 Jul 1999 10:27:26 -0700 From: John-Mark Gurney To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> <37A1BD1A.59DF842E@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <37A1BD1A.59DF842E@newsguy.com>; from Daniel C. Sobral on Fri, Jul 30, 1999 at 11:56:26PM +0900 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 Daniel C. Sobral scribbled this message on Jul 30: > Dag-Erling Smorgrav wrote: > > > > To be precise, I experience a 30% decrease in system time and a 100% > > increase in user time when I use RE_STARTEND and eliminate the > > malloc() / memcpy() calls in procfile(). > > Could you please test my patch that removes malloc() but bot > memcpy()? Here it is again, though against an old version: wierd, I was running your patch, and at first I would get from .69 up to 1.03 seconds run time, but I can't seem to generate that problem right now... w/ your patches I'm getting around .67 to .7 seconds for: time ./grep THIS /tmp/ports/freegrep/work/grep-0.10/termcap.long > /dev/null 0.68 real 0.63 user 0.03 sys 0.67 real 0.65 user 0.01 sys 0.67 real 0.63 user 0.03 sys 0.67 real 0.63 user 0.03 sys 0.67 real 0.66 user 0.00 sys 0.67 real 0.64 user 0.02 sys summary of gprof output: [3] 50.1 0.02 0.21 108213 procline [3] [4] 46.7 0.02 0.19 108213 regexec [4] [7] 28.5 0.13 0.00 108214 mmfgetln [7] [10] 4.8 0.00 0.02 2393 grep_realloc [10] with my patch and the exact same command, I get .58 to .59 seconds... 0.58 real 0.54 user 0.03 sys 0.58 real 0.53 user 0.04 sys 0.58 real 0.55 user 0.02 sys 0.58 real 0.57 user 0.00 sys 0.59 real 0.55 user 0.02 sys 0.58 real 0.55 user 0.02 sys summary of gprof output: [3] 57.1 0.04 0.19 108213 procline [3] [4] 48.0 0.02 0.17 108213 regexec [4] [7] 34.1 0.13 0.00 108214 mmfgetln [7] [10] 2.0 0.01 0.00 1 _munmap [10] (I include _munmap because realloc/malloc/free are in the 0.0% on my patch) and grep 0.10 w/o patches: 2.82 real 1.63 user 1.12 sys 2.79 real 1.53 user 1.20 sys 2.80 real 1.65 user 1.08 sys 2.84 real 1.67 user 1.10 sys 2.82 real 1.67 user 1.08 sys 2.91 real 1.66 user 1.14 sys summary of gprof output: [5] 55.1 1.12 0.00 74985 _madvise [5] [7] 13.3 0.04 0.23 108213 regexec [7] [9] 8.4 0.00 0.17 108217 grep_malloc [9] [13] 6.5 0.13 0.00 108214 mmfgetln [13] all of the programs were compiled w/ the exact same options... that is I added -g -pg to the CFLAGS in the Makefile to generate profiling info.. I'm not sure about you, but on my k6/200, the STARTEND is more efficient than the memcpy/realloc, and to tell you the truth, I can't see why it'd be more effecient to copy possible multiple kilobytes of data than to just use indexes instead of modifing a ptr... right now, I'm trying to think of a way to eliminate the fgetln searching for end of line... of course this would eliminate some of the simplicity of design, but we can get a BIG speed increase if we simply don't scan for the new line unless we NEED to... and if we do, why not use regexec to search for us? -- 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 30 10:45:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 81083151CD; Fri, 30 Jul 1999 10:45:35 -0700 (PDT) (envelope-from roy.s.nielsen@intel.com) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id KAA22014; Fri, 30 Jul 1999 10:45:27 -0700 (PDT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jul 1999 10:45:25 -0700 Message-ID: <9ABEE73CE8D0D211AC4300A0C96B345CA64366@fmsmsx53.fm.intel.com> From: "Nielsen, Roy S" To: "'freebsd-small@FreeBSD.org'" , "'freebsd-hackers@FreeBSD.org'" Subject: bootloader.... Date: Fri, 30 Jul 1999 10:44:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? I'll take any and all suggestions :) Thanks, -roy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 12:19:25 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 CB98D1502F for ; Fri, 30 Jul 1999 12:19:16 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA24252; Fri, 30 Jul 1999 14:18:37 -0500 (CDT) Date: Fri, 30 Jul 1999 14:18:37 -0500 From: Alan Cox To: Matthew Dillon Cc: David Greenman , hackers@freebsd.org Subject: Re: patch for behavior changes and madvise MADV_DONTNEED Message-ID: <19990730141837.B22738@cs.rice.edu> References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> <19990730000528.L10860@cs.rice.edu> <199907301651.JAA91354@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <199907301651.JAA91354@apollo.backplane.com>; from Matthew Dillon on Fri, Jul 30, 1999 at 09:51:35AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 09:51:35AM -0700, Matthew Dillon wrote: > > I'm not sure I see how MADV_FREE could slow performance down unless, > perhaps, it is the overhead of the system call itself. e.g. if malloc > is calling it on a page-by-page basis and not implementing any hysteresis. > It's the system call overhead. Adding (more) hysteresis would reduce the overhead by some factor, but we'd still be making unnecessary MADV_FREE calls. Calling MADV_FREE accomplishes nothing unless the system is actually short of memory. The right way to address this problem is likely to add a mechanism to the VM system that sends a signal to the process when MADV_FREE would actually be beneficial. > 2% isn't a big deal. MADV_FREE theoretically makes a big impact on > paging performance in a heavily loaded & paging system. If your tests > were run on a system that wasn't paging, you weren't testing the right > thing. > 99% of our user base, whose machines aren't thrashing during a "make world" or other normal operation, shouldn't pay a 2% penalty to produce a theoretical improvement for the 1% that are. At best, that's "optimizing" the infrequent case at the expense of the frequent, not a good trade-off. In any case, the man page for malloc/free explains how to change the default, if you're a part of the "oppressed" 1%. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 12:31: 7 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 14FC3151FA for ; Fri, 30 Jul 1999 12:31:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA93747; Fri, 30 Jul 1999 12:30:58 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 12:30:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907301930.MAA93747@apollo.backplane.com> To: Alan Cox Cc: David Greenman , hackers@FreeBSD.ORG Subject: Re: patch for behavior changes and madvise MADV_DONTNEED References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> <19990730000528.L10860@cs.rice.edu> <199907301651.JAA91354@apollo.backplane.com> <19990730141837.B22738@cs.rice.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In any case, the man page for malloc/free explains how to change :the default, if you're a part of the "oppressed" 1%. : :Alan Not with a gig of memory :-). My only concern is for the performance curve to look good and not be too jagged. -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 Fri Jul 30 12:41: 7 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 62778151FA for ; Fri, 30 Jul 1999 12:40:36 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA79350 for ; Fri, 30 Jul 1999 20:36:02 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id NAA65694 for hackers@freebsd.org; Fri, 30 Jul 1999 13:52:39 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Fri, 30 Jul 1999 13:52:39 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: No elf(5) man page (docs/7914) Message-ID: <19990730135239.A65473@kilt.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, We have an a.out(5), but no elf(5) (as pointed out in docs/7914). Does anyone feel up to writing one? 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 Fri Jul 30 12:42: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 AFA9B15712 for ; Fri, 30 Jul 1999 12:40:36 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA79357 for ; Fri, 30 Jul 1999 20:36:03 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id OAA67166 for hackers@freebsd.org; Fri, 30 Jul 1999 14:04:11 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Fri, 30 Jul 1999 14:04:11 +0100 From: Nik Clayton To: hackers@freebsd.org Subject: Is the _Device Driver Writers Guide_ still apropos? Message-ID: <19990730140411.A66986@kilt.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, Is the FreeBSD Device Driver Writers Guide at http://www.freebsd.org/tutorials/ddwg/ddwg.html still correct? I know there have been changes to this area of the tree over the past 6 months or so, but I don't know how much of that document is still appropriate for what we have now. Thanks, 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 Fri Jul 30 12:45:33 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 4AE6E1523B for ; Fri, 30 Jul 1999 12:45:30 -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 MAA08446 for ; Fri, 30 Jul 1999 12:46:19 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: hackers@freebsd.org Subject: So, back on the topic of enabling bpf in GENERIC... Date: Fri, 30 Jul 1999 12:46:19 -0700 Message-ID: <8442.933363979@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Thanks, - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 12:51:33 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 5ACF9156FF for ; Fri, 30 Jul 1999 12:50:41 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id UAA79389; Fri, 30 Jul 1999 20:36:08 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id LAA48685; Fri, 30 Jul 1999 11:08:58 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Fri, 30 Jul 1999 11:08:58 +0100 From: Nik Clayton To: "Alton, Matthew" Cc: "'Matthew Dillon'" , "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: DOC volunteer WAS:RE: userfs help needed. Message-ID: <19990730110858.A48178@kilt.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Alton, Matthew on Thu, Jul 29, 1999 at 10:45:51AM -0500 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote: > I ran screaming into the woods last year from trying to grok VOP_foo. The > prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer > to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy > FS-implementer's Guide to the new VOP_foo. All the coders have to do is > answer my (at least marginally clueful) questions along the way and keep > posted as to what's going on in new VM-land. I won't even pester anyone > with design suggestions... very much. Solid offer, kids. Everybody wins. > Give it some thought. Sounds good. Yell for any assistance you need from the Doc. Proj. In particular, the FS Implementer's Guide sounds good. What (markup) language were you planning on using? N PS: Reply-to: should probably be set to doc, but I've left that at your discretion. -- [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 Fri Jul 30 12:56: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 382AE1523B for ; Fri, 30 Jul 1999 12:55:58 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id OAA12803; Fri, 30 Jul 1999 14:54:11 -0500 (CDT) Date: Fri, 30 Jul 1999 14:54:11 -0500 From: "Matthew D. Fuller" To: Mike Smith Cc: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? Message-ID: <19990730145410.M24560@futuresouth.com> References: <55670.933331823@axl.noc.iafrica.com> <199907301613.JAA03962@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199907301613.JAA03962@dingo.cdrom.com>; from Mike Smith on Fri, Jul 30, 1999 at 09:13:52AM -0700 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me that Mike Smith remarked > > I think that the administrator should be forced to override the warning > manually to indicate that they are aware of the issues they are getting > themselves in for, or at the very least that there should be some very > serious warnings placed in the relevant manpages (mount_nfs, passwd(5), > vipw, etc) covering these issues.a How about a bit of a compromise on it? Make pwd_mkdb just spew a warning like --- WARNING: UID(s) over XXXXX detected, may cause problems. --- by default, with a flag (-v?) to list the specific ones causing problems. Warning in manpages are, of course, always a Good Thing. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13: 1:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 395B614CED for ; Fri, 30 Jul 1999 13:01:37 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA30574; Fri, 30 Jul 1999 16:00:20 -0400 (EDT) Message-Id: <199907302000.QAA30574@cs.rpi.edu> To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: Message from "Jordan K. Hubbard" of "Fri, 30 Jul 1999 12:46:19 PDT." <8442.933363979@zippy.cdrom.com> Date: Fri, 30 Jul 1999 16:00:16 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here is a pro vote for enabling BPF in GENERIC: It will let us use a dhcp client in the install programs, this is of tremendous use to many people as DHCP starts to become much more popular. I cannot net install a machine at home since that is on a DHCP cable modem service. Also, if root is compromised on a system, even if you don't have bpf installed you would be a fool to believe that they are not sniffing packets/passwords. At the very least Mr. Pragmatic(sp?) has shown the world the power and flexability of KLDs... I am sure someone could write a KLD to impliment the functionality of a packet sniffer. Also an attacker, once obtaining root, could certainly trojan ftpd/sshd/telnetd/login/whatever. I think disabling bpf for "security reasons" is a false sense of security. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13: 1:49 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 1B13C1570B for ; Fri, 30 Jul 1999 13:01:41 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA07245; Fri, 30 Jul 1999 16:00:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:00:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Alan Cox Cc: Matthew Dillon , David Greenman , hackers@FreeBSD.org Subject: Re: patch for behavior changes and madvise MADV_DONTNEED In-Reply-To: <19990730141837.B22738@cs.rice.edu> 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 Time for this oppressed person to go ln -s H /etc/malloc.conf... 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 Fri Jul 30 13: 5: 2 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 3C0C81570A for ; Fri, 30 Jul 1999 13:04:56 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA07306; Fri, 30 Jul 1999 16:04:48 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:04:47 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <8442.933363979@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 If root is compromised, that's the only way bpf can be gotten to by default. When root's compromised, if no bpf is available, the mem devices can still be created (if not there) and network queues can be listened to. And can't IFF_PROMISC be turned on too? There's no good reason to not have bpf in at least the boot disk kernel. 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 Fri Jul 30 13: 6: 3 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 BAB4514EDB for ; Fri, 30 Jul 1999 13:05:59 -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 NAA08587; Fri, 30 Jul 1999 13:05:20 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "David E. Cross" Cc: hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-reply-to: Your message of "Fri, 30 Jul 1999 16:00:16 EDT." <199907302000.QAA30574@cs.rpi.edu> Date: Fri, 30 Jul 1999 13:05:20 -0700 Message-ID: <8583.933365120@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It will let us use a dhcp client in the install programs, this is of > tremendous use to many people as DHCP starts to become much more > popular. I cannot net install a machine at home since that is on a > DHCP cable modem service. Well, just to clarify this, if you're installing a 4.0 snapshot then you can indeed now do so; it will just be a bit savage in that the installation-time lease will be snapshotted into your /etc/rc.conf in order that the box can reboot for the first time with network connectivity. After that, it's a very good idea to build a new kernel with bpf support enabled and change the ifconfig_foo line in your /etc/rc.conf to say "DHCP" instead of the static lease information it will have in it. Then you're set from then on out. My only desire is that this process be made entirely automatic by enabling you to skip that kernel rebuild part. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13: 7:34 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 CBEE1152FA; Fri, 30 Jul 1999 13:07:31 -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 NAA08608; Fri, 30 Jul 1999 13:06:13 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-reply-to: Your message of "Fri, 30 Jul 1999 16:04:47 EDT." Date: Fri, 30 Jul 1999 13:06:13 -0700 Message-ID: <8605.933365173@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13: 9: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 9025514EDB for ; Fri, 30 Jul 1999 13:09:28 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA07386; Fri, 30 Jul 1999 16:08:51 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:08:50 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <8605.933365173@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 Fri, 30 Jul 1999, Jordan K. Hubbard wrote: > > There's no good reason to not have bpf in at least the boot disk kernel. > > It already is. That's not the question under discussion here - we're > talking about how to make things work in the post-installation boot > scenario. When did that happen? :) In that case, my argument changes to: "There's no good reason not to have bpf in the GENERIC kernel." > > - 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 Fri Jul 30 13:23:16 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 A56A814ED1 for ; Fri, 30 Jul 1999 13:23:08 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA07660; Fri, 30 Jul 1999 16:21:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:21:35 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... 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, 30 Jul 1999, Brian F. Feldman wrote: > On Fri, 30 Jul 1999, Jordan K. Hubbard wrote: > > > > There's no good reason to not have bpf in at least the boot disk kernel. > > > > It already is. That's not the question under discussion here - we're > > talking about how to make things work in the post-installation boot > > scenario. > > When did that happen? :) > > In that case, my argument changes to: > "There's no good reason not to have bpf in the GENERIC kernel." And how about having if (securelevel > 3) return (EPERM); in bpf_open()? Here's a nice, relevant excerpt from security(7): SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS If an attacker breaks root he can do just about anything, but there are certain conveniences. For example, most modern kernels have a packet sniffing device driver built in. Under FreeBSD it is called the `bpf' device. An intruder will commonly attempt to run a packet sniffer on a compromised machine. You do not need to give the intruder the capability and most systems should not have the bpf device compiled in. But even if you turn off the bpf device, you still have /dev/mem and /dev/kmem to worry about. For that matter, the intruder can still write raw devices. Also, there is another kernel feature called kldload(8). An enterprising intruder can use a KLD module to install his own bpf de- vice or other sniffing device on a running kernel. To avoid these prob- lems you have to run the kernel at a higher secure level, at least se- curelevel 1. The securelevel can be set with a sysctl on the kern.se- curelevel variable. Once you have set the securelevel to 1, write access to raw devices will be denied and special chflags flags, such as `schg', will be enforced. You must also ensure that the `schg' flag is set on critical startup binaries, directories, and script files - everything that gets run up to the point where the securelevel is set. This might be overdoing it, and upgrading the system is much more difficult when you operate at a higher secure level. You may compromise and run the system at a higher secure level but not set the schg flag for every system file and directory under the sun. > > > > > - 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 > 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 Fri Jul 30 13:37:37 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 5760614CBB; Fri, 30 Jul 1999 13:37:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA94153; Fri, 30 Jul 1999 13:37:17 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 13:37:17 -0700 (PDT) From: Matthew Dillon Message-Id: <199907302037.NAA94153@apollo.backplane.com> To: "Brian F. Feldman" Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13:39:21 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 2343314C58 for ; Fri, 30 Jul 1999 13:39:17 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA09522; Fri, 30 Jul 1999 16:39:02 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:39:01 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: "Jordan K. Hubbard" , hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <199907302037.NAA94153@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 Fri, 30 Jul 1999, Matthew Dillon wrote: > : But even if you turn off the bpf device, you still have /dev/mem and > : /dev/kmem to worry about. For that matter, the intruder can still write > : raw devices. Also, there is another kernel feature called kldload(8). > > BTW, I wrote this section because a hacker actually installed the bpf > device via the module loader during one of the root compromises at BEST, > a year or two ago. He had gotten it from a hackers cookbook of exploits > which he convieniently left on-disk long enough for our daily backups to > catch it :-). Want to post the ocde for it? It would be interesting to see how that was done! > > -Matt > > > > 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 Fri Jul 30 13:44:45 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 42F0414E6F; Fri, 30 Jul 1999 13:44:41 -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 NAA01060; Fri, 30 Jul 1999 13:37:36 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907302037.NAA01060@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-reply-to: Your message of "Fri, 30 Jul 1999 13:37:17 PDT." <199907302037.NAA94153@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jul 1999 13:37:36 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : But even if you turn off the bpf device, you still have /dev/mem and > : /dev/kmem to worry about. For that matter, the intruder can still write > : raw devices. Also, there is another kernel feature called kldload(8). > > BTW, I wrote this section because a hacker actually installed the bpf > device via the module loader during one of the root compromises at BEST, > a year or two ago. He had gotten it from a hackers cookbook of exploits > which he convieniently left on-disk long enough for our daily backups to > catch it :-). This doesn't actually help the attacker much, since at that point in time the network drivers wouldn't have been calling the bpf tap points, so it might well have been loaded, but it wouldn't have been _doing_ anything useful. -- \\ 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 Fri Jul 30 13:45:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9573A14C58 for ; Fri, 30 Jul 1999 13:45:04 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA08787; Fri, 30 Jul 1999 14:44:15 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA14297; Fri, 30 Jul 1999 14:44:14 -0600 Date: Fri, 30 Jul 1999 14:44:14 -0600 Message-Id: <199907302044.OAA14297@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <8442.933363979@zippy.cdrom.com> References: <8442.933363979@zippy.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is a clear security vs functionality issue and I need to get a > good feel for which "cause" is ascendent here in knowing which way to > jump on the matter. Can we now hear the closing arguments from the > pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I thought that was the over-riding reason for adding bpf to the kernel. Otherwise, BPF is mostly (completely) un-necessary for general purpose computing machines. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 13:45:42 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 DEC1B15745; Fri, 30 Jul 1999 13:45:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA94214; Fri, 30 Jul 1999 13:45:28 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 13:45:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199907302045.NAA94214@apollo.backplane.com> To: Mike Smith Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <199907302037.NAA01060@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> BTW, I wrote this section because a hacker actually installed the bpf :> device via the module loader during one of the root compromises at BEST, :> a year or two ago. He had gotten it from a hackers cookbook of exploits :> which he convieniently left on-disk long enough for our daily backups to :> catch it :-). : :This doesn't actually help the attacker much, since at that point in :time the network drivers wouldn't have been calling the bpf tap points, :so it might well have been loaded, but it wouldn't have been _doing_ :anything useful. Whatever it was, it was recording packets. This was a year or so ago, I don't have the code handy. -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 Fri Jul 30 13:55:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 7CE9614E6F for ; Fri, 30 Jul 1999 13:55:21 -0700 (PDT) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id PAA22602 for ; Fri, 30 Jul 1999 15:53:57 -0500 (CDT) Date: Fri, 30 Jul 1999 15:53:56 -0500 (CDT) From: Steve Price To: freebsd-hackers@freebsd.org Subject: docs for 3Com 3C515-TX NIC? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone have detailed docs for 3Com's 3C515 NIC? I found Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ but it didn't recognize the card I have. I was going to spend some time this weekend to see if I could figure out what was up. Just thought it might be easier if I had a little light reading material that described how the chip on it was supposed to work. :) Thanks. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 14: 3:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id CE85814E6F for ; Fri, 30 Jul 1999 14:03:24 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA06823; Fri, 30 Jul 1999 13:59:06 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 13:59:06 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Nate Williams Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <199907302044.OAA14297@mt.sri.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 Fri, 30 Jul 1999, Nate Williams wrote: > > This is a clear security vs functionality issue and I need to get a > > good feel for which "cause" is ascendent here in knowing which way to > > jump on the matter. Can we now hear the closing arguments from the > > pro and con folks? > > I thought we decided that the networking gurus we're going to make it > possible to send out broadcast packets on an unconfigured interface so > that DHCP would work, so that bpf wasn't required. This is by far the preferred solution. I might have the details archived from the dhcp mailing list, but IIRC it boils down to dealing properly with an address of 255.255.255.255. Whoever it was that mentioned it recently on this list clearly had the right idea. 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 30 14: 9: 0 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 185C015216 for ; Fri, 30 Jul 1999 14:08:52 -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 OAA08922; Fri, 30 Jul 1999 14:02:43 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-reply-to: Your message of "Fri, 30 Jul 1999 14:44:14 MDT." <199907302044.OAA14297@mt.sri.com> Date: Fri, 30 Jul 1999 14:02:43 -0700 Message-ID: <8919.933368563@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I thought we decided that the networking gurus we're going to make it > possible to send out broadcast packets on an unconfigured interface so > that DHCP would work, so that bpf wasn't required. I believe we decided that this would be the preferred method, yes. I don't think, however, that we decided that this was likely to show up in any reasonable amount of time or that anyone had decided to do the actual work. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 14: 9:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id 0BF281585D for ; Fri, 30 Jul 1999 14:09:19 -0700 (PDT) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 3.02 #1) id 11AJrb-000CJs-00; Fri, 30 Jul 1999 16:06:47 -0500 Date: Fri, 30 Jul 1999 16:06:46 -0500 From: Guy Helmer To: Steve Price Cc: freebsd-hackers@freebsd.org Subject: Re: docs for 3Com 3C515-TX NIC? 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, 30 Jul 1999, Steve Price wrote: > Anyone have detailed docs for 3Com's 3C515 NIC? I found > Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ > but it didn't recognize the card I have. I was going to > spend some time this weekend to see if I could figure out > what was up. Just thought it might be easier if I had > a little light reading material that described how the > chip on it was supposed to work. :) Have you tried booting with the "-v" flag to see the driver's probe messages? Did you configure the card using the configuration "pnp" commands before the kernel starts booting? For example, config> pnp 1 0 irq0 9 port0 0x360 enable os did the trick for me on a 3.2 system. When I did an install of FreeBSD 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall captured this config command and wrote it to the kernel.conf file for future boots. Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but with some ports changed. Sorry, I don't happen to have tech docs for the card. Good luck, Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 14:16:38 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 BDED4151FA for ; Fri, 30 Jul 1999 14:16:34 -0700 (PDT) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id QAA12469; Fri, 30 Jul 1999 16:11:27 -0500 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma012427; Fri, 30 Jul 99 16:11:13 -0500 Received: from stlabcexg004.anheuser-busch.com ([151.145.101.160]) by 151.145.101.130 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 30 Jul 1999 21:09:23 0000 (GMT) Received: by stlabcexg004.anheuser-busch.com with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jul 1999 16:09:11 -0500 Message-ID: From: "Alton, Matthew" To: "'Nik Clayton'" Cc: "'Matthew Dillon'" , "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: RE: DOC volunteer WAS:RE: userfs help needed. Date: Fri, 30 Jul 1999 16:09:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. Currently, I'm hatching a plan to free up an AMD386/40 running FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/ UNIXWare LAN onto the big cloud for more than 2 years. It really is emotionally difficult to pull the little box out of production. It has a personality and everything. Anyway, Mr. Dillon, once I have a development box to smack around, I intend to start with your suggestion of implementing a filesystem of my own concoction by returning an error for all VOP calls and issuing a kernel printf. How visible will the new VOP code be to me at this level? The Penguins are rewriting the bejesus out of their VFS system to the point where all the existing FS code must be redone to conform. Please debifurcate: 1) Any attempt from-scratch FS development should definitely wait for the new VFS code. Start now and you'll only end up rewiting in the Fall. 2) Hack away. All changes will be completely transparent to the FS coder. Your code, as well as everything in 2.x and 3.x will drag and drop right into the new model and build like the very wind. Thanks -----Original Message----- From: Nik Clayton [mailto:nik@nothing-going-on.demon.co.uk] Sent: Friday, July 30, 1999 05:09 To: Alton, Matthew Cc: 'Matthew Dillon'; David E. Cross; freebsd-hackers@FreeBSD.ORG Subject: Re: DOC volunteer WAS:RE: userfs help needed. On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote: > I ran screaming into the woods last year from trying to grok VOP_foo. The > prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer > to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy > FS-implementer's Guide to the new VOP_foo. All the coders have to do is > answer my (at least marginally clueful) questions along the way and keep > posted as to what's going on in new VM-land. I won't even pester anyone > with design suggestions... very much. Solid offer, kids. Everybody wins. > Give it some thought. Sounds good. Yell for any assistance you need from the Doc. Proj. In particular, the FS Implementer's Guide sounds good. What (markup) language were you planning on using? N PS: Reply-to: should probably be set to doc, but I've left that at your discretion. -- [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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 14:50: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id 3E07B151F7 for ; Fri, 30 Jul 1999 14:50:02 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.125]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA54C8; Fri, 30 Jul 1999 23:50:01 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id XAA02885; Fri, 30 Jul 1999 23:46:27 +0200 (CEST) (envelope-from asmodai) Date: Fri, 30 Jul 1999 23:46:26 +0200 From: Jeroen Ruigrok/Asmodai To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: No elf(5) man page (docs/7914) Message-ID: <19990730234626.C4337@daemon.ninth-circle.org> References: <19990730135239.A65473@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990730135239.A65473@kilt.nothing-going-on.org>; from Nik Clayton on Fri, Jul 30, 1999 at 01:52:39PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nik Clayton (nik@nothing-going-on.demon.co.uk) [990730 23:37]: > Hi folks, > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914). > > Does anyone feel up to writing one? Saw it before, noticed it, placed on my to-do list. If no-one objects I'll submit a manpage per a.out(5) style tomorrow for review untill it's ready for inclusion. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 14:50: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id 34E9615239 for ; Fri, 30 Jul 1999 14:50:05 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.125]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAB54C8; Fri, 30 Jul 1999 23:50:02 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id XAA05511; Fri, 30 Jul 1999 23:48:48 +0200 (CEST) (envelope-from asmodai) Date: Fri, 30 Jul 1999 23:48:47 +0200 From: Jeroen Ruigrok/Asmodai To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: Is the _Device Driver Writers Guide_ still apropos? Message-ID: <19990730234847.D4337@daemon.ninth-circle.org> References: <19990730140411.A66986@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990730140411.A66986@kilt.nothing-going-on.org>; from Nik Clayton on Fri, Jul 30, 1999 at 02:04:11PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nik Clayton (nik@nothing-going-on.demon.co.uk) [990730 23:37]: > -hackers, > > Is the FreeBSD Device Driver Writers Guide at > > http://www.freebsd.org/tutorials/ddwg/ddwg.html > > still correct? I know there have been changes to this area of the tree > over the past 6 months or so, but I don't know how much of that document > is still appropriate for what we have now. As far as I have been able to learn and glance from Bill Paul and some other device driver guru's too much has changed in order for it to be correct under CURRENT. A rewrite is on my to-do list for the PDP, however, should people feel like they want to rewrite it, be my guest and cc: me on any submissions so I can include it in the PDP. Else I will start this ASAHP. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 15: 7:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 8CE591571E for ; Fri, 30 Jul 1999 15:07:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA07470; Fri, 30 Jul 1999 15:05:14 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 15:05:14 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Matthew Dillon Cc: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-Reply-To: <199907290107.SAA65216@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, 28 Jul 1999, Matthew Dillon wrote: > :> Sheldon Hearn writes: > :> > I plan to mention in the comments for each service in /etc/services, the > :> > latest RFC describing the service. > :> > :> Good idea. > : > : Hmmmm... I'm not sure what this gets us. Wouldn't it be better to > :place this kind of information in the man page that you suggest below? As > :often as /etc/services gets read, do we really want to bloat it with > :non-functional information? > :... > :Doug > > I kinda like the idea of putting the RFC numbers in comments in > /etc/services. It makes the comments more meaningful. I still haven't heard anyone answer the two key (IMO) questions. Why is it better to have this in the file than in a man page, and how do you justify the additional cost to parse the file for every single system call that uses it? Please note that I _do_ think that the information is valuable. My only concern is that putting it IN the file has more costs than benefits. > It would be nice if we DBM'd /etc/services. Well that would definitely solve the problem of the "cost" of comments that I mention above, and it could also be handy in the sense that you could build an error-checker into the dbm'ing process. However this raises additional questions, like how to deal with the situation where the file is updated but the db is not. Thinking in mergemaster terms, I already have to special case master.passwd for this reason, and probably should special case login.conf too (just made myself a note). 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 30 15:12:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id AE634151F7 for ; Fri, 30 Jul 1999 15:12:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA07491; Fri, 30 Jul 1999 15:10:18 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 15:10:18 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Ben Rosengart Cc: hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Jul 1999, Ben Rosengart wrote: > On Thu, 29 Jul 1999, Josef Karthauser wrote: > > > Ok - but it's a bit misleading having both values in /etc/services.. > > > > Shouldn't be: > > http 80/tcp www www-http #World Wide Web HTTP > > http 80/udp www www-http #World Wide Web HTTP > > > > Should be: > > http 80/tcp www www-http #World Wide Web HTTP > > http 80/udp #[not used] > > > > Don't you think? At least that way you don't have to read all of the > > rfcs to construct a firewall ;). > > And the output of netstat (trafshow, etc.) would be considerably easier to > read. The -n option to trafshow disables number->name translation for both addresses and ports, although that might be more than what is wanted. I do know what you mean though. On some of the machines I administer I have some custom entries for /etc/services that make more sense than the defaults, especially for the ports > 1023. 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 30 15:28:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 4940D1571E for ; Fri, 30 Jul 1999 15:28:31 -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 SAA87008; Fri, 30 Jul 1999 18:28:20 -0400 (EDT) Date: Fri, 30 Jul 1999 18:28:20 -0400 (EDT) From: Ben Rosengart To: Doug Cc: hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services 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, 30 Jul 1999, Doug wrote: > The -n option to trafshow disables number->name translation for > both addresses and ports, although that might be more than what is wanted. > I do know what you mean though. On some of the machines I administer I > have some custom entries for /etc/services that make more sense than the > defaults, especially for the ports > 1023. Yeah, it's not that I don't want to see the service names, it's just that I want to see the accurate ones and not the inaccurate ones. As you implied, that often means the ones below port 1024 and not the others. -- 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 Fri Jul 30 15:35:13 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 CD5F915733 for ; Fri, 30 Jul 1999 15:35:04 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18370.on.bellglobal.com [206.172.130.50]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA03257; Fri, 30 Jul 1999 18:38:02 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA67239; Fri, 30 Jul 1999 18:28:38 -0400 (EDT) (envelope-from tim) Date: Fri, 30 Jul 1999 18:28:38 -0400 From: Tim Vanderhoek To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990730182838.B67094@mad> References: <379F3701.F79E10DF@newsguy.com> <19990728191531.A318@mad> <37A04635.59E74FF6@newsguy.com> <19990729182229.E24296@mad> <37A1AF27.C5B9DB7D@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <37A1AF27.C5B9DB7D@newsguy.com>; from Daniel C. Sobral on Fri, Jul 30, 1999 at 10:56:55PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote: > > I said that I did not care whether the thing is inside or outside > the regexp library. Yes, although I think at this point it's obvious we're coming at this discussion from fairly different perspectives. By the time you brought-up complexity originally, I had more or less decided that I did not want to see the new grep imported without significant speed improvements and was concerned with how to improve grep. Your interest is in debating that point (fortunately arguing for the side I agree with :). > 4) grep -e 123 456 world.build [I assume "grep -e 123 -e 124 world.build"] > One can clearly see that GNU grep has a much better complexity in > the cases of longer patterns or multiple patterns with common > prefix. Alright, someone else already mentioned to me in email that I totally ignored what differences involved multiple patterns. Combining multiple patterns is a big win if those two patterns have a common prefix (I hadn't considered the case of similar patterns before, actually). Combining multiple patterns when they're dissimilar doesn't appear to help much (which is the only case I had considered -- my mistake, and also the reason I ignored what you said about multiple patterns). I'm surprised by the way GNU grep is able to handle longer patterns, and I probably wouldn't have noticed it unless I'd taken some time to examine the GNU source. Congratulations, you win. :) The rest of your lengthy message mostly goes on to repeat the fact that GNU grep is able to merge multiple patterns with a common prefix (and postfix?) to good effect. > It also shows that the new grep spends a lot of time in an activity > not related to the search itself, since it does multiple patterns by Well, duh. This is really why my reaction to "complexity analysis" is (still) what it is. Complexity analysis is almost only useful for comparing two different algorithms and the fact that the new grep spends a lot of time doing things other than pattern searching is quite obvious after a casual perusal of the source. Complexity analysis does not (directly) help improving an algorithm. With the possible exception of the idea of merging common prefixes, most of this is not useful (at this stage) to improving grep. If I was going to propose replacing the existing GNU grep, I would (and always would have) done considerable more speed trials than the simple one in my last message. > It would seem that GNU grep is superior in the case of partial > matches without a full match too, but the standard deviation for the That is almost certainly something inside the regex library, which I have repeatedly said I'm not interested in even looking at. If our regex library is too slow, then we need to look into the newer one the Henry Spencer is rumoured to be sitting on. -- 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 Fri Jul 30 15:56:17 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 9A63214DF6 for ; Fri, 30 Jul 1999 15:56:12 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18321.on.bellglobal.com [206.172.130.1]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA26256; Fri, 30 Jul 1999 18:55:46 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA67544; Fri, 30 Jul 1999 18:53:56 -0400 (EDT) (envelope-from tim) Date: Fri, 30 Jul 1999 18:53:56 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: John-Mark Gurney , James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990730185356.A67407@mad> References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Dag-Erling Smorgrav on Fri, Jul 30, 1999 at 03:27:20PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > > it was VERY simple to do... and attached is the patch... this uses the > > option REG_STARTEND to do what the copy was trying to do... all of the > > code to use REG_STARTEND was already there, it just needed to be enabled.. > > Funnily, I experience a near-doubling of running time with similar > patches. Strange... His patches made grep on my system much faster than the original 0.10 and almost as fast as GNU grep. b$ /usr/bin/time ./grep-10 -e printer longfile > /dev/null 1.16 real 0.97 user 0.19 sys b$ /usr/bin/time ./grep-10-jmg -e printer longfile > /dev/null 0.48 real 0.43 user 0.04 sys b$ /usr/bin/time grep -e printer longfile > /dev/null 0.28 real 0.09 user 0.18 sys This is one of the original Celerons, FWIW. Once-in-a-while that gives me performance numbers somewhat different from any other Intel. -- 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 Fri Jul 30 16:38: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 219C414DF8 for ; Fri, 30 Jul 1999 16:37:53 -0700 (PDT) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id SAA31563; Fri, 30 Jul 1999 18:36:42 -0500 (CDT) Date: Fri, 30 Jul 1999 18:36:41 -0500 (CDT) From: Steve Price To: Guy Helmer Cc: freebsd-hackers@freebsd.org Subject: Re: docs for 3Com 3C515-TX NIC? 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, 30 Jul 1999, Guy Helmer wrote: # Have you tried booting with the "-v" flag to see the driver's probe # messages? Did you configure the card using the configuration "pnp" # commands before the kernel starts booting? For example, I did the former but not the latter. I'll stick it in a machine here at home (right after dinner) and give it a try. # config> pnp 1 0 irq0 9 port0 0x360 enable os # # did the trick for me on a 3.2 system. When I did an install of FreeBSD # 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall # captured this config command and wrote it to the kernel.conf file for # future boots. # # Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but # with some ports changed. Sorry, I don't happen to have tech docs for the # card. Thanks for the hints. If I have to change anything to get it to work I'll send you some diffs. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 16:39: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 4ABA2151A6; Fri, 30 Jul 1999 16:39:37 -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 RAA77719; Fri, 30 Jul 1999 17:38:48 -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 RAA85055; Fri, 30 Jul 1999 17:40:42 -0600 (MDT) Message-Id: <199907302340.RAA85055@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 30 Jul 1999 13:06:13 PDT." <8605.933365173@zippy.cdrom.com> References: <8605.933365173@zippy.cdrom.com> Date: Fri, 30 Jul 1999 17:40:41 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <8605.933365173@zippy.cdrom.com> "Jordan K. Hubbard" writes: : It already is. That's not the question under discussion here - we're : talking about how to make things work in the post-installation boot : scenario. I'm in favor of having it in the kernel by default. With one proviso. Any place where we talk about locking down a FreeBSD machine, we'd need to make it explicit that bpf should be turned off when you wish to make it hard for intruders to get packets off your wire in a root compromize situation. I wonder if /dev/bpf should be disabled when secure level is > 1 or 2... 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 30 16:41:13 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 A7AB814DF8; Fri, 30 Jul 1999 16:41: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 RAA77729; Fri, 30 Jul 1999 17:41:08 -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 RAA85088; Fri, 30 Jul 1999 17:42:57 -0600 (MDT) Message-Id: <199907302342.RAA85088@harmony.village.org> To: "Brian F. Feldman" Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 30 Jul 1999 16:21:35 EDT." References: Date: Fri, 30 Jul 1999 17:42:57 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : And how about having : if (securelevel > 3) : return (EPERM); : in bpf_open()? There are no security levels > 3. I'd be happy with > 0. This is consistant with the meaning of "raw devices". 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 30 16:46: 9 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 06B9614DF8; Fri, 30 Jul 1999 16:45:56 -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 TAA21332; Fri, 30 Jul 1999 19:44:55 -0400 (EDT) Date: Fri, 30 Jul 1999 19:44:54 -0400 (EDT) From: Alfred Perlstein To: Warner Losh Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <199907302342.RAA85088@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, 30 Jul 1999, Warner Losh wrote: > In message "Brian F. Feldman" writes: > : And how about having > : if (securelevel > 3) > : return (EPERM); > : in bpf_open()? > > There are no security levels > 3. I'd be happy with > 0. This is > consistant with the meaning of "raw devices". What about the one-way sysctls that have been suggested? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 16:47: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 5C53614DF8; Fri, 30 Jul 1999 16:47:16 -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 RAA77749; Fri, 30 Jul 1999 17:46:47 -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 RAA85152; Fri, 30 Jul 1999 17:48:41 -0600 (MDT) Message-Id: <199907302348.RAA85152@harmony.village.org> To: Alfred Perlstein Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 30 Jul 1999 19:44:54 EDT." References: Date: Fri, 30 Jul 1999 17:48:41 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Alfred Perlstein writes: : What about the one-way sysctls that have been suggested? They need to be implemente dfirst. A quick securelevel > 0 in bpf_open would allow many people's objections to bpf in the kernel by default. 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 30 16:54:12 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 F033714C2F; Fri, 30 Jul 1999 16:54:04 -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 QAA09522; Fri, 30 Jul 1999 16:53:59 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Warner Losh Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-reply-to: Your message of "Fri, 30 Jul 1999 17:42:57 MDT." <199907302342.RAA85088@harmony.village.org> Date: Fri, 30 Jul 1999 16:53:59 -0700 Message-ID: <9518.933378839@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There are no security levels > 3. I'd be happy with > 0. This is > consistant with the meaning of "raw devices". Would you be willing to make this change? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 16:56: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 4F4DB14C2F; Fri, 30 Jul 1999 16:56:50 -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 RAA77789; Fri, 30 Jul 1999 17:56:06 -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 RAA85254; Fri, 30 Jul 1999 17:57:59 -0600 (MDT) Message-Id: <199907302357.RAA85254@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 30 Jul 1999 16:53:59 PDT." <9518.933378839@zippy.cdrom.com> References: <9518.933378839@zippy.cdrom.com> Date: Fri, 30 Jul 1999 17:57:59 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <9518.933378839@zippy.cdrom.com> "Jordan K. Hubbard" writes: : > There are no security levels > 3. I'd be happy with > 0. This is : > consistant with the meaning of "raw devices". : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. 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 30 17:11:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id B2E7315745 for ; Fri, 30 Jul 1999 17:11:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA08394 for ; Fri, 30 Jul 1999 17:11:31 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 17:11:31 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-hackers@freebsd.org Subject: readdirplus is very cool, any other nfs client suggestions? 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 Spent quite a bit of time today playing around with the newly repaired readdirplus option for nfs clients in -current. My thanks to Matt Dillon and Bill Paul. For those that don't remember, I'm trying to use amd/nfs client stuff on some freebsd web servers that read their data from our sun (and now sun + netapp) web farm. I have a script that used to lock up amd and/or nfs and/or the whole machine pretty regularly. I've run it about 100 times today in various conditions with no ill effects. About this I am quite pleased. :) Since I'm new to nfs, and wasn't aware of the readdirplus option, it dawns on me that there might be other cool things I'm not using that also might be a benefit. I'm using amd for now, although this might be replaced with plain old hard mounts at some time in the near future. The following options I've cobbled together from advice on the lists, my reading of the man pages and other documentation, and a lot of experimentation. Any comments or suggestions for improvements would be welcome. Thanks, Doug amd.conf: [ global ] map_type = file search_path = /etc auto_dir = /usr/amd/realmounts normalize_hostnames = yes plock = yes selectors_on_default = yes [ /usr/amd/Interfaces ] map_name = amd.Interfaces amd.Interfaces: /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp * 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 30 17:44:18 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 953D414BED for ; Fri, 30 Jul 1999 17:44:11 -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 UAA07680; Fri, 30 Jul 1999 20:43:13 -0400 (EDT) Date: Fri, 30 Jul 1999 20:43:12 -0400 (EDT) From: Alfred Perlstein Reply-To: Alfred Perlstein To: Doug Cc: freebsd-hackers@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: readdirplus is very cool, any other nfs client suggestions? 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, 30 Jul 1999, Doug wrote: > Spent quite a bit of time today playing around with the newly > repaired readdirplus option for nfs clients in -current. My thanks to Matt > Dillon and Bill Paul. For those that don't remember, I'm trying to use > amd/nfs client stuff on some freebsd web servers that read their data from > our sun (and now sun + netapp) web farm. I have a script that used to lock > up amd and/or nfs and/or the whole machine pretty regularly. I've run it > about 100 times today in various conditions with no ill effects. About > this I am quite pleased. :) ... > amd.Interfaces: > > /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp > > * rhost:=IP${key};rfs:=/Space/${key} Not to rain on your parade, but Dag-Erling informed me that there was problems using NFSv3 over the loopback interface that can cause lockups. DES: can you elaborate? you think it may cause problems with amd since it's like an NFS buffer isn't it and would work over the loopback... -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 17:56:51 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 7774214D65; Fri, 30 Jul 1999 17:56:50 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA95155; Fri, 30 Jul 1999 17:55:15 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 17:55:15 -0700 (PDT) From: Matthew Dillon Message-Id: <199907310055.RAA95155@apollo.backplane.com> To: Warner Losh Cc: "Jordan K. Hubbard" , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <9518.933378839@zippy.cdrom.com> <199907302357.RAA85254@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <9518.933378839@zippy.cdrom.com> "Jordan K. Hubbard" writes: :: > There are no security levels > 3. I'd be happy with > 0. This is :: > consistant with the meaning of "raw devices". :: :: Would you be willing to make this change? : :Yes. I will make this change tomorrow unless there is significant :objections that cannot be resolved in the mean time. : :Warner It seems to me quite reasonable to prevent further opens of bpf once the secure level has been raised above zero. None of the devices using bpf appear to have a rebinding problem (e.g. as opposed to named running as non-root), so this would fit in well. -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 Fri Jul 30 18: 3: 9 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 C551D14DDA for ; Fri, 30 Jul 1999 18:03:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95240; Fri, 30 Jul 1999 18:02:58 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 18:02:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907310102.SAA95240@apollo.backplane.com> To: Doug Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: readdirplus is very cool, any other nfs client suggestions? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Spent quite a bit of time today playing around with the newly :repaired readdirplus option for nfs clients in -current. My thanks to Matt :Dillon and Bill Paul. For those that don't remember, I'm trying to use :amd/nfs client stuff on some freebsd web servers that read their data from :our sun (and now sun + netapp) web farm. I have a script that used to lock :up amd and/or nfs and/or the whole machine pretty regularly. I've run it :about 100 times today in various conditions with no ill effects. About :this I am quite pleased. :) : : Since I'm new to nfs, and wasn't aware of the readdirplus option, :it dawns on me that there might be other cool things I'm not using that :also might be a benefit. I'm using amd for now, although this might be :replaced with plain old hard mounts at some time in the near future. The :following options I've cobbled together from advice on the lists, my :reading of the man pages and other documentation, and a lot of :experimentation. Any comments or suggestions for improvements would be :welcome. : :Thanks, : :Doug The only other major feature is the nq leasing stuff for cache coherency, but it is highly experimental and you probably shouldn't use it. Plus very few other OS's support it. There is a lot of tweaking you can do with 'normal' nfs options, such as tuning the read & write block size, adjusting cache timeouts for various parameters, and so forth. man mount_nfs and look at the various -o options available. -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 Fri Jul 30 18: 7:42 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 EBA2614CD3 for ; Fri, 30 Jul 1999 18:07:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95269; Fri, 30 Jul 1999 18:05:12 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 18:05:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907310105.SAA95269@apollo.backplane.com> To: Alfred Perlstein Cc: Doug , freebsd-hackers@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: readdirplus is very cool, any other nfs client suggestions? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> amd.Interfaces: :> :> /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp :> :> * rhost:=IP${key};rfs:=/Space/${key} : :Not to rain on your parade, but Dag-Erling informed me that there :was problems using NFSv3 over the loopback interface that can cause :lockups. : :DES: can you elaborate? you think it may cause problems with amd :since it's like an NFS buffer isn't it and would work over the :loopback... : :-Alfred If there are easily reproducable problems with the kernel nfs client or server, please report them to me and we can almost certainly get them fixed. Problems related to amd are harder - it's really up to the author to fix those if it turns out to be a bug in amd rather then the kernel. So far, though, most of the recent bugs have been on the kernel side. -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 Fri Jul 30 18:21: 7 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 7B62214E5F for ; Fri, 30 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 SAA95376; Fri, 30 Jul 1999 18:19:59 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 18:19:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199907310119.SAA95376@apollo.backplane.com> To: "Alton, Matthew" Cc: "'Nik Clayton'" , "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: RE: DOC volunteer WAS:RE: userfs help needed. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Anyway, Mr. Dillon, once I have a development box to smack around, I :intend to start with your suggestion of implementing a filesystem :of my own concoction by returning an error for all VOP calls and :issuing a kernel printf. How visible will the new VOP code be to :me at this level? The Penguins are rewriting the bejesus out of their :VFS system to the point where all the existing FS code must be redone :to conform. Please debifurcate: :1) Any attempt from-scratch FS development should definitely wait for : the new VFS code. Start now and you'll only end up rewiting in the : Fall. :2) Hack away. All changes will be completely transparent to the FS : coder. Your code, as well as everything in 2.x and 3.x will drag : and drop right into the new model and build like the very wind. :Thanks I would go with option #2. The VFS/BIO changes are several months away at the very least. The framework hasn't even been worked out yet. The new model will not be compatible with the old, but if your stuff is in the source tree whoever winds up doing the major porting work will port it along with everything else. -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 Fri Jul 30 18:37:57 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 12AAB14EE7; Fri, 30 Jul 1999 18:37:51 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-168.bellatlantic.net [151.198.117.168]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA27214; Fri, 30 Jul 1999 21:34:28 -0400 (EDT) Message-ID: <37A25361.34799F96@bellatlantic.net> Date: Fri, 30 Jul 1999 21:37:37 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Warner Losh Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <199907302342.RAA85088@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 "Brian F. Feldman" writes: > : And how about having > : if (securelevel > 3) > : return (EPERM); > : in bpf_open()? > > There are no security levels > 3. I'd be happy with > 0. This is > consistant with the meaning of "raw devices". Disabling bpf it will break rarpd (and also rbootd but it is less important). I think such a thing should be mentioned in documentation. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 18:41: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 DCAF414EE7; Fri, 30 Jul 1999 18:41:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA95581; Fri, 30 Jul 1999 18:40:07 -0700 (PDT) (envelope-from dillon) Date: Fri, 30 Jul 1999 18:40:07 -0700 (PDT) From: Matthew Dillon Message-Id: <199907310140.SAA95581@apollo.backplane.com> To: Sergey Babkin Cc: Warner Losh , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <199907302342.RAA85088@harmony.village.org> <37A25361.34799F96@bellatlantic.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> consistant with the meaning of "raw devices". : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. -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 Fri Jul 30 18:53:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id C100415780 for ; Fri, 30 Jul 1999 18:52:29 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id SAA08905; Fri, 30 Jul 1999 18:29:22 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 18:29:22 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: readdirplus is very cool, any other nfs client suggestions? In-Reply-To: <199907310102.SAA95240@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 Fri, 30 Jul 1999, Matthew Dillon wrote: > The only other major feature is the nq leasing stuff for cache coherency, > but it is highly experimental and you probably shouldn't use it. Plus > very few other OS's support it. heh... I'm just happy when the stuff works that's supposed to work. I really don't want to push my luck. > There is a lot of tweaking you can do with 'normal' nfs options, > such as tuning the read & write block size, adjusting cache timeouts > for various parameters, and so forth. > > man mount_nfs and look at the various -o options available. Yeah, I've been reading the various man pages and things for quite a while now and it's starting to synch in. Do you have any suggestions for additional reading? The O'Reilly book seems a bit out of date, but I'll try it if folks say it's good. Basically my problem is that there are so MANY options, and my knowledged about potential side effects is very limited. Thanks for your response, 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 30 19: 9:24 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 9DFFA14E21 for ; Fri, 30 Jul 1999 19:09:20 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (Hamilton-ppp44819.sympatico.ca [206.172.76.12]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id WAA00614; Fri, 30 Jul 1999 22:08:33 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id WAA69506; Fri, 30 Jul 1999 22:07:26 -0400 (EDT) (envelope-from tim) Date: Fri, 30 Jul 1999 22:07:26 -0400 From: Tim Vanderhoek To: Dag-Erling Smorgrav Cc: John-Mark Gurney , James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990730220726.A69246@mad> References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Dag-Erling Smorgrav on Fri, Jul 30, 1999 at 03:27:20PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote: > > Funnily, I experience a near-doubling of running time with similar > patches. Incidentally, it seems that it's not possible to assume that our regex library is even anywhere in the same league as the GNU regex library. b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null real 0m21.284s user 0m22.034s sys 0m0.083s Now, with a profiled executable with optimization turned off it takes about 25 seconds. Regardless, it appears to spend 98% of its time in regexec(), which is good, since that's where it should be spending time. [I had been intending to combine multiple patterns, ultimately combining in a '\n' to avoid the memchr() in mmopen]. b$ time grep '(vt100)|(printer)' longfile > /dev/null real 0m0.267s user 0m0.109s sys 0m0.157s 98% * 20 = ~19... Without an improved regex library, any mildly complicated pattern will bring the new grep to its knees. This could be the dfa helping GNU grep more than having a better regexp library... Probably both. I wonder how well the devel/pcre port would do POSIX regular expressions. -- 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 Fri Jul 30 19:39:57 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 6F6FB150FF; Fri, 30 Jul 1999 19:39:45 -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 UAA78039; Fri, 30 Jul 1999 20:39:17 -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 UAA85677; Fri, 30 Jul 1999 20:41:11 -0600 (MDT) Message-Id: <199907310241.UAA85677@harmony.village.org> To: Sergey Babkin Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 30 Jul 1999 21:37:37 EDT." <37A25361.34799F96@bellatlantic.net> References: <37A25361.34799F96@bellatlantic.net> <199907302342.RAA85088@harmony.village.org> Date: Fri, 30 Jul 1999 20:41:11 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37A25361.34799F96@bellatlantic.net> Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. 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 30 19:50:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 256DC14ED3 for ; Fri, 30 Jul 1999 19:50:42 -0700 (PDT) (envelope-from kylee@oslab0.sogang.ac.kr) Received: from oslab0.sogang.ac.kr (oslab0.sogang.ac.kr [163.239.130.31]) by ccs.sogang.ac.kr (8.9.1a-H1/8.9.1) with ESMTP id LAA22200 for ; Sat, 31 Jul 1999 11:46:01 +0900 (KST) Received: from love by oslab0.sogang.ac.kr (8.8.8/SMI-SVR4) id LAA03638; Sat, 31 Jul 1999 11:38:54 +0900 (KST) Message-ID: <001701bedb00$a0e7a090$5e00a8c0@love.net> From: "kylee" To: References: <19990729182229.E24296@mad> <19990729192330.B25978@mad> Subject: Unsubscribe Date: Sat, 31 Jul 1999 11:58:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 19:51:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by hub.freebsd.org (Postfix) with ESMTP id F2CF71526B for ; Fri, 30 Jul 1999 19:51:10 -0700 (PDT) (envelope-from kylee@oslab0.sogang.ac.kr) Received: from oslab0.sogang.ac.kr (oslab0.sogang.ac.kr [163.239.130.31]) by ccs.sogang.ac.kr (8.9.1a-H1/8.9.1) with ESMTP id LAA19880 for ; Sat, 31 Jul 1999 11:46:53 +0900 (KST) Received: from love by oslab0.sogang.ac.kr (8.8.8/SMI-SVR4) id LAA03642; Sat, 31 Jul 1999 11:39:47 +0900 (KST) Message-ID: <002201bedb00$c00ea220$5e00a8c0@love.net> From: "kylee" To: Subject: Unsubscribe Date: Sat, 31 Jul 1999 11:59:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 19:52:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B4BA14D6A for ; Fri, 30 Jul 1999 19:52:51 -0700 (PDT) (envelope-from kylee@oslab0.sogang.ac.kr) Received: from oslab0.sogang.ac.kr (oslab0.sogang.ac.kr [163.239.130.31]) by ccs.sogang.ac.kr (8.9.1a-H1/8.9.1) with ESMTP id LAA21056 for ; Sat, 31 Jul 1999 11:49:07 +0900 (KST) Received: from love by oslab0.sogang.ac.kr (8.8.8/SMI-SVR4) id LAA03659; Sat, 31 Jul 1999 11:41:56 +0900 (KST) Message-ID: <003f01bedb01$0fb9fd10$5e00a8c0@love.net> From: "kylee" To: Subject: Unsubscribe Date: Sat, 31 Jul 1999 12:01:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 20:59:39 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 5CB1614D2A for ; Fri, 30 Jul 1999 20:59:36 -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 UAA10383 for ; Fri, 30 Jul 1999 20:58:09 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: hackers@freebsd.org Subject: Hey kernel hackers, this is worth a read. Date: Fri, 30 Jul 1999 20:58:09 -0700 Message-ID: <10379.933393489@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://features.linuxtoday.com/stories/8191.html A story on upcoming plans for the Linux 2.4 kernel. Since they're going after a lot of the same performance goals we are, it's worth a read. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 21: 6:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-18.ppp.wenet.net [206.15.85.18]) by hub.freebsd.org (Postfix) with ESMTP id 00E2214FB2 for ; Fri, 30 Jul 1999 21:06:43 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id VAA50479; Fri, 30 Jul 1999 21:06:27 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 30 Jul 1999 21:06:27 -0700 (PDT) From: Alex Zepeda To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: Hey kernel hackers, this is worth a read. In-Reply-To: <10379.933393489@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 Fri, 30 Jul 1999, Jordan K. Hubbard wrote: > http://features.linuxtoday.com/stories/8191.html > > A story on upcoming plans for the Linux 2.4 kernel. Since they're > going after a lot of the same performance goals we are, it's worth a > read. It seems to me that a lot of the features mentioned are already in -CURRENT and some in -STABLE. Hmm. I rather liked this paragraph: Users who connect to Windows shares via SMB will be pleased that there is no longer a compile time option for enabling bug workarounds for Win9x. Instead, Linux 2.4 will be able to detect the type of machine it is connected to and react accordingly. This will make Linux a much better option overall in homogenous networks. :^) - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 21: 7:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-18.ppp.wenet.net [206.15.85.18]) by hub.freebsd.org (Postfix) with ESMTP id A57B314FB2 for ; Fri, 30 Jul 1999 21:07:30 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id VAA50485; Fri, 30 Jul 1999 21:07:22 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 30 Jul 1999 21:07:22 -0700 (PDT) From: Alex Zepeda To: kylee Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Unsubscribe In-Reply-To: <003f01bedb01$0fb9fd10$5e00a8c0@love.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 31 Jul 1999, kylee wrote: > Unsubscribe No. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 21:17:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rneswold.pr.MCS.net (rneswold.pr.mcs.net [204.95.35.148]) by hub.freebsd.org (Postfix) with ESMTP id D8F6415267 for ; Fri, 30 Jul 1999 21:17:41 -0700 (PDT) (envelope-from rneswold@rneswold.pr.MCS.net) Received: (from rneswold@localhost) by rneswold.pr.MCS.net (8.9.3/8.9.3) id XAA01968; Fri, 30 Jul 1999 23:15:14 -0500 (CDT) (envelope-from rneswold) Date: Fri, 30 Jul 1999 23:15:13 -0500 From: Rich Neswold To: John Reynolds~ Cc: hackers@freebsd.org Subject: Re: SURVEY: Sound cards that work under FreeBSD Message-ID: <19990730231513.A926@drmemory.fnal.gov> Reply-To: rneswold@mcs.net References: <14231.33937.454645.22076@hip186.ch.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <14231.33937.454645.22076@hip186.ch.intel.com>; from John Reynolds~ on Thu, Jul 22, 1999 at 01:52:33PM -0700 X-PGP-RSAfprint: 0A C8 A5 76 DF 8E E1 B3 F3 97 BE 73 DA CD 4B C9 X-PGP-RSAkey: ftp://ftp.mcs.net/mcsnet.users/rneswold/pub.key X-Operating-System: FreeBSD 3.2-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If memory serves, didn't John Reynolds~ say: > > 1) The sound card make and model/chipset. Please be as specific as you > can with board rev numbers if possible. Please include wether the card is > ISA or PCI. Crystal Tidalwave32 -- plug-n-play ISA card CSN 1 Vendor ID: XTL0005 [0x05008c62] > 2) FreeBSD version(s) it was tested with. List *all* versions of FreeBSD > for which you can verify that the sound card does/doesn't work (don't > include -BETA or -SNAP releases but dates on -STABLE and -CURRENT > branches are welcome). Tested with 2.2.8 and 3.2. Doesn't work with either. I'm going to try the OSS drivers. > 3) Appropriate lines from your kernel config file / PNP setup. i.e. what > did you have to do to get this card working? Did you need patches not > committed to a particular branch (if so URLs would be welcome)? Do you > use OSS drivers instead? I've tried many different config lines, but couldn't get it to work. > 4) Sample dmesg output for properly configured device. Show the world > what boot messages relate to the device after properly configured. CSN 1 Vendor ID: XTL0005 [0x05008c62] is reported from the pnp0 driver. > 5) Miscellaneous notes. State anything "not obvious" to the casual > FreeBSD user. Good examples might be, "volume is 0 by default, use > mixer(1) to adjust at boot time," or "sh MAKEDEV snd1 for the 1st device, > not snd0." > 6) Is it OK to publish your e-mail address / name as the contributor of > this information? You may type in an anti-spam version of your e-mail > address below if you would like that option instead. Yeah. Publish my email. I'd like to be notified if someone finds a way to get this to work. -- Rich ------------------------------------------------------------------------ Rich Neswold | PGP: 0A C8 A5 76 DF 8E E1 B3 rneswold@mcs.net | F3 97 BE 73 DA CD 4B C9 http://www.mcs.net/~rneswold | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 23: 1:56 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 EA4CF15200 for ; Fri, 30 Jul 1999 23:01:47 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 79239 invoked from network); 31 Jul 1999 05:59:03 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 31 Jul 1999 05:59:03 -0000 Date: Sat, 31 Jul 1999 00:59:03 -0500 (CDT) From: David Scheidt To: Alex Zepeda Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: Hey kernel hackers, this is worth a read. 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, 30 Jul 1999, Alex Zepeda wrote: > On Fri, 30 Jul 1999, Jordan K. Hubbard wrote: > > > http://features.linuxtoday.com/stories/8191.html > > > > A story on upcoming plans for the Linux 2.4 kernel. Since they're > > going after a lot of the same performance goals we are, it's worth a > > read. > > It seems to me that a lot of the features mentioned are already in > -CURRENT and some in -STABLE. Hmm. I rather liked this paragraph: There are some suprising things missing there. No ISA PnP, just now unifiying read and write buffer caches. There are also things were they appear to be ahead of FreeBSD, like SMP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 30 23:24:46 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 50B9014BF4 for ; Fri, 30 Jul 1999 23:24:38 -0700 (PDT) (envelope-from jir@logx.com) Received: (qmail 24475 invoked from network); 31 Jul 1999 06:22:11 -0000 Received: from p84b658.sng4.ap.so-net.ne.jp (HELO mebius2) (210.132.182.88) by pop3.logx.com with SMTP; 31 Jul 1999 06:22:11 -0000 Message-ID: <012c01bedb1d$3ab927e0$0101a8c0@aladdin.jp> From: =?iso-2022-jp?B?amlyIBskQiRHJDkkJiQmGyhC?= To: Subject: Fw: thunks Date: Sat, 31 Jul 1999 15:22:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 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$B!!(BPCG-C1$B!!(BFreeBSD be$B!!(Blate$B!!(Bsorry Thunks kindness to Mr Dirk GOUDERS From: Dirk GOUDERS Subject: Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire" ethernet controller driver and plus question compaq presario dec et Date: Thu, 22 Jul 1999 09:55:05 +0200 > o.k., Bill, I'll try to translate it for you: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 0:58:13 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 EF4B714D32 for ; Sat, 31 Jul 1999 00:58:11 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id QAA08402; Sat, 31 Jul 1999 16:56:36 +0900 (JST) Message-ID: <37A2A57D.9BE13D3A@newsguy.com> Date: Sat, 31 Jul 1999 16:27:57 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: John-Mark Gurney Cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) References: <19990729182229.E24296@mad> <19990729164533.36798@hydrogen.fircrest.net> <37A1BD1A.59DF842E@newsguy.com> <19990730102726.34286@hydrogen.fircrest.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 John-Mark Gurney wrote: > > right now, I'm trying to think of a way to eliminate the fgetln searching > for end of line... of course this would eliminate some of the simplicity > of design, but we can get a BIG speed increase if we simply don't scan for > the new line unless we NEED to... and if we do, why not use regexec to > search for us? As Dillon said, the decrease in speed of the scan might not be that great. On the other hand, a decent pattern matching algorithm *does not* examine every character (which is why GNU grep performs so much better with bigger patterns). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 1:28:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 7F15014D32 for ; Sat, 31 Jul 1999 01:28:09 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 7420 invoked by uid 1001); 31 Jul 1999 08:24:51 -0000 Date: 31 Jul 1999 08:24:50 -0000 Message-ID: <19990731082450.7417.qmail@ns.oeno.com> From: Ville-Pertti Keinonen To: dillon@apollo.backplane.com Cc: wes@softweyr.com, hackers@FreeBSD.ORG In-reply-to: <199907301634.JAA91238@apollo.backplane.com> (message from Matthew Dillon on Fri, 30 Jul 1999 09:34:46 -0700 (PDT)) Subject: Re: Documenting writev(2) ENOBUFS error Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :wes@softweyr.com (Wes Peters) writes: > : > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > :> eration. > : > :Do you know what kind of circumstances that error *really* occurs > :under? > : > :If it happened with files, that would be a bug and should be fixed. > :The call is supposed to block to wait for writes to be possible. This > > I am almost certain that this error can only occur when writing to > sockets, and only then of the network mbuf pool is completely exhausted. > UDP is probably the most vulernable. It looks to me like it can't happen to stream sockets using write/writev. As far as I can tell, the ENOBUFS error can occur internally for sends if: - There is a shortage of mbufs at a low level (at higher levels, code either blocks or panics) - A network interface has a lot of packets queued (this is done at an IP level) - The socket buffer of a local datagram socket is full (the receiving socket, not the one the send occurred on) The TCP layer doesn't let ENOBUFS from low-level calls get through, but returns success. A TCP socket is prepared to resend the data at a higher level, anyhow, so the data is not lost and an error doesn't need to be returned. OOB data or implicit connections can return ENOBUFS for TCP sends, but they are activated by parameters only available through the send/sendto API. So you can get ENOBUFS not related to mbufs for UDP/local datagram sockets, but you should never get ENOBUFS from write for TCP sockets or local stream sockets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 1:54:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (Postfix) with ESMTP id A7D1B14E8B for ; Sat, 31 Jul 1999 01:54:51 -0700 (PDT) (envelope-from asami@sunrise.cs.berkeley.edu) Received: from bubble.didi.com (sji-ca3-136.ix.netcom.com [209.109.233.136]) by vader.cs.berkeley.edu (8.9.3/8.6.9) with ESMTP id BAA52171; Sat, 31 Jul 1999 01:53:01 -0700 (PDT) Received: (from asami@localhost) by bubble.didi.com (8.9.3/8.8.8) id WAA05103; Fri, 30 Jul 1999 22:50:51 -0700 (PDT) (envelope-from asami) Date: Fri, 30 Jul 1999 22:50:51 -0700 (PDT) Message-Id: <199907310550.WAA05103@bubble.didi.com> To: jkh@zippy.cdrom.com Cc: Doug@gorean.org, sheldonh@uunet.co.za, vanderh@ecf.utoronto.ca, freebsd-hackers@FreeBSD.ORG In-reply-to: <1871.933233844@zippy.cdrom.com> (jkh@zippy.cdrom.com) Subject: Re: XFree 3.3.4 not on ftp.freebsd.org? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: "Jordan K. Hubbard" Look, we're obviously not going to convince each other with this discussion. I'm sorry I caused you much trouble by adding it without working it with you first, but I believe the current state is workable for both of us. Can we leave it as it is? * 2. Your INDEX files can frequently be out of date with the ports * collection and someone should be able to do their own "make index" * when that happens. There is a "chopindex" script in ports/Tools/portbuild/scripts that anyone can use to clean up the index file (remove extra dependencies, lines for non-existent packages, etc.). * packages and that is simply not [yet] the case. The INDEX file * certainly isn't for the ports - they already get the dependency * information out of the Makefiles - it's for the packages and for * rudimentary search features. It is for all of them, as well as things like the ports web page. The one I commit is simply one with most information -- you can derive the package index from this one, but not the other way around. * To put it another way, consider me as Bruce and this as a really * egregious style(9) bug on your part. You can argue about it forever, * but it won't make you any less wrong in the end. :) If you want to declare yourself Bruce, go ahead. Then I'm going to take your advice about Bruce-filters and take note to your opinion but respectfully stand by my decision, thank you very much. :) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 4:40: 5 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 2DB0C14BF9 for ; Sat, 31 Jul 1999 04:39:59 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA28161; Sat, 31 Jul 1999 20:38:01 +0900 (JST) Message-ID: <37A2D781.AA0EA382@newsguy.com> Date: Sat, 31 Jul 1999 20:01:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <8442.933363979@zippy.cdrom.com> 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 "Jordan K. Hubbard" wrote: > > We got off onto a big tangent about switches and vlans and stuff and I > learned a number of interesting things, don't get me wrong, but we > still haven't established any consensus on the trade-offs of enabling > bpf. This wasn't meant to be a hypothetical discussion, I'm truly > trying to measure the trade-off between enabling bpf and (by some > fraction) opening things up to easier attack by sniffers in a > root-compromise situation vs not having DHCP work properly at all > after installation. > > This is a clear security vs functionality issue and I need to get a > good feel for which "cause" is ascendent here in knowing which way to > jump on the matter. Can we now hear the closing arguments from the > pro and con folks? I'm a pro folk. Your machine will have to be compromised before bpf becomes and issue, and once a machine is compromised, it is compromised. The concept of "reducing damage" is an illusion. That's like calling finger a security tool. DHCP is very important nowadays. If anyone wants to delude themselves, they can very well press the "Yes! I want to delude myself." button by removing bpf from the kernel. Besides... is there anyone _seriously_ interested in security using GENERIC? Not that GENERIC is in any way deficient, but why use a kitchen-sink kernel? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 7: 0:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from asteroid.svib.ru (asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (Postfix) with ESMTP id 3274514FF7 for ; Sat, 31 Jul 1999 07:00:14 -0700 (PDT) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.9.3/8.9.3) with ESMTP id RAA92639 for ; Sat, 31 Jul 1999 17:57:45 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (minas-tirith.pol.ru [127.0.0.1]) by shuttle.svib.ru (8.9.3/8.8.8) with ESMTP id RAA28820 for ; Sat, 31 Jul 1999 17:59:32 +0400 (MSD) (envelope-from tarkhil@shuttle.svib.ru) Message-Id: <199907311359.RAA28820@shuttle.svib.ru> To: hackers@freebsd.org Reply-To: tarkhil@asteroid.svib.ru Subject: Solution for mail pseudo-users? X-URL: http://freebsd.svib.ru Date: Sat, 31 Jul 1999 17:59:31 +0400 From: Alex Povolotsky Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 7:21: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 7180014CE0; Sat, 31 Jul 1999 07:21:35 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-137.bellatlantic.net [151.198.117.137]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id KAA24714; Sat, 31 Jul 1999 10:19:09 -0400 (EDT) Message-ID: <37A3069B.819E8D69@bellatlantic.net> Date: Sat, 31 Jul 1999 10:22:19 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Warner Losh Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <37A25361.34799F96@bellatlantic.net> <199907302342.RAA85088@harmony.village.org> <199907310241.UAA85677@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 <37A25361.34799F96@bellatlantic.net> Sergey Babkin writes: > : Disabling bpf it will break rarpd (and also rbootd but it is less > : important). I think such a thing should be mentioned in documentation. > > Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -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 31 7:29:41 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 144B714CE0 for ; Sat, 31 Jul 1999 07:29:35 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-137.bellatlantic.net [151.198.117.137]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id KAA24981; Sat, 31 Jul 1999 10:26:28 -0400 (EDT) Message-ID: <37A30852.20E5A7AF@bellatlantic.net> Date: Sat, 31 Jul 1999 10:29:38 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: tarkhil@asteroid.svib.ru Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? References: <199907311359.RAA28820@shuttle.svib.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Povolotsky wrote: > > Hello! > > I'm going to implement a large mail-box, with several hundreds of mail-only > users. They should never access anything besides their POP3 mailboxes and > change password via (SSLed) web interface. > > So, I don't want to add all of them to /etc/passwd. > > I have a hack that requires to change libc to make getpwent access not only > /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild > and overall dirty hack. > > Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -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 31 7:34:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from asteroid.svib.ru (asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (Postfix) with ESMTP id BB31415076 for ; Sat, 31 Jul 1999 07:34:54 -0700 (PDT) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.9.3/8.9.3) with ESMTP id SAA92791; Sat, 31 Jul 1999 18:31:28 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (minas-tirith.pol.ru [127.0.0.1]) by shuttle.svib.ru (8.9.3/8.8.8) with ESMTP id SAA30363; Sat, 31 Jul 1999 18:33:14 +0400 (MSD) (envelope-from tarkhil@shuttle.svib.ru) Message-Id: <199907311433.SAA30363@shuttle.svib.ru> X-Mailer: exmh version 2.0.2 2/24/98 To: Sergey Babkin Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? In-reply-to: Your message "Sat, 31 Jul 1999 10:29:38 EDT." <37A30852.20E5A7AF@bellatlantic.net> Reply-To: tarkhil@asteroid.svib.ru X-URL: http://freebsd.svib.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Jul 1999 18:33:13 +0400 From: Alex Povolotsky Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG <37A30852.20E5A7AF@bellatlantic.net>Sergey Babkin writes: >> Any suggestions, anyone? > >Modify the POP daemon to use your mySQL database in addition to getpwent ? >That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Alex. -- Alexander B. Povolotsky [ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [tarkhil@asteroid.svib.ru] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 8: 7:39 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 A95DD157C0 for ; Sat, 31 Jul 1999 08:07:18 -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 JAA21145; Sat, 31 Jul 1999 09:07:53 -0500 (CDT) Date: Sat, 31 Jul 1999 09:07:52 -0500 (CDT) From: "Jasper O'Malley" To: Alex Povolotsky Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? In-Reply-To: <199907311359.RAA28820@shuttle.svib.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 31 Jul 1999, Alex Povolotsky wrote: > I'm going to implement a large mail-box, with several hundreds of mail-only > users. They should never access anything besides their POP3 mailboxes and > change password via (SSLed) web interface. > > So, I don't want to add all of them to /etc/passwd. Use Cyrus :) The web pages at http://andrew2.andrew.cmu.edu/cyrus/ are horribly out of date, but the project is still active, and there's recent code in the FTP area. 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 Sat Jul 31 8:11:49 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 7762C15113; Sat, 31 Jul 1999 08:11:42 -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.3) id XAA04626; Fri, 30 Jul 1999 23:47:00 +0100 (BST) (envelope-from nik) Date: Fri, 30 Jul 1999 23:46:59 +0100 From: Nik Clayton To: "Alton, Matthew" Cc: "'Nik Clayton'" , "'Matthew Dillon'" , "David E. Cross" , freebsd-hackers@FreeBSD.ORG, doc@freebsd.org Subject: Re: DOC volunteer WAS:RE: userfs help needed. Message-ID: <19990730234659.A3260@catkin.nothing-going-on.org> Reply-To: doc@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Alton, Matthew on Fri, Jul 30, 1999 at 04:09:20PM -0500 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ cc'd to -doc, reply-to points there ] On Fri, Jul 30, 1999 at 04:09:20PM -0500, Alton, Matthew wrote: > I prefer to work in flat ASCII. Perhaps the doc project can HTMLize > the final product. We can, it just takes longer, that's all. It would make life simpler if you can follow the general structure, which basically consists of an overall document, containing zero or more parts, each part containing one or more chapters, each chapter containing zero or more sections, each section divided in to zero or more subsections (and so on, down to sub-sub-sub-sub-sub-sections). Each part, chapter, and section has a mandatory title. The Handbook is a good example of a document that uses parts, further divided in to chapters, and the Doc. Proj. primer is a good example of a document that dispenses with parts, and just uses chapters and sections. Generally, something like Title Abstract ..................... ..................... ..................... Chapter 1: Overview ..................... ..................... ..................... and then further chapters as necessary. Within the text, set off things that are 'out of band' information, like notes, tips, and important information. If you include instructions for the user to follow, please use "#" for the root prompt, and "%" for the regular user prompt. Refer to commands as 'command(n)', and assume that in the web (and PDF) version that will be generated that this will automatically turn in to a link to the manual page. The Doc. Proj. primer has a (sparse) writing style chapter that covers things like contractions, serial commas, and so on. Of course, you don't have to do any of this, it just makes it harder for whoever turns it in to DocBook (which will probably be me) to do the conversion. Once again, thanks for volunteering to do this. 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 Sat Jul 31 9:16:47 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 3C47F14D99 for ; Sat, 31 Jul 1999 09:16:43 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA07908; Sun, 1 Aug 1999 01:14:51 +0900 (JST) Message-ID: <37A320DC.F174BB4@newsguy.com> Date: Sun, 01 Aug 1999 01:14:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: tarkhil@asteroid.svib.ru Cc: Sergey Babkin , hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? References: <199907311433.SAA30363@shuttle.svib.ru> 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 Alex Povolotsky wrote: > > <37A30852.20E5A7AF@bellatlantic.net>Sergey Babkin writes: > >> Any suggestions, anyone? > > > >Modify the POP daemon to use your mySQL database in addition to getpwent ? > >That seems to be the easiest way that should not break anything else. > > And modify sendmail to throw off mail for nonexistent users? Try Postfix instead of sendmail. It will come out much easier. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 10: 9: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id AAB1C14CE4; Sat, 31 Jul 1999 10:08:42 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id TAA24891; Sat, 31 Jul 1999 19:08:06 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id TAA44445; Sat, 31 Jul 1999 19:07:30 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id TAA18441; Sat, 31 Jul 1999 19:08:16 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 Jul 1999 19:08:15 +0200 From: Bernd Walter To: Warner Losh Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... Message-ID: <19990731190814.A18402@cicely8.cicely.de> References: <199907302342.RAA85088@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199907302342.RAA85088@harmony.village.org>; from Warner Losh on Fri, Jul 30, 1999 at 05:42:57PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: > In message "Brian F. Feldman" writes: > : And how about having > : if (securelevel > 3) > : return (EPERM); > : in bpf_open()? > > There are no security levels > 3. I'd be happy with > 0. This is > consistant with the meaning of "raw devices". That would mean you can't run a secured DHCP server :( -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 10:18:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penelope.skunk.org (penelope.skunk.org [208.133.204.51]) by hub.freebsd.org (Postfix) with ESMTP id 5711014CE4; Sat, 31 Jul 1999 10:18:56 -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 NAA95041; Sat, 31 Jul 1999 13:17:44 -0400 (EDT) Date: Sat, 31 Jul 1999 13:17:44 -0400 (EDT) From: Ben Rosengart To: Bernd Walter Cc: Warner Losh , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: <19990731190814.A18402@cicely8.cicely.de> 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, 31 Jul 1999, Bernd Walter wrote: > That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. -- 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 31 10:37:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 7A7CC14CF0; Sat, 31 Jul 1999 10:37:27 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id TAA25469; Sat, 31 Jul 1999 19:33:57 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id TAA44493; Sat, 31 Jul 1999 19:33:19 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id TAA18512; Sat, 31 Jul 1999 19:34:11 +0200 (CEST) (envelope-from ticso) Date: Sat, 31 Jul 1999 19:34:10 +0200 From: Bernd Walter To: Ben Rosengart Cc: Bernd Walter , Warner Losh , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... Message-ID: <19990731193410.C18402@cicely8.cicely.de> References: <19990731190814.A18402@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Ben Rosengart on Sat, Jul 31, 1999 at 01:17:44PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote: > On Sat, 31 Jul 1999, Bernd Walter wrote: > > > That would mean you can't run a secured DHCP server :( > > I think only the client needs BPF. Anyway, you just start the server in > the rc files, before securelevel is raised. AFAIK it needs - but rarpd was already mentioned and there are lots of other tools which needs bpf and may reopen bpf. The securelevel is a realy nice feature and I use it often. My problem with it is that I asume the more features are put in the more often users may see that they can't raise it one step higher because of other needs. Maybe a set of sysctls with a switch to off only behavour would be a better way. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 10:43:14 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 4E74B14DBD for ; Sat, 31 Jul 1999 10:43:07 -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 NAA33437; Sat, 31 Jul 1999 13:39:16 -0400 (EDT) (envelope-from adrian@ubergeeks.com) X-Authentication-Warning: thneed.ubergeeks.com: adrian owned process doing -bs Date: Sat, 31 Jul 1999 13:39:16 -0400 (EDT) From: Adrian Filipi-Martin Reply-To: Adrian Filipi-Martin To: "Matthew D. Fuller" Cc: Mike Smith , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? In-Reply-To: <19990730145410.M24560@futuresouth.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 Fri, 30 Jul 1999, Matthew D. Fuller wrote: > On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me > that Mike Smith remarked > > > > I think that the administrator should be forced to override the warning > > manually to indicate that they are aware of the issues they are getting > > themselves in for, or at the very least that there should be some very > > serious warnings placed in the relevant manpages (mount_nfs, passwd(5), > > vipw, etc) covering these issues.a > > How about a bit of a compromise on it? > Make pwd_mkdb just spew a warning like > --- > WARNING: UID(s) over XXXXX detected, may cause problems. > --- > by default, with a flag (-v?) to list the specific ones causing problems. > > Warning in manpages are, of course, always a Good Thing. I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. Then the behavior could be easily configured for your environment with something like "32bit_uid_ok=yes" dirrective in the file. Even an environment variable could work. I have thought about making such a file to avoid recompiling pwd_mkdb with different defaults for large passwd files. The defaults get tiring when using vipw. A save can take 30 seconds on some of our sytstems. 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 Sat Jul 31 11:14:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m2-4-dbn.dial-up.net (m2-4-dbn.dial-up.net [196.34.155.68]) by hub.freebsd.org (Postfix) with ESMTP id ABFCF14F17 for ; Sat, 31 Jul 1999 11:14:09 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by m2-4-dbn.dial-up.net (8.8.7/8.6.12) id UAA12306; Sat, 31 Jul 1999 20:12:41 +0200 (SAST) From: Robert Nordier Message-Id: <199907311812.UAA12306@m2-4-dbn.dial-up.net> Subject: Re: bootloader.... In-Reply-To: <9ABEE73CE8D0D211AC4300A0C96B345CA64366@fmsmsx53.fm.intel.com> from "Nielsen, Roy S" at "Jul 30, 1999 10:44:57 am" To: roy.s.nielsen@intel.com (Nielsen Roy S) Date: Sat, 31 Jul 1999 20:12:38 +0200 (SAST) Cc: 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 [Cross-posted: replying to -hackers] > I'm looking at booting(embedded devices) and I've been looking at lilo boot > loader code and booteasy bootloader code... > > does anyone know of any documentation that anyone out there has done on this > topic? -- more specifically without > bios calls/support? There is some information in the FreeBSD handbook http://www.freebsd.org/handbook/ for example, "PC Memory Utilization" and "The FreeBSD Booting Process", though much of this is currently out-of-date. Otherwise, as maintainer of the low-level i386 boot code, I can probably help with specific issues. I'm not aware off-hand of any code anywhere that doesn't rely on the BIOS at all, though in some cases (eg. src/sys/i386/boot/netboot) BIOS support could fairly easily be dispensed with, by writing a bit of extra code. > I've seen the booteasy code at: > > ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ > > is there a newer version? this code is supposed to be compiled with > TASM/Borland C right? is there source that > can be compiled with gnu tools? See src/sys/boot/i386/boot0 in the FreeBSD source tree. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 11:32: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 83C8414BFC; Sat, 31 Jul 1999 11:32:02 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: from localhost (billf@localhost) by jade.chc-chimes.com (8.9.3/8.9.3) with ESMTP id NAA07070; Sat, 31 Jul 1999 13:29:17 -0400 (EDT) (envelope-from billf@jade.chc-chimes.com) Date: Sat, 31 Jul 1999 13:29:17 -0400 (EDT) From: Bill Fumerola To: Ben Rosengart Cc: Bernd Walter , Warner Losh , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... 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 Sat, 31 Jul 1999, Ben Rosengart wrote: > > That would mean you can't run a secured DHCP server :( > > I think only the client needs BPF. Anyway, you just start the server in > the rc files, before securelevel is raised. The isc dhcp server doesn't support a -SIGHUP reload, which would mean a reboot everytime you wanted to change the config file. For the average ISP this isn't a problem, for someone who uses dhcp to make configuring servers easier (me) this would suck. However that's an administrator's choice and changing the behavior wouldn't be that difficult. -- - 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 Sat Jul 31 11:58:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mobil.surnet.ru (mobil.surnet.ru [195.54.2.7]) by hub.freebsd.org (Postfix) with ESMTP id EE9E514E7B; Sat, 31 Jul 1999 11:58:10 -0700 (PDT) (envelope-from ilia@cgilh.chel.su) Received: (from uucgilh@localhost) by mobil.surnet.ru (8.9.1a/8.9.1) with UUCP id AAA23233; Sun, 1 Aug 1999 00:54:38 +0600 (UDT) Received: (from uucp@localhost) by cgilh.chel.su (8.8.7/8.8.7) with UUCP id XAA02603; Sat, 31 Jul 1999 23:55:21 +0600 Received: from localhost (ilia@localhost) by localhost.cgu.chel.su (8.9.2/8.9.2) with ESMTP id XAA00266; Sat, 31 Jul 1999 23:50:47 +0600 (ESS) (envelope-from ilia@cgilh.chel.su) X-Authentication-Warning: localhost.cgu.chel.su: ilia owned process doing -bs Date: Sat, 31 Jul 1999 23:50:46 +0600 (ESS) From: Ilia Chipitsine X-Sender: ilia@localhost.cgu.chel.su To: questions@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: something wrong with malloc ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody, I received a letter from Cron daemon -------------------------------------------------- Date: Sat, 31 Jul 1999 02:10:00 +0600 (ESS) From: root (Cron Daemon) To: root Subject: Cron /usr/libexec/atrun CRON in malloc(): warning: pointer to wrong page. -------------------------------------------------- surely, I'd like to reproduce it, but I simply do not remember what did was I doing ... anybody else seen it ? suggestions ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 12:47:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id B359914F05; Sat, 31 Jul 1999 12:45:08 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id PAA02477; Sat, 31 Jul 1999 15:44:59 -0400 (EDT) Message-ID: <19990731154458.A2068@netmonger.net> Date: Sat, 31 Jul 1999 15:44:58 -0400 From: Christopher Masto To: Warner Losh , "Brian F. Feldman" Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <199907302342.RAA85088@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199907302342.RAA85088@harmony.village.org>; from Warner Losh on Fri, Jul 30, 1999 at 05:42:57PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: > In message "Brian F. Feldman" writes: > : And how about having > : if (securelevel > 3) > : return (EPERM); > : in bpf_open()? > > There are no security levels > 3. I'd be happy with > 0. This is > consistant with the meaning of "raw devices". I hope you mean "> 1". I often diagnose problems using tcpdump etc., and I don't think bpf should be broken just because someone wants the minor "flags can't be turned off" feature of level 1. It seems to be that disabling bpf is more appropriate for security level 2 and up, if such a thing is desirable. I'm not sure it is. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- 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 31 14: 1:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 82CDE14D8A for ; Sat, 31 Jul 1999 14:00:43 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id QAA22124 for ; Sat, 31 Jul 1999 16:59:17 -0400 (EDT) Date: Sat, 31 Jul 1999 16:59:17 -0400 (EDT) From: Bosko Milekic To: freebsd-hackers@freebsd.org Subject: Re: Solution for mail pseudo-users? In-Reply-To: <199907311359.RAA28820@shuttle.svib.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know if my previous send was successfull, so I will send again. MY apollogies if a copy of this email is already/has already been delivered. Alex, You may want to try the patches for qpopper (if this is what you're using) to connect to a MySQL db for this sort of stuff. If you don't like qpopper, implementing these sorts of changes is generally easy and not very time-consuming for most POP daemons that come with the source. Also, a patch for smtp (sendmail+MySQL) is in the works, you may want to look at http://www.colba.net/~paul/projects/ Cheers. _____________________________________________________________. Bosko Milekic bmilekic@dsuper.net | Network Operations Delphi SuperNet | http://www.dsuper.net/ an Internet Direct company | +1.514.281.7500, x233 (phone) +1.514.281.6599 (fax) | http://www.dsuper.net/~bmilekic/ | _____________________________________________________________| On Sat, 31 Jul 1999, Alex Povolotsky wrote: > Hello! > > I'm going to implement a large mail-box, with several hundreds of mail-only > users. They should never access anything besides their POP3 mailboxes and > change password via (SSLed) web interface. > > So, I don't want to add all of them to /etc/passwd. > > I have a hack that requires to change libc to make getpwent access not only > /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild > and overall dirty hack. > > Do not ask me to RTFM on PAM, for PAM does not allow me to add users not > mentioned in passwd. > > As far as I understand, LDAP is rather bulky and suited to X.500 > integration, and that is not what I want. > > Any suggestions, anyone? > > 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 Sat Jul 31 14: 7:44 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 A74C914C36 for ; Sat, 31 Jul 1999 14:05:51 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: from kilt.nothing-going-on.org (kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id VAA70480; Sat, 31 Jul 1999 21:59:45 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by kilt.nothing-going-on.org (8.9.3/8.9.3) id TAA08621; Sat, 31 Jul 1999 19:26:14 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Date: Sat, 31 Jul 1999 19:26:14 +0100 From: Nik Clayton To: Jeroen Ruigrok/Asmodai Cc: Nik Clayton , hackers@freebsd.org Subject: Re: Is the _Device Driver Writers Guide_ still apropos? Message-ID: <19990731192614.A7118@kilt.nothing-going-on.org> References: <19990730140411.A66986@kilt.nothing-going-on.org> <19990730234847.D4337@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ZGiS0Q5IWpPtfppv X-Mailer: Mutt 0.95.4i In-Reply-To: <19990730234847.D4337@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Fri, Jul 30, 1999 at 11:48:47PM +0200 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii On Fri, Jul 30, 1999 at 11:48:47PM +0200, Jeroen Ruigrok/Asmodai wrote: > * Nik Clayton (nik@nothing-going-on.demon.co.uk) [990730 23:37]: > > Is the FreeBSD Device Driver Writers Guide at > > > > http://www.freebsd.org/tutorials/ddwg/ddwg.html > > > > still correct? I know there have been changes to this area of the tree > > over the past 6 months or so, but I don't know how much of that document > > is still appropriate for what we have now. > > As far as I have been able to learn and glance from Bill Paul and some other > device driver guru's too much has changed in order for it to be correct > under CURRENT. > > A rewrite is on my to-do list for the PDP, however, should people feel like > they want to rewrite it, be my guest and cc: me on any submissions so I can > include it in the PDP. Else I will start this ASAHP. How does the attached patch grab you? 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> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ddwg.sgml =================================================================== RCS file: /home/ncvs/doc/en/tutorials/ddwg/ddwg.sgml,v retrieving revision 1.6 diff -u -r1.6 ddwg.sgml --- ddwg.sgml 1998/06/18 13:20:41 1.6 +++ ddwg.sgml 1999/07/31 18:25:12 @@ -28,6 +28,13 @@ +2.x specific + +

Due to changes in FreeBSD over time, this guide is only accurate as +regards FreeBSD 2.x. A replacement guide for FreeBSD 3.x and beyond +is being written. Please contact Jeroen Ruigrok Overview

--ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 14: 8: 8 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 84BC514D3E for ; Sat, 31 Jul 1999 14:07:07 -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 11AgJQ-000HyC-00; Sat, 31 Jul 1999 23:05:00 +0200 From: Sheldon Hearn To: Adrian Filipi-Martin Cc: "Matthew D. Fuller" , Mike Smith , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? In-reply-to: Your message of "Sat, 31 Jul 1999 13:39:16 -0400." Date: Sat, 31 Jul 1999 23:05:00 +0200 Message-ID: <69079.933455100@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 31 Jul 1999 13:39:16 -0400, Adrian Filipi-Martin wrote: > I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar > file. Eeeuw! :-) I'm not in favour of this idea, but issuing a single warning for one or more UID's encountered isn't behaviour that would make retrofitting your idea impossible if you decided to do it later. While warnings and error messages should give me enough information to address a problem efficiently (something on the wishlist of any Wintendo administrator), once I know there is more than zero potentially problematic entries, I can used cat, awk and sh to find all the culprits if I want to. Ciao, Sheldon. PS: Those two paragraphs have nothing to do with each other, by the way. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 14:14: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 E387A14C23 for ; Sat, 31 Jul 1999 14:14:52 -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 11AgSN-000Hzk-00; Sat, 31 Jul 1999 23:14:15 +0200 From: Sheldon Hearn To: Doug Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Fri, 30 Jul 1999 15:05:14 MST." Date: Sat, 31 Jul 1999 23:14:15 +0200 Message-ID: <69175.933455655@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: > I still haven't heard anyone answer the two key (IMO) questions. Your questions are easier answered in reverse order: > and how do you justify the additional cost to parse the file for every > single system call that uses it? The information is part of the comments within the file. The cost is in disk space, and it's cheaper than fleabites. > Why is it better to have this in the file than in a man page, Since it costs nothing to have it in /etc/services, why not leave it there along with the information with which it's associated? The alternative is to have a manpage that contains most of the information in /etc/services! > My only concern is that putting it IN the file has more costs than > benefits. What am I missing here, that I don't see a cost? What software scans the lines in /etc/services beyond the comment delimiter, other than null terminator searches? So far, I've had some great advice on this issue (although I think it's time the thread took a long walk off a short pier), so I definitely have my ears open. I'm just having trouble either understanding or believing what I'm hearing. :-) 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 31 14:51:59 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 3074914DB1 for ; Sat, 31 Jul 1999 14:51:52 -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 11Ah1M-000IEH-00; Sat, 31 Jul 1999 23:50:24 +0200 From: Sheldon Hearn To: Jeroen Ruigrok/Asmodai Cc: Nik Clayton , hackers@freebsd.org Subject: Re: No elf(5) man page (docs/7914) In-reply-to: Your message of "Fri, 30 Jul 1999 23:46:26 +0200." <19990730234626.C4337@daemon.ninth-circle.org> Date: Sat, 31 Jul 1999 23:50:24 +0200 Message-ID: <70076.933457824@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote: > If no-one objects I'll submit a manpage per a.out(5) style tomorrow > for review untill it's ready for inclusion. Anyone who objects to your submissions is a woes -- real bastards wait for you to do the work before shooting you down. :-) 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 31 14:57:40 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 2CE9514CEF for ; Sat, 31 Jul 1999 14:57:32 -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 11Ah72-000IFz-00; Sat, 31 Jul 1999 23:56:16 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: Dag-Erling Smorgrav , John-Mark Gurney , James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-reply-to: Your message of "Fri, 30 Jul 1999 22:07:26 -0400." <19990730220726.A69246@mad> Date: Sat, 31 Jul 1999 23:56:16 +0200 Message-ID: <70182.933458176@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote: > b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null > b$ time grep '(vt100)|(printer)' longfile > /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) 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 31 15: 9:18 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 03A7014DCF for ; Sat, 31 Jul 1999 15:09:11 -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 11AhHN-000IJD-00; Sun, 01 Aug 1999 00:06:57 +0200 From: Sheldon Hearn To: Doug Cc: Ben Rosengart , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Fri, 30 Jul 1999 15:10:18 MST." Date: Sun, 01 Aug 1999 00:06:57 +0200 Message-ID: <70382.933458817@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote: > On some of the machines I administer I have some custom entries for > /etc/services that make more sense than the defaults, especially for > the ports > 1023. Would you need these entries if inetd let you specify port numbers instead of service names? That behaviour is a function of laziness, rather than principle. If I'm correct in my suspicion that most people only meddle with /etc/services to appease inetd's harvest of sown laziness, then the effort required to change the current behaviour will be worthwhile. 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 31 15:35:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 4B87D14DC0 for ; Sat, 31 Jul 1999 15:35:13 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id PAA64606; Sat, 31 Jul 1999 15:34:17 -0700 (PDT) From: Archie Cobbs Message-Id: <199907312234.PAA64606@bubba.whistle.com> Subject: Re: No MAXUID ? In-Reply-To: <199907301613.JAA03962@dingo.cdrom.com> from Mike Smith at "Jul 30, 1999 09:13:52 am" To: mike@smith.net.au (Mike Smith) Date: Sat, 31 Jul 1999 15:34:17 -0700 (PDT) Cc: 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 Mike Smith writes: > v2 NFS doesn't support UIDs > 65535, and UIDs around that number are > magic to it as well. There are serious security issues here (files > will appear to be owned by the wrong user). Hmm, isn't this a separate bug in itself (unrelated to pwd_mkdb)? Ie, somewhere in the kernel there should be a check for "UID wrap" that generates an error if detected. At least on the server; on the client of course it would be too late. -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 Sat Jul 31 16: 7:25 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 D12BA14E3D for ; Sat, 31 Jul 1999 16:07:22 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-158.skylink.it [194.185.55.158]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id BAA20765; Sun, 1 Aug 1999 01:06:16 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id AAA19452; Sun, 1 Aug 1999 00:56:10 +0200 (CEST) Date: Sun, 1 Aug 1999 00:56:10 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Sheldon Hearn Cc: Adrian Filipi-Martin , "Matthew D. Fuller" , Mike Smith , hackers@FreeBSD.ORG Subject: Re: No MAXUID ? In-Reply-To: <69079.933455100@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 > > I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar > > file. ... > While warnings and error messages should give me enough information > to address a problem efficiently (something on the wishlist of any > Wintendo administrator), once I know there is more than zero potentially > problematic entries, I can used cat, awk and sh to find all the culprits > if I want to. What we are looking at is a warning for potential problems with legacy tools. Yet another configuration file is not going to make our life any easier. What Sheldon proposed was to get rid of n-1 messages out of n. Maybe there is a good reason to have a config file, but this does not sound like one. Nick -- 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 Sat Jul 31 16:13:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id 882B814EA7 for ; Sat, 31 Jul 1999 16:13:12 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.55]) by smtp04.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAC320; Sun, 1 Aug 1999 01:12:59 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id AAA02560; Sun, 1 Aug 1999 00:48:38 +0200 (CEST) (envelope-from asmodai) Date: Sun, 1 Aug 1999 00:48:38 +0200 From: Jeroen Ruigrok/Asmodai To: Sheldon Hearn Cc: Jeroen Ruigrok/Asmodai , Nik Clayton , hackers@freebsd.org Subject: Re: No elf(5) man page (docs/7914) Message-ID: <19990801004838.B2214@daemon.ninth-circle.org> References: <19990730234626.C4337@daemon.ninth-circle.org> <70076.933457824@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <70076.933457824@axl.noc.iafrica.com>; from Sheldon Hearn on Sat, Jul 31, 1999 at 11:50:24PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Sheldon Hearn (sheldonh@uunet.co.za) [990801 00:35]: > > > On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote: > > > If no-one objects I'll submit a manpage per a.out(5) style tomorrow > > for review untill it's ready for inclusion. > > Anyone who objects to your submissions is a woes -- real bastards wait > for you to do the work before shooting you down. :-) Now, that gives me a good feeling =P I already started work on it... -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 16:13:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id 5C94014EA9; Sat, 31 Jul 1999 16:13:12 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.55]) by smtp04.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAB320; Sun, 1 Aug 1999 01:12:58 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id AAA02567; Sun, 1 Aug 1999 00:50:30 +0200 (CEST) (envelope-from asmodai) Date: Sun, 1 Aug 1999 00:50:30 +0200 From: Jeroen Ruigrok/Asmodai To: Nik Clayton Cc: Jeroen Ruigrok/Asmodai , Nik Clayton , hackers@freebsd.org Subject: Re: Is the _Device Driver Writers Guide_ still apropos? Message-ID: <19990801005030.C2214@daemon.ninth-circle.org> References: <19990730140411.A66986@kilt.nothing-going-on.org> <19990730234847.D4337@daemon.ninth-circle.org> <19990731192614.A7118@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990731192614.A7118@kilt.nothing-going-on.org>; from Nik Clayton on Sat, Jul 31, 1999 at 07:26:14PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nik Clayton (nik@freebsd.org) [990801 00:35]: > How does the attached patch grab you? I think it perfect... Now to find the time to wrote the sucker ;) -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 16:19:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-1.uoregon.edu (metriclient-1.uoregon.edu [128.223.172.1]) by hub.freebsd.org (Postfix) with ESMTP id C5C1414E2B; Sat, 31 Jul 1999 16:19:37 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-1.uoregon.edu (8.9.1/8.8.7) id QAA23056; Sat, 31 Jul 1999 16:18:54 -0700 (PDT) Message-ID: <19990731161854.11826@hydrogen.fircrest.net> Date: Sat, 31 Jul 1999 16:18:54 -0700 From: John-Mark Gurney To: Sheldon Hearn Cc: hackers@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <70382.933458817@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <70382.933458817@axl.noc.iafrica.com>; from Sheldon Hearn on Sun, Aug 01, 1999 at 12:06:57AM +0200 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 Sheldon Hearn scribbled this message on Aug 1: > Would you need these entries if inetd let you specify port numbers > instead of service names? I vote for allowing inetd.conf to specify a port number instead of a service name... it should be very easy to make the modification, and I'm willing to do all the work, assuming no one on -committers objects.. -- 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 Sat Jul 31 16:30: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 EF85B14E2B; Sat, 31 Jul 1999 16:30: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 RAA82025; Sat, 31 Jul 1999 17:29:05 -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 RAA94627; Sat, 31 Jul 1999 17:31:09 -0600 (MDT) Message-Id: <199907312331.RAA94627@harmony.village.org> To: Bernd Walter Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: Ben Rosengart , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 31 Jul 1999 19:34:10 +0200." <19990731193410.C18402@cicely8.cicely.de> References: <19990731193410.C18402@cicely8.cicely.de> <19990731190814.A18402@cicely8.cicely.de> Date: Sat, 31 Jul 1999 17:31:09 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990731193410.C18402@cicely8.cicely.de> Bernd Walter writes: : Maybe a set of sysctls with a switch to off only behavour would be a : better way. Actually, a better way would be to have the interfaces to the network stack that would handle this stuff w/o needing to resort to bpf. 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 31 16:31: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 3090B14E25; Sat, 31 Jul 1999 16:31: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 RAA82038; Sat, 31 Jul 1999 17:31: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 RAA94671; Sat, 31 Jul 1999 17:33:55 -0600 (MDT) Message-Id: <199907312333.RAA94671@harmony.village.org> To: Christopher Masto Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 31 Jul 1999 15:44:58 EDT." <19990731154458.A2068@netmonger.net> References: <19990731154458.A2068@netmonger.net> <199907302342.RAA85088@harmony.village.org> Date: Sat, 31 Jul 1999 17:33:55 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990731154458.A2068@netmonger.net> Christopher Masto writes: : I hope you mean "> 1". I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor "flags can't be turned off" feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels.... 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 31 16:32:30 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 5778914EE6; Sat, 31 Jul 1999 16:30: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 RAA82021; Sat, 31 Jul 1999 17:27:51 -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 RAA94611; Sat, 31 Jul 1999 17:29:55 -0600 (MDT) Message-Id: <199907312329.RAA94611@harmony.village.org> To: Bernd Walter Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 31 Jul 1999 19:08:15 +0200." <19990731190814.A18402@cicely8.cicely.de> References: <19990731190814.A18402@cicely8.cicely.de> <199907302342.RAA85088@harmony.village.org> Date: Sat, 31 Jul 1999 17:29:54 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990731190814.A18402@cicely8.cicely.de> Bernd Walter writes: : > There are no security levels > 3. I'd be happy with > 0. This is : > consistant with the meaning of "raw devices". : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. 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 31 16:42:39 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 9469714E25 for ; Sat, 31 Jul 1999 16:42:33 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18415.on.bellglobal.com [206.172.130.95]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA09196; Sat, 31 Jul 1999 19:40:49 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA02604; Sat, 31 Jul 1999 19:39:30 -0400 (EDT) (envelope-from tim) Date: Sat, 31 Jul 1999 19:39:30 -0400 From: Tim Vanderhoek To: Sheldon Hearn Cc: Dag-Erling Smorgrav , John-Mark Gurney , James Howard , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) Message-ID: <19990731193930.B2466@mad> References: <19990730220726.A69246@mad> <70182.933458176@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <70182.933458176@axl.noc.iafrica.com>; from Sheldon Hearn on Sat, Jul 31, 1999 at 11:56:16PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote: > > > b$ time ./grep -E '(vt100)|(printer)' longfile > /dev/null > > b$ time grep '(vt100)|(printer)' longfile > /dev/null > > You think that's fair? Surely you can't expect Jamie's extended regex > support to outperform GNU's simple regex support? :-) GNU has no simple regex support. Actually, neither did Jamie's by the time I did that test, but I added the -E flag to make it obvious what was going on. :) I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. -- 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 Sat Jul 31 16:53:15 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 80C7114C20 for ; Sat, 31 Jul 1999 16:53:05 -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 JAA09100; Sun, 1 Aug 1999 09:25:48 +0930 (CST) Message-Id: <199907312355.JAA09100@at.dotat.com> To: tarkhil@asteroid.svib.ru Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? In-reply-to: Your message of "Sat, 31 Jul 1999 17:59:31 +0400." <199907311359.RAA28820@shuttle.svib.ru> Date: Sun, 01 Aug 1999 09:25:48 +0930 From: Leigh Hart Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Alex, Alex Povolotsky wrote: > > I'm going to implement a large mail-box, with several hundreds of > mail-only users. They should never access anything besides their > POP3 mailboxes and change password via (SSLed) web interface. > > So, I don't want to add all of them to /etc/passwd. cucipop is fairly simple to modify (it's well structured for change) and I've managed to hack in bits of merit radius client code into it once or twice -- to authenticate POP clients from the local radius server... sendmail local delivery was a pain, I ended up fudging that with an additional aliases file mapping names to files (ugh!)... 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 Sat Jul 31 18:15:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-39.ppp.wenet.net [206.15.85.39]) by hub.freebsd.org (Postfix) with ESMTP id 54A7F14EBD for ; Sat, 31 Jul 1999 18:15:17 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id SAA27930; Sat, 31 Jul 1999 18:14:51 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 31 Jul 1999 18:14:51 -0700 (PDT) From: Alex Zepeda To: Alex Povolotsky Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? In-Reply-To: <199907311359.RAA28820@shuttle.svib.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh yeah, and check out the jail code (sections 2 and 4, I *think* -CURRENT only). - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 18:15:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-39.ppp.wenet.net [206.15.85.39]) by hub.freebsd.org (Postfix) with ESMTP id 93AB314C2D for ; Sat, 31 Jul 1999 18:15:08 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id SAA27923; Sat, 31 Jul 1999 18:14:26 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 31 Jul 1999 18:14:26 -0700 (PDT) From: Alex Zepeda To: Alex Povolotsky Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? In-Reply-To: <199907311359.RAA28820@shuttle.svib.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 31 Jul 1999, Alex Povolotsky wrote: > I'm going to implement a large mail-box, with several hundreds of mail-only > users. They should never access anything besides their POP3 mailboxes and > change password via (SSLed) web interface. > > So, I don't want to add all of them to /etc/passwd. The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with "real" users IMO is quite a bit less hackish. - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 18:35:49 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 0170914E7B for ; Sat, 31 Jul 1999 18:35:45 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-159.bellatlantic.net [151.198.117.159]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA19603; Sat, 31 Jul 1999 21:35:35 -0400 (EDT) Message-ID: <37A3A526.253BAD94@bellatlantic.net> Date: Sat, 31 Jul 1999 21:38:46 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: tarkhil@asteroid.svib.ru Cc: hackers@FreeBSD.ORG Subject: Re: Solution for mail pseudo-users? References: <199907311433.SAA30363@shuttle.svib.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Povolotsky wrote: > > <37A30852.20E5A7AF@bellatlantic.net>Sergey Babkin writes: > >> Any suggestions, anyone? > > > >Modify the POP daemon to use your mySQL database in addition to getpwent ? > >That seems to be the easiest way that should not break anything else. > > And modify sendmail to throw off mail for nonexistent users? You can unload the user list from mySQL into a Berkeley db file and modify /etc/sendmail.cf to route the mail for the users listed in this file to a special delivery agent. And this special delivery agent would be a quite straightforward modification of /usr/libexec/mail.local. A variation of this would be to modify mail.local to add the data from mySQL database to getpwent, just like POP3 does, and instruct sendmail to process the mail for the extra users by mail.local. -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 31 18:57:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 9F8E114E7B for ; Sat, 31 Jul 1999 18:57:09 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Akqm-0002Mu-00; Sat, 31 Jul 1999 19:55:45 -0600 Message-ID: <37A399C1.43B5154E@softweyr.com> Date: Sat, 31 Jul 1999 18:50:09 -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: Ville-Pertti Keinonen Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: Documenting writev(2) ENOBUFS error References: <19990731082450.7417.qmail@ns.oeno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen wrote: > > > :wes@softweyr.com (Wes Peters) writes: > > : > > :> [ENOBUFS] Insufficient system buffer space exists to complete the op- > > :> eration. > > : > > :Do you know what kind of circumstances that error *really* occurs > > :under? > > So you can get ENOBUFS not related to mbufs for UDP/local datagram > sockets, but you should never get ENOBUFS from write for TCP sockets > or local stream sockets. So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. -- "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 31 19:31:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id ED94D14F6A for ; Sat, 31 Jul 1999 19:31:48 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11AlPb-0005VN-00; Sat, 31 Jul 1999 20:31:43 -0600 Message-ID: <37A3B18D.2716CBBE@softweyr.com> Date: Sat, 31 Jul 1999 20:31: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: Jeroen Ruigrok/Asmodai Cc: Nik Clayton , hackers@FreeBSD.ORG Subject: Re: No elf(5) man page (docs/7914) References: <19990730135239.A65473@kilt.nothing-going-on.org> <19990730234626.C4337@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok/Asmodai wrote: > > * Nik Clayton (nik@nothing-going-on.demon.co.uk) [990730 23:37]: > > Hi folks, > > > > We have an a.out(5), but no elf(5) (as pointed out in docs/7914). > > > > Does anyone feel up to writing one? > > Saw it before, noticed it, placed on my to-do list. If no-one objects > I'll submit a manpage per a.out(5) style tomorrow for review untill it's > ready for inclusion. NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^) -- "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 31 19:48:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 51F9515290 for ; Sat, 31 Jul 1999 19:48:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Alf4-0007Wy-00; Sat, 31 Jul 1999 20:47:42 -0600 Message-ID: <37A3B54D.3DCB638C@softweyr.com> Date: Sat, 31 Jul 1999 20:47: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: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <8442.933363979@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > We got off onto a big tangent about switches and vlans and stuff and I > learned a number of interesting things, don't get me wrong, but we > still haven't established any consensus on the trade-offs of enabling > bpf. This wasn't meant to be a hypothetical discussion, I'm truly > trying to measure the trade-off between enabling bpf and (by some > fraction) opening things up to easier attack by sniffers in a > root-compromise situation vs not having DHCP work properly at all > after installation. > > This is a clear security vs functionality issue and I need to get a > good feel for which "cause" is ascendent here in knowing which way to > jump on the matter. Can we now hear the closing arguments from the > pro and con folks? Pro: it's not a vulnerability unless somebody has already cracked root. -- "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 31 19:50:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 0FDF314DB4; Sat, 31 Jul 1999 19:50:40 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Alhu-0007iN-00; Sat, 31 Jul 1999 20:50:39 -0600 Message-ID: <37A3B5FD.78733187@softweyr.com> Date: Sat, 31 Jul 1999 20:50: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: "Brian F. Feldman" Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... 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 Fri, 30 Jul 1999, Brian F. Feldman wrote: > > > > In that case, my argument changes to: > > "There's no good reason not to have bpf in the GENERIC kernel." > > And how about having > if (securelevel > 3) > return (EPERM); > in bpf_open()? I like this. Nice one, Greenie! ;^) Now stop replying to yourself, it's too much like... -- "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 31 19:56: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id B3FC814FFF; Sat, 31 Jul 1999 19:55:55 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Alkj-0000A8-00; Sat, 31 Jul 1999 20:53:33 -0600 Message-ID: <37A3B6AC.E399063B@softweyr.com> Date: Sat, 31 Jul 1999 20:53:32 -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: "Jordan K. Hubbard" , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <9518.933378839@zippy.cdrom.com> <199907302357.RAA85254@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 <9518.933378839@zippy.cdrom.com> "Jordan K. Hubbard" writes: > : > There are no security levels > 3. I'd be happy with > 0. This is > : > consistant with the meaning of "raw devices". > : > : Would you be willing to make this change? > > Yes. I will make this change tomorrow unless there is significant > objections that cannot be resolved in the mean time. Zounds good to me. This should be simple enough even *I* could handle 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 Sat Jul 31 19:56:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id F1BC415022; Sat, 31 Jul 1999 19:56:16 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11Alm6-0000NG-00; Sat, 31 Jul 1999 20:54:58 -0600 Message-ID: <37A3B701.851DF00B@softweyr.com> Date: Sat, 31 Jul 1999 20:54:57 -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: Matthew Dillon Cc: Sergey Babkin , Warner Losh , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... References: <199907302342.RAA85088@harmony.village.org> <37A25361.34799F96@bellatlantic.net> <199907310140.SAA95581@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :> consistant with the meaning of "raw devices". > : > :Disabling bpf it will break rarpd (and also rbootd but it is less > :important). I think such a thing should be mentioned in documentation. > : > :-SB > > Not if rarpd is started via the rc files... it would hook up to bpf > prior to the securelevel being raised. > > But I agree about the documentation. The various server documentation > as well as the inetd documentation should mention that bpf-using servers > need to be started from the rc's when securelevel is used. Do we have a list of all services that use bpf? I'm willing to edit the man pages, given a list. I guess I could just grep-o-matic here, huh? -- "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 31 21:14:52 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 F3C1F14D09; Sat, 31 Jul 1999 21:14: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 WAA82697; Sat, 31 Jul 1999 22:14:39 -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 WAA95811; Sat, 31 Jul 1999 22:16:46 -0600 (MDT) Message-Id: <199908010416.WAA95811@harmony.village.org> To: Wes Peters Subject: Re: So, back on the topic of enabling bpf in GENERIC... Cc: Matthew Dillon , Sergey Babkin , "Brian F. Feldman" , "Jordan K. Hubbard" , hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 31 Jul 1999 20:54:57 MDT." <37A3B701.851DF00B@softweyr.com> References: <37A3B701.851DF00B@softweyr.com> <199907302342.RAA85088@harmony.village.org> <37A25361.34799F96@bellatlantic.net> <199907310140.SAA95581@apollo.backplane.com> Date: Sat, 31 Jul 1999 22:16:46 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37A3B701.851DF00B@softweyr.com> Wes Peters writes: : Do we have a list of all services that use bpf? I'm willing to edit the man : pages, given a list. I guess I could just grep-o-matic here, huh? Yes. I'm also in a holding off pattern until we know the exact impact for all daemons that use this... 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 31 21:32:14 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 90BDA14D27 for ; Sat, 31 Jul 1999 21:32:11 -0700 (PDT) (envelope-from howardjp@wam.umd.edu) Received: from rac9.wam.umd.edu (root@rac9.wam.umd.edu [128.8.10.149]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA02248; Sun, 1 Aug 1999 00:28:34 -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 AAA21344; Sun, 1 Aug 1999 00:28:33 -0400 (EDT) Received: from localhost by rac9.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA21340; Sun, 1 Aug 1999 00:28:33 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: howardjp owned process doing -bs Date: Sun, 1 Aug 1999 00:28:33 -0400 (EDT) From: James Howard To: Tim Vanderhoek Cc: Sheldon Hearn , Dag-Erling Smorgrav , John-Mark Gurney , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: replacing grep(1) In-Reply-To: <19990731193930.B2466@mad> 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, 31 Jul 1999, Tim Vanderhoek wrote: > I rather hope that the rumoured newer version of H. Spencer's regex > lib is faster... Being as slow for that pattern as it is has got to > be a bug of some sort... It's actually faster to scan the file twice, > once for the first string and then for the second. If it is not, how about linking it with libregex? I realize it is GNU too, but it will be there whether or not grep gets replaced and the authors were at least kind enough to LGPL it instead. Hey, maybe someone who knows more about regular expressions than I do would feel compelled to rewrite GNU regex... :) I bet the existing Spencer libraries would be a good starting point and maybe the rumored new version is a great starting point... But that's enough hint dropping... Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 22:59:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id C438614D13 for ; Sat, 31 Jul 1999 22:59:13 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id WAA19255; Sat, 31 Jul 1999 22:58:28 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37A3E203.DE0FE656@gorean.org> Date: Sat, 31 Jul 1999 22:58:27 -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: Sheldon Hearn Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <69175.933455655@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: > > > I still haven't heard anyone answer the two key (IMO) questions. > > Your questions are easier answered in reverse order: > > > and how do you justify the additional cost to parse the file for every > > single system call that uses it? > > The information is part of the comments within the file. The cost is in > disk space, and it's cheaper than fleabites. Nowhere did I mention disk space. I agree that if that were the only issue I wouldn't be raising the objection. > > Why is it better to have this in the file than in a man page, > > Since it costs nothing to have it in /etc/services, why not leave it > there along with the information with which it's associated? The > alternative is to have a manpage that contains most of the information > in /etc/services! And why is that bad? Since when is redundancy in the documentation a problem? Like you said, disk is cheap. > > My only concern is that putting it IN the file has more costs than > > benefits. > > What am I missing here, that I don't see a cost? What software scans the > lines in /etc/services beyond the comment delimiter, other than null > terminator searches? So, how many comments are you going to add? Let's say the total parsing cost to the system for all of your additions is X. X is probably a pretty small number, I'm not arguing that point at all. Now multiply X times every packet on a highly loaded server, because that's how many times ipfw is going to need to parse the file (roughly). My point is simply that the information is valuable, but it belongs in a man page. There is no reason to add a good deal of non-functional information to a file that is used by so many parts of the system. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 23: 0:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 3B39C14D13 for ; Sat, 31 Jul 1999 23:00:25 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id XAA19265; Sat, 31 Jul 1999 23:00:15 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37A3E26F.45FCB02B@gorean.org> Date: Sat, 31 Jul 1999 23:00:15 -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: Sheldon Hearn Cc: Ben Rosengart , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <70382.933458817@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote: > > > On some of the machines I administer I have some custom entries for > > /etc/services that make more sense than the defaults, especially for > > the ports > 1023. > > Would you need these entries if inetd let you specify port numbers > instead of service names? Errr... while that may be of value to someone, it has nothing to do with the issue Ben and I were discussing. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 23:19:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw00.execpc.com (mailgw00.execpc.com [169.207.1.78]) by hub.freebsd.org (Postfix) with ESMTP id 4E63F15011 for ; Sat, 31 Jul 1999 23:19:39 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (kronos-1-145.mdm.mkt.execpc.com [169.207.86.19]) by mailgw00.execpc.com (8.9.1) id BAA17138; Sun, 1 Aug 1999 01:19:10 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 874C5135; Sun, 1 Aug 1999 01:19:37 -0500 (CDT) To: Doug Cc: Sheldon Hearn , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Sat, 31 Jul 1999 22:58:27 PDT." <37A3E203.DE0FE656@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 01:19:37 -0500 From: Jon Hamilton Message-Id: <19990801061937.874C5135@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37A3E203.DE0FE656@gorean.org>, Doug wrote: } Sheldon Hearn wrote: } > } > On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: } > } > > I still haven't heard anyone answer the two key (IMO) questions. } > } > Your questions are easier answered in reverse order: } > } > > and how do you justify the additional cost to parse the file for every } > > single system call that uses it? } > } > The information is part of the comments within the file. The cost is in } > disk space, and it's cheaper than fleabites. } } Nowhere did I mention disk space. I agree that if that were the only is } sue } I wouldn't be raising the objection. } } > > Why is it better to have this in the file than in a man page, } > } > Since it costs nothing to have it in /etc/services, why not leave it } > there along with the information with which it's associated? The } > alternative is to have a manpage that contains most of the information } > in /etc/services! } } And why is that bad? Since when is redundancy in the documentation a } problem? Like you said, disk is cheap. } } > > My only concern is that putting it IN the file has more costs than } > > benefits. } > } > What am I missing here, that I don't see a cost? What software scans the } > lines in /etc/services beyond the comment delimiter, other than null } > terminator searches? } } So, how many comments are you going to add? Let's say the total parsing } cost to the system for all of your additions is X. X is probably a pretty } small number, I'm not arguing that point at all. Now multiply X times every } packet on a highly loaded server, because that's how many times ipfw is } going to need to parse the file (roughly). No. ipfw deals with /etc/services only at startup time (any other behavior on its part would be ridiculous). } My point is simply that the information is valuable, but it belongs in } a } man page. There is no reason to add a good deal of non-functional } information to a file that is used by so many parts of the system. I think you're overestimating the cost by a considerable amount. I'm not saying that the cost is zero, but I am saying that it's close enough that the value of having the information *right there* outweighs the cost. Can you demonstrate a realistic scenario in which multiplying the volume of comments in /etc/services by, say, 10x results in a perceptible performance hit? -- 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 31 23:30: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id EB9D214FB1 for ; Sat, 31 Jul 1999 23:30:00 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id XAA19348; Sat, 31 Jul 1999 23:29:24 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37A3E944.7F28E91B@gorean.org> Date: Sat, 31 Jul 1999 23:29:24 -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: Jon Hamilton Cc: Sheldon Hearn , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services References: <19990801061937.874C5135@woodstock.monkey.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Hamilton wrote: > No. ipfw deals with /etc/services only at startup time (any other behavior on > its part would be ridiculous). That's not entirely true, there are other situations (like adding a rule, etc.) but your point is well taken. And no, I can't provide specific examples, my point is really much simpler than that. > I think you're overestimating the cost by a considerable amount. I'm > not saying that the cost is zero, but I am saying that it's close enough > that the value of having the information *right there* outweighs the cost. Anyone interested in the information will stay interested long enough to look it up in a man page. Even if the cost to the system is very very small, I think that adding it to the file is silly when it could just as easily be added to a man page. Of course, there are other benefits to having it in a man page too. The primary one being that changes/updates to the comments don't require a change to the file, and would be picked up automatically during a make world. Now you'll have to excuse me while I go sharpen my lance... Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 31 23:44:14 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 00D9A14CFB for ; Sat, 31 Jul 1999 23:44:11 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (kronos-1-145.mdm.mkt.execpc.com [169.207.86.19]) by mailgw01.execpc.com (8.9.1) id BAA15461; Sun, 1 Aug 1999 01:43:58 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 12D5C155; Sun, 1 Aug 1999 01:44:26 -0500 (CDT) To: Doug Cc: Sheldon Hearn , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Sat, 31 Jul 1999 23:29:24 PDT." <37A3E944.7F28E91B@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 01:44:26 -0500 From: Jon Hamilton Message-Id: <19990801064426.12D5C155@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37A3E944.7F28E91B@gorean.org>, Doug wrote: } Jon Hamilton wrote: } } > No. ipfw deals with /etc/services only at startup time (any other behavior } on } > its part would be ridiculous). } } That's not entirely true, there are other situations (like adding a rul } e, } etc.) but your point is well taken. And no, I can't provide specific } examples, my point is really much simpler than that. } } > I think you're overestimating the cost by a considerable amount. I'm } > not saying that the cost is zero, but I am saying that it's close enough } > that the value of having the information *right there* outweighs the cost. } } Anyone interested in the information will stay interested long enough t } o } look it up in a man page. Even if the cost to the system is very very } small, I think that adding it to the file is silly when it could just as } easily be added to a man page. It's not "just as easy" for the person looking for the information; it doesn't *get* any easier than having it right there alongside the place you're going to use it. Just because in principle someone can go look up the information somewhere else, doesn't mean that it's not easier and more friendly to [also?] have the information right there in the file. } Of course, there are other benefits to having it in a man page too. The } primary one being that changes/updates to the comments don't require a } change to the file, and would be picked up automatically during a make } world. That is true, but then again this data doesn't change that often. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message