From owner-freebsd-hackers Sun Sep 2 3:46:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from loops.nilpotent.org (loops.nilpotent.org [12.17.163.70]) by hub.freebsd.org (Postfix) with SMTP id 51BBF37B403 for ; Sun, 2 Sep 2001 03:46:02 -0700 (PDT) Received: (qmail 61136 invoked from network); 2 Sep 2001 10:45:55 -0000 Received: from unknown (root@63.100.203.228) by loops.nilpotent.org with QMTP; 2 Sep 2001 10:45:55 -0000 Received: (qmail 800 invoked by uid 500); 2 Sep 2001 10:43:44 -0000 To: freebsd-hackers@freebsd.org Subject: .so and threads, and stereo /dev/dsp, freebsd 4.3-stable. From: fn@hungry.org (Faried Nawaz) Organization: Integral Domains Date: 02 Sep 2001 15:43:21 +0459 Message-ID: Lines: 50 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I checked out quakeforge (http://www.quakeforge.net/) from their cvs tree, and tried building it on FreeBSD yesterday. It mostly worked, but I ran into two odd problems. Quakeforge uses plugins to handle sound; there is an OSS plugin for the normal system sound libs, and an SDL plugin if you have libsdl installed. It can also build other plugins (there are ones for ALSA, SGI, etc) depending on one's platform. When I build sdl from ports, its configure script sees that it can use gcc -thread, and builds libsdl with threads support. The downside is that I need to use libc_r when I link against other apps. When quakeforge builds a .so for its sdl sound plugin, it uses something like "gcc -thread -shared ... -o libsound_sdl.so"; which all nice and good, except it doesn't pull in libc_r. So, when quakeforge runs with the sdl sound plugin, it complains about not being able to find the pthread_cond_wait symbol. Is there something special I need to do to make gcc link with -lc_r for gcc -shared -thread code? Next: the OSS plugin builds but doesn't seem to work properly. At some point, it tries to set /dev/dsp to stereo, and fails: tmp = 0; if (shm->channels == 2) tmp = 1; rc = ioctl (audio_fd, SNDCTL_DSP_STEREO, &tmp); if (rc < 0) { perror (snd_dev); Con_Printf ("Could not set %s to stereo=%d", snd_dev, shm->chann els); close (audio_fd); return 0; } I have a Creative 128 card which identifies itself as pcm0: port 0x6800-0x683f irq 10 at device 10.0 on pci0 What can I do here to make quakeforge use the sound card? Faried. -- "...the first are last, the blessed get wired the best is yet to come..." self name. superstar! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 5:30:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by hub.freebsd.org (Postfix) with ESMTP id 525C037B401 for ; Sun, 2 Sep 2001 05:30:33 -0700 (PDT) Received: from heather.plazza.uk ([213.120.117.63]) by btclick.com (Netscape Messaging Server 4.05) with ESMTP id GJ1C2V02.33Y; Sun, 2 Sep 2001 13:30:31 +0100 Date: Sun, 2 Sep 2001 13:31:45 +0100 (BST) From: Nick Hibma X-X-Sender: To: Jim Bryant Cc: Matthew Emmerton , Andrew J Caines , FreeBSD Hackers Subject: Re: Mounting FAT16 on USB connected Rio 600 In-Reply-To: <3B858720.3080304@yahoo.com> Message-ID: <20010902133013.X3272-100000@heather.plazza.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. If it is an ATAPI based device it might be more work to get this device working. Nick On Thu, 23 Aug 2001, Jim Bryant wrote: > Matthew Emmerton wrote: > > >>Hackers, > >> > >>The overwhelming lack of response on -questions suggests I might do better > >>here. I though this would be an easy one. > >> > >>In short, I simply want to know what device to mount and what to do get > >>that device configured. > >> > >># usbdevs -v > >>Controller /dev/usb0: > >>addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev > >> > > 0x0100 > > > >> port 1 powered > >> port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio > >> > > Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 > > > >>/kernel: ugen0: at uhub0 port 2 (addr 2) disconnected > >>/kernel: ugen0: detached > >>/kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio > >> > > Player, rev 1.00/1.00, addr 2 > > > > Since this device is recognized by the kernel as 'ugen0', it doesn't know > > that it's a storage unit, and explains why you can't mount it. > > > > In order to use this device, you'll have to update the USB subsystem to > > recognize this device as a storage unit, and perhaps do some other code > > hacking before you can access it as a SCSI disk. > > > > Hopefully someone else on the list can provide you with more details (as in, > > how do I do what I need to do to get this thing working!) > > > For an example of how to do this, please see the changes to: > > /usr/src/sys/dev/usb/umass.c > /usr/src/sys/dev/usb/usbdevs > /usr/src/sys/dev/usb/usbdevs.h > /usr/src/sys/dev/usb/usbdevs_data.h > /usr/src/sys/cam/scsi/scsi_da.c > > These changes were just committed to solve the exact problem you are having, instead it was for the MicroTech CameraMate > CompactFlash/SmardCard reader. grep -i microtech on those files and look in the vicinity of the hits for the changes. The two .h > files don't have to be changed, just run the makefile in that directory after changing usbdevs. > > Since I don't have a Diamond MP3 player, I can't do this. Although I didn't write the changes for the MicroTech CameraMate, I did > learn a bit from the experience testing them, and it really doesn't look that hard once you figure out what is going on. > > Oh yeah, once you have it working, come back here, and post the patches asking that they be further tested and committed! It can > take a little while, but it'll be worth it for the next guy. > > You may also want to search the archives and see if anyone else has announced patches being available for testing, that's how I came > across the CameraMate patches that were just committed as a result of my testing [and asking for them to be committed until a > committer noticed I was asking]. I searched the archives, found that someone had done some patches, and advertised the fact asking > for others to test them, this was from back in April. A few weeks ago, I wrote him, and asked for a copy, although they didn't go > in straight from patch, they were easy enough to put in by hand, and generate -current patches. After testing them out and finding > they work, it was just a matter of asking for them to be committed. > > Welcome to open-source, community-supported operating systems! > > Should you choose to take this assignment, Matt, the secretary will disavow your actions if you are caught. Good luck! ;^) > > jim > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 6:19:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 8095637B407 for ; Sun, 2 Sep 2001 06:19:34 -0700 (PDT) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f82DJW2r019075; Sun, 2 Sep 2001 14:19:32 +0100 Date: Sun, 2 Sep 2001 14:19:32 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Deepak Jain Cc: "freebsd-hackers@FreeBSD. ORG" Subject: Re: Routing Performance? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 1 Sep 2001, Deepak Jain wrote: > The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of > 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD > box and all but the most specialized, packet-pushing ASICs? > > I was doing some rough figuring, and could see how a P4 with its new bus and > memory path would have trouble forwarding at least 2Gb/s. > > Am I missing something? Hard to say without testing it, but if your estimate is reasonable (could you expand on how you arrived at it? there are interested eyes) then you max out at <5Mpps, which is not core-class routing this year, but is certainly within shooting distance of Juniper's entry level. Without any proper grounds for the notion, I also suspect the ia64 might do fairly well at fast packet classification. J To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 9:55: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id ADD5237B403 for ; Sun, 2 Sep 2001 09:55:03 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f82Gt3W64592 for freebsd-hackers@freebsd.org; Sun, 2 Sep 2001 09:55:03 -0700 (PDT) (envelope-from obrien) Date: Sun, 2 Sep 2001 09:55:03 -0700 From: "David O'Brien" To: freebsd-hackers@freebsd.org Subject: signal handling descrpancy (FreeBSD oaf fix/Evolution) Message-ID: <20010902095503.A64412@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Hackers, et.al. The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, does not run on FreeBSD. The authors have made a change so that it will. However, we would like to know if FreeBSD is the odd-man-out, or if the authors were lucky Evolution ran on Solaris and Linux. ----- Forwarded message Subject: FreeBSD oaf fix Date: 02 Sep 2001 01:27:58 -0700 To: gnome-components-list@gnome.org, evolution-hackers@ximian.com Evolution has hung on startup on FreeBSD (all versions I've tested along the 4.x branch, and I assume the 5.x stuff as well) for some time now. This patch to OAF (the oaf-stable-0-6 branch) fixes the problem. I've run evolution on Linux with the fix and haven't noticed a change. Considering this fix isn't needed to keep things working on the other platforms evolution supports (linux, solaris) there's obviously some discrepancy in the handling of signal masks (specifically those which block SIGCHLD) between these platforms. Not sure which platform(s) are the ones with the bug, honestly, or if the correct behavior is even specified someplace. toshok Index: oaf-fork-server.c =================================================================== RCS file: /cvs/gnome/oaf/liboaf/oaf-fork-server.c,v retrieving revision 1.1.2.3 diff -c -u -r1.1.2.3 oaf-fork-server.c --- oaf-fork-server.c 2001/07/22 18:14:46 1.1.2.3 +++ oaf-fork-server.c 2001/09/02 08:23:59 @@ -267,6 +267,7 @@ if (od_iorstr) oaf_setenv ("OAF_OD_IOR", od_iorstr); + sigprocmask (SIG_SETMASK, &omask, NULL); close (iopipes[0]); ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 10:20:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id BD01F37B403 for ; Sun, 2 Sep 2001 10:20:24 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f82HKKg64936; Sun, 2 Sep 2001 10:20:20 -0700 (PDT) (envelope-from obrien) Date: Sun, 2 Sep 2001 10:20:19 -0700 From: "David O'Brien" To: Kevin Way Cc: freebsd-hackers@freebsd.org Subject: Re: :q:q![kevin.way@overtone.org: Re: import NetBSD rc system] Message-ID: <20010902102019.A64910@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010901151146.A53543@bean.overtone.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010901151146.A53543@bean.overtone.org>; from kevin.way@overtone.org on Sat, Sep 01, 2001 at 03:11:46PM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Sep 01, 2001 at 03:11:46PM +0000, Kevin Way wrote: > I don't see any reason to force the boot order to be maintained. As long > as the dependancies are set correctly, i'd think the boot order would be > determined solely by the output of rcorder. Correct. > What am I missing? Nothing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 10:22:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B79BD37B403 for ; Sun, 2 Sep 2001 10:22:30 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f82HME065025; Sun, 2 Sep 2001 10:22:14 -0700 (PDT) (envelope-from obrien) Date: Sun, 2 Sep 2001 10:22:14 -0700 From: "David O'Brien" To: Kris Kennaway Cc: hackers@FreeBSD.org Subject: Re: gzipped crashdumps Message-ID: <20010902102214.B64910@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010901011631.A59345@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010901011631.A59345@xor.obsecurity.org>; from kris@obsecurity.org on Sat, Sep 01, 2001 at 01:16:31AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Sep 01, 2001 at 01:16:31AM -0700, Kris Kennaway wrote: > Anyone else think this patch from NetBSD is worthwhile? As JDP said, "YES!". > --- /dev/null Sat Sep 1 01:13:34 2001 > +++ zopen.c Sat Sep 1 01:10:14 2001 > @@ -0,0 +1,39 @@ > +/* > + * Public domain stdio wrapper for libz, written by Johan Danielsson. > + */ Can we add this to libz or some other lib? These are general bits that I could see other programs wanting to use. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 10:25:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 623FF37B403 for ; Sun, 2 Sep 2001 10:25:52 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f82HPmC65042; Sun, 2 Sep 2001 10:25:48 -0700 (PDT) (envelope-from obrien) Date: Sun, 2 Sep 2001 10:25:48 -0700 From: "David O'Brien" To: Charles Shannon Hendrix Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD and Athlon Processors Message-ID: <20010902102548.C64910@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200109010033.f810XaT08748@saturn.cs.uml.edu> <20010902001113.B27595@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010902001113.B27595@widomaker.com>; from shannon@widomaker.com on Sun, Sep 02, 2001 at 12:11:15AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: > On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: > > > Well, since it didn't, I might as well explain the problem here too. > > There are at least two major problems with VIA chips: > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. -- -- David (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 Sun Sep 2 10:39:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 7C55437B405; Sun, 2 Sep 2001 10:39:08 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f82HdUY83387; Sun, 2 Sep 2001 19:39:30 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200109021739.f82HdUY83387@freebsd.dk> Subject: Re: FreeBSD and Athlon Processors In-Reply-To: <20010902102548.C64910@dragon.nuxi.com> "from David O'Brien at Sep 2, 2001 10:25:48 am" To: obrien@FreeBSD.ORG Date: Sun, 2 Sep 2001 19:39:20 +0200 (CEST) Cc: Charles Shannon Hendrix , freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems David O'Brien wrote: > On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: > > On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: > > > > > Well, since it didn't, I might as well explain the problem here too. > > > There are at least two major problems with VIA chips: > > > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > > > Are you sure about that? > > I am. I was having data coruption in a terrable way when I added a 2nd > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Hmm, dont MSI have a fixed BIOS ? I could add the code to the kernel, but do we have a placeholder for such PCI quirks ?? There is nothing new to these kind of problems, lots of chipsets has problems that are worked around in the BIOS, and frankly that is where such fixes should be IMNHO... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 11:55:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E821D37B401; Sun, 2 Sep 2001 11:55:23 -0700 (PDT) Subject: Patches for Conexant LANfinity support To: hackers@freebsd.org Date: Sun, 2 Sep 2001 11:55:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010902185523.E821D37B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Phil Kernick (Phil@Kernick.org) has been kind enough (and brave enough) to sit down and produce patches for the dc(4) driver to add support for the Conexant LANfinity miniPCI fast ethernet controller. Those of you that have laptops with this chipset can test the patches at: http://www.freebsd.org/~wpaul/conexant.patch.gz http://www.freebsd.org/~wpaul/conexant_5.0.patch.gz The latter file is for 5.0-current, the former for -stable. Apply the patch as follows: # cd /tmp # fetch http://www.freebsd.org/~wpaul/conexant.patch.gz # gunzip conexant.patch.gz # cd /sys/pci # patch < conexant.patch Then compile a new kernel and/or if_dc.ko kernel module. I intend to commit the patch for -current when I get back to work next week, however the patch for -stable will probably have to wait until the code freeze for 4.4-RELEASE is lifted (sorry guys). In the meantime, success/failure/whatever reports would be much appreciated. -Bill -- ============================================================================ -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================ "I like zees guys. Zey are fonny guys. Just keel one ofzem." -- The 3 Amigos ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 12: 6:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 85DFA37B408 for ; Sun, 2 Sep 2001 12:06:44 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f82J6eg18347; Sun, 2 Sep 2001 12:06:41 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f82J6eh02459; Sun, 2 Sep 2001 12:06:40 -0700 (PDT) (envelope-from jdp) Date: Sun, 2 Sep 2001 12:06:40 -0700 (PDT) Message-Id: <200109021906.f82J6eh02459@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: deepak@ai.net Subject: Re: Routing Performance? In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article , Deepak Jain wrote: > > The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of > 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD > box and all but the most specialized, packet-pushing ASICs? I doubt it. My understanding is that RAMBUS memory is faster for long burst transfers, but that its random access latency is actually worse than that of conventional memory. Your routing table lookups (random accesses into a huge data structure) would be slower, not faster. There is very little bulk copying in the IP forwarding path of the kernel, so the higher bandwidth of RAMBUS would not provide much benefit. I suppose it would speed up the DMA transfers between the NICs and RAM. But I still bet overall performance wouldn't be improved by the use of RAMBUS memory. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 12:52:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id F0D2237B401 for ; Sun, 2 Sep 2001 12:52:35 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f82JqXg18622; Sun, 2 Sep 2001 12:52:33 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f82JqWa02677; Sun, 2 Sep 2001 12:52:32 -0700 (PDT) (envelope-from jdp) Date: Sun, 2 Sep 2001 12:52:32 -0700 (PDT) Message-Id: <200109021952.f82JqWa02677@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: "Deepak Jain" Subject: Re: Routing Performance? In-Reply-To: <200109021906.f82J6eh02459@vashon.polstra.com> References: <200109021906.f82J6eh02459@vashon.polstra.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Correcting myself ... In article <200109021906.f82J6eh02459@vashon.polstra.com>, John Polstra wrote: > There is very little bulk copying in the IP forwarding path of the > kernel, so the higher bandwidth of RAMBUS would not provide much > benefit. I suppose it would speed up the DMA transfers between the > NICs and RAM. Actually, it wouldn't help the DMA transfers either. They'd be limited by the PCI bus bandwidth, not the memory bandwidth. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 13:39:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail35.sdc1.sfba.home.com (femail35.sdc1.sfba.home.com [24.254.60.25]) by hub.freebsd.org (Postfix) with ESMTP id 80EC537B405 for ; Sun, 2 Sep 2001 13:39:52 -0700 (PDT) Received: from home.com ([24.12.186.185]) by femail35.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010902203952.CVXB19181.femail35.sdc1.sfba.home.com@home.com> for ; Sun, 2 Sep 2001 13:39:52 -0700 Message-ID: <3B929900.808F485E@home.com> Date: Sun, 02 Sep 2001 13:39:28 -0700 From: Rob X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD and Athlon Processors References: <200109021739.f82HdUY83387@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On a related topic, I wonder whether gcc 3.0 will improve Athon compilations. I have a big number crunching program that runs just as fast on Windows2000 on my laptop(1Ghz PPro), as on my monster 1.2G Athlon DDR with FreeBSD. Rob. "Søren Schmidt" wrote: > > It seems David O'Brien wrote: > > On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: > > > On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: > > > > > > > Well, since it didn't, I might as well explain the problem here too. > > > > There are at least two major problems with VIA chips: > > > > > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > > > > > Are you sure about that? > > > > I am. I was having data coruption in a terrable way when I added a 2nd > > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. > > Hmm, dont MSI have a fixed BIOS ? > > I could add the code to the kernel, but do we have a placeholder > for such PCI quirks ?? > > There is nothing new to these kind of problems, lots of chipsets > has problems that are worked around in the BIOS, and frankly that > is where such fixes should be IMNHO... > > -Søren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- The Numeric Python EM Project www.members.home.net/europax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 14: 0:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ntlg.sibnet.ru (dns.sibnet.ru [217.70.96.34]) by hub.freebsd.org (Postfix) with ESMTP id DBE8F37B401 for ; Sun, 2 Sep 2001 14:00:13 -0700 (PDT) Received: from tlg5-ppp5.sibnet.ru (tlg5-ppp5.sibnet.ru [217.70.97.6]) by ntlg.sibnet.ru (8.9.3+Sun/8.9.3) with ESMTP id AAA13180 for ; Mon, 3 Sep 2001 00:59:50 +0400 (MSD) Date: Mon, 3 Sep 2001 03:59:47 +0600 (GMT+6) From: "Semen A. Ustimenko" X-Sender: semenu@default To: freebsd-hackers@FreeBSD.org Subject: page fault unmounting FFS from NFS-located special Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! Here is sequence leading to page fault: 1. Make special file on NFS 2. Mount FFS from this file 3. Read or write special file (for attributes to change) 4. Unmount this special 5. Enjoy ``Fatal trap 12: ...'' Like this: su-2.04# mount 192.168.5.1:/home/diskless_root on / (nfs, noatime) mfs:10 on /var (mfs, asynchronous, local) 192.168.5.1:/home on /home (nfs) su-2.04# mount /dev/ad0s2a /mnt su-2.04# dd if=/dev/ad0s2a of=/dev/null bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.003526 secs (290416 bytes/sec) su-2.04# umount /mnt ... (gdb) where #0 0xc01ae3a8 in nfs_request (vp=0xcec34a00, mrest=0xc07a8900, procnum=2, procp=0xcec39560, cred=0x0, mrp=0xcf654da8, mdp=0xcf654dac, dposp=0xcf654db0) at ../../nfs/nfs_socket.c:1006 #1 0xc01ba167 in nfs_setattrrpc (vp=0xcec34a00, vap=0xcf654e1c, cred=0x0, procp=0xcec39560) at ../../nfs/nfs_vnops.c:792 #2 0xc01b8b50 in nfs_setattr (ap=0xcf654e08) at ../../nfs/nfs_vnops.c:740 #3 0xc01c9441 in nfsspec_close (ap=0xcf654e94) at vnode_if.h:305 #4 0xc01da96a in ffs_unmount (mp=0xc21d4600, mntflags=0, p=0xcec39560) at vnode_if.h:218 #5 0xc0161ace in dounmount (mp=0xc21d4600, flags=0, p=0xcec39560) at ../../kern/vfs_syscalls.c:483 #6 0xc0161a11 in unmount (p=0xcec39560, uap=0xcf654f80) at ../../kern/vfs_syscalls.c:451 #7 0xc021f73e in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134661253, tf_esi = 134738749, tf_ebp = -1077937436, tf_isp = -815444012, tf_ebx = 0, tf_edx = 0, tf_ecx = 3, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 134522456, tf_cs = 31, tf_eflags = 663, tf_esp = -1077938584, tf_ss = 47}) at ../../i386/i386/trap.c:1126 #8 0xc02120d5 in Xint0x80_syscall () #9 0x8048442 in ?? () #10 0x8048139 in ?? () (gdb) f 0 #0 0xc01ae3a8 in nfs_request (vp=0xcec34a00, mrest=0xc07a8900, procnum=2, procp=0xcec39560, cred=0x0, mrp=0xcf654da8, mdp=0xcf654dac, dposp=0xcf654db0) at ../../nfs/nfs_socket.c:1006 1006 if (cred->cr_ngroups < 1) (gdb) print cred $1 = (struct ucred *) 0x0 the cause is code in ffs_vfsops.c:ffs_unmount() ... error = VOP_CLOSE(ump->um_devvp, fs->fs_ronly ? FREAD : FREAD|FWRITE, NOCRED, p); ^^^^^^ == NULL ... I have no good ideas how to fix this and if it is worth to be fixed... (This all was tested on 4.1 system, but it seems nothing changed since those times) Bye! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 18:20:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from blueyonder.co.uk (pcow034o.blueyonder.co.uk [195.188.53.122]) by hub.freebsd.org (Postfix) with ESMTP id 3A51837B408 for ; Sun, 2 Sep 2001 18:20:18 -0700 (PDT) Received: from mail.yahoo.com ([62.30.72.42]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 3 Sep 2001 02:20:30 +0100 Received: (from steve@localhost) by mail.yahoo.com (8.11.3/8.11.3) id f831JkD00504; Mon, 3 Sep 2001 02:19:46 +0100 (BST) (envelope-from steve) Date: Mon, 3 Sep 2001 02:19:46 +0100 From: Steve Roome To: "David O'Brien" Cc: Keith Stevenson , Leo Bicknell , freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <20010903021946.A377@dylan.home> Mail-Followup-To: Steve Roome , David O'Brien , Keith Stevenson , Leo Bicknell , freebsd-hackers@freebsd.org References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <20010831153409.A27173@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010831153409.A27173@dragon.nuxi.com>; from dev-null@NUXI.com on Fri, Aug 31, 2001 at 03:34:09PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 31, 2001 at 03:34:09PM -0700, David O'Brien wrote: > On Thu, Aug 30, 2001 at 11:21:09PM +0100, Steve Roome wrote: > > ping http://www.myserver.wherever/ > > instead of telnet wherever 80, just to see if I get a connected or > > not ? > > Do you have *ANY* clue how ping works? Ping uses ICMP packets; not TCP, > not UDP -- thus there is NO concept of ports. And what does "instead of > telnet mean"?? Again, do you have any clue how ping works? I certainly understand that ping currently works on ICMP, and that a feature enhancement to allow it to use a different type of packet might be, perhaps to some, a useful addition to its capability. Considering, for example, that an ICMP packet may take a very different route to (and hence time to reach) the destination machine comparted to a TCP/IP packet containing http information it might not be such a bad idea. e.g. Transparent web proxies. Had you read the thread of course, you may have noticed that I was merely replying to someone else who has asked about this sort of functionality. But feel free to take a dig at _me_ anyway, I won't be frightened away from it all just yet. Luckily I'm not a new user who's going to take harshly and hate us bloody arrogant unix zealots though. > To the person that wants to "traceroute http://www.myserver.wherever/", > do you have *ANY* clue how traceroute works? You cannnot use a port that > something is answering on. Again, if you've got a transparent web proxy in the way, this would be a really nice feature. I've not got a clue how to implement it though, it would probably involve changing the way rather a lot of network hardware works, I just commented on it. Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 20:12:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.halplant.com (24-168-203-47.wo.cox.rr.com [24.168.203.47]) by hub.freebsd.org (Postfix) with ESMTP id 1292C37B406 for ; Sun, 2 Sep 2001 20:12:36 -0700 (PDT) Received: by mail.halplant.com (Postfix, from userid 1001) id 2D2031F25; Sun, 2 Sep 2001 23:12:30 -0400 (EDT) Date: Sun, 2 Sep 2001 23:12:30 -0400 From: Andrew J Caines To: FreeBSD Hackers Subject: Re: Mounting FAT16 on USB connected Rio 600 Message-ID: <20010902231230.D55388@hal9000.servehttp.com> Reply-To: Andrew J Caines Mail-Followup-To: FreeBSD Hackers References: <3B858720.3080304@yahoo.com> <20010902133013.X3272-100000@heather.plazza.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010902133013.X3272-100000@heather.plazza.uk>; from n_hibma@webweaving.org on Sun, Sep 02, 2001 at 01:31:45PM +0100 Organization: H.A.L. Plant X-Powered-by: FreeBSD 4.4-RC X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nick, > As said below, modify usbdevs/umass.c to recognise your device and then > see whether it behaves. If not, try adding the quirks to scsi_da.c (no > READS_6 and no cache sync) and see whether that improves things. Since I started this, I ought to say that while I enjoy new challenges I don't think my non-existent coding skills are up to this. Given this and the fact that I am getting fed up looking at my Rio and thinking how nice it would be if I could use it thanks to some kind and talented coder who could whip up some support, I wonder if any of you fine folks would like me to send you the device to test and enjoy for a while. Would any takers please let me know if you're interested so we can work out something. -Andrew- -- ______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 2 20:35: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 5259F37B401 for ; Sun, 2 Sep 2001 20:35:02 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 0987381D01; Sun, 2 Sep 2001 22:35:02 -0500 (CDT) Date: Sun, 2 Sep 2001 22:35:02 -0500 From: Alfred Perlstein To: Andrew J Caines Cc: FreeBSD Hackers Subject: Re: Mounting FAT16 on USB connected Rio 600 Message-ID: <20010902223501.K81307@elvis.mu.org> References: <3B858720.3080304@yahoo.com> <20010902133013.X3272-100000@heather.plazza.uk> <20010902231230.D55388@hal9000.servehttp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010902231230.D55388@hal9000.servehttp.com>; from A.J.Caines@halplant.com on Sun, Sep 02, 2001 at 11:12:30PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Andrew J Caines [010902 22:12] wrote: > Nick, > > > As said below, modify usbdevs/umass.c to recognise your device and then > > see whether it behaves. If not, try adding the quirks to scsi_da.c (no > > READS_6 and no cache sync) and see whether that improves things. > > Since I started this, I ought to say that while I enjoy new challenges I > don't think my non-existent coding skills are up to this. > > Given this and the fact that I am getting fed up looking at my Rio and > thinking how nice it would be if I could use it thanks to some kind and > talented coder who could whip up some support, I wonder if any of you fine > folks would like me to send you the device to test and enjoy for a while. > > Would any takers please let me know if you're interested so we can work > out something. I can do it if you include enough packaging such that I can mail it back to you with minimal effort. I'm in the SF Bay Area. If you haven't made arrangements yet mail me priavtely and I'll give you my address. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 3: 4:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by hub.freebsd.org (Postfix) with ESMTP id BA1A837B406 for ; Mon, 3 Sep 2001 03:04:52 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Sep 2001 12:04:54 +0200 Message-ID: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> From: Gunnar Olsson To: "Freebsd Hackers (E-mail)" Subject: virtual consoles Date: Mon, 3 Sep 2001 12:04:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, To increase number of xterms I thought. only the option MAXCONS could be changed. But even though I change it from 16 to 32, I still only get 16. Someone there who can give me I quick answer? Best Regards, Gunnar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 3:18: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 044A537B401 for ; Mon, 3 Sep 2001 03:18:01 -0700 (PDT) Received: (qmail 90015 invoked by uid 1000); 3 Sep 2001 10:15:04 -0000 Date: Mon, 3 Sep 2001 13:15:04 +0300 From: Peter Pentchev To: Gunnar Olsson Cc: "Freebsd Hackers (E-mail)" Subject: Re: virtual consoles Message-ID: <20010903131504.I72833@ringworld.oblivion.bg> Mail-Followup-To: Gunnar Olsson , "Freebsd Hackers (E-mail)" References: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se>; from gunnar.olsson@xelerated.com on Mon, Sep 03, 2001 at 12:04:45PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 03, 2001 at 12:04:45PM +0200, Gunnar Olsson wrote: > Hi, > > To increase number of xterms I thought. > only the option MAXCONS could be changed. > But even though I change it from 16 to 32, > I still only get 16. > > Someone there who can give me I quick answer? I think this is the same issue that came up with a friend of mine just today. Actually, you do have 32 consoles; you just cannot switch to them using the function keys. The Alt-Fx combinations are only defined for 16 consoles (you have to use Alt-Shift-F[3-6] for the last four). Extending this would plough straight into the key definitions for the function keys themselves, which would be a Bad Thing (tm). You still can get to the additional consoles by switching to ttyvf (Alt-Shift-F6) and repeatedly pressing PrintScreen to get to the next VC. I realize that this is probably not much help, but it might be a wise thing to step back and think if you really do need all that many VC's; my friend's reply was 'I like to watch logs', but this is easily done with screen(1) - ^A 0 to ^A 9 give you 10 terminals per VC :) G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 3:19:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from zilla.emergent.com.au (www.emergent.com.au [203.27.68.30]) by hub.freebsd.org (Postfix) with ESMTP id CAEC337B40B for ; Mon, 3 Sep 2001 03:19:51 -0700 (PDT) Received: from lengdesk (syd4-56k-026.tpgi.com.au [202.7.173.26]) by zilla.emergent.com.au (8.11.3/8.9.3) with SMTP id f83AJj802362 for ; Mon, 3 Sep 2001 20:19:47 +1000 (EST) (envelope-from cmoran@emergent.com.au) Message-ID: <02e101c13461$f7dcf690$1400a8c0@lengdesk> Reply-To: "Moran, Chris" From: "Moran, Chris" To: References: <200109010033.f810XaT08748@saturn.cs.uml.edu> Subject: Re: FreeBSD and Athlon Processors Date: Mon, 3 Sep 2001 20:19:46 +1000 Organization: Emergent Technology 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This might be a dumb question, but if a fix exists in the linux world, should there not be code available? If so, could this code be integrated (by someone far more skillful than yours truly) into a future release? Cheers, ----- Original Message ----- From: "Albert D. Cahalan" To: Cc: Sent: Saturday, September 01, 2001 10:33 AM Subject: Re: FreeBSD and Athlon Processors > > Erik Greenwald writes: > > [Erik Greenwald too] > > >> I'm using both of those (iwill kk266) with a thunderbird 850, and > >> haven't had problems in fbsd. Linux flakes out a bit when I tell > >> it I have a k7 processor, so I told it I have a k6 and it works fine. > > > > sorry, this thread was supposed to stay in -stable, > > Well, since it didn't, I might as well explain the problem here too. > There are at least two major problems with VIA chips: > > Any fast PCI device (often IDE) can cause data corruption. > VIA initially blamed this on a specific sound card that would > push the bus pretty hard, then offered a Windows hack that > would disable some performance features. After some trouble > finding a contact at VIA, Linux got the same hack. If you > don't have this hack... well maybe you just got lucky or did > not notice that your data is getting trashed. (with FreeBSD's > small user base, a data corruption problem like this one > might go unnoticed for a while) > > If the CPU pushes the memory bus too hard, stuff goes wrong. > This was first noticed with some Athlon-specific assembly code > in the Linux kernel. The problem has also been seen by Windows > users running Photoshop. Sometimes the problem goes away if you > upgrade to a very large power supply. AMD has been having some > trouble running their new core on VIA motherboards; maybe the > new core hits the same problem on unoptimized code. > > So problems will be less common with an OS that doesn't push > the hardware very hard, but do you really want to trust this > junky product? Maybe next year you will upgrade to a new gcc > that generates code that is fast enough to trigger a problem, > or you will install a gigabit network card that is aggressive > with the PCI bus. Don't upgrade that CPU next year either. > > 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 Sep 3 7:43:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by hub.freebsd.org (Postfix) with ESMTP id 287E037B59E for ; Mon, 3 Sep 2001 07:43:36 -0700 (PDT) Received: from Bsdguru@aol.com by imo-m03.mx.aol.com (mail_out_v31_r1.4.) id j.159.604a23 (25309); Mon, 3 Sep 2001 10:42:57 -0400 (EDT) From: Bsdguru@aol.com Message-ID: <159.604a23.28c4f0f1@aol.com> Date: Mon, 3 Sep 2001 10:42:57 EDT Subject: Re: Routing Performance? To: deepak@ai.net Cc: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In a message dated 9/1/01 8:41:58 PM Eastern Daylight Time, deepak@ai.net writes: > The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of > 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD > box and all but the most specialized, packet-pushing ASICs? > > I was doing some rough figuring, and could see how a P4 with its new bus and > memory path would have trouble forwarding at least 2Gb/s. > Which MBs have you found/tested with 64bit PCI busses? Bryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 7:49:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 807A937B401 for ; Mon, 3 Sep 2001 07:49:10 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f83EnAR07914 for hackers@FreeBSD.ORG; Mon, 3 Sep 2001 10:49:10 -0400 (EDT) (envelope-from bicknell) Date: Mon, 3 Sep 2001 10:49:09 -0400 From: Leo Bicknell To: hackers@FreeBSD.ORG Subject: Re: Routing Performance? Message-ID: <20010903104909.B7801@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , hackers@FreeBSD.ORG References: <159.604a23.28c4f0f1@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <159.604a23.28c4f0f1@aol.com>; from Bsdguru@aol.com on Mon, Sep 03, 2001 at 10:42:57AM -0400 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 03, 2001 at 10:42:57AM -0400, Bsdguru@aol.com wrote: > Which MBs have you found/tested with 64bit PCI busses? While not Intel, I understand the Alpha port is coming along nicely: http://www.api-networks.com/products/up1000-board.shtml http://www.api-networks.com/products/up1100-board.shtml http://www.api-networks.com/products/up2000-board.shtml The last is a dual processor alpha board. Alpha motherboards have generally better memory IO, including 2.6 Gb/Sec to main memory. Unfortunately it can only take 2 gig of RAM. It has dual 64 bit PCI busses though, and can be had with dual 64bit SCSI Ultra Wide on it. Best of all, extended ATX...although it needs a large power supply (600W). -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 9:19:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.koganei.wide.ad.jp (koganei.wide.ad.jp [202.249.37.254]) by hub.freebsd.org (Postfix) with ESMTP id 863AC37B409 for ; Mon, 3 Sep 2001 09:19:11 -0700 (PDT) Received: from koganei.wide.ad.jp (koganei.wide.ad.jp [202.249.37.254]) by ns.koganei.wide.ad.jp (8.11.3/8.11.3) with ESMTP id f83GJQI28977 for ; Tue, 4 Sep 2001 01:19:26 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) Message-ID: <3B93ADEB.BD097426@koganei.wide.ad.jp> Date: Tue, 04 Sep 2001 01:21:00 +0900 From: Katsushi Kobayashi Reply-To: ikob@koganei.wide.ad.jp X-Mailer: Mozilla 4.77 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: Firewire driver available References: <3B843FF7.F9B04318@vpop.net> <200108230407.f7N47DW80946@harmony.village.org> <3B84F30B.456E9FBE@koganei.wide.ad.jp> Content-Type: text/plain; charset=iso-2022-jp; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have uploaded the updated driver at: ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-bsd-5.0-20010903 Note that this driver is an as-is basis code, so there is no document for users. Although the kernel patch includes a file name as "sbp.c", this code does not support any firewire disk devices. This code is only a sample for "firewire" bus. Also, this driver only support OHCI1394 compliant chipset, since I think 1394 I/F card are being converged to OHCI series, and it is not easy to get other chipset cards. Anyway, I would like to know whether my implementation direction would be acceptable for FreeBSD folks or Not. Katsushi Kobayashi wrote: > I have been rewriting the driver to change a generic one. Right now, a > primitive > driver is already working. I believe it is more easy to implement device > specific > function to the new one. If somebody contribute my effort, you are > welcome. > > P.S. I will upload the latest one to some place after my travel. > > Warner Losh wrote: > > > In message <3B843FF7.F9B04318@vpop.net> Matthew Reimer writes: > > : I saw this on Freshmeat the other day: > > : http://www.sfc.wide.ad.jp/DVTS/ > > : Maybe someday it can be committed? > > > > Maybe. One problem with these patches are that they only do a certain > > type of firewire stuff. They treat the firewire device as only a > > fancy network adapter. However, you can also do other things (like > > disk drives) with firewire. > > > > It does look cool. I wish I had a DV camera to play with it... > > > > Warner > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 9:40: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by hub.freebsd.org (Postfix) with ESMTP id 2299137B408 for ; Mon, 3 Sep 2001 09:40:02 -0700 (PDT) Received: from cx443070b ([24.0.36.170]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010903164001.SWSR5652.femail18.sdc1.sfba.home.com@cx443070b>; Mon, 3 Sep 2001 09:40:01 -0700 Message-ID: <000b01c13497$0f6f1a10$aa240018@cx443070b> From: "Jeremiah Gowdy" To: Cc: Subject: Via Chipset Fix Date: Mon, 3 Sep 2001 09:39:54 -0700 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I noticed the following thread about the Via chipset problem. I run a production server off a Tyan Tiger 133A, which also has this problem. Tyan does not have a BIOS fix, nor does it look like they ever will. When you contact them, they point to the Windows driver fix. They don't seem to understand there are non-Windows systems. If you could add such code to the kernel it would help me get past a 20 day uptime which has been the record this box has had. It simply panics on heavy IDE useage. / /usr /var /tmp and swap are all on very fast SCSI. /usr/home is on a large IDE UDMA66 for storage. if you go to /usr/home and do something like du -h (there's about 30 gigs in there) or ls -R or something of that nature it will almost certainly panic. We've made some adjustments and the frequency of the problem is reduced, but a kernel option for a hack on this chipset would be very worthy in the eyes of those of us stuck with these motherboards running FreeBSD. This is just a single example, I also have a KX133 which is affected, with no patch from Asus. > > > Well, since it didn't, I might as well explain the problem here too. > > > There are at least two major problems with VIA chips: > > > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > > > Are you sure about that? > > I am. I was having data coruption in a terrable way when I added a 2nd > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Hmm, dont MSI have a fixed BIOS ? I could add the code to the kernel, but do we have a placeholder for such PCI quirks ?? There is nothing new to these kind of problems, lots of chipsets has problems that are worked around in the BIOS, and frankly that is where such fixes should be IMNHO... - -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 10:18:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5151737B409 for ; Mon, 3 Sep 2001 10:18:41 -0700 (PDT) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id DEE713E31; Mon, 3 Sep 2001 10:18:40 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id D45073C12D for ; Mon, 3 Sep 2001 10:18:40 -0700 (PDT) To: hackers@freebsd.org Subject: Outdated comment in namei.h Date: Mon, 03 Sep 2001 10:18:35 -0700 From: Dima Dorfman Message-Id: <20010903171840.DEE713E31@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The following is from namei.h, around line 116 in -current (r1.30): /* * Namei parameter descriptors. * * SAVENAME may be set by either the callers of namei or by VOP_LOOKUP. * If the caller of namei sets the flag (for example execve wants to * know the name of the program that is being executed), then it must * free the buffer. If VOP_LOOKUP sets the flag, then the buffer must >>>> * be freed by either the commit routine or the VOP_ABORT routine. * SAVESTART is set only by the callers of namei. It implies SAVENAME * plus the addition of saving the parent directory that contains the * name in ni_startdir. It allows repeated calls to lookup for the * name being sought. The caller is responsible for releasing the * buffer and for vrele'ing ni_startdir. */ The line marked refers to VOP_ABORT, which doesn't exist. It probably means VOP_ABORTOP, but that was removed two years ago. Anybody care to update this comment, or suggest what to write instead of that sentence? Would s/VOP_ABORT/NDFREE/ do it? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 10:49: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 7154D37B401 for ; Mon, 3 Sep 2001 10:48:58 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f83HnIg23330; Mon, 3 Sep 2001 19:49:18 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200109031749.f83HnIg23330@freebsd.dk> Subject: Re: Via Chipset Fix In-Reply-To: <000b01c13497$0f6f1a10$aa240018@cx443070b> "from Jeremiah Gowdy at Sep 3, 2001 09:39:54 am" To: Jeremiah Gowdy Date: Mon, 3 Sep 2001 19:49:17 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Jeremiah Gowdy wrote: > I noticed the following thread about the Via chipset problem. I run a > production server off a Tyan Tiger 133A, which also has this problem. Tyan > does not have a BIOS fix, nor does it look like they ever will. When you > contact them, they point to the Windows driver fix. They don't seem to > understand there are non-Windows systems. If you could add such code to the > kernel it would help me get past a 20 day uptime which has been the record > this box has had. It simply panics on heavy IDE useage. / /usr /var /tmp > and swap are all on very fast SCSI. /usr/home is on a large IDE UDMA66 for > storage. if you go to /usr/home and do something like du -h (there's about > 30 gigs in there) or ls -R or something of that nature it will almost > certainly panic. We've made some adjustments and the frequency of the > problem is reduced, but a kernel option for a hack on this chipset would be > very worthy in the eyes of those of us stuck with these motherboards running > FreeBSD. This is just a single example, I also have a KX133 which is > affected, with no patch from Asus. Hmm, what you should try is change pci reg 0x76 of the K?133 chip, that is most likely on pci0:0:0. Then using pciconf set bit 5 to 0 and bit 4 to 1, the other bits should be left untouched. Does that help ? if not you are probably having another problem.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 11:31: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140]) by hub.freebsd.org (Postfix) with ESMTP id 888E437B40D for ; Mon, 3 Sep 2001 11:30:57 -0700 (PDT) Received: from cx443070b ([24.0.36.170]) by femail13.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010903183056.EXEL19391.femail13.sdc1.sfba.home.com@cx443070b>; Mon, 3 Sep 2001 11:30:56 -0700 Message-ID: <001901c134a6$8e071990$aa240018@cx443070b> From: "Jeremiah Gowdy" To: Cc: References: <200109031749.f83HnIg23330@freebsd.dk> Subject: Re: Via Chipset Fix Date: Mon, 3 Sep 2001 11:30:49 -0700 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hmm, what you should try is change pci reg 0x76 of the K?133 chip, that is > most likely on pci0:0:0. Then using pciconf set bit 5 to 0 and bit 4 to 1, > the other bits should be left untouched. Does that help ? if not you > are probably having another problem.... > > -Søren Could I beg of you a command line for using pciconf to do this ? I could probably figure it out, I'm not really new or anything, but I'd rather not drop this production box by doing the wrong thing. (If the proper command drops the box, I'm willing to risk that though). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 11:34: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d03.mx.aol.com (imo-d03.mx.aol.com [205.188.157.35]) by hub.freebsd.org (Postfix) with ESMTP id 0D2AC37B40C for ; Mon, 3 Sep 2001 11:34:05 -0700 (PDT) Received: from Bsdguru@aol.com by imo-d03.mx.aol.com (mail_out_v31_r1.4.) id i.1e.1a94936f (4417); Mon, 3 Sep 2001 14:33:55 -0400 (EDT) From: Bsdguru@aol.com Message-ID: <1e.1a94936f.28c52713@aol.com> Date: Mon, 3 Sep 2001 14:33:55 EDT Subject: Re: Routing Performance? To: bicknell@ufp.org Cc: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 139 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In a message dated 09/03/2001 10:49:30 AM Eastern Daylight Time, bicknell@ufp.org writes: > While not Intel, I understand the Alpha port is coming along nicely: > > http://www.api-networks.com/products/up1000-board.shtml > http://www.api-networks.com/products/up1100-board.shtml > http://www.api-networks.com/products/up2000-board.shtml > > The last is a dual processor alpha board. Alpha motherboards > have generally better memory IO, including 2.6 Gb/Sec to main memory. > Unfortunately it can only take 2 gig of RAM. It has dual 64 bit > PCI busses though, and can be had with dual 64bit SCSI Ultra Wide > on it. > Well, I thought we were talking about "new P4 processors"...how does the original poster expect to route 2 GB without a 64bit bus? Bryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 11:50:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 13B9837B408 for ; Mon, 3 Sep 2001 11:50:21 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA13347; Mon, 3 Sep 2001 12:13:43 -0700 (PDT) Message-ID: <3B93CF5A.A6EBEE2E@elischer.org> Date: Mon, 03 Sep 2001 11:43:38 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: ikob@koganei.wide.ad.jp Cc: hackers@FreeBSD.ORG Subject: Re: Firewire driver available References: <3B843FF7.F9B04318@vpop.net> <200108230407.f7N47DW80946@harmony.village.org> <3B84F30B.456E9FBE@koganei.wide.ad.jp> <3B93ADEB.BD097426@koganei.wide.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Katsushi Kobayashi wrote: > > I have uploaded the updated driver at: > > ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-bsd-5.0-20010903 This url fails for me.. > > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 12:10:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0FB0737B406 for ; Mon, 3 Sep 2001 12:10:14 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA13409; Mon, 3 Sep 2001 12:23:47 -0700 (PDT) Message-ID: <3B93D1B5.2180B4D8@elischer.org> Date: Mon, 03 Sep 2001 11:53:41 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: ikob@koganei.wide.ad.jp, hackers@FreeBSD.ORG Subject: Re: Firewire driver available References: <3B843FF7.F9B04318@vpop.net> <200108230407.f7N47DW80946@harmony.village.org> <3B84F30B.456E9FBE@koganei.wide.ad.jp> <3B93ADEB.BD097426@koganei.wide.ad.jp> <3B93CF5A.A6EBEE2E@elischer.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Katsushi Kobayashi wrote: > > > > I have uploaded the updated driver at: > > > > ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-bsd-5.0-20010903 > > This url fails for me.. found it at: ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-freebsd-5.0-20010903 > -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 12:10:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D27E637B409 for ; Mon, 3 Sep 2001 12:10:16 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA13437; Mon, 3 Sep 2001 12:28:26 -0700 (PDT) Message-ID: <3B93D2CB.6D12843B@elischer.org> Date: Mon, 03 Sep 2001 11:58:19 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: ikob@koganei.wide.ad.jp Cc: hackers@FreeBSD.ORG Subject: Re: Firewire driver available References: <3B843FF7.F9B04318@vpop.net> <200108230407.f7N47DW80946@harmony.village.org> <3B84F30B.456E9FBE@koganei.wide.ad.jp> <3B93ADEB.BD097426@koganei.wide.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Katsushi Kobayashi wrote: > > I have uploaded the updated driver at: > > ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-bsd-5.0-20010903 > > Note that this driver is an as-is basis code, so there is no document for > users. Although the kernel patch includes a file name as "sbp.c", this > code does not support any firewire disk devices. This code is only a > sample for "firewire" bus. Also, this driver only support OHCI1394 > compliant chipset, since I think 1394 I/F card are being converged to > OHCI series, and it is not easy to get other chipset cards. > > Anyway, I would like to know whether my implementation direction > would be acceptable for FreeBSD folks or Not. I have not read too much yet, but it looks well written.. The driver could do with comments. People do not know the firewire spec off by heart so descriptions as to what and why it is doing things, and what the modes mean might make it easier to review the driver. I'm tempted to add a netgraph interface to it :-) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 12:38:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 14AF737B40E for ; Mon, 3 Sep 2001 12:38:34 -0700 (PDT) Received: (qmail 76465 invoked by uid 1001); 3 Sep 2001 19:38:31 +0000 (GMT) To: mb@imp.ch Cc: Tor.Egge@fast.no, bde@zeta.org.au, bkarp@icsi.berkeley.edu, kpielorz@tdx.co.uk, sthaug@nethelp.no, atrn@zeta.org.au, roberto@eurocontrol.fr, drussell@saturn-tech.com, phk@FreeBSD.ORG, Patrick.Guelat@imp.ch, freebsd-hackers@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 31 Aug 2001 10:10:03 +0200 (CEST)" References: <20010831100828.S8426-100000@levais.imp.ch> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 03 Sep 2001 21:38:30 +0200 Message-ID: <76463.999545910@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I tested your patch and it solved our problem 100%. There's no > timedrift anymore. > > Do you think the patch will make it in 4.4R. ? We need it urgently. I can confirm the solution to the time drift problem. Our Netfinity 5600 SMP servers with Serverworks LE chipset now stay nicely in sync. Good work, Tor! Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 14: 4:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 8B60437B406; Mon, 3 Sep 2001 14:04:09 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2949466D0A; Mon, 3 Sep 2001 14:04:09 -0700 (PDT) Date: Mon, 3 Sep 2001 14:04:08 -0700 From: Kris Kennaway To: David O'Brien Cc: Kris Kennaway , hackers@FreeBSD.org Subject: Re: gzipped crashdumps Message-ID: <20010903140408.A36572@xor.obsecurity.org> References: <20010901011631.A59345@xor.obsecurity.org> <20010902102214.B64910@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010902102214.B64910@dragon.nuxi.com>; from obrien@FreeBSD.org on Sun, Sep 02, 2001 at 10:22:14AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 02, 2001 at 10:22:14AM -0700, David O'Brien wrote: > > --- /dev/null Sat Sep 1 01:13:34 2001 > > +++ zopen.c Sat Sep 1 01:10:14 2001 > > @@ -0,0 +1,39 @@ > > +/* > > + * Public domain stdio wrapper for libz, written by Johan Danielsson. > > + */ >=20 > Can we add this to libz or some other lib? These are general bits that I > could see other programs wanting to use. libz seems the most natural place, although it's a vendor library. Kris --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7k/BIWry0BWjoQKURAlP2AJ4+I4uWPR6w+6AvD1zkfk7qGaba4wCdGdJ/ LUMU8YIklq1yHKgI5u+UTXQ= =otgS -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 14:39:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from server1.lordlegacy.org (lordlegacy.org [209.61.182.147]) by hub.freebsd.org (Postfix) with ESMTP id 12B4A37B406 for ; Mon, 3 Sep 2001 14:39:17 -0700 (PDT) Received: from sharon ([216.13.207.127]) by server1.lordlegacy.org (8.9.3/8.9.3) with SMTP id LAA13323 for ; Mon, 3 Sep 2001 11:49:34 -0500 From: "Stephen Hurd" To: "FreeBSD-Hackers" Subject: Patch to allow disabling logging of arp movements through sysctl Date: Mon, 3 Sep 2001 15:43:41 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've had a problem with my DSL connection for some time now, the bridging they use appears to forward arp responses AND respond to arp requests. This ends up filling my log with: Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:06:29:d5:04:c7 to 00:10:b5:4f:d1:1a on rl0 Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:10:b5:4f:d1:1a to 00:06:29:d5:04:c7 on rl0 I've dug around on the list archives, and it looks like I'm not the first person to get annoyed at this, but I haven't found a solution. So, I've finally gotten so annoyed at my huge logs that I broke down and added the following patch to add the sysctl variable net.link.ether.inet.log_arp_movements Is this the "right place" to send the patch or should I file a PR? --- /usr/src/sys/netinet/if_ether.c.old Mon Sep 3 14:26:38 2001 +++ /usr/src/sys/netinet/if_ether.c Mon Sep 3 15:13:08 2001 @@ -497,10 +497,15 @@ * but formerly didn't normally send requests. */ static int log_arp_wrong_iface = 1; +static int log_arp_movements = 1; SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_wrong_iface, CTLFLAG_RW, &log_arp_wrong_iface, 0, "log arp packets arriving on the wrong interface"); +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_movements, CTLFLAG_RW, + &log_arp_movements, 0, + "log arp replies from MACs different the the one in the cache"); + static void in_arpinput(m) @@ -586,12 +591,13 @@ } if (sdl->sdl_alen && bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen)) { - if (rt->rt_expire) - log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", - inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", - ea->arp_sha, ":", - ac->ac_if.if_name, ac->ac_if.if_unit); - else { + if (rt->rt_expire) { + if (log_arp_movements) + log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", + inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", + ea->arp_sha, ":", + ac->ac_if.if_name, ac->ac_if.if_unit); + } else { log(LOG_ERR, "arp: %6D attempts to modify permanent entry for %s on %s%d\n", ea->arp_sha, ":", inet_ntoa(isaddr), To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 14:46:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 6221537B403 for ; Mon, 3 Sep 2001 14:46:12 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 3FBA881D01; Mon, 3 Sep 2001 16:46:07 -0500 (CDT) Date: Mon, 3 Sep 2001 16:46:07 -0500 From: Alfred Perlstein To: Stephen Hurd Cc: FreeBSD-Hackers Subject: Re: Patch to allow disabling logging of arp movements through sysctl Message-ID: <20010903164607.R81307@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from deuce@lordlegacy.org on Mon, Sep 03, 2001 at 03:43:41PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cool, I'll try to get this in later tonight, thanks for taking the time to do this. As far as methodology, filing a PR then bringing up on the lists if it goes unresolved for a couple of days is the prefered method. * Stephen Hurd [010903 16:39] wrote: > I've had a problem with my DSL connection for some time now, the bridging they > use appears to forward arp responses AND respond to arp requests. This ends up > filling my log with: > -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' '"Java" developer, like "special" Olympics, right?' - Bill Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 15: 2:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id EFE8837B407; Mon, 3 Sep 2001 15:01:58 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id B205039; Mon, 3 Sep 2001 22:42:10 +0100 (BST) Date: Mon, 3 Sep 2001 22:42:10 +0100 From: Josef Karthauser To: Stephen Hurd Cc: net@FreeBSD.org Subject: Re: Patch to allow disabling logging of arp movements through sysctl Message-ID: <20010903224210.C28738@tao.org.uk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from deuce@lordlegacy.org on Mon, Sep 03, 2001 at 03:43:41PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --XWOWbaMNXpFDWE00 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable You should really send this to net@FreeBSD.org (Cc'd). Filing a -PR is a g= ood thing too, as you can always refer to the -PR number in any mail to the list. Joe On Mon, Sep 03, 2001 at 03:43:41PM -0600, Stephen Hurd wrote: > I've had a problem with my DSL connection for some time now, the bridging= they > use appears to forward arp responses AND respond to arp requests. This e= nds up > filling my log with: >=20 > Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:06:29:d5:04:= c7 to > 00:10:b5:4f:d1:1a on rl0 > Sep 3 15:17:57 tw2 /kernel: arp: 216.13.207.2 moved from 00:10:b5:4f:d1:= 1a to > 00:06:29:d5:04:c7 on rl0 >=20 > I've dug around on the list archives, and it looks like I'm not the first= person > to get annoyed at this, but I haven't found a solution. So, I've finally= gotten > so annoyed at my huge logs that I broke down and added the following patc= h to > add the sysctl variable net.link.ether.inet.log_arp_movements >=20 > Is this the "right place" to send the patch or should I file a PR? >=20 > --- /usr/src/sys/netinet/if_ether.c.old Mon Sep 3 14:26:38 2001 > +++ /usr/src/sys/netinet/if_ether.c Mon Sep 3 15:13:08 2001 > @@ -497,10 +497,15 @@ > * but formerly didn't normally send requests. > */ > static int log_arp_wrong_iface =3D 1; > +static int log_arp_movements =3D 1; >=20 > SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_wrong_iface, CTLFLAG_= RW, > &log_arp_wrong_iface, 0, > "log arp packets arriving on the wrong interface"); > +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, log_arp_movements, CTLFLAG_RW, > + &log_arp_movements, 0, > + "log arp replies from MACs different the the one in the cache"); > + >=20 > static void > in_arpinput(m) > @@ -586,12 +591,13 @@ > } > if (sdl->sdl_alen && > bcmp((caddr_t)ea->arp_sha, LLADDR(sdl), sdl->sdl_alen)) { > - if (rt->rt_expire) > - log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", > - inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", > - ea->arp_sha, ":", > - ac->ac_if.if_name, ac->ac_if.if_unit); > - else { > + if (rt->rt_expire) { > + if (log_arp_movements) > + log(LOG_INFO, "arp: %s moved from %6D to %6D on %s%d\n", > + inet_ntoa(isaddr), (u_char *)LLADDR(sdl), ":", > + ea->arp_sha, ":", > + ac->ac_if.if_name, ac->ac_if.if_unit); > + } else { > log(LOG_ERR, > "arp: %6D attempts to modify permanent entry for %s on %s%d\n", > ea->arp_sha, ":", inet_ntoa(isaddr), >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --XWOWbaMNXpFDWE00 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuT+TIACgkQXVIcjOaxUBbOQgCfXAgDr/cKnisbgYtyLsvRIKE2 5lkAoLv44vcnXbdZaFEIJblklS2fIdXS =AW1l -----END PGP SIGNATURE----- --XWOWbaMNXpFDWE00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 16: 3: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id AA85037B426 for ; Mon, 3 Sep 2001 16:02:56 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f83N2qF66767; Mon, 3 Sep 2001 16:02:52 -0700 (PDT) (envelope-from obrien) Date: Mon, 3 Sep 2001 16:02:52 -0700 From: "David O'Brien" To: Kris Kennaway Cc: hackers@FreeBSD.org Subject: Re: gzipped crashdumps Message-ID: <20010903160252.B66151@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010901011631.A59345@xor.obsecurity.org> <20010902102214.B64910@dragon.nuxi.com> <20010903140408.A36572@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010903140408.A36572@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Sep 03, 2001 at 02:04:08PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 03, 2001 at 02:04:08PM -0700, Kris Kennaway wrote: > On Sun, Sep 02, 2001 at 10:22:14AM -0700, David O'Brien wrote: > > > > --- /dev/null Sat Sep 1 01:13:34 2001 > > > +++ zopen.c Sat Sep 1 01:10:14 2001 > > > @@ -0,0 +1,39 @@ > > > +/* > > > + * Public domain stdio wrapper for libz, written by Johan Danielsson. > > > + */ > > > > Can we add this to libz or some other lib? These are general bits that I > > could see other programs wanting to use. > > libz seems the most natural place, although it's a vendor library. Doesn't really matter. Just drop the file into src/lib/libz and modify src/lib/libz/Makefile. -- -- David (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 Mon Sep 3 17: 1:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with SMTP id 2C43237B405 for ; Mon, 3 Sep 2001 17:01:09 -0700 (PDT) Received: (qmail 1520908 invoked from network); 3 Sep 2001 18:01:04 -0600 Received: from snaresland.acl.lanl.gov (128.165.147.113) by acl.lanl.gov with SMTP; 3 Sep 2001 18:01:04 -0600 Received: (qmail 26856 invoked by uid 3499); 3 Sep 2001 18:01:04 -0600 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Sep 2001 18:01:04 -0600 Date: Mon, 3 Sep 2001 18:01:04 -0600 (MDT) From: Ronald G Minnich X-X-Sender: To: Cc: , Subject: Re: Routing Performance? In-Reply-To: <1e.1a94936f.28c52713@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 3 Sep 2001 Bsdguru@aol.com wrote: > > While not Intel, I understand the Alpha port is coming along nicely: > > > > http://www.api-networks.com/products/up1000-board.shtml > > http://www.api-networks.com/products/up1100-board.shtml > > http://www.api-networks.com/products/up2000-board.shtml > > > > The last is a dual processor alpha board. Alpha motherboards > > have generally better memory IO, including 2.6 Gb/Sec to main memory. > > Unfortunately it can only take 2 gig of RAM. It has dual 64 bit > > PCI busses though, and can be had with dual 64bit SCSI Ultra Wide > > on it. you do know that API just layed off (almost) all their alpha people, right? alpha is dead. Thank compaq any time. ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 17:38: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id E332F37B401 for ; Mon, 3 Sep 2001 17:38:03 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f840c1H18193; Mon, 3 Sep 2001 20:38:01 -0400 (EDT) (envelope-from bicknell) Date: Mon, 3 Sep 2001 20:38:01 -0400 From: Leo Bicknell To: Ronald G Minnich Cc: Bsdguru@aol.com, bicknell@ufp.org, hackers@FreeBSD.ORG Subject: Re: Routing Performance? Message-ID: <20010903203801.A18173@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Ronald G Minnich , Bsdguru@aol.com, bicknell@ufp.org, hackers@FreeBSD.ORG References: <1e.1a94936f.28c52713@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rminnich@lanl.gov on Mon, Sep 03, 2001 at 06:01:04PM -0600 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 03, 2001 at 06:01:04PM -0600, Ronald G Minnich wrote: > you do know that API just layed off (almost) all their alpha people, > right? > > alpha is dead. Thank compaq any time. > > ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) No I didn't. That's really sad. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 17:50:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 6C71A37B408 for ; Mon, 3 Sep 2001 17:50:37 -0700 (PDT) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 92FC8137FEC for ; Mon, 3 Sep 2001 20:50:36 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.4/8.9.3) id f840oal88105; Mon, 3 Sep 2001 20:50:36 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15252.9563.895072.420187@trooper.velocet.net> Date: Mon, 3 Sep 2001 20:50:35 -0400 To: freebsd-hackers@freebsd.org Subject: Promise ATA attaches UDMA66, but not UDMA33 X-Mailer: VM 6.92 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've got a promise ATA-66 controller. According to it's bios screen, the hard drives attached to it are UDMA-4 and the two CD-type devices are UDMA-2. All four devices are attached with ATA-66 cabling. I also have "hw.ata.atapi_dma=1" in loader.conf. I get the following probe: ad6: 39266MB [79780/16/63] at ata3-master UDMA66 ad7: 39266MB [79780/16/63] at ata3-slave UDMA66 acd0: DVD-ROM at ata2-master using PIO4 acd1: CD-RW at ata2-slave using PIO4 Is the driver possibly not recognising the UDMA2 state from the controller? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 20: 1:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id DFDDD37B406 for ; Mon, 3 Sep 2001 20:01:39 -0700 (PDT) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 1B39A137F36; Mon, 3 Sep 2001 23:01:33 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.4/8.9.3) id f8431Lj17749; Mon, 3 Sep 2001 23:01:21 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15252.17409.362982.53413@trooper.velocet.net> Date: Mon, 3 Sep 2001 23:01:21 -0400 To: Peter Pentchev Cc: Gunnar Olsson , "Freebsd Hackers (E-mail)" Subject: [hackers] Re: virtual consoles In-Reply-To: <20010903131504.I72833@ringworld.oblivion.bg> References: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> <20010903131504.I72833@ringworld.oblivion.bg> X-Mailer: VM 6.92 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> "Peter" == Peter Pentchev writes: Peter> On Mon, Sep 03, 2001 at 12:04:45PM +0200, Gunnar Olsson wrote: >> Hi, >> >> To increase number of xterms I thought. only the option MAXCONS >> could be changed. But even though I change it from 16 to 32, I >> still only get 16. >> >> Someone there who can give me I quick answer? Peter> Actually, you do have 32 consoles; you just cannot switch to Ok... yes ... that's true ... you should put that setting back down to something sane. The real answer is that you need to make more pty's. Given that people use lots of xterms these days, the default of setting up 16 should be examined, too. Do this as root: cd /dev ./MAKEDEV pty0 pty1 pty2 pty3 pty4 pty5 pty6 pty7 Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 20:37:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 7367537B406 for ; Mon, 3 Sep 2001 20:37:41 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f843bUY91612; Tue, 4 Sep 2001 11:37:30 +0800 (KRAST) Date: Tue, 4 Sep 2001 11:37:39 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <1144619252.20010904113739@morning.ru> To: Peter Pentchev Cc: Gunnar Olsson , "Freebsd Hackers (E-mail)" Subject: Re[2]: virtual consoles In-Reply-To: <20010903131504.I72833@ringworld.oblivion.bg> References: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> <20010903131504.I72833@ringworld.oblivion.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Mon, Sep 03, 2001 at 12:04:45PM +0200, Gunnar Olsson wrote: >> Hi, >> >> To increase number of xterms I thought. >> only the option MAXCONS could be changed. >> But even though I change it from 16 to 32, >> I still only get 16. >> >> Someone there who can give me I quick answer? > I think this is the same issue that came up with a friend of mine > just today. > Actually, you do have 32 consoles; you just cannot switch to them > using the function keys. The Alt-Fx combinations are only defined > for 16 consoles (you have to use Alt-Shift-F[3-6] for the last four). > Extending this would plough straight into the key definitions for > the function keys themselves, which would be a Bad Thing (tm). > You still can get to the additional consoles by switching to ttyvf > (Alt-Shift-F6) and repeatedly pressing PrintScreen to get to > the next VC. > I realize that this is probably not much help, but it might be > a wise thing to step back and think if you really do need all > that many VC's; my friend's reply was 'I like to watch logs', > but this is easily done with screen(1) - ^A 0 to ^A 9 give you > 10 terminals per VC :) Screen is a nice thing, I agree. Just one drawback is (Ctrl-A)*N consoles (i.e., when you use screen at local console, than log in into another box and run screen there. Local screen will see catch Ctrl-A and you're forced to type it twice or even more times :) BTW, for LINUX there are such thing as TWIN (http://linuz.sns.it/~max/twin/). I belive it could be easy ported to FreeBSD (screen shots are http://linuz.sns.it/~max/twin/twin-screenshot.gif and http://www.linux.org.ru:8101/profile/_white/gallery/bigX8ZtRj.gif) > G'luck, > Peter -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 21:35:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from damnfast.idsi.net (damnfast.idsi.net [216.91.16.5]) by hub.freebsd.org (Postfix) with ESMTP id B599237B403 for ; Mon, 3 Sep 2001 21:35:20 -0700 (PDT) Received: (from mkm@localhost) by damnfast.idsi.net (8.11.4/8.11.4) id f844ZCl06988 for freebsd-hackers@freebsd.org; Tue, 4 Sep 2001 00:35:12 -0400 (EDT) (envelope-from mkm) Date: Tue, 4 Sep 2001 00:35:11 -0400 From: Kyle Martin To: freebsd-hackers@freebsd.org Subject: lite2 syscallargs Message-ID: <20010904003511.A6939@idsi.net> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I'll go ahead and apologize if this question has already been answered, but I didn't find anything in the list archive, but I was spelunking through the source tree and i noticed the following comment in sys/sys/sysent.h: /* placeholder till we integrate rest of lite2 syscallargs changes XXX */ This first appeared Mon Feb 10 02:19:36 1997 UTC (4 years, 6 months ago) by dyson. can someone tell me what these changes are? Or is it safe to say that there aren't going to be any changes as previously planned? Oh, the comment is at line 52, just after the SCARG define if that helps. Thanks, Kyle -- /* Kyle Martin * Software Engineer, Arachnid Inc. * mkm@isdi.net */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 22:30:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 4C56F37B407 for ; Mon, 3 Sep 2001 22:30:21 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f845U4T05792; Mon, 3 Sep 2001 22:30:05 -0700 (PDT) Message-ID: <3B946708.ECB7307B@mindspring.com> Date: Mon, 03 Sep 2001 22:30:48 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: What is VT_TFS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Zhihui Zhang wrote: > > What is the file system that uses VT_TFS in vnode.h? Is it still available > on FreeBSD? Thanks. Julian added it for TRW Financial Services; the first public reference machine for 386BSD (which later became FreeBSD and NetBSD) was ref.tfs.com. TRW supported a lot of the early 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw in and had us change the version number from 0.1 to 1.0 to make it a bit easier to sell. The version numbers have been bloating ever since... The purpose of the new vnode type was to permit the VFS to own the vnode, instead of having it owned by the OS, as a contended resource (System V based systems, including UnixWare, Solaris, etc., all give ownership of vnodes to the underlying VFS, instead of having a system wide free vnode pool, like BSD uses). You'd have to ask Julian to be sure, but it may even have been done to port TFS from a System V derived system. Julian also did the original Adaptec SCSI controller support for 386BSD/NetBSD/FreeBSD... this was back when FreeBSD was really 386BSD (authored by Bill Jolitz) + the patchkit (that I originally authored, before I foisted it off on Rod Grimes, Nate Williams, and later Jordan Hubbard, and the original "Unofficial FAQ" off on to Dave Burgess. Technically, having the vnodes owned by the VFS is a much better design, since it helps scaling to get away from the global list, and you can allocated the incore inode and the vnode as a single allocation unit. It also helps with the VFS stacking issues, by avoiding a stacked layer race that can happen when you are low on the vnodes, when you have two or more stacked layers. It also lets you proxy calls across the user/kernel boundary more easily, which lets you do neat things like source level debug stacking layers entirely in user space. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23: 6:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1CB4837B403 for ; Mon, 3 Sep 2001 23:06:25 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f8465pT30048; Tue, 4 Sep 2001 08:05:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: tlambert2@mindspring.com Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: Your message of "Mon, 03 Sep 2001 22:30:48 PDT." <3B946708.ECB7307B@mindspring.com> Date: Tue, 04 Sep 2001 08:05:51 +0200 Message-ID: <30045.999583551@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3B946708.ECB7307B@mindspring.com>, Terry Lambert writes: >Zhihui Zhang wrote: >> >> What is the file system that uses VT_TFS in vnode.h? Is it still available >> on FreeBSD? Thanks. > >Julian added it for TRW Financial Services; And "TFS" means "Truly evil File System" :-) It should be nuked now of course. v_tag is only a debugging aid and it should be replaced by a "const char *" instead so that we don't need to modify just to add a filesystem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:26:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ranger.acns.ab.ca (h24-68-206-125.sbm.shawcable.net [24.68.206.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA7A37B405 for ; Mon, 3 Sep 2001 23:26:01 -0700 (PDT) Received: from colnta.acns.ab.ca (colnta [192.168.1.2]) by ranger.acns.ab.ca (8.11.6/8.11.3) with ESMTP id f846RxN00904 for ; Tue, 4 Sep 2001 00:27:59 -0600 (MDT) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id f846Qda19261 for freebsd-hackers@freebsd.org; Tue, 4 Sep 2001 00:26:39 -0600 (MDT) (envelope-from davidc) Date: Tue, 4 Sep 2001 00:26:39 -0600 From: Chad David To: freebsd-hackers@freebsd.org Subject: System build script Message-ID: <20010904002639.A19206@colnta.acns.ab.ca> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've written a script that handles the complete updating of an existing system from a cvsup through to reboot, and I thought I would check and see if anybody else was interested enough for me to make it public (maybe as a port). I also updated mergemaster to read from a config file so that it can run completely unattended. Since I almost never bother with the diffs from mergemaster, and either install the file or delete it, I just created a config that says which files to copy, and which to leave alone. To give you an idea of the the script does, here is the help: colnta.acns.ab.ca->rebuild -h Usage: rebuild [-bcehikmpvwC] -b reboot when complete -c run cvsup -e install kernel -h this help message -i install world -k build kernel -m run mergemaster -p print the config settings -v run verbose (print status to stdout) -w build world -C /path -- path for config file and the currently configurable parameters: whisper.acns.ab.ca->rebuild -bceikmwp rebuild 1.0 printing config VERBOSE yes PAGER /usr/bin/false DO_MERGEMASTER yes MERGEMASTER_ARGS -A -X -C/mnt1/devel/work/dev/rebuild/etc/mergemaster_auto.conf DO_CVSUP yes CVSUP_CONFIG /mnt1/devel/work/dev/rebuild/etc/cvsup.config CVSUP_ARGS -g -L2 MACHINE_ARCH i386 KERNCONF WHISPER DO_BACKUP_ETC yes TAR_ARGS -zcf ETC_BACKUP_FILE /tmp/rebuild_etc_backup.tgz DO_BUILD_WORLD yes BUILD_WORLD_MAKE_ARGS -j2 DO_INSTALL_WORLD yes INSTALL_WORLD_MAKE_ARGS DO_BUILD_KERNEL yes BUILD_KERNEL_MAKE_ARGS -j2 DO_INSTALL_KERNEL yes INSTALL_KERNEL_MAKE_ARGS DO_REBOOT yes The mergemaster config that I am using is a follows: ignore://etc/crontab/ ignore://etc/inetd.conf/ ignore://etc/motd/ ignore://etc/sysctl.conf/ ignore://etc/passwd/ ignore://etc/master.passwd/ ignore://etc/group/ ignore://etc/mail/sendmail.cf/ ignore://namedb/named.conf/ delete://etc/mail/mailertable.sample/ delete://etc/mail/virtusertable.sample/ delete://etc/mail/access.sample/ delete://etc/mail/freebsd.cf/ and I added the following arguments to mergemaster: -A Process files automatically from the mergemaster auto config file -C /path/auto_config_file Specify location of auto config file to use -X In the case of -A set the default to install. Normally the default is ignore If anybody cares I'd be happy to make the script source and the mergemaster patch available. -- Chad David davidc@acns.ab.ca ACNS Inc. Calgary, Alberta Canada I applied the patch twice, and it still doesn't work! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:29:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 65B5D37B408 for ; Mon, 3 Sep 2001 23:29:53 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA15850; Mon, 3 Sep 2001 23:40:25 -0700 (PDT) Message-ID: <3B94702B.8FAEDEB@elischer.org> Date: Mon, 03 Sep 2001 23:09:47 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: tlambert2@mindspring.com Cc: Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: What is VT_TFS? References: <3B946708.ECB7307B@mindspring.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Zhihui Zhang wrote: > > > > What is the file system that uses VT_TFS in vnode.h? Is it still available > > on FreeBSD? Thanks. > > Julian added it for TRW Financial Services; the first public > reference machine for 386BSD (which later became FreeBSD and > NetBSD) was ref.tfs.com. TRW supported a lot of the early > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw > in and had us change the version number from 0.1 to 1.0 to > make it a bit easier to sell. The version numbers have been > bloating ever since... I think you are thinking of other stuff I did at TFS, (we had something similar) but never committed here.. this was actually done in the following commit: ----------------------------------------------------------------------- Revision 1.36 / (download) - annotate - [select for diffs], Thu Oct 17 17:12:04 1996 UTC (4 years, 10 months ago) by jkh Branch: MAIN CVS Tags: RELENG_2_2_BP Branch point for: RELENG_2_2 Changes since 1.35: +2 -2 lines Diff to previous 1.35 (colored) Some very small changes to support Netcon's TFS filesystem. These patches were formerly applied by the Netcon installer before rebuilding your kernel. -------------------------------------------------------------------------------- -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:30:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 15DF137B40C for ; Mon, 3 Sep 2001 23:30:05 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA15859; Mon, 3 Sep 2001 23:45:14 -0700 (PDT) Message-ID: <3B94714B.8BD2DF9@elischer.org> Date: Mon, 03 Sep 2001 23:14:35 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp Cc: tlambert2@mindspring.com, Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <30045.999583551@critter> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <3B946708.ECB7307B@mindspring.com>, Terry Lambert writes: > >Zhihui Zhang wrote: > >> > >> What is the file system that uses VT_TFS in vnode.h? Is it still available > >> on FreeBSD? Thanks. > > > >Julian added it for TRW Financial Services; > > And "TFS" means "Truly evil File System" :-) not of my doing.. see other email (cvsweb is your friend) > > It should be nuked now of course. I have no idea if they (the people who added it) are still working on that filesystem. > > v_tag is only a debugging aid and it should be replaced by a "const char *" > instead so that we don't need to modify just to add a filesystem. AMEN -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:34:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id AD7D137B401 for ; Mon, 3 Sep 2001 23:34:16 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA26863; Mon, 3 Sep 2001 23:34:14 -0700 (PDT) Message-ID: <3B947612.D7AA1A7C@mindspring.com> Date: Mon, 03 Sep 2001 23:34:58 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Evan Sarmiento Cc: freebsd-hackers@freebsd.org Subject: Re: sysent in fork() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Evan Sarmiento wrote: > > Hey, > > I have a question about sysent. If a modification > to a processes p->p_sysent and associated substructures > are made, are the changes propagated through fork > to children? Yes, for fork(). You probably wanted to ask about exec(), though... the answer for exec() is "it uses the brand on the exec()'ed binary to decide which call table to use". This probably means that you are running into a problem with an unbranded Linux binary being run from another Linux binary... alternately, you might be confusing the path prefix lookup for branded binaries, which causes an path search to look in the /compat/linux directory before looking under /, if what is being run is a Linux binary. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:47:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id B3B0537B405; Mon, 3 Sep 2001 23:47:31 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA20459; Mon, 3 Sep 2001 23:47:18 -0700 (PDT) Message-ID: <3B947922.F8B98DBD@mindspring.com> Date: Mon, 03 Sep 2001 23:48:02 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Jakovenko" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010902054617.A47742@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Vladimir A. Jakovenko" wrote: > > Hello! > > According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than > one socket to the same port (even with same source ip address). But quick > look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will > work as expected (data stream duplicate) only on multicast/broadcast local > addresses. Please pay attention to the following code fragment comments: [ ... ] > Is there still any real need in such backward compatibility? Can such > functionality be added (fixed) with possibility to switch it off using > sysctl or kernel-build option? > > I find such possibility realy useful at least for NetFlow data > processing and believe that it would be useful for many UDP-based > protocols. Bound UDP sockets have always been problematic; there's a lot of code out there that depnds on the historical behaviour for unicast, unfortunately, including a number of commercial applications that run on FreeBSD (e.g. Real Server). If you look at that code for any length of time, you will get to see it as an armpit: it's not a good place to stick your nose, and it tends to smell to high heaven. At my current job, I'm up to my elbows in it... Similarly, there are a number of bugs in the TCP sockets as well; specifically, there's a problem with all sockets being treated as being in the same collision domain, when doing automatic port assignment. This limits you to 65535 oubound TCP connections, even though you have multiple IP aliases on an interface (theoretically, you should get 64k connections per IP address, if you bind _not_ to IN_ADDR_ANY, but instead use a specific port, but the hash is broken). There's also another problem with the cloned route, in the case you get a redirect, since the clone is not properly updated (e.g. do a ping, get a redirect, and notice that you keep getting the redirect until you stop and restart the ping, after which you get the correct route record: there was a recent thread on this in -current, where someone ICMP'ed themselves to death using multiple Gigabit interfaces as unbonded non-VLAN equivalence routes). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 3 23:57:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 5568337B406 for ; Mon, 3 Sep 2001 23:57:39 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id XAA07265; Mon, 3 Sep 2001 23:57:35 -0700 (PDT) Message-ID: <3B947B8B.54D0ED7A@mindspring.com> Date: Mon, 03 Sep 2001 23:58:19 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Faried Nawaz Cc: freebsd-hackers@freebsd.org Subject: Re: .so and threads, and stereo /dev/dsp, freebsd 4.3-stable. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Faried Nawaz wrote: > Next: the OSS plugin builds but doesn't seem to work properly. At > some point, it tries to set /dev/dsp to stereo, and fails: > > tmp = 0; > if (shm->channels == 2) > tmp = 1; > rc = ioctl (audio_fd, SNDCTL_DSP_STEREO, &tmp); > if (rc < 0) { > perror (snd_dev); > Con_Printf ("Could not set %s to stereo=%d", snd_dev, shm->chann > els); > close (audio_fd); > return 0; > } > > I have a Creative 128 card which identifies itself as > > pcm0: port 0x6800-0x683f irq 10 at device 10.0 on pci0 > > What can I do here to make quakeforge use the sound card? I've seen something like this before. The cause was the sourd card being opened twice, and the second open failing, without the programmer checking the open return code in the second case. The fix was to use the already open fd, instead of reopening the card. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0: 3:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 579ED37B403 for ; Tue, 4 Sep 2001 00:03:24 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f8473fY02926; Tue, 4 Sep 2001 09:03:41 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200109040703.f8473fY02926@freebsd.dk> Subject: Re: Promise ATA attaches UDMA66, but not UDMA33 In-Reply-To: <15252.9563.895072.420187@trooper.velocet.net> "from David Gilbert at Sep 3, 2001 08:50:35 pm" To: David Gilbert Date: Tue, 4 Sep 2001 09:02:40 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems David Gilbert wrote: > I've got a promise ATA-66 controller. According to it's bios screen, > the hard drives attached to it are UDMA-4 and the two CD-type devices > are UDMA-2. All four devices are attached with ATA-66 cabling. I > also have "hw.ata.atapi_dma=1" in loader.conf. > > I get the following probe: > > ad6: 39266MB [79780/16/63] at ata3-master UDMA66 > ad7: 39266MB [79780/16/63] at ata3-slave UDMA66 > acd0: DVD-ROM at ata2-master using PIO4 > acd1: CD-RW at ata2-slave using PIO4 > > Is the driver possibly not recognising the UDMA2 state from the > controller? The Promise controllers doesn't support ATAPI DMA, or at least the older ones didn't, and some require special code, however the newer ones (TX2) should support it. I have this on my list for the newer Promises, watch -current for when it hits the tree... -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 Sep 4 0: 9: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 51EFF37B40B; Tue, 4 Sep 2001 00:09:01 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA13547; Tue, 4 Sep 2001 00:09:00 -0700 (PDT) Message-ID: <3B947E37.D3E11452@mindspring.com> Date: Tue, 04 Sep 2001 00:09:43 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: signal handling descrpancy (FreeBSD oaf fix/Evolution) References: <20010902095503.A64412@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > Hi Hackers, et.al. > > The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, > does not run on FreeBSD. The authors have made a change so that it will. > However, we would like to know if FreeBSD is the odd-man-out, or if the > authors were lucky Evolution ran on Solaris and Linux. There's some oddity in FreeBSD's SIGCHLD handling. If you ignore the signal, it's supposed to "magically reap" when child processes exit, according to my copy of "Go SOLO 2" (The Single UNIX Specification). FreeBSD makes you explicitly set the handler/mask the signal yourself. Technically, either way could be considered correct; there was a patch to -current that "fixed" FreeBSD; I'm not sure if it was MFC'ed to the 4.4 branch or not... There was a big discussion on -current about "proper handling", if I recall correctly. FWIW, I opposed the change (which implied SA_CLDWAIT, I think, with no way to turn it off to get historical behaviour for programs which needed it). I hate POSIX signal handling... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0:11:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 32BDF37B407 for ; Tue, 4 Sep 2001 00:11:47 -0700 (PDT) Received: (from root@localhost) by bugz.infotecs.ru (8.11.6/8.11.4) id f847BWT53165; Tue, 4 Sep 2001 11:11:32 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200109040711.f847BWT53165@bugz.infotecs.ru> Subject: Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat]) To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 4 Sep 2001 11:11:31 +0400 (MSD) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Matt Dillon" at Aug 31, 2001 11:55:10 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I comitted a fix to -current two months ago. It's still in my -stable > tree... if Jordan gives the O.K., I will MFC it to -stable. > > -Matt Erm, sorry, but what does MFC mean here ? I see this term used a lot and I can even guess what it stands for, but I may get it incorrectly ... Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0:17:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id D746C37B403; Tue, 4 Sep 2001 00:17:41 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA26446; Tue, 4 Sep 2001 00:17:40 -0700 (PDT) Message-ID: <3B948040.29033A09@mindspring.com> Date: Tue, 04 Sep 2001 00:18:25 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Paul Cc: hackers@FreeBSD.ORG Subject: Re: general ethernet driver changes References: <20010902185523.E821D37B401@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Did you have opportunity to play with the soft interrupt coalescing we discussed? I was able to remove a third of the interrupt overhead from the Tigon III driver, using the approach we discussed at the user group meeting two months back. It looks to be a serious win... and it appears to be applicable to almost every driver you've written (it's about a 12 line change per driver). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0:21:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 6B1A037B406 for ; Tue, 4 Sep 2001 00:21:19 -0700 (PDT) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id f847L7u13218117; Tue, 4 Sep 2001 11:21:07 +0400 (MSD) Date: Tue, 4 Sep 2001 11:21:02 +0400 (MSD) From: Maxim Konovalov To: "Eugene L. Vorokov" Cc: Matt Dillon , Subject: Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat]) In-Reply-To: <200109040711.f847BWT53165@bugz.infotecs.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Sep 2001, Eugene L. Vorokov wrote: > > I comitted a fix to -current two months ago. It's still in my -stable > > tree... if Jordan gives the O.K., I will MFC it to -stable. > > > > -Matt > > Erm, sorry, but what does MFC mean here ? I see this term used a lot and > I can even guess what it stands for, but I may get it incorrectly ... Merged From Current. > Regards, > Eugene > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0:22:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 31D8837B40E; Tue, 4 Sep 2001 00:22:07 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA02853; Tue, 4 Sep 2001 00:22:05 -0700 (PDT) Message-ID: <3B948149.1FE08591@mindspring.com> Date: Tue, 04 Sep 2001 00:22:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@freebsd.org Cc: Charles Shannon Hendrix , freebsd-hackers@freebsd.org Subject: Re: FreeBSD and Athlon Processors References: <200109010033.f810XaT08748@saturn.cs.uml.edu> <20010902001113.B27595@widomaker.com> <20010902102548.C64910@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > > Well, since it didn't, I might as well explain the problem here too. > > > There are at least two major problems with VIA chips: > > > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > > > Are you sure about that? > > I am. I was having data coruption in a terrable way when I added a 2nd > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Are you sure it's not just a CMD640 IDE controller? They are known to have issues; Linux has a patch... FreeBSD used to, but I think it got yanked out, or was just turned off by default. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 0:25:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4C9A937B40B; Tue, 4 Sep 2001 00:25:55 -0700 (PDT) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id f847Nem76568; Tue, 4 Sep 2001 00:23:40 -0700 (PDT) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200109040723.f847Nem76568@iguana.aciri.org> Subject: Re: general ethernet driver changes In-Reply-To: <3B948040.29033A09@mindspring.com> from Terry Lambert at "Sep 4, 2001 0:18:25 am" To: tlambert2@mindspring.com Date: Tue, 4 Sep 2001 00:23:40 -0700 (PDT) Cc: wpaul@FreeBSD.ORG, hackers@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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Did you have opportunity to play with the soft interrupt > coalescing we discussed? Did this message just leak to a mailing list, or would you be able to expand this (or pass a pointer to mailing lists where this was discussed) ? thanks luigi > I was able to remove a third of the interrupt overhead > from the Tigon III driver, using the approach we discussed > at the user group meeting two months back. > > It looks to be a serious win... and it appears to be > applicable to almost every driver you've written (it's > about a 12 line change per driver). > > -- Terry > > 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 Sep 4 0:54:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 79A7B37B403 for ; Tue, 4 Sep 2001 00:54:42 -0700 (PDT) Received: (qmail 62109 invoked by uid 1000); 4 Sep 2001 07:45:53 -0000 Date: Tue, 4 Sep 2001 10:45:53 +0300 From: Peter Pentchev To: Igor Podlesny Cc: Gunnar Olsson , "Freebsd Hackers (E-mail)" Subject: Re: virtual consoles Message-ID: <20010904104553.B61594@ringworld.oblivion.bg> Mail-Followup-To: Igor Podlesny , Gunnar Olsson , "Freebsd Hackers (E-mail)" References: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> <20010903131504.I72833@ringworld.oblivion.bg> <1144619252.20010904113739@morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1144619252.20010904113739@morning.ru>; from poige@morning.ru on Tue, Sep 04, 2001 at 11:37:39AM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 04, 2001 at 11:37:39AM +0800, Igor Podlesny wrote: [snip] > > Screen is a nice thing, I agree. Just one drawback is (Ctrl-A)*N > consoles (i.e., when you use screen at local console, than log in > into another box and run screen there. Local screen will see catch > Ctrl-A and you're forced to type it twice or even more times :) And then, of course, there is always the 'escape' screenrc command, allowing you to set a different command character for each session :) Though.. this would probably lead to a nightmare of misdirected key presses.. But still, it is there. G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 1:13:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id AADDB37B405 for ; Tue, 4 Sep 2001 01:13:36 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA13253; Tue, 4 Sep 2001 01:13:32 -0700 (PDT) Message-ID: <3B948D58.EDCD5396@mindspring.com> Date: Tue, 04 Sep 2001 01:14:16 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Zhihui Zhang , freebsd-hackers@freebsd.org Subject: Re: What is VT_TFS? References: <3B946708.ECB7307B@mindspring.com> <3B94702B.8FAEDEB@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > > What is the file system that uses VT_TFS in vnode.h? Is it > > > still available on FreeBSD? Thanks. > > > > Julian added it for TRW Financial Services; the first public > > reference machine for 386BSD (which later became FreeBSD and > > NetBSD) was ref.tfs.com. TRW supported a lot of the early > > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw > > in and had us change the version number from 0.1 to 1.0 to > > make it a bit easier to sell. The version numbers have been > > bloating ever since... > > I think you are thinking of other stuff I did at TFS, (we had > something similar) but never committed here.. this was actually > done in the following commit: Hunh. I could have sworn that that was your baby... I guess I'm just remembering a conversation about the "something similar". In any case, it's useful to let a VFS layer "own" its vnodes... so I'd leave it there: never know when you might need it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 1:37:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id A1B7E37B405; Tue, 4 Sep 2001 01:37:05 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f848abT02233; Tue, 4 Sep 2001 10:36:37 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, hackers@freebsd.org Subject: Junior Kernel Hacker task: improve vnode->v_tag From: Poul-Henning Kamp Date: Tue, 04 Sep 2001 10:36:37 +0200 Message-ID: <2231.999592597@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Assignment: The v_tag element in struct vnode is a debugging aid, but unfortunately it is implemented in a way which means that adding a filesystem means modifying the definition in . Convert the v_tag to an "const char *" and have the filesystems put their name in there instead. The v_tag has been abused a few places, easily recognizable by the fact that the kernel should never inspect the value of v_tag. These places should be easily changeable to use the new representation. Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 1:48:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 83AFC37B405; Tue, 4 Sep 2001 01:48:45 -0700 (PDT) Received: from mindspring.com (dialup-209.247.140.38.Dial1.SanJose1.Level3.net [209.247.140.38]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA28947; Tue, 4 Sep 2001 01:48:43 -0700 (PDT) Message-ID: <3B949598.FA3DF10E@mindspring.com> Date: Tue, 04 Sep 2001 01:49:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: wpaul@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: general ethernet driver changes References: <200109040723.f847Nem76568@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > > Did you have opportunity to play with the soft interrupt > > coalescing we discussed? > > Did this message just leak to a mailing list, or would you > be able to expand this (or pass a pointer to mailing lists > where this was discussed) ? Ignore the man behind the curtain... 8-) Seriously, it was at two BABUG (Bay Area BSD User's Group) meetings; no big secret. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 2:42:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tarakan-network.com (chojin.adsl.nerim.net [62.4.22.98]) by hub.freebsd.org (Postfix) with ESMTP id 7A24B37B40C; Tue, 4 Sep 2001 02:42:29 -0700 (PDT) Received: from chojin (chojin.lan.tarakan-network.com [192.168.69.2]) by tarakan-network.com (8.11.6/8.11.3) with SMTP id f849geo53888; Tue, 4 Sep 2001 11:42:40 +0200 (CEST) (envelope-from freebsd@tarakan-network.com) Message-ID: <011701c13525$f63030e0$0245a8c0@chojin> From: "Chojin" To: , Subject: Snmp problems Date: Tue, 4 Sep 2001 11:42:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg It says: SNMP Error: no response received SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) community: "TMRTGCHO" request ID: 1484981548 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on TMRTGCHO@127.0.0.1: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' SNMP Error: no response received SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) community: "TMRTGCHO" request ID: 1484981549 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on TMRTGCHO@127.0.0.1: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' ... It's very strange because I didn't modify anything on snmp configuration. Then I can't have trafic stats for my interfaces... I killed and restarted snmpd but no change. Anyone has got an idea ? Regards, Chojin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 2:56:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sunny.pacific.net.sg (sunny.pacific.net.sg [203.120.90.127]) by hub.freebsd.org (Postfix) with ESMTP id ECE1F37B403; Tue, 4 Sep 2001 02:56:45 -0700 (PDT) Received: from smtp2.pacific.net.sg (smtp2.pacific.net.sg [203.120.90.169]) by sunny.pacific.net.sg with ESMTP id f849uhV25269; Tue, 4 Sep 2001 17:56:43 +0800 (SGT) Received: from pacific.net.sg ([203.208.143.98]) by smtp2.pacific.net.sg with ESMTP id f849ugf28190; Tue, 4 Sep 2001 17:56:43 +0800 Message-ID: <3B94A6BE.3070709@pacific.net.sg> Date: Tue, 04 Sep 2001 18:02:38 +0800 From: Kelvin Ng Chee Hoong User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: zh-TW,en MIME-Version: 1.0 To: Chojin Cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Snmp problems References: <011701c13525$f63030e0$0245a8c0@chojin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Do your community string correct ? Do you change community string recently ? Do you configure [Target] tag in mrtg.conf point to correct MIB ? Chojin wrote: >Hello, > >Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg >It says: >SNMP Error: >no response received >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) > community: "TMRTGCHO" > request ID: 1484981548 > PDU bufsize: 8000 bytes > timeout: 2s > retries: 5 > backoff: 1) > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 >SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on >TMRTGCHO@127.0.0.1: > at /usr/local/bin/mrtg line 1485 >WARNING: Expected a number but got '' >WARNING: Expected a number but got '' > >SNMP Error: >no response received >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) > community: "TMRTGCHO" > request ID: 1484981549 > PDU bufsize: 8000 bytes > timeout: 2s > retries: 5 > backoff: 1) > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 >SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on >TMRTGCHO@127.0.0.1: > at /usr/local/bin/mrtg line 1485 >WARNING: Expected a number but got '' >WARNING: Expected a number but got '' >... > >It's very strange because I didn't modify anything on snmp configuration. >Then I can't have trafic stats for my interfaces... > >I killed and restarted snmpd but no change. > >Anyone has got an idea ? > >Regards, > >Chojin > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" 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 Sep 4 3: 1:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tarakan-network.com (chojin.adsl.nerim.net [62.4.22.98]) by hub.freebsd.org (Postfix) with ESMTP id B7E9937B448; Tue, 4 Sep 2001 03:01:14 -0700 (PDT) Received: from chojin (chojin.lan.tarakan-network.com [192.168.69.2]) by tarakan-network.com (8.11.6/8.11.3) with SMTP id f84A1Jo55900; Tue, 4 Sep 2001 12:01:19 +0200 (CEST) (envelope-from freebsd@tarakan-network.com) Message-ID: <01d201c13528$910e6c10$0245a8c0@chojin> From: "Chojin" To: "Kelvin Ng Chee Hoong" Cc: , References: <011701c13525$f63030e0$0245a8c0@chojin> <3B94A6BE.3070709@pacific.net.sg> Subject: Re: Snmp problems Date: Tue, 4 Sep 2001 12:01:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Problems started since yesterday and last time I modified community and other things few weeks ago. When I try to cfgmaker, it displays the same errors. ----- Original Message ----- From: "Kelvin Ng Chee Hoong" To: "Chojin" Cc: ; Sent: Tuesday, September 04, 2001 12:02 PM Subject: Re: Snmp problems > Do your community string correct ? Do you change community string > recently ? Do you configure [Target] tag in mrtg.conf point to correct > MIB ? > > > Chojin wrote: > > >Hello, > > > >Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg > >It says: > >SNMP Error: > >no response received > >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) > > community: "TMRTGCHO" > > request ID: 1484981548 > > PDU bufsize: 8000 bytes > > timeout: 2s > > retries: 5 > > backoff: 1) > > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 > >SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on > >TMRTGCHO@127.0.0.1: > > at /usr/local/bin/mrtg line 1485 > >WARNING: Expected a number but got '' > >WARNING: Expected a number but got '' > > > >SNMP Error: > >no response received > >SNMPv1_Session (remote host: "127.0.0.1" [127.0.0.1].161) > > community: "TMRTGCHO" > > request ID: 1484981549 > > PDU bufsize: 8000 bytes > > timeout: 2s > > retries: 5 > > backoff: 1) > > at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 > >SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on > >TMRTGCHO@127.0.0.1: > > at /usr/local/bin/mrtg line 1485 > >WARNING: Expected a number but got '' > >WARNING: Expected a number but got '' > >... > > > >It's very strange because I didn't modify anything on snmp configuration. > >Then I can't have trafic stats for my interfaces... > > > >I killed and restarted snmpd but no change. > > > >Anyone has got an idea ? > > > >Regards, > > > >Chojin > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-questions" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 Sep 4 4: 3: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tarakan-network.com (chojin.adsl.nerim.net [62.4.22.98]) by hub.freebsd.org (Postfix) with ESMTP id 132AA37B403; Tue, 4 Sep 2001 04:02:56 -0700 (PDT) Received: from chojin (chojin.lan.tarakan-network.com [192.168.69.2]) by tarakan-network.com (8.11.6/8.11.3) with SMTP id f84B37o62585; Tue, 4 Sep 2001 13:03:07 +0200 (CEST) (envelope-from freebsd@tarakan-network.com) Message-ID: <024e01c13531$33498390$0245a8c0@chojin> From: "Chojin" To: , Subject: ipnat, ipf, ipfstat devices not configured Date: Tue, 4 Sep 2001 13:03:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Since I recompiled my system and kernel (4.3-RELEASE) I can't use ipnat ipf and ipfstat: #ipnat /dev/ipnat: open: Device not configured #ipf -Fa -f /etc/ipf.rules open device: Device not configured ioctl(SIOCIPFFL): Bad file descriptor open device: Device not configured 2:ioctl(add/insert rule): Bad file descriptor 3:ioctl(add/insert rule): Bad file descriptor #ipfstat open: Device not configured I did all things needed as MAKEDEV all (done by mergemaster). There are all options unchanged in my kernel configuration file: options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging options IPFIREWALL options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT I don't understand why there is this problem. Anyone could help me ? Chojin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 4:58:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f270.law8.hotmail.com [216.33.240.145]) by hub.freebsd.org (Postfix) with ESMTP id 8BFF737B40D for ; Tue, 4 Sep 2001 04:58:13 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Sep 2001 04:58:13 -0700 Received: from 202.129.101.73 by lw8fd.law8.hotmail.msn.com with HTTP; Tue, 04 Sep 2001 11:58:13 GMT X-Originating-IP: [202.129.101.73] From: "Tim Allshorn" To: freebsd-hackers@freeBSD.org Subject: subscriber incoming Date: Tue, 04 Sep 2001 21:58:13 +1000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Sep 2001 11:58:13.0465 (UTC) FILETIME=[DFF12C90:01C13538] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG subscribe freebsd-hackers _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 5:13:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from habanero.hesketh.net (habanero.hesketh.net [66.45.6.196]) by hub.freebsd.org (Postfix) with ESMTP id B921137B409; Tue, 4 Sep 2001 05:13:42 -0700 (PDT) Received: from mutt.rcfile.org (rdu57-26-120.nc.rr.com [66.57.26.120]) by habanero.hesketh.net (8.11.1/8.11.1) with ESMTP id f84CDdo11116; Tue, 4 Sep 2001 08:13:39 -0400 X-Received-From: brent@mutt.rcfile.org X-Delivered-To: phk@FreeBSD.ORG X-Spam-Filter: check_local@habanero.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Received: (from brent@localhost) by mutt.rcfile.org (8.11.6/8.11.5) id f84CDbu17179; Tue, 4 Sep 2001 08:13:37 -0400 (EDT) (envelope-from brent) Date: Tue, 4 Sep 2001 08:13:37 -0400 From: Brent Verner To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010904081337.A8968@rcfile.org> References: <2231.999592597@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2231.999592597@critter> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in . | | Convert the v_tag to an "const char *" and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment. #include I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... These uses /seem/ fairly significant due to the fact that the v_tag is being used to determine capabilities of the vnode in question. How should this be worked around? It would be fairly trivial to change v_tag to v_feature (or similar) then add the v_tag as you propose. I suggest this since those _tests_ for features should IMO not be done with a char[] operation, since that would (in my ignorant estimation) have a very negative effect on fs performance. Of course, my suggested v_feature hack would again require changing vnode.h for new features, but this is (assumedly) less frequent than modifying for file systems. I'll work on this this weekend, and (hopefully) follow thru with a patch. cheers. Brent -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 5:27:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 342E037B408; Tue, 4 Sep 2001 05:27:32 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f84CR0T12841; Tue, 4 Sep 2001 14:27:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brent Verner Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: Your message of "Tue, 04 Sep 2001 08:13:37 EDT." <20010904081337.A8968@rcfile.org> Date: Tue, 04 Sep 2001 14:27:00 +0200 Message-ID: <12839.999606420@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: >| >| Assignment: >| >| The v_tag element in struct vnode is a debugging aid, but unfortunately >| it is implemented in a way which means that adding a filesystem means >| modifying the definition in . >| >| Convert the v_tag to an "const char *" and have the filesystems put >| their name in there instead. >| >| The v_tag has been abused a few places, easily recognizable by the fact >| that the kernel should never inspect the value of v_tag. >| These places should be easily changeable to use the new representation. >| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment. > >#include > >I've done a /cursory/ look over how this v_tag is used. I'm not sure >this is a simple/clean as you propose, since this is used in the >IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 5:31:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by hub.freebsd.org (Postfix) with ESMTP id DC37437B408; Tue, 4 Sep 2001 05:31:31 -0700 (PDT) Received: from laptop.6bone.nl (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id f84CVNG19548; Tue, 4 Sep 2001 14:31:23 +0200 Received: (nullmailer pid 22624 invoked by uid 1000); Tue, 04 Sep 2001 12:31:23 -0000 Date: Tue, 4 Sep 2001 14:31:23 +0200 From: Mark Santcroos To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010904143123.A534@laptop.6bone.nl> References: <20010904081337.A8968@rcfile.org> <12839.999606420@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <12839.999606420@critter>; from phk@critter.freebsd.dk on Tue, Sep 04, 2001 at 02:27:00PM +0200 X-Handles: MS6-6BONE, MS18417-RIPE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 04, 2001 at 02:27:00PM +0200, Poul-Henning Kamp wrote: > >I've done a /cursory/ look over how this v_tag is used. I'm not sure > >this is a simple/clean as you propose, since this is used in the > >IS_LOCKING_VFS macro, as well as in union_subr.c... > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. That's what the line of comment above it said ;) /* * [dfr] Kludge until I get around to fixing all the vfs locking. */ Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6: 9:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with SMTP id 0FC7237B40B for ; Tue, 4 Sep 2001 06:09:36 -0700 (PDT) To: chris@calldei.com Cc: Steve Roome , Keith Stevenson , Leo Bicknell , freebsd-hackers@FreeBSD.ORG Received: From MAIL.WGATE.COM (10.1.1.4[10.1.1.4 port:2819]) by mx.wgate.comMail essentials (server 2.429) with SMTP id: <513@mx.wgate.com>transfer for ; Tue, 4 Sep 2001 9:05:44 AM -0400 ;transfer smtpmailfrom X-MESINK_Inbound: 0 X-MESINK_MailForType: SMTP X-MESINK_SenderType: SMTP X-MESINK_Sender: msinz@wgate.com X-MESINK_MailFor: freebsd-hackers@FreeBSD.ORG Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)id SAMDX8PK; Tue, 4 Sep 2001 09:08:14 -0400 Received: from wgate.com (localhost [127.0.0.1])by sinz.eng.tvol.net (8.11.3/8.11.3) with ESMTP id f84D9AL41193;Tue, 4 Sep 2001 09:09:11 -0400 (EDT)(envelope-from msinz@wgate.com) Date: Tue, 04 Sep 2001 09:09:10 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en Subject: Re: Should URL's be pervasive. References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <00000e180511ee07d1@[192.168.1.4]> <000010020513d807d1@[192.168.1.4]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-receiver: freebsd-hackers@FreeBSD.ORG x-sender: msinz@wgate.com MIME-Version: 1.0 Message-ID: <000003ff0207cf07d1@[192.168.1.4]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Chris Costello wrote: > > On Friday, August 31, 2001, Michael Sinz wrote: > > I too have been hoping for (and building internal tools) that work > > this way. I really wish you could just do: > > > > open("nfs://server.name.dom/directory/file.txt") > > > > and have it work. That would be nice. (Replace the above with > > ftp: or http: or whatever other protocol would provide read and/or write > > access.) > > > > Anyway, I don't see it happening quickly but I don't see it as a bad thing > > and I would guess that it will eventually get to that point. (The network > > includes your local machine so why not) > > Whatever happened to not distinguishing different types of file > systems from one another in pathnames? And are you suggesting that > we add network overhead (I'd still imagine lo0 can't help speeding > things up...) to file system accesses? What I was trying to say is that there is no reason that I should care if the file is local or not. Why should a program have to specifically offer support to edit that file from an FTP site. (EMACS and other editors have added transparent FTP support, but that was extra work for them) Just as the OS support having multiple storage devices and media and the software does not need to know if the file is on a SCSI or IDE disk or if it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if it is local or on the machine beside it or on the machine on the other side of the world? Now, the OS (from a technical level) should be smart enough to handle not doing actual NFS (or FTP or HTTP or whatever protocol) to its local disk when it can. (Sometimes going in via FTP to the local machine gets you in as a different user and thus gets you different access rights so the level of complexity is not always obviously trivial) Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6:19:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with SMTP id BD3BA37B401 for ; Tue, 4 Sep 2001 06:19:35 -0700 (PDT) To: Paul Chvostek Cc: freebsd-hackers@FreeBSD.ORG Received: From MAIL.WGATE.COM (10.1.1.4[10.1.1.4 port:4466]) by mx.wgate.comMail essentials (server 2.429) with SMTP id: <599@mx.wgate.com>transfer for ; Tue, 4 Sep 2001 9:15:40 AM -0400 ;transfer smtpmailfrom X-MESINK_Inbound: 0 X-MESINK_MailForType: SMTP X-MESINK_SenderType: SMTP X-MESINK_Sender: msinz@wgate.com X-MESINK_MailFor: freebsd-hackers@FreeBSD.ORG Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)id SAMDX8WY; Tue, 4 Sep 2001 09:18:10 -0400 Received: from wgate.com (localhost [127.0.0.1])by sinz.eng.tvol.net (8.11.3/8.11.3) with ESMTP id f84DJ7L41224;Tue, 4 Sep 2001 09:19:07 -0400 (EDT)(envelope-from msinz@wgate.com) Date: Tue, 04 Sep 2001 09:19:07 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en Subject: Re: Should URL's be pervasive. References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <00000e180511ee07d1@[192.168.1.4]> <000046d0064aa607d1@[192.168.1.4]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-receiver: freebsd-hackers@FreeBSD.ORG x-sender: msinz@wgate.com MIME-Version: 1.0 Message-ID: <0000046c02083c07d1@[192.168.1.4]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Paul Chvostek wrote: > > On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote: > > > > I too have been hoping for (and building internal tools) that work > > this way. I really wish you could just do: > > > > open("nfs://server.name.dom/directory/file.txt") > > NAME > amd - automatically mount file systems > ... > DESCRIPTION > Amd is a daemon that automatically mounts filesystems whenever a file or > directory within that filesystem is accessed. Filesystems are automati- > cally unmounted when they appear to be quiescent. Ahh, but that assumes that your AMD configuration has all systems and mount points enumerated in it. Let me see - I think that 30gig drive may be big enough for that file :-) > > and have it work. That would be nice. (Replace the above with > > ftp: or http: or whatever other protocol would provide read and/or write > > access.) > > What you're looking for is a substitute open() function. Perhaps > someone should just write a URI base library. Put it in the public > domain, of course, so that all UR base is belong to us.... Ahh, but that does not address all software. Sure, edit all source and make the call to open() now be a call to uri_open()... Why bother making the OS deal with the issues involved? The reason the OS should (and could) is that it is the base from which all such services grow. Now, in a microkernel design (such as the previously mentioned HURD) there are ways to extend the filesystem to include new types (FTPFS is a great example of such a filter/expansion) but in FreeBSD (very much not microkernel) this then becomes an OS issue or a user-program issue. If it is in user space you end up with "some have it" and "some don't" and "some have some subset" which makes it really nasty. Can you imagine if there was an ide_open() to open files on IDE drives and a scsi_open() to open files on SCSI drives? Or a UFS_open() vs an ext2_open() vs an FFS_open()? Why would you then want a uri_open() vs regular open()? > Watch those puns - I could end up returning them unopened :-) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6:20:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by hub.freebsd.org (Postfix) with ESMTP id 0BB0737B409; Tue, 4 Sep 2001 06:20:13 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id f84DK7c24736; Tue, 4 Sep 2001 09:20:07 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id f84DK5f02583; Tue, 4 Sep 2001 09:20:05 -0400 (EDT) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub2.mitre.org with SMTP id 7617718; Tue, 04 Sep 2001 09:18:51 -0400 Message-ID: <3B94D4AC.6B08187C@mitre.org> Date: Tue, 04 Sep 2001 09:18:36 -0400 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tlambert2@mindspring.com Cc: obrien@freebsd.org, Charles Shannon Hendrix , freebsd-hackers@freebsd.org Subject: Re: FreeBSD and Athlon Processors References: <200109010033.f810XaT08748@saturn.cs.uml.edu> <20010902001113.B27595@widomaker.com> <20010902102548.C64910@dragon.nuxi.com> <3B948149.1FE08591@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > David O'Brien wrote: > > > > Well, since it didn't, I might as well explain the problem here too. > > > > There are at least two major problems with VIA chips: > > > > > > [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] > > > > > > Are you sure about that? > > > > I am. I was having data coruption in a terrable way when I added a 2nd > > IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. > > Are you sure it's not just a CMD640 IDE controller? They are > known to have issues; Linux has a patch... FreeBSD used to, but > I think it got yanked out, or was just turned off by default. I didn't think anybody used the CMD640 anymore (not since early Pentium days even). Anyway sys/pci/ide_pci.c still has the workaround for the CMD640, it's just not a kernel option anymore because FreeBSD automagically detects and installs the workaround now if you have one. -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6:41:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with SMTP id 966E537B405 for ; Tue, 4 Sep 2001 06:41:43 -0700 (PDT) To: John Polstra Cc: hackers@FreeBSD.ORG, kris@obsecurity.org Received: From MAIL.WGATE.COM (10.1.1.4[10.1.1.4 port:2929]) by mx.wgate.comMail essentials (server 2.429) with SMTP id: <811@mx.wgate.com>transfer for ; Tue, 4 Sep 2001 9:37:57 AM -0400 ;transfer smtpmailfrom X-MESINK_Inbound: 0 X-MESINK_MailForType: SMTP X-MESINK_SenderType: SMTP X-MESINK_Sender: msinz@wgate.com X-MESINK_MailFor: hackers@FreeBSD.ORG Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)id SAMDX9F9; Tue, 4 Sep 2001 09:40:27 -0400 Received: from wgate.com (localhost [127.0.0.1])by sinz.eng.tvol.net (8.11.3/8.11.3) with ESMTP id f84DfOL41349;Tue, 4 Sep 2001 09:41:24 -0400 (EDT)(envelope-from msinz@wgate.com) Date: Tue, 04 Sep 2001 09:41:24 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en Subject: Re: gzipped crashdumps References: <20010901011631.A59345@xor.obsecurity.org> <000047ca064ba007d1@[192.168.1.4]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-receiver: hackers@FreeBSD.ORG x-sender: msinz@wgate.com MIME-Version: 1.0 Message-ID: <0000058102095107d1@[192.168.1.4]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Polstra wrote: > > In article <20010901011631.A59345@xor.obsecurity.org>, > Kris Kennaway wrote: > > > > Anyone else think this patch from NetBSD is worthwhile? > > Yes yes yes yes yes! That's 5 votes in favor of it already. :-) Add in another 50 here (the number of machines here that produce dumps in our test lab :-() -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6:58: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 0ED8737B409; Tue, 4 Sep 2001 06:57:58 -0700 (PDT) Received: from vega.vega.com (dialup6-2.iptelecom.net.ua [212.9.227.66]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id QAA22072; Tue, 4 Sep 2001 16:57:51 +0300 (EEST) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f84DhO097646; Tue, 4 Sep 2001 16:43:24 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200109041343.f84DhO097646@vega.vega.com> Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 4 Sep 2001 16:42:03 +0300 (EEST) Cc: brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <12839.999606420@critter> from "Poul-Henning Kamp" at Sep 04, 2001 02:27:00 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: > >| > >| Assignment: > >| > >| The v_tag element in struct vnode is a debugging aid, but unfortunately > >| it is implemented in a way which means that adding a filesystem means > >| modifying the definition in . > >| > >| Convert the v_tag to an "const char *" and have the filesystems put > >| their name in there instead. > >| > >| The v_tag has been abused a few places, easily recognizable by the fact > >| that the kernel should never inspect the value of v_tag. > >| These places should be easily changeable to use the new representation. > >| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment. > > > >#include > > > >I've done a /cursory/ look over how this v_tag is used. I'm not sure > >this is a simple/clean as you propose, since this is used in the > >IS_LOCKING_VFS macro, as well as in union_subr.c... > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > > The places which inspect v_tag will have to be changed to use > strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 6:59:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9AA3537B40C; Tue, 4 Sep 2001 06:59:44 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f84DxFT57179; Tue, 4 Sep 2001 15:59:15 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Maxim Sobolev Cc: brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: Your message of "Tue, 04 Sep 2001 16:42:03 +0300." <200109041343.f84DhO097646@vega.vega.com> Date: Tue, 04 Sep 2001 15:59:15 +0200 Message-ID: <57177.999611955@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: >> >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: >> >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: >> >| >> >| Assignment: >> >| >> >| The v_tag element in struct vnode is a debugging aid, but unfortunately >> >| it is implemented in a way which means that adding a filesystem means >> >| modifying the definition in . >> >| >> >| Convert the v_tag to an "const char *" and have the filesystems put >> >| their name in there instead. >> >| >> >| The v_tag has been abused a few places, easily recognizable by the fact >> >| that the kernel should never inspect the value of v_tag. >> >| These places should be easily changeable to use the new representation. >> >| Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment. >> > >> >#include >> > >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure >> >this is a simple/clean as you propose, since this is used in the >> >IS_LOCKING_VFS macro, as well as in union_subr.c... >> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. >> >> The places which inspect v_tag will have to be changed to use >> strcmp() then... > >I think that we can add a new vnode flag, say VCANLOCK, so that each >particular VFS can set it if it supports locking, which should allow >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can >produce a patch if it sounds reasonably. Yeah, I think that makes a lot of sense. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 7: 6:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.teledis.be (mail.teledis.be [217.117.32.52]) by hub.freebsd.org (Postfix) with ESMTP id 448C637B406 for ; Tue, 4 Sep 2001 07:06:25 -0700 (PDT) Received: from natalie ([217.117.38.8]) by mail.teledis.be (Netscape Messaging Server 4.15) with SMTP id GJ55US00.CIM for ; Tue, 4 Sep 2001 16:06:28 +0200 Message-ID: <001301c1354b$58bbb340$0201a8c0@teledisnet.be> From: "Sansonetti Laurent" To: References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <00000e180511ee07d1@[192.168.1.4]> <000010020513d807d1@[192.168.1.4]> <000003ff0207cf07d1@[192.168.1.4]> Subject: Re: Should URL's be pervasive. Date: Tue, 4 Sep 2001 16:10:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Anyway, the point is that a file that I can access should be a file I > can access via VI or MORE or EMACS or GREP or any other tool without > having those tools each having FTP and HTTP and SSH support built in to > them. The OS should handle it. Yes, this should be nice. There's a similar project for Linux here: http://ftpfs.sourceforge.net/ (FTP only). It would be amusing to port it into a KLD file. -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 7:13: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.twwells.com (mail.twwells.com [64.38.247.128]) by hub.freebsd.org (Postfix) with ESMTP id D8D9E37B403 for ; Tue, 4 Sep 2001 07:13:01 -0700 (PDT) Received: from xfermail (helo=mail.twwells.com) by mail.twwells.com with local-bsmtp (Exim 3.32 #1) id 15eGwn-000GAf-00 for freebsd-hackers@freebsd.org; Tue, 04 Sep 2001 07:13:01 -0700 X-Filter-Status: mail.twwells.com ok 13 Received: from twwells.com ( [65.14.140.228] ) by mail.twwells.com via tcp with esmtp id 3b94e160-00f2ac; Tue, 4 Sep 2001 14:12:48 +0000 Received: from root by twwells.com with local (Exim 3.22 #1) id 15eGwP-0005gh-00; Tue, 04 Sep 2001 10:12:37 -0400 Subject: Re: Should URL's be pervasive. References: <000003ff0207cf07d1@[192.168.1.4]> To: freebsd-hackers@freebsd.org Message-Id: From: Charlie Root Date: Tue, 04 Sep 2001 10:12:37 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > What I was trying to say is that there is no reason that I should care > if the file is local or not. You do need to know if the file is local or not. You need to know for security. You need to know because files behave differently on different machines. You need to know because file structures don't map from one machine to another. You need to know because differing protocols allow you do to very different things to files. You need to know because performance varies dramatically depending on where the file is located. > Just as the OS support having multiple storage devices and media and the > software does not need to know if the file is on a SCSI or IDE disk or if > it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if > it is local or on the machine beside it or on the machine on the other side > of the world? The OS support of multiple device types exists because it is possible and reasonable to abstract each of those device types into a single "virtual" type. When this isn't possible or reasonable, it's not only difficult but *wrong* to abstract. There are way too many things you can do with a local file that you can't do with a remote file to allow this abstraction. > Anyway, the point is that a file that I can access should be a file I > can access via VI or MORE or EMACS or GREP or any other tool without > having those tools each having FTP and HTTP and SSH support built in to > them. The OS should handle it. No it should not. It's not reasonable for the *operating system* to know about every damned protocol that someone decides would be a just peachy way to access a file. Hell, it's not even practical. The idea of universal abstraction just does not work. If you think otherwise, I suggest you start coding and stop bothering the rest of us until you've made it work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 7:30:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with SMTP id A137337B408 for ; Tue, 4 Sep 2001 07:30:16 -0700 (PDT) To: Sansonetti Laurent Cc: freebsd-hackers@FreeBSD.ORG Received: From MAIL.WGATE.COM (10.1.1.4[10.1.1.4 port:4441]) by mx.wgate.comMail essentials (server 2.429) with SMTP id: <1244@mx.wgate.com>transfer for ; Tue, 4 Sep 2001 10:26:24 AM -0400 ;transfer smtpmailfrom X-MESINK_Inbound: 0 X-MESINK_MailForType: SMTP X-MESINK_SenderType: SMTP X-MESINK_Sender: msinz@wgate.com X-MESINK_MailFor: freebsd-hackers@FreeBSD.ORG Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)id SAMDX0BB; Tue, 4 Sep 2001 10:28:54 -0400 Received: from wgate.com (localhost [127.0.0.1])by sinz.eng.tvol.net (8.11.3/8.11.3) with ESMTP id f84ETmL41448;Tue, 4 Sep 2001 10:29:51 -0400 (EDT)(envelope-from msinz@wgate.com) Date: Tue, 04 Sep 2001 10:29:47 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en Subject: Re: Should URL's be pervasive. References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <00000e180511ee07d1@[192.168.1.4]> <000010020513d807d1@[192.168.1.4]> <000003ff0207cf07d1@[192.168.1.4]> <000006a5020a7507d1@[192.168.1.4]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-receiver: freebsd-hackers@FreeBSD.ORG x-sender: msinz@wgate.com MIME-Version: 1.0 Message-ID: <000007ac020b7c07d1@[192.168.1.4]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sansonetti Laurent wrote: > > > Anyway, the point is that a file that I can access should be a file I > > can access via VI or MORE or EMACS or GREP or any other tool without > > having those tools each having FTP and HTTP and SSH support built in to > > them. The OS should handle it. > > Yes, this should be nice. There's a similar project for Linux here: > http://ftpfs.sourceforge.net/ (FTP only). > It would be amusing to port it into a KLD file. Hmmm... Looks like a good first step -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 7:58:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from stox.sa.enteract.com (stox.sa.enteract.com [207.229.132.161]) by hub.freebsd.org (Postfix) with ESMTP id F3D2537B408 for ; Tue, 4 Sep 2001 07:58:39 -0700 (PDT) Received: (from stox@localhost) by stox.sa.enteract.com (8.11.6/8.11.6) id f84EwV301580; Tue, 4 Sep 2001 09:58:31 -0500 (CDT) (envelope-from stox) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <000007ac020b7c07d1@[192.168.1.4]> Date: Tue, 04 Sep 2001 09:58:31 -0500 (CDT) Organization: Imaginary Landscape, LLC. From: "Kenneth P. Stox" To: Michael Sinz Subject: Re: Should URL's be pervasive. Cc: freebsd-hackers@FreeBSD.ORG, Sansonetti Laurent Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Sep-01 Michael Sinz wrote: > Sansonetti Laurent wrote: >> >> > Anyway, the point is that a file that I can access should be a file I >> > can access via VI or MORE or EMACS or GREP or any other tool without >> > having those tools each having FTP and HTTP and SSH support built in to >> > them. The OS should handle it. >> >> Yes, this should be nice. There's a similar project for Linux here: >> http://ftpfs.sourceforge.net/ (FTP only). >> It would be amusing to port it into a KLD file. > > Hmmm... Looks like a good first step You may also wish to take a look at wwfs: ---------------------------------- E-Mail: Kenneth P. Stox Date: 04-Sep-01 Time: 09:57:36 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8: 0:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mx.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with SMTP id 8917E37B408 for ; Tue, 4 Sep 2001 08:00:44 -0700 (PDT) To: Charlie Root Cc: freebsd-hackers@FreeBSD.ORG Received: From MAIL.WGATE.COM (10.1.1.4[10.1.1.4 port:3974]) by mx.wgate.comMail essentials (server 2.429) with SMTP id: <1549@mx.wgate.com>transfer for ; Tue, 4 Sep 2001 10:57:09 AM -0400 ;transfer smtpmailfrom X-MESINK_Inbound: 0 X-MESINK_MailForType: SMTP X-MESINK_SenderType: SMTP X-MESINK_Sender: msinz@wgate.com X-MESINK_MailFor: freebsd-hackers@FreeBSD.ORG Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)id SAMDX04X; Tue, 4 Sep 2001 10:59:40 -0400 Received: from wgate.com (localhost [127.0.0.1])by sinz.eng.tvol.net (8.11.3/8.11.3) with ESMTP id f84F0bL41538;Tue, 4 Sep 2001 11:00:37 -0400 (EDT)(envelope-from msinz@wgate.com) Date: Tue, 04 Sep 2001 11:00:37 -0400 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en Subject: Re: Should URL's be pervasive. References: <000003ff0207cf07d1@[192.168.1.4]> <000006fd020acd07d1@[192.168.1.4]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-receiver: freebsd-hackers@FreeBSD.ORG x-sender: msinz@wgate.com MIME-Version: 1.0 Message-ID: <00000925020cf507d1@[192.168.1.4]> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Charlie Root wrote: > > > What I was trying to say is that there is no reason that I should care > > if the file is local or not. > > You do need to know if the file is local or not. You need to know > for security. You need to know because files behave differently on > different machines. You need to know because file structures don't > map from one machine to another. You need to know because > differing protocols allow you do to very different things to > files. You need to know because performance varies dramatically > depending on where the file is located. Ok - so my server here has files that various platforms access via NFS. The fact that everything accesses the files via NFS does not reduce or change the fact that the endian nature of the platform or the word size of the platform need to be either understood or that the file format be strictly structured so as to no matter. And if you think that each application needs to know about the different semantics of the file storage system, why is NFS just like FFS just like UFS just like FAT16 just like... Each has different limits and behaviors. NFS is very stateless. Local file systems are much more stateful. FAT has file name restrictions (pre-VFAT it was 8.3 with upper case only, for example) ISO9660 has depth limits and version numbers, VMS has version numbers and different character exclusions, etc. Some of these limits are annoying and, in some cases, incompatible with the work you may wish to do. However, most of these are limits that are also limits on other file systems (albeit different - 32 character names or 255 character names, for example, but still a name length limit) Performance differences are vast, even with local files. Have you written to a floppy lately. Almost all my network connected disks are *much* faster. How about that slow MO drive? Or that ultra-fast SCSI RAID pack? At some point the performance issues are just "if you use X it will not perform like Y" and not a "this program can't use X because we feel it does not perform well enough and thus we did not code for it." (cp, mv, etc, all work with floppy disks and other slow media...) > > Just as the OS support having multiple storage devices and media and the > > software does not need to know if the file is on a SCSI or IDE disk or if > > it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if > > it is local or on the machine beside it or on the machine on the other side > > of the world? > > The OS support of multiple device types exists because it is > possible and reasonable to abstract each of those device types > into a single "virtual" type. When this isn't possible or > reasonable, it's not only difficult but *wrong* to abstract. There > are way too many things you can do with a local file that you > can't do with a remote file to allow this abstraction. I never said this was trivial. We (which includes me) tried to start such a project at Amiga (Commodore) - It was well before HTTP was so popular. The goal was to hide the specifics and provide a single operation. FTP support was via a local cache while the file was open and if you did a write, it would write back the file at close time. This is due to limits in the ftp protocol, but it did not change the behavior to the application. The fact that writes were not instant to the FTP server was just one of the differences between it and other file systems. NFS had other limits. Our own network filesystem had yet other design goals and thus different limits/behaviors. The hard part we faced was the fact that the computers were much less powerful than today (slower/less RAM/ etc) and that Amiga(Commodore) was not very focused on networking (or anything else other than loosing money :-) > > Anyway, the point is that a file that I can access should be a file I > > can access via VI or MORE or EMACS or GREP or any other tool without > > having those tools each having FTP and HTTP and SSH support built in to > > them. The OS should handle it. > > No it should not. It's not reasonable for the *operating system* > to know about every damned protocol that someone decides would be > a just peachy way to access a file. Hell, it's not even practical. Not every protocol - or maybe every protocol supported by people who make the protocol filters. This is where external (to the kernel) protocol filters fit in well. But lets not go there (now). All of this started with the quest for URIs being useable everywhere. That is a nice starting point for an idea. Now, if I gave you foobar://xx/yy you might not know what to do with the foobar protocol from the URI. That would be an error, much like but not exactly like, file not found. (It would be unknown protocol as a subset of file not found, much like when you use /var/lof/messages when you were going to use /var/log/messages) > The idea of universal abstraction just does not work. If you think > otherwise, I suggest you start coding and stop bothering the rest > of us until you've made it work. I was not asking for a magic bullet. (Well, not this time :-) I was asking that the OS support reading and/or writing of data (whatever that may be) to a file/filehandle that was created via a standard system call. The data itself will have to be correct. I don't want to make some magic XDR type of thing. That is what XDR and/or file format definitions are for. But why should VI or EMACS have to have special code in each editor just so you can load/edit a file from FTP rather than local? -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8: 3:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 1988137B407 for ; Tue, 4 Sep 2001 08:03:35 -0700 (PDT) Received: (from root@localhost) by bugz.infotecs.ru (8.11.6/8.11.4) id f84F3WS57075 for freebsd-hackers@freebsd.org; Tue, 4 Sep 2001 19:03:32 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200109041503.f84F3WS57075@bugz.infotecs.ru> Subject: KLD subsystem improvement To: freebsd-hackers@freebsd.org Date: Tue, 4 Sep 2001 19:03:32 +0400 (MSD) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I'm going to implement a small improvement to a KLD system. I want linker file not to be loaded at all when all modules inside it fail to load for some reasons. I think that would be logical behaviour. Does anyone think that such change would break something ? Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8:34: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.twwells.com (mail.twwells.com [64.38.247.128]) by hub.freebsd.org (Postfix) with ESMTP id 0B5EE37B405 for ; Tue, 4 Sep 2001 08:34:03 -0700 (PDT) Received: from xfermail (helo=mail.twwells.com) by mail.twwells.com with local-bsmtp (Exim 3.32 #1) id 15eIDC-000GS4-00 for freebsd-hackers@freebsd.org; Tue, 04 Sep 2001 08:34:02 -0700 X-Filter-Status: mail.twwells.com ok 48 Received: from twwells.com ( [65.14.140.228] ) by mail.twwells.com via tcp with esmtp id 3b94f43a-00f703; Tue, 4 Sep 2001 15:33:14 +0000 Received: from root by twwells.com with local (Exim 3.22 #1) id 15eICB-0007ny-00 for freebsd-hackers@freebsd.org; Tue, 04 Sep 2001 11:32:59 -0400 Subject: Re: Should URL's be pervasive. To: freebsd-hackers@freebsd.org Date: Tue, 4 Sep 2001 11:32:59 -0400 (EDT) In-Reply-To: <00000925020cf507d1@[192.168.1.4]> from "Michael Sinz" at Sep 04, 2001 11:00:37 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Charlie Root Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > All of this started with the quest for URIs being useable everywhere. It's a stupid quest, for reasons others have pointed out. > > When this isn't possible or > > reasonable, it's not only difficult but *wrong* to abstract. > > I never said this was trivial. We (which includes me) tried to start > such a project at Amiga (Commodore) - It was well before HTTP was so > popular. The goal was to hide the specifics and provide a single operation. > FTP support was via a local cache while the file was open and if you did > a write, it would write back the file at close time. See above. There's a reason AFS hasn't replaced NFS. > I was not asking for a magic bullet. (Well, not this time :-) > I was asking that the OS support reading and/or writing of data (whatever > that may be) to a file/filehandle that was created via a standard > system call. Pipes, named or otherwise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8:37:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 492F837B406; Tue, 4 Sep 2001 08:37:09 -0700 (PDT) Received: from vega.vega.com (dialup4-44.iptelecom.net.ua [212.9.226.236]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id SAA46300; Tue, 4 Sep 2001 18:36:44 +0300 (EEST) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f84FaDG98107; Tue, 4 Sep 2001 18:36:13 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200109041536.f84FaDG98107@vega.vega.com> Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 4 Sep 2001 18:35:32 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <57177.999611955@critter> from "Poul-Henning Kamp" at Sep 04, 2001 03:59:15 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.97537.999617732--%" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --%--multipart-mixed-boundary-1.97537.999617732--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: > >> > >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > >> > > >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure > >> >this is a simple/clean as you propose, since this is used in the > >> >IS_LOCKING_VFS macro, as well as in union_subr.c... > >> > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > >> > >> The places which inspect v_tag will have to be changed to use > >> strcmp() then... > > > >I think that we can add a new vnode flag, say VCANLOCK, so that each > >particular VFS can set it if it supports locking, which should allow > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > >produce a patch if it sounds reasonably. > > Yeah, I think that makes a lot of sense. See attached. Please let me know if it is OK for you. -Maxim --%--multipart-mixed-boundary-1.97537.999617732--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: ASCII C program text Content-Disposition: attachment; filename="p" Index: isofs/cd9660/cd9660_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v retrieving revision 1.91 diff -d -u -r1.91 cd9660_vfsops.c --- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91 +++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46 @@ -697,6 +697,7 @@ } MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE, M_WAITOK | M_ZERO); + vp->v_flag |= VLOCKABLE; lockinit(&vp->v_lock, PINOD, "isonode", 0, 0); /* * ISOFS uses stdlock and can share lock structure Index: ufs/ffs/ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.157 diff -d -u -r1.157 ffs_vfsops.c --- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157 +++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25 @@ -1172,6 +1172,7 @@ return (error); } bzero((caddr_t)ip, sizeof(struct inode)); + vp->v_flag |= VLOCKABLE; /* * FFS supports lock sharing in the stack of vnodes */ Index: ufs/ifs/ifs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v retrieving revision 1.6 diff -d -u -r1.6 ifs_vfsops.c --- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6 +++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25 @@ -217,6 +217,7 @@ return (error); } bzero((caddr_t)ip, sizeof(struct inode)); + vp->v_flag |= VLOCKABLE; /* * IFS supports lock sharing in the stack of vnodes */ Index: nfs/nfs_node.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.49 diff -d -u -r1.49 nfs_node.c --- nfs/nfs_node.c 2001/05/01 08:13:14 1.49 +++ nfs/nfs_node.c 2001/09/04 15:21:25 @@ -232,6 +232,7 @@ } vp = nvp; bzero((caddr_t)np, sizeof *np); + vp->v_flag |= VLOCKABLE; vp->v_data = np; np->n_vnode = vp; /* Index: sys/vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.154 diff -d -u -r1.154 vnode.h --- sys/vnode.h 2001/08/27 06:09:55 1.154 +++ sys/vnode.h 2001/09/04 15:21:25 @@ -175,6 +175,7 @@ /* open for business 0x100000 */ #define VONWORKLST 0x200000 /* On syncer work-list */ #define VMOUNT 0x400000 /* Mount in progress */ +#define VLOCKABLE 0x600000 /* vnode supports locking */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value @@ -433,12 +434,7 @@ /* * [dfr] Kludge until I get around to fixing all the vfs locking. */ -#define IS_LOCKING_VFS(vp) ((vp)->v_tag == VT_UFS \ - || (vp)->v_tag == VT_NFS \ - || (vp)->v_tag == VT_LFS \ - || (vp)->v_tag == VT_ISOFS \ - || (vp)->v_tag == VT_MSDOSFS \ - || (vp)->v_tag == VT_DEVFS) +#define IS_LOCKING_VFS(vp) ((vp)->v_flag & VLOCKABLE) #define ASSERT_VOP_LOCKED(vp, str) \ do { \ Index: fs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v retrieving revision 1.27 diff -d -u -r1.27 devfs_vnops.c --- fs/devfs/devfs_vnops.c 2001/08/14 06:42:32 1.27 +++ fs/devfs/devfs_vnops.c 2001/09/04 15:21:25 @@ -151,6 +151,7 @@ } else { vp->v_type = VBAD; } + vp->v_flag |= VLOCKABLE; vp->v_data = de; de->de_vnode = vp; vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); Index: fs/msdosfs/msdosfs_denode.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v retrieving revision 1.57 diff -d -u -r1.57 msdosfs_denode.c --- fs/msdosfs/msdosfs_denode.c 2001/05/25 08:14:09 1.57 +++ fs/msdosfs/msdosfs_denode.c 2001/09/04 15:21:33 @@ -261,6 +261,7 @@ return error; } bzero((caddr_t)ldep, sizeof *ldep); + nvp->v_flag |= VLOCKABLE; lockinit(&nvp->v_lock, PINOD, "denode", 0, 0); nvp->v_vnlock = &nvp->v_lock; nvp->v_data = ldep; --%--multipart-mixed-boundary-1.97537.999617732--%-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8:50:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by hub.freebsd.org (Postfix) with ESMTP id 41D2237B408; Tue, 4 Sep 2001 08:50:12 -0700 (PDT) Received: from theta.dante.org.uk ([193.63.211.7] helo=dante.org.uk) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 15eISe-0003fH-00; Tue, 04 Sep 2001 16:50:00 +0100 Message-ID: <3B94F834.C337F392@dante.org.uk> Date: Tue, 04 Sep 2001 16:50:13 +0100 From: Konstantin Chuguev Organization: Delivery of Advanced Network Technology to Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: ru, en MIME-Version: 1.0 To: Maxim Sobolev Cc: Poul-Henning Kamp , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag References: <200109041536.f84FaDG98107@vega.vega.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Maxim, Perhaps you meant: diff -d -u -r1.154 vnode.h --- sys/vnode.h 2001/08/27 06:09:55 1.154 +++ sys/vnode.h 2001/09/04 15:21:25 @@ -175,6 +175,7 @@ /* open for business 0x100000 */ #define VONWORKLST 0x200000 /* On syncer work-list */ #define VMOUNT 0x400000 /* Mount in progress */ +#define VLOCKABLE 0x600000 /* vnode supports locking */ ...should be ^^^^^^^^ +#define VLOCKABLE 0x800000 /* vnode supports locking */ ? Regards, Konstantin. Maxim Sobolev wrote: > > In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: > > >> > > >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > > >> > > > >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure > > >> >this is a simple/clean as you propose, since this is used in the > > >> >IS_LOCKING_VFS macro, as well as in union_subr.c... > > >> > > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > > >> > > >> The places which inspect v_tag will have to be changed to use > > >> strcmp() then... > > > > > >I think that we can add a new vnode flag, say VCANLOCK, so that each > > >particular VFS can set it if it supports locking, which should allow > > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > > >produce a patch if it sounds reasonably. > > > > Yeah, I think that makes a lot of sense. > > See attached. Please let me know if it is OK for you. > > -Maxim > > ---------------------------------------------------------------------- > Name: p > p Type: Plain Text (text/plain) > Encoding: 7bit > Description: ASCII C program text -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.net United Kingdom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 8:54:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CFE0A37B406; Tue, 4 Sep 2001 08:54:02 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f84FrYT12426; Tue, 4 Sep 2001 17:53:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Maxim Sobolev Cc: brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: Your message of "Tue, 04 Sep 2001 18:35:32 +0300." <200109041536.f84FaDG98107@vega.vega.com> Date: Tue, 04 Sep 2001 17:53:34 +0200 Message-ID: <12420.999618814@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG apart from the numerical value, yes, looks good. Poul-Henning In message <200109041536.f84FaDG98107@vega.vega.com>, Maxim Sobolev writes: > >--%--multipart-mixed-boundary-1.97537.999617732--% >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >> In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: >> >> >> >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: >> >> > >> >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure >> >> >this is a simple/clean as you propose, since this is used in the >> >> >IS_LOCKING_VFS macro, as well as in union_subr.c... >> >> >> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. >> >> >> >> The places which inspect v_tag will have to be changed to use >> >> strcmp() then... >> > >> >I think that we can add a new vnode flag, say VCANLOCK, so that each >> >particular VFS can set it if it supports locking, which should allow >> >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can >> >produce a patch if it sounds reasonably. >> >> Yeah, I think that makes a lot of sense. > >See attached. Please let me know if it is OK for you. > >-Maxim > >--%--multipart-mixed-boundary-1.97537.999617732--% >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit >Content-Description: ASCII C program text >Content-Disposition: attachment; filename="p" > >Index: isofs/cd9660/cd9660_vfsops.c >=================================================================== >RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v >retrieving revision 1.91 >diff -d -u -r1.91 cd9660_vfsops.c >--- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91 >+++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46 >@@ -697,6 +697,7 @@ > } > MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE, > M_WAITOK | M_ZERO); >+ vp->v_flag |= VLOCKABLE; > lockinit(&vp->v_lock, PINOD, "isonode", 0, 0); > /* > * ISOFS uses stdlock and can share lock structure >Index: ufs/ffs/ffs_vfsops.c >=================================================================== >RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v >retrieving revision 1.157 >diff -d -u -r1.157 ffs_vfsops.c >--- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157 >+++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25 >@@ -1172,6 +1172,7 @@ > return (error); > } > bzero((caddr_t)ip, sizeof(struct inode)); >+ vp->v_flag |= VLOCKABLE; > /* > * FFS supports lock sharing in the stack of vnodes > */ >Index: ufs/ifs/ifs_vfsops.c >=================================================================== >RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v >retrieving revision 1.6 >diff -d -u -r1.6 ifs_vfsops.c >--- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6 >+++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25 >@@ -217,6 +217,7 @@ > return (error); > } > bzero((caddr_t)ip, sizeof(struct inode)); >+ vp->v_flag |= VLOCKABLE; > /* > * IFS supports lock sharing in the stack of vnodes > */ >Index: nfs/nfs_node.c >=================================================================== >RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v >retrieving revision 1.49 >diff -d -u -r1.49 nfs_node.c >--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49 >+++ nfs/nfs_node.c 2001/09/04 15:21:25 >@@ -232,6 +232,7 @@ > } > vp = nvp; > bzero((caddr_t)np, sizeof *np); >+ vp->v_flag |= VLOCKABLE; > vp->v_data = np; > np->n_vnode = vp; > /* >Index: sys/vnode.h >=================================================================== >RCS file: /home/ncvs/src/sys/sys/vnode.h,v >retrieving revision 1.154 >diff -d -u -r1.154 vnode.h >--- sys/vnode.h 2001/08/27 06:09:55 1.154 >+++ sys/vnode.h 2001/09/04 15:21:25 >@@ -175,6 +175,7 @@ > /* open for business 0x100000 */ > #define VONWORKLST 0x200000 /* On syncer work-list */ > #define VMOUNT 0x400000 /* Mount in progress */ >+#define VLOCKABLE 0x600000 /* vnode supports locking */ > > /* > * Vnode attributes. A field value of VNOVAL represents a field whose value >@@ -433,12 +434,7 @@ > /* > * [dfr] Kludge until I get around to fixing all the vfs locking. > */ >-#define IS_LOCKING_VFS(vp) ((vp)->v_tag == VT_UFS \ >- || (vp)->v_tag == VT_NFS \ >- || (vp)->v_tag == VT_LFS \ >- || (vp)->v_tag == VT_ISOFS \ >- || (vp)->v_tag == VT_MSDOSFS \ >- || (vp)->v_tag == VT_DEVFS) >+#define IS_LOCKING_VFS(vp) ((vp)->v_flag & VLOCKABLE) > > #define ASSERT_VOP_LOCKED(vp, str) \ > do { \ >Index: fs/devfs/devfs_vnops.c >=================================================================== >RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v >retrieving revision 1.27 >diff -d -u -r1.27 devfs_vnops.c >--- fs/devfs/devfs_vnops.c 2001/08/14 06:42:32 1.27 >+++ fs/devfs/devfs_vnops.c 2001/09/04 15:21:25 >@@ -151,6 +151,7 @@ > } else { > vp->v_type = VBAD; > } >+ vp->v_flag |= VLOCKABLE; > vp->v_data = de; > de->de_vnode = vp; > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); >Index: fs/msdosfs/msdosfs_denode.c >=================================================================== >RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v >retrieving revision 1.57 >diff -d -u -r1.57 msdosfs_denode.c >--- fs/msdosfs/msdosfs_denode.c 2001/05/25 08:14:09 1.57 >+++ fs/msdosfs/msdosfs_denode.c 2001/09/04 15:21:33 >@@ -261,6 +261,7 @@ > return error; > } > bzero((caddr_t)ldep, sizeof *ldep); >+ nvp->v_flag |= VLOCKABLE; > lockinit(&nvp->v_lock, PINOD, "denode", 0, 0); > nvp->v_vnlock = &nvp->v_lock; > nvp->v_data = ldep; > >--%--multipart-mixed-boundary-1.97537.999617732--%-- > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 9:15:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.newgold.net (aphex.newgold.net [209.42.222.44]) by hub.freebsd.org (Postfix) with SMTP id 47D0937B408 for ; Tue, 4 Sep 2001 09:15:45 -0700 (PDT) Received: (qmail 97163 invoked by uid 1000); 4 Sep 2001 16:15:34 -0000 Date: Tue, 4 Sep 2001 16:15:34 +0000 From: Joseph Mallett To: Charlie Root Cc: freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <20010904161534.A97071@NewGold.NET> References: <00000925020cf507d1@[192.168.1.4]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.21i Organisation: New Gold Technology Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What strikes me in this thread is that a lot of people are stupid and lazy and want FreeBSD's kernel (or libc) to do stupid things with URLs the same way you can throw a URL anywhere in Windows and have it mean something. Here's some news for you: It shouldn't, and probably won't, happen. If you really want something that insane and obscene and that much of a bastardisation of EVERYTHING networking-related, check in with the BASH people and do it on the shell level. If you're really lazy and want to be able to do: telnet smtp://localhost I suggest you look into this relatively new invention called '/etc/services' and read some manual pages. You'll find you can do something quite similar, and much saner. /joseph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 9:17: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 3BF8537B405; Tue, 4 Sep 2001 09:16:52 -0700 (PDT) Received: from vega.vega.com (dialup4-39.iptelecom.net.ua [212.9.226.231]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id TAA53900; Tue, 4 Sep 2001 19:16:42 +0300 (EEST) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f84GGC898315; Tue, 4 Sep 2001 19:16:12 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200109041616.f84GGC898315@vega.vega.com> Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag To: Konstantin.Chuguev@dante.org.uk (Konstantin Chuguev) Date: Tue, 4 Sep 2001 19:16:11 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), phk@critter.freebsd.dk (Poul-Henning Kamp), brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Konstantin Chuguev" at Sep 04, 2001 04:50:13 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Hi Maxim, > > Perhaps you meant: > diff -d -u -r1.154 vnode.h > --- sys/vnode.h 2001/08/27 06:09:55 1.154 > +++ sys/vnode.h 2001/09/04 15:21:25 > @@ -175,6 +175,7 @@ > /* open for business 0x100000 */ > #define VONWORKLST 0x200000 /* On syncer work-list */ > #define VMOUNT 0x400000 /* Mount in progress */ > +#define VLOCKABLE 0x600000 /* vnode supports locking */ > ...should be ^^^^^^^^ > +#define VLOCKABLE 0x800000 /* vnode supports locking */ Indeed. Thank you for pointing out! -Maxim > > > > Maxim Sobolev wrote: > > > > In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: > > > >> > > > >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > > > >> > > > > >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure > > > >> >this is a simple/clean as you propose, since this is used in the > > > >> >IS_LOCKING_VFS macro, as well as in union_subr.c... > > > >> > > > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > > > >> > > > >> The places which inspect v_tag will have to be changed to use > > > >> strcmp() then... > > > > > > > >I think that we can add a new vnode flag, say VCANLOCK, so that each > > > >particular VFS can set it if it supports locking, which should allow > > > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > > > >produce a patch if it sounds reasonably. > > > > > > Yeah, I think that makes a lot of sense. > > > > See attached. Please let me know if it is OK for you. > > > > -Maxim > > > > ---------------------------------------------------------------------- > > Name: p > > p Type: Plain Text (text/plain) > > Encoding: 7bit > > Description: ASCII C program text > > -- > * * Konstantin Chuguev Francis House > * * Application Engineer 112 Hills Road > * Tel: +44 1223 302992 Cambridge CB2 1PQ > D A N T E WWW: http://www.dante.net United Kingdom > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 9:39:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from seven.Alameda.net (seven.Alameda.net [64.81.63.137]) by hub.freebsd.org (Postfix) with ESMTP id F1E7037B401 for ; Tue, 4 Sep 2001 09:39:35 -0700 (PDT) Received: by seven.Alameda.net (Postfix, from userid 1000) id BE6D63A298; Tue, 4 Sep 2001 09:39:35 -0700 (PDT) Date: Tue, 4 Sep 2001 09:39:35 -0700 From: Ulf Zimmermann To: hackers@FreeBSD.org Subject: 4.4-RC3 scontrib and other files problem ? Message-ID: <20010904093935.O35204@seven.alameda.net> Reply-To: ulf@Alameda.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.3-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tried to install complete source tree via sysinstall and it always fails on scontrib with unexpected EOF. And it seems several of the chunks are not the usual 240640 bytes in size. Checked several of the FTP servers: -r--r--r-- 1 1006 1006 231335 Sep 2 04:23 sbin.ab -r--r--r-- 1 1006 1006 3763 Sep 1 18:55 scontrib.cq -r--r--r-- 1 1006 1006 63151 Sep 1 18:55 scontrib.cu -r--r--r-- 1 1006 1006 7233 Sep 1 18:55 scontrib.cz -r--r--r-- 1 1006 1006 2145984 Sep 1 18:55 scontrib.eh -r--r--r-- 1 1006 1006 66801 Sep 1 18:55 scontrib.en -r--r--r-- 1 1006 1006 1096775 Sep 1 18:55 scontrib.ex -r--r--r-- 1 1006 1006 6778448 Sep 1 18:55 sgames.ag -r--r--r-- 1 1006 1006 7834 Sep 1 18:55 slib.bb All the ones which are shorter then 240640 bytes are no the last file in their sequences. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 9:54:41 2001 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 4FD6E37B40D; Tue, 4 Sep 2001 09:54:31 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f84GsOP56050; Tue, 4 Sep 2001 12:54:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 4 Sep 2001 12:54:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: developers@FreeBSD.org, hackers@FreeBSD.org Subject: REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It's that time again! I'm in the process of preparing the August, 2001 FreeBSD monthly status report, and as such am interested in seeing submissions in much the same style as previous months. Generally, this means about one paragraph of text per project describing events that have occured since the last status report (or two paragraphs for new projects, so as to introduce them). Large projects can be broken down into multiple sub-projects with seperate reports reports. If multiple developers are working on the same project, they should coordinate so as to submit only one report (or split it up into parts as appropriate along logical boundaries). Reports should relate to the FreeBSD Project, but are not limited to on-going software development: documentation, public relations, management, application developer relations, technology transfer, etc, are all relevant. Please submit reports in the following format: Project: (name here -- required field) URL: (URL, if any, here -- omit field if none) Contact: (name and e-mail address of one or more contact points -- required field) One paragraph on the topic of project status since the last report, indented two spaces, and wrapped at column 78. Plain text only, please. Please send submissions to: robert+freebsd.monthly@cyrus.watson.org The deadline for submissions is September 7, 2001, at 3:00pm EST. The report will be released soon thereafter. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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 Tue Sep 4 10:10:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 751F137B405; Tue, 4 Sep 2001 10:10:35 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id A665628E08; Wed, 5 Sep 2001 00:10:31 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 9BA1C28C76; Wed, 5 Sep 2001 00:10:31 +0700 (ALMST) Date: Wed, 5 Sep 2001 00:10:31 +0700 (ALMST) From: Boris Popov To: Maxim Sobolev Cc: Poul-Henning Kamp , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: <200109041343.f84DhO097646@vega.vega.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Sep 2001, Maxim Sobolev wrote: > > The places which inspect v_tag will have to be changed to use > > strcmp() then... > > I think that we can add a new vnode flag, say VCANLOCK, so that each > particular VFS can set it if it supports locking, which should allow > to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > produce a patch if it sounds reasonably. I'm not sure if this a right thing to do. Under SMPng each filesystem is ought to implement correct vnode locking, i.e. vop_nolock() and friends shouldn't exist. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 10:55: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 80C3437B407; Tue, 4 Sep 2001 10:54:55 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA27863; Wed, 5 Sep 2001 03:54:51 +1000 Date: Wed, 5 Sep 2001 03:54:29 +1000 (EST) From: Bruce Evans X-X-Sender: To: Maxim Sobolev Cc: Poul-Henning Kamp , Brent Verner , , Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: <200109041343.f84DhO097646@vega.vega.com> Message-ID: <20010905034832.N17574-100000@alphplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Sep 2001, Maxim Sobolev wrote: > > [neither Maxim Sobolev nor Brent Verner wrote] > > In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > > >#include > > > > > >I've done a /cursory/ look over how this v_tag is used. I'm not sure > > >this is a simple/clean as you propose, since this is used in the > > >IS_LOCKING_VFS macro, as well as in union_subr.c... > > > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > > > > The places which inspect v_tag will have to be changed to use > > strcmp() then... > > I think that we can add a new vnode flag, say VCANLOCK, so that each > particular VFS can set it if it supports locking, which should allow > to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > produce a patch if it sounds reasonably. Since IS_LOCKING_VFS() is a temporary kludge, the correct fix is to remove it (after fixing whatever it was for), not to add more cruft. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 11: 7:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E3ADF37B406 for ; Tue, 4 Sep 2001 11:07:13 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA05182; Tue, 4 Sep 2001 12:06:44 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA09310; Tue, 4 Sep 2001 12:06:42 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.6194.432852.114923@nomad.yogotech.com> Date: Tue, 4 Sep 2001 12:06:42 -0600 To: tlambert2@mindspring.com Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: <3B946708.ECB7307B@mindspring.com> References: <3B946708.ECB7307B@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > What is the file system that uses VT_TFS in vnode.h? Is it still available > > on FreeBSD? Thanks. > > Julian added it for TRW Financial Services; the first public > reference machine for 386BSD (which later became FreeBSD and > NetBSD) was ref.tfs.com. So far so good. ref died an ugly horrible death, although I think I still have lying around a 4mm backup tape of what was left of it. > TRW supported a lot of the early > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw > in and had us change the version number from 0.1 to 1.0 to > make it a bit easier to sell. *Huh* That's revisionist history if I've ever heard it. We did a 1.0 release for FreeBSD because we wanted to differentiate ourselves from 386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had a 0.8 release at that time). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 11:12:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 07F3037B405 for ; Tue, 4 Sep 2001 11:12:45 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f84IC5T79375; Tue, 4 Sep 2001 20:12:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: nate@yogotech.com (Nate Williams) Cc: tlambert2@mindspring.com, Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: Your message of "Tue, 04 Sep 2001 12:06:42 MDT." <15253.6194.432852.114923@nomad.yogotech.com> Date: Tue, 04 Sep 2001 20:12:05 +0200 Message-ID: <79373.999627125@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15253.6194.432852.114923@nomad.yogotech.com>, Nate Williams writes: >> TRW supported a lot of the early >> 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw >> in and had us change the version number from 0.1 to 1.0 to >> make it a bit easier to sell. > >*Huh* That's revisionist history if I've ever heard it. We did a 1.0 >release for FreeBSD because we wanted to differentiate ourselves from >386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had >a 0.8 release at that time). Nate, You're replying to Terry for christs sake! What did you expect if not revisionist $anything ? Which reminds me, Adrian still oves us his story about ref :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 11:16:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wit379119.student.utwente.nl (wit379119.student.utwente.nl [130.89.232.129]) by hub.freebsd.org (Postfix) with ESMTP id 1B15537B40E for ; Tue, 4 Sep 2001 11:16:17 -0700 (PDT) Received: by wit379119.student.utwente.nl (Postfix, from userid 1000) id D2EFB5D35; Tue, 4 Sep 2001 19:20:30 +0200 (CEST) Date: Tue, 4 Sep 2001 19:20:30 +0200 From: Niek Bergboer To: freebsd-hackers@freebsd.org Subject: Tagged Command Queuing support for IC-35L0?0 ? Message-ID: <20010904192030.A2347@wit379119.student.utwente.nl> Reply-To: niek@bergboer.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I posted this message on -questions, and since I got no reply I've assumed that it's technical enough to post here on -hackers. Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM DTLA and DPTA IDE drives. However, the newer "Deskstar GXP" drives also support TCQ according to IBM's website? Can these newer drives, based on the IC-35L0?0-chipset, also be used with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the drive has 20, 40 or 60 GB capacity). Thanks in advance, Niek Bergboer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 12: 6:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 1239837B406; Tue, 4 Sep 2001 12:05:17 -0700 (PDT) Received: from vega.vega.com (dialup11-47.iptelecom.net.ua [212.9.228.175]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id WAA78273; Tue, 4 Sep 2001 22:05:06 +0300 (EEST) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f84J4ZZ99036; Tue, 4 Sep 2001 22:04:35 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200109041904.f84J4ZZ99036@vega.vega.com> Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 4 Sep 2001 22:04:35 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), brent@rcfile.org (Brent Verner), current@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <12420.999618814@critter> from "Poul-Henning Kamp" at Sep 04, 2001 05:53:34 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-2.97537.999630275--%" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --%--multipart-mixed-boundary-2.97537.999630275--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > apart from the numerical value, yes, looks good. Ok, please find the final patch attached. Dare I say that it looks really ugly? I'm looking forward for your comments. -Maxim > > Poul-Henning > > In message <200109041536.f84FaDG98107@vega.vega.com>, Maxim Sobolev writes: > > > >--%--multipart-mixed-boundary-1.97537.999617732--% > >Content-Type: text/plain; charset=us-ascii > >Content-Transfer-Encoding: 7bit > > > >> In message <200109041343.f84DhO097646@vega.vega.com>, Maxim Sobolev writes: > >> >> > >> >> In message <20010904081337.A8968@rcfile.org>, Brent Verner writes: > >> >> > > >> >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure > >> >> >this is a simple/clean as you propose, since this is used in the > >> >> >IS_LOCKING_VFS macro, as well as in union_subr.c... > >> >> > >> > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > >> >> > >> >> The places which inspect v_tag will have to be changed to use > >> >> strcmp() then... > >> > > >> >I think that we can add a new vnode flag, say VCANLOCK, so that each > >> >particular VFS can set it if it supports locking, which should allow > >> >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > >> >produce a patch if it sounds reasonably. > >> > >> Yeah, I think that makes a lot of sense. > > > >See attached. Please let me know if it is OK for you. > > > >-Maxim > > > >--%--multipart-mixed-boundary-1.97537.999617732--% > >Content-Type: text/plain; charset=us-ascii > >Content-Transfer-Encoding: 7bit > >Content-Description: ASCII C program text > >Content-Disposition: attachment; filename="p" > > > >Index: isofs/cd9660/cd9660_vfsops.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v > >retrieving revision 1.91 > >diff -d -u -r1.91 cd9660_vfsops.c > >--- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91 > >+++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46 > >@@ -697,6 +697,7 @@ > > } > > MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE, > > M_WAITOK | M_ZERO); > >+ vp->v_flag |= VLOCKABLE; > > lockinit(&vp->v_lock, PINOD, "isonode", 0, 0); > > /* > > * ISOFS uses stdlock and can share lock structure > >Index: ufs/ffs/ffs_vfsops.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v > >retrieving revision 1.157 > >diff -d -u -r1.157 ffs_vfsops.c > >--- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157 > >+++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25 > >@@ -1172,6 +1172,7 @@ > > return (error); > > } > > bzero((caddr_t)ip, sizeof(struct inode)); > >+ vp->v_flag |= VLOCKABLE; > > /* > > * FFS supports lock sharing in the stack of vnodes > > */ > >Index: ufs/ifs/ifs_vfsops.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v > >retrieving revision 1.6 > >diff -d -u -r1.6 ifs_vfsops.c > >--- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6 > >+++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25 > >@@ -217,6 +217,7 @@ > > return (error); > > } > > bzero((caddr_t)ip, sizeof(struct inode)); > >+ vp->v_flag |= VLOCKABLE; > > /* > > * IFS supports lock sharing in the stack of vnodes > > */ > >Index: nfs/nfs_node.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v > >retrieving revision 1.49 > >diff -d -u -r1.49 nfs_node.c > >--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49 > >+++ nfs/nfs_node.c 2001/09/04 15:21:25 > >@@ -232,6 +232,7 @@ > > } > > vp = nvp; > > bzero((caddr_t)np, sizeof *np); > >+ vp->v_flag |= VLOCKABLE; > > vp->v_data = np; > > np->n_vnode = vp; > > /* > >Index: sys/vnode.h > >=================================================================== > >RCS file: /home/ncvs/src/sys/sys/vnode.h,v > >retrieving revision 1.154 > >diff -d -u -r1.154 vnode.h > >--- sys/vnode.h 2001/08/27 06:09:55 1.154 > >+++ sys/vnode.h 2001/09/04 15:21:25 > >@@ -175,6 +175,7 @@ > > /* open for business 0x100000 */ > > #define VONWORKLST 0x200000 /* On syncer work-list */ > > #define VMOUNT 0x400000 /* Mount in progress */ > >+#define VLOCKABLE 0x600000 /* vnode supports locking */ > > > > /* > > * Vnode attributes. A field value of VNOVAL represents a field whose value > >@@ -433,12 +434,7 @@ > > /* > > * [dfr] Kludge until I get around to fixing all the vfs locking. > > */ > >-#define IS_LOCKING_VFS(vp) ((vp)->v_tag == VT_UFS \ > >- || (vp)->v_tag == VT_NFS \ > >- || (vp)->v_tag == VT_LFS \ > >- || (vp)->v_tag == VT_ISOFS \ > >- || (vp)->v_tag == VT_MSDOSFS \ > >- || (vp)->v_tag == VT_DEVFS) > >+#define IS_LOCKING_VFS(vp) ((vp)->v_flag & VLOCKABLE) > > > > #define ASSERT_VOP_LOCKED(vp, str) \ > > do { \ > >Index: fs/devfs/devfs_vnops.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v > >retrieving revision 1.27 > >diff -d -u -r1.27 devfs_vnops.c > >--- fs/devfs/devfs_vnops.c 2001/08/14 06:42:32 1.27 > >+++ fs/devfs/devfs_vnops.c 2001/09/04 15:21:25 > >@@ -151,6 +151,7 @@ > > } else { > > vp->v_type = VBAD; > > } > >+ vp->v_flag |= VLOCKABLE; > > vp->v_data = de; > > de->de_vnode = vp; > > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); > >Index: fs/msdosfs/msdosfs_denode.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v > >retrieving revision 1.57 > >diff -d -u -r1.57 msdosfs_denode.c > >--- fs/msdosfs/msdosfs_denode.c 2001/05/25 08:14:09 1.57 > >+++ fs/msdosfs/msdosfs_denode.c 2001/09/04 15:21:33 > >@@ -261,6 +261,7 @@ > > return error; > > } > > bzero((caddr_t)ldep, sizeof *ldep); > >+ nvp->v_flag |= VLOCKABLE; > > lockinit(&nvp->v_lock, PINOD, "denode", 0, 0); > > nvp->v_vnlock = &nvp->v_lock; > > nvp->v_data = ldep; > > > >--%--multipart-mixed-boundary-1.97537.999617732--%-- > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > --%--multipart-mixed-boundary-2.97537.999630275--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: ASCII C program text Content-Disposition: attachment; filename="v_tag.diff" Index: coda/coda.h =================================================================== RCS file: /home/ncvs/src/sys/coda/coda.h,v retrieving revision 1.9 diff -d -u -r1.9 coda.h --- coda/coda.h 1999/12/29 04:54:30 1.9 +++ coda/coda.h 2001/09/04 18:46:42 @@ -41,7 +41,7 @@ #ifndef _CODA_HEADER_ #define _CODA_HEADER_ - +#define VT_CODA "VT_CODA" /* Catch new _KERNEL defn for NetBSD */ #ifdef __NetBSD__ Index: fs/devfs/devfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs.h,v retrieving revision 1.7 diff -d -u -r1.7 devfs.h --- fs/devfs/devfs.h 2001/05/23 17:48:20 1.7 +++ fs/devfs/devfs.h 2001/09/04 18:47:23 @@ -37,6 +37,8 @@ #ifndef _FS_DEVFS_DEVFS_H_ #define _FS_DEVFS_DEVFS_H_ +#define VT_DEVFS "VT_DEVFS" + #ifdef _KERNEL /* No userland stuff in here... */ /* Index: fs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v retrieving revision 1.27 diff -d -u -r1.27 devfs_vnops.c --- fs/devfs/devfs_vnops.c 2001/08/14 06:42:32 1.27 +++ fs/devfs/devfs_vnops.c 2001/09/04 18:47:23 @@ -151,6 +151,7 @@ } else { vp->v_type = VBAD; } + vp->v_flag |= VLOCKABLE; vp->v_data = de; de->de_vnode = vp; vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); Index: fs/fdescfs/fdesc.h =================================================================== RCS file: /home/ncvs/src/sys/fs/fdescfs/fdesc.h,v retrieving revision 1.14 diff -d -u -r1.14 fdesc.h --- fs/fdescfs/fdesc.h 2000/10/09 20:06:13 1.14 +++ fs/fdescfs/fdesc.h 2001/09/04 18:47:23 @@ -38,6 +38,8 @@ * $FreeBSD: src/sys/fs/fdescfs/fdesc.h,v 1.14 2000/10/09 20:06:13 chris Exp $ */ +#define VT_FDESC "VT_FDESC" + #ifdef _KERNEL struct fdescmount { struct vnode *f_root; /* Root node */ Index: fs/hpfs/hpfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/hpfs/hpfs.h,v retrieving revision 1.6 diff -d -u -r1.6 hpfs.h --- fs/hpfs/hpfs.h 2001/04/25 07:07:43 1.6 +++ fs/hpfs/hpfs.h 2001/09/04 18:47:28 @@ -44,6 +44,8 @@ #define BMSIZE (4 * DEV_BSIZE) #define HPFS_MAXFILENAME 255 +#define VT_HPFS "VT_HPFS" + #define SU_MAGIC ((u_int64_t)0xFA53E9C5F995E849) struct sublock { u_int64_t su_magic; Index: fs/msdosfs/fat.h =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/fat.h,v retrieving revision 1.9 diff -d -u -r1.9 fat.h --- fs/msdosfs/fat.h 1999/12/29 04:54:53 1.9 +++ fs/msdosfs/fat.h 2001/09/04 18:47:28 @@ -83,6 +83,8 @@ #define MSDOSFSEOF(pmp, cn) ((((cn) | ~(pmp)->pm_fatmask) & CLUST_EOFS) == CLUST_EOFS) +#define VT_MSDOSFS "VT_MSDOSFS" + #ifdef _KERNEL /* * These are the values for the function argument to the function Index: fs/msdosfs/msdosfs_denode.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v retrieving revision 1.57 diff -d -u -r1.57 msdosfs_denode.c --- fs/msdosfs/msdosfs_denode.c 2001/05/25 08:14:09 1.57 +++ fs/msdosfs/msdosfs_denode.c 2001/09/04 18:47:28 @@ -261,6 +261,7 @@ return error; } bzero((caddr_t)ldep, sizeof *ldep); + nvp->v_flag |= VLOCKABLE; lockinit(&nvp->v_lock, PINOD, "denode", 0, 0); nvp->v_vnlock = &nvp->v_lock; nvp->v_data = ldep; Index: fs/msdosfs/msdosfs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vfsops.c,v retrieving revision 1.79 diff -d -u -r1.79 msdosfs_vfsops.c --- fs/msdosfs/msdosfs_vfsops.c 2001/06/28 03:47:50 1.79 +++ fs/msdosfs/msdosfs_vfsops.c 2001/09/04 18:47:28 @@ -770,8 +770,8 @@ TAILQ_FIRST(&vp->v_cleanblkhd), TAILQ_FIRST(&vp->v_dirtyblkhd), vp->v_numoutput, vp->v_type); - printf("union %p, tag %d, data[0] %08x, data[1] %08x\n", - vp->v_socket, vp->v_tag, + printf("union %p, tag %s, data[0] %08x, data[1] %08x\n", + vp->v_socket, vp->v_tag != NULL ? vp->v_tag : "VT_NON", ((u_int *)vp->v_data)[0], ((u_int *)vp->v_data)[1]); } Index: fs/ntfs/ntfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/ntfs/ntfs.h,v retrieving revision 1.10 diff -d -u -r1.10 ntfs.h --- fs/ntfs/ntfs.h 2001/04/25 07:07:48 1.10 +++ fs/ntfs/ntfs.h 2001/09/04 18:47:33 @@ -36,6 +36,8 @@ typedef u_int64_t cn_t; typedef u_int16_t wchar; +#define VT_NTFS "VT_NTFS" + #pragma pack(1) #define BBSIZE 1024 #define BBOFF ((off_t)(0)) Index: fs/nullfs/null.h =================================================================== RCS file: /home/ncvs/src/sys/fs/nullfs/null.h,v retrieving revision 1.15 diff -d -u -r1.15 null.h --- fs/nullfs/null.h 2000/09/05 09:02:07 1.15 +++ fs/nullfs/null.h 2001/09/04 18:47:33 @@ -47,6 +47,8 @@ struct vnode *nullm_rootvp; /* Reference to root null_node */ }; +#define VT_NULL "VT_NULL" + #ifdef _KERNEL /* * A cache of vnode references Index: fs/nwfs/nwfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/nwfs/nwfs.h,v retrieving revision 1.4 diff -d -u -r1.4 nwfs.h --- fs/nwfs/nwfs.h 2001/05/26 11:57:37 1.4 +++ fs/nwfs/nwfs.h 2001/09/04 18:47:33 @@ -49,6 +49,8 @@ #define NWFSIOC_GETEINFO _IOR('n',2,struct nw_entry_info) #define NWFSIOC_GETNS _IOR('n',3,int) +#define VT_NWFS "VT_NWFS" + #ifdef _KERNEL #include Index: fs/portalfs/portal.h =================================================================== RCS file: /home/ncvs/src/sys/fs/portalfs/portal.h,v retrieving revision 1.7 diff -d -u -r1.7 portal.h --- fs/portalfs/portal.h 1999/12/29 04:54:45 1.7 +++ fs/portalfs/portal.h 2001/09/04 18:47:33 @@ -67,5 +67,7 @@ #define PORTAL_ROOTFILEID 2 +#define VT_PORTAL "VT_PORTAL" + extern vop_t **portal_vnodeop_p; #endif /* _KERNEL */ Index: fs/procfs/procfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/procfs/procfs.h,v retrieving revision 1.37 diff -d -u -r1.37 procfs.h --- fs/procfs/procfs.h 2001/08/03 17:51:05 1.37 +++ fs/procfs/procfs.h 2001/09/04 18:47:33 @@ -80,6 +80,8 @@ #define PROCFS_CTLLEN 8 /* max length of a ctl msg (/proc/$pid/ctl */ #define PROCFS_NAMELEN 8 /* max length of a filename component */ +#define VT_PROCFS "VT_PROCFS" + /* * Kernel stuff follows */ Index: fs/pseudofs/pseudofs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/pseudofs/pseudofs.h,v retrieving revision 1.5 diff -d -u -r1.5 pseudofs.h --- fs/pseudofs/pseudofs.h 2001/06/10 21:37:11 1.5 +++ fs/pseudofs/pseudofs.h 2001/09/04 18:47:33 @@ -37,6 +37,8 @@ #define PFS_NAMELEN 24 #define PFS_DELEN (8 + PFS_NAMELEN) +#define VT_PSEUDOFS "VT_PSEUDOFS" + typedef enum { pfstype_none = 0, pfstype_root, Index: fs/smbfs/smbfs.h =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs.h,v retrieving revision 1.2 diff -d -u -r1.2 smbfs.h --- fs/smbfs/smbfs.h 2001/04/13 11:26:54 1.2 +++ fs/smbfs/smbfs.h 2001/09/04 18:47:33 @@ -48,6 +48,7 @@ #define SMBFS_MAXPATHCOMP 256 /* maximum number of path components */ +#define VT_SMBFS "VT_SMBFS" /* Layout of the mount control block for a netware file system. */ struct smbfs_args { Index: fs/umapfs/umap.h =================================================================== RCS file: /home/ncvs/src/sys/fs/umapfs/umap.h,v retrieving revision 1.15 diff -d -u -r1.15 umap.h --- fs/umapfs/umap.h 2000/05/26 02:05:04 1.15 +++ fs/umapfs/umap.h 2001/09/04 18:47:33 @@ -43,6 +43,8 @@ #define NOBODY 32767 #define NULLGROUP 65534 +#define VT_UMAP "VT_UMAP" + struct umap_args { char *target; /* Target of loopback */ int nentries; /* # of entries in user map array */ Index: fs/unionfs/union.h =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union.h,v retrieving revision 1.20 diff -d -u -r1.20 union.h --- fs/unionfs/union.h 2001/05/17 04:52:57 1.20 +++ fs/unionfs/union.h 2001/09/04 18:47:33 @@ -48,6 +48,8 @@ #define UNMNT_REPLACE 0x0003 /* Target replaces mount point */ #define UNMNT_OPMASK 0x0003 +#define VT_UNION "VT_UNION" + struct union_mount { struct vnode *um_uppervp; /* UN_ULOCK holds locking state */ struct vnode *um_lowervp; /* Left unlocked */ Index: fs/unionfs/union_subr.c =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union_subr.c,v retrieving revision 1.54 diff -d -u -r1.54 union_subr.c --- fs/unionfs/union_subr.c 2001/05/23 09:42:13 1.54 +++ fs/unionfs/union_subr.c 2001/09/04 18:47:40 @@ -443,7 +443,9 @@ do { scan = VTOUNION(scan)->un_pvp; - } while (scan && scan->v_tag == VT_UNION && scan != dvp); + } while (scan && scan->v_tag != NULL && + /* XXX: ABUSE OF v_tag */ + strcmp(scan->v_tag, VT_UNION) == 0 && scan != dvp); if (scan != dvp) { /* * our new un is above dvp (we never saw dvp Index: isofs/cd9660/cd9660_mount.h =================================================================== RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_mount.h,v retrieving revision 1.5 diff -d -u -r1.5 cd9660_mount.h --- isofs/cd9660/cd9660_mount.h 2001/03/11 10:05:08 1.5 +++ isofs/cd9660/cd9660_mount.h 2001/09/04 18:48:02 @@ -39,6 +39,8 @@ * $FreeBSD: src/sys/isofs/cd9660/cd9660_mount.h,v 1.5 2001/03/11 10:05:08 bp Exp $ */ +#define VT_ISOFS "VT_ISOFS" + /* * Arguments to mount ISO 9660 filesystems. */ Index: isofs/cd9660/cd9660_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v retrieving revision 1.91 diff -d -u -r1.91 cd9660_vfsops.c --- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91 +++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 18:48:16 @@ -697,6 +697,7 @@ } MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE, M_WAITOK | M_ZERO); + vp->v_flag |= VLOCKABLE; lockinit(&vp->v_lock, PINOD, "isonode", 0, 0); /* * ISOFS uses stdlock and can share lock structure Index: kern/kern_descrip.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.104 diff -d -u -r1.104 kern_descrip.c --- kern/kern_descrip.c 2001/08/23 13:19:32 1.104 +++ kern/kern_descrip.c 2001/09/04 18:48:16 @@ -66,6 +66,8 @@ #include #include +#include + static MALLOC_DEFINE(M_FILEDESC, "file desc", "Open file descriptor table"); MALLOC_DEFINE(M_FILE, "file", "Open file structure"); static MALLOC_DEFINE(M_SIGIO, "sigio", "sigio structures"); @@ -1102,9 +1104,13 @@ static int is_unsafe(struct file *fp) { - if (fp->f_type == DTYPE_VNODE && - ((struct vnode *)(fp->f_data))->v_tag == VT_PROCFS) - return (1); + + if (fp->f_type == DTYPE_VNODE) { + /* XXX: ABUSE OF v_tag */ + const char *tag= ((struct vnode *)(fp->f_data))->v_tag; + if (tag != NULL && strcmp(tag, VT_PROCFS) == 0) + return (1); + } return (0); } Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.287 diff -d -u -r1.287 vfs_bio.c --- kern/vfs_bio.c 2001/08/22 18:10:37 1.287 +++ kern/vfs_bio.c 2001/09/04 18:48:29 @@ -159,6 +159,8 @@ #define VFS_BIO_NEED_FREE 0x04 /* wait for free bufs, hi hysteresis */ #define VFS_BIO_NEED_BUFSPACE 0x08 /* wait for buf space, lo hysteresis */ +#define VT_NFS "VT_NFS" /* XXX */ + /* * Buffer hash table code. Note that the logical block scans linearly, which * gives us some L1 cache locality. @@ -1122,8 +1124,8 @@ * around to prevent it from being reconstituted and starting a second * background write. */ - if ((bp->b_flags & B_VMIO) - && !(bp->b_vp->v_tag == VT_NFS && + if ((bp->b_flags & B_VMIO) && bp->b_vp->v_tag != NULL + && !((strcmp(bp->b_vp->v_tag, VT_NFS) == 0) && /* XXX: ABUSE OF v_tag */ !vn_isdisk(bp->b_vp, NULL) && (bp->b_flags & B_DELWRI)) ) { Index: kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.318 diff -d -u -r1.318 vfs_subr.c --- kern/vfs_subr.c 2001/08/27 06:09:54 1.318 +++ kern/vfs_subr.c 2001/09/04 18:48:42 @@ -518,7 +518,7 @@ */ int getnewvnode(tag, mp, vops, vpp) - enum vtagtype tag; + const char *tag; struct mount *mp; vop_t **vops; struct vnode **vpp; @@ -1061,7 +1061,8 @@ */ if (TAILQ_EMPTY(&vp->v_dirtyblkhd) && !vn_isdisk(vp, NULL)) - panic("sched_sync: fsync failed vp %p tag %d", vp, vp->v_tag); + panic("sched_sync: fsync failed vp %p tag %s", + vp, vp->v_tag != NULL ? vp->v_tag : "VT_NON"); /* * Put us back on the worklist. The worklist * routine will remove us from our current @@ -1338,7 +1339,7 @@ } if (vfinddev(dev, VCHR, vpp)) return (0); - error = getnewvnode(VT_NON, (struct mount *)0, spec_vnodeop_p, &nvp); + error = getnewvnode(NULL, (struct mount *)0, spec_vnodeop_p, &nvp); if (error) { *vpp = NULLVP; return (error); @@ -1863,7 +1864,7 @@ */ vp->v_op = dead_vnodeop_p; vn_pollgone(vp); - vp->v_tag = VT_NON; + vp->v_tag = NULL; vp->v_flag &= ~VXLOCK; vp->v_vxproc = NULL; if (vp->v_flag & VXWANT) { @@ -2605,7 +2606,7 @@ int error; /* Allocate a new vnode */ - if ((error = getnewvnode(VT_VFS, mp, sync_vnodeop_p, &vp)) != 0) { + if ((error = getnewvnode("VT_VFS", mp, sync_vnodeop_p, &vp)) != 0) { mp->mnt_syncer = NULL; return (error); } Index: nfs/nfs.h =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs.h,v retrieving revision 1.59 diff -d -u -r1.59 nfs.h --- nfs/nfs.h 2001/04/17 20:45:21 1.59 +++ nfs/nfs.h 2001/09/04 18:48:48 @@ -44,6 +44,8 @@ #include "opt_nfs.h" #endif +#define VT_NFS "VT_NFS" + /* * Tunable constants for nfs */ Index: nfs/nfs_node.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.49 diff -d -u -r1.49 nfs_node.c --- nfs/nfs_node.c 2001/05/01 08:13:14 1.49 +++ nfs/nfs_node.c 2001/09/04 18:48:48 @@ -232,6 +232,7 @@ } vp = nvp; bzero((caddr_t)np, sizeof *np); + vp->v_flag |= VLOCKABLE; vp->v_data = np; np->n_vnode = vp; /* @@ -393,7 +394,7 @@ vp->v_flag |= VXWANT; (void) tsleep((caddr_t)vp, PINOD, "nfslck", 0); } - if (vp->v_tag == VT_NON) + if (vp->v_tag == NULL) return (ENOENT); #if 0 Index: nfsclient/nfs_node.c =================================================================== RCS file: /home/ncvs/src/sys/nfsclient/nfs_node.c,v retrieving revision 1.49 diff -d -u -r1.49 nfs_node.c --- nfsclient/nfs_node.c 2001/05/01 08:13:14 1.49 +++ nfsclient/nfs_node.c 2001/09/04 18:48:55 @@ -393,7 +393,7 @@ vp->v_flag |= VXWANT; (void) tsleep((caddr_t)vp, PINOD, "nfslck", 0); } - if (vp->v_tag == VT_NON) + if (vp->v_tag == NULL) return (ENOENT); #if 0 Index: sys/vnode.h =================================================================== RCS file: /home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.154 diff -d -u -r1.154 vnode.h --- sys/vnode.h 2001/08/27 06:09:55 1.154 +++ sys/vnode.h 2001/09/04 18:49:14 @@ -62,18 +62,6 @@ enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VFIFO, VBAD }; /* - * Vnode tag types. - * These are for the benefit of external programs only (e.g., pstat) - * and should NEVER be inspected by the kernel. - */ -enum vtagtype { - VT_NON, VT_UFS, VT_NFS, VT_UNUSED, VT_PC, VT_LFS, VT_LOFS, VT_FDESC, - VT_PORTAL, VT_NULL, VT_UMAP, VT_KERNFS, VT_PROCFS, VT_AFS, VT_ISOFS, - VT_UNION, VT_MSDOSFS, VT_DEVFS, VT_TFS, VT_VFS, VT_CODA, VT_NTFS, - VT_HPFS, VT_NWFS, VT_PSEUDOFS, VT_SMBFS -}; - -/* * Each underlying filesystem allocates its own private area and hangs * it from v_data. If non-null, this area is freed in getnewvnode(). */ @@ -123,7 +111,7 @@ struct mtx v_interlock; /* lock on usecount and flag */ struct lock v_lock; /* used if fs don't have one */ struct lock *v_vnlock; /* pointer to vnode lock */ - enum vtagtype v_tag; /* type of underlying data */ + const char *v_tag; /* type of underlying data */ void *v_data; /* private data for fs */ LIST_HEAD(, namecache) v_cache_src; /* Cache entries from us */ TAILQ_HEAD(, namecache) v_cache_dst; /* Cache entries to us */ @@ -175,6 +163,7 @@ /* open for business 0x100000 */ #define VONWORKLST 0x200000 /* On syncer work-list */ #define VMOUNT 0x400000 /* Mount in progress */ +#define VLOCKABLE 0x800000 /* vnode supports locking */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value @@ -433,12 +422,7 @@ /* * [dfr] Kludge until I get around to fixing all the vfs locking. */ -#define IS_LOCKING_VFS(vp) ((vp)->v_tag == VT_UFS \ - || (vp)->v_tag == VT_NFS \ - || (vp)->v_tag == VT_LFS \ - || (vp)->v_tag == VT_ISOFS \ - || (vp)->v_tag == VT_MSDOSFS \ - || (vp)->v_tag == VT_DEVFS) +#define IS_LOCKING_VFS(vp) ((vp)->v_flag & VLOCKABLE) #define ASSERT_VOP_LOCKED(vp, str) \ do { \ @@ -561,7 +545,7 @@ void cache_purgeleafdirs __P((int ndir)); void cvtstat __P((struct stat *st, struct ostat *ost)); void cvtnstat __P((struct stat *sb, struct nstat *nsb)); -int getnewvnode __P((enum vtagtype tag, +int getnewvnode __P((const char *tag, struct mount *mp, vop_t **vops, struct vnode **vpp)); int lease_check __P((struct vop_lease_args *ap)); int spec_vnoperate __P((struct vop_generic_args *)); Index: ufs/ffs/ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.157 diff -d -u -r1.157 ffs_vfsops.c --- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157 +++ ufs/ffs/ffs_vfsops.c 2001/09/04 18:49:14 @@ -1172,6 +1172,7 @@ return (error); } bzero((caddr_t)ip, sizeof(struct inode)); + vp->v_flag |= VLOCKABLE; /* * FFS supports lock sharing in the stack of vnodes */ Index: ufs/ifs/ifs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v retrieving revision 1.6 diff -d -u -r1.6 ifs_vfsops.c --- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6 +++ ufs/ifs/ifs_vfsops.c 2001/09/04 18:49:14 @@ -217,6 +217,7 @@ return (error); } bzero((caddr_t)ip, sizeof(struct inode)); + vp->v_flag |= VLOCKABLE; /* * IFS supports lock sharing in the stack of vnodes */ Index: ufs/ufs/ufsmount.h =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufsmount.h,v retrieving revision 1.21 diff -d -u -r1.21 ufsmount.h --- ufs/ufs/ufsmount.h 2001/05/29 21:21:53 1.21 +++ ufs/ufs/ufsmount.h 2001/09/04 18:49:14 @@ -37,6 +37,8 @@ #ifndef _UFS_UFS_UFSMOUNT_H_ #define _UFS_UFS_UFSMOUNT_H_ +#define VT_UFS "VT_UFS" + /* * Arguments to mount UFS-based filesystems */ Index: vm/vm_swap.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_swap.c,v retrieving revision 1.110 diff -d -u -r1.110 vm_swap.c --- vm/vm_swap.c 2001/07/28 20:18:38 1.110 +++ vm/vm_swap.c 2001/09/04 18:49:15 @@ -65,6 +65,7 @@ #ifndef NSWAPDEV #define NSWAPDEV 4 #endif +#define VT_NFS "VT_NFS" /* XXX */ static struct swdevt should_be_malloced[NSWAPDEV]; struct swdevt *swdevt = should_be_malloced; static int nswap; /* first block after the interleaved devs */ @@ -215,7 +216,8 @@ if (vn_isdisk(vp, &error)) error = swaponvp(p, vp, vp->v_rdev, 0); - else if (vp->v_type == VREG && vp->v_tag == VT_NFS && + else if (vp->v_type == VREG && vp->v_tag != NULL && + strcmp(vp->v_tag, VT_NFS) == 0 && /* XXX: ABUSE of v_tag */ (error = VOP_GETATTR(vp, &attr, p->p_ucred, p)) == 0) { /* * Allow direct swapping to NFS regular files in the same @@ -257,7 +259,7 @@ u_long aligned_nblks; if (!swapdev_vp) { - error = getnewvnode(VT_NON, NULL, swapdev_vnodeop_p, + error = getnewvnode(NULL, NULL, swapdev_vnodeop_p, &swapdev_vp); if (error) panic("Cannot get vnode for swapdev"); --%--multipart-mixed-boundary-2.97537.999630275--%-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 12:12:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D2D7F37B40B for ; Tue, 4 Sep 2001 12:12:25 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA19028; Tue, 4 Sep 2001 12:21:14 -0700 (PDT) Date: Tue, 4 Sep 2001 12:21:13 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: Nate Williams , tlambert2@mindspring.com, Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: <79373.999627125@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Sep 2001, Poul-Henning Kamp wrote: > > Which reminds me, Adrian still oves us his story about ref :-) Yeah, the REAL one... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 12:59: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by hub.freebsd.org (Postfix) with ESMTP id 4929937B403 for ; Tue, 4 Sep 2001 12:58:58 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id f84Jwjc26213; Tue, 4 Sep 2001 15:58:46 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id f84Jwif03589; Tue, 4 Sep 2001 15:58:44 -0400 (EDT) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub1.mitre.org with SMTP id 7513535; Tue, 04 Sep 2001 15:58:41 -0400 Message-ID: <3B953273.5001C515@mitre.org> Date: Tue, 04 Sep 2001 15:58:43 -0400 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: niek@bergboer.net Cc: freebsd-hackers@freebsd.org Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? References: <20010904192030.A2347@wit379119.student.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Niek Bergboer wrote: > > Hi, > > I posted this message on -questions, and since I got no reply I've > assumed that it's technical enough to post here on -hackers. > > Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM > DTLA and DPTA IDE drives. However, the newer "Deskstar GXP" drives > also support TCQ according to IBM's website? > > Can these newer drives, based on the IC-35L0?0-chipset, also be used > with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the > drive has 20, 40 or 60 GB capacity). I think so: ad0: 58644MB [119150/16/63] at ata0-master tagged UDMA33 I had to manually add "IC35L060AVER07-0" to ata-disk.c (around line 832) to get FreeBSD to use it though. ... ad_tagsupported(struct ad_softc *adp) { const char *drives[] = {"IBM-DPTA", "IBM-DTLA", "IC35L060AVER07-0", NULL}; ... This was a month or so though, so someone might have done the right thing and figured out how to parse those new IBM product strings to determine if the drive supports CTQ or not. -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 13:38:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mother.ludd.luth.se (mother.ludd.luth.se [130.240.16.3]) by hub.freebsd.org (Postfix) with ESMTP id 91BD237B410 for ; Tue, 4 Sep 2001 13:38:16 -0700 (PDT) Received: from brother.ludd.luth.se (brother.ludd.luth.se [130.240.16.78]) by mother.ludd.luth.se (8.9.3+Sun/8.9.3) with ESMTP id WAA12048; Tue, 4 Sep 2001 22:38:13 +0200 (MEST) Message-Id: <200109042038.WAA12048@mother.ludd.luth.se> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Michael Sinz Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Should URL's be pervasive. In-Reply-To: Message from Michael Sinz of "Tue, 04 Sep 2001 09:19:07 EDT." <0000046c02083c07d1@[192.168.1.4]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Sep 2001 22:38:11 +0200 From: Mattias Pantzare Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > NAME > > amd - automatically mount file systems > > ... > > DESCRIPTION > > Amd is a daemon that automatically mounts filesystems whenever a file or > > directory within that filesystem is accessed. Filesystems are automati- > > cally unmounted when they appear to be quiescent. > > Ahh, but that assumes that your AMD configuration has all systems and mount > points enumerated in it. Let me see - I think that 30gig drive may be big > enough for that file :-) No. Set amd_enable to YES in /etc/rc.conf and the default configuration will let you do a cd /net/nfs_servername.someplace to view all NFS exported filesystems on nfs_servername.someplace. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 13:46:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 3542F37B40D; Tue, 4 Sep 2001 13:46:23 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Sep 2001 21:46:22 +0100 (BST) Date: Tue, 4 Sep 2001 21:46:22 +0100 From: David Malone To: David O'Brien Cc: freebsd-hackers@freebsd.org Subject: Re: signal handling descrpancy (FreeBSD oaf fix/Evolution) Message-ID: <20010904214622.A24258@walton.maths.tcd.ie> References: <20010902095503.A64412@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010902095503.A64412@dragon.nuxi.com>; from obrien@freebsd.org on Sun, Sep 02, 2001 at 09:55:03AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Sep 02, 2001 at 09:55:03AM -0700, David O'Brien wrote: > The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, > does not run on FreeBSD. The authors have made a change so that it will. > However, we would like to know if FreeBSD is the odd-man-out, or if the > authors were lucky Evolution ran on Solaris and Linux. I think this is the change which we had a patch for recently. It was committed to -current and -stable recently. Unfortunately there was a small problem with the implimentation and had to be backed out. I think either Matt or Ian or both had fixes for the problems, but they haven't been recommitted yet. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 14:19:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from seven.Alameda.net (seven.Alameda.net [64.81.63.137]) by hub.freebsd.org (Postfix) with ESMTP id BC28637B406 for ; Tue, 4 Sep 2001 14:19:06 -0700 (PDT) Received: by seven.Alameda.net (Postfix, from userid 1000) id 810F83A24E; Tue, 4 Sep 2001 14:19:06 -0700 (PDT) Date: Tue, 4 Sep 2001 14:19:06 -0700 From: Ulf Zimmermann To: hackers@FreeBSD.org Subject: Question about VLAN dot1q tagging in FreeBSD Message-ID: <20010904141906.B31175@seven.alameda.net> Reply-To: ulf@Alameda.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.3-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Got a question for the people who worked on the support. All my experience is under 4.3-Release/-Stable/4.4-RC3. A while back when I wanted to use dot1q tagging, it seems to work fine with the expection that I wasn't able to get VLAN 1 (default VLAN) to work. Last night I setup dot1q tagging again on another machine and had the same problem. Looking into packets sent down the trunk, I saw that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that VLAN 1 packets aren't tagged, while other VLANs are). If this is right, I think we should mention this in the man page. Here is a copy of the current man page of ifconfig in regards to VLAN: vlan vlan_tag If the interface is a vlan pseudo interface, set the vlan tag value to vlan_tag. This value is a 16-bit number which is used to create an 802.1Q vlan header for packets sent from the vlan interface. Note that vlan and vlandev must both be set at the same time. vlandev iface If the interface is a vlan pseudo device, associate physical interface iface with it. Packets transmitted through the vlan interface will be diverted to the specified physical interface iface with 802.1Q vlan encapsulation. Packets with 802.1Q encap- sulation received by the parent interface with the correct vlan tag will be diverted to the associated vlan pseudo-interface. The vlan interface is assigned a copy of the parent interface's flags and the parent's ethernet address. The vlandev and vlan must both be set at the same time. If the vlan interface already has a physical interface associated with it, this command will fail. To change the association to another physical interface, the existing association must be cleared first. Note: if the link0 flag is set on the vlan interface, the vlan pseudo interface's behavior changes: the link0 tells the vlan interface that the parent interface supports insertion and extraction of vlan tags on its own (usually in firmware) and that it should pass packets to and from the parent unaltered. -vlandev iface If the driver is a vlan pseudo device, disassociate the physical interface iface from it. This breaks the link between the vlan interface and its parent, clears its vlan tag, flags and its link address and shuts the interface down. My current config in the case I setup last night looks like this from /etc/rc.conf: network_interfaces="fxp0 vlan2 lo0" ifconfig_fxp0="inet 192.168.0.250 netmask 255.255.255.0 media 100basetx mediaopt full-duplex" ifconfig_vlan2="inet 64.81.63.130 netmask 255.255.255.224 vlan 2 vlandev fxp0" 192.168.0.250 is my private LAN which is VLAN 1 on my switches. VLAN 2 and 3 are my external networks (DSL/Cable Modem). My suggestion is to add to ifconfig man page something like this under "vlan vlan_tag": Note: VLAN 1 is not tagged and should be put directly on the physical interface. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 14:24:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 74E3237B40B for ; Tue, 4 Sep 2001 14:24:52 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f84LOoe52170; Tue, 4 Sep 2001 17:24:50 -0400 (EDT) (envelope-from bicknell) Date: Tue, 4 Sep 2001 17:24:50 -0400 From: Leo Bicknell To: Ulf Zimmermann Cc: hackers@FreeBSD.ORG Subject: Re: Question about VLAN dot1q tagging in FreeBSD Message-ID: <20010904172450.A52029@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Ulf Zimmermann , hackers@FreeBSD.ORG References: <20010904141906.B31175@seven.alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904141906.B31175@seven.alameda.net>; from ulf@Alameda.net on Tue, Sep 04, 2001 at 02:19:06PM -0700 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote: > Last night I setup dot1q tagging again on another machine and had > the same problem. Looking into packets sent down the trunk, I saw > that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that > VLAN 1 packets aren't tagged, while other VLANs are). If this is > right, I think we should mention this in the man page. Here is a > copy of the current man page of ifconfig in regards to VLAN: It is slightly more complicated. 802.1q allows a single, untagged vlan to operate across a link for compatability reasons, and calls it the 'default' VLAN. There is no requirement that it be VLAN 1. That is, you could set the default vlan to be 10 on both sides, and tag all the rest (including 1). You could also set vlan 1 on one side, and vlan 10 on the other, and they would be bridged together. Cisco devices warn when you do this (via CDP, it must be enabled). Convention seems to be that vlan 1 is the 'default vlan' on almost all devices. Having better notes in a man page would be good. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 14:30:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from seven.Alameda.net (seven.Alameda.net [64.81.63.137]) by hub.freebsd.org (Postfix) with ESMTP id E588037B405 for ; Tue, 4 Sep 2001 14:30:15 -0700 (PDT) Received: by seven.Alameda.net (Postfix, from userid 1000) id B1B063A24E; Tue, 4 Sep 2001 14:30:15 -0700 (PDT) Date: Tue, 4 Sep 2001 14:30:15 -0700 From: Ulf Zimmermann To: Leo Bicknell , Ulf Zimmermann , hackers@FreeBSD.ORG Subject: Re: Question about VLAN dot1q tagging in FreeBSD Message-ID: <20010904143015.C31175@seven.alameda.net> Reply-To: ulf@Alameda.net References: <20010904141906.B31175@seven.alameda.net> <20010904172450.A52029@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904172450.A52029@ussenterprise.ufp.org>; from bicknell@ufp.org on Tue, Sep 04, 2001 at 05:24:50PM -0400 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.3-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 04, 2001 at 05:24:50PM -0400, Leo Bicknell wrote: > On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote: > > Last night I setup dot1q tagging again on another machine and had > > the same problem. Looking into packets sent down the trunk, I saw > > that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that > > VLAN 1 packets aren't tagged, while other VLANs are). If this is > > right, I think we should mention this in the man page. Here is a > > copy of the current man page of ifconfig in regards to VLAN: > > It is slightly more complicated. 802.1q allows a single, untagged > vlan to operate across a link for compatability reasons, and calls > it the 'default' VLAN. There is no requirement that it be VLAN 1. > That is, you could set the default vlan to be 10 on both sides, > and tag all the rest (including 1). You could also set vlan 1 on > one side, and vlan 10 on the other, and they would be bridged > together. Cisco devices warn when you do this (via CDP, it must > be enabled). All the documentation I have read lately seemed to indicated that VLAN 1 is the one to be present, but I haven't read the dot1q spec (time to do that (: ). > > Convention seems to be that vlan 1 is the 'default vlan' on almost > all devices. > > Having better notes in a man page would be good. We should at least put a note into the man about it, different wording when what I had posted. I haven't checked the handbook lately, but every time I mention dot1q tagging and FreeBSD, I seem to find someone who says the documentation about it is very sparse. We might want to review that too. I personal use it for lab setups I have done at home (been trying to CCIE, but right now I am having a grudge against Cisco and their supposely high quality about the tests (Lab protoctor showed up late, didn't give the lost time at the end, errors in the documentation of the lab, no reply from the CCIE program so far)). > > -- > Leo Bicknell - bicknell@ufp.org > Systems Engineer - Internetworking Engineer - CCIE 3440 > Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org > -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 14:44:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail29.sdc1.sfba.home.com (femail29.sdc1.sfba.home.com [24.254.60.19]) by hub.freebsd.org (Postfix) with ESMTP id 0285E37B403 for ; Tue, 4 Sep 2001 14:44:10 -0700 (PDT) Received: from bean.overtone.org ([24.249.254.100]) by femail29.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010904214409.BIOU15592.femail29.sdc1.sfba.home.com@bean.overtone.org>; Tue, 4 Sep 2001 14:44:09 -0700 Received: by bean.overtone.org (Postfix, from userid 1001) id 9D12F5B4D9; Tue, 4 Sep 2001 21:43:44 +0000 (GMT) Date: Tue, 4 Sep 2001 21:43:43 +0000 From: Kevin Way To: Joseph Mallett Cc: freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <20010904214343.B77906@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010904161534.A97071@NewGold.NET>; from jmallett@NewGold.NET on Tue, Sep 04, 2001 at 04:15:34PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > If you're really lazy and want to be able to do: > telnet smtp://localhost > I suggest you look into this relatively new invention called > '/etc/services' and read some manual pages. You'll find you can do > something quite similar, and much saner. I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea "lazy". I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Kevin Way To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 14:46:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aries.ai.net (aries.ai.net [205.134.163.4]) by hub.freebsd.org (Postfix) with ESMTP id C494F37B401; Tue, 4 Sep 2001 14:46:01 -0700 (PDT) Received: from blood (pool-138-88-75-252.res.east.verizon.net [138.88.75.252]) by aries.ai.net (8.9.3/8.9.3) with SMTP id RAA11869; Tue, 4 Sep 2001 17:52:49 -0400 (EDT) (envelope-from deepak@ai.net) Reply-To: From: "Deepak Jain" To: "freebsd-isp@FreeBSD. ORG" Cc: "freebsd-hackers@FreeBSD. ORG" Subject: Flow cache on FreeBSD? Date: Tue, 4 Sep 2001 17:50:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there a way to provide functionality similar to ip flow cache stats on a FreeBSD router? Let me clarify, I am talking about being able to easily see groupings of traffic go through a FreeBSD box. So if a downstream customer is being attacked, a simple table in realtime [or near real-time] will show the attack characteristics [ip ranges, packet types, general number of packets, etc].? Thanks, Deepak Jain AiNET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 16:25:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mimer.webgiro.com (mailer2.webgiro.com [213.162.131.18]) by hub.freebsd.org (Postfix) with ESMTP id B9AB837B403; Tue, 4 Sep 2001 16:25:43 -0700 (PDT) Received: from webgiro.com (mailer2.webgiro.com [213.162.131.18]) by mimer.webgiro.com (Postfix) with ESMTP id 04D6C68469; Wed, 5 Sep 2001 01:25:38 +0200 (CEST) Message-ID: <3B95623F.B41731F6@webgiro.com> Date: Wed, 05 Sep 2001 01:22:39 +0200 From: Andrzej Bialecki Organization: WebGiro AB X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: deepak@ai.net Cc: "freebsd-isp@FreeBSD. ORG" , "freebsd-hackers@FreeBSD. ORG" Subject: Re: Flow cache on FreeBSD? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Deepak Jain wrote: > > Is there a way to provide functionality similar to ip flow cache stats on a > FreeBSD router? > > Let me clarify, I am talking about being able to easily see groupings of > traffic go through a FreeBSD box. So if a downstream customer is being > attacked, a simple table in realtime [or near real-time] will show the > attack characteristics [ip ranges, packet types, general number of packets, > etc].? Yes. Please go and find the NeTraMet package on the web - it should compile cleanly on FreeBSD (if not the latest versions, then surely some older - I used them some time ago). It's very configurable, and comes with a lot of examples (among others, and XWindow application to watch the flows in real-time). -- Andrzej // ---------------------------------------------------------------- // Andrzej Bialecki , Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // ---------------------------------------------------------------- // FreeBSD developer (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 Sep 4 17: 8:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guru.mired.org (okc-94-248-46.mmcable.com [24.94.248.46]) by hub.freebsd.org (Postfix) with SMTP id C83B437B406 for ; Tue, 4 Sep 2001 17:08:45 -0700 (PDT) Received: (qmail 39510 invoked by uid 100); 5 Sep 2001 00:08:44 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.27916.591039.936494@guru.mired.org> Date: Tue, 4 Sep 2001 19:08:44 -0500 To: Kevin Way Cc: Joseph Mallett , freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. In-Reply-To: <20010904214343.B77906@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kevin Way types: > > If you're really lazy and want to be able to do: > > telnet smtp://localhost > > I suggest you look into this relatively new invention called > > '/etc/services' and read some manual pages. You'll find you can do > > something quite similar, and much saner. > I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost > should do something useful. Nor do I consider his idea "lazy". I do think > that he was suggesting, and I concur, that there's no logical reason that > networked file access should be treated differently by user applications > than local file access. I would concur with that, so long as you remember that "local file access" involves someone making usually-privileged system calls to arrange to map those remote name spaces into the local name space. That is different from making URLs pervasive. For one thing, it doesn't muck with the local name space. If URL's are pervasive and I issue the comand "vi mailto:kevin.way@overtone.org", am I going to edit a file in the local directory called mailto:kevin.way@overtone.org, or am I going to send a mail message to kevin.way@overtone.org? For another, it provides a place to hang information that's global about that mapping - for instance, providing uids and permission bits to handed back from file systems that don't have them. > I strongly suggest you read his post again, and think about how nice it is > for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, > etc and have user-level programs access their data in exactly the same > manner. Those are all file systems, and operations on the things on them all have pretty much the same semantics. This isn't true for URLs in general. It's true for some subset of the available schemes, and I don't think anyone would object to file system modules for ftp or http. You can even do this in userland with an nfs server API if you want it to be portable. However, not all URI schemes have that property. For instance, Mike refers to emacs having "transparent FTP support". It's not really transparent, as opening a local file never asks me for a password! If the ftp server is mounted, then you can provide authentication information as options to the mount. You can even deal with FTP servers that want an ACCT command, which doesn't have a place in the RFC 1738 ftp scheme. I don't know of any application that handles local files that responds to any open error by prompting for a password. If "open" can now return an HTTP 401 error, every application is going to need to be able to deal with that in some sane way. Either that, or users are going to have to know the proper syntax for usernames and passwords in every URL scheme they deal with - and start putting passwords on command lines, and other things that give security officers nightmares. > This is not an LSD-induced 'turn freebsd into windows' idea, it's a very > simple extension of ideas that FreeBSD already has in place. Conceptually, it may be very simple. In practice, it's very, very messy. The correct thing to do with a URL is going to depend on the application that's doing it, what the application is doing, and the scheme for the URL. The application is really the only thing that can figure all that out. In the simplest possible example, "cat" can just treat appropriate URLs like files and read from them. "vi" - or something that vi is talking to - needs to be taught how to deal with streaming data in some way. Sockets are similar in many respects. In a lot of ways, sockets look like file descriptors with some extra functions that can be applied to them. In many cases, all you do with a socket once you've got it is standard file descriptor calls. However, the kernel doesn't let you just "open" a socket. Yes, there are file systems that let you treat a subset of the possible sockets and socket operations that way. But to take full advantage of them, you have to use a different API. In summary, each command needs to decide - possibly on a case-by-case basis whether or not the string it's got is a URL or a file name. It needs to decide how the operation it's been asked to be performed can be performed on the object that URL represents, and if so how it should be mapped. If it's a URL, the application may well have to deal with events that don't happen with local files. All of which is why I think we're already moving in the right direction. We've got a library routine that you can hand a URL to, and it hands back FILE *. We've also got routines that will parse the URL so you can manipulate it, for instance plugging in a new password and user name that the application got from the user in a manner appropriate for that application. For some reason, this all brings to mind the request to make open act like the Perl open..... http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 17:49:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shinatama.hayai.de (tekkno.tv [212.222.165.65]) by hub.freebsd.org (Postfix) with ESMTP id 4ED7037B410 for ; Tue, 4 Sep 2001 17:49:24 -0700 (PDT) Received: (from marco@localhost) by shinatama.hayai.de (8.11.6/8.11.3) id f852ns847839 for freebsd-hackers@freebsd.org; Wed, 5 Sep 2001 02:49:54 GMT (envelope-from marco) Date: Wed, 5 Sep 2001 02:49:54 +0000 From: Marco Wertejuk To: freebsd-hackers@freebsd.org Subject: Re: Flow cache on FreeBSD? Message-ID: <20010905024954.A47654@localhost.com> References: <3B95623F.B41731F6@webgiro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B95623F.B41731F6@webgiro.com>; from abial@webgiro.com on Wed, Sep 05, 2001 at 01:22:39AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, | Yes. Please go and find the NeTraMet package on the web - it should NeTraMet is in the ports so you don't have to search it on the web: /usr/ports/net/NeTraMet/ -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Computer/Internet/Security-Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 17:54: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 0061D37B407 for ; Tue, 4 Sep 2001 17:53:53 -0700 (PDT) Received: from localhost.softweyr.com ([127.0.0.1] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 15eR78-0000G5-00; Tue, 04 Sep 2001 19:04:22 -0600 Message-ID: <3B957A16.6F73C03C@softweyr.com> Date: Tue, 04 Sep 2001 19:04:22 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Leo Bicknell Cc: Ronald G Minnich , Bsdguru@aol.com, hackers@FreeBSD.ORG Subject: Re: Routing Performance? References: <1e.1a94936f.28c52713@aol.com> <20010903203801.A18173@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Leo Bicknell wrote: > > On Mon, Sep 03, 2001 at 06:01:04PM -0600, Ronald G Minnich wrote: > > you do know that API just layed off (almost) all their alpha people, > > right? > > > > alpha is dead. Thank compaq any time. > > > > ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) > > No I didn't. That's really sad. I wonder if the impending Hewlett-Compaqard merger will hasten the Alpha into its grave. The King is Dead, Long Live the King! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 18:42:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by hub.freebsd.org (Postfix) with ESMTP id EB0CE37B40C for ; Tue, 4 Sep 2001 18:42:06 -0700 (PDT) Received: from bean.overtone.org ([24.249.254.100]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010905014206.ILRD4874.femail40.sdc1.sfba.home.com@bean.overtone.org>; Tue, 4 Sep 2001 18:42:06 -0700 Received: by bean.overtone.org (Postfix, from userid 1001) id 529F05B4DB; Wed, 5 Sep 2001 01:41:48 +0000 (GMT) Date: Wed, 5 Sep 2001 01:41:48 +0000 From: Kevin Way To: Mike Meyer Cc: jmallett@newgold.net, freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <20010905014148.A90520@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> <15253.27916.591039.936494@guru.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15253.27916.591039.936494@guru.mired.org>; from mwm@mired.org on Tue, Sep 04, 2001 at 07:08:44PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote: > Kevin Way types: > > I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://local= host > > should do something useful. Nor do I consider his idea "lazy". I do t= hink > > that he was suggesting, and I concur, that there's no logical reason th= at > > networked file access should be treated differently by user applications > > than local file access. >=20 > I would concur with that, so long as you remember that "local file > access" involves someone making usually-privileged system calls to > arrange to map those remote name spaces into the local name > space. That is different from making URLs pervasive. Agreed. You'll notice I agreed with Michael Sinz's post, not the pro-URL posts. I like the idea of being able to say... mount -t http http://www.freebsd.org/ /www/freebsd cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html even a simple example like 'cat http://www.freebsd.org/' seems nice, but it raises as more questions than it answers. Obviously protocols which are not file oriented won't translate effectively into filesystems. mailto is an excellent example of a scheme that doesn't translate effectively into a filesystem translation layer. I'd have no idea what to do with a mailto url, or how to reference it as a filesystem. Combine the above filesystem concept with something like amd, and many activities become extremely convenient. > > I strongly suggest you read his post again, and think about how nice it= is > > for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, S= MBFS, > > etc and have user-level programs access their data in exactly the same= =20 > > manner. >=20 > Those are all file systems, and operations on the things on them all > have pretty much the same semantics. This isn't true for URLs in > general. Agreed. > It's true for some subset of the available schemes, and don't think anyone > would object to file system modules for ftp or http.=20 this is what the post I agred with was suggesting. this is what i believe would be a good idea. > You can even do this in userland with an nfs server API if you > want it to be portable. Novel idea. I'll file it into the maybe pile. > I don't know of any application that handles local files that responds > to any open error by prompting for a password. If "open" can now > return an HTTP 401 error, every application is going to need to be > able to deal with that in some sane way. Either that, or users are > going to have to know the proper syntax for usernames and passwords in > every URL scheme they deal with - and start putting passwords on > command lines, and other things that give security officers > nightmares. I would imagine that an http filesystem layer would return EACCES for a 401, as that would probably cause any program to return a sane error to the user. > > This is not an LSD-induced 'turn freebsd into windows' idea, it's a very > > simple extension of ideas that FreeBSD already has in place. >=20 > Conceptually, it may be very simple. In practice, it's very, very > messy. The correct thing to do with a URL is going to depend on the > application that's doing it, what the application is doing, and the > scheme for the URL. The application is really the only thing that can > figure all that out. In the simplest possible example, "cat" can just > treat appropriate URLs like files and read from them. "vi" - or > something that vi is talking to - needs to be taught how to deal with > streaming data in some way. Yes, unfortunately all ideas are just a Simple Matter of Programming... One miscommunication I should apologize for, I'm not suggesting the URLification of FreeBSD. I'm suggesting that it would be a Good Thing if files available via any common networked file transfer protocol were able to be accessed via standard system calls. > In summary, each command needs to decide - possibly on a case-by-case > basis whether or not the string it's got is a URL or a file name. It > needs to decide how the operation it's been asked to be performed can > be performed on the object that URL represents, and if so how it > should be mapped. If it's a URL, the application may well have to deal > with events that don't happen with local files. I really don't want all that in every command. I want it in a filesystem layer, where appropriate, as described above. Anyway, in conclusion it would seem to me that we agree, but there was a misunderstanding because I did a poor job of clipping relevant text to show what it was I was agreeing with. I apologize for the miscommunication. Kevin Way --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7lYLcKxA01iDoLN4RAuOxAJ9+wpgwEehffmerYbTvLiAQFW6cJgCeNPhb 8CJU/ChnSb1v4keIyI9vMGY= =dBhp -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 18:48: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from blueyonder.co.uk (pcow035o.blueyonder.co.uk [195.188.53.121]) by hub.freebsd.org (Postfix) with ESMTP id 23E9137B406 for ; Tue, 4 Sep 2001 18:48:01 -0700 (PDT) Received: from mail.yahoo.com ([62.30.72.42]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 5 Sep 2001 00:38:30 +0100 Received: (from steve@localhost) by mail.yahoo.com (8.11.3/8.11.3) id f84Nc2B00679; Wed, 5 Sep 2001 00:38:02 +0100 (BST) (envelope-from steve) Date: Wed, 5 Sep 2001 00:38:02 +0100 From: Steve Roome To: Niek Bergboer Cc: freebsd-hackers@freebsd.org Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? Message-ID: <20010905003802.A571@dylan.home> Mail-Followup-To: Steve Roome , Niek Bergboer , freebsd-hackers@freebsd.org References: <20010904192030.A2347@wit379119.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010904192030.A2347@wit379119.student.utwente.nl>; from niek@bergboer.net on Tue, Sep 04, 2001 at 07:20:30PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 04, 2001 at 07:20:30PM +0200, Niek Bergboer wrote: > Can these newer drives, based on the IC-35L0?0-chipset, also be used > with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the > drive has 20, 40 or 60 GB capacity). I've got one of these : ad0: 39266MB [79780/16/63] at ata0-master UDMA66 If I turn tagged queueing on, I get an awful lot of write failures and ata timeouts and whatnot. Basically it just doesn't work. **For me** I'm not blaming Søren Schmidt here! it could be due to broken hardware, code or just my sheer incompetence, but in the end I gave up trying, it didn't work with my last drive either, and that was a 30GP type drive (don't remember the model number though). As far as I remember there are apparently problems with some of these drives in terms of whether they even work when they leave the factory, but I've only ever heard that here (make what you want of that). Good luck, YMMV I think I might have made a local patch to include my drive.. something like this... /usr/src/sys/dev/ata/ata-disk.c around line 861 const char *drives[] = {"IBM-DPTA", "IBM-DTLA", "IC35L040AVER07", NULL}; As I said, it didn't work though =( Steve P.S. let me know if you suceed in getting it to work, maybe I need a different motherboard or just to change some settings or something? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 21:12:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 9C85A37B406 for ; Tue, 4 Sep 2001 21:12:44 -0700 (PDT) Received: (qmail 8107 invoked by uid 1000); 5 Sep 2001 04:12:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Sep 2001 04:12:43 -0000 Date: Tue, 4 Sep 2001 23:12:43 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: "Vladimir A. Jakovenko" , , Subject: Re: SO_REUSEPORT on unicast UDP sockets In-Reply-To: <3B947922.F8B98DBD@mindspring.com> Message-ID: <20010904231049.E7815-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 3 Sep 2001, Terry Lambert wrote: > Similarly, there are a number of bugs in the TCP sockets as > well; specifically, there's a problem with all sockets being > treated as being in the same collision domain, when doing > automatic port assignment. This limits you to 65535 oubound > TCP connections, even though you have multiple IP aliases on > an interface (theoretically, you should get 64k connections > per IP address, if you bind _not_ to IN_ADDR_ANY, but instead > use a specific port, but the hash is broken). I like this problem's evil sibling: client side TIME_WAITs. If you build them up, you just sit there unable to allocate outgoing ports until they time out. Maybe net or openbsd handle these situations better, I'll have to check later. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 23:11:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D30137B407; Tue, 4 Sep 2001 23:11:41 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f856BdX22157; Wed, 5 Sep 2001 00:11: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.11.3/8.11.4) with ESMTP id f856BYh41835; Wed, 5 Sep 2001 00:11:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109050611.f856BYh41835@harmony.village.org> To: tlambert2@mindspring.com Subject: Re: FreeBSD and Athlon Processors Cc: obrien@FreeBSD.ORG, Charles Shannon Hendrix , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 04 Sep 2001 00:22:49 PDT." <3B948149.1FE08591@mindspring.com> References: <3B948149.1FE08591@mindspring.com> <200109010033.f810XaT08748@saturn.cs.uml.edu> <20010902001113.B27595@widomaker.com> <20010902102548.C64910@dragon.nuxi.com> Date: Wed, 05 Sep 2001 00:11:33 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3B948149.1FE08591@mindspring.com> Terry Lambert writes: : Are you sure it's not just a CMD640 IDE controller? They are : known to have issues; Linux has a patch... FreeBSD used to, but : I think it got yanked out, or was just turned off by default. The CMD640 had many DMA corruption bugs. Many are fixed with the Linux patch, but data corruption issues remain. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 4 23:14: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1828537B409 for ; Tue, 4 Sep 2001 23:13:57 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f856DtX22171; Wed, 5 Sep 2001 00:13:55 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f856Dsh41869; Wed, 5 Sep 2001 00:13:55 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109050613.f856Dsh41869@harmony.village.org> To: "Eugene L. Vorokov" Subject: Re: KLD subsystem improvement Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 04 Sep 2001 19:03:32 +0400." <200109041503.f84F3WS57075@bugz.infotecs.ru> References: <200109041503.f84F3WS57075@bugz.infotecs.ru> Date: Wed, 05 Sep 2001 00:13:54 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200109041503.f84F3WS57075@bugz.infotecs.ru> "Eugene L. Vorokov" writes: : I'm going to implement a small improvement to a KLD system. I want linker : file not to be loaded at all when all modules inside it fail to load for : some reasons. I think that would be logical behaviour. Does anyone think : that such change would break something ? kldload if_ed.ko Would break. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:24:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 6ABDF37B401 for ; Wed, 5 Sep 2001 00:24:27 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA11257; Wed, 5 Sep 2001 00:24:22 -0700 (PDT) Message-ID: <3B95D353.8E8D1C42@mindspring.com> Date: Wed, 05 Sep 2001 00:25:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Roome Cc: Niek Bergboer , freebsd-hackers@freebsd.org Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? References: <20010904192030.A2347@wit379119.student.utwente.nl> <20010905003802.A571@dylan.home> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Steve Roome wrote: > > Can these newer drives, based on the IC-35L0?0-chipset, also be used > > with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the > > drive has 20, 40 or 60 GB capacity). > = > I've got one of these : > = > ad0: 39266MB [79780/16/63] at ata0-master UDMA66 > = > If I turn tagged queueing on, I get an awful lot of write failures and > ata timeouts and whatnot. Basically it just doesn't work. **For me** > = > I'm not blaming S=F8ren Schmidt here! it could be due to broken > hardware, code or just my sheer incompetence, but in the end I gave up > trying, it didn't work with my last drive either, and that was a 30GP > type drive (don't remember the model number though). > = > As far as I remember there are apparently problems with some of these > drives in terms of whether they even work when they leave the factory, > but I've only ever heard that here (make what you want of that). Search for "tagged command queueing" and "DLTA" and "IBM"; you will be rewarded with many horror storries about the drive electronics not being able to keep up on these drives, when writing near the spindle. This normally doesn't happen until the disk is almost full, with Windows FS's, which will usually place your machine "safely" out of warranty. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:43:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id C013437B40E for ; Wed, 5 Sep 2001 00:43:03 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA11067; Wed, 5 Sep 2001 00:42:58 -0700 (PDT) Message-ID: <3B95D7AE.22C12A17@mindspring.com> Date: Wed, 05 Sep 2001 00:43:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <3B946708.ECB7307B@mindspring.com> <15253.6194.432852.114923@nomad.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > TRW supported a lot of the early > > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw > > in and had us change the version number from 0.1 to 1.0 to > > make it a bit easier to sell. > > *Huh* That's revisionist history if I've ever heard it. We > did a 1.0 release for FreeBSD because we wanted to differentiate > ourselves from 386BSD (lot of bad blood there with the Jolitz's) > and NetBSD (which had a 0.8 release at that time). FWIW: This is all archived on Minnie, thanks to Warren Toomey. I believe that Julian was the first corporately employed person, who had at least part of his paid job as working on the 386BSD/FreeBSD code. Bill Jolitz approved a 0.5 "interim release" of 386BSD, as his recent family troubles and recent contract with Sun precluded him getting the promised 1.0 release out any time soon. Some of the people who later split off NetBSD and released the NetBSD 0.8 release had reverse engineered the patchkit format, and built tools to do the same thing. Not understanding the fact that the patchkit was in fact a simple, single user revision control system that I had hacked together, they released patches of their own, starting at #1000. This resulted in problems with serialization, and, I believe, was one of the main factors in their going off on their own. Progress was made on the 386BSD 0.5 release under the auspices of the patchkit maintainers, who had their position of control because I did not distribute the patchkit patch making shell scripts very widely, in order to ensure serialization, so that the patches, when applied, would work, have proper dependency tracking, and not result in conflicts. There was an angry posting on Usenet by Lynne Jolitz; in it, she claimed that 1/3 of the patchkit was good, 1/3 was benign (but unnecessary), and 1/3 was crap. Then she would not say which 1/3 was which; this pissed off more people than the original claim that only 1/3 of the code was any good. After much sniping back and forth, Bill Jolitz posted, and revoked his previous permission to use the 386BSD name (a common law trademark belonging to him), and therefore he had effectively scuttled the interim release under the 386BSD name. Unwilling to throw away many months of work, it was decided to go forward with the release, under the name FreeBSD 0.1. Walnut Creek CDROM suggested that the version number be changed to "1.0", in order to make it an easier sell on CDROM. Check with Warren, if you don't believe this account. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:54:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D6BF37B403 for ; Wed, 5 Sep 2001 00:54:47 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id BAA07990; Wed, 5 Sep 2001 01:54:25 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id BAA13433; Wed, 5 Sep 2001 01:54:25 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.55856.528797.176984@nomad.yogotech.com> Date: Wed, 5 Sep 2001 01:54:24 -0600 To: tlambert2@mindspring.com Cc: Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: <3B95D7AE.22C12A17@mindspring.com> References: <3B946708.ECB7307B@mindspring.com> <15253.6194.432852.114923@nomad.yogotech.com> <3B95D7AE.22C12A17@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > TRW supported a lot of the early > > > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw > > > in and had us change the version number from 0.1 to 1.0 to > > > make it a bit easier to sell. > > > > *Huh* That's revisionist history if I've ever heard it. We > > did a 1.0 release for FreeBSD because we wanted to differentiate > > ourselves from 386BSD (lot of bad blood there with the Jolitz's) > > and NetBSD (which had a 0.8 release at that time). > > FWIW: This is all archived on Minnie, thanks to Warren Toomey. Sure, and I've got archives of it as well. > I believe that Julian was the first corporately employed > person, who had at least part of his paid job as working on > the 386BSD/FreeBSD code. Yes, and the original SCSI system was Julian's, which was later replaced by CAM. > Bill Jolitz approved a 0.5 "interim release" of 386BSD And then Lynn revoked this, and posted a public message to the world stating what obnoxious fiends we were. As the person who spoke with both Bill and Lynn getting their approval (Jordan did as well), I'm *very* familiar with the process. > Some of the people who later split off NetBSD and released the > NetBSD 0.8 release had reverse engineered the patchkit format, > and built tools to do the same thing. Actually, no. It was the person who was going to take it from me (I could name him, but it wouldn't do much good). The new maintainer didn't do anything or respond to email for over 3 months, so Jordan took it over from where I left off. NetBSD was Chris Demetriou's child after he got fed up with Bill's promises never coming true. I was the third committer on what would later become the NetBSD development box, but I still naively assumed that Bill's promises would eventually come to fruition. NetBSD happened when Lynn's famous email was sent out claiming we were all evil incarnate, and that no-one understood them anymore. Soon afterward NetBSD 0.8 was released, but Adam Glass (the owner of the second account on the NetBSD development box) was a big 68K fan, so his influence (as well as Chris's) made NetBSD into a cross-platform OS. > Progress was made on the 386BSD 0.5 release under the auspices > of the patchkit maintainers, who had their position of control > because I did not distribute the patchkit patch making shell > scripts very widely, in order to ensure serialization, so that > the patches, when applied, would work, have proper dependency > tracking, and not result in conflicts. Actually, all of the patchkit maintainers (myself, Jordan, and Rod) had access to your shell software. However, it turned out that avoiding conflicts was hard, because serialization often required patches upon patches upon patches upon patches, and at some point, the creation/maintenance of the patchkit was greater than building a new release. (Plus the fact that you couldn't install the patches w/out a running system, and the running system couldn't be installed on certain hardware w/out patches, causing a catch-22). > There was an angry posting on Usenet by Lynne Jolitz; in it, > she claimed that 1/3 of the patchkit was good, 1/3 was benign > (but unnecessary), and 1/3 was crap. Then she would not say > which 1/3 was which; this pissed off more people than the > original claim that only 1/3 of the code was any good. > > After much sniping back and forth, Bill Jolitz posted, and > revoked his previous permission to use the 386BSD name (a > common law trademark belonging to him), and therefore he had > effectively scuttled the interim release under the 386BSD > name. Close, but the original posting was by Bill, and the revokation was done by Lynn. > Unwilling to throw away many months of work, it was decided to > go forward with the release, under the name FreeBSD 0.1. > > Walnut Creek CDROM suggested that the version number be changed > to "1.0", in order to make it an easier sell on CDROM. > > Check with Warren, if you don't believe this account. I was involved with the entire affair, and Warren's archive doesn't include much of what later became 'core' email. Also, it doesn't include the phone conversations with Bill and Lynn, which (obviously) aren't in the public domain. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:56: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 1E89037B407 for ; Wed, 5 Sep 2001 00:56:01 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA29701; Wed, 5 Sep 2001 00:55:48 -0700 (PDT) Message-ID: <3B95DAB1.67861BCF@mindspring.com> Date: Wed, 05 Sep 2001 00:56:33 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <79373.999627125@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Nate, > > You're replying to Terry for christs sake! What did you expect if not > revisionist $anything ? > > Which reminds me, Adrian still oves us his story about ref :-) Poul, you're going off again, without regard for facts. Remember the last time FreeBSD history came up, I proved Nate mistaken in his claim that my authorship of the original 386BSD FAQ was "revisionist history". You can check these facts out in the archives on Minnie; I can also provide almost every email I ever sent or received (if it resulted in a response from me to the author), from 1988 forward, since I have it all archived, since even at the time, I felt it might end up being an important historical record. At the very least, it has provided me with a rich source of information from which to draw, in order to study "Open Source" projects in general, and 386BSD, FreeBSD, and NetBSD, in particular. I am only willing to open up the non-private email sent or received, and then only with considerable incentive (it is a very large archive). Alternately, you can go to Warren's archive and look there, before making accusations of revisionism. However, if you insist, I can and will happily quote large sections of it to this mailing list, in support of any contended claims of inaccuracy... Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:56:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 9867B37B401 for ; Wed, 5 Sep 2001 00:56:10 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f857uQM18767; Wed, 5 Sep 2001 09:56:26 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200109050756.f857uQM18767@freebsd.dk> Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? In-Reply-To: <20010905003802.A571@dylan.home> "from Steve Roome at Sep 5, 2001 00:38:02 am" To: Steve Roome Date: Wed, 5 Sep 2001 09:56:26 +0200 (CEST) Cc: Niek Bergboer , freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Steve Roome wrote: > On Tue, Sep 04, 2001 at 07:20:30PM +0200, Niek Bergboer wrote: > > Can these newer drives, based on the IC-35L0?0-chipset, also be used > > with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the > > drive has 20, 40 or 60 GB capacity). Yes, and support has been committed to both -current & -stable. > I've got one of these : > > ad0: 39266MB [79780/16/63] at ata0-master UDMA66 > > If I turn tagged queueing on, I get an awful lot of write failures and > ata timeouts and whatnot. Basically it just doesn't work. **For me** > > I'm not blaming Søren Schmidt here! it could be due to broken > hardware, code or just my sheer incompetence, but in the end I gave up > trying, it didn't work with my last drive either, and that was a 30GP > type drive (don't remember the model number though). > > As far as I remember there are apparently problems with some of these > drives in terms of whether they even work when they leave the factory, > but I've only ever heard that here (make what you want of that). Well, thanks :) Anyhow, the problem at hand is more like bad chipsets, there is ALOT of ATA chipsets thats not working right when used the way needed for tagged queuing. That said, the IBM DTLA's series of drives are extremely picky about power (that makes them unusable in at least California right :)) which I've seen cause trouble on highly loaded machines. However I run 4 of them here locally with tags, and they get about as much beating as they can handle, not a single error yet, so it definitly works, you just need the right environment for them. So what chipset does you machine have ? that could very well be the problem here. -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 0:58:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 1F0DD37B403 for ; Wed, 5 Sep 2001 00:58:35 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id BAA08160; Wed, 5 Sep 2001 01:58:13 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id BAA13473; Wed, 5 Sep 2001 01:58:12 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.56084.135671.531364@nomad.yogotech.com> Date: Wed, 5 Sep 2001 01:58:12 -0600 To: tlambert2@mindspring.com Cc: Poul-Henning Kamp , Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: <3B95DAB1.67861BCF@mindspring.com> References: <79373.999627125@critter> <3B95DAB1.67861BCF@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > You're replying to Terry for christs sake! What did you expect if not > > revisionist $anything ? > > > > Which reminds me, Adrian still oves us his story about ref :-) > > Poul, you're going off again, without regard for facts. > > Remember the last time FreeBSD history came up, I proved Nate > mistaken in his claim that my authorship of the original 386BSD > FAQ was "revisionist history". No you didn't. You changed the questions. :) > You can check these facts out in the archives on Minnie; I can > also provide almost every email I ever sent or received (if it > resulted in a response from me to the author), from 1988 forward, > since I have it all archived, since even at the time, I felt it > might end up being an important historical record. At the very > least, it has provided me with a rich source of information from > which to draw, in order to study "Open Source" projects in general, > and 386BSD, FreeBSD, and NetBSD, in particular. You're not the only pack-rat around here. Be careful of your claims, since they could come back to bite you. Nate ps. I still have my phone-logs of my conversations with Bill as well. ;) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 1:20:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tarakan-network.com (chojin.adsl.nerim.net [62.4.22.98]) by hub.freebsd.org (Postfix) with ESMTP id D797F37B405; Wed, 5 Sep 2001 01:20:40 -0700 (PDT) Received: from chojin (Cho@chojin.lan.tarakan-network.com [192.168.69.2] (may be forged)) by tarakan-network.com (8.11.6/8.11.3) with SMTP id f858KTj92538; Wed, 5 Sep 2001 10:20:29 +0200 (CEST) (envelope-from freebsd@tarakan-network.com) Message-ID: <010401c135e3$ac9886d0$0245a8c0@chojin> From: "Chojin" To: "Fernando Gleiser" Cc: , References: <20010904164621.N29260-100000@cactus.fi.uba.ar> Subject: Re: ipnat, ipf, ipfstat devices not configured Date: Wed, 5 Sep 2001 10:20:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, #dmesg | grep IP plip0: on ppbus0 IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled IP Filter: already initialized IP Filter: v3.4.16 unloaded module_register_init: MOD_LOAD (IP Filter: v3.4.16, c0388278, 0) error 16 It seems there is an error in the module. I'll test with generic when I'll have time :o) ----- Original Message ----- From: "Fernando Gleiser" To: "Chojin" Cc: Sent: Tuesday, September 04, 2001 9:51 PM Subject: Re: ipnat, ipf, ipfstat devices not configured > On Tue, 4 Sep 2001, Chojin wrote: > > > Hello, > > > > Since I recompiled my system and kernel (4.3-RELEASE) I can't use ipnat ipf > > and ipfstat: > > > > #ipnat > > /dev/ipnat: open: Device not configured > > > > #ipf -Fa -f /etc/ipf.rules > > open device: Device not configured > > ioctl(SIOCIPFFL): Bad file descriptor > > open device: Device not configured > > 2:ioctl(add/insert rule): Bad file descriptor > > 3:ioctl(add/insert rule): Bad file descriptor > > It seems you don't have IP Filter support in your kernel. The kernel options > are fine, maybe you recompiled the kernel but forgot to install it. > > Do a 'dmesg | grep IP', a line like this should apear: > > IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled > > Try booting GENERIC and kldload ipl, to load IP Filter as a module. > I load ipf as a module, to keep it up to date with Darren's fixes. The upgrade > is easier. > > > Hope This helps. > > > Fer > > > > > > #ipfstat > > open: Device not configured > > > > I did all things needed as MAKEDEV all (done by mergemaster). > > > > There are all options unchanged in my kernel configuration file: > > options IPFILTER #ipfilter support > > options IPFILTER_LOG #ipfilter logging > > options IPFIREWALL > > options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options IPDIVERT > > > > I don't understand why there is this problem. > > Anyone could help me ? > > > > Chojin > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" 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 Sep 5 1:23:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tarakan-network.com (chojin.adsl.nerim.net [62.4.22.98]) by hub.freebsd.org (Postfix) with ESMTP id 586E937B406; Wed, 5 Sep 2001 01:23:41 -0700 (PDT) Received: from chojin (Cho@chojin.lan.tarakan-network.com [192.168.69.2] (may be forged)) by tarakan-network.com (8.11.6/8.11.3) with SMTP id f858Nej92835; Wed, 5 Sep 2001 10:23:41 +0200 (CEST) (envelope-from freebsd@tarakan-network.com) Message-ID: <010e01c135e4$1ea267a0$0245a8c0@chojin> From: "Chojin" To: , References: <200109041949.f84JnJs36681@freefall.freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser Date: Wed, 5 Sep 2001 10:23:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2526.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG When I apply the patch : [ /usr/src/usr.sbin/adduser]$patch -p < /home/chojin/patch/rmuser.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: rmuser.perl |=================================================================== |RCS file: /usr2/ncvs/src/usr.sbin/adduser/rmuser.perl,v |retrieving revision 1.8.2.4 |retrieving revision 1.8.2.5 |diff -u -r1.8.2.4 -r1.8.2.5 |--- rmuser.perl 2001/05/25 15:05:00 1.8.2.4 |+++ rmuser.perl 2001/07/28 12:10:15 1.8.2.5 -------------------------- Patching file rmuser.perl using Plan A... Hunk #1 failed at 42. Hunk #2 failed at 311. Hunk #3 failed at 340. Hunk #4 failed at 350. 4 out of 4 hunks failed--saving rejects to rmuser.perl.rej done ----- Original Message ----- From: "FreeBSD Security Advisories" To: "FreeBSD Security Advisories" Sent: Tuesday, September 04, 2001 9:49 PM Subject: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser > -----BEGIN PGP SIGNED MESSAGE----- > > ============================================================================ = > FreeBSD-SA-01:59 Security Advisory > FreeBSD, Inc. > > Topic: rmuser contains a race condition exposing /etc/master.passwd > > Category: core > Module: rmuser > Announced: 2001-09-04 > Credits: dynamo@harvard.net > Affects: FreeBSD 4.2-RELEASE, 4.3-RELEASE > FreeBSD 4.3-STABLE prior to the correction date. > Corrected: 2001-07-28 12:10:15 UTC (4.3-STABLE) > 2001-09-04 07:46:57 UTC (RELENG_4_3) > FreeBSD only: Yes > > I. Background > > rmuser is a perl script used to completely remove users from a system. > > II. Problem Description > > When removing a user from the system with the rmuser utility, the > /etc/master.passwd file and it's corresponding database /etc/spwd.db > must be updated. The rmuser script was incorrectly doing this by > creating a new master.passwd file with an unsafe umask and then using > chmod to set its permissions to 0600. Between the time that the file > was created and the time that its permissions were changed the file is > world-readable. > > This is only a minor security vulnerability since the rmuser command > is only used infrequently on most systems, and the attack is highly > timing-dependent. > > All versions of FreeBSD prior to the correction date including FreeBSD > 4.3 contain this problem. The base system that will ship with FreeBSD > 4.4 does not contain this problem since it was corrected prior to the > release. > > III. Impact > > For a brief amount of time while running rmuser, a world-readable copy > of /etc/master.passwd is available. A local attacker who reads this > file can extract password hashes from the copy of /etc/master.passwd. > This information could be used by attackers to escalate their > privileges, possibly yielding root privileges on the local system, by > mounting an offline dictionary attack in order to guess the plaintext > passwords of the accounts on the local system. > > IV. Workaround > > Use the pw(8) utility to remove users instead of rmuser. > > - "pw userdel " will only remove the user from > /etc/passwd, /etc/master.passwd and /etc/group > - "pw -r userdel " will also remove the user's home > dirrectory > > V. Solution > > 1) Upgrade your vulnerable system to 4.3-STABLE or the RELENG_4_3 > security branch, dated after the respective correction dates. > > 2) To patch your present system: download the relevant patch from the > below location, and execute the following commands as root: > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:59/rmuser.patch > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:59/rmuser.patch.asc > > Verify the detached PGP signature using your PGP utility. > > This patch has been verified to apply to FreeBSD 4.2-RELEASE and > 4.3-RELEASE. It may or may not apply to older, unsupported releases > of FreeBSD. > > # cd /usr/src/usr.sbin/adduser > # patch -p < /path/to/patch > # make depend && make all install > > 3) FreeBSD 4.3-RELEASE systems: > > An experimental upgrade package is available for users who wish to > provide testing and feedback on the binary upgrade process. This > package may be installed on FreeBSD 4.3-RELEASE systems only, and is > intended for use on systems for which source patching is not practical > or convenient. > > If you use the upgrade package, feedback (positive or negative) to > security-officer@FreeBSD.org is requested so we can improve the > process for future advisories. > > During the installation procedure, backup copies are made of the files > which are replaced by the package. These backup copies will be > reinstalled if the package is removed, reverting the system to a > pre-patched state. > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:59/security-patch-rmus er-01.59.tgz > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:59/security-patch-rmus er-01.59.tgz.asc > > Verify the detached PGP signature using your PGP utility. > > # pkg_add security-patch-rmuser-01.59.tgz > > VI. CVS Revisions > > The following $FreeBSD$ CVS revision contain the fixes for this > vulnerability. The $FreeBSD$ revision of installed sources can be > examined using the ident(1) command. These revision IDs are not > updated by applying the patch referenced above. > > [FreeBSD 4.3-STABLE] > > Revision Path > 1.8.2.5 src/usr.sbin/rmuser.perl > > [RELENG_4_3] > > Revision Path > 1.8.2.2.2.1 src/usr.sbin/rmuser.perl > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iQCVAwUBO5SH1lUuHi5z0oilAQEWLAQAniPWZpgjNvhoT6ECltW4G9lKlsswDur9 > WMKkX2KEvZ9pswx3rqkn1IC+kBTfgdwwhU/54dyx1HKb2XJH5QdGpW/H/niTox4z > ImJjctZNvnEuB52si1+Ivx3avwgw57YjAsJgLcv+CYYW+iizX1zVFBjdce6PDQgI > pb50qM0sJYA= > =hxQ5 > -----END PGP SIGNATURE----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" 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 Sep 5 1:34:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from faerie.gib.ru (faerie.gib.ru [212.13.111.11]) by hub.freebsd.org (Postfix) with ESMTP id DEA5737B403 for ; Wed, 5 Sep 2001 01:34:50 -0700 (PDT) Received: by faerie.gib.ru (Postfix, from userid 1024) id C4D7D8D62; Wed, 5 Sep 2001 12:34:48 +0400 (MSD) From: s To: freebsd-hackers@freebsd.org Subject: IICBUS_READ Message-Id: <20010905083448.C4D7D8D62@faerie.gib.ru> Date: Wed, 5 Sep 2001 12:34:48 +0400 (MSD) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've look at /sys/dev/iicbus/iiconf.c: > int > iicbus_read(device_t bus, char *buf, int len, int *read, int last, int delay) > { > struct iicbus_softc *sc = (struct iicbus_softc *)device_get_softc(bus); > > /* a slave must have been started with the appropriate address */ > if (!sc->started || !(sc->started & LSB)) > return (EINVAL); > > return (IICBUS_READ(device_get_parent(bus), buf, len, read, last, delay)); > } Where is defined IICBUS_READ ? Seva. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 1:45:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.68.253]) by hub.freebsd.org (Postfix) with ESMTP id BB1D737B405 for ; Wed, 5 Sep 2001 01:45:44 -0700 (PDT) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id RAA25984 for ; Wed, 5 Sep 2001 17:44:17 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200109050844.RAA25984@shidahara1.planet.sci.kobe-u.ac.jp> To: hackers@freebsd.org Subject: Re: IICBUS_READ In-reply-to: Your message of "Wed, 05 Sep 2001 12:34:48 +0400." <20010905083448.C4D7D8D62@faerie.gib.ru> Date: Wed, 05 Sep 2001 17:44:17 +0900 From: Takanori Watanabe Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010905083448.C4D7D8D62@faerie.gib.ru>, s $B$5$s$$$o$/(B: > > >I've look at /sys/dev/iicbus/iiconf.c: > >> int >> iicbus_read(device_t bus, char *buf, int len, int *read, int last, int delay >) >> { >> struct iicbus_softc *sc = (struct iicbus_softc *)device_get_softc(bus); >> >> /* a slave must have been started with the appropriate address */ >> if (!sc->started || !(sc->started & LSB)) >> return (EINVAL); >> >> return (IICBUS_READ(device_get_parent(bus), buf, len, read, last, de >lay)); >> } > >Where is defined IICBUS_READ ? /sys/${MACHINE}/compile/${YOURCONF}/iicbus_if.h This is generated from /sys/dev/iicbus/iicbus_if.m . Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 1:47: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id AFF1137B403 for ; Wed, 5 Sep 2001 01:46:56 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA21115; Wed, 5 Sep 2001 01:46:41 -0700 (PDT) Message-ID: <3B95E69D.5E3BE11D@mindspring.com> Date: Wed, 05 Sep 2001 01:47:25 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <3B946708.ECB7307B@mindspring.com> <15253.6194.432852.114923@nomad.yogotech.com> <3B95D7AE.22C12A17@mindspring.com> <15253.55856.528797.176984@nomad.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > Bill Jolitz approved a 0.5 "interim release" of 386BSD > > And then Lynn revoked this, and posted a public message to the world > stating what obnoxious fiends we were. Actually, Lynne didn't have the right to do this; the trademark was Bill's, so the revocation wasn't valid until Bill did it. > > Some of the people who later split off NetBSD and released the > > NetBSD 0.8 release had reverse engineered the patchkit format, > > and built tools to do the same thing. > > Actually, no. It was the person who was going to take it from me (I > could name him, but it wouldn't do much good). The new maintainer > didn't do anything or respond to email for over 3 months, so Jordan took > it over from where I left off. I was aware that CGD had reverse engineered it. I wasn't aware that you had given the tools to the people who later released the "1000" level patches. > NetBSD was Chris Demetriou's child after he got fed up with Bill's > promises never coming true. I was the third committer on what would > later become the NetBSD development box, but I still naively assumed > that Bill's promises would eventually come to fruition. All of us pretty much assumed that, at the time. 8-(. > NetBSD happened when Lynn's famous email was sent out claiming we were > all evil incarnate, and that no-one understood them anymore. I talked to Lynne and Bill through much of that time; it was (unfortunately) a discussion well before the fireworks that resulted in him knowing about common law trademarks. I was still on good terms with them, well after the NetBSD 0.8 release, and we mostly "just lost touch", rather than letting the bickering come between us. One thing that was not commonly known at the time, though I guess most people know it now, is that they had had a financial setback, followed by a death in the family, and really weren't in any condition to be doing anything but picking up the pieces; the whole incident was really unfortunate. > Actually, all of the patchkit maintainers (myself, Jordan, and Rod) had > access to your shell software. However, it turned out that avoiding > conflicts was hard, because serialization often required patches upon > patches upon patches upon patches, and at some point, the > creation/maintenance of the patchkit was greater than building a new > release. (Plus the fact that you couldn't install the patches w/out a > running system, and the running system couldn't be installed on certain > hardware w/out patches, causing a catch-22). Yes. It was effectively a single author thing. I always used it by manually applying the patches and resolving any conflicts by hand, and then running a diff between the base tree and the target tree. I never really claimed it as anything other than a vehicle for distributing patches (it sure as heck was no CVS!). As for the binaries, we had a number of patched floppy images floating around (I personally couldn't boot the thing at all until I binary edited the floppy to look for 639 instead of 640 in the CMOS base memory data registers). > Close, but the original posting was by Bill, and the revokation was done > by Lynn. I remember it the other way, but would have to go to tape on it to know for sure... 8-). Originally, Lynne recommended the patchkit and FAQ -- here's an excerpt of a usenet posting of hers from 28 January 1993: | You can get a copy of 386BSD from agate.berkeley.edu (and it's mirror | sites) via anonymous ftp. It is also available on CDROM from Austin | Code Works (info@acw.com) [Note -- this is unpatched 0.1 -- you should | get the patchkit in /unofficial on agate, and also the FAQ]. > I was involved with the entire affair, and Warren's archive doesn't > include much of what later became 'core' email. Unfortunately, I cut myself out of the loop early on that, due to the impending purchase of USL by Novell, which went through in June of 1994, after off shore locations which were not Berne Convention signatories had been found to house the code in case the worst happened, so this email is not part of my personal archives. I hope someone, somewhere has saved it for posterity... > Also, it doesn't include the phone conversations with Bill and > Lynn, which (obviously) aren't in the public domain. Nor mine. Actually, in California, Utah, and Montanna, and now many more states, so long as one party to the conversation is the one doing the recording, you don't even have to have the periodic "beep" to indicate a recording... even back then. But I never even considered recording my calls, and I rather doubt that anyone else had the foresight to do it, either. It's annoying in retrospect, because I had the equipment for doing passive monitoring without violating the phone company rules on connecting equipment to their wires. 20/20 hindsight... 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 1:50:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 88F4937B407 for ; Wed, 5 Sep 2001 01:50:56 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA27024; Wed, 5 Sep 2001 01:50:49 -0700 (PDT) Message-ID: <3B95E796.9F63665B@mindspring.com> Date: Wed, 05 Sep 2001 01:51:34 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Poul-Henning Kamp , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <79373.999627125@critter> <3B95DAB1.67861BCF@mindspring.com> <15253.56084.135671.531364@nomad.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > You're not the only pack-rat around here. Be careful of your claims, > since they could come back to bite you. I'm willing to be bitten in public, if I'm wrong... always have been. ;-). > ps. I still have my phone-logs of my conversations with Bill as well. ;) Now I'm jealous... I have some yellow legal pads with notes on them, and two of the archives of the "grand unified console driver" online discussions (what a boondoggle that turned out\ to be!), but no real phone logs. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 1:52: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 2828E37B405 for ; Wed, 5 Sep 2001 01:51:45 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id CAA10454; Wed, 5 Sep 2001 02:51:38 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id CAA13811; Wed, 5 Sep 2001 02:51:37 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.59289.67264.667368@nomad.yogotech.com> Date: Wed, 5 Sep 2001 02:51:37 -0600 To: tlambert2@mindspring.com Cc: Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: <3B95E69D.5E3BE11D@mindspring.com> References: <3B946708.ECB7307B@mindspring.com> <15253.6194.432852.114923@nomad.yogotech.com> <3B95D7AE.22C12A17@mindspring.com> <15253.55856.528797.176984@nomad.yogotech.com> <3B95E69D.5E3BE11D@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Bill Jolitz approved a 0.5 "interim release" of 386BSD > > > > And then Lynn revoked this, and posted a public message to the world > > stating what obnoxious fiends we were. > > Actually, Lynne didn't have the right to do this; the trademark > was Bill's, so the revocation wasn't valid until Bill did it. > > > > > Some of the people who later split off NetBSD and released the > > > NetBSD 0.8 release had reverse engineered the patchkit format, > > > and built tools to do the same thing. > > > > Actually, no. It was the person who was going to take it from me (I > > could name him, but it wouldn't do much good). The new maintainer > > didn't do anything or respond to email for over 3 months, so Jordan took > > it over from where I left off. > > I was aware that CGD had reverse engineered it. He didn't. Chris never used the patchkit, nor did he ever release any patches. He used some of the patches, but never got involved in anything but his own BSD release. > I wasn't aware > that you had given the tools to the people who later released > the "1000" level patches. He was supposed to be the next maintainer. :( > > NetBSD happened when Lynn's famous email was sent out claiming we were > > all evil incarnate, and that no-one understood them anymore. > > I talked to Lynne and Bill through much of that time; it was > (unfortunately) a discussion well before the fireworks that > resulted in him knowing about common law trademarks. I was > still on good terms with them, well after the NetBSD 0.8 > release, and we mostly "just lost touch", rather than letting > the bickering come between us. I'm suprised you were able to talk to them. Lynn refused to talk to me (or anyone else) on the phone towards the end, and then the famous email was released. > As for the binaries, we had a number of patched floppy images > floating around (I personally couldn't boot the thing at all > until I binary edited the floppy to look for 639 instead of > 640 in the CMOS base memory data registers). Right, but they weren't good enough for a complete install. > Unfortunately, I cut myself out of the loop early on that, > due to the impending purchase of USL by Novell, which went through > in June of 1994, after off shore locations which were not Berne > Convention signatories had been found to house the code in case the > worst happened, so this email is not part of my personal archives. > I hope someone, somewhere has saved it for posterity... It's on 120MB QIC tapes in the drawer next to me. The 'original' 386BSD/FreeBSD development box (prior to WC's involvement) with the tape drive is still in service as my firewall. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 2: 2:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 99C3237B40B; Wed, 5 Sep 2001 02:02:49 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2D80366D0A; Wed, 5 Sep 2001 02:02:49 -0700 (PDT) Date: Wed, 5 Sep 2001 02:02:48 -0700 From: Kris Kennaway To: Chojin Cc: security-advisories@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser Message-ID: <20010905020248.A71012@xor.obsecurity.org> References: <200109041949.f84JnJs36681@freefall.freebsd.org> <010e01c135e4$1ea267a0$0245a8c0@chojin> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <010e01c135e4$1ea267a0$0245a8c0@chojin>; from freebsd@tarakan-network.com on Wed, Sep 05, 2001 at 10:23:57AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 05, 2001 at 10:23:57AM +0200, Chojin wrote: > When I apply the patch : > [ /usr/src/usr.sbin/adduser]$patch -p < /home/chojin/patch/rmuser.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: rmuser.perl > |=================================================================== > |RCS file: /usr2/ncvs/src/usr.sbin/adduser/rmuser.perl,v > |retrieving revision 1.8.2.4 > |retrieving revision 1.8.2.5 > |diff -u -r1.8.2.4 -r1.8.2.5 > |--- rmuser.perl 2001/05/25 15:05:00 1.8.2.4 > |+++ rmuser.perl 2001/07/28 12:10:15 1.8.2.5 > -------------------------- > Patching file rmuser.perl using Plan A... > Hunk #1 failed at 42. > Hunk #2 failed at 311. > Hunk #3 failed at 340. > Hunk #4 failed at 350. > 4 out of 4 hunks failed--saving rejects to rmuser.perl.rej > done I don't think this is the fault of the patch. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7leo4Wry0BWjoQKURAu8oAKDj/O8rRO0nC1qn9jgxoHKjLeCj/QCeJPIX IG9yaZMzOQbWDRlr29i85BQ= =ejze -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 2: 8:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id AD87A37B401 for ; Wed, 5 Sep 2001 02:08:18 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f8597fT08462; Wed, 5 Sep 2001 11:07:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: tlambert2@mindspring.com Cc: Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? In-Reply-To: Your message of "Wed, 05 Sep 2001 00:56:33 PDT." <3B95DAB1.67861BCF@mindspring.com> Date: Wed, 05 Sep 2001 11:07:41 +0200 Message-ID: <8460.999680861@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3B95DAB1.67861BCF@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> Nate, >> >> You're replying to Terry for christs sake! What did you expect if not >> revisionist $anything ? >> >> Which reminds me, Adrian still oves us his story about ref :-) > >Poul, you're going off again, without regard for facts. Terry, *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. *You* have talked to people who worked at TFS. Now, remind me again why historians are so picky about "primary sources" and "secondary sources" for historical information... Are we done now ? (Apart from Adrians story of course :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 2:20:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 9052A37B407; Wed, 5 Sep 2001 02:19:46 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA05452; Wed, 5 Sep 2001 02:19:26 -0700 (PDT) Message-ID: <3B95EE4A.EF204095@mindspring.com> Date: Wed, 05 Sep 2001 02:20:10 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: "Vladimir A. Jakovenko" , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010904231049.E7815-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > > Similarly, there are a number of bugs in the TCP sockets as > > well; specifically, there's a problem with all sockets being > > treated as being in the same collision domain, when doing > > automatic port assignment. This limits you to 65535 oubound > > TCP connections, even though you have multiple IP aliases on > > an interface (theoretically, you should get 64k connections > > per IP address, if you bind _not_ to IN_ADDR_ANY, but instead > > use a specific port, but the hash is broken). > > I like this problem's evil sibling: client side TIME_WAITs. If > you build them up, you just sit there unable to allocate outgoing > ports until they time out. If you fix or workaround the source IP address problem, and patch/tune the kernel for enough outbound sockets, you can go to 250,000 outbound connections very easily. I used a couple of 1GB memory systems in this configuration to get my 1M (actually, closer to 2M) inbound server connections... obviously, a server doesn't have the port limitation, when it comes to accepting connections. The client TIME_WAIT problem is more an issue for port reuse; for a 2MSL timer in the standard 60 second range, this will basically limit you to 65535/60, or ~1000 outbound connections a second per IP address, as a sustained rate, with a total outstanding count of 65535 * IP_address_count. Unless you set SO_REUSEPORT/SO_REUSEADDR. So for the client side, you are pretty much limited by the bug (or your fix), and whatever you set the 2MSL timer down to, as a sustained rate top end. For most real world uses, apart from test equipment, which will usually just use raw sockets directly, and fake the AYN/ACK for the SYN, and then accept the ACK without an RST, you never really get up into this number of client connections on a single box. > Maybe net or openbsd handle these situations better, I'll have > to check later. I doubt it. Until I did testing on 4.3, no one had really run over 32,766 open sockets in a production server, since at that point, the ucred reference count overflowed, which would result in some strange and very hard to identify crashes, when closing those connections. Alfred fixed this in -current, but it wasn't done consciously to address a known problem, it was done "just in case" (Alfred finds problems like that, and fixes them without necessarily being aware of it... 8-)). It hadn't been MFC'ed back to 4.3 until I identified an actual problem, and the root cause. NetBSD and OpenBSD have some hacks on the server side of the scaling problem (e.g. they have each implemented a SYN cache, which is OK as far as it goes, but is really inferior to the SYN cache and rate halving algorithm code (also against FreeBSD) out of the Pittsburgh Supercomputing Center. I've done a preliminary port of the PSC code to 4.x, actually, though I would need to strip out a number of local changes. One interesting thing about the SYN cache code is that it could use the tcptmpl allocation until it saw the ACK (or even the first data, as was suggested by some of the researchers at that startup in India, a while back, though that's very aggressive). Mostly, you aren't going to see the hashing on both source and detination IP's and ports -- what you'd see in an L2/L3 switch, if you were building one -- which would let you reuse the local pair, so long as it was associated with a different remote pair. That's probably the real long term fix, if there is one. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 2:22:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guru.mired.org (okc-94-248-46.mmcable.com [24.94.248.46]) by hub.freebsd.org (Postfix) with SMTP id 0D72237B406 for ; Wed, 5 Sep 2001 02:22:14 -0700 (PDT) Received: (qmail 56303 invoked by uid 100); 5 Sep 2001 09:22:13 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.61124.936424.530720@guru.mired.org> Date: Wed, 5 Sep 2001 04:22:12 -0500 To: Kevin Way Cc: Mike Meyer , jmallett@newgold.net, freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. In-Reply-To: <20010905014148.A90520@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> <15253.27916.591039.936494@guru.mired.org> <20010905014148.A90520@bean.overtone.org> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kevin Way types: > > You can even do this in userland with an nfs server API if you > > want it to be portable. > Novel idea. I'll file it into the maybe pile. Old idea. I first saw an ftp version of this in '91 or '92. Last time I went looking for source code, I couldn't find it, so I have no idea who to credit. > > I don't know of any application that handles local files that responds > > to any open error by prompting for a password. If "open" can now > > return an HTTP 401 error, every application is going to need to be > > able to deal with that in some sane way. Either that, or users are > > going to have to know the proper syntax for usernames and passwords in > > every URL scheme they deal with - and start putting passwords on > > command lines, and other things that give security officers > > nightmares. > I would imagine that an http filesystem layer would return EACCES for a > 401, as that would probably cause any program to return a sane error to > the user. Hopefuly, an http file system will have options to let you specify a username and password, so you can mount password-protected "volumes" that way. Or possibly a place to specify an authentication realm file, giving username/password pairs for the various different realms that might be in the mounted tree. > Yes, unfortunately all ideas are just a Simple Matter of Programming... > One miscommunication I should apologize for, I'm not suggesting the > URLification of FreeBSD. I'm suggesting that it would be a Good Thing if > files available via any common networked file transfer protocol were able > to be accessed via standard system calls. I can't argue that having that capability on a workstation would be nice. I don't think it's something I'd make a lot of use of, and I'm not really interested in adding it. > Anyway, in conclusion it would seem to me that we agree, but there was a > misunderstanding because I did a poor job of clipping relevant text to > show what it was I was agreeing with. I think it's more a case of topic drift. This thread started with the observation that URLs were ubiquitous, and asked whether or not they should be pervasive as well. Your - and presumably Mike's - proposed solution doesn't deal with that at all. > > In summary, each command needs to decide - possibly on a case-by-case > > basis whether or not the string it's got is a URL or a file name. It > > needs to decide how the operation it's been asked to be performed can > > be performed on the object that URL represents, and if so how it > > should be mapped. If it's a URL, the application may well have to deal > > with events that don't happen with local files. > I really don't want all that in every command. I want it in a filesystem > layer, where appropriate, as described above. I agree about that. On the other hand, there are commands that take arguments with information that can be put into a url. Because URLs are ubiquitous, it would be nice if those commands would extrat that information for you. I.e. - ncftp grew the ability to deal with FTP urls. fetch carries that even further. I can see wanting a mail composition program that would recognize a mailto URL on the argument line, and pull out the address and subject for you. One of the suggestions that fell out of this was that there be a shell command for doing these kinds of things. While I like that idea, I think the shell command should be a wrapper around some library calls, so that this kind of thing can easily be added to commands where appropriate. Especially since we already have half the functionality - if in a crippled form - in libfetch. This is something I'm willing to work on, and have even started on. I submitted PR 30318, which adds the missing half the functionality to libfetch - but doesn't do any healing of the first half - and a small program that tries to act like the "url" command described earlier on the thread. > I apologize for the miscommunication. I don't think one is necessary, or if one is, I need to apologize as well for missing the change in direction. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 2:27:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 6848237B408 for ; Wed, 5 Sep 2001 02:27:48 -0700 (PDT) Received: from mindspring.com (dialup-209.245.138.192.Dial1.SanJose1.Level3.net [209.245.138.192]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA15676; Wed, 5 Sep 2001 02:27:37 -0700 (PDT) Message-ID: <3B95F035.362A4948@mindspring.com> Date: Wed, 05 Sep 2001 02:28:21 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <8460.999680861@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. I'm well aware of your checkered past... 8-). I guess Julian might pipe up now about the use of the acronym "AWOL"... > Now, remind me again why historians are so picky about "primary > sources" and "secondary sources" for historical information... That would be... Dennis Ritchie? 8-) 8-). > Are we done now ? I guess... > (Apart from Adrians story of course :-) If you think you can beat it out of him... I think we'd all like to sit around the camp fire and listen to it, while stroking our long grey beards... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 3:17: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 9CA4237B407 for ; Wed, 5 Sep 2001 03:16:58 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f85AFkY50615; Wed, 5 Sep 2001 18:16:00 +0800 (KRAST) Date: Wed, 5 Sep 2001 18:15:54 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <1125409218.20010905181554@morning.ru> To: Peter Pentchev Cc: "Freebsd Hackers (E-mail)" Subject: Re[2]: virtual consoles In-Reply-To: <20010904104553.B61594@ringworld.oblivion.bg> References: <31A473DBB655D21180850008C71E251A031AAFF1@mail.kebne.se> <20010903131504.I72833@ringworld.oblivion.bg> <1144619252.20010904113739@morning.ru> <20010904104553.B61594@ringworld.oblivion.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Tue, Sep 04, 2001 at 11:37:39AM +0800, Igor Podlesny wrote: > [snip] >> >> Screen is a nice thing, I agree. Just one drawback is (Ctrl-A)*N >> consoles (i.e., when you use screen at local console, than log in >> into another box and run screen there. Local screen will see catch >> Ctrl-A and you're forced to type it twice or even more times :) > And then, of course, there is always the 'escape' screenrc command, > allowing you to set a different command character for each session :) > Though.. this would probably lead to a nightmare of misdirected key > presses.. But still, it is there. Yeah, I knew that but considered it was "a nightmare" :) -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 3:19:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 97BC537B40B for ; Wed, 5 Sep 2001 03:19:28 -0700 (PDT) Received: (qmail 9776 invoked by uid 1000); 5 Sep 2001 10:19:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Sep 2001 10:19:27 -0000 Date: Wed, 5 Sep 2001 12:19:27 +0200 (CEST) From: Attila Nagy To: Leo Bicknell Cc: Subject: Re: Routing Performance? In-Reply-To: <20010903104909.B7801@ussenterprise.ufp.org> Message-ID: <20010905121838.F8758-100000@scribble.fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, > The last is a dual processor alpha board. Alpha motherboards have > generally better memory IO, including 2.6 Gb/Sec to main memory. > Unfortunately it can only take 2 gig of RAM. AFAIK, that's not a problem, because FreeBSD on alpha can't handle more than that... -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 4:10:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 7E0DB37B401 for ; Wed, 5 Sep 2001 04:10:27 -0700 (PDT) Received: from fump.kawo2.rwth-aachen.de (root@fump.kawo2.rwth-aachen.de [134.130.181.148]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id NAA09733 for ; Wed, 5 Sep 2001 13:10:26 +0200 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.11.3/8.11.3) id f85BASV05488 for freebsd-hackers@FreeBSD.org; Wed, 5 Sep 2001 13:10:28 +0200 (CEST) (envelope-from alex) Date: Wed, 5 Sep 2001 13:10:27 +0200 From: Alexander Langer To: freebsd-hackers@FreeBSD.org Subject: local changes to CVS tree Message-ID: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Kris Kennaway (kris@obsecurity.org): > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? I mean I have much stuff, which gets M file in the next cvs update, but I'd really like to cvs commit them to my local /home/ncvs, but cvsup will overwrite these changes. Thanks Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 4:11:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 63E8937B406 for ; Wed, 5 Sep 2001 04:11:34 -0700 (PDT) Received: (qmail 91724 invoked by uid 1000); 5 Sep 2001 11:11:55 -0000 Date: Wed, 5 Sep 2001 13:11:55 +0200 From: "Karsten W. Rohrbach" To: Hans Christensen Cc: freebsd-hackers@freebsd.org Subject: Re: SLOW ftp transfers one way Message-ID: <20010905131155.C91205@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Hans Christensen , freebsd-hackers@freebsd.org References: <006c01c131cf$1ea67020$523e5042@datamatrix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006c01c131cf$1ea67020$523e5042@datamatrix.com>; from hansc@techserve.datamatrix.com on Thu, Aug 30, 2001 at 08:43:38PM -0700 X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.webmonster.de/ X-Disclaimer: My opinions do not necessarily represent those of my employer X-Work-URL: http://www.ngenn.net/ X-Work-Address: nGENn GmbH, Schloss Kransberg, D-61250 Usingen-Kransberg, Germany X-Work-Phone: +49-6081-682-304 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable you should check the settings of your switch ports and look into the output of 'ifconfig -a'. try nailing the switch to 100baseTX.full duplex and set up the network card with 'ifconfig fxp0 media 100baseTX mediaopt full-duplex' this solves carrier transition problems with stupid switch hardware which cause throughtput degradation. in the environments i administer, nway autonegotiation is always turned off, both sides are set to 100base/fdup. /k Hans Christensen(hansc@techserve.datamatrix.com)@2001.08.30 20:43:38 +0000: > I have recently redefined a problem which has been plaguing me for cl= ose > to a year now. I have several FBSD boxes at a site fed by a Sprint T1 (Si= te > A). Each of these boxes is capable of ftp'ing to each other on the same > subnet at speeds approaching the limits of the disk subsystem. In short, > transfers on the LAN between FBSD boxen appear to be fine. In addition, I > have enlisted the help of the folks at sprint to ftp in and out of these > boxes with speeds approaching the limits of the T1 line - no problem ther= e. > It should be noted that the sprint guys have done their transfers from > within sprint's network and are therefore NOT crossing their own network > access points. > Here is where it gets weird. If I ftp into one of my boxes at Site A > across the WAN (in this case from a colocation facility) and put a large > file onto my server in Site A, I get speeds of about 10KB/s. This may > fluctuate from 4KB/s to 16KB/s, but it far below what one would normally = see > across a T1 line. Interestingly enough, sending ftp traffic out of Site A > seems to move five to ten time faster - not perfect, but workable. Below = are > example of the same file transferred first out of Site A to the colocation > facility, and then the same file just transferred, back into Site A. You > will note the difference in speeds... This colocation facility is NOT on = the > same network as sprint and therefore DOES have to cross one of Sprint's > network access points. Furthermore, to rule out the possibility that the > colo facility is to blame, I ftp'ed from a linux box on yet another ISP's > network. This linux box had the same type of performance problems. Slow p= uts > to Site A and reasonable gets from Site A. > I have seen this before as well, between boxes at the colocation > facility and again across different class c subnets. Sprint claims that t= he > problem lies with the MTU settings of the boxes at the "linux side" and t= he > "colo side." This smells wrong to me, but I confess that I don't really k= now > that it is wrong. I have looked in the FBSD bug reports for any indication > of a similar problem and do not see any so far, but I have seen several > questions on the mailing list archives. Most of these are dismissed as > improper configuration of ethernet cards. I have tried these suggestions = but > found no relief. > I ftp close to a GB of info every night into Site A and I need it to = go > faster than it has been going, but I'm stumped. Anybody got any clues for > the clueless? >=20 > Hans Christensen > hansc@datamatrix.com >=20 > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> put jdk-1_2_2_006-win.exe > local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe > 227 Entering Passive Mode (************). > 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe > 100% > |************************************************************************= *** > ***************************| 298 KB 00:00 ETA > 226 Transfer complete. > 305152 bytes sent in 3.66 seconds (81.33 KB/s) > ftp> get jdk-1_2_2_006-win.exe > local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe > 227 Entering Passive Mode (*************). > 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe (305152 > bytes). > 100% > |************************************************************************= *** > ***************************| 298 KB 00:00 ETA > 226 Transfer complete. > 305152 bytes received in 25.77 seconds (11.56 KB/s) > ftp> >=20 >=20 > Here is a dmesg: >=20 > Copyright (c) 1992-2001 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.3-STABLE #0: Fri Jun 1 06:59:28 PDT 2001 > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x673 Stepping =3D 3 >=20 > Features=3D0x387f9ff PAT,PSE36,PN,MMX,FXSR,SSE> > real memory =3D 201261056 (196544K bytes) > avail memory =3D 192282624 (187776K bytes) > Preloaded elf kernel "kernel" at 0xc035e000. > VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc02fd882 (1000022) > VESA: ATI MACH64 > Pentium Pro MTRR support enabled > md0: Malloc disk > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at 0.0 irq 11 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0xf000-0xf00f at device 7.1 = on > pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: at 7.2 > chip1: port 0x5000-0x500f at > device 7.3 on pci0 > fxp0: port 0xe400-0xe43f mem > 0xeb000000-0xeb0fffff,0xeb202000-0xeb202fff irq 10 at device 9.0 on pci0 > fxp0: Ethernet address 00:90:27:9a:47:1e > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp1: port 0xe800-0xe83f mem > 0xeb100000-0xeb1fffff,0xeb200000-0xeb200fff irq 5 at device 10.0 on pci0 > fxp1: Ethernet address 00:90:27:9a:47:10 > inphy1: on miibus1 > inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ahc0: port 0xec00-0xecff mem > 0xeb201000-0xeb201fff irq 11 at device 12.0 on pci0 > aic7880: Wide Channel A, SCSI Id=3D7, 16/255 SCBs > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: failed to get data. > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > IP packet filtering initialized, divert disabled, rule-based forwarding > enabled, default to accept, logging disabled > ad0: 9787MB [19885/16/63] at ata0-master UDMA33 > ad2: 19546MB [39714/16/63] at ata1-master UDMA33 > acd0: CD-RW at ata0-slave using PIO4 > Waiting 5 seconds for SCSI devices to settle > no devsw da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 105010MB (215061120 512 byte sectors: 255H 63S/T 13386C) > (majdev=3D0 bootdev=3D0xa0200000) > Mounting root from ufs:/dev/ad0s1 --=20 > MCSE: Minesweeper Consultant & Solitaire Engineer KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7lgh7M0BPTilkv0YRAnQjAJ9b/iOAtLWtXYNHoteroA6tmgT17QCgvM3F 9sc466xj93Q01mgr3kUA/AA= =EBsS -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 6: 7:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id B839137B401; Wed, 5 Sep 2001 06:07:10 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f85D78Y56072; Wed, 5 Sep 2001 21:07:09 +0800 (KRAST) Date: Wed, 5 Sep 2001 21:07:19 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <16615694707.20010905210719@morning.ru> To: freebsd-isp@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: auto relaying for subdomains -- why? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My greetings! I noticed that some mailers (sendmail, postfix) in case they allow relaying for somedomain.zone also allow relaying for subdomain-of.somedomain.zone. I can accept this as reasonable behavior but would like to know how to deny it! :) Also I wish to know what was the actual idea behind this? P.S. I searched for answers through Inet, digging RFCs but nothing have found yet... -- Best regards, Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 6: 9:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id DE42837B407 for ; Wed, 5 Sep 2001 06:09:11 -0700 (PDT) Received: from fump.kawo2.rwth-aachen.de (root@fump.kawo2.rwth-aachen.de [134.130.181.148]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id PAA14809 for ; Wed, 5 Sep 2001 15:09:11 +0200 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.11.3/8.11.3) id f85D9DJ05820 for freebsd-hackers@FreeBSD.org; Wed, 5 Sep 2001 15:09:13 +0200 (CEST) (envelope-from alex) Date: Wed, 5 Sep 2001 15:09:13 +0200 From: Alexander Langer To: freebsd-hackers@FreeBSD.org Subject: Re: local changes to CVS tree Message-ID: <20010905150913.D5586@fump.kawo2.rwth-aachen.de> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905142800.C633@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905142800.C633@ringworld.oblivion.bg>; from roam@ringlet.net on Wed, Sep 05, 2001 at 02:28:00PM +0300 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Peter Pentchev (roam@ringlet.net): > One way that (I think it was) Sheldon pointed out to me a few months > ago would be keeping your own CVS repository and vendor-importing > the FreeBSD source on a regular basis. The regular vendor-import > is quite time-consuming though :( That sucks. From what I've heart about the Sparc64 development on freefall, perforce seems to be able to do such stuff automatically, right? Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 6:30:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 1F70737B40E for ; Wed, 5 Sep 2001 06:30:32 -0700 (PDT) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f85DUSP07313; Wed, 5 Sep 2001 15:30:29 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f85DUk116821; Wed, 5 Sep 2001 15:30:46 +0200 (CEST) Date: Wed, 5 Sep 2001 15:30:45 +0200 From: Bernd Walter To: Alexander Langer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: local changes to CVS tree Message-ID: <20010905153045.D16349@cicely20.cicely.de> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905131027.A5476@fump.kawo2.rwth-aachen.de>; from alex@big.endian.de on Wed, Sep 05, 2001 at 01:10:27PM +0200 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: > Thus spake Kris Kennaway (kris@obsecurity.org): > > > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > > something to fix it soon :-) > > I'm just curious: > How do people fix stuff in their local CVS tree and sync other > FreeBSD changes with that? It's a CVSup FAQ: http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal -- 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 Wed Sep 5 6:32:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id C63FD37B405; Wed, 5 Sep 2001 06:32:06 -0700 (PDT) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f85DW3P07331; Wed, 5 Sep 2001 15:32:03 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f85DWLb16852; Wed, 5 Sep 2001 15:32:21 +0200 (CEST) Date: Wed, 5 Sep 2001 15:32:20 +0200 From: Bernd Walter To: Igor Podlesny Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: auto relaying for subdomains -- why? Message-ID: <20010905153220.E16349@cicely20.cicely.de> References: <16615694707.20010905210719@morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <16615694707.20010905210719@morning.ru>; from poige@morning.ru on Wed, Sep 05, 2001 at 09:07:19PM +0800 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 09:07:19PM +0800, Igor Podlesny wrote: > > My greetings! > > I noticed that some mailers (sendmail, postfix) in case they allow > relaying for somedomain.zone also allow relaying for > subdomain-of.somedomain.zone. > > I can accept this as reasonable behavior but would like to know how to > deny it! :) Also I wish to know what was the actual idea behind this? Allow domain.com disallow .domain.com -- 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 Wed Sep 5 7:15:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (sentinel.office1.bg [217.75.135.254]) by hub.freebsd.org (Postfix) with SMTP id E26A237B406 for ; Wed, 5 Sep 2001 07:15:07 -0700 (PDT) Received: (qmail 1266 invoked by uid 1000); 5 Sep 2001 11:28:00 -0000 Date: Wed, 5 Sep 2001 14:28:00 +0300 From: Peter Pentchev To: Alexander Langer Cc: freebsd-hackers@FreeBSD.org Subject: Re: local changes to CVS tree Message-ID: <20010905142800.C633@ringworld.oblivion.bg> Mail-Followup-To: Alexander Langer , freebsd-hackers@FreeBSD.org References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905131027.A5476@fump.kawo2.rwth-aachen.de>; from alex@big.endian.de on Wed, Sep 05, 2001 at 01:10:27PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: > Thus spake Kris Kennaway (kris@obsecurity.org): > > > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > > something to fix it soon :-) > > I'm just curious: > How do people fix stuff in their local CVS tree and sync other > FreeBSD changes with that? > > I mean I have much stuff, which gets > M file > in the next cvs update, but I'd really like to cvs commit them > to my local /home/ncvs, but cvsup will overwrite these changes. One way that (I think it was) Sheldon pointed out to me a few months ago would be keeping your own CVS repository and vendor-importing the FreeBSD source on a regular basis. The regular vendor-import is quite time-consuming though :( Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). G'luck, Peter -- Thit sentence is not self-referential because "thit" is not a word. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 8:23:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay04.esat.net (relay04.esat.net [192.111.39.47]) by hub.freebsd.org (Postfix) with ESMTP id 6081F37B406 for ; Wed, 5 Sep 2001 08:23:22 -0700 (PDT) Received: from (consecurity.KINDLEBANKSYS.COM) [193.120.150.86] by relay04.esat.net with esmtp id 15eeWP-0002vf-00; Wed, 05 Sep 2001 16:23:21 +0100 Received: from smtp.kindlebanksys.com (unverified) by consecurity.KINDLEBANKSYS.COM (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Wed, 5 Sep 2001 16:19:44 +0100 Received: by smtp.kindlebanksys.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256ABE.0053923A ; Wed, 5 Sep 2001 16:12:49 +0100 X-Lotus-FromDomain: KINDLE From: Ullasan_Kottummal@kindlebanksys.com To: freebsd-hackers@FreeBSD.org Message-ID: <80256ABE.005390D9.00@smtp.kindlebanksys.com> Date: Wed, 5 Sep 2001 16:18:19 +0100 Subject: Posix Threading Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. Thanks in advance Ullasan --------------------------------------------------------------------------------------------------------------------------- This email message (including any attachment) is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, you may not disclose it, copy it, distribute it or take or omit to take any action on foot of it. Any such act or omission is prohibited and may be unlawful. This message (including any attachment) is transmitted for discussion purposes only. It is protected by copyright laws and it has no other legal or contractual standing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 8:25:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id B612337B408 for ; Wed, 5 Sep 2001 08:25:41 -0700 (PDT) Received: (qmail 16682 invoked by uid 3130); 5 Sep 2001 15:25:40 -0000 Date: Wed, 5 Sep 2001 11:25:40 -0400 From: Garrett Rooney To: Ullasan_Kottummal@kindlebanksys.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: Posix Threading Message-ID: <20010905112540.B93013@electricjellyfish.net> References: <80256ABE.005390D9.00@smtp.kindlebanksys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <80256ABE.005390D9.00@smtp.kindlebanksys.com>; from Ullasan_Kottummal@kindlebanksys.com on Wed, Sep 05, 2001 at 04:18:19PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 04:18:19PM +0100, Ullasan_Kottummal@kindlebanksys.com wrote: > > > Hi All, > I am trying to create threads under HP-UX 11 using POSIX threads library and > using the method pthread_create(...). > > But I don't know how can I create a thread in a suspended state. > > Thanks in advance This mailing list is a forum for discussion related to the development of the FreeBSD operating system, so it probably isn't the best place to ask HP-UX specific questions. -- garrett rooney Unix was not designed to stop you from rooneg@electricjellyfish.net doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 8:38:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.spock.org (cm-24-29-85-81.nycap.rr.com [24.29.85.81]) by hub.freebsd.org (Postfix) with ESMTP id 8662F37B40F; Wed, 5 Sep 2001 08:38:27 -0700 (PDT) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Wed, 5 Sep 2001 11:38:26 -0400 (EDT) (envelope-from jon)$ Date: Wed, 5 Sep 2001 11:38:26 -0400 From: Jonathan Chen To: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010905113826.B28669@enterprise.spock.org> References: <200109041343.f84DhO097646@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: ; from bp@butya.kz on Wed, Sep 05, 2001 at 12:10:31AM +0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While on the subject of VFS locking... Accessing devfs through a nullfs redirection causes a panic() due to locking issues. I haven't had time to look at this in detail yet, if somebody wants to jump up and fix the problem, feel free... -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 8:46:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prima-exc01.cidadei.com.br (a200042033005.rev.prima.com.ar [200.42.33.5]) by hub.freebsd.org (Postfix) with ESMTP id 2798237B40B for ; Wed, 5 Sep 2001 08:46:51 -0700 (PDT) Received: by prima-exc01.cidadei.com.br with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 12:41:07 -0300 Message-ID: <9CF6FAED416EA043A968ED643E1371950C4C76@prima-exc01.cidadei.com.br> From: Daniel Abad To: "'hackers@FreeBSD.ORG'" Subject: no memory for rx list Date: Wed, 5 Sep 2001 12:40:59 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Help!!! What can I do??? /var/log/messages: Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! /var/log/httpd/error_log: [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 configured -- resuming normal operations [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, consider raising the MaxClients setting /usr/local/apache/conf/httpd.conf MinSpareServers 200 MaxSpareServers 10000 StartServers 1024 MaxClients 256 MaxRequestsPerChild 10000 Tks, Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 8:50:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from distortion.dk (distortion.dk [195.249.147.156]) by hub.freebsd.org (Postfix) with ESMTP id 39BC437B403 for ; Wed, 5 Sep 2001 08:50:40 -0700 (PDT) Received: from petri2000 ([194.192.131.98]) by distortion.dk (8.9.3/8.9.1) with SMTP id RAA25263; Wed, 5 Sep 2001 17:57:11 +0200 (CEST) (envelope-from freebsd@petri.cc) Message-ID: <00a901c13622$7cc4ba20$8632a8c0@atomic.dk> From: "Nicolai Petri" To: "Daniel Abad" Cc: References: <9CF6FAED416EA043A968ED643E1371950C4C76@prima-exc01.cidadei.com.br> Subject: Re: no memory for rx list Date: Wed, 5 Sep 2001 17:50:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Daniel, Check netstat -m to see if your are out of mbufs (my guess) To fix this see the man page for 'tuning' It describes how to increase the network buffers on your system. Best regards, --- Nicolai Petri ----- Original Message ----- From: "Daniel Abad" To: Sent: Wednesday, September 05, 2001 5:40 PM Subject: no memory for rx list > Help!!! What can I do??? > > /var/log/messages: > Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > /var/log/httpd/error_log: > [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 > configured -- resuming normal operations > [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 > [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, > consider raising the MaxClients setting > > /usr/local/apache/conf/httpd.conf > MinSpareServers 200 > MaxSpareServers 10000 > StartServers 1024 > MaxClients 256 > MaxRequestsPerChild 10000 > > > Tks, > > Dan > > 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 Sep 5 9:58:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 71AB237B409; Wed, 5 Sep 2001 09:58:47 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [127.0.0.1]) by horsey.gshapiro.net (8.12.0.Gamma0/8.12.0.Gamma0) with ESMTP id f85GwkUN022165 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Sep 2001 09:58:46 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.0.Gamma0/8.12.0.Gamma0/Submit) id f85Gwjmc022162; Wed, 5 Sep 2001 09:58:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <15254.22980.843972.348805@horsey.gshapiro.net> Date: Wed, 5 Sep 2001 09:58:44 -0700 From: Gregory Neil Shapiro To: Igor Podlesny Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: auto relaying for subdomains -- why? In-Reply-To: <16615694707.20010905210719@morning.ru> References: <16615694707.20010905210719@morning.ru> X-Mailer: VM 6.95 under 21.5 (beta1) "anise" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG poige> I noticed that some mailers (sendmail, postfix) in case they a= llow poige> relaying for somedomain.zone also allow relaying = for poige> subdomain-of.somedomain.zone. poige> I can accept this as reasonable behavior but would like to know ho= w to poige> deny it! :) Also I wish to know what was the actual idea behind th= is? =46rom /usr/share/sendmail/cf/README: +----------+ | FEATURES | +----------+ =2E.. Available features are: =2E.. relay_hosts_only By default, names that are listed as RELAY in the access db and class {R} are domain names, not host names. For example, if you specify ``foo.com'', then mail to or from foo.com, abc.foo.com, or a.very.deep.domain.foo.com will all be accepted for relaying. This feature changes the behaviour to lookup individual host names only. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 9:59:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prima-exc01.cidadei.com.br (a200042033005.rev.prima.com.ar [200.42.33.5]) by hub.freebsd.org (Postfix) with ESMTP id 52BAC37B418 for ; Wed, 5 Sep 2001 09:58:56 -0700 (PDT) Received: by prima-exc01.cidadei.com.br with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 13:53:14 -0300 Message-ID: <9CF6FAED416EA043A968ED643E1371950C4C77@prima-exc01.cidadei.com.br> From: Daniel Abad To: 'Nicolai Petri' Cc: freebsd-hackers@freebsd.org Subject: RES: no memory for rx list Date: Wed, 5 Sep 2001 13:53:09 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1362B.3DBE4D60" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1362B.3DBE4D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that=B4s the problem 1598/1616/4096 mbufs in use (current/peak/max): 1107 mbufs allocated to data 491 mbufs allocated to packet headers 1024/1024/1024 mbuf clusters in use (current/peak/max) =20 2452 Kbytes allocated to network (79% of mb_map in use) 8784 requests for memory denied =20 I=B4ll look for tunning... -----Mensagem original----- De: Nicolai Petri [mailto:freebsd@petri.cc] Enviada em: quarta-feira, 5 de setembro de 2001 12:50 Para: Daniel Abad Cc: freebsd-hackers@freebsd.org Assunto: Re: no memory for rx list Hi Daniel, Check netstat -m to see if your are out of mbufs (my guess) To fix this see the man page for 'tuning'=20 It describes how to increase the network buffers on your system. Best regards, --- Nicolai Petri ----- Original Message -----=20 From: "Daniel Abad" To: Sent: Wednesday, September 05, 2001 5:40 PM Subject: no memory for rx list > Help!!! What can I do???=20 >=20 > /var/log/messages: > Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- = packet > dropped! > /var/log/httpd/error_log: > [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 > configured -- resuming normal operations > [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 > [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, > consider raising the MaxClients setting >=20 > /usr/local/apache/conf/httpd.conf=20 > MinSpareServers 200 > MaxSpareServers 10000 > StartServers 1024 > MaxClients 256=20 > MaxRequestsPerChild 10000 > =20 >=20 > Tks, >=20 > Dan >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ------_=_NextPart_000_01C1362B.3DBE4D60 Content-Type: application/octet-stream; name="Daniel Abad.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Daniel Abad.vcf" BEGIN:VCARD VERSION:2.1 N:Abad;Daniel FN:Daniel Abad ORG:Cidade Internet;Tecnologia NOTE;ENCODING=3DQUOTED-PRINTABLE:Analista de Suporte=3D0D=3D0A TEL;WORK;VOICE:3365-0186 TEL;WORK;VOICE:3365-0192 ADR;WORK:;;Av. Juscelino Kubistchek, 1830 Torre 1 - 4=BA and..;S=E3o = Paulo;SP;04543-900;Brasil LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Av. Juscelino Kubistchek, 1830 = Torre 1 - 4=3DBA and..=3D0D=3D0AS=3DE3o Paulo, SP 045=3D 43-900=3D0D=3D0ABrasil EMAIL;PREF;INTERNET:dabad@cidadei.com.br REV:20010126T145133Z END:VCARD ------_=_NextPart_000_01C1362B.3DBE4D60-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 10:24:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id D73C537B40E for ; Wed, 5 Sep 2001 10:23:54 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f85HNcg41619; Wed, 5 Sep 2001 10:23:38 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f85HNbl07385; Wed, 5 Sep 2001 10:23:37 -0700 (PDT) (envelope-from jdp) Date: Wed, 5 Sep 2001 10:23:37 -0700 (PDT) Message-Id: <200109051723.f85HNbl07385@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: roam@ringlet.net Subject: Re: local changes to CVS tree In-Reply-To: <20010905142800.C633@ringworld.oblivion.bg> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905142800.C633@ringworld.oblivion.bg> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20010905142800.C633@ringworld.oblivion.bg>, Peter Pentchev wrote: > > Also, I'm not really sure if CVS would allow having two vendor branches > (say, RELENG_4 and RELENG_5) and two corresponding working branches > (your changes to RELENG_4 and your changes to RELENG_5, which might be > *way* different). CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where "the" vendor branch is hard-coded as 1.1.1. You really don't want to use multiple vendor branches -- trust me. :-) Use two repositories instead, or use perforce. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 11: 1:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 0B3FC37B401 for ; Wed, 5 Sep 2001 11:01:25 -0700 (PDT) Received: from hades.hell.gr (patr530-b030.otenet.gr [195.167.121.158]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f85I1M717660 for ; Wed, 5 Sep 2001 21:01:22 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f85GYOc00811 for hackers@freebsd.org; Wed, 5 Sep 2001 19:34:25 +0300 (EEST) (envelope-from charon@labs.gr) Date: Wed, 5 Sep 2001 19:34:24 +0300 From: Giorgos Keramidas To: hackers@freebsd.org Subject: usr.sbin/ac change - request for comments Message-ID: <20010905193424.A686@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The code of usr.sbin/ac/ includes support for handling ":0.0" as console logins, when CONSOLE_TTY is defined during compilation. Looking at the code, and revisions from 1.2 and up, this doesn't seem to be used. Is there any reason why this should not be removed from the sources. It's not used anyway :/ I'm talking about pieces of code like the following: #ifdef CONSOLE_TTY static char *Console = CONSOLE_TTY; #endif or parts like the even more exotic: while ((c = getopt(argc, argv, "Dc:dpt:w:")) != -1) { switch (c) { ... case 'c': #ifdef CONSOLE_TTY Console = optarg; #else usage(); /* XXX */ #endif break; The code is cluttered all over with #ifdef'ed pieces of code that are not used. Is it really necessary that we keep these parts? -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 11:43:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id F23D337B40C for ; Wed, 5 Sep 2001 11:43:26 -0700 (PDT) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.4/8.11.4) with ESMTP id f85IhPg04767 for ; Wed, 5 Sep 2001 14:43:25 -0400 (EDT) Date: Wed, 5 Sep 2001 14:42:09 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: kernel ddb help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I know gdb can source stepping the kernel. But without two machines, you can not do it. Now I have only one machine and the system panic: db> trace bqrelse(cxxx, cxxx, cxxx, cxxxx, cxxx) at bqrelse+0x25 is there a way to use these addresses to figure out which line or lines of source are suspect to cause the panic? Thanks. Regards, -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 11:44:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id A447537B408 for ; Wed, 5 Sep 2001 11:44:14 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA02193; Wed, 5 Sep 2001 20:44:13 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.4) id f85IiCZ01739; Wed, 5 Sep 2001 20:44:12 +0200 (CEST) (envelope-from wkb) Date: Wed, 5 Sep 2001 20:44:12 +0200 From: Wilko Bulte To: Attila Nagy Cc: Leo Bicknell , hackers@FreeBSD.ORG Subject: Re: Routing Performance? Message-ID: <20010905204412.B1651@freebie.xs4all.nl> References: <20010903104909.B7801@ussenterprise.ufp.org> <20010905121838.F8758-100000@scribble.fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905121838.F8758-100000@scribble.fsn.hu>; from bra@fsn.hu on Wed, Sep 05, 2001 at 12:19:27PM +0200 X-OS: FreeBSD 4.4-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 12:19:27PM +0200, Attila Nagy wrote: > Hello, > > > The last is a dual processor alpha board. Alpha motherboards have > > generally better memory IO, including 2.6 Gb/Sec to main memory. > > Unfortunately it can only take 2 gig of RAM. > AFAIK, that's not a problem, because FreeBSD on alpha can't handle more > than that... Correct. I noticed that NetBSD appears to have fixed this BTW. -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 11:47:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id BF71737B405 for ; Wed, 5 Sep 2001 11:47:24 -0700 (PDT) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.6/8.11.4) id f85Il5o93867; Wed, 5 Sep 2001 14:47:05 -0400 (EDT) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.7p2 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, 05 Sep 2001 14:47:05 -0400 (EDT) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: Zhihui Zhang Subject: RE: kernel ddb help Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You can use gdb on the dump file or even on live kernel after reboot to figure out exactly what the problem was. Use gdb -k ./kernel.debug /dev/mem or gdb -k ./kernel.debug /var/crash/vmcore. On 05-Sep-2001 Zhihui Zhang wrote: > > I know gdb can source stepping the kernel. But without two machines, you > can not do it. Now I have only one machine and the system panic: > > db> trace > bqrelse(cxxx, cxxx, cxxx, cxxxx, cxxx) at bqrelse+0x25 > > is there a way to use these addresses to figure out which line or lines of > source are suspect to cause the panic? Thanks. -------------------------------------------- E-Mail: Alexander N. Kabaev Date: 05-Sep-2001 Time: 14:44:40 -------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 11:53:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0427637B409; Wed, 5 Sep 2001 11:53:41 -0700 (PDT) Received: from mindspring.com (dialup-209.247.139.244.Dial1.SanJose1.Level3.net [209.247.139.244]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA07748; Wed, 5 Sep 2001 11:53:26 -0700 (PDT) Message-ID: <3B9674D1.2AB00B6D@mindspring.com> Date: Wed, 05 Sep 2001 11:54:09 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Podlesny Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: auto relaying for subdomains -- why? References: <16615694707.20010905210719@morning.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Igor Podlesny wrote: > I noticed that some mailers (sendmail, postfix) in case they allow > relaying for somedomain.zone also allow relaying for > subdomain-of.somedomain.zone. > > I can accept this as reasonable behavior but would like to know how to > deny it! :) Also I wish to know what was the actual idea behind this? Sendmail does _not_ do this by default; you have to specifically allow it by adding entries to your M4 file from which you build your sendmail.cf. If I had to guess, I'd guess that you enabled the domain via a sendmail.cw file, rather than a virtusertable, or by setting yourself up as a promiscuous relay. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12: 8:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 2155537B405 for ; Wed, 5 Sep 2001 12:08:10 -0700 (PDT) Received: from mindspring.com (dialup-209.247.139.244.Dial1.SanJose1.Level3.net [209.247.139.244]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA25540; Wed, 5 Sep 2001 12:07:43 -0700 (PDT) Message-ID: <3B967827.F166E3A6@mindspring.com> Date: Wed, 05 Sep 2001 12:08:23 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra Cc: hackers@freebsd.org, roam@ringlet.net Subject: Re: local changes to CVS tree References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905142800.C633@ringworld.oblivion.bg> <200109051723.f85HNbl07385@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Polstra wrote: > CVS claims to support multiple vendor branches, but in practice it > doesn't work in any useful sense. There's at least one place in the > CVS sources where "the" vendor branch is hard-coded as 1.1.1. You > really don't want to use multiple vendor branches -- trust me. :-) > Use two repositories instead, or use perforce. I guess I'll ask the usual question: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? This would be incredibly useful for building a combined local source tree from multiple project's CVS repositories. It could be used by FreeBSD for a number of "contrib" things, as well... Just a "hint hint" to the Modula 3 programmers among us... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12: 8:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5F8D737B407 for ; Wed, 5 Sep 2001 12:08:19 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA24614; Wed, 5 Sep 2001 12:22:19 -0700 (PDT) Date: Wed, 5 Sep 2001 12:22:18 -0700 (PDT) From: Julian Elischer To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: kernel ddb help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG you can gdb -k mykernel /dev/mem and do list bqrelse+0x25 (I think) alternatively, in ddb you can do: x/iiiiiiiiiiiiiiiiiii bqrelse and work out what is wrong by reading the machine instructions WHen I have one machine I usually debug by running the new kernel within a VMWARE virtual machine. Using the nmdm driver you can run gdb in the main machine to debug it, all within one machine. (unfortunatly it doesn't help for debugging drivers because the virtual machine doesn't have acces to the real hardware). On Wed, 5 Sep 2001, Zhihui Zhang wrote: > > I know gdb can source stepping the kernel. But without two machines, you > can not do it. Now I have only one machine and the system panic: > > db> trace > bqrelse(cxxx, cxxx, cxxx, cxxxx, cxxx) at bqrelse+0x25 > > is there a way to use these addresses to figure out which line or lines of > source are suspect to cause the panic? Thanks. > > Regards, > > -Zhihui > > > 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 Sep 5 12:20:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 07BDF37B401 for ; Wed, 5 Sep 2001 12:20:10 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA05473; Wed, 5 Sep 2001 13:20:04 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA17159; Wed, 5 Sep 2001 13:20:02 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15254.31457.818766.916542@nomad.yogotech.com> Date: Wed, 5 Sep 2001 13:20:01 -0600 To: tlambert2@mindspring.com Cc: John Polstra , hackers@FreeBSD.ORG, roam@ringlet.net Subject: Re: local changes to CVS tree In-Reply-To: <3B967827.F166E3A6@mindspring.com> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905142800.C633@ringworld.oblivion.bg> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > CVS claims to support multiple vendor branches, but in practice it > > doesn't work in any useful sense. There's at least one place in the > > CVS sources where "the" vendor branch is hard-coded as 1.1.1. You > > really don't want to use multiple vendor branches -- trust me. :-) > > Use two repositories instead, or use perforce. > > I guess I'll ask the usual question: > > Any chance of getting CVSup to transfer from a remote repository > to a local vendor branch, instead of from a remote repository to > a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:23:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 179D637B405 for ; Wed, 5 Sep 2001 12:23:31 -0700 (PDT) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.4/8.11.4) with ESMTP id f85JLHg05509; Wed, 5 Sep 2001 15:21:17 -0400 (EDT) Date: Wed, 5 Sep 2001 15:20:01 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: kernel ddb help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Sep 2001, Julian Elischer wrote: > you can gdb -k mykernel /dev/mem > and do > list bqrelse+0x25 > (I think) > alternatively, > in ddb you can do: > > > x/iiiiiiiiiiiiiiiiiii bqrelse > > and work out what is wrong by reading the machine instructions > > > WHen I have one machine I usually debug by running the new kernel > within a VMWARE virtual machine. Using the nmdm driver > you can run gdb in the main machine to debug it, all within one machine. > (unfortunatly it doesn't help for debugging drivers because the virtual > machine doesn't have acces to the real hardware). I am interested in setting up this environment. Is there any help information out there? If not, can you give me a few guideline? I will try myself. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:26:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id A2EFC37B407 for ; Wed, 5 Sep 2001 12:26:53 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f85JPcg42402; Wed, 5 Sep 2001 12:25:38 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f85JPce08130; Wed, 5 Sep 2001 12:25:38 -0700 (PDT) (envelope-from jdp) Date: Wed, 5 Sep 2001 12:25:38 -0700 (PDT) Message-Id: <200109051925.f85JPce08130@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: nate@yogotech.com Subject: Re: local changes to CVS tree In-Reply-To: <15254.31457.818766.916542@nomad.yogotech.com> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> <15254.31457.818766.916542@nomad.yogotech.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <15254.31457.818766.916542@nomad.yogotech.com>, Nate Williams wrote: > > > > Any chance of getting CVSup to transfer from a remote repository > > to a local vendor branch, instead of from a remote repository to > > a local repository? > > The problem is that you aren't just transferring bits from the HEAD, but > from multiple active branches. As John already stated, CVS doesn't > handle multiple 'vendor' branches well (and in this case, the FreeBSD > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:31: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 41E2C37B408 for ; Wed, 5 Sep 2001 12:30:50 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA05913; Wed, 5 Sep 2001 13:30:48 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA17241; Wed, 5 Sep 2001 13:30:47 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15254.32102.836154.871291@nomad.yogotech.com> Date: Wed, 5 Sep 2001 13:30:46 -0600 To: John Polstra Cc: hackers@freebsd.org, nate@yogotech.com Subject: Re: local changes to CVS tree In-Reply-To: <200109051925.f85JPce08130@vashon.polstra.com> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> <15254.31457.818766.916542@nomad.yogotech.com> <200109051925.f85JPce08130@vashon.polstra.com> X-Mailer: VM 6.95 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Any chance of getting CVSup to transfer from a remote repository > > > to a local vendor branch, instead of from a remote repository to > > > a local repository? > > > > The problem is that you aren't just transferring bits from the HEAD, but > > from multiple active branches. As John already stated, CVS doesn't > > handle multiple 'vendor' branches well (and in this case, the FreeBSD > > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > > > CVS is simply not setup to do what you ask. :( > > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. So, you're saying that the person would choose the branch (which may be RELENG_4 *OR* HEAD). I can see how that would work for RELENG_4, but for the HEAD, many of the files on the HEAD in /usr/src/contrib are on vendor branches, which means it would be a *nightmare* to get that right (IMO). > I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. Agreed. Although, it may not be as useful to developers, who often have to track development in multiple branches (for MFC's). > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... *sigh* Let's hope it doesn't come down to that. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:35:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (d211.dhcp212-26.cybercable.fr [212.198.26.211]) by hub.freebsd.org (Postfix) with ESMTP id 8BFF437B403 for ; Wed, 5 Sep 2001 12:35:33 -0700 (PDT) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id VAA10015; Wed, 5 Sep 2001 21:33:23 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B967E23.185B6299@herbelot.com> Date: Wed, 05 Sep 2001 21:33:55 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: sos@freebsd.dk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? References: <200109050756.f857uQM18767@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, sos "Søren Schmidt" wrote: > [SNIP] > Anyhow, the problem at hand is more like bad chipsets, there is ALOT > of ATA chipsets thats not working right when used the way needed for > tagged queuing. That said, the IBM DTLA's series of drives are extremely is there some place where a "recommended" list of chipsets is compiled ? (my interest would be about oldies like 440LX/400BX - there may be some "known-bad" revision for these babies -, and the 762 North Bridge of the soon to be there SMP Athlon) Cheers (and keep up the ata) -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:39:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 1D9B837B407 for ; Wed, 5 Sep 2001 12:39:12 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f85Jd5g42517; Wed, 5 Sep 2001 12:39:05 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f85Jd4208229; Wed, 5 Sep 2001 12:39:04 -0700 (PDT) (envelope-from jdp) Date: Wed, 5 Sep 2001 12:39:04 -0700 (PDT) Message-Id: <200109051939.f85Jd4208229@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: nate@yogotech.com Subject: Re: local changes to CVS tree In-Reply-To: <15254.32102.836154.871291@nomad.yogotech.com> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <15254.31457.818766.916542@nomad.yogotech.com> <200109051925.f85JPce08130@vashon.polstra.com> <15254.32102.836154.871291@nomad.yogotech.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <15254.32102.836154.871291@nomad.yogotech.com>, Nate Williams wrote: > So, you're saying that the person would choose the branch (which may > be RELENG_4 *OR* HEAD). Yep. For instance, a company might have a product that's based on RELENG_4, but with some local mods. So FreeBSD-4.x is in effect that company's "vendor". > I can see how that would work for RELENG_4, but for the HEAD, many > of the files on the HEAD in /usr/src/contrib are on vendor branches, > which means it would be a *nightmare* to get that right (IMO). It would still work just the same. You're just checking out -current and importing it onto your own vendor branch. You don't know or care about FreeBSD's vendor branch. Of course (and this is one of the big complications), CVSup would have to map the version numbers somehow. Another big complication would be that at some point in the future a user would want to switch from being based on RELENG_4 to being based on RELENG_5. I have a feeling that could get tricky for CVSup to deal with. > Although, it may not be as useful to developers, who often have > to track development in multiple branches (for MFC's). Right, it would be pretty worthless for FreeBSD developers. > > Maybe if the economy gets worse ... > > *sigh* Let's hope it doesn't come down to that. Just looking for that silver lining. Mom would be so proud of me. :-) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:40:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id 1221737B414 for ; Wed, 5 Sep 2001 12:40:14 -0700 (PDT) Received: from mindspring.com (dialup-209.247.139.244.Dial1.SanJose1.Level3.net [209.247.139.244]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f85Je5b02955; Wed, 5 Sep 2001 12:40:06 -0700 (PDT) Message-ID: <3B967FC1.AEB592D9@mindspring.com> Date: Wed, 05 Sep 2001 12:40:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ullasan_Kottummal@kindlebanksys.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: Posix Threading References: <80256ABE.005390D9.00@smtp.kindlebanksys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ullasan_Kottummal@kindlebanksys.com wrote: > > Hi All, > I am trying to create threads under HP-UX 11 using POSIX threads library and > using the method pthread_create(...). > > But I don't know how can I create a thread in a suspended state. First the obligatory "off topic" humor: This is not the place to ask about HP-UX programming; you probably want the Hewlet-Compaqard user's mailing list... 8-p. -- You don't give us enough information about your application for us to tell you the correct approach to building it; you've started with a hammer ("initially suspended threads") and are ignoring other tools (e.g. "the jaws of life") in your search for a way to instance your hammer, under the theory that your problem is a nail (it might not be; you've given us no way to know). Probably switching to FreeBSD and the kqueue interface would better match your problem. Let's do some setup, and then guess at what you wanted to do, and give you several approaches to our satisfying our guesses... Short answer: You can't. The "suspended" state is an attribute of the thread that is controlled by the threads scheduler, and is not directly controllable by you. A thread is guaranteed to be suspended only when it is waiting on a mutex, condition variable, or blocking call (such as I/O). I suggest you rethink your design. If the intent is to get an immediate context switch back to yourself, you will need to create a mutex that can not be acquired by the newly created thread, and attempt to acquire it as the first thing you do. You can then immediately release it so as not to block other threads trying the same dirty trick. Note that there is not an explicit "yield", so you will have to do something like this to get a "yield" equivalent. Alternately, if the intent is to create threads so that they will be around when you need them, you would be better off delaying their creation until you need them. The expensive part of threads creation is _supposed_ to be the allocation of the stack; so if you keep a pool of preallocated stacks lying around for your use, you will get only a small startup latency. If the intent is to have "a pool of idle threads", ready to go when you get request traffic, and get around the latency, well, you'd do a lot better in the latency department if you went to a finite state automaton, instead of messing with threads. But if you insist, the best you are going to be able to get is use of a mutex, since a condition variable will result in a "thundering herd" problem. You will still have to eat the latency for the mutex trigger to the thread you give the work to, however (this is how I designed the work-to-do dispatcher in the Pathworks for VMS (NetWare) product for DEC and Novell). If the intent is a "horse race", where you create a bunch of threads, and then open the "starting gate" and have them all start going ``at once'', then you want a condition variable. I intentionally quoted ``at once'', since the concurrency will not be real without multiple CPUs and cooperation from the OS, it will be virtual -- just as if you were running multiple processes, instead of trying to use threads. This is an artifact of the scheduler, and varies from implementation to implementation. Note: I don't know what level of standards compliance the HP-UX 11 version of pthreads has achieved; some of the things described above are probably not going to be easy to achieve in downrev versions of the library. Last time I looked, the HP-UX version of pthreads was a Draft-4 version, not a Draft-10 or standard version, so you may be in more trouble than you originally thought; specifically, you will have a problem with creating a preinitialized mutex in a Draft-4 version of pthreads, so you will have to create the mutex (if you use one) first. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 12:52:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id BED8D37B40B for ; Wed, 5 Sep 2001 12:52:52 -0700 (PDT) Received: from mindspring.com (dialup-209.247.139.244.Dial1.SanJose1.Level3.net [209.247.139.244]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f85Jqgb03053; Wed, 5 Sep 2001 12:52:43 -0700 (PDT) Message-ID: <3B9682B6.E253B983@mindspring.com> Date: Wed, 05 Sep 2001 12:53:26 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: John Polstra , hackers@FreeBSD.ORG, roam@ringlet.net Subject: Re: local changes to CVS tree References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905142800.C633@ringworld.oblivion.bg> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> <15254.31457.818766.916542@nomad.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > I guess I'll ask the usual question: > > > > Any chance of getting CVSup to transfer from a remote repository > > to a local vendor branch, instead of from a remote repository to > > a local repository? > > The problem is that you aren't just transferring bits from the HEAD, but > from multiple active branches. As John already stated, CVS doesn't > handle multiple 'vendor' branches well (and in this case, the FreeBSD > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > CVS is simply not setup to do what you ask. :( I know how to make it do it, using a numeric tuple pair prefix to effectively force things onto a vendor branch; CVS will just "do the right thing" with the data: it's really CVSup, not CVS, which is the bottleneck. I've actually done this one on an experimental basis, by using CVSup to mirror the CVS repository, and then using scripts to hack the holy heck out of the mirror during a copy, which left me with a local repository containing only a skeleton and a vendor branch (with ID's up in the 5000's). It worked, but I got a cramp: the local copy was so expensive compared to an integrated approach, that it was not worth maintaining. It's just been 15 years or so since I did any Modula programming, and the Modula 3 compiler is a behemoth that I'd rather not have to slay to get real work done. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13: 1:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 25B2737B410 for ; Wed, 5 Sep 2001 13:01:12 -0700 (PDT) Received: from mindspring.com (dialup-209.247.139.244.Dial1.SanJose1.Level3.net [209.247.139.244]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA10638; Wed, 5 Sep 2001 13:01:06 -0700 (PDT) Message-ID: <3B9684AE.31C4FB9F@mindspring.com> Date: Wed, 05 Sep 2001 13:01:50 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra Cc: hackers@freebsd.org, nate@yogotech.com Subject: Re: local changes to CVS tree References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> <15254.31457.818766.916542@nomad.yogotech.com> <200109051925.f85JPce08130@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Polstra wrote: > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. Yes, precisely. People always complain that companies are gun-shy of -current; the inability to tag a "sufficiently stable" version is why most companies stay away from it. This means that most commercially funded work occurs on the -RELEASE/-STABLE branches, for fear of destabilizing their products. Everyone in FreeBSD-land always complains about this, even as they continue to make -current even less stable, and less likely to result in them getting funded help to work on it. So a lot of forward looking research takes a lot longer than it should to bear fruit (or wither, if it turns out to be a net loss). > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... I hear Hewlett-Compaqard is laying off 15,000, if that's any incentive... I guess a better question would be whether funding would help? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13: 8: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D420437B409 for ; Wed, 5 Sep 2001 13:08:04 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA25001; Wed, 5 Sep 2001 13:37:08 -0700 (PDT) Date: Wed, 5 Sep 2001 13:37:06 -0700 (PDT) From: Julian Elischer To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: kernel ddb/gdb help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Sep 2001, Zhihui Zhang wrote: > > > On Wed, 5 Sep 2001, Julian Elischer wrote: > > > > WHen I have one machine I usually debug by running the new kernel > > within a VMWARE virtual machine. Using the nmdm driver > > you can run gdb in the main machine to debug it, all within one machine. > > (unfortunatly it doesn't help for debugging drivers because the virtual > > machine doesn't have acces to the real hardware). > > I am interested in setting up this environment. Is there any help > information out there? If not, can you give me a few guideline? I will try > myself. > first you need to get vmware running on your machine. (use the vmware2 port) (I select host-only (non bridged) networking) then you boot and install FreeBSD on the machine. then in the virtual machine, set in the file /boot/device.hints the line: hints.sio.1.flags="0xc0" in the vmware config editor set com2 to type "device" and give it a device of /dev/nmdm0A then in the gdb config follow the instructions for remote debugging but use the device nmdm0B when the virtual machine enters the debugger (ddb) enter the word "gdb" to make it use the gdb stub then you will need to do a 's' to make it actually switch. In teh compile directory of the kernel on the main machine: enter gdb and set remote debugging mode. (I use the folloing .gdbinit file in the compile directory:) file kernel.debug set remotebaud 9600 target remote /dev/nmdmb1 It's also useful to set a serial console on com1 of the virtual machine so tha tyou can record and capture messages..... I sent a message outlining how to do all this to: freebsd-emulation@freebsd.org on Fri, 19 Jan 2001 Message ID: <3A68B649.A52AB05A@elischer.org> if you want to look at it in the archives. also there is a screenshot that probably has some hints on it at http://www.freebsd.org/~julian/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13:28:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 72F9537B403 for ; Wed, 5 Sep 2001 13:28:03 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA25045; Wed, 5 Sep 2001 13:41:20 -0700 (PDT) Date: Wed, 5 Sep 2001 13:41:19 -0700 (PDT) From: Julian Elischer To: John Polstra Cc: hackers@freebsd.org, nate@yogotech.com Subject: Re: local changes to CVS tree In-Reply-To: <200109051925.f85JPce08130@vashon.polstra.com> 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As a workaround, people could just gat the source each week and do an cvs import into the vendor branch via script.. (of course with doing it correctly you could have matching version numbers on the vendor branch) On Wed, 5 Sep 2001, John Polstra wrote: > In article <15254.31457.818766.916542@nomad.yogotech.com>, > Nate Williams wrote: > > >=20 > > > Any chance of getting CVSup to transfer from a remote repository > > > to a local vendor branch, instead of from a remote repository to > > > a local repository? > >=20 > > The problem is that you aren't just transferring bits from the HEAD, bu= t > > from multiple active branches. As John already stated, CVS doesn't > > handle multiple 'vendor' branches well (and in this case, the FreeBSD > > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > >=20 > > CVS is simply not setup to do what you ask. :( >=20 > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. >=20 > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... >=20 > John > --=20 > John Polstra jdp@polstra.= com > John D. Polstra & Co., Inc. Seattle, Washington = USA > "Disappointment is a good sign of basic intelligence." -- Ch=F6gyam Tr= ungpa >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13:31:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id C3D6F37B406 for ; Wed, 5 Sep 2001 13:31:35 -0700 (PDT) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.4/8.11.4) with ESMTP id f85KV5g02068; Wed, 5 Sep 2001 16:31:05 -0400 (EDT) Date: Wed, 5 Sep 2001 16:29:49 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@onyx To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: kernel ddb help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Your snapshot is cool and I have found your old mail regarding VMWARE. One more question: Is X-windows needed for this stuff? Thanks, -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13:34:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 918A637B403 for ; Wed, 5 Sep 2001 13:34:46 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f85KYdX25178; Wed, 5 Sep 2001 14:34:40 -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.11.3/8.11.4) with ESMTP id f85KYdh47743; Wed, 5 Sep 2001 14:34:39 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109052034.f85KYdh47743@harmony.village.org> To: tlambert2@mindspring.com Subject: Re: local changes to CVS tree Cc: John Polstra , hackers@FreeBSD.ORG, nate@yogotech.com In-reply-to: Your message of "Wed, 05 Sep 2001 13:01:50 PDT." <3B9684AE.31C4FB9F@mindspring.com> References: <3B9684AE.31C4FB9F@mindspring.com> <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <200109051723.f85HNbl07385@vashon.polstra.com> <3B967827.F166E3A6@mindspring.com> <15254.31457.818766.916542@nomad.yogotech.com> <200109051925.f85JPce08130@vashon.polstra.com> Date: Wed, 05 Sep 2001 14:34:39 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3B9684AE.31C4FB9F@mindspring.com> Terry Lambert writes: : Yes, precisely. People always complain that companies are : gun-shy of -current; the inability to tag a "sufficiently : stable" version is why most companies stay away from it. For what its worth, I did most of the pccard based work in -current, then switched to -stable for testing/deploying it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 13:36: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DE91F37B407 for ; Wed, 5 Sep 2001 13:35:53 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f85KZnX25193; Wed, 5 Sep 2001 14:35:49 -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.11.3/8.11.4) with ESMTP id f85KZnh47772; Wed, 5 Sep 2001 14:35:49 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109052035.f85KZnh47772@harmony.village.org> To: Julian Elischer Subject: Re: local changes to CVS tree Cc: John Polstra , hackers@FreeBSD.ORG, nate@yogotech.com In-reply-to: Your message of "Wed, 05 Sep 2001 13:41:19 PDT." References: Date: Wed, 05 Sep 2001 14:35:49 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message Julian Elischer writes: : As a workaround, people could just gat the source each week : and do an cvs import into the vendor branch via script.. : (of course with doing it correctly you could have matching version numbers : on the vendor branch) As someone who does lots of vendor branch imports of FreeBSD into cvs, I can tell you that automating it is fraught with dangers if you have any significant changes in your base tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 14:47:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 388DB37B406 for ; Wed, 5 Sep 2001 14:47:30 -0700 (PDT) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA10157; Wed, 5 Sep 2001 14:47:28 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3B967FC1.AEB592D9@mindspring.com> Date: Wed, 05 Sep 2001 14:47:24 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Posix Threading Cc: freebsd-hackers@FreeBSD.org, Ullasan_Kottummal@kindlebanksys.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05-Sep-01 Terry Lambert wrote: > Ullasan_Kottummal@kindlebanksys.com wrote: >> >> Hi All, >> I am trying to create threads under HP-UX 11 using POSIX threads library >> and >> using the method pthread_create(...). >> >> But I don't know how can I create a thread in a suspended state. > > First the obligatory "off topic" humor: > > This is not the place to ask about HP-UX programming; you > probably want the Hewlet-Compaqard user's mailing list... 8-p. > > -- > > You don't give us enough information about your application > for us to tell you the correct approach to building it; you've > started with a hammer ("initially suspended threads") and are > ignoring other tools (e.g. "the jaws of life") in your search > for a way to instance your hammer, under the theory that your > problem is a nail (it might not be; you've given us no way to > know). > > Probably switching to FreeBSD and the kqueue interface would > better match your problem. > > > Let's do some setup, and then guess at what you wanted to do, > and give you several approaches to our satisfying our guesses... > > > Short answer: You can't. The "suspended" state is an attribute > of the thread that is controlled by the threads scheduler, and > is not directly controllable by you. > > > A thread is guaranteed to be suspended only when it is waiting > on a mutex, condition variable, or blocking call (such as I/O). > > I suggest you rethink your design. > > > If the intent is to get an immediate context switch back to > yourself, you will need to create a mutex that can not be > acquired by the newly created thread, and attempt to acquire > it as the first thing you do. > > You can then immediately release it so as not to block other > threads trying the same dirty trick. Note that there is not > an explicit "yield", so you will have to do something like > this to get a "yield" equivalent. > > > Alternately, if the intent is to create threads so that they > will be around when you need them, you would be better off > delaying their creation until you need them. The expensive > part of threads creation is _supposed_ to be the allocation > of the stack; so if you keep a pool of preallocated stacks > lying around for your use, you will get only a small startup > latency. > > If the intent is to have "a pool of idle threads", ready to > go when you get request traffic, and get around the latency, > well, you'd do a lot better in the latency department if you > went to a finite state automaton, instead of messing with > threads. But if you insist, the best you are going to be > able to get is use of a mutex, since a condition variable will > result in a "thundering herd" problem. You will still have to > eat the latency for the mutex trigger to the thread you give > the work to, however (this is how I designed the work-to-do > dispatcher in the Pathworks for VMS (NetWare) product for DEC > and Novell). > > If the intent is a "horse race", where you create a bunch of > threads, and then open the "starting gate" and have them all > start going ``at once'', then you want a condition variable. I > intentionally quoted ``at once'', since the concurrency will > not be real without multiple CPUs and cooperation from the OS, > it will be virtual -- just as if you were running multiple > processes, instead of trying to use threads. This is an > artifact of the scheduler, and varies from implementation to > implementation. > > Note: I don't know what level of standards compliance the > HP-UX 11 version of pthreads has achieved; some of the things > described above are probably not going to be easy to achieve > in downrev versions of the library. Last time I looked, the > HP-UX version of pthreads was a Draft-4 version, not a Draft-10 > or standard version, so you may be in more trouble than you > originally thought; specifically, you will have a problem with > creating a preinitialized mutex in a Draft-4 version of pthreads, > so you will have to create the mutex (if you use one) first. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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 Sep 5 15:15:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id D1C7937B403; Wed, 5 Sep 2001 15:15:07 -0700 (PDT) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA25669; Wed, 5 Sep 2001 15:15:07 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 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, 05 Sep 2001 15:15:03 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: Re: Posix Threading Cc: Ullasan_Kottummal@kindlebanksys.com, freebsd-hackers@FreeBSD.org, Terry Lambert Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ I really hate it when my window manager gets stuck in a loop spinning while I'm composing a mail message and I forget to fix up the mail message. *sigh* ] > On 05-Sep-01 Terry Lambert wrote: >> Ullasan_Kottummal@kindlebanksys.com wrote: >>> >>> Hi All, >>> I am trying to create threads under HP-UX 11 using POSIX threads library >>> and >>> using the method pthread_create(...). >>> >>> But I don't know how can I create a thread in a suspended state. >> >> First the obligatory "off topic" humor: >> >> This is not the place to ask about HP-UX programming; you >> probably want the Hewlet-Compaqard user's mailing list... 8-p. >> >> -- >> >> If the intent is to have "a pool of idle threads", ready to >> go when you get request traffic, and get around the latency, >> well, you'd do a lot better in the latency department if you >> went to a finite state automaton, instead of messing with >> threads. But if you insist, the best you are going to be >> able to get is use of a mutex, since a condition variable will >> result in a "thundering herd" problem. You will still have to >> eat the latency for the mutex trigger to the thread you give >> the work to, however (this is how I designed the work-to-do >> dispatcher in the Pathworks for VMS (NetWare) product for DEC >> and Novell). Most of what you say is ok, but this is wrong. condition variables do not mandate using a wakeup all strategy. There is such a thing as 'signal' instead of 'broadcast', which only wakes up one thread. PTHREAD_COND_SIGNAL(3) FreeBSD Library Functions Manual PTHREAD_COND_SIGNAL(3) SYNOPSIS #include int pthread_cond_signal(pthread_cond_t *cond); DESCRIPTION The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/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 Sep 5 17:11:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 1FA0237B406 for ; Wed, 5 Sep 2001 17:11:09 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f860B1332052; Wed, 5 Sep 2001 17:11:01 -0700 (PDT) (envelope-from obrien) Date: Wed, 5 Sep 2001 17:11:00 -0700 From: "David O'Brien" To: Thierry Herbelot Cc: sos@freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? Message-ID: <20010905171100.B13337@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200109050756.f857uQM18767@freebsd.dk> <3B967E23.185B6299@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B967E23.185B6299@herbelot.com>; from thierry@herbelot.com on Wed, Sep 05, 2001 at 09:33:55PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > "known-bad" revision for these babies -, and the 762 North Bridge of the > soon to be there SMP Athlon) "Soon to be there"?? Hum... I'm typing to you from one. -- -- David (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 Sep 5 17:43:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 361DB37B40D; Wed, 5 Sep 2001 17:43:28 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f860hSx04662; Wed, 5 Sep 2001 17:43:28 -0700 Date: Wed, 5 Sep 2001 17:43:27 -0700 From: Brooks Davis To: hackers@freebsd.org Cc: msmith@freebsd.org Subject: proposed change to pci_pci.c Message-ID: <20010905174327.A3591@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to propose committing the following change which adds a new undocumented option in the spirit of PCI_ENABLE_IO_MODES. The new option (PCI_ALLOW_UNSUPPORTED_IO_RANGE) allows me to boot my old HP Omnibook 4150 while docked. Since I've seen a couple other people need this fix, I figure it would be more useful if they just had to add a line to their kernel config instead of editing the source files. Any objections? -- Brooks Index: pci_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v retrieving revision 1.3 diff -u -r1.3 pci_pci.c --- pci_pci.c 13 Dec 2000 01:25:11 -0000 1.3 +++ pci_pci.c 7 Jun 2001 17:31:50 -0000 @@ -286,7 +286,9 @@ " (decoding 0x%x-0x%x)\n", device_get_name(child), device_get_unit(child), start, end, sc->iobase, sc->iolimit); +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE return(NULL); +#endif } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded I/O range 0x%lx-0x= %lx\n", @@ -306,7 +308,9 @@ " (decoding 0x%x-0x%x, 0x%x-0x%x)\n", device_get_name(child), device_get_unit(child), start, end, sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit); +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE return(NULL); +#endif } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded memory range 0x%lx= -0x%lx\n", --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7lsauXY6L6fI4GtQRAlYkAJ9BS8yO/HeRrVEmbp0HRZLy0VX/zQCfcwqI 1TsAzTG5bFfK4NHTz7Kk+O8= =Nu3h -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 18:31: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 623CA37B403 for ; Wed, 5 Sep 2001 18:30:58 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f861bSO05433; Wed, 5 Sep 2001 18:37:28 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200109060137.f861bSO05433@mass.dis.org> To: Brooks Davis Cc: hackers@freebsd.org Subject: Re: proposed change to pci_pci.c In-Reply-To: Message from Brooks Davis of "Wed, 05 Sep 2001 17:43:27 PDT." <20010905174327.A3591@Odin.AC.HMC.Edu> Date: Wed, 05 Sep 2001 18:37:28 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd be OK with this being done as a hack for now. I think the bridge code needs to be a bit kinder about allowing "stupid" things to be done if they're set up by the BIOS. > I'd like to propose committing the following change which adds a new > undocumented option in the spirit of PCI_ENABLE_IO_MODES. The new option > (PCI_ALLOW_UNSUPPORTED_IO_RANGE) allows me to boot my old HP Omnibook > 4150 while docked. Since I've seen a couple other people need this fix, > I figure it would be more useful if they just had to add a line to their > kernel config instead of editing the source files. Any objections? > > -- Brooks > > Index: pci_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v > retrieving revision 1.3 > diff -u -r1.3 pci_pci.c > --- pci_pci.c 13 Dec 2000 01:25:11 -0000 1.3 > +++ pci_pci.c 7 Jun 2001 17:31:50 -0000 > @@ -286,7 +286,9 @@ > " (decoding 0x%x-0x%x)\n", > device_get_name(child), device_get_unit(child), start, end, > sc->iobase, sc->iolimit); > +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE > return(NULL); > +#endif > } > if (bootverbose) > device_printf(sc->dev, "device %s%d requested decoded I/O range 0x%lx-0x= > %lx\n", > @@ -306,7 +308,9 @@ > " (decoding 0x%x-0x%x, 0x%x-0x%x)\n", > device_get_name(child), device_get_unit(child), start, end, > sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit); > +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE > return(NULL); > +#endif > } > if (bootverbose) > device_printf(sc->dev, "device %s%d requested decoded memory range 0x%lx= > -0x%lx\n", > > --=20 > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > > --ZGiS0Q5IWpPtfppv > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7lsauXY6L6fI4GtQRAlYkAJ9BS8yO/HeRrVEmbp0HRZLy0VX/zQCfcwqI > 1TsAzTG5bFfK4NHTz7Kk+O8= > =Nu3h > -----END PGP SIGNATURE----- > > --ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 18:36: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id F2F5F37B405 for ; Wed, 5 Sep 2001 18:35:16 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f861ZGI68787 for hackers@freebsd.org; Wed, 5 Sep 2001 18:35:16 -0700 (PDT) (envelope-from obrien) Date: Wed, 5 Sep 2001 18:35:16 -0700 From: "David O'Brien" To: hackers@freebsd.org Subject: post 2.95.3 patches to test Message-ID: <20010905183516.A68720@dragon.nuxi.com> Reply-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, This patch has the "official" GCC 2.95 fixes for sjlj exceptions. As you may know, the ones we have in our tree are the sjlj changes that were in 2.95.3.test3, but removed for 2.95.3.test4. I would like to apply this patch to -current and then -stable afterwards. I have one good report, from a very good FreeBSD GCC tester. But before I commit it, I would not mind hearing any one else's experiences with it. Replying to the list so all can see is preferred. -- -- David (obrien@FreeBSD.org) Index: ChangeLog =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/ChangeLog,v retrieving revision 1.1.1.12 diff -u -r1.1.1.12 ChangeLog --- ChangeLog 2001/03/19 19:46:16 1.1.1.12 +++ ChangeLog 2001/08/30 21:05:19 @@ -1,3 +1,160 @@ +2001-08-29 David O'Brien + + * config/alpha/crtbegin.asm: The normal calling convention for alpha is + to re-initialize gp using 'ldgp gp,0(ra)' after a jsr instruction. + +2001-06-19 Bernd Schmidt + + * regmove.c (optimize_reg_copy_3): Do nothing if previous insn + carries a REG_EQUIV note. If it carries REG_EQUAL, delete the + note. + +2001-05-22 Bernd Schmidt + + * sparc.md (movsf, movdf): Allow constant to integer reg moves. + (movsf, movdf splitters): Always split if there's an alignment + problem. + +2001-05-22 David Edelsohn + + * rs6000.md (movsfcc,movdfcc): Remove NE case. + +2001-05-17 Bernd Schmidt + + * function.c: Small formatting change to prevent compilation errors + on broken hpux systems. + + * expr.c (protect_from_queue): Protect against subsequent calls to + emit_queue. + (expand_expr, case ADDR_EXPR): Prevent protect_from_queue from being + too clever. + +2001-04-06 Bernd Schmidt + + 2000-10-17 Franz Sirl + * function.c (locate_and_pad_parm): Don't align stack unconditionally. + + Thu Oct 28 10:20:02 1999 Geoffrey Keating + * config/rs6000/rs6000.md (movsf): Don't convert a SUBREG + of the function return register into a plain REG until + after function inlining is done. + +2001-04-04 Bernd Schmidt + + Fri Nov 5 10:07:25 1999 Nick Clifton + * function.c (is_addressof): New function. Returns true if + the given piece of RTL is an ADDRESSOF. + (purge_addressof_1): Make boolean. Return false if the + ADDRESSOFs could not be purged. + (purge_addressof): If ADDRESSOFs could not be purged from the + notes attached to an insn, remove the offending note(s), + unless they are attached to a libcall. + +2001-04-03 Bernd Schmidt + + 2001-03-16 Jakub Jelinek + * crtstuff.c (init_dummy): Use CRT_END_INIT_DUMMY if defined. + Remove ia32 linux PIC kludge and move it... + * config/i386/linux.h (CRT_END_INIT_DUMMY): ...here. + + * loop.c (combine_movables): Restrict combinations of constants with + different modes so that we don't introduce SUBREGs into memory + addresses. + + 2001-02-02 Philip Blundell + * arm/linux-elf.h (MAKE_DECL_ONE_ONLY, UNIQUE_SECTION_P): Define. + (UNIQUE_SECTION): Define. + + Wed Aug 25 15:27:22 1999 Gavin Romig-Koch + * combine.c (nonzero_bits) : Allow single-ly set registers to be + anywere in the function only if they are pseudos and set before + being used (not live at the start of the function). + (num_sign_bit_copies) : Same. + (get_last_value_validate) : Same. + (get_last_value) : Same. + + Fri Mar 3 12:49:28 2000 J"orn Rennecke + * reload1.c (reload_combine_note_use): Handle return register USEs. + REG case: Handle multi-hard-register hard regs. + +2001-03-30 Bernd Schmidt + + * jump.c (delete_barrier_successors): Fix error in last change. + + * reload1.c (delete_output_reload): Call eliminate_regs on substed. + (reload_as_needed): Call update_eliminable_offsets a bit later. + + * final.c (cleanup_subreg_operands): Also clean up inside MEMs. + + Mon Oct 4 02:31:20 1999 Mark Mitchell + * mips.md: Define conditional move patterns for floating point + operands and DI mode conditions. + + 2000-11-25 Jakub Jelinek + * config/sparc/sparc.md (muldi3_v8plus): Remove H constraint. + Handle CONST_INT as second argument. + +2001-03-28 Bernd Schmidt + + * flow.c (propagate_block): When trying to delete a case vector, cope + if its label has LABEL_PRESERVE_P set. + * jump.c (jump_optimize_1): Move call to delete_barrier_successors to + a point where JUMP_LABELS and LABEL_NUSES are set up properly. + (delete_barrier_successors): If deleting a table jump, delete the case + vector as well. + * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P + so it won't get deleted. + +Tue Mar 20 18:31:48 2001 Kaveh R. Ghazi + + 1999-11-30 Kaveh R. Ghazi + * c-lex.c (yylex): With -Wtraditional, when the ANSI type of an + integer constant does not match the traditional type, limit the + warnings to cases where the base of the type is ten. + + * invoke.texi (-Wtraditional): Document it. + +2001-03-20 David O'Brien + + from 2000-07-12 Zack Weinberg + * final.c (profile_function): Do not emit profile counters in + the data section, if NO_PROFILE_COUNTERS is defined. + * tm.texi: Document NO_PROFILE_COUNTERS. Update doc for + FUNCTION_PROFILER. + + from 2000-10-02 David O'Brien + * config/i386/freebsd.h (NO_PROFILE_COUNTERS): Define. + +2001-03-19 Bernd Schmidt + + * version.c: Bump. + + 2000-01-18 Martin v. Löwis + * c-parse.in (SAVE_WARN_FLAGS): Create an INTEGER_CST. + (RESTORE_WARN_FLAGS): Unpack it. + Change semantic type of extension to ttype. + * c-common.c (split_specs_attrs): Expect an INTEGER_CST. + * c-parse.y, c-parse.c, objc/objc-parse.y, + objc/objc-parse.c: Regenerate. + + Wed Sep 1 09:12:02 1999 Jim Kingdon + * c-parse.in: save and restore warn_pointer_arith on __extension__ + along with pedantic. + (SAVE_WARN_FLAGS, RESTORE_WARN_FLAGS): Added. + Set the type of extension to itype rather than $1 kludge. + * extend.texi (Alternate Keywords): Adjust documentation. + + Bring back the sjlj eh fixes. + * expr.c (expand_builtin_setjmp_setup): New. + (expand_builtin_setjmp_receiver): New. + (expand_builtin_setjmp): Split out _setup and _receiver functions. + Move argument parsing in from ... + (expand_builtin): ... here. + * except.c (receive_exception_label): Branch around receiver + unless new-style exceptions. Call expand_builtin_setjmp_receiver. + (start_dynamic_handler): Call expand_builtin_setjmp_setup. + * expr.h: Update builtin setjmp decls. + Fri Mar 16 12:46:19 GMT 2001 Bernd Schmidt (bernds@redhat.com) * gcc-2.95.3 Released. Index: c-common.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/c-common.c,v retrieving revision 1.12 diff -u -r1.12 c-common.c --- c-common.c 2001/05/25 19:00:07 1.12 +++ c-common.c 2001/08/30 21:05:19 @@ -983,6 +983,15 @@ { tree t, s, a, next, specs, attrs; + /* This can happen after an __extension__ in pedantic mode. */ + if (specs_attrs != NULL_TREE + && TREE_CODE (specs_attrs) == INTEGER_CST) + { + *declspecs = NULL_TREE; + *prefix_attributes = NULL_TREE; + return; + } + /* This can happen in c++ (eg: decl: typespec initdecls ';'). */ if (specs_attrs != NULL_TREE && TREE_CODE (specs_attrs) != TREE_LIST) Index: c-lex.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/c-lex.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 c-lex.c --- c-lex.c 1999/10/16 06:01:50 1.1.1.3 +++ c-lex.c 2001/08/30 21:05:19 @@ -1812,7 +1812,11 @@ type = flag_traditional ? traditional_type : ansi_type; - if (warn_traditional && traditional_type != ansi_type) + /* We assume that constants specified in a non-decimal + base are bit patterns, and that the programmer really + meant what they wrote. */ + if (warn_traditional && base == 10 + && traditional_type != ansi_type) { if (TYPE_PRECISION (traditional_type) != TYPE_PRECISION (ansi_type)) Index: c-parse.in =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/c-parse.in,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 c-parse.in --- c-parse.in 1999/10/16 06:01:51 1.1.1.3 +++ c-parse.in 2001/08/30 21:05:20 @@ -186,7 +186,7 @@ %type init maybeasm %type asm_operands nonnull_asm_operands asm_operand asm_clobbers %type maybe_attribute attributes attribute attribute_list attrib -%type any_word +%type any_word extension %type compstmt @@ -247,6 +247,17 @@ /* 1 if we explained undeclared var errors. */ static int undeclared_variable_notice; +/* For __extension__, save/restore the warning flags which are + controlled by __extension__. */ +#define SAVE_WARN_FLAGS() \ + build_int_2 (pedantic | (warn_pointer_arith << 1), 0) +#define RESTORE_WARN_FLAGS(tval) \ + do { \ + int val = TREE_INT_CST_LOW (tval); \ + pedantic = val & 1; \ + warn_pointer_arith = (val >> 1) & 1; \ + } while (0) + ifobjc /* Objective-C specific information */ @@ -307,7 +318,7 @@ else error ("argument of `asm' is not a constant string"); } | extension extdef - { pedantic = $1; } + { RESTORE_WARN_FLAGS ($1); } ; datadef: @@ -448,7 +459,7 @@ /* __extension__ turns off -pedantic for following primary. */ | extension cast_expr %prec UNARY { $$ = $2; - pedantic = $1; } + RESTORE_WARN_FLAGS ($1); } | unop cast_expr %prec UNARY { $$ = build_unary_op ($1, $2, 0); overflow_warning ($$); } @@ -1015,7 +1026,7 @@ | declmods ';' { pedwarn ("empty declaration"); } | extension decl - { pedantic = $1; } + { RESTORE_WARN_FLAGS ($1); } ; /* Declspecs which contain at least one type specifier or typedef name. @@ -1614,7 +1625,7 @@ { $$ = NULL_TREE; } | extension component_decl { $$ = $2; - pedantic = $1; } + RESTORE_WARN_FLAGS ($1); } ; components: @@ -2426,8 +2437,9 @@ extension: EXTENSION - { $$ = pedantic; - pedantic = 0; } + { $$ = SAVE_WARN_FLAGS(); + pedantic = 0; + warn_pointer_arith = 0; } ; ifobjc Index: combine.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/combine.c,v retrieving revision 1.1.1.6 diff -u -r1.1.1.6 combine.c --- combine.c 2001/02/17 08:35:07 1.1.1.6 +++ combine.c 2001/08/30 21:05:20 @@ -7580,8 +7580,11 @@ if (reg_last_set_value[REGNO (x)] != 0 && reg_last_set_mode[REGNO (x)] == mode - && (REG_N_SETS (REGNO (x)) == 1 - || reg_last_set_label[REGNO (x)] == label_tick) + && (reg_last_set_label[REGNO (x)] == label_tick + || (REGNO (x) >= FIRST_PSEUDO_REGISTER + && REG_N_SETS (REGNO (x)) == 1 + && ! REGNO_REG_SET_P (BASIC_BLOCK (0)->global_live_at_start, + REGNO (x)))) && INSN_CUID (reg_last_set[REGNO (x)]) < subst_low_cuid) return reg_last_set_nonzero_bits[REGNO (x)]; @@ -7970,8 +7973,11 @@ if (reg_last_set_value[REGNO (x)] != 0 && reg_last_set_mode[REGNO (x)] == mode - && (REG_N_SETS (REGNO (x)) == 1 - || reg_last_set_label[REGNO (x)] == label_tick) + && (reg_last_set_label[REGNO (x)] == label_tick + || (REGNO (x) >= FIRST_PSEUDO_REGISTER + && REG_N_SETS (REGNO (x)) == 1 + && ! REGNO_REG_SET_P (BASIC_BLOCK (0)->global_live_at_start, + REGNO (x)))) && INSN_CUID (reg_last_set[REGNO (x)]) < subst_low_cuid) return reg_last_set_sign_bit_copies[REGNO (x)]; @@ -10819,9 +10825,11 @@ for (j = regno; j < endregno; j++) if (reg_last_set_invalid[j] - /* If this is a pseudo-register that was only set once, it is - always valid. */ - || (! (regno >= FIRST_PSEUDO_REGISTER && REG_N_SETS (regno) == 1) + /* If this is a pseudo-register that was only set once and not + live at the beginning of the function, it is always valid. */ + || (! (regno >= FIRST_PSEUDO_REGISTER + && REG_N_SETS (regno) == 1 + && ! REGNO_REG_SET_P (BASIC_BLOCK (0)->global_live_at_start, regno)) && reg_last_set_label[j] > tick)) { if (replace) @@ -10880,12 +10888,21 @@ regno = REGNO (x); value = reg_last_set_value[regno]; - /* If we don't have a value or if it isn't for this basic block, - return 0. */ + /* If we don't have a value, or if it isn't for this basic block and + it's either a hard register, set more than once, or it's a live + at the beginning of the function, return 0. + + Because if it's not live at the beginnning of the function then the reg + is always set before being used (is never used without being set). + And, if it's set only once, and it's always set before use, then all + uses must have the same last value, even if it's not from this basic + block. */ if (value == 0 - || (REG_N_SETS (regno) != 1 - && reg_last_set_label[regno] != label_tick)) + || (reg_last_set_label[regno] != label_tick + && (regno < FIRST_PSEUDO_REGISTER + || REG_N_SETS (regno) != 1 + || REGNO_REG_SET_P (BASIC_BLOCK (0)->global_live_at_start, regno)))) return 0; /* If the value was set in a later insn than the ones we are processing, Index: crtstuff.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/crtstuff.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 crtstuff.c --- crtstuff.c 1999/10/16 06:03:46 1.1.1.3 +++ crtstuff.c 2001/08/30 21:05:31 @@ -380,19 +380,8 @@ #endif asm (TEXT_SECTION_ASM_OP); -/* This is a kludge. The i386 GNU/Linux dynamic linker needs ___brk_addr, - __environ and atexit (). We have to make sure they are in the .dynsym - section. We accomplish it by making a dummy call here. This - code is never reached. */ - -#if defined(__linux__) && defined(__PIC__) && defined(__i386__) - { - extern void *___brk_addr; - extern char **__environ; - - ___brk_addr = __environ; - atexit (); - } +#ifdef CRT_END_INIT_DUMMY + CRT_END_INIT_DUMMY; #endif } Index: cse.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/cse.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 cse.c --- cse.c 2001/02/17 08:35:14 1.1.1.7 +++ cse.c 2001/08/30 21:05:31 @@ -695,8 +695,6 @@ static struct cse_reg_info* get_cse_reg_info PROTO((int)); static void free_cse_reg_info PROTO((splay_tree_value)); static void flush_hash_table PROTO((void)); - -extern int rtx_equal_function_value_matters; /* Dump the expressions in the equivalence class indicated by CLASSP. This function is used only for debugging. */ Index: except.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/except.c,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 except.c --- except.c 2001/03/24 01:58:31 1.1.1.5 +++ except.c 2001/08/30 21:05:32 @@ -733,20 +733,20 @@ } emit_label (handler_label); - + if (! exceptions_via_longjmp) { #ifdef HAVE_exception_receiver if (HAVE_exception_receiver) - emit_insn (gen_exception_receiver ()); + emit_insn (gen_exception_receiver ()); else #endif #ifdef HAVE_nonlocal_goto_receiver if (HAVE_nonlocal_goto_receiver) - emit_insn (gen_nonlocal_goto_receiver ()); + emit_insn (gen_nonlocal_goto_receiver ()); else #endif - { /* Nothing */ } + { /* Nothing */ } } else { Index: expr.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/expr.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 expr.c --- expr.c 2001/03/24 01:58:30 1.1.1.8 +++ expr.c 2001/08/30 21:05:32 @@ -450,6 +450,9 @@ QUEUED_INSN (y)); return temp; } + /* Copy the address into a pseudo, so that the returned value + remains correct across calls to emit_queue. */ + XEXP (new, 0) = copy_to_reg (XEXP (new, 0)); return new; } /* Otherwise, recursively protect the subexpressions of all @@ -476,9 +479,11 @@ } return x; } - /* If the increment has not happened, use the variable itself. */ + /* If the increment has not happened, use the variable itself. Copy it + into a new pseudo so that the value remains correct across calls to + emit_queue. */ if (QUEUED_INSN (x) == 0) - return QUEUED_VAR (x); + return copy_to_reg (QUEUED_VAR (x)); /* If the increment has happened and a pre-increment copy exists, use that copy. */ if (QUEUED_COPY (x) != 0) @@ -8077,7 +8082,9 @@ if (ignore) return op0; - op0 = protect_from_queue (op0, 0); + /* Pass 1 for MODIFY, so that protect_from_queue doesn't get + clever and returns a REG when given a MEM. */ + op0 = protect_from_queue (op0, 1); /* We would like the object in memory. If it is a constant, we can have it be statically allocated into memory. For @@ -8603,7 +8610,7 @@ /* Construct the trailing part of a __builtin_setjmp call. This is used directly by sjlj exception handling code. */ - + void expand_builtin_setjmp_receiver (receiver_label) rtx receiver_label ATTRIBUTE_UNUSED; @@ -8726,7 +8733,7 @@ current_function_has_nonlocal_label = 1; nonlocal_goto_handler_labels = gen_rtx_EXPR_LIST (VOIDmode, next_lab, nonlocal_goto_handler_labels); - + return target; } Index: final.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/final.c,v retrieving revision 1.9 diff -u -r1.9 final.c --- final.c 2001/03/19 20:32:45 1.9 +++ final.c 2001/08/30 21:07:13 @@ -3055,7 +3055,8 @@ if (GET_CODE (recog_operand[i]) == SUBREG) recog_operand[i] = alter_subreg (recog_operand[i]); else if (GET_CODE (recog_operand[i]) == PLUS - || GET_CODE (recog_operand[i]) == MULT) + || GET_CODE (recog_operand[i]) == MULT + || GET_CODE (recog_operand[i]) == MEM) recog_operand[i] = walk_alter_subreg (recog_operand[i]); } @@ -3064,7 +3065,8 @@ if (GET_CODE (*recog_dup_loc[i]) == SUBREG) *recog_dup_loc[i] = alter_subreg (*recog_dup_loc[i]); else if (GET_CODE (*recog_dup_loc[i]) == PLUS - || GET_CODE (*recog_dup_loc[i]) == MULT) + || GET_CODE (*recog_dup_loc[i]) == MULT + || GET_CODE (*recog_dup_loc[i]) == MEM) *recog_dup_loc[i] = walk_alter_subreg (*recog_dup_loc[i]); } } Index: flow.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/flow.c,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 flow.c --- flow.c 2001/02/17 08:35:29 1.1.1.5 +++ flow.c 2001/08/30 21:05:38 @@ -2744,15 +2744,23 @@ { if (REG_NOTE_KIND (inote) == REG_LABEL) { + int n_forced; rtx label = XEXP (inote, 0); rtx next; LABEL_NUSES (label)--; + /* The label may be forced if it has been put in the + constant pool. We can't delete it in this case, but + we still must discard a jump table following it. */ + n_forced = 0; + if (LABEL_PRESERVE_P (label)) + n_forced++; + /* If this label was attached to an ADDR_VEC, it's safe to delete the ADDR_VEC. In fact, it's pretty much mandatory to delete it, because the ADDR_VEC may be referencing labels that no longer exist. */ - if (LABEL_NUSES (label) == 0 + if (LABEL_NUSES (label) == n_forced && (next = next_nonnote_insn (label)) != NULL && GET_CODE (next) == JUMP_INSN && (GET_CODE (PATTERN (next)) == ADDR_VEC Index: function.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/function.c,v retrieving revision 1.8 diff -u -r1.8 function.c --- function.c 2001/02/17 09:03:40 1.8 +++ function.c 2001/08/30 21:05:38 @@ -515,8 +515,9 @@ static int contains PROTO((rtx, int *)); #endif /* HAVE_prologue || HAVE_epilogue */ static void put_addressof_into_stack PROTO((rtx, struct hash_table *)); -static void purge_addressof_1 PROTO((rtx *, rtx, int, int, +static boolean purge_addressof_1 PROTO((rtx *, rtx, int, int, struct hash_table *)); +static int is_addressof PROTO ((rtx *, void *)); static struct hash_entry *insns_for_mem_newfunc PROTO((struct hash_entry *, struct hash_table *, hash_table_key)); @@ -3057,9 +3058,10 @@ /* Helper function for purge_addressof. See if the rtx expression at *LOC in INSN needs to be changed. If FORCE, always put any ADDRESSOFs into - the stack. */ + the stack. If the function returns FALSE then the replacement could not + be made. */ -static void +static boolean purge_addressof_1 (loc, insn, force, store, ht) rtx *loc; rtx insn; @@ -3070,13 +3072,14 @@ RTX_CODE code; int i, j; char *fmt; + boolean result = true; /* Re-start here to avoid recursion in common cases. */ restart: x = *loc; if (x == 0) - return; + return true; code = GET_CODE (x); @@ -3089,7 +3092,7 @@ if (validate_change (insn, loc, sub, 0) || validate_replace_rtx (x, sub, insn)) - return; + return true; start_sequence (); sub = force_operand (sub, NULL_RTX); @@ -3100,7 +3103,7 @@ insns = gen_sequence (); end_sequence (); emit_insn_before (insns, insn); - return; + return true; } else if (code == MEM && GET_CODE (XEXP (x, 0)) == ADDRESSOF && ! force) { @@ -3119,7 +3122,7 @@ && (MEM_VOLATILE_P (x) || GET_MODE (x) == BLKmode)) { put_addressof_into_stack (XEXP (x, 0), ht); - return; + return true; } else if (GET_CODE (sub) == REG && GET_MODE (x) != GET_MODE (sub)) { @@ -3138,7 +3141,7 @@ if (rtx_equal_p (x, XEXP (tem, 0))) { *loc = XEXP (XEXP (tem, 1), 0); - return; + return true; } /* See comment for purge_addressof_replacements. */ @@ -3178,11 +3181,17 @@ z = gen_lowpart (GET_MODE (x), z); *loc = z; - return; + return true; } - /* There should always be such a replacement. */ - abort (); + /* Sometimes we may not be able to find the replacement. For + example when the original insn was a MEM in a wider mode, + and the note is part of a sign extension of a narrowed + version of that MEM. Gcc testcase compile/990829-1.c can + generate an example of this siutation. Rather than complain + we return false, which will prompt our caller to remove the + offending note. */ + return false; } size_x = GET_MODE_BITSIZE (GET_MODE (x)); @@ -3268,7 +3277,7 @@ purge_bitfield_addressof_replacements)); /* We replaced with a reg -- all done. */ - return; + return true; } } else if (validate_change (insn, loc, sub, 0)) @@ -3285,13 +3294,13 @@ if (rtx_equal_p (XEXP (x, 0), XEXP (tem, 0))) { XEXP (XEXP (tem, 1), 0) = sub; - return; + return true; } purge_addressof_replacements = gen_rtx (EXPR_LIST, VOIDmode, XEXP (x, 0), gen_rtx_EXPR_LIST (VOIDmode, sub, purge_addressof_replacements)); - return; + return true; } goto restart; } @@ -3301,13 +3310,13 @@ else if (code == ADDRESSOF) { put_addressof_into_stack (x, ht); - return; + return true; } else if (code == SET) { - purge_addressof_1 (&SET_DEST (x), insn, force, 1, ht); - purge_addressof_1 (&SET_SRC (x), insn, force, 0, ht); - return; + result = purge_addressof_1 (&SET_DEST (x), insn, force, 1, ht); + result &= purge_addressof_1 (&SET_SRC (x), insn, force, 0, ht); + return result; } /* Scan all subexpressions. */ @@ -3315,11 +3324,13 @@ for (i = 0; i < GET_RTX_LENGTH (code); i++, fmt++) { if (*fmt == 'e') - purge_addressof_1 (&XEXP (x, i), insn, force, 0, ht); + result &= purge_addressof_1 (&XEXP (x, i), insn, force, 0, ht); else if (*fmt == 'E') for (j = 0; j < XVECLEN (x, i); j++) - purge_addressof_1 (&XVECEXP (x, i, j), insn, force, 0, ht); + result &= purge_addressof_1 (&XVECEXP (x, i, j), insn, force, 0, ht); } + + return result; } /* Return a new hash table entry in HT. */ @@ -3439,6 +3450,16 @@ } } +/* Helper function for purge_addressof called through for_each_rtx. + Returns true iff the rtl is an ADDRESSOF. */ +static int +is_addressof (rtl, data) + rtx * rtl; + void * data ATTRIBUTE_UNUSED; +{ + return GET_CODE (* rtl) == ADDRESSOF; +} + /* Eliminate all occurrences of ADDRESSOF from INSNS. Elide any remaining (MEM (ADDRESSOF)) patterns, and force any needed registers into the stack. */ @@ -3467,9 +3488,30 @@ if (GET_CODE (insn) == INSN || GET_CODE (insn) == JUMP_INSN || GET_CODE (insn) == CALL_INSN) { - purge_addressof_1 (&PATTERN (insn), insn, - asm_noperands (PATTERN (insn)) > 0, 0, &ht); - purge_addressof_1 (®_NOTES (insn), NULL_RTX, 0, 0, &ht); + if (! purge_addressof_1 (&PATTERN (insn), insn, + asm_noperands (PATTERN (insn)) > 0, 0, &ht)) + /* If we could not replace the ADDRESSOFs in the insn, + something is wrong. */ + abort (); + + if (! purge_addressof_1 (®_NOTES (insn), NULL_RTX, 0, 0, &ht)) + { + /* If we could not replace the ADDRESSOFs in the insn's notes, + we can just remove the offending notes instead. */ + rtx note; + + for (note = REG_NOTES (insn); note; note = XEXP (note, 1)) + { + /* If we find a REG_RETVAL note then the insn is a libcall. + Such insns must have REG_EQUAL notes as well, in order + for later passes of the compiler to work. So it is not + safe to delete the notes here, and instead we abort. */ + if (REG_NOTE_KIND (note) == REG_RETVAL) + abort (); + if (for_each_rtx (& note, is_addressof, NULL)) + remove_note (insn, note); + } + } } /* Clean up. */ @@ -5294,7 +5336,18 @@ - offset_ptr->constant); } #else /* !ARGS_GROW_DOWNWARD */ - pad_to_arg_alignment (initial_offset_ptr, boundary); + if (!in_regs +#ifdef REG_PARM_STACK_SPACE + || REG_PARM_STACK_SPACE (fndecl) > 0 +#else + /* For the gcc-2_95-branch we want to make sure not to break something + on platforms which pass argument in registers but don't define + REG_PARM_STACK_SPACE. So we force the original behaviour here. */ + || 1 +#endif + ) + pad_to_arg_alignment (initial_offset_ptr, boundary); + *offset_ptr = *initial_offset_ptr; #ifdef PUSH_ROUNDING @@ -6936,7 +6989,7 @@ } } } - #endif +#endif } /* Reposition the prologue-end and epilogue-begin notes after instruction Index: invoke.texi =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/invoke.texi,v retrieving revision 1.8 diff -u -r1.8 invoke.texi --- invoke.texi 2001/02/17 09:04:50 1.8 +++ invoke.texi 2001/08/30 21:05:38 @@ -1698,6 +1698,12 @@ @item A non-@code{static} function declaration follows a @code{static} one. This construct is not accepted by some traditional C compilers. + +@item +The ANSI type of an integer constant has a different width or signedness +from its traditional type. This warning is only issued if the base of +the constant is ten. I.e. hexadecimal or octal values, which typically +represent bit patterns, are not warned about. @end itemize @item -Wundef Index: jump.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/jump.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 jump.c --- jump.c 1999/11/01 08:26:16 1.1.1.4 +++ jump.c 2001/08/30 21:05:38 @@ -200,8 +200,6 @@ if (flag_exceptions && cross_jump) init_insn_eh_region (f, max_uid); - delete_barrier_successors (f); - /* Leave some extra room for labels and duplicate exit test insns we make. */ max_jump_chain = max_uid * 14 / 10; @@ -224,6 +222,8 @@ for (insn = exception_handler_labels; insn; insn = XEXP (insn, 1)) LABEL_NUSES (XEXP (insn, 0))++; + delete_barrier_successors (f); + /* Quit now if we just wanted to rebuild the JUMP_LABEL and REG_LABEL notes and recompute LABEL_NUSES. */ if (mark_labels_only) @@ -2139,7 +2139,24 @@ insn = NEXT_INSN (insn); while (insn != 0 && GET_CODE (insn) != CODE_LABEL) { - if (GET_CODE (insn) == NOTE + if (GET_CODE (insn) == JUMP_INSN) + { + /* Detect when we're deleting a tablejump; get rid of + the jump table as well. */ + rtx next1 = next_nonnote_insn (insn); + rtx next2 = next1 ? next_nonnote_insn (next1) : 0; + if (next2 && GET_CODE (next1) == CODE_LABEL + && GET_CODE (next2) == JUMP_INSN + && (GET_CODE (PATTERN (next2)) == ADDR_VEC + || GET_CODE (PATTERN (next2)) == ADDR_DIFF_VEC)) + { + delete_insn (insn); + insn = next2; + } + else + insn = delete_insn (insn); + } + else if (GET_CODE (insn) == NOTE && NOTE_LINE_NUMBER (insn) != NOTE_INSN_FUNCTION_END) insn = NEXT_INSN (insn); else Index: loop.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/loop.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 loop.c --- loop.c 2001/02/17 08:35:49 1.1.1.9 +++ loop.c 2001/08/30 21:05:38 @@ -1481,10 +1481,16 @@ width as M1. The check for integer is redundant, but safe, since the only case of differing destination modes with equal sources is when both sources are - VOIDmode, i.e., CONST_INT. */ + VOIDmode, i.e., CONST_INT. + + For 2.95, don't do this if the mode of M1 is Pmode. + This prevents us from substituting SUBREGs for REGs + in memory accesses; not all targets are prepared to + handle this properly. */ (GET_MODE (m->set_dest) == GET_MODE (m1->set_dest) || (GET_MODE_CLASS (GET_MODE (m->set_dest)) == MODE_INT && GET_MODE_CLASS (GET_MODE (m1->set_dest)) == MODE_INT + && GET_MODE (m1->set_dest) != Pmode && (GET_MODE_BITSIZE (GET_MODE (m->set_dest)) >= GET_MODE_BITSIZE (GET_MODE (m1->set_dest))))) /* See if the source of M1 says it matches M. */ Index: regmove.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/regmove.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 regmove.c --- regmove.c 1999/11/01 08:26:31 1.1.1.3 +++ regmove.c 2001/08/30 21:05:38 @@ -693,6 +693,9 @@ } if (! (set = single_set (p)) || GET_CODE (SET_SRC (set)) != MEM + /* If there's a REG_EQUIV note, this must be an insn that loads an + argument. Prefer keeping the note over doing this optimization. */ + || find_reg_note (p, REG_EQUIV, NULL_RTX) || SET_DEST (set) != src_reg) return; @@ -736,6 +739,12 @@ /* One or more changes were no good. Back out everything. */ PUT_MODE (src_reg, old_mode); XEXP (src, 0) = src_reg; + } + else + { + rtx note = find_reg_note (p, REG_EQUAL, NULL_RTX); + if (note) + remove_note (p, note); } } Index: reload1.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/reload1.c,v retrieving revision 1.1.1.6 diff -u -r1.1.1.6 reload1.c --- reload1.c 2001/02/17 08:36:02 1.1.1.6 +++ reload1.c 2001/08/30 21:05:38 @@ -4278,9 +4278,6 @@ spill_reg_order); } - if (num_eliminable && chain->need_elim) - update_eliminable_offsets (); - if (n_reloads > 0) { rtx next = NEXT_INSN (insn); @@ -4327,6 +4324,10 @@ NOTE_LINE_NUMBER (p) = NOTE_INSN_DELETED; } } + + if (num_eliminable && chain->need_elim) + update_eliminable_offsets (); + /* Any previously reloaded spilled pseudo reg, stored in this insn, is no longer validly lying around to save a future reload. Note that this does not detect pseudos that were reloaded @@ -8071,7 +8072,9 @@ } n_occurrences = count_occurrences (PATTERN (insn), reg); if (substed) - n_occurrences += count_occurrences (PATTERN (insn), substed); + n_occurrences += count_occurrences (PATTERN (insn), + eliminate_regs (substed, 0, + NULL_RTX)); if (n_occurrences > n_inherited) return; @@ -9967,6 +9970,21 @@ } break; + case USE: + /* If this is the USE of a return value, we can't change it. */ + if (GET_CODE (XEXP (x, 0)) == REG && REG_FUNCTION_VALUE_P (XEXP (x, 0))) + { + /* Mark the return register as used in an unknown fashion. */ + rtx reg = XEXP (x, 0); + int regno = REGNO (reg); + int nregs = HARD_REGNO_NREGS (regno, GET_MODE (reg)); + + while (--nregs >= 0) + reg_state[regno + nregs].use_index = -1; + return; + } + break; + case CLOBBER: if (GET_CODE (SET_DEST (x)) == REG) return; @@ -9983,11 +10001,22 @@ { int regno = REGNO (x); int use_index; + int nregs; /* Some spurious USEs of pseudo registers might remain. Just ignore them. */ if (regno >= FIRST_PSEUDO_REGISTER) return; + + nregs = HARD_REGNO_NREGS (regno, GET_MODE (x)); + + /* We can't substitute into multi-hard-reg uses. */ + if (nregs > 1) + { + while (--nregs >= 0) + reg_state[regno + nregs].use_index = -1; + return; + } /* If this register is already used in some unknown fashion, we can't do anything. Index: rtl.h =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/rtl.h,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 rtl.h --- rtl.h 2001/02/17 08:36:04 1.1.1.5 +++ rtl.h 2001/08/30 21:05:38 @@ -888,6 +888,12 @@ /* For a NOTE_INSN_LIVE note, the original basic block number. */ #define RANGE_LIVE_ORIG_BLOCK(INSN) (XINT (INSN, 1)) +/* Nonzero if we need to distinguish between the return value of this function + and the return value of a function called by this function. This helps + integrate.c. + This is 1 until after the rtl generation pass. */ +extern int rtx_equal_function_value_matters; + /* Generally useful functions. */ /* The following functions accept a wide integer argument. Rather than Index: tm.texi =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/tm.texi,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 tm.texi --- tm.texi 1999/10/16 06:05:53 1.1.1.3 +++ tm.texi 2001/08/30 21:05:39 @@ -3464,6 +3464,13 @@ system's installed C compiler and look at the assembler code that results. +@findex NO_PROFILE_COUNTERS +@item NO_PROFILE_COUNTERS +Define this macro if the @code{mcount} subroutine on your system does +not need a counter variable allocated for each function. This is true +for almost all modern implementations. If you define this macro, you +must not use the @var{labelno} argument to @code{FUNCTION_PROFILER}. + @findex PROFILE_BEFORE_PROLOGUE @item PROFILE_BEFORE_PROLOGUE Define this macro if the code for function profiling should come before Index: toplev.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/toplev.c,v retrieving revision 1.12 diff -u -r1.12 toplev.c --- toplev.c 2001/08/16 06:05:18 1.12 +++ toplev.c 2001/08/30 21:05:39 @@ -139,8 +139,6 @@ #define DIR_SEPARATOR '/' #endif -extern int rtx_equal_function_value_matters; - #if ! (defined (VMS) || defined (OS2)) extern char **environ; #endif Index: varasm.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/varasm.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 varasm.c --- varasm.c 2001/03/24 01:58:28 1.1.1.7 +++ varasm.c 2001/08/30 21:05:39 @@ -3494,18 +3494,9 @@ pop_obstacks (); } - if (GET_CODE (x) == LABEL_REF) - { - extern rtx forced_labels; - - push_obstacks_nochange (); - rtl_in_saveable_obstack (); - forced_labels = gen_rtx_EXPR_LIST (VOIDmode, - XEXP (x, 0), - forced_labels); - pop_obstacks (); - } + if (GET_CODE (x) == LABEL_REF) + LABEL_PRESERVE_P (XEXP (x, 0)) = 1; /* Allocate a pool constant descriptor, fill it in, and chain it in. */ Index: config/i386/linux.h =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/config/i386/linux.h,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 linux.h --- config/i386/linux.h 1999/10/16 06:08:08 1.1.1.4 +++ config/i386/linux.h 2001/08/30 21:05:26 @@ -234,3 +234,21 @@ } \ } while (0) #endif + +#if defined(__PIC__) && defined (USE_GNULIBC_1) +/* This is a kludge. The i386 GNU/Linux dynamic linker needs ___brk_addr, + __environ and atexit (). We have to make sure they are in the .dynsym + section. We accomplish it by making a dummy call here. This + code is never reached. */ + +#define CRT_END_INIT_DUMMY \ + do \ + { \ + extern void *___brk_addr; \ + extern char **__environ; \ + \ + ___brk_addr = __environ; \ + atexit (0); \ + } \ + while (0) +#endif Index: config/sparc/sparc.md =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/config/sparc/sparc.md,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 sparc.md --- config/sparc/sparc.md 2001/02/17 08:37:45 1.1.1.5 +++ config/sparc/sparc.md 2001/08/30 21:05:31 @@ -2899,6 +2899,11 @@ crashes in output_constant_pool. */ if (operands [1] == const0_rtx) operands[1] = CONST0_RTX (SFmode); + /* We are able to build any SF constant in integer registers + with at most 2 instructions. */ + if (REGNO (operands[0]) < 32) + goto movsf_is_ok; + operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]), operands[1])); } @@ -3093,6 +3098,9 @@ crashes in output_constant_pool. */ if (operands [1] == const0_rtx) operands[1] = CONST0_RTX (DFmode); + if (REGNO (operands[0]) < 32) + goto movdf_is_ok; + operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]), operands[1])); } @@ -3277,17 +3285,11 @@ (define_split [(set (match_operand:DF 0 "register_operand" "") (match_operand:DF 1 "memory_operand" ""))] - "((! TARGET_V9 - || (! TARGET_ARCH64 - && ((GET_CODE (operands[0]) == REG - && REGNO (operands[0]) < 32) - || (GET_CODE (operands[0]) == SUBREG - && GET_CODE (SUBREG_REG (operands[0])) == REG - && REGNO (SUBREG_REG (operands[0])) < 32)))) - && (reload_completed - && (((REGNO (operands[0])) % 2) != 0 - || ! mem_min_alignment (operands[1], 8)) - && offsettable_memref_p (operands[1])))" + "reload_completed + && ! TARGET_ARCH64 + && (((REGNO (operands[0]) % 2) != 0) + || ! mem_min_alignment (operands[1], 8)) + && offsettable_memref_p (operands[1])" [(clobber (const_int 0))] " { @@ -3318,17 +3320,11 @@ (define_split [(set (match_operand:DF 0 "memory_operand" "") (match_operand:DF 1 "register_operand" ""))] - "((! TARGET_V9 - || (! TARGET_ARCH64 - && ((GET_CODE (operands[1]) == REG - && REGNO (operands[1]) < 32) - || (GET_CODE (operands[1]) == SUBREG - && GET_CODE (SUBREG_REG (operands[1])) == REG - && REGNO (SUBREG_REG (operands[1])) < 32)))) - && (reload_completed - && (((REGNO (operands[1])) % 2) != 0 - || ! mem_min_alignment (operands[0], 8)) - && offsettable_memref_p (operands[0])))" + "reload_completed + && ! TARGET_ARCH64 + && (((REGNO (operands[1]) % 2) != 0) + || ! mem_min_alignment (operands[0], 8)) + && offsettable_memref_p (operands[0])" [(clobber (const_int 0))] " { @@ -5211,7 +5207,7 @@ (define_insn "muldi3_v8plus" [(set (match_operand:DI 0 "register_operand" "=r,h") (mult:DI (match_operand:DI 1 "arith_double_operand" "%r,0") - (match_operand:DI 2 "arith_double_operand" "rHI,rHI"))) + (match_operand:DI 2 "arith_double_operand" "rI,rI"))) (clobber (match_scratch:SI 3 "=&h,X")) (clobber (match_scratch:SI 4 "=&h,X"))] "TARGET_V8PLUS" @@ -5221,6 +5217,13 @@ output_asm_insn (\"srl\\t%L1, 0, %L1\", operands); if (which_alternative == 1) output_asm_insn (\"sllx\\t%H1, 32, %H1\", operands); + if (GET_CODE (operands[2]) == CONST_INT) + { + if (which_alternative == 1) + return \"or\\t%L1, %H1, %H1\\n\\tmulx\\t%H1, %2, %L0\;srlx\\t%L0, 32, %H0\"; + else + return \"sllx\\t%H1, 32, %3\\n\\tor\\t%L1, %3, %3\\n\\tmulx\\t%3, %2, %3\\n\\tsrlx\\t%3, 32, %H0\\n\\tmov\\t%3, %L0\"; + } if (sparc_check_64 (operands[2], insn) <= 0) output_asm_insn (\"srl\\t%L2, 0, %L2\", operands); if (which_alternative == 1) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 19:40:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 0B0FE37B405; Wed, 5 Sep 2001 19:40:22 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f862eKY79830; Thu, 6 Sep 2001 10:40:20 +0800 (KRAST) Date: Thu, 6 Sep 2001 10:40:39 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <8264494448.20010906104039@morning.ru> To: Gregory Neil Shapiro Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re[2]: auto relaying for subdomains -- why? In-Reply-To: <15254.22980.843972.348805@horsey.gshapiro.net> References: <16615694707.20010905210719@morning.ru> <15254.22980.843972.348805@horsey.gshapiro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG poige>> I noticed that some mailers (sendmail, postfix) in case they allow poige>> relaying for somedomain.zone also allow relaying for poige>> subdomain-of.somedomain.zone. poige>> I can accept this as reasonable behavior but would like to know how to poige>> deny it! :) Also I wish to know what was the actual idea behind this? >>From /usr/share/sendmail/cf/README: > +----------+ > | FEATURES | > +----------+ > .... > Available features are: > .... > relay_hosts_only > By default, names that are listed as RELAY in the access > db and class {R} are domain names, not host names. > For example, if you specify ``foo.com'', then mail to or > from foo.com, abc.foo.com, or a.very.deep.domain.foo.com > will all be accepted for relaying. This feature changes > the behaviour to lookup individual host names only. Yes, I saw this info here: http://www.sendmail.org/m4/features.html#relay_mail_from but most valuable part of my question was about the purpose or the idea behind this, cause it's not too clear to me why allowing relaying for domain FOO.BAR should allow relaying for SUB.FOO.BAR? I mentioned RFCs because I had a hope to find out the answer from it but still haven't yet... -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 20:14:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id A0CD237B405; Wed, 5 Sep 2001 20:14:19 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f863EFY81124; Thu, 6 Sep 2001 11:14:16 +0800 (KRAST) Date: Thu, 6 Sep 2001 11:14:35 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <3566530585.20010906111435@morning.ru> To: Terry Lambert Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re[2]: auto relaying for subdomains -- why? In-Reply-To: <3B9674D1.2AB00B6D@mindspring.com> References: <16615694707.20010905210719@morning.ru> <3B9674D1.2AB00B6D@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Igor Podlesny wrote: >> I noticed that some mailers (sendmail, postfix) in case they allow >> relaying for somedomain.zone also allow relaying for >> subdomain-of.somedomain.zone. >> >> I can accept this as reasonable behavior but would like to know how to >> deny it! :) Also I wish to know what was the actual idea behind this? > Sendmail does _not_ do this by default; you have to specifically > allow it by adding entries to your M4 file from which you build > your sendmail.cf. > If I had to guess, I'd guess that you enabled the domain via a > sendmail.cw file, Ieh :) But what is wrong with that? it just says to sendmail that he is the end point for mail destined to @foo.bar. Now it's named /etc/mail/local-host-names > rather than a virtusertable, or by setting > yourself up as a promiscuous relay. no... no for these gueses :) > -- Terry -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 20:59:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id A12F637B405; Wed, 5 Sep 2001 20:59:42 -0700 (PDT) Received: from horsey.gshapiro.net (gshapiro@localhost [127.0.0.1]) by horsey.gshapiro.net (8.12.0.Gamma0/8.12.0.Gamma0) with ESMTP id f863xfUN028176 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Sep 2001 20:59:41 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.0.Gamma0/8.12.0.Gamma0/Submit) id f863xfgu028173; Wed, 5 Sep 2001 20:59:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15254.62636.867613.151378@horsey.gshapiro.net> Date: Wed, 5 Sep 2001 20:59:40 -0700 From: Gregory Neil Shapiro To: Igor Podlesny Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Re[2]: auto relaying for subdomains -- why? In-Reply-To: <8264494448.20010906104039@morning.ru> References: <16615694707.20010905210719@morning.ru> <15254.22980.843972.348805@horsey.gshapiro.net> <8264494448.20010906104039@morning.ru> X-Mailer: VM 6.95 under 21.5 (beta1) "anise" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG poige> Yes, I saw this info here: poige> http://www.sendmail.org/m4/features.html#relay_mail_from but most poige> valuable part of my question was about the purpose or the idea behind poige> this, cause it's not too clear to me why allowing relaying for domain poige> FOO.BAR should allow relaying for SUB.FOO.BAR? Because some places have only one machine (firewall) that accepts mail from the outside world for all of the hosts inside the network. For example, in my previous life as a sysadmin at WPI, only smtp.wpi.edu would accept incoming mail for all of the machines (> 3000) on campus. I'd much rather say "wpi.edu" in one place instead of listing loads of subdomains (ee.wpi.edu, me.wpi.edu, res.wpi.edu, ...). poige> I mentioned RFCs because I had a hope to find out the answer from it poige> but still haven't yet... RFC's cover protocols over the Internet, not local configuration or policy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 21: 0:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 260A837B40F; Wed, 5 Sep 2001 21:00:34 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f863xAW82889; Thu, 6 Sep 2001 11:59:10 +0800 (KRAST) Date: Thu, 6 Sep 2001 11:59:30 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <1969225581.20010906115930@morning.ru> To: Bernd Walter Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re[2]: auto relaying for subdomains -- why? In-Reply-To: <20010905153220.E16349@cicely20.cicely.de> References: <16615694707.20010905210719@morning.ru> <20010905153220.E16349@cicely20.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Wed, Sep 05, 2001 at 09:07:19PM +0800, Igor Podlesny wrote: >> >> My greetings! >> >> I noticed that some mailers (sendmail, postfix) in case they allow >> relaying for somedomain.zone also allow relaying for >> subdomain-of.somedomain.zone. >> >> I can accept this as reasonable behavior but would like to know how to >> deny it! :) Also I wish to know what was the actual idea behind this? > Allow domain.com > disallow .domain.com Which software use this syntax? :) or just an idea? -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 21:41:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from herbelot.dyndns.org (d211.dhcp212-26.cybercable.fr [212.198.26.211]) by hub.freebsd.org (Postfix) with ESMTP id 84A2537B407; Wed, 5 Sep 2001 21:41:31 -0700 (PDT) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id GAA10845; Thu, 6 Sep 2001 06:39:39 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B96FE21.4B93363B@herbelot.com> Date: Thu, 06 Sep 2001 06:40:01 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? References: <200109050756.f857uQM18767@freebsd.dk> <3B967E23.185B6299@herbelot.com> <20010905171100.B13337@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > > "known-bad" revision for these babies -, and the 762 North Bridge of the > > soon to be there SMP Athlon) > > "Soon to be there"?? Hum... I'm typing to you from one. Excuse me : I meant for the common mortal, with prices more in line with what can be expected from Asus or Abit Nice to hear it works (and works well, I assume) TfH > > -- > -- David (obrien@FreeBSD.org) -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 22:14:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id E5E2937B403 for ; Wed, 5 Sep 2001 22:14:15 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f865EDg58620; Wed, 5 Sep 2001 22:14:13 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id f865ECv09269; Wed, 5 Sep 2001 22:14:12 -0700 (PDT) (envelope-from jdp) Date: Wed, 5 Sep 2001 22:14:12 -0700 (PDT) Message-Id: <200109060514.f865ECv09269@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: tlambert2@mindspring.com Subject: Re: local changes to CVS tree In-Reply-To: <3B9684AE.31C4FB9F@mindspring.com> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <15254.31457.818766.916542@nomad.yogotech.com> <200109051925.f85JPce08130@vashon.polstra.com> <3B9684AE.31C4FB9F@mindspring.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <3B9684AE.31C4FB9F@mindspring.com>, Terry Lambert wrote: > John Polstra wrote: > > I have had this on my to-do list for a long time, but I have no idea > > if or when it'll ever get implemented. It would require a focused > > period of working on it that I just don't have these days. Maybe if > > the economy gets worse ... [...] > I guess a better question would be whether funding would help? Sure -- that would take care of the "my real jobs take priority" problem. But I'm currently on two open-ended jobs, which is the most I can manage effectively. So right now I can't guess when I could do it even if I had funding. I'd very much like to do it, but I can't until I've met my existing commitments. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 22:35:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id B1A1237B405 for ; Wed, 5 Sep 2001 22:35:51 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.5/8.11.1) id f865Zlt09838; Wed, 5 Sep 2001 22:35:47 -0700 (PDT) (envelope-from obrien) Date: Wed, 5 Sep 2001 22:35:47 -0700 From: "David O'Brien" To: Thierry Herbelot Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tagged Command Queuing support for IC-35L0?0 ? Message-ID: <20010905223547.A97656@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200109050756.f857uQM18767@freebsd.dk> <3B967E23.185B6299@herbelot.com> <20010905171100.B13337@dragon.nuxi.com> <3B96FE21.4B93363B@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B96FE21.4B93363B@herbelot.com>; from thierry@herbelot.com on Thu, Sep 06, 2001 at 06:40:01AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 06, 2001 at 06:40:01AM +0200, Thierry Herbelot wrote: > > On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > > > "known-bad" revision for these babies -, and the 762 North Bridge of the > > > soon to be there SMP Athlon) > > > > "Soon to be there"?? Hum... I'm typing to you from one. > > Excuse me : I meant for the common mortal, with prices more in line with > what can be expected from Asus or Abit These *are* prices for common mortals: Tyan Tiger 760MP mobo $220 2x Palomino 1.2GHz MP $160 x 2 total: $540 Surely one can afford that. Heck the K6-2/450 I used for 2.5 years cost me $225 and the Tyan Trinity100 mobo was like $125; that was $350 just for that. OR go with the Tyan Thunder 2/dual 10/100 NICs + dual U160 SCSI for $445 this board also has on-board ATI VGA video. All you need with this board is 2x CPU's + 256MB PC2400 DDR memory + case + power supply ==> $445 + 2x$160 + $70 + case = $835 + case (reuse your existing disks) > Nice to hear it works (and works well, I assume) DAMN NICE !! I mean SWEET !! -- -- David (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 Sep 5 22:46:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id A7DB137B405; Wed, 5 Sep 2001 22:46:14 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f865kCd86951; Thu, 6 Sep 2001 13:46:13 +0800 (KRAST) Date: Thu, 6 Sep 2001 13:46:34 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <7575649117.20010906134634@morning.ru> To: Gregory Neil Shapiro Cc: freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re[4]: auto relaying for subdomains -- why? In-Reply-To: <15254.62636.867613.151378@horsey.gshapiro.net> References: <16615694707.20010905210719@morning.ru> <15254.22980.843972.348805@horsey.gshapiro.net> <8264494448.20010906104039@morning.ru> <15254.62636.867613.151378@horsey.gshapiro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG poige>> Yes, I saw this info here: poige>> http://www.sendmail.org/m4/features.html#relay_mail_from but most poige>> valuable part of my question was about the purpose or the idea behind poige>> this, cause it's not too clear to me why allowing relaying for domain poige>> FOO.BAR should allow relaying for SUB.FOO.BAR? > Because some places have only one machine (firewall) that accepts mail from > the outside world for all of the hosts inside the network. For example, in > my previous life as a sysadmin at WPI, only smtp.wpi.edu would accept > incoming mail for all of the machines (> 3000) on campus. I'd much rather > say "wpi.edu" in one place instead of listing loads of subdomains > (ee.wpi.edu, me.wpi.edu, res.wpi.edu, ...). Not too close to question again... I understand this (this is the need to easily cover all the domain and as I wrote in the initial letter "...I can accept this as reasonable behavior..." having in mind just the same reason you're talking about). But that time I wasn't sure whether it is a SENDMAIL's feature (local configuration as you said after) or it's required/described in RFC. This was the start :) Now it's all clear :) and I understand that it was just a way SENDMAIL's is configured. Another question could be why not to use syntax .foo.bar instead of foo.bar but I'm quite ready to call it a rhetorical one ;-)) (regexps are also there ;-) poige>> I mentioned RFCs because I had a hope to find out the answer from it poige>> but still haven't yet... > RFC's cover protocols over the Internet, not local configuration or policy. But who could say these early hours that such behavior isn't dependant on protocol? :-)) P.S. Thank you everybody, your answers have thrown some additional light upon the subject deepness! ;-) ---------------------------------------------------------------------- P.P.S. I'm not quite sure should I start new thread or can remain within it with another question which is: What MTA software supports highly configurable relaying... One of the needed features is a support for using alternative mail routers (relays) in case when this MTA can't send a message by itself because of networks problem. For example situation could be: MTA is on a network A which is temporarily cut off from it's uplink so it can't transfer mail by itself, but it has a connection (permanent or dial-up) to another mailer. Are there such MTAs which can be said "if you can't send it by yourself (would be cool if additional parameters were some_time_period and failure_reason) then use that MTA (ip-addr) or that (another-ip)?". I suspect in common case such "system" could easily lead to loops and have other drawbacks but in such simple configuration it seems all should work fine... -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 5 23:19:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sharmas.dhs.org (cpe-66-1-147-119.ca.sprintbbd.net [66.1.147.119]) by hub.freebsd.org (Postfix) with ESMTP id CDD8537B406 for ; Wed, 5 Sep 2001 23:19:54 -0700 (PDT) Received: by sharmas.dhs.org (Postfix, from userid 500) id 1B9045E374; Wed, 5 Sep 2001 23:22:38 -0700 (PDT) Date: Wed, 5 Sep 2001 23:22:38 -0700 From: Arun Sharma To: FreeBSD Hackers Subject: POSIX compatibility issue Message-ID: <20010905232238.A7124@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Can someone take a look at this PR ? http://www.freebsd.org/cgi/query-pr.cgi?pr=30317 It's necessary to fix compilation issues for a POSIX compliant Java VM, that uses sockets. There are similar open bug reports against NetBSD too, without any comments on why this change can not be made. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 0:40:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.ntu-kpi.kiev.ua (www.ntu-kpi.kiev.ua [212.111.192.161]) by hub.freebsd.org (Postfix) with ESMTP id CC98037B406 for ; Thu, 6 Sep 2001 00:40:00 -0700 (PDT) Received: from comsys.ntu-kpi.kiev.ua (eth0.comsys.ntu-kpi.kiev.ua [10.0.1.184]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id 065922EEC5 for ; Thu, 6 Sep 2001 10:39:56 +0300 (EEST) Received: from pm5149 (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) by comsys.ntu-kpi.kiev.ua (8.11.3/8.11.3) with SMTP id f867YBF40647 for ; Thu, 6 Sep 2001 10:34:11 +0300 (EEST) Message-ID: <004f01c1369d$5fc07ba0$6d36120a@comsys.ntukpi.kiev.ua> From: "Andrey Simonenko" To: Subject: Permissions on /root directory and /etc/mtree/BSD.root.dist Date: Thu, 6 Sep 2001 10:30:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi All, I have one idea about permissions on /root directory and permissions on /root directory specified in the /etc/mtree/BSD.root.dist file. After finishing FreeBSD installating process permissions on /root directory are equal to 0755. Some administrators don't like these permissions for home dir of root and changed them to 0700, or to 0750, or to any other permissions. 0700 mode restricts other users from reading /root directory. When root wants to upgrade system he/she run "make buildworld", "make installworld". But installworld calls mtree, which changes /root permissions to default value specified in the /etc/mtree/BSD.root.dist file. So, if administrator will not forgot about needed permissions on /root, then installworld will open /root directory for reading for everybody. I propose not to change permissions on /root directory in the /etc/mtree/BSD.root.dist file and leave them unchanged. Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 3: 7: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 1FEC137B406 for ; Thu, 6 Sep 2001 03:06:58 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AA5FC66D24; Thu, 6 Sep 2001 03:06:57 -0700 (PDT) Date: Thu, 6 Sep 2001 03:06:57 -0700 From: Kris Kennaway To: hackers@FreeBSD.org Subject: undocumented wall(1) feature Message-ID: <20010906030656.C2453@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Does anyone object to this? Kris Index: wall.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/usr.bin/wall/wall.c,v retrieving revision 1.19 diff -u -r1.19 wall.c --- wall.c 2001/05/08 11:11:42 1.19 +++ wall.c 2001/09/06 10:06:06 @@ -71,8 +71,6 @@ static void usage(void); char *ttymsg(struct iovec *, int, const char *, int); =20 -#define IGNOREUSER "sleeper" - struct wallgroup { struct wallgroup *next; char *name; @@ -140,8 +138,7 @@ iov.iov_len =3D mbufsize; /* NOSTRICT */ while (fread((char *)&utmp, sizeof(utmp), 1, fp) =3D=3D 1) { - if (!utmp.ut_name[0] || - !strncmp(utmp.ut_name, IGNOREUSER, sizeof(utmp.ut_name))) + if (!utmp.ut_name[0]) continue; if (grouplist) { strlcpy(username, utmp.ut_name, sizeof(utmp.ut_name)); --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7l0rAWry0BWjoQKURAsbNAJ4xKYRl1GHd9rfWHZr9jRFvqfwAbQCg1g5D qIDQD5LbDeRwlf39u9wwnFA= =T5UH -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 4: 7: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id C5E5437B401 for ; Thu, 6 Sep 2001 04:07:01 -0700 (PDT) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id NAA01016; Thu, 6 Sep 2001 13:07:01 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id 94B6F14B44; Thu, 6 Sep 2001 13:07:00 +0200 (CEST) Date: Thu, 6 Sep 2001 13:07:00 +0200 From: Alexander Langer To: Bernd Walter Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: local changes to CVS tree Message-ID: <20010906130700.A1259@zerogravity.kawo2.rwth-aachen.d> References: <20010905131027.A5476@fump.kawo2.rwth-aachen.de> <20010905153045.D16349@cicely20.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010905153045.D16349@cicely20.cicely.de>; from ticso@mail.cicely.de on Wed, Sep 05, 2001 at 03:30:45PM +0200 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Also sprach Bernd Walter (ticso@mail.cicely.de): > > How do people fix stuff in their local CVS tree and sync other > > FreeBSD changes with that? > It's a CVSup FAQ: > http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal Great, thanks. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 4:51:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bugz.infotecs.ru (bugz.infotecs.ru [195.210.139.22]) by hub.freebsd.org (Postfix) with ESMTP id 54F4B37B409 for ; Thu, 6 Sep 2001 04:51:43 -0700 (PDT) Received: (from root@localhost) by bugz.infotecs.ru (8.11.6/8.11.4) id f86Bpd769679 for freebsd-hackers@freebsd.org; Thu, 6 Sep 2001 15:51:39 +0400 (MSD) (envelope-from vel) From: "Eugene L. Vorokov" Message-Id: <200109061151.f86Bpd769679@bugz.infotecs.ru> Subject: corrupted 'w' output To: freebsd-hackers@freebsd.org Date: Thu, 6 Sep 2001 15:51:38 +0400 (MSD) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I updated from -current yesterday, ran "make world; make kernel KERNCONF=X" and went to bed. When I rebooted with fresh kernel this morning, I noticed something strange: vel@bugz:/usr/src # w 3:47PM up 5:38, 4 users, load averages: 0.00, 0.11, 0.08 USER TTY FROM LOGIN@ IDLE WHAT vel p0 kg.infotecs.ru 10:11AM 2 ssh -l vel bsx.ru vel p1 kg.infotecs.ru 10:22AM - w vel p2 kg.infotecs.ru 12:13PM 1:55 \M-[\M-!\^D\b (tcsh) vel p3 kg.infotecs.ru 12:53PM 2 \M-[\M-!\^D\b (tcsh) This only happens for terminals that are in a shell, when something else is running, output isn't corrupted. I think someone reported similar problem with 'ps' output. Regards, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 6: 9:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B7A4237B407 for ; Thu, 6 Sep 2001 06:09:36 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f86D8sx31880; Thu, 6 Sep 2001 16:08:54 +0300 (EEST) (envelope-from ru) Date: Thu, 6 Sep 2001 16:08:54 +0300 From: Ruslan Ermilov To: Kris Kennaway Cc: hackers@FreeBSD.org Subject: Re: undocumented wall(1) feature Message-ID: <20010906160854.K18362@sunbay.com> References: <20010906030656.C2453@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906030656.C2453@xor.obsecurity.org>; from kris@obsecurity.org on Thu, Sep 06, 2001 at 03:06:57AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 06, 2001 at 03:06:57AM -0700, Kris Kennaway wrote: > Does anyone object to this? > Just a bit of history. This has been added with this CSRG commit: : D 4.5 81/06/12 13:23:15 root 5 4 00003/00001/00129 : MRs: : COMMENTS: : I suppressed wall messages to the sleeper program Not sure what does it mean. Perhaps, at that times, the sleeper existed as a user process and was run under the sleeper user. > Index: wall.c > =================================================================== > RCS file: /mnt/ncvs/src/usr.bin/wall/wall.c,v > retrieving revision 1.19 > diff -u -r1.19 wall.c > --- wall.c 2001/05/08 11:11:42 1.19 > +++ wall.c 2001/09/06 10:06:06 > @@ -71,8 +71,6 @@ > static void usage(void); > char *ttymsg(struct iovec *, int, const char *, int); > > -#define IGNOREUSER "sleeper" > - > struct wallgroup { > struct wallgroup *next; > char *name; > @@ -140,8 +138,7 @@ > iov.iov_len = mbufsize; > /* NOSTRICT */ > while (fread((char *)&utmp, sizeof(utmp), 1, fp) == 1) { > - if (!utmp.ut_name[0] || > - !strncmp(utmp.ut_name, IGNOREUSER, sizeof(utmp.ut_name))) > + if (!utmp.ut_name[0]) > continue; > if (grouplist) { > strlcpy(username, utmp.ut_name, sizeof(utmp.ut_name)); -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 7:36:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id BAFEC37B401 for ; Thu, 6 Sep 2001 07:36:08 -0700 (PDT) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.6/8.11.4) id f86Ea8k00433 for freebsd-hackers@FreeBSD.ORG; Thu, 6 Sep 2001 10:36:08 -0400 (EDT) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.7p2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010905183516.A68720@dragon.nuxi.com> Date: Thu, 06 Sep 2001 10:36:07 -0400 (EDT) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: freebsd-hackers@FreeBSD.ORG Subject: RE: post 2.95.3 patches to test Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG All my previous test cases which used to break without sjlj patches are working with this patch correctly. I guess you might my results to your list of successes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 9: 0:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id F07D037B407 for ; Thu, 6 Sep 2001 09:00:15 -0700 (PDT) Received: from jane (dhcp124.vicor-nb.com [208.206.78.124]) by mail.vicor-nb.com (Postfix) with SMTP id C096B1B21C for ; Thu, 6 Sep 2001 09:00:15 -0700 (PDT) From: "Steele Yang" To: Subject: Help with 3ware 3dm utility????? Date: Thu, 6 Sep 2001 08:59:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike or anyone, I am having some difficulties getting 3dm for the 3ware escalade IDE raid card to work on FreeBSD 4.1 or 4.2 I am getting the following errors: twe0: command failed-aborted due to system command or reconfiguration twe0: TWETO_GET_PARAM failed for 0x40610x216 I can see that /dev/twe0 and /dev/twed0 exist when I look in the /dev directory. When I execute "ps -auxw | grep 3dmd", I am getting mulitple 3dmd process spawning. root 259 0.0 0.3 620 412 p0 I 6:16PM 0:00.00 ./3dmd root 260 0.0 0.3 620 412 p0 I 6:16PM 0:00.03 ./3dmd root 261 0.0 0.4 636 436 p0 S 6:16PM 0:00.04 ./3dmd I'm not sure if I'm on the latest firmware version. If I'm not, how do I install the latest firmware version on to the card. FYI:(dmesg | grep twe0) twe0: <3ware Storage Controller> port 0xefa0-0xefaf irq 11 at device 17.0 on pci0 twe0: 4 ports, Firmware FE6X 1.01.18.001, BIOS BEXX 1.06.00.001 twed0: on twe0 Any tips or suggestions will be most grateful......... Thanks, Steele...... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 10:27:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id CF59D37B401; Thu, 6 Sep 2001 10:27:15 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.2/8.11.3) id f86HTLf06981; Thu, 6 Sep 2001 13:29:21 -0400 (EDT) (envelope-from mike) Date: Thu, 6 Sep 2001 13:29:21 -0400 From: Mike Barcroft To: "Eugene L. Vorokov" Cc: current@FreeBSD.org Subject: Re: corrupted 'w' output Message-ID: <20010906132921.C1976@coffee.q9media.com> Mail-Followup-To: Mike Barcroft , "Eugene L. Vorokov" , current@FreeBSD.org References: <200109061151.f86Bpd769679@bugz.infotecs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109061151.f86Bpd769679@bugz.infotecs.ru>; from vel@bugz.infotecs.ru on Thu, Sep 06, 2001 at 03:51:38PM +0400 Organization: The FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Moved to -current, BCC'd to -hackers] Eugene L. Vorokov writes: > Hello, > > I updated from -current yesterday, ran "make world; make kernel KERNCONF=X" > and went to bed. When I rebooted with fresh kernel this morning, I noticed > something strange: > > vel@bugz:/usr/src # w > 3:47PM up 5:38, 4 users, load averages: 0.00, 0.11, 0.08 > USER TTY FROM LOGIN@ IDLE WHAT > vel p0 kg.infotecs.ru 10:11AM 2 ssh -l vel bsx.ru > vel p1 kg.infotecs.ru 10:22AM - w > vel p2 kg.infotecs.ru 12:13PM 1:55 \M-[\M-!\^D\b (tcsh) > vel p3 kg.infotecs.ru 12:53PM 2 \M-[\M-!\^D\b (tcsh) > > This only happens for terminals that are in a shell, when something else > is running, output isn't corrupted. I think someone reported similar problem > with 'ps' output. > > Regards, > Eugene Those shell argv[0]'s are generated by login(1). I wonder if it was a recent commit to src/usr.bin/login/login.c that is causing it. Can you try locally backing out Rev. 1.68 (and Rev 1.36 of Makefile)? You will ofcourse have to relogin to see whether the w(1) output has changed. BTW, I can't reproduce this problem locally. Is there any special about your local configuration, particularly regarding PAM? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 10:57:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 80AA737B408 for ; Thu, 6 Sep 2001 10:57:34 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 219B3305; Thu, 6 Sep 2001 18:57:33 +0100 (BST) Date: Thu, 6 Sep 2001 18:57:32 +0100 From: Josef Karthauser To: FreeBSD Current Users Subject: DRI, XFree86-4.0.3 and -current. Message-ID: <20010906185732.A3148@tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Has anyone got patches for DRI under -current? Joe --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuXuQwACgkQXVIcjOaxUBZ8wQCgwihtD9YH+8Kc3j1Pw2GWk4JY +igAniF6SPBfIAm6d/tycp/Vxcxd0X7W =Kb7e -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 11: 1:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from enterprise.spock.org (cm-24-29-85-81.nycap.rr.com [24.29.85.81]) by hub.freebsd.org (Postfix) with ESMTP id 6678137B406; Thu, 6 Sep 2001 11:01:42 -0700 (PDT) Received: (from jon@localhost) by enterprise.spock.org serial EF600Q3T-B7F; Thu, 6 Sep 2001 14:01:29 -0400 (EDT) (envelope-from jon)$ Date: Thu, 6 Sep 2001 14:01:29 -0400 From: Jonathan Chen To: Mike Smith Cc: Brooks Davis , hackers@FreeBSD.ORG Subject: Re: proposed change to pci_pci.c Message-ID: <20010906140129.A13575@enterprise.spock.org> References: <200109060137.f861bSO05433@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: telnet/1.1x In-Reply-To: <200109060137.f861bSO05433@mass.dis.org>; from msmith@FreeBSD.ORG on Wed, Sep 05, 2001 at 06:37:28PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Sep 05, 2001 at 06:37:28PM -0700, Mike Smith wrote: > > I'd be OK with this being done as a hack for now. I think the bridge > code needs to be a bit kinder about allowing "stupid" things to be done > if they're set up by the BIOS. > > > I'd like to propose committing the following change which adds a new > > undocumented option in the spirit of PCI_ENABLE_IO_MODES. The new option > > (PCI_ALLOW_UNSUPPORTED_IO_RANGE) allows me to boot my old HP Omnibook > > 4150 while docked. Since I've seen a couple other people need this fix, > > I figure it would be more useful if they just had to add a line to their > > kernel config instead of editing the source files. Any objections? The pci_pci code actually needs some other changes done. Note the comment at line 267, "If this is a 'default' allocation against this rid, we can't work out where it's coming from (we should actually never see these) so we just have to punt." The "we should actually never see these" part is not quite correct, since NEWCARD uses default allocation to automagically get an "unused" range from the pci bus. Then we have to tweak the window for the pcipci bridge to forward the new addresses if the window wasn't big enough. Not to mention, we still need to implement a way to request bus numbers properly... Bleah, hardware sucks. Give me a virtual machine. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 11:31:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 6CA3637B401 for ; Thu, 6 Sep 2001 11:31:23 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f86IVEn57770; Thu, 6 Sep 2001 14:31:15 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010905232238.A7124@sharmas.dhs.org> References: <20010905232238.A7124@sharmas.dhs.org> Date: Thu, 6 Sep 2001 14:31:12 -0400 To: Arun Sharma , freebsd-standards@bostonradio.org From: Garance A Drosihn Subject: Re: POSIX compatibility issue Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I imagine Garrett and other standards-minded people have already seen this question, but I thought I'd echo it to the freebsd-standards mailing list. It's about a PR which makes a minor change to to solve some compile-time errors so that a program compiled with -D_POSIX_SOURCE currently gets if it references . Seems like a plausible change to me, but I don't know enough about POSIX details to really know... At 11:22 PM -0700 9/5/01, Arun Sharma wrote: >Can someone take a look at this PR ? > >http://www.freebsd.org/cgi/query-pr.cgi?pr=30317 > >It's necessary to fix compilation issues for a POSIX compliant Java VM, >that uses sockets. > >There are similar open bug reports against NetBSD too, without any >comments on why this change can not be made. > > -Arun -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 11:53: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from naboo.ethz.ch (naboo.ethz.ch [129.132.17.66]) by hub.freebsd.org (Postfix) with ESMTP id 0C4AF37B405 for ; Thu, 6 Sep 2001 11:52:58 -0700 (PDT) Received: by naboo.ethz.ch (Postfix, from userid 224) id EA2AD275B6; Thu, 6 Sep 2001 20:52:56 +0200 (CEST) Subject: Any plans to integrate gcc 3.0.1 ? To: freebsd-hackers@freebsd.org Date: Thu, 6 Sep 2001 20:52:56 +0200 (CEST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010906185256.EA2AD275B6@naboo.ethz.ch> From: carlo@vis.ethz.ch (Carlo Dapor) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Fellow hackers Are there any plans to upgrade GCC to 3.0.1 in the near future ? Has anybody built the world with the GCC 3.0.1 ? If not, I might give it a try. I built the most recent version from the ports. Ciao, derweil, -- Carlo PS: I am asking this because I am not able to successfully bootstrap GNU Smalltalk with the JIT enabled, due to a GCC bug. I hope to be more successfull with the 'new' GCC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 12:17:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from atlantic.mail.pas.earthlink.net (atlantic.mail.pas.earthlink.net [207.217.120.179]) by hub.freebsd.org (Postfix) with ESMTP id F32B937B407 for ; Thu, 6 Sep 2001 12:17:12 -0700 (PDT) Received: from positron.anholt.dyn.dhs.org (209-63-112-157.pdx.jps.net [209.63.112.157]) by atlantic.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA18727; Thu, 6 Sep 2001 12:17:03 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" From: Eric Anholt Reply-To: anholt@teleport.com To: Josef Karthauser , FreeBSD Current Users Subject: Re: DRI, XFree86-4.0.3 and -current. Date: Thu, 6 Sep 2001 12:16:19 -0700 X-Mailer: KMail [version 1.2] References: <20010906185732.A3148@tao.org.uk> In-Reply-To: <20010906185732.A3148@tao.org.uk> MIME-Version: 1.0 Message-Id: <01090612161901.00588@positron.anholt.dyn.dhs.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a page about the DRI for FreeBSD at http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on -stable. There is one compile error on -current that should be obvious to fix in the kernel modules, but I haven't uploaded patches as I haven't actually tested it yet (I'm still setting up my new -current installation). On Thursday 06 September 2001 10:57, Josef Karthauser wrote: > Has anyone got patches for DRI under -current? > > Joe -- Eric Anholt anholt@teleport.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 12:26:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 1AAC037B406 for ; Thu, 6 Sep 2001 12:26:11 -0700 (PDT) Received: from float by dayspring.firedrake.org with local (Exim 3.22 #1 (Debian)) id 15f4kQ-0001oB-00; Thu, 06 Sep 2001 20:23:34 +0100 Date: Thu, 6 Sep 2001 20:23:34 +0100 To: Andrey Simonenko Cc: freebsd-hackers@freebsd.org Subject: Re: Permissions on /root directory and /etc/mtree/BSD.root.dist Message-ID: <20010906202334.A6682@firedrake.org> References: <004f01c1369d$5fc07ba0$6d36120a@comsys.ntukpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004f01c1369d$5fc07ba0$6d36120a@comsys.ntukpi.kiev.ua> User-Agent: Mutt/1.3.18i From: void Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 06, 2001 at 10:30:08AM +0400, Andrey Simonenko wrote: > > 0700 mode restricts other users from reading /root directory. > When root wants to upgrade system he/she run "make buildworld", > "make installworld". But installworld calls mtree, which changes > /root permissions to default value specified in the /etc/mtree/BSD.root.dist > file. So, if administrator will not forgot about needed permissions > on /root, then installworld will open /root directory for reading > for everybody. > > I propose not to change permissions on /root directory in > the /etc/mtree/BSD.root.dist file and leave them unchanged. > > Comments? There is a whole class of problems like this. For example, my installation of mutt doesn't work right if /var/mail is not mode 1777, but BSD.var.dist changes it to 755 every time I installworld. I think a more general solution might be in order. Perhaps some sort of local.dist that is processed after BSD.*.dist. As a workaround, I put "chmod 1777 /var/mail" in my rc.local script. I suggest you do something similar. -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 12:28:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 5573937B403; Thu, 6 Sep 2001 12:28:21 -0700 (PDT) Received: from mindspring.com (dialup-209.244.104.168.Dial1.SanJose1.Level3.net [209.244.104.168]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f86JSI514843; Thu, 6 Sep 2001 12:28:18 -0700 (PDT) Message-ID: <3B97CE7E.ED6A3D0F@mindspring.com> Date: Thu, 06 Sep 2001 12:29:02 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Ullasan_Kottummal@kindlebanksys.com, freebsd-hackers@FreeBSD.org Subject: Re: Posix Threading References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > >> If the intent is to have "a pool of idle threads", ready to > >> go when you get request traffic, and get around the latency, > >> well, you'd do a lot better in the latency department if you > >> went to a finite state automaton, instead of messing with > >> threads. But if you insist, the best you are going to be > >> able to get is use of a mutex, since a condition variable will > >> result in a "thundering herd" problem. You will still have to > >> eat the latency for the mutex trigger to the thread you give > >> the work to, however (this is how I designed the work-to-do > >> dispatcher in the Pathworks for VMS (NetWare) product for DEC > >> and Novell). > > Most of what you say is ok, but this is wrong. condition variables > do not mandate using a wakeup all strategy. There is such a thing > as 'signal' instead of 'broadcast', which only wakes up one thread. My concern over recommending this would be that it is very implementation dependent as to which thread gets woken up. In Linux, it could result in a full context switch for it to be implemented by the threads system. Also I remembered something about a problem with the implementation from Draft 2, and as I said previously, I had no idea of the compliance level (this is from an experience with adapting the threads in the Standard Template Library, as distributed by the Moscow Supercomputing Center, to so correct "static" mutex initialization). In FreeBSD, you're certainly right, though it will maybe end up having the full context switch overhead (or even CPU selection overhead) once kernel threading via KSE is the norm (but in FreeBSD's implementation, you might be able to argue the same thing about mutex based triggers, if implemented such that the context is not passed off instead -- except that he wanted initial hibernation, and I don't think you could guarantee that with a mutex). FWIW, my implementation in VMS was based on DEC's MTS, which was a BLISS-based call conversion threading package, which I had to extend to have timers, and also had to add all the necessary synchorinization primitives. The basic implementation was made using ASTs with SYS$WAITEFLOR -- wait-event-flag-OR -- very similar to condition variables. The new condition variable primitive wasn't enough to give a guarantee the necessary semantics for the application (a port of Mentat Streams to VMS, in support of the SPX and IPX stacks used by NetWare), and I had to build real Mutex support on top of the primitives to get the packet MUX to do the correct thing. Anyway, there was really not enough information in his request, or my potentially outdated knowledge of pthreads on HP-UX for me to recommend condition variables with the "wake one" semantics. But again, your point is 100% valid for the FreeBSD release version out there, and I *DID* recommend that he switch his application to FreeBSD. ;-). PS: BLISS is ignorance... Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 12:33:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 833B737B406 for ; Thu, 6 Sep 2001 12:33:35 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 2CEDB304; Thu, 6 Sep 2001 20:33:32 +0100 (BST) Date: Thu, 6 Sep 2001 20:33:32 +0100 From: Josef Karthauser To: Eric Anholt Cc: FreeBSD Current Users Subject: Re: DRI, XFree86-4.0.3 and -current. Message-ID: <20010906203332.C3148@tao.org.uk> References: <20010906185732.A3148@tao.org.uk> <01090612161901.00588@positron.anholt.dyn.dhs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01090612161901.00588@positron.anholt.dyn.dhs.org>; from anholt@teleport.com on Thu, Sep 06, 2001 at 12:16:19PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: > I have a page about the DRI for FreeBSD at=20 > http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on= =20 > -stable. There is one compile error on -current that should be obvious t= o=20 > fix in the kernel modules, but I haven't uploaded patches as I haven't=20 > actually tested it yet (I'm still setting up my new -current installation= ). I had a look at that, but it wasn't too clear what I needed to do. I suspect that I'm expecting to checkout the DRI tree _over_ the top of the XFree86-4 tree but perhaps I don't need to do that. Additionally I'm using devfs on -current and I suspect that the r128.ko module doesn't DTRT WRTT. Joe --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuXz4sACgkQXVIcjOaxUBbF/QCdFxLrAg3WFFEoozcQDHWVA8yf nT0AoNLR1PxM5dSnAZ21LsPzi1KM+kL2 =Rsrd -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 12:58:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 8189B37B406; Thu, 6 Sep 2001 12:58:10 -0700 (PDT) Received: from mindspring.com (dialup-209.244.104.168.Dial1.SanJose1.Level3.net [209.244.104.168]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f86Jw4L12715; Thu, 6 Sep 2001 12:58:05 -0700 (PDT) Message-ID: <3B97D579.921CBCE9@mindspring.com> Date: Thu, 06 Sep 2001 12:58:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Podlesny Cc: Gregory Neil Shapiro , freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: auto relaying for subdomains -- why? References: <16615694707.20010905210719@morning.ru> <15254.22980.843972.348805@horsey.gshapiro.net> <8264494448.20010906104039@morning.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Igor Podlesny wrote: > Yes, I saw this info here: > http://www.sendmail.org/m4/features.html#relay_mail_from but most > valuable part of my question was about the purpose or the idea behind > this, cause it's not too clear to me why allowing relaying for domain > FOO.BAR should allow relaying for SUB.FOO.BAR? I mentioned RFCs > because I had a hope to find out the answer from it but still haven't > yet... Whose account name at your customer's site are you going to intentionally render unintelligble, and force them to change their business cards and stationary? Alternately, why wouldn't they just say "screw you", and set their masquerade features to make all the machines lie and say they were sending from the domain? What are you trying to accomplish by prohibiting some machines legitimately in a delegated subdomain (for which account and other authority has been vested in someone other than the main site administrator, such as a departmental administrator) from sending legitimate email? Why do you want them to have to jump through hoops in order to be able to send email which they will ultimately jump through the hoops -- and send through your relay anyway? What possible legitimate purpose is serves by letting send email, but prohibiting from sending mail? I suspect that you are more concerned with having only a single MAIL_HUB relaying email through you, rather than actually prohibiting people from using delegated subdomains. If so, then your problem is because you are trying to use the wrong tool to accomplish your task: do not use domain naming to try to control relaying, or people will simply spoof their source addresses, and relay an incredible amount of SPAM through your mail relays, since they will leak like a sieve. Also note: even if you prohibit outbound, you _can't_ do the same for inbound, without prohibiting delegation of subdomains. This would be like me insisting that you not use the email address , because at the top level, I will only allow relaying for , since "morning.ru" is a delegation from "ru". In other words, if you are trying to solve a problem, tell us the problem, don't ask us how to implement your proposed answer to a secret problem you won't share with us. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 13: 1:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from naboo.ethz.ch (naboo.ethz.ch [129.132.17.66]) by hub.freebsd.org (Postfix) with ESMTP id BA1A937B406 for ; Thu, 6 Sep 2001 13:01:23 -0700 (PDT) Received: by naboo.ethz.ch (Postfix, from userid 224) id 5D598275B6; Thu, 6 Sep 2001 22:01:22 +0200 (CEST) Subject: KSE: mount_msdosfs works again !! To: freebsd-hackers@freebsd.org Date: Thu, 6 Sep 2001 22:01:22 +0200 (CEST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010906200122.5D598275B6@naboo.ethz.ch> From: carlo@vis.ethz.ch (Carlo Dapor) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear KSE guinnea-pigsters The msdos partition mounts again under a KSE kernel. I applied the diff file straight from Julian's home page, dated -rw-r--r-- 1 carlo other 2532518 Sep 6 18:14 thediff and its md5 check sum being. MD5 (thediff) = 867c031f8b3d4278c8bb58db03e020ab As usual, ccd, ncp and smbfs did not compile, but I don't use them. Interestingly, the newly build kernel detects my xl NIC, but the 'normal' kernel does not *shrug*. My next step is to build a KSE kernel with gcc 3.0.1; I know what You are going to say now: why increase complexity ? Don't worry, I won't post any damage detection based on unsing the new gcc. I am simply curious. Ciao, derweil, -- Carlo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 13:17:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 645B137B409; Thu, 6 Sep 2001 13:17:24 -0700 (PDT) Received: from mindspring.com (dialup-209.244.104.168.Dial1.SanJose1.Level3.net [209.244.104.168]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f86KHIL14441; Thu, 6 Sep 2001 13:17:18 -0700 (PDT) Message-ID: <3B97D9FA.BFE4AC15@mindspring.com> Date: Thu, 06 Sep 2001 13:18:02 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Podlesny Cc: Gregory Neil Shapiro , freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: auto relaying for subdomains -- why? References: <16615694707.20010905210719@morning.ru> <15254.22980.843972.348805@horsey.gshapiro.net> <8264494448.20010906104039@morning.ru> <15254.62636.867613.151378@horsey.gshapiro.net> <7575649117.20010906134634@morning.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Igor Podlesny wrote: > Now it's all clear :) and I understand that it was just a way > SENDMAIL's is configured. Another question could be why not to use > syntax .foo.bar instead of foo.bar but I'm quite ready to call it a > rhetorical one ;-)) (regexps are also there ;-) The virtusertable file syntax is such that: foo.bar means "relay for foo.bar, but not *.foo.bar", and: .foo.bar means "relay for *.foo.bar, but not foo.bar", and: foo.bar .foo.bar means "relay for both foo.bar and *.foo.bar". The value of depends on what you want to do with the email, and it is usually a tuple consisting of a mailer and a disposition suffix for that mailer, e.g.: foo.bar local:bob .foo.bar smtp:tom@isp.com means "send all mail with an address in foo.bar to the POP3 mailbox on the local machine for the local user ``bob'', and send all mail for any delegates subdomains of foo.bar to the user ``tom'' with a mail account at another ISP named ``isp.com''". If you need to get this complicated, I suggest you read the sendmail FAQ, or buy a copy of the O'Reilly Sendmail book. > P.P.S. I'm not quite sure should I start new thread or can remain > within it with another question which is: What MTA software supports > highly configurable relaying... One of the needed features is a > support for using alternative mail routers (relays) in case when this > MTA can't send a message by itself because of networks problem. Sendmail... this is handled by the SMART_HOST feature of sendmail. > For example situation could be: MTA is on a network A which is temporarily > cut off from it's uplink so it can't transfer mail by itself, but it > has a connection (permanent or dial-up) to another mailer. Mail routing is via DNS. If you are on the other side of a dialup, you should mark the mailer expensive, set HoldExpensive to "True", and then explicitly do the queue run in your link-up script, or, if you prefer, at intervals. Generally, what you want to do is a bad idea, since the best way to handle this if you have an unreliable permanent connection, is to simply use your other connection to contact the same list of MX's that it would have contacted anyway. > Are there such MTAs which can be said "if you can't send it > by yourself (would be cool if additional parameters > were some_time_period and failure_reason) then use that MTA > (ip-addr) or that (another-ip)?". By IP address is a bad idea, though it could be done. > I suspect in common case such "system" could easily lead to > loops and have other drawbacks but in such simple > configuration it seems all should work fine... Not really. But it will take you some amount of time to configure this correctly, and to get your back end infrastructure in place. I did this work for IBM Web Connections, and it took us 3 months to do the back end stuff, and 8 months to do all the client side stuff, so that it was all turn key. Basically, you are asking for a huge technology transfer, which generally runs most ISPs several hundreds of thousands of dollars to acquire. With the questions you are asking, you will probably need to buy or license it from someone. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 13:37:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 878F837B405; Thu, 6 Sep 2001 13:37:50 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 492BC66D67; Thu, 6 Sep 2001 13:37:50 -0700 (PDT) Date: Thu, 6 Sep 2001 13:37:50 -0700 From: Kris Kennaway To: Ruslan Ermilov Cc: Kris Kennaway , hackers@FreeBSD.org Subject: Re: undocumented wall(1) feature Message-ID: <20010906133750.G18228@xor.obsecurity.org> References: <20010906030656.C2453@xor.obsecurity.org> <20010906160854.K18362@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="iAL9S67WQOXgEPD9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906160854.K18362@sunbay.com>; from ru@FreeBSD.org on Thu, Sep 06, 2001 at 04:08:54PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --iAL9S67WQOXgEPD9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 04:08:54PM +0300, Ruslan Ermilov wrote: > On Thu, Sep 06, 2001 at 03:06:57AM -0700, Kris Kennaway wrote: > > Does anyone object to this? > >=20 > Just a bit of history. This has been added with this CSRG > commit: >=20 > : D 4.5 81/06/12 13:23:15 root 5 4 00003/00001/00129 > : MRs: > : COMMENTS: > : I suppressed wall messages to the sleeper program >=20 > Not sure what does it mean. Perhaps, at that times, > the sleeper existed as a user process and was run > under the sleeper user. Bizarre :) Kris --iAL9S67WQOXgEPD9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7l96dWry0BWjoQKURAtg+AKDis3sU2zOJDbYqD3+B3K2hFMU9HACgsRfU YUzYgen+LOzuwrLb1Bz5ZRM= =F9zD -----END PGP SIGNATURE----- --iAL9S67WQOXgEPD9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 13:46: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cognet.ci0.org (aboukir-101-1-4-cognet.adsl.nerim.net [80.65.224.102]) by hub.freebsd.org (Postfix) with ESMTP id 8D49737B403 for ; Thu, 6 Sep 2001 13:46:02 -0700 (PDT) Received: from nerim.net (localhost [127.0.0.1]) by cognet.ci0.org (8.11.6/8.11.4) with ESMTP id f86Kjpx20564; Thu, 6 Sep 2001 22:45:51 +0200 (CEST) (envelope-from cognet@nerim.net) Message-ID: <3B97E07F.CDAC79F2@nerim.net> Date: Thu, 06 Sep 2001 22:45:51 +0200 From: Olivier Houchard Organization: CIO X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Josef Karthauser Cc: FreeBSD Current Users Subject: Re: DRI, XFree86-4.0.3 and -current. References: <20010906185732.A3148@tao.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Josef Karthauser wrote: > > Has anyone got patches for DRI under -current? > > Joe > > I made an ugly patch so that the drm, gamma and tdfx kernel modules compile under current. I submitted it to DRI, so you may find it at dri.sourceforge.net. By the way no it doesn't work with devfs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 13:46:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7AA5C37B403 for ; Thu, 6 Sep 2001 13:46:47 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA30213; Thu, 6 Sep 2001 14:12:07 -0700 (PDT) Date: Thu, 6 Sep 2001 14:12:06 -0700 (PDT) From: Julian Elischer To: Carlo Dapor Cc: freebsd-hackers@freebsd.org Subject: Re: KSE: mount_msdosfs works again !! In-Reply-To: <20010906200122.5D598275B6@naboo.ethz.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG probably better in -current than hackers :-) hmm I can't think of a change that would have done that... I gotta get to smbfs and nwfs... On Thu, 6 Sep 2001, Carlo Dapor wrote: > Dear KSE guinnea-pigsters > > The msdos partition mounts again under a KSE kernel. > I applied the diff file straight from Julian's home page, dated > > -rw-r--r-- 1 carlo other 2532518 Sep 6 18:14 thediff > > and its md5 check sum being. > > MD5 (thediff) = 867c031f8b3d4278c8bb58db03e020ab > > As usual, ccd, ncp and smbfs did not compile, but I don't use them. > Interestingly, the newly build kernel detects my xl NIC, but the 'normal' > kernel does not *shrug*. > > My next step is to build a KSE kernel with gcc 3.0.1; I know what You are > going to say now: why increase complexity ? Don't worry, I won't post any > damage detection based on unsing the new gcc. I am simply curious. > > Ciao, derweil, thanks for testing.. > -- > Carlo > > 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 Sep 6 15:13:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [216.188.96.212]) by hub.freebsd.org (Postfix) with ESMTP id 9B98C37B403 for ; Thu, 6 Sep 2001 15:13:55 -0700 (PDT) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id f86M9Aj69475 for ; Thu, 6 Sep 2001 15:09:10 -0700 (PDT) (envelope-from john@kozubik.com) Date: Thu, 6 Sep 2001 15:09:10 -0700 (PDT) From: John Kozubik To: hackers@freebsd.org Subject: OT: firewire slugs available ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the near future I will be doing some research and development with IEEE 1394. Such that I will be requiring a _large_ number of firewire devices. It is not within my budget to purchase 63 x 4 cameras. So I was trying to think of the cheapest possible IEEE 1394 device - if worst comes to worse I could just buy 252 of those ... again, not very practicle. IEEE 1394 chipsets, however, are about $8.00 each. Has anyone seen IEEE 1394 "slugs" - devices that perform basic functionality (in terms of participating on the bus) but not much else ? (presumably, if these devices exist, they were developed for just this type of development) Comments and information appreciated. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 16:13:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ntlg.sibnet.ru (dns.sibnet.ru [217.70.96.34]) by hub.freebsd.org (Postfix) with ESMTP id B7E7D37B403 for ; Thu, 6 Sep 2001 16:13:26 -0700 (PDT) Received: from tlg5-ppp48.sibnet.ru (tlg5-ppp48.sibnet.ru [217.70.97.49]) by ntlg.sibnet.ru (8.9.3+Sun/8.9.3) with ESMTP id DAA12644 for ; Fri, 7 Sep 2001 03:13:20 +0400 (MSD) Date: Fri, 7 Sep 2001 06:14:04 +0600 (GMT+6) From: "Semen A. Ustimenko" X-Sender: semenu@default To: freebsd-hackers@FreeBSD.org Subject: NFS read cache and fcntl locking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I wonder how can userlevel process turn NFS-client's read cache off: Turn off attribute caching? Use fcntl lock triggering to invalidate the cache? Other way? Bye! P.S: The ac(reg|dir)(min|max) options of mount_nfs are not taking effect right now due to 4 missing lines in mount_nfs.c. I filled PR bin/30334 with a fix, so please somebody brave enough, take a look... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 6 16:43:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id C7E2D37B403 for ; Thu, 6 Sep 2001 16:43:15 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 96340305; Fri, 7 Sep 2001 00:43:14 +0100 (BST) Date: Fri, 7 Sep 2001 00:43:14 +0100 From: Josef Karthauser To: Eric Anholt Cc: FreeBSD Current Users Subject: Re: DRI, XFree86-4.0.3 and -current. Message-ID: <20010907004314.E8285@tao.org.uk> References: <20010906185732.A3148@tao.org.uk> <01090612161901.00588@positron.anholt.dyn.dhs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wTWi5aaYRw9ix9vO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01090612161901.00588@positron.anholt.dyn.dhs.org>; from anholt@teleport.com on Thu, Sep 06, 2001 at 12:16:19PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --wTWi5aaYRw9ix9vO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: > I have a page about the DRI for FreeBSD at=20 > http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on= =20 > -stable. There is one compile error on -current that should be obvious t= o=20 > fix in the kernel modules, but I haven't uploaded patches as I haven't=20 > actually tested it yet (I'm still setting up my new -current installation= ). I'll test it for you with my AGP MOBILE M3 if you send me the bits and tell me where to install them ;). Joe --wTWi5aaYRw9ix9vO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuYChIACgkQXVIcjOaxUBbTLgCghvCDVvoNVc95TlmwyEeGc6hs pk0Ani1+f4B2/EpEjGgHiCEagArQX2nU =d/E8 -----END PGP SIGNATURE----- --wTWi5aaYRw9ix9vO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 2:56:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ranger.acns.ab.ca (h24-68-206-125.sbm.shawcable.net [24.68.206.125]) by hub.freebsd.org (Postfix) with ESMTP id CF90E37B406 for ; Fri, 7 Sep 2001 02:56:39 -0700 (PDT) Received: from colnta.acns.ab.ca (colnta [192.168.1.2]) by ranger.acns.ab.ca (8.11.6/8.11.3) with ESMTP id f8790RN09239 for ; Fri, 7 Sep 2001 03:00:28 -0600 (MDT) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id f876Ufj61084 for hackers@freebsd.org; Fri, 7 Sep 2001 00:30:41 -0600 (MDT) (envelope-from davidc) Date: Fri, 7 Sep 2001 00:30:41 -0600 From: Chad David To: hackers@freebsd.org Subject: ipfw and access Message-ID: <20010907003041.A61061@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I was just wondering about the caveat in that access(2) man page that says that access is a potential security hole and should never be used, and the fact that ipfw calls it on line 2435. I seem to recall a discussion about this a few months ago, but I don't really remember the details... and the irony of ipfw calling a documented "should never be used" function got my attention. Is this really a problem, or is the man page paranoid? Thanks -- Chad David davidc@acns.ab.ca ACNS Inc. Calgary, Alberta Canada I applied the patch twice, and it still doesn't work! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 3:13: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from r220-1.rz.RWTH-Aachen.DE (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by hub.freebsd.org (Postfix) with ESMTP id EE14A37B403 for ; Fri, 7 Sep 2001 03:13:02 -0700 (PDT) Received: from r220-1.rz.RWTH-Aachen.DE (relay2.RWTH-Aachen.DE [134.130.3.1]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3-2) with ESMTP id f87AD3c22083; Fri, 7 Sep 2001 12:13:03 +0200 (MEST) Received: from hyperion.informatik.rwth-aachen.de (hyperion.Informatik.RWTH-Aachen.de [137.226.112.212]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3/5) with ESMTP id f87AD2u22079; Fri, 7 Sep 2001 12:13:02 +0200 (MEST) Received: from agamemnon.informatik.rwth-aachen.de (agamemnon.Informatik.RWTH-Aachen.DE [137.226.194.74]) by hyperion.informatik.rwth-aachen.de (8.9.1b+Sun/8.9.1) with ESMTP id MAA03213; Fri, 7 Sep 2001 12:11:36 +0200 (MET DST) Received: (from stolz@localhost) by agamemnon.informatik.rwth-aachen.de (8.9.1b+Sun/8.9.1-gb-2) id MAA00948; Fri, 7 Sep 2001 12:12:57 +0200 (MET DST) Date: Fri, 7 Sep 2001 12:12:57 +0200 From: Volker Stolz To: Josef Karthauser Cc: freebsd-hackers@freebsd.org Subject: Re: DRI, XFree86-4.0.3 and -current. Message-ID: <20010907121257.A944@i2.informatik.rwth-aachen.de> References: <20010906185732.A3148@tao.org.uk> <01090612161901.00588@positron.anholt.dyn.dhs.org> <20010906203332.C3148@tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010906203332.C3148@tao.org.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In local.freebsd-hackers, you wrote: > On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: >> I have a page about the DRI for FreeBSD at=20 >> http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on= > > I had a look at that, but it wasn't too clear what I needed to do. I > suspect that I'm expecting to checkout the DRI tree _over_ the top of > the XFree86-4 tree but perhaps I don't need to do that. Neither was I. Could you clarify on merging XFree from the ports and the CVS? I tried copying the CVS-stuff over the port, but the build stopped with: cleaning in programs/Xserver/hw/xfree86/input/calcomp... cd: can't cd to calcomp [Might be my fault, after-all. R-To: -multimedia?] -- Neues aus Genua? http://germany.indymedia.org/ Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 3:18:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id B58A437B406 for ; Fri, 7 Sep 2001 03:18:43 -0700 (PDT) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id 5E65A3E31; Fri, 7 Sep 2001 03:18:43 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id 4C95A3C12E; Fri, 7 Sep 2001 03:18:43 -0700 (PDT) To: Chad David Cc: hackers@freebsd.org Subject: Re: ipfw and access In-Reply-To: <20010907003041.A61061@colnta.acns.ab.ca>; from davidc@acns.ab.ca on "Fri, 7 Sep 2001 00:30:41 -0600" Date: Fri, 07 Sep 2001 03:18:38 -0700 From: Dima Dorfman Message-Id: <20010907101843.5E65A3E31@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Chad David wrote: > I was just wondering about the caveat in that access(2) man page > that says that access is a potential security hole and should > never be used, and the fact that ipfw calls it on line 2435. > > I seem to recall a discussion about this a few months ago, but > I don't really remember the details... and the irony of ipfw > calling a documented "should never be used" function got my > attention. > > Is this really a problem, or is the man page paranoid? The manual page is probably paranoid, but I don't think we should change it. It's very easy to abuse access(2). It's a potential security hole if you use it to provide access control. E.g., you're a setuid process, and you got a filename as an argument. You want to open it, but only if the user that called you has sufficient privileges to do so. Using access(2) on that filename and opening it if it returns success would be a security hole, because that file might've changed (mv, cp, chmod, whatever) between your call to access(2) and your call to open(2) (classic example of a race condition). The right thing to do would be to drop effective privileges to that of the user, and use open(2) directly. ipfw just wants to know if its last argument is a valid filename (see the first usage form in the manual page). I think that's a pretty legitimate use, although it shouldn't rely on the fact that the file will exist and/or be readable when it gets around to opening it. I.e., it should still handle a failed open gracefully--and it does. One can still trick it into trying to open a file that isn't there, but the results won't be any more spectacular than doing that to any other program (e.g., `cat /nonexistent`). Besides, ipfw isn't privileged. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 3:44:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 2315237B403; Fri, 7 Sep 2001 03:44:15 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id NQY70812; Fri, 7 Sep 2001 13:44:03 +0300 (EEST) (envelope-from vovik) Date: Fri, 7 Sep 2001 13:44:03 +0300 From: "Vladimir A. Jakovenko" To: Terry Lambert Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010907134403.T2693@lucky.net> References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B947922.F8B98DBD@mindspring.com>; from tlambert2@mindspring.com on Mon, Sep 03, 2001 at 11:48:02PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 03, 2001 at 11:48:02PM -0700, Terry Lambert wrote: >"Vladimir A. Jakovenko" wrote: >> >> Hello! >> >> According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than >> one socket to the same port (even with same source ip address). But quick >> look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will >> work as expected (data stream duplicate) only on multicast/broadcast local >> addresses. Please pay attention to the following code fragment comments: > >[ ... ] > >> Is there still any real need in such backward compatibility? Can such >> functionality be added (fixed) with possibility to switch it off using >> sysctl or kernel-build option? >> >> I find such possibility realy useful at least for NetFlow data >> processing and believe that it would be useful for many UDP-based >> protocols. > >Bound UDP sockets have always been problematic; there's a lot >of code out there that depnds on the historical behaviour for >unicast, unfortunately, including a number of commercial >applications that run on FreeBSD (e.g. Real Server). > >If you look at that code for any length of time, you will get >to see it as an armpit: it's not a good place to stick your >nose, and it tends to smell to high heaven. At my current >job, I'm up to my elbows in it... Terry, I clearly understand all your explanations. Yes, we are living in real life and there is a lot of programms with bad design. But all what I want is possibility to receive UDP packets with corresponding dst IP and port by more than one process on a single host. This already works for Broadcast and Multicast addresses. If I want to get same functionality for unicast (without any kernel changes) I have to use UDP-proxy, which redirects given datagrams to loopback broadcast address, where they can be received by more that one process. According to comment in udp_input() SO_REUSEPORT hack on unicast sockets could be used in single process, right? How possibility to get duplicate traffic on two UDP sockets, which was created in _different_ processes with the same local address and port values, would break existing applications? -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 3:53:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from web11108.mail.yahoo.com (web11108.mail.yahoo.com [216.136.131.155]) by hub.freebsd.org (Postfix) with SMTP id C65B637B408 for ; Fri, 7 Sep 2001 03:53:16 -0700 (PDT) Message-ID: <20010907105316.17187.qmail@web11108.mail.yahoo.com> Received: from [212.250.115.247] by web11108.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 11:53:16 BST Date: Fri, 7 Sep 2001 11:53:16 +0100 (BST) From: =?iso-8859-1?q?Philip=20Taylor?= Subject: Interest Contributing to the FreeBsd To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello Freebsd I have used FreeBsd For several Months including using linux and unix for about 5 Years. I have studied Information Technology and Programming for two years. I have came to the point where i believe i could help in building Freebsd. Could you please send me some information about how i can help. Philip Taylor ===== This Project Bebox2 will happy to help you with all your Beos and Machines bought from us. ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 3:58: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 0553F37B401 for ; Fri, 7 Sep 2001 03:58:07 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 49E5266D24; Fri, 7 Sep 2001 03:58:06 -0700 (PDT) Date: Fri, 7 Sep 2001 03:58:05 -0700 From: Kris Kennaway To: Philip Taylor Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Interest Contributing to the FreeBsd Message-ID: <20010907035805.A49934@xor.obsecurity.org> References: <20010907105316.17187.qmail@web11108.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907105316.17187.qmail@web11108.mail.yahoo.com>; from bebox2uk@yahoo.co.uk on Fri, Sep 07, 2001 at 11:53:16AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 11:53:16AM +0100, Philip Taylor wrote: > Hello Freebsd >=20 > I have used FreeBsd For several Months including using > linux and unix for about 5 Years. I have studied > Information Technology and Programming for two years. > I have came to the point where i believe i could help > in building Freebsd.=20 > Could you please send me some information about how i > can help. Find something to contribute, and contribute it :) You might like to start with an open PR in the PR database. Kris --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7mKg8Wry0BWjoQKURAuOiAKDcMtBliZEI4XYLJT7HV9Qis92FdwCeMou8 DmnC5z0+pWuSGpg61mvc8RA= =xeBX -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 4:52:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 95B1E37B403 for ; Fri, 7 Sep 2001 04:52:36 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 28A68304; Fri, 7 Sep 2001 12:52:35 +0100 (BST) Date: Fri, 7 Sep 2001 12:52:35 +0100 From: Josef Karthauser To: Olivier Houchard Cc: FreeBSD Current Users Subject: Re: DRI, XFree86-4.0.3 and -current. Message-ID: <20010907125235.L3148@tao.org.uk> References: <20010906185732.A3148@tao.org.uk> <3B97E07F.CDAC79F2@nerim.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7vLGWvOrvbSM0Ba8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B97E07F.CDAC79F2@nerim.net>; from cognet@nerim.net on Thu, Sep 06, 2001 at 10:45:51PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --7vLGWvOrvbSM0Ba8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2001 at 10:45:51PM +0200, Olivier Houchard wrote: > Josef Karthauser wrote: > >=20 > > Has anyone got patches for DRI under -current? > >=20 > > Joe > >=20 > > =20 > I made an ugly patch so that the drm, gamma and tdfx kernel modules > compile under current. I submitted it to DRI, so you may find it at > dri.sourceforge.net. By the way no it doesn't work with devfs. I couldn't find the patch at sourceforge. Would you mind mailing it to me too? Thanks, Joe --7vLGWvOrvbSM0Ba8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuYtQIACgkQXVIcjOaxUBbiBACaAlgkMg1MqpV02rQ9S0Cccq7p umkAn37jHBonzRbDU6K8cSX5QwzL/fbz =yhu2 -----END PGP SIGNATURE----- --7vLGWvOrvbSM0Ba8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 7:35: 4 2001 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 9542237B40D; Fri, 7 Sep 2001 07:34:36 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f87EYTP96004; Fri, 7 Sep 2001 10:34:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Sep 2001 10:34:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-hackers@FreeBSD.org, developers@FreeBSD.org Subject: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Submissions are due this afternoon. Please submit by e-mail ASAP. We're currently substantially behind prior months -- this is in some ways expected due to various people on summer vacations in the Northern Hemisphere, but it would be nice to get things a bit more fleshed up. In particular, I'd like to see reports on: - Documentation and web work - Release engineering for 4.4-RELEASE - SMPng - KAME - Other on-going network stack changes - Ports to other platforms, including ia64, sparc64 - Hardware driver work - PR management - Security officer work Etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ---------- Forwarded message ---------- Date: Tue, 4 Sep 2001 12:54:24 -0400 (EDT) From: Robert Watson To: developers@FreeBSD.org, hackers@FreeBSD.org Subject: REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions It's that time again! I'm in the process of preparing the August, 2001 FreeBSD monthly status report, and as such am interested in seeing submissions in much the same style as previous months. Generally, this means about one paragraph of text per project describing events that have occured since the last status report (or two paragraphs for new projects, so as to introduce them). Large projects can be broken down into multiple sub-projects with seperate reports reports. If multiple developers are working on the same project, they should coordinate so as to submit only one report (or split it up into parts as appropriate along logical boundaries). Reports should relate to the FreeBSD Project, but are not limited to on-going software development: documentation, public relations, management, application developer relations, technology transfer, etc, are all relevant. Please submit reports in the following format: Project: (name here -- required field) URL: (URL, if any, here -- omit field if none) Contact: (name and e-mail address of one or more contact points -- required field) One paragraph on the topic of project status since the last report, indented two spaces, and wrapped at column 78. Plain text only, please. Please send submissions to: robert+freebsd.monthly@cyrus.watson.org The deadline for submissions is September 7, 2001, at 3:00pm EST. The report will be released soon thereafter. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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 Fri Sep 7 7:40:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (sentinel.office1.bg [217.75.135.254]) by hub.freebsd.org (Postfix) with SMTP id 9C89A37B405 for ; Fri, 7 Sep 2001 07:40:44 -0700 (PDT) Received: (qmail 1606 invoked by uid 1000); 7 Sep 2001 14:40:20 -0000 Date: Fri, 7 Sep 2001 17:40:20 +0300 From: Peter Pentchev To: void Cc: Andrey Simonenko , freebsd-hackers@freebsd.org Subject: Re: Permissions on /root directory and /etc/mtree/BSD.root.dist Message-ID: <20010907174020.D638@ringworld.oblivion.bg> Mail-Followup-To: void , Andrey Simonenko , freebsd-hackers@freebsd.org References: <004f01c1369d$5fc07ba0$6d36120a@comsys.ntukpi.kiev.ua> <20010906202334.A6682@firedrake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010906202334.A6682@firedrake.org>; from float@firedrake.org on Thu, Sep 06, 2001 at 08:23:34PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 06, 2001 at 08:23:34PM +0100, void wrote: > On Thu, Sep 06, 2001 at 10:30:08AM +0400, Andrey Simonenko wrote: > > > > 0700 mode restricts other users from reading /root directory. > > When root wants to upgrade system he/she run "make buildworld", > > "make installworld". But installworld calls mtree, which changes > > /root permissions to default value specified in the /etc/mtree/BSD.root.dist > > file. So, if administrator will not forgot about needed permissions > > on /root, then installworld will open /root directory for reading > > for everybody. > > > > I propose not to change permissions on /root directory in > > the /etc/mtree/BSD.root.dist file and leave them unchanged. > > > > Comments? > > There is a whole class of problems like this. For example, my > installation of mutt doesn't work right if /var/mail is not mode 1777, > but BSD.var.dist changes it to 755 every time I installworld. > > I think a more general solution might be in order. Perhaps some sort > of local.dist that is processed after BSD.*.dist. > > As a workaround, I put "chmod 1777 /var/mail" in my rc.local script. > I suggest you do something similar. And then, of course, there is the obvious solution: maintaining some local patches, applied to the source tree after each update. (and reversed before each update..) This is the way I'm doing it, but then, I have a *lot* of local changes, and such an approach might not make sense for a single change like that.. G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 9:21:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 73C8B37B405; Fri, 7 Sep 2001 09:21:16 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f87GLK218174; Fri, 7 Sep 2001 17:21:20 +0100 (BST) (envelope-from nik) Date: Fri, 7 Sep 2001 17:21:20 +0100 From: Nik Clayton To: Robert Watson Cc: freebsd-hackers@FreeBSD.org, developers@FreeBSD.org Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions Message-ID: <20010907172120.N66592@clan.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="JWJEtCrVvH5hpatL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Fri, Sep 07, 2001 at 10:34:29AM -0400 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --JWJEtCrVvH5hpatL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 10:34:29AM -0400, Robert Watson wrote: > Project: (name here -- required field) > URL: (URL, if any, here -- omit field if none) > Contact: (name and e-mail address of one or more contact points -- > required field) Project: Documentation Project URL: http://www.FreeBSD.org/docs.html URL: http://www.FreeBSD.org/docproj/index.html Contact: Documentation Project The Handbook has been the main focus of activity this month. Due to go to the printers on the 15th a vast amount of new content has been submitted and committed. This includes a complete rewrite of the "Installing FreeBSD", which massively expands the amount of information available to people new to FreeBSD. It even includes screenshots. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html Comments, and contributions are, of course, welcome. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --JWJEtCrVvH5hpatL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuY8/4ACgkQk6gHZCw343XaNwCfVxrbGUMMXrcYE6VAbJcd02/y 44wAn0+KHpfQEl6Yz0u8PBeFcdgoI9nC =k3uw -----END PGP SIGNATURE----- --JWJEtCrVvH5hpatL-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 10:26: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9508437B401 for ; Fri, 7 Sep 2001 10:25:59 -0700 (PDT) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA34649; Fri, 7 Sep 2001 10:43:44 -0700 (PDT) Message-ID: <3B98FF2E.2E7C3472@elischer.org> Date: Fri, 07 Sep 2001 10:09:02 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Philip Taylor Cc: freebsd-hackers@FreeBSD.org Subject: Re: Interest Contributing to the FreeBsd References: <20010907105316.17187.qmail@web11108.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Philip Taylor wrote: > > Hello Freebsd > > I have used FreeBsd For several Months including using > linux and unix for about 5 Years. I have studied > Information Technology and Programming for two years. > I have came to the point where i believe i could help > in building Freebsd. > Could you please send me some information about how i > can help. Since this is a volunteer project there is no formal "you should do this" list. 1/ find somthing you'd LIKE to do 2/ see if someone is doing it (search the mailing lists etc.) 3/ contact them (also check CVS logs of associated files to see who may be actually checking the stuff in and contact them too) ask them if you can help them test/develop their project.. 4/ get more involved with time and use all your free time :-) > > Philip Taylor > > ===== > This Project Bebox2 will happy to help you with all your Beos and Machines bought from us. > > ____________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > or your free @yahoo.ie address at http://mail.yahoo.ie > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12: 0:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 39E4737B401; Fri, 7 Sep 2001 12:00:19 -0700 (PDT) Received: from mindspring.com (dialup-209.247.142.57.Dial1.SanJose1.Level3.net [209.247.142.57]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f87J06325278; Fri, 7 Sep 2001 12:00:06 -0700 (PDT) Message-ID: <3B991962.C8D0A398@mindspring.com> Date: Fri, 07 Sep 2001 12:00:50 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Jakovenko" Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Vladimir A. Jakovenko" wrote: > Terry, I clearly understand all your explanations. Yes, we are living in > real life and there is a lot of programms with bad design. > > But all what I want is possibility to receive UDP packets with > corresponding dst IP and port by more than one process on a single > host. This already works for Broadcast and Multicast addresses. If > I want to get same functionality for unicast (without any kernel > changes) I have to use UDP-proxy, which redirects given datagrams > to loopback broadcast address, where they can be received by more > that one process. Yes. > According to comment in udp_input() SO_REUSEPORT hack on unicast > sockets could be used in single process, right? Yes. > How possibility to get duplicate traffic on two UDP sockets, which > was created in _different_ processes with the same local address > and port values, would break existing applications? Consider a UDP based reliable delivery protocol that cares about key frames, but not about all frames. A good example of this would be any RTSP/RTP type protocol implemented on UDP, which was used to implement streaming video of a live broadcast, using limited buffer space. In this situation, the video is delivered by sending a key frame, and then subsequent data is sent as deltas on that key frame. Effectively, this MUXes two protocols: a reliable datagram protocol containing the key frames, and an unreliable protocol containing the deltas, over a single channel. This method of key frame use is the same method used to encode DVD data and a number of real time streaming protocols, including a number of streaming video protocols running over UDP (the original technique was pioneered by a company named CinemaWare, a Utah-based developer of Amiga software, which used a technique called "cell animation" to reduce image data size requirements). Your hypothetical two-process-no-proxy program would not correctly acknowledge key frames consisting of more than one UDP packet, unless you delivered the unicast to both. If you delivered the unicast to both, you would need to build an "acknowledgement proxy", which would only acknowledge when the entire key frame had been received by *both* processes. Taking an even simpler case, you could build a UDP packet payload classifier, which would classify UDP packets based on payload (size, etc.), and report statistics at the end of a run. Your change would result in erroneous reporting. On a philosophical note, it's questionable about whether a unicast is directed to an IP/port pair, or whether it is directed to a particular application, and the IP/port pair, or even the UDP protocol, are just a necessary vehicle for the delivery of the information. On a practical note, if you could fix the multiple delivery problem, so that only one listener got the packet, this would address many, but not all, of the objections above(*). On a purely technical note, I think you want to use something other than unicast for your implementation: multicast group seems to be the most correct fit (I am in the camp that a unicast is directed at an application, not merely a machine). (*) You would still have the problem of a meta relationship between multiple packets, and you would still have the problem of "correctly" selecting who would get the packet; right now, the behaviour is "first listener", not LRU more MRU... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12: 4:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 072A437B406; Fri, 7 Sep 2001 12:04:41 -0700 (PDT) Received: from mindspring.com (dialup-209.247.142.57.Dial1.SanJose1.Level3.net [209.247.142.57]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f87J4d319300; Fri, 7 Sep 2001 12:04:39 -0700 (PDT) Message-ID: <3B991A74.6CEE1FA9@mindspring.com> Date: Fri, 07 Sep 2001 12:05:24 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: freebsd-hackers@FreeBSD.org, developers@FreeBSD.org Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > > Submissions are due this afternoon. Please submit by e-mail ASAP. We're > currently substantially behind prior months -- this is in some ways > expected due to various people on summer vacations in the Northern > Hemisphere, but it would be nice to get things a bit more fleshed up. In > particular, I'd like to see reports on: You should add a section for academic research and commercial users of FreeBSD. This might not be keeping with the philosophy, though, since most of us do not trust -current enough to do our PhD Thesis, Master's Project, or business work on it, and tend to create derivative works of -stable, instead... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12: 7:45 2001 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 B8AFA37B401; Fri, 7 Sep 2001 12:07:36 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f87J7SP99605; Fri, 7 Sep 2001 15:07:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Sep 2001 15:07:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: freebsd-hackers@FreeBSD.org, developers@FreeBSD.org Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions In-Reply-To: <3B991A74.6CEE1FA9@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Sep 2001, Terry Lambert wrote: > Robert Watson wrote: > > > > Submissions are due this afternoon. Please submit by e-mail ASAP. We're > > currently substantially behind prior months -- this is in some ways > > expected due to various people on summer vacations in the Northern > > Hemisphere, but it would be nice to get things a bit more fleshed up. In > > particular, I'd like to see reports on: > > You should add a section for academic research and commercial users of > FreeBSD. > > This might not be keeping with the philosophy, though, since most of us > do not trust -current enough to do our PhD Thesis, Master's Project, or > business work on it, and tend to create derivative works of -stable, > instead... I'd be interested in seeing submissions of this sort, including mass deployment, new research done on the platform, etc. The development status report is limited to new development on -CURRENT, and can include status on merging of features to -stable, the release process, etc. At one point, Jordan was spitting out a FreeBSD news letter once in a while. Dunno if we'll ever see it again, but I thought that was a good idea, and was part of the impetus for exploring a monthly electronic report. Of course, I've never received status information from Jordan :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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 Fri Sep 7 12:21: 1 2001 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 3A21437B406; Fri, 7 Sep 2001 12:20:56 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f87JKmP99721; Fri, 7 Sep 2001 15:20:48 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Sep 2001 15:20:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: freebsd-hackers@FreeBSD.org, developers@FreeBSD.org Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions In-Reply-To: <3B991A74.6CEE1FA9@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Sep 2001, Terry Lambert wrote: > This might not be keeping with the philosophy, though, since most of us > do not trust -current enough to do our PhD Thesis, Master's Project, or > business work on it, and tend to create derivative works of -stable, > instead... It should be noted, of course, that for successful technology transfer, it really good idea to target -CURRENT regardless of the ups and downs of -CURRENT: otherwise you find your work stuck in a backwater and lost (witness the lottery scheduling support, and many other things..). Part of the problem here is that often research funding waves its hands at technology transfer, but doesn't cover the day-to-day activity of merging and tracking a moving target, which is required to work on both Linux and FreeBSD. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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 Fri Sep 7 12:31:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by hub.freebsd.org (Postfix) with ESMTP id 0AE6137B405 for ; Fri, 7 Sep 2001 12:31:37 -0700 (PDT) Received: from unity.ncsu.edu (convent.csc.ncsu.edu [152.14.51.152]) by uni02mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id PAA26848 for ; Fri, 7 Sep 2001 15:31:32 -0400 (EDT) Message-ID: <3B991EB3.1770F47@unity.ncsu.edu> Date: Fri, 07 Sep 2001 15:23:31 -0400 From: Ashley Thomas Organization: NCSU X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Compiling source code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Could anybody give me some info about 'how to compile the FreeBSD source code' and run. Any pointers to useful links will also suffice. thanks a lot ashley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12:47:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 7F99A37B401 for ; Fri, 7 Sep 2001 12:47:32 -0700 (PDT) Received: (qmail 90915 invoked by uid 3130); 7 Sep 2001 19:47:30 -0000 Date: Fri, 7 Sep 2001 15:47:30 -0400 From: Garrett Rooney To: Ashley Thomas Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Compiling source code Message-ID: <20010907154729.B97109@electricjellyfish.net> References: <3B991EB3.1770F47@unity.ncsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B991EB3.1770F47@unity.ncsu.edu>; from athomas@unity.ncsu.edu on Fri, Sep 07, 2001 at 03:23:31PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 03:23:31PM -0400, Ashley Thomas wrote: > Hi, > > Could anybody give me some info about 'how to compile the FreeBSD source > code' and run. > Any pointers to useful links will also suffice. first, this isn't the proper mailing list for this type of question. freebsd-questions@freebsd.org would be much more appropriate. second, check out the freebsd handbook, at http://freebsd.org/handbook for the answer to your question and a whole lot more... -- garrett rooney Unix was not designed to stop you from rooneg@electricjellyfish.net doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12:54:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id D227937B401; Fri, 7 Sep 2001 12:54:03 -0700 (PDT) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id f87JrmT38198; Fri, 7 Sep 2001 12:53:48 -0700 (PDT) (envelope-from jkh@freebsd.org) To: rwatson@freebsd.org Cc: tlambert2@mindspring.com, freebsd-hackers@freebsd.org, developers@freebsd.org Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions In-Reply-To: References: <3B991A74.6CEE1FA9@mindspring.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010907125348E.jkh@freebsd.org> Date: Fri, 07 Sep 2001 12:53:48 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > status on merging of features to -stable, the release process, etc. At > one point, Jordan was spitting out a FreeBSD news letter once in a while. > Dunno if we'll ever see it again, but I thought that was a good idea, and > was part of the impetus for exploring a monthly electronic report. > > Of course, I've never received status information from Jordan :-). I know, I know, life's been rather extremely busy. I'd love to revive the newsletter, believe me, though I also think that DaemonNews and other publications like it have admirably filled the niche. We just need to provide them with material from time to time. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 12:55:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id A890C37B403 for ; Fri, 7 Sep 2001 12:55:10 -0700 (PDT) Received: from opal (cs.binghamton.edu [128.226.123.101]) by bingnet2.cc.binghamton.edu (8.11.4/8.11.4) with ESMTP id f87Jt6K08284 for ; Fri, 7 Sep 2001 15:55:06 -0400 (EDT) Date: Fri, 7 Sep 2001 15:55:05 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@opal To: freebsd-hackers@freebsd.org Subject: Error of BUF_STRATEGY() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I use BUF_STRATEGY() in a kernel module to read a sector on a device like /dev/ad0s3g. The biowait() routine after BUF_STRATEGY() gives me errors like EALREADY and EPERM from time to time. I find out that these errors occur after I already wrote the same device by another program. If I wait a bit longer or try again, the BUF_STRATEGY() works fine and no error happens. I am wondering who is giving these errors. Is it the hardware? If so, the kernel should somehow translate the hardware error to EALREADY and EPERM. What is the exact meaning of these two errors? Thanks, -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 13: 5:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8F8FE37B407 for ; Fri, 7 Sep 2001 13:05:48 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA35366; Fri, 7 Sep 2001 13:30:34 -0700 (PDT) Date: Fri, 7 Sep 2001 13:30:33 -0700 (PDT) From: Julian Elischer To: Ashley Thomas Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Compiling source code In-Reply-To: <3B991EB3.1770F47@unity.ncsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Assuming it is in /usr/src (where it gets put by default) cd /usr/src make or cd /usr/src/ make buildworld make installworld or cd /usr/src/usr.bin/yourfavouriteutility make depend make maek install If you do not hav ethe source, see the many places in th online handbook that tell you how to keep your sources up-to date with the branch you select. (look for references to cvsup) On Fri, 7 Sep 2001, Ashley Thomas wrote: > Hi, > > Could anybody give me some info about 'how to compile the FreeBSD source > code' and run. > Any pointers to useful links will also suffice. > > thanks a lot > ashley > > > 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 Sep 7 13:21:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by hub.freebsd.org (Postfix) with ESMTP id 00B4C37B401; Fri, 7 Sep 2001 13:21:31 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA09506; Fri, 7 Sep 2001 22:21:28 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.4) id f87KLSk00571; Fri, 7 Sep 2001 22:21:28 +0200 (CEST) (envelope-from wkb) Date: Fri, 7 Sep 2001 22:21:27 +0200 From: Wilko Bulte To: Jordan Hubbard Cc: rwatson@FreeBSD.ORG, tlambert2@mindspring.com, freebsd-hackers@FreeBSD.ORG, developers@FreeBSD.ORG Subject: Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions Message-ID: <20010907222127.A551@freebie.xs4all.nl> References: <3B991A74.6CEE1FA9@mindspring.com> <20010907125348E.jkh@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907125348E.jkh@freebsd.org>; from jkh@FreeBSD.ORG on Fri, Sep 07, 2001 at 12:53:48PM -0700 X-OS: FreeBSD 4.4-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 12:53:48PM -0700, Jordan Hubbard wrote: > > status on merging of features to -stable, the release process, etc. At > > one point, Jordan was spitting out a FreeBSD news letter once in a while. > > Dunno if we'll ever see it again, but I thought that was a good idea, and > > was part of the impetus for exploring a monthly electronic report. > > > > Of course, I've never received status information from Jordan :-). Wasn't this something like: hug a palm @ Hawaii ? ;-)) > I know, I know, life's been rather extremely busy. I'd love to revive > the newsletter, believe me, though I also think that DaemonNews and It all amounts to somebody/a team with Pulitzer prize aspirations. Meaning: people who can and are willing to write stuff on a regular basis. -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 13:55:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from atlantic.mail.pas.earthlink.net (atlantic.mail.pas.earthlink.net [207.217.120.179]) by hub.freebsd.org (Postfix) with ESMTP id 76CA937B405 for ; Fri, 7 Sep 2001 13:55:47 -0700 (PDT) Received: from positron.anholt.dyn.dhs.org (IP-209-239-211-114.PDX.JPS.NET [209.239.211.114]) by atlantic.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA00613; Fri, 7 Sep 2001 13:54:51 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" From: Eric Anholt Reply-To: anholt@teleport.com To: Volker Stolz , Josef Karthauser Subject: Re: DRI, XFree86-4.0.3 and -current. Date: Fri, 7 Sep 2001 13:54:06 -0700 X-Mailer: KMail [version 1.2] Cc: freebsd-hackers@FreeBSD.ORG References: <20010906185732.A3148@tao.org.uk> <20010906203332.C3148@tao.org.uk> <20010907121257.A944@i2.informatik.rwth-aachen.de> In-Reply-To: <20010907121257.A944@i2.informatik.rwth-aachen.de> MIME-Version: 1.0 Message-Id: <01090713540600.00540@positron.anholt.dyn.dhs.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oops, I'll have to clarify that. No, you don't need to keep an XFree86-4 tree around at all. Just get the X-DRI tree from sourceforge, and install it over your XFree86-4 install. I have both XFree and X-DRI CVS trees (downloading the 90MB or whatever per X release just isn't going to happen through my 28.8): /usr/local/src/xfree is X CVS (cvs.xfree86.org, updated/installed rarely, as most changes end up in X-DRI soon enough anyway) /usr/lcoal/src/xdri is X-DRI CVS (cvs.sourceforge.net bsd-2-0-0-branch, compiled/installed frequently). I'm working on making it so we can have an official port of the DRI -- you'll install the XFree86-4.x port (which would install X, the dri modules, libGL, libGLU, etc.), then go to graphics/drm-kmod and install that, and you'll be done installing. It's not quite finished yet, and I am waiting to get to a faster line (2 weeks) before downloading the X release to test against. On Friday 07 September 2001 03:12, Volker Stolz wrote: > In local.freebsd-hackers, you wrote: > > On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: > >> I have a page about the DRI for FreeBSD at=20 > >> http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works > > > > I had a look at that, but it wasn't too clear what I needed to do. I > > suspect that I'm expecting to checkout the DRI tree _over_ the top of > > the XFree86-4 tree but perhaps I don't need to do that. > > Neither was I. Could you clarify on merging XFree from the ports and the > CVS? I tried copying the CVS-stuff over the port, but the build stopped > with: > cleaning in programs/Xserver/hw/xfree86/input/calcomp... > cd: can't cd to calcomp -- Eric Anholt anholt@teleport.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 15: 4:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 3108D37B403 for ; Fri, 7 Sep 2001 15:04:17 -0700 (PDT) Received: (qmail 39266 invoked by uid 1001); 7 Sep 2001 22:04:16 -0000 Date: 7 Sep 2001 15:04:16 -0700 Date: Fri, 7 Sep 2001 15:04:16 -0700 From: Bill Swingle To: FreeBSD Hackers Subject: tiny patch to pkg_add Message-ID: <20010907150416.A38565@dub.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD toxic.magnesium.net 4.3-STABLE FreeBSD 4.3-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ok, So this represents my most significant effort to date to fix something in C. It took me far too long to identify where the one line fix needed to go and even longer to figure out how to do it in C.=20 Here's the problem that this fixes: When using "pkg_add -r" to add multiple packages=20 (i.e. "pkg_add -r foo bar baz") pkg_add was dying after adding the first package because it was botching the URL for every package after the initial one. It looked a bit like this: # pkg_add -r xonix nethack an Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/xo= nix.tgz... Done. Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packa= ges-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/package= s-4.4-release/Latest/nethack.tgz: File unavailable (e.g., file not found, n= o access) pkg_add: unable to fetch `ftp://ftp.freebsd.org/pub/FreeBSD/ports= /i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i= 386/packages-4.4-release/Latest/nethack.tgz' by URL Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packa= ges-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/package= s-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-= 4.4-release/Latest/an.tgz: File unavailable (e.g., file not found, no acces= s) pkg_add: unable to fetch `ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/p= ackages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/pac= kages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packa= ges-4.4-release/Latest/an.tgz' by URL Anyway, it's an easy fix but my real question is, is this the correct way to destroy the value of a variable in C? Here's my patch: --- src/usr.sbin/pkg_install/add/main.c Fri Sep 7 15:02:17 2001 +++ src/usr.sbin/pkg_install/add/main.c.orig Fri Sep 7 13:11:40 2001 @@ -189,7 +189,6 @@ } } } - strlcpy(packagesite, "", sizeof(packagesite)); } } /* If no packages, yelp */ -Bill --=20 -=3D| Bill Swingle - -=3D| Every message PGP signed -=3D| Fingerprint: C1E3 49D1 EFC9 3EE0 EA6E 6414 5200 1C95 8E09 0223 -=3D| Different all twisty a of in maze are you, passages little --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7mURgUgAclY4JAiMRAjJqAKC+PuHWeC/j6YjqV3Zz5MNg3rXvuACglwaU SE5wSsdzUH76JqTjqQR2HJM= =hoWr -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 15:19:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 3C7E737B401 for ; Fri, 7 Sep 2001 15:19:36 -0700 (PDT) Received: (qmail 40285 invoked by uid 1001); 7 Sep 2001 22:19:35 -0000 Date: 7 Sep 2001 15:19:35 -0700 Date: Fri, 7 Sep 2001 15:19:35 -0700 From: Bill Swingle To: FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907151935.A40146@dub.net> References: <20010907150416.A38565@dub.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907150416.A38565@dub.net>; from unfurl@dub.net on Fri, Sep 07, 2001 at 03:04:16PM -0700 X-Operating-System: FreeBSD toxic.magnesium.net 4.3-STABLE FreeBSD 4.3-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: > - strlcpy(packagesite, "", sizeof(packagesite)); Chris Costello recommended that I do this like this instead: packagesite[0] =3D '\0' Which seems to make sense since it lacks the overhead of strlcpy. Is there a "right" way to do this? -Bill --=20 -=3D| Bill Swingle - -=3D| Every message PGP signed -=3D| Fingerprint: C1E3 49D1 EFC9 3EE0 EA6E 6414 5200 1C95 8E09 0223 -=3D| Different all twisty a of in maze are you, passages little --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7mUf3UgAclY4JAiMRAioxAKCMqFHLZyncv0XYUrPEDuN+7WjYKQCeM75d O4QtYGvchWglwU6+Bm1jdI8= =s8wM -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 15:25:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail28.sdc1.sfba.home.com (femail28.sdc1.sfba.home.com [24.254.60.18]) by hub.freebsd.org (Postfix) with ESMTP id 13CDB37B405 for ; Fri, 7 Sep 2001 15:25:43 -0700 (PDT) Received: from intruder.bmah.org ([24.176.204.87]) by femail28.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010907222542.GMOX560.femail28.sdc1.sfba.home.com@intruder.bmah.org>; Fri, 7 Sep 2001 15:25:42 -0700 Received: (from bmah@localhost) by intruder.bmah.org (8.11.6/8.11.3) id f87MPgE03023; Fri, 7 Sep 2001 15:25:42 -0700 (PDT) (envelope-from bmah) Message-Id: <200109072225.f87MPgE03023@intruder.bmah.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bill Swingle Cc: FreeBSD Hackers Subject: Re: tiny patch to pkg_add In-Reply-To: <20010907151935.A40146@dub.net> References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> Comments: In-reply-to Bill Swingle message dated "Fri, 07 Sep 2001 15:19:35 -0700." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-611408166P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 07 Sep 2001 15:25:42 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --==_Exmh_-611408166P Content-Type: text/plain; charset=us-ascii If memory serves me right, Bill Swingle wrote: > Chris Costello recommended that I do this like this instead: > > packagesite[0] =3D '\0' > > Which seems to make sense since it lacks the overhead of strlcpy. Is > there a "right" way to do this? Although I haven't seen the context for this line (other than what was in the context diff), I think most C programmers (including myself) would go with Chris's suggestion. Hope this helps, Bruce. --==_Exmh_-611408166P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE7mUlm2MoxcVugUsMRAoTfAKDspP6uDGNw9DUeXMKeBcv90InwgACg+fBg J53enn62GmvYfcYhMRa+sL0= =cVB2 -----END PGP SIGNATURE----- --==_Exmh_-611408166P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 15:31: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id 5654437B407 for ; Fri, 7 Sep 2001 15:31:04 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f87MWgh66289 for hackers@FreeBSD.ORG; Fri, 7 Sep 2001 18:32:42 -0400 (EDT) (envelope-from bicknell) Date: Fri, 7 Sep 2001 18:32:42 -0400 From: Leo Bicknell To: FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907183242.A66179@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , FreeBSD Hackers References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907151935.A40146@dub.net>; from unfurl@dub.net on Fri, Sep 07, 2001 at 03:19:35PM -0700 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 03:19:35PM -0700, Bill Swingle wrote: > On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: > > - strlcpy(packagesite, "", sizeof(packagesite)); > > Chris Costello recommended that I do this like this instead: > > packagesite[0] = '\0' > > Which seems to make sense since it lacks the overhead of strlcpy. Is > there a "right" way to do this? I think Chris's version is right, although if you're writing a security app, or just want to be overly paranoid in general you could use: bzero((void *)packagesite, sizeof(packagesite)); -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 15:46:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id CC5E437B403 for ; Fri, 7 Sep 2001 15:46:30 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f87MkRp00985; Fri, 7 Sep 2001 17:46:27 -0500 (CDT) (envelope-from chris) Date: Fri, 7 Sep 2001 17:46:26 -0500 From: Chris Costello To: Leo Bicknell Cc: FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907174626.A548@holly.calldei.com> Reply-To: chris@calldei.com References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> <20010907183242.A66179@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907183242.A66179@ussenterprise.ufp.org>; from bicknell@ufp.org on Fri, Sep 07, 2001 at 06:32:42PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, September 07, 2001, Leo Bicknell wrote: > I think Chris's version is right, although if you're writing a > security app, or just want to be overly paranoid in general > you could use: > > bzero((void *)packagesite, sizeof(packagesite)); That's unnecessary unless you know you're going to be reading data from that string starting somewhere other than &packagesite[0];. And the `void *' cast is unnecessary, as an array is converted to a pointer when passed to a function, and any data pointer is also implicitly converted to a `void *' pointer where necessary. -- +-------------------+------------------------+ | Chris Costello | Save energy: | | chris@calldei.com | Drive a smaller shell. | +-------------------+------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 16:12:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id E32A537B405; Fri, 7 Sep 2001 16:12:47 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f87NCjX01095; Fri, 7 Sep 2001 18:12:45 -0500 (CDT) (envelope-from chris) Date: Fri, 7 Sep 2001 18:11:24 -0500 From: Chris Costello To: Maxim Sobolev Cc: Poul-Henning Kamp , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010907181124.B548@holly.calldei.com> Reply-To: chris@calldei.com References: <12420.999618814@critter> <200109041904.f84J4ZZ99036@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109041904.f84J4ZZ99036@vega.vega.com>; from sobomax@FreeBSD.ORG on Tue, Sep 04, 2001 at 10:04:35PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, September 04, 2001, Maxim Sobolev wrote: Content-Description: ASCII C program text > Index: coda/coda.h > =================================================================== > RCS file: /home/ncvs/src/sys/coda/coda.h,v > retrieving revision 1.9 > diff -d -u -r1.9 coda.h > --- coda/coda.h 1999/12/29 04:54:30 1.9 > +++ coda/coda.h 2001/09/04 18:46:42 > @@ -41,7 +41,7 @@ > #ifndef _CODA_HEADER_ > #define _CODA_HEADER_ > > - > +#define VT_CODA "VT_CODA" ... I don't think that the point of this is to use a string like that, but rather a descriptive string, i.e. #define VT_FDESCFS "file-descriptor file system" #define VT_NFS "network file system" But is it necessary that you really use those defines? The idea is not to use them globally. Perhaps getnewvnode() should get the string from `mp->mnt_stat.f_mntfromname', instead... -- +-------------------+-------------------------------------------+ | Chris Costello | As far as we know, our computer has never | | chris@calldei.com | had an undetected error. - Weisert | +-------------------+-------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 16:20: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by hub.freebsd.org (Postfix) with ESMTP id AB49237B401 for ; Fri, 7 Sep 2001 16:19:54 -0700 (PDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.11.1/8.11.1) id f87NMJs67639; Fri, 7 Sep 2001 19:22:19 -0400 (EDT) (envelope-from bicknell) Date: Fri, 7 Sep 2001 19:22:19 -0400 From: Leo Bicknell To: Chris Costello Cc: Leo Bicknell , FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907192219.A67548@ussenterprise.ufp.org> Mail-Followup-To: Leo Bicknell , Chris Costello , Leo Bicknell , FreeBSD Hackers References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> <20010907183242.A66179@ussenterprise.ufp.org> <20010907174626.A548@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907174626.A548@holly.calldei.com>; from chris@calldei.com on Fri, Sep 07, 2001 at 05:46:26PM -0500 Organization: United Federation of Planets Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 05:46:26PM -0500, Chris Costello wrote: > > bzero((void *)packagesite, sizeof(packagesite)); > > That's unnecessary unless you know you're going to be reading > data from that string starting somewhere other than > &packagesite[0];. And the `void *' cast is unnecessary, as an > array is converted to a pointer when passed to a function, and > any data pointer is also implicitly converted to a `void *' > pointer where necessary. That's not the only reason to do it. Many people in the past have gotten passwords out of various applications by making them core dump, sifting through /dev/kmem, and other things. While it's not clear that his application might have these issues, I come from the better safe than sorry school. If you want to make a string "empty", make it empty, don't just clobber the first character. The void * is necessary to make lint happy. It is not necessary for the program to work right. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 16:22:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 63DF137B406 for ; Fri, 7 Sep 2001 16:22:44 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f87NMho17176; Fri, 7 Sep 2001 16:22:43 -0700 (PDT) (envelope-from obrien) Date: Fri, 7 Sep 2001 16:22:43 -0700 From: "David O'Brien" To: Bill Swingle Cc: FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907162242.A16949@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010907150416.A38565@dub.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907150416.A38565@dub.net>; from unfurl@dub.net on Fri, Sep 07, 2001 at 03:04:16PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: > So this represents my most significant effort to date to fix something > in C. It took me far too long to identify where the one line fix needed > to go and even longer to figure out how to do it in C. > > Here's the problem that this fixes: This was introduced in rev 1.38: and replace a big if..then..else construct to determine the package download directory with a lookup table. I am very tempted to back this part out. This "better implimentation" has now had two logic bugs. I wrote that "big if..then..else contstruct" so that the code would be *so* simple my simple my 1st quarter freshman students (back when I TA'ed) could understand it. I did it that way because I got tired of committers constantly breaking -r. -- -- David (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 Fri Sep 7 16:26:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id 1264237B403; Fri, 7 Sep 2001 16:26:46 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f87NQh201212; Fri, 7 Sep 2001 18:26:43 -0500 (CDT) (envelope-from chris) Date: Fri, 7 Sep 2001 18:26:32 -0500 From: Chris Costello To: Maxim Sobolev Cc: Poul-Henning Kamp , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010907182632.C548@holly.calldei.com> Reply-To: chris@calldei.com References: <12420.999618814@critter> <200109041904.f84J4ZZ99036@vega.vega.com> <20010907181124.B548@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907181124.B548@holly.calldei.com>; from chris@calldei.com on Fri, Sep 07, 2001 at 06:11:24PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, September 07, 2001, Chris Costello wrote: > But is it necessary that you really use those defines? The > idea is not to use them globally. Perhaps getnewvnode() should > get the string from `mp->mnt_stat.f_mntfromname', instead... ^^^^^^^^^^^^^ Er, fstypename... -- +-------------------+------------------------------------+ | Chris Costello | Unprecedented performance: | | chris@calldei.com | Nothing ever ran this slow before. | +-------------------+------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 16:58: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 61C6F37B403 for ; Fri, 7 Sep 2001 16:57:56 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id D45E92BE; Sat, 8 Sep 2001 00:57:52 +0100 (BST) Date: Sat, 8 Sep 2001 00:57:52 +0100 From: Josef Karthauser To: Eric Anholt Cc: Volker Stolz , freebsd-hackers@FreeBSD.ORG Subject: Re: DRI, XFree86-4.0.3 and -current. Message-ID: <20010908005752.U3148@tao.org.uk> Mail-Followup-To: Josef Karthauser , Eric Anholt , Volker Stolz , freebsd-hackers@FreeBSD.ORG References: <20010906185732.A3148@tao.org.uk> <20010906203332.C3148@tao.org.uk> <20010907121257.A944@i2.informatik.rwth-aachen.de> <01090713540600.00540@positron.anholt.dyn.dhs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="glDgwcODtpHomn63" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01090713540600.00540@positron.anholt.dyn.dhs.org>; from anholt@teleport.com on Fri, Sep 07, 2001 at 01:54:06PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --glDgwcODtpHomn63 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 01:54:06PM -0700, Eric Anholt wrote: > I'm working on making it so we can have an official port of the DRI -- yo= u'll=20 > install the XFree86-4.x port (which would install X, the dri modules, lib= GL,=20 > libGLU, etc.), then go to graphics/drm-kmod and install that, and you'll = be=20 > done installing. It's not quite finished yet, and I am waiting to get to= a=20 > faster line (2 weeks) before downloading the X release to test against. Cool. I'll give you a hand with it with you want. In particular I have a need for it under -current. Joe --glDgwcODtpHomn63 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuZXv8ACgkQXVIcjOaxUBb8AQCgrVMavBWphbMkT/fQ4lnjBNXF MCQAoJATkp0zo1TojjG3RdIiz9PqQoRI =6cwR -----END PGP SIGNATURE----- --glDgwcODtpHomn63-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 17: 2:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id D872E37B40B for ; Fri, 7 Sep 2001 17:02:44 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 20A4D2F1; Sat, 8 Sep 2001 01:02:43 +0100 (BST) Date: Sat, 8 Sep 2001 01:02:43 +0100 From: Josef Karthauser To: Bill Swingle Cc: FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010908010243.V3148@tao.org.uk> References: <20010907150416.A38565@dub.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7fXEoLLey27Fs/d6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907150416.A38565@dub.net>; from unfurl@dub.net on Fri, Sep 07, 2001 at 03:04:16PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --7fXEoLLey27Fs/d6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: > Anyway, it's an easy fix but my real question is, is this the correct > way to destroy the value of a variable in C? Here's my patch: >=20 > --- src/usr.sbin/pkg_install/add/main.c Fri Sep 7 15:02:17 2001 > +++ src/usr.sbin/pkg_install/add/main.c.orig Fri Sep 7 13:11:40 2001 > @@ -189,7 +189,6 @@ > } > } > } > - strlcpy(packagesite, "", sizeof(packagesite)); > } > } > /* If no packages, yelp */ Surely: *packagesite =3D '\0'; would do just as well? Joe --7fXEoLLey27Fs/d6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuZYCIACgkQXVIcjOaxUBblCwCeKxr8xig+RDfWnC9eTjwyNKoC JyIAoNLezN2+Ax+n7WpTORkg0v+gD+tM =s0KF -----END PGP SIGNATURE----- --7fXEoLLey27Fs/d6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 17:14:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 2DACA37B407; Fri, 7 Sep 2001 17:14:43 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1098) id D8CE081D05; Fri, 7 Sep 2001 19:14:37 -0500 (CDT) Date: Fri, 7 Sep 2001 19:14:37 -0500 From: Bill Fumerola To: David O'Brien Cc: Bill Swingle , FreeBSD Hackers Subject: Re: tiny patch to pkg_add Message-ID: <20010907191437.A5216@elvis.mu.org> References: <20010907150416.A38565@dub.net> <20010907162242.A16949@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010907162242.A16949@dragon.nuxi.com>; from obrien@freebsd.org on Fri, Sep 07, 2001 at 04:22:43PM -0700 X-Operating-System: FreeBSD 4.3-FEARSOME-20010712 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 04:22:43PM -0700, David O'Brien wrote: > This was introduced in rev 1.38: > > and replace a big if..then..else construct > to determine the package download directory with a lookup table. > > I am very tempted to back this part out. This "better implimentation" > has now had two logic bugs. I wrote that "big if..then..else contstruct" > so that the code would be *so* simple my simple my 1st quarter freshman > students (back when I TA'ed) could understand it. I did it that way > because I got tired of committers constantly breaking -r. the funniest thing about this is that multiple packages in -r was already fixed once by chris piazza in rev 1.29 (almost 2 years ago). -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 22:32:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9F9E437B403; Fri, 7 Sep 2001 22:32:17 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.4/8.11.4) with ESMTP id f885VaT90901; Sat, 8 Sep 2001 07:31:36 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: chris@calldei.com Cc: Maxim Sobolev , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: Your message of "Fri, 07 Sep 2001 18:11:24 CDT." <20010907181124.B548@holly.calldei.com> Date: Sat, 08 Sep 2001 07:31:36 +0200 Message-ID: <90899.999927096@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010907181124.B548@holly.calldei.com>, Chris Costello writes: >On Tuesday, September 04, 2001, Maxim Sobolev wrote: >Content-Description: ASCII C program text >> Index: coda/coda.h >> =================================================================== >> RCS file: /home/ncvs/src/sys/coda/coda.h,v >> retrieving revision 1.9 >> diff -d -u -r1.9 coda.h >> --- coda/coda.h 1999/12/29 04:54:30 1.9 >> +++ coda/coda.h 2001/09/04 18:46:42 >> @@ -41,7 +41,7 @@ >> #ifndef _CODA_HEADER_ >> #define _CODA_HEADER_ >> >> - >> +#define VT_CODA "VT_CODA" >... > > I don't think that the point of this is to use a string like >that, but rather a descriptive string, i.e. No actually not, I want something short and predictable like "VT_CODA". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 22:39: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id A77A837B401; Fri, 7 Sep 2001 22:39:01 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f885csm02155; Sat, 8 Sep 2001 00:38:54 -0500 (CDT) (envelope-from chris) Date: Sat, 8 Sep 2001 00:38:43 -0500 From: Chris Costello To: Poul-Henning Kamp Cc: Maxim Sobolev , Brent Verner , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010908003843.D548@holly.calldei.com> Reply-To: chris@calldei.com References: <20010907181124.B548@holly.calldei.com> <90899.999927096@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <90899.999927096@critter>; from phk@critter.freebsd.dk on Sat, Sep 08, 2001 at 07:31:36AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, September 08, 2001, Poul-Henning Kamp wrote: > No actually not, I want something short and predictable like > "VT_CODA". How about my second suggestion: making v_tag point to mp->mnt_stat.f_fstypename, or a copy thereof? -- +-------------------+--------------------------------------+ | Chris Costello | Why do we want intelligent terminals | | chris@calldei.com | when there are so many stupid users? | +-------------------+--------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 23:36:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 1280C37B405 for ; Fri, 7 Sep 2001 23:36:21 -0700 (PDT) Received: (qmail 92646 invoked by uid 1001); 8 Sep 2001 16:36:18 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Sat, 08 Sep 2001 16:36:18 +1000 From: Greg Black To: obrien@freebsd.org Cc: Bill Swingle , FreeBSD Hackers Subject: Re: tiny patch to pkg_add References: <20010907150416.A38565@dub.net> <20010907162242.A16949@dragon.nuxi.com> In-reply-to: <20010907162242.A16949@dragon.nuxi.com> of Fri, 07 Sep 2001 16:22:43 MST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" wrote: | On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: | > So this represents my most significant effort to date to fix something | > in C. It took me far too long to identify where the one line fix needed | > to go and even longer to figure out how to do it in C. | > | > Here's the problem that this fixes: | | This was introduced in rev 1.38: | | and replace a big if..then..else construct | to determine the package download directory with a lookup table. | | I am very tempted to back this part out. This "better implimentation" | has now had two logic bugs. I wrote that "big if..then..else contstruct" | so that the code would be *so* simple my simple my 1st quarter freshman | students (back when I TA'ed) could understand it. I did it that way | because I got tired of committers constantly breaking -r. Simple and correct is always better than clever and wrong. I'd be strongly in favour of backing it out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 23:45:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 84F2237B405 for ; Fri, 7 Sep 2001 23:45:27 -0700 (PDT) Received: (qmail 93021 invoked by uid 1001); 8 Sep 2001 16:45:25 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Sat, 08 Sep 2001 16:45:25 +1000 From: Greg Black To: Leo Bicknell Cc: Chris Costello , FreeBSD Hackers Subject: Re: tiny patch to pkg_add References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> <20010907183242.A66179@ussenterprise.ufp.org> <20010907174626.A548@holly.calldei.com> <20010907192219.A67548@ussenterprise.ufp.org> In-reply-to: <20010907192219.A67548@ussenterprise.ufp.org> of Fri, 07 Sep 2001 19:22:19 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Leo Bicknell wrote: | On Fri, Sep 07, 2001 at 05:46:26PM -0500, Chris Costello wrote: | > > bzero((void *)packagesite, sizeof(packagesite)); | > | > That's unnecessary unless you know you're going to be reading | > data from that string starting somewhere other than | > &packagesite[0];. And the `void *' cast is unnecessary, as an | > array is converted to a pointer when passed to a function, and | > any data pointer is also implicitly converted to a `void *' | > pointer where necessary. | | That's not the only reason to do it. Many people in the past have | gotten passwords out of various applications by making them core | dump, sifting through /dev/kmem, and other things. While it's not | clear that his application might have these issues, I come from | the better safe than sorry school. If you want to make a string | "empty", make it empty, don't just clobber the first character. If this was a password, then there would be reasons to clear it out, but it's not. Don't just make work for the sake of it, but understand the code and do what is needed. | The void * is necessary to make lint happy. It is not necessary | for the program to work right. If you have a lint that needs the cast, throw it away because it's wrong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 7 23:50:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 2BA6037B401 for ; Fri, 7 Sep 2001 23:50:37 -0700 (PDT) Received: (qmail 93614 invoked by uid 1001); 8 Sep 2001 16:50:35 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Sat, 08 Sep 2001 16:50:34 +1000 From: Greg Black To: Bill Swingle Cc: FreeBSD Hackers Subject: Re: tiny patch to pkg_add References: <20010907150416.A38565@dub.net> <20010907151935.A40146@dub.net> In-reply-to: <20010907151935.A40146@dub.net> of Fri, 07 Sep 2001 15:19:35 MST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Swingle wrote: | > - strlcpy(packagesite, "", sizeof(packagesite)); | | Chris Costello recommended that I do this like this instead: | | packagesite[0] = '\0' | | Which seems to make sense since it lacks the overhead of strlcpy. Is | there a "right" way to do this? A C programmer would do it the way Chris suggested. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 0:21:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 080AD37B403; Sat, 8 Sep 2001 00:21:45 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA05457; Sat, 8 Sep 2001 17:21:34 +1000 Date: Sat, 8 Sep 2001 17:20:47 +1000 (EST) From: Bruce Evans X-X-Sender: To: Chris Costello Cc: Poul-Henning Kamp , Maxim Sobolev , Brent Verner , , Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag In-Reply-To: <20010908003843.D548@holly.calldei.com> Message-ID: <20010908170906.G45139-100000@alphplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 8 Sep 2001, Chris Costello wrote: > On Saturday, September 08, 2001, Poul-Henning Kamp wrote: > > No actually not, I want something short and predictable like > > "VT_CODA". > > How about my second suggestion: making v_tag point to > mp->mnt_stat.f_fstypename, or a copy thereof? Good, but I as far as I understand this, the only legitimate point of v_tag is to tell applications like fstat(1) the type of the vnode. fstat can find chase the kernel pointers in vp->v_mount->mnt_stat->f_fstypename almost as (un)easily as it could chase vp->v_tag if v_tag is a pointer. Copying the string would give ugly bloat, but would not be all that much worse than the bloat for a pointer on alphas (the contents of the string "VT_CODA" takes the same space as a pointer on alphas). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 1: 1:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id D1D1737B409; Sat, 8 Sep 2001 01:01:19 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f8881BX02724; Sat, 8 Sep 2001 03:01:11 -0500 (CDT) (envelope-from chris) Date: Sat, 8 Sep 2001 03:01:11 -0500 From: Chris Costello To: Maxim Sobolev Cc: phk@critter.freebsd.dk, brent@rcfile.org, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010908030110.E548@holly.calldei.com> Reply-To: chris@calldei.com References: <20010908003843.D548@holly.calldei.com> <200109080729.KAA87536@www.abc.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109080729.KAA87536@www.abc.com.ua>; from sobomax@FreeBSD.org on Sat, Sep 08, 2001 at 10:29:40AM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, September 08, 2001, Maxim Sobolev wrote: > No, it should be pre-defined, because otherwise we will be > unable to use strcmp() in a few places when v_tag is abused. So in these cases (which ideally would be eliminated rather than considered for support), why can't you do: if (strcmp(vp->v_tag, "procfs") == 0) { rather than if (strcmp(vp->v_tag, VT_PROCFS) == 0) { in the case of procfs? As for a solution to the problem, I'm not entirely sure, but maybe this is a case for either a new vnode flag, `VUNSAFE', for files which should be closed across exec() calls (this is all setugidsafety() and its hackish is_unsafe() companion are used for as far as I can tell). -- +-------------------+------------------------------------+ | Chris Costello | Let the machine do the dirty work. | | chris@calldei.com | - Elements of Programming Style | +-------------------+------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 2:39:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aries.ai.net (aries.ai.net [205.134.163.4]) by hub.freebsd.org (Postfix) with ESMTP id 6B1CA37B409; Sat, 8 Sep 2001 02:39:39 -0700 (PDT) Received: from blood (pool-138-88-72-170.res.east.verizon.net [138.88.72.170]) by aries.ai.net (8.9.3/8.9.3) with SMTP id FAA02736; Sat, 8 Sep 2001 05:47:23 -0400 (EDT) (envelope-from deepak@ai.net) Reply-To: From: "Deepak Jain" To: , "freebsd-hackers@FreeBSD. ORG" Subject: Kernel-loadable Root Kits Date: Sat, 8 Sep 2001 05:43:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Short question: Is there a way to prevent the kernel from allowing loadable modules? Thought process -- --- With the advent of the kernel-loadable root kit, intrusion detection has gotten a bit more complicated. Is there a _simple_ solution to detecting the presence of a kernel-based root kit once it is running? Scenario: System is violated, Root kit is installed, Root kit [binaries] are deleted from the machine. Solution: Reboot machine How does one DETECT that the root kit is there in the first place to know to reboot it? Thanks, Deepak Jain AiNET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 2:45:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (sentinel.office1.bg [217.75.135.254]) by hub.freebsd.org (Postfix) with SMTP id 651C937B407 for ; Sat, 8 Sep 2001 02:45:50 -0700 (PDT) Received: (qmail 9160 invoked by uid 1000); 8 Sep 2001 09:45:28 -0000 Date: Sat, 8 Sep 2001 12:45:28 +0300 From: Peter Pentchev To: Deepak Jain Cc: freebsd-security@freebsd.org, "freebsd-hackers@FreeBSD. ORG" Subject: Re: Kernel-loadable Root Kits Message-ID: <20010908124528.D2176@ringworld.oblivion.bg> Mail-Followup-To: Deepak Jain , freebsd-security@freebsd.org, "freebsd-hackers@FreeBSD. ORG" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from deepak@ai.net on Sat, Sep 08, 2001 at 05:43:41AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Sep 08, 2001 at 05:43:41AM -0400, Deepak Jain wrote: > > Short question: > > Is there a way to prevent the kernel from allowing loadable modules? Run your system in securelevel 1 or higher. See the init(8) manual page and the kern_securelevel_enable and kern_securelevel variables in the rc.conf(5) manual page. G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 7:17:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.teledis.be (mail.teledis.be [217.117.32.52]) by hub.freebsd.org (Postfix) with ESMTP id A3CE537B403 for ; Sat, 8 Sep 2001 07:17:22 -0700 (PDT) Received: from natalie ([217.117.38.8]) by mail.teledis.be (Netscape Messaging Server 4.15) with SMTP id GJCL0Y00.93W; Sat, 8 Sep 2001 16:17:22 +0200 Message-ID: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be> From: "Sansonetti Laurent" To: Cc: References: Subject: Re: Kernel-loadable Root Kits Date: Sat, 8 Sep 2001 16:21:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, > Short question: > > Is there a way to prevent the kernel from allowing loadable modules? Yes, by hacking kldload(2). You can also switch the secure level using sysctl. > With the advent of the kernel-loadable root kit, intrusion detection has > gotten a bit more complicated. Is there a _simple_ solution to detecting the > presence of a kernel-based root kit once it is running? 1) scan the sysent table and check syscalls pointers (generally, rootkits intercepts syscalls) 2) scan the tail queue called 'modules' (note, many rootkits erases their entry in MOD_LOAD) Hope this help, -- Sansonetti Laurent - http://lrz.linuxbe.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 7:51:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id CA1EC37B405; Sat, 8 Sep 2001 07:51:24 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id RTS88893; Sat, 8 Sep 2001 17:51:13 +0300 (EEST) (envelope-from vovik) Date: Sat, 8 Sep 2001 17:51:13 +0300 From: "Vladimir A. Jakovenko" To: Terry Lambert Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010908175113.B84471@lucky.net> References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net> <3B991962.C8D0A398@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B991962.C8D0A398@mindspring.com>; from tlambert2@mindspring.com on Fri, Sep 07, 2001 at 12:00:50PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 12:00:50PM -0700, Terry Lambert wrote: >"Vladimir A. Jakovenko" wrote: >> Terry, I clearly understand all your explanations. Yes, we are living in >> real life and there is a lot of programms with bad design. >> >> But all what I want is possibility to receive UDP packets with >> corresponding dst IP and port by more than one process on a single >> host. This already works for Broadcast and Multicast addresses. If >> I want to get same functionality for unicast (without any kernel >> changes) I have to use UDP-proxy, which redirects given datagrams >> to loopback broadcast address, where they can be received by more >> that one process. > >Yes. Ok. >> According to comment in udp_input() SO_REUSEPORT hack on unicast >> sockets could be used in single process, right? > >Yes. Ok. >> How possibility to get duplicate traffic on two UDP sockets, which >> was created in _different_ processes with the same local address >> and port values, would break existing applications? >Consider a UDP based reliable delivery protocol that cares >about key frames, but not about all frames. A good example >of this would be any RTSP/RTP type protocol implemented on >UDP, which was used to implement streaming video of a live >broadcast, using limited buffer space. Terry, your example is right for UDP services which requires _acknowledgment_. But in my case what I need is the simple, even classic, unreliable UDP datastream delivery _without_ acknowledgment_ destinated to one or _more_ processes on single host. Yes, multicast (and even broadcast) is good, but not all time. I.e. if in one broadcast domain exists at least one non trusted host it would be difficult (and in the case of broadcast not possible) to restrict such host ability to receive traffic destinated to multicast group if other hosts should have ability to join group and receive traffic. Lets sum up all mentioned issues: 1. There is restriction in FreeBSD kernel about processing SO_REUSEPORT socket option on UDP scokets, which allows more than one binding to given ip:port on one host. This restriction blocks possibility to obtain UNICAST traffic destinated to same ip:port by two or more processes simultaneously. 2. If this restriction would be removed only for sockets crated by different processes it would not break existing applications. Am I right? -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 13: 6:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from holly.calldei.com (adsl-208-191-149-190.dsl.hstntx.swbell.net [208.191.149.190]) by hub.freebsd.org (Postfix) with ESMTP id C6AAD37B405; Sat, 8 Sep 2001 13:06:28 -0700 (PDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f88K6Mr06088; Sat, 8 Sep 2001 15:06:22 -0500 (CDT) (envelope-from chris) Date: Sat, 8 Sep 2001 15:06:21 -0500 From: Chris Costello To: Maxim Sobolev Cc: phk@critter.freebsd.dk, brent@rcfile.org, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Junior Kernel Hacker task: improve vnode->v_tag Message-ID: <20010908150620.F548@holly.calldei.com> Reply-To: chris@calldei.com References: <20010908030110.E548@holly.calldei.com> <200109081154.OAA95138@www.abc.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109081154.OAA95138@www.abc.com.ua>; from sobomax@FreeBSD.org on Sat, Sep 08, 2001 at 02:54:38PM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, September 08, 2001, Maxim Sobolev wrote: > I don't like idea to hardcode the same string ("procfs"), with the > same meaning in several places across kernel. As for your proposition > to use f_fstypename to set v_tag, it is even more bogus because > value of the f_fstypename is supplied from the user level, so > potentially it could be anything and we can't make any reasonable > assumptions about mapping between its value and type of the filesystem > in question. How do you figure? The contents if `f_fstypename' must match a configured file system exactly, so it could _not_ be anything. To quote sys/kern/vfs_syscalls.c:mount(): if ((error = copyinstr(SCARG(uap, type), fstypename, MFSNAMELEN, NULL)) vput(vp); return (error); } for (vfsp = vfsconf; vfsp; vfsp = vfsp->vfc_next) if (!strcmp(vfsp->vfc_name, fstypename)) break; if (vfsp == NULL) { /* ... try and load a module ... */ /* ... fail if no module can be found, or no * matching VFS is loaded */ } -- +-------------------+---------------------------------------------------+ | Chris Costello | You depend too much on computers for information. | | chris@calldei.com | | +-------------------+---------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 16:43:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id 1D53337B407 for ; Sat, 8 Sep 2001 16:43:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 15f8Zl-0000L1-00; Thu, 06 Sep 2001 17:28:49 -0600 Message-ID: <3B97C3C2.396D0504@softweyr.com> Date: Thu, 06 Sep 2001 12:43:14 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: tlambert2@mindspring.com Cc: Poul-Henning Kamp , Nate Williams , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: What is VT_TFS? References: <8460.999680861@critter> <3B95F035.362A4948@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Poul-Henning Kamp wrote: > > *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. > > I'm well aware of your checkered past... 8-). > > I guess Julian might pipe up now about the use of the acronym > "AWOL"... > > > Now, remind me again why historians are so picky about "primary > > sources" and "secondary sources" for historical information... > > That would be... Dennis Ritchie? 8-) 8-). > > > Are we done now ? > > I guess... > > > (Apart from Adrians story of course :-) > > If you think you can beat it out of him... I think we'd all > like to sit around the camp fire and listen to it, while > stroking our long grey beards... Do I have to grow my beard as long as Groggy's now? I'd better get started... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://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 Sep 8 17:49:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 07A3337B405 for ; Sat, 8 Sep 2001 17:49:07 -0700 (PDT) Received: from hades.hell.gr (patr530-b118.otenet.gr [195.167.121.246]) by mailsrv.otenet.gr (8.11.5/8.11.5) with ESMTP id f890n1A16337; Sun, 9 Sep 2001 03:49:01 +0300 (EEST) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id f88LJqf06975; Sun, 9 Sep 2001 00:19:52 +0300 (EEST) (envelope-from charon@labs.gr) Date: Sun, 9 Sep 2001 00:19:51 +0300 From: Giorgos Keramidas To: Sansonetti Laurent Cc: deepak@ai.net, freebsd-hackers@freebsd.org Subject: Re: Kernel-loadable Root Kits Message-ID: <20010909001951.A6949@hades.hell.gr> References: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002f01c13871$8dc2d360$0201a8c0@teledisnet.be>; from lorenzo@linuxbe.org on Sat, Sep 08, 2001 at 04:21:29PM +0200 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From: Sansonetti Laurent Subject: Re: Kernel-loadable Root Kits Date: Sat, Sep 08, 2001 at 04:21:29PM +0200 > Hello, > > > Short question: > > > > Is there a way to prevent the kernel from allowing loadable modules? > > Yes, by hacking kldload(2). You can also switch the secure level using > sysctl. > > > With the advent of the kernel-loadable root kit, intrusion > > detection has gotten a bit more complicated. Is there a _simple_ > > solution to detecting the presence of a kernel-based root kit once > > it is running? > > 1) scan the sysent table and check syscalls pointers (generally, rootkits > intercepts syscalls) This can get really "hairy". To scan the syscall table, even if you are 'root' and directly access /dev/mem you will have to use some system calls to open(), read() and seek() into the /dev/mem device. But those syscalls might be the intercepted ones: ouch! Instead of worrying after the module has been loaded it's much safer to run the kernel in securelevel>=1 when modules cannot be loaded without a reboot to single-user mode. -giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 18: 1:22 2001 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 E5E9237B405 for ; Sat, 8 Sep 2001 18:01:18 -0700 (PDT) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f8910g514575; Sat, 8 Sep 2001 21:00:42 -0400 (EDT) (envelope-from arr@watson.org) Date: Sat, 8 Sep 2001 21:00:41 -0400 (EDT) From: "Andrew R. Reiter" To: Giorgos Keramidas Cc: Sansonetti Laurent , deepak@ai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits In-Reply-To: <20010909001951.A6949@hades.hell.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Instead of worrying after the module has been loaded it's much safer :to run the kernel in securelevel>=1 when modules cannot be loaded :without a reboot to single-user mode. : Not entirely true. They are called kernel bugs... Not the proper url for this, but good enough: http://julianor.tripod.com/freebsd-kernel-bof.txt *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 18:49:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-m09.mx.aol.com (imo-m09.mx.aol.com [64.12.136.164]) by hub.freebsd.org (Postfix) with ESMTP id 8C20837B406 for ; Sat, 8 Sep 2001 18:49:52 -0700 (PDT) Received: from Bsdguru@aol.com by imo-m09.mx.aol.com (mail_out_v31_r1.4.) id n.146.146a821 (4415) for ; Sat, 8 Sep 2001 21:49:49 -0400 (EDT) From: Bsdguru@aol.com Message-ID: <146.146a821.28cc24bc@aol.com> Date: Sat, 8 Sep 2001 21:49:48 EDT Subject: PCI probe reordering? To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've encountered a MB that seems to probe devices in a less than desirable order. There is an onboard fxp controller, but it scans the slots first, so that the onboard controller is fxp1 if there is another intel card in the box, for example. I want to make the onboard controller fxp0 (since most MBs probe that way and it makes sense). Where would I have to hack to get Freebsd to probe slots in reverse order? Thanks, bryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 21: 4:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 10FE837B406; Sat, 8 Sep 2001 21:04:17 -0700 (PDT) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f8944AY03851; Sun, 9 Sep 2001 04:04:11 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Sun, 9 Sep 2001 04:04:06 +0000 (GMT) From: "E.B. Dreger" To: hackers@freebsd.org, net@freebsd.org Subject: outbound SOCK_STREAM - force source addr? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings all, Any way to force the source address for an outbound SOCK_STREAM? I know that one can do it for SOCK_DGRAM... but I've found no way to do so for, say, a TCP connection. Example: + dc0 has 192.168.0.1/24 as primary IP, 192.168.0.2/24 as alias + an outbound connection wishes to "come from" 192.168.0.2. I know that one can always use an IP socket (duh!), but it's silly to reinvent the TCP stack to force the source addr. I've not looked at jail(2) to see if there's anything similar. I don't necessarily want to _use_ jail(2), but if there's code that one could hack into a setsockopt(2) call, that would be a start. Finally, I don't care about how loose or tight allowed-address restrictions are, as long as any "local address" is acceptable. (Local address = one for which the machine answers ARP requests.) Suggestions? Have I overlooked something simple? TIA, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 21:29:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smile.idiom.com (inreach-gw1.idiom.com [209.209.13.26]) by hub.freebsd.org (Postfix) with ESMTP id 7DC7137B408 for ; Sat, 8 Sep 2001 21:29:45 -0700 (PDT) Received: from mdaxke (adsl-63-196-0-143.dsl.snfc21.pacbell.net [63.196.0.143]) by smile.idiom.com (8.9.1/8.8.5) with SMTP id VAA43455 for ; Sat, 8 Sep 2001 21:29:39 -0700 (PDT) Message-ID: <0ab401c138e7$f0ff2b60$6501a8c0@mdaxke> From: "Mark D. Anderson" To: Subject: Re: local changes to CVS tree Date: Sat, 8 Sep 2001 21:28:27 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Terry Lambert " wrote: > Any chance of getting CVSup to transfer from a remote repository > to a local vendor branch, instead of from a remote repository to > a local repository? > > This would be incredibly useful for building a combined local > source tree from multiple project's CVS repositories. It could > be used by FreeBSD for a number of "contrib" things, as well... this has probably been discussed before, but has the freebsd project considered using perforce for the central repository? perforce runs on freebsd. the company gives free licenses to free software projects, though it is not itself a source-available product. that may bother the religiously open-source, though it really is far superior to CVS. perl5 development has been using perforce; i don't know if they've decided yet what perl6 will use (and in fact that may depend on what sourceforge will supply them). see for example this post on why the perl project is using it: http://www.mail-archive.com/bootstrap@perl.org/msg00589.html as compared to cvs, it has support for views (including both multiple repositories and server-side proxying to other repositories), advanced branching/merging, atomic change sets, and is fast. there are various ways to offer at least readonly cvs access even if committers adopted perforce, as outlined in the link above. (in addition to various master-master and master-slave relationships between perforce and cvs, it should also be possible to have a pserver proxy server fronting over perforce. that would probably be ideal, though i don't think a trustworthy implementation of that yet exists.) -mda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 21:30:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3351E37B407; Sat, 8 Sep 2001 21:30:20 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 04EF181D05; Sat, 8 Sep 2001 23:30:15 -0500 (CDT) Date: Sat, 8 Sep 2001 23:30:15 -0500 From: Alfred Perlstein To: "E.B. Dreger" Cc: hackers@freebsd.org, net@freebsd.org Subject: Re: outbound SOCK_STREAM - force source addr? Message-ID: <20010908233014.J2965@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eddy+public+spam@noc.everquick.net on Sun, Sep 09, 2001 at 04:04:06AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * E.B. Dreger [010908 23:04] wrote: > Greetings all, > > Any way to force the source address for an outbound SOCK_STREAM? I > know that one can do it for SOCK_DGRAM... but I've found no way to > do so for, say, a TCP connection. It's not immediatly obvious, but you can bind(2) a socket before calling connect(2) in order to do this. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 8 23:52:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 060FC37B408 for ; Sat, 8 Sep 2001 23:52:23 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f896qL601446; Sun, 9 Sep 2001 00:52:22 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f896qLt02726; Sun, 9 Sep 2001 00:52:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109090652.f896qLt02726@harmony.village.org> To: Bsdguru@aol.com Subject: Re: PCI probe reordering? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 08 Sep 2001 21:49:48 EDT." <146.146a821.28cc24bc@aol.com> References: <146.146a821.28cc24bc@aol.com> Date: Sun, 09 Sep 2001 00:52:21 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <146.146a821.28cc24bc@aol.com> Bsdguru@aol.com writes: : I've encountered a MB that seems to probe devices in a less than desirable : order. There is an onboard fxp controller, but it scans the slots first, so : that the onboard controller is fxp1 if there is another intel card in the : box, for example. : : I want to make the onboard controller fxp0 (since most MBs probe that way and : it makes sense). Where would I have to hack to get Freebsd to probe slots in : reverse order? I truly believe that it would be easier to hack the pci bus code to support wired hints than it would be to hack the probe order and still have things work afterwards. The outline of the hack: hints.fxp.0.at="pci1:10:0" would be how you'd tell the system about it. Then, in the device probe/attachment routine, check to see if the "at" hint, if it exists, matches the bus:device:function you are about to probe. If so, go ahead with the probe/attach. Otherwise bump the child number and go to the "Then" part of this paragraph. This may be a little difficult, because I think that the probing the children is actually pushed down into the bus code... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message