From owner-freebsd-hackers Sun Jan 3 02:14:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05372 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 02:14:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA05357; Sun, 3 Jan 1999 02:14:24 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.56.52]) by smtp04.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA2873; Sun, 3 Jan 1999 11:13:55 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 03 Jan 1999 11:21:05 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Steven Ji Subject: RE: snotty quotes Cc: freebsd-advocacy@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jan-99 Steven Ji wrote: > I recently found this alleged Linus Torvalds quote on someone's sig, while > reading through a Linux mailing list archive. > > 'Ooohh.. "FreeBSD is faster over loopback, when compared to > Linux over the wire". Film at 11.' -Linus > > Does anybody know whether it's real? This statement is from the days the 2.0 wasn't even in the planning stages yet. I think this is a quote from back in the days he was still in Finland. That's roughly 5 years ago or so... > I've rarely heard such ludicrous comparisons... certainly never from any > official source or core member. Nor does the quote jive with what I know > about Linus himself. Ehm, it's his quote alright. It was one of the things he used to say when announcing new kernels and such... > In any case, this is the kind of wasted breath that causes tension between > the Linux and BSD communities, where there should instead be more healthy > exchange -- as there has been. Just about any UNIX-like OS has its place, > big or small, IMHO. Is this not the popular opinion? >From the BSD's mayhaps... IMHO Linux has it's share of 'l33t users. It also has good people offcourse =) --- Jeroen Ruigrok van der Werven Life is the only Pain asmodai(at)wxs.nl we endeavour... Network/Security Specialist BSD & picoBSD: The Power to Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 06:57:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02348 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 06:57:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from actcom.co.il (actcom.co.il [192.114.47.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA02343 for ; Sun, 3 Jan 1999 06:57:03 -0800 (PST) (envelope-from baum@actcom.co.il) Received: from localhost by actcom.co.il with SMTP (8.9.1a/actcom-0.2) id QAA18248 for ; Sun, 3 Jan 1999 16:56:34 +0200 (EET) (rfc931-sender: baum@localhost) Date: Sun, 3 Jan 1999 16:56:29 +0200 (EET) From: Alexander Indenbaum To: freebsd-hackers@FreeBSD.ORG Subject: Sun automount -> Amd (4.4BSD Automounter) map convertor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I'm looking for script which will convert Sun automount map into Amd (4.4BSD Automounter) map to be used in NIS Makefile. Does such tool exist? Alexander Indenbaum baum@actcom.co.il To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 08:37:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10183 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 08:37:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10014 for ; Sun, 3 Jan 1999 08:37:04 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id RAA25588 for freebsd-hackers@FreeBSD.ORG; Sun, 3 Jan 1999 17:36:35 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 8FB011509; Sun, 3 Jan 1999 12:45:57 +0100 (CET) Date: Sun, 3 Jan 1999 12:45:57 +0100 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: shared libs question (overlooked in freebsd-questions) Message-ID: <19990103124557.A2357@keltia.freenix.fr> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <19981230224144.A8416@apogee.whack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Alfred Perlstein on Thu, Dec 31, 1998 at 04:06:24AM -0500 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4931 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Alfred Perlstein: > b) save execution time if many seperate programs are being run that > use the same libraries (for instance a heavily loaded web site > running a lot of CGI programs that share common routines) because > of smaller text segment. (really better shared) Last time we talked about this with John Dyson, he said the opposite. FreeBSD can share text between statically linked programs better than with dynamically linked ones. So if you have many instance of the same program (e.g. shells), make the binary static. There is a not-so-small price to pay with dynamically linked programs. The startup time can be significant and you trash your cache lines when you call a library routine because you don't have locality anymore (the "make test" phase of Perl5 is about 20%-30% slower when using a dynamic Perl binary). Code inside a shared lib is PIC code and that is slower as well. > c) save memory Yes and no. Yes because the library is loaded only once and no because a static binary will have only the functions you need (with dependencies of course) whereas a library is mapped entirely. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 09:10:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA14098 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 09:10:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14092 for ; Sun, 3 Jan 1999 09:10:20 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id MAA46493; Sun, 3 Jan 1999 12:13:34 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Sun, 3 Jan 1999 12:13:34 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Ollivier Robert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared libs question (overlooked in freebsd-questions) In-Reply-To: <19990103124557.A2357@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 3 Jan 1999, Ollivier Robert wrote: > According to Alfred Perlstein: > > b) save execution time if many seperate programs are being run that > > use the same libraries (for instance a heavily loaded web site > > running a lot of CGI programs that share common routines) because > > of smaller text segment. (really better shared) > > Last time we talked about this with John Dyson, he said the opposite. > FreeBSD can share text between statically linked programs better than with > dynamically linked ones. So if you have many instance of the same program > (e.g. shells), make the binary static. > > There is a not-so-small price to pay with dynamically linked programs. The > startup time can be significant and you trash your cache lines when you call a > library routine because you don't have locality anymore (the "make test" > phase of Perl5 is about 20%-30% slower when using a dynamic Perl binary). > > Code inside a shared lib is PIC code and that is slower as well. recommended linking all of our CGI programs static but was told that because we have so many CGIs that use the same library, we were thrashing our system because of all the extra code + number of distinc programs being loaded. I didn't do the test myself as i came aboard after the switch was made, but because of oracle, cig libc and other shared objects i trhink it made sense in our case. -Alfred > > > c) save memory > > Yes and no. Yes because the library is loaded only once and no because a > static binary will have only the functions you need (with dependencies of > course) whereas a library is mapped entirely. Yes, in our case it seemed to make sense as well as deliver observable results. As with most things, your milage may vary :) > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 09:42:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17930 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 09:42:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA17925 for ; Sun, 3 Jan 1999 09:42:44 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id LAA21838 for freebsd-hackers@freebsd.org; Sun, 3 Jan 1999 11:42:19 -0600 (CST) From: Mohit Aron Message-Id: <199901031742.LAA21838@cs.rice.edu> Subject: fine-grained timers To: freebsd-hackers@FreeBSD.ORG Date: Sun, 3 Jan 1999 11:42:19 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm using FreeBSD-2.2.6. I want to make FreeBSD generate timer interrupts with a granularity as fine as 100usecs. Since the hardclock() operates at a 10ms granularity, its not of much use. I also want to disable dynamically the fine-grained interrupts, so I don't want to simply modify the granularity at which hardclock gets called. Can someone suggest the functions or places in the kernel which I should modify to register my own interrupt handler. Thanks, - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 09:53:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18833 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 09:53:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from csmd2.cs.uni-magdeburg.de (csmd2.CS.Uni-Magdeburg.De [141.44.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18825 for ; Sun, 3 Jan 1999 09:53:42 -0800 (PST) (envelope-from jesse@prinz-atm.CS.Uni-Magdeburg.De) Received: from knecht.cs.uni-magdeburg.de (knecht [141.44.21.3]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id SAA22992 for ; Sun, 3 Jan 1999 18:53:15 +0100 (MET) Received: (from jesse@localhost) by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) id SAA26049; Sun, 3 Jan 1999 18:51:54 +0100 (MET) From: Roland Jesse MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13967.44598.764504.512958@knecht> Date: Sun, 3 Jan 1999 18:51:50 +0100 (MET) To: freebsd-hackers@FreeBSD.ORG Subject: RTLD_GLOBAL in dlopen(3) X-Mailer: VM 6.63 under 20.4 "Emerald" XEmacs Lucid Reply-To: Roland Jesse X-Organization: University of Magdeburg X-Pgp-Fingerprint: 5D 08 5A E3 B4 AA 68 C1 FF 67 06 29 62 DD 9A D7 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I am in the process of porting Bamboo (http://watsen.net/Bamboo/) to FreeBSD. While doing so, I realized that the RTLD_GLOBAL flag for dlopen() does not exist on FreeBSD (only RTLD_LAZY, RTLD_NOW, and RTLD_NEXT do). It seems to exist on a couple other Unix OS. It does at least on Solaris, Irix, and Linux. The dlopen manpage on Solaris says: To determine the scope of visibility for symbols loaded with a dlopen() invocation, the mode parameter should be bitwise or'ed with one of the following values: RTLD_GLOBAL The object's global symbols are made available for the relocation processing of any other object. In addition, symbol lookup using dlopen(0, mode) and an asso- ciated dlsym(), allows objects loaded with RTLD_GLOBAL to be searched. Is there a counterpart of it that can be used to achieve the same effect (i.e. making symbols accessible to everyone without any explicit calls)? Any hints in the right direction are appreciated. Regards, Roland -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 10:11:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20637 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 10:11:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from genius.cirx.org (r00t.m1.ntu.edu.tw [140.112.240.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20613 for ; Sun, 3 Jan 1999 10:10:41 -0800 (PST) (envelope-from clkao@CirX.ORG) Received: (from clkao@localhost) by genius.cirx.org (8.9.1/8.9.1) id CAA37568; Mon, 4 Jan 1999 02:08:54 +0800 (CST) (envelope-from clkao@CirX.ORG) Date: Mon, 4 Jan 1999 02:08:54 +0800 (CST) Message-Id: <199901031808.CAA37568@genius.cirx.org> X-Authentication-Warning: genius.cirx.org: clkao set sender to clkao@CirX.ORG using -f From: Chia-liang Kao To: freebsd-hackers@FreeBSD.ORG Subject: setjmp/longjmp corrupts stack? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have a little program attached below causing SIGSEGV. But the program works out (partially, see below) dramatically if the function being called in main() (haha()) changes to hehe(). In my trace record, the stack corrupted right after longjmp to j2. But if I change the haha() in main() to hehe(), although the result is as expected, the stack is somewhat corrupted too. Like the following: (gdb) bt #0 haha () at testjmp.c:18 #1 0x804852d in main () at testjmp.c:35 #2 0xefbfd704 in ?? () #3 0x6b6c633d in ?? () Error accessing memory address 0x52455355: Bad address. The situation is met also when calling longjmp to j2, too. My box is 3.0-CURRENT FreeBSD 3.0-CURRENT #2: Sat Jan 2 05:26:13 CST 1999. The result tested on Linux 2.0.34 is the same; while it works as expected(well, it's just my expectation, perhaps the POSIX definition is not as what I thought. But I can't find any other useful info on man pages either) on Solaris 2.6. Regards, CLK ====================== #include #include jmp_buf j1, j2; void haha() { int r; static int cnt; /* ... */ printf("send\n"); if(!(r =setjmp(j2))) { /* go back */ longjmp(j1, ++cnt); } /* resume */ printf("resume\n"); return; } void hehe() { haha(); } int main() { int r; if((r = setjmp(j1))) { printf("jmp %d\n", r); if(r == 1) longjmp(j2, 1); else exit(0); } printf("main\n"); haha(); printf("after longjmp\n"); return 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 11:40:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29285 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 11:40:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29277 for ; Sun, 3 Jan 1999 11:40:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA51723; Sun, 3 Jan 1999 11:39:37 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Jan 1999 11:39:37 -0800 (PST) From: Matthew Dillon Message-Id: <199901031939.LAA51723@apollo.backplane.com> To: Chia-liang Kao Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: setjmp/longjmp corrupts stack? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, : :I have a little program attached below causing SIGSEGV. But the :program works out (partially, see below) dramatically if the function :being called in main() (haha()) changes to hehe(). : :In my trace record, the stack corrupted right after longjmp to j2. :But if I change the haha() in main() to hehe(), although the result is :as expected, the stack is somewhat corrupted too. Like the following: :... What you are doing is totally illegal. You cannot push down the stack, setjmp, return from that context, then longjmp() back down into it. The only legal way to use setjmp()/longjmp() is for the context that you setjmp() to remain *valid* from the point setjmp() is called to the point longjmp() is called to get back to it. In the code below you setjmp j1 in main, then call haha which setjmp's j2 and longjmp's back to j1 (which is ok), but that means you've popped the haha() context. Then your main function longjmp's back to j2, inside haha(), which is now totally illegal because that context was popped when you longjmp'd out of it the first time. -Matt :Regards, :CLK : :====================== :#include :#include : :jmp_buf j1, j2; : :void :haha() :{ : int r; : static int cnt; : /* ... */ : printf("send\n"); : if(!(r =setjmp(j2))) { : /* go back */ : longjmp(j1, ++cnt); : } : /* resume */ : printf("resume\n"); : return; :} : :void :hehe() :{ : haha(); :} : :int :main() :{ : int r; : if((r = setjmp(j1))) { : printf("jmp %d\n", r); : if(r == 1) : longjmp(j2, 1); : else : exit(0); : } : printf("main\n"); : haha(); : printf("after longjmp\n"); : return 0; :} : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 12:12:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02400 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 12:12:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02394 for ; Sun, 3 Jan 1999 12:12:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id MAA52065; Sun, 3 Jan 1999 12:11:33 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Jan 1999 12:11:33 -0800 (PST) From: Matthew Dillon Message-Id: <199901032011.MAA52065@apollo.backplane.com> To: Ollivier Robert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared libs question (overlooked in freebsd-questions) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :According to Alfred Perlstein: :> b) save execution time if many seperate programs are being run that :> use the same libraries (for instance a heavily loaded web site :> running a lot of CGI programs that share common routines) because :> of smaller text segment. (really better shared) : :Last time we talked about this with John Dyson, he said the opposite. :FreeBSD can share text between statically linked programs better than with :dynamically linked ones. So if you have many instance of the same program :(e.g. shells), make the binary static. : :There is a not-so-small price to pay with dynamically linked programs. The :startup time can be significant and you trash your cache lines when you call a :library routine because you don't have locality anymore (the "make test" :phase of Perl5 is about 20%-30% slower when using a dynamic Perl binary). : :Code inside a shared lib is PIC code and that is slower as well. : :> c) save memory : :Yes and no. Yes because the library is loaded only once and no because a :static binary will have only the functions you need (with dependencies of :course) whereas a library is mapped entirely. :-- :Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr John is right. Dynamic libraries work better (save memory) only when you have lots of *DIFFERENT* programs accessing the same library. If you have many separately-run instances of a single program, static linking is generally better. Remember that dynamic libraries not only require mmap()'ing (which is cheap but adds a few milliseconds to the startup), it also requires doing fixups of the library vectors, which causes copy-on-write faults and is not cheap. Each instance of the same program, if run separately, will eat more memory. In the case of a program which fork()'s multiple copies of itself, static and dynamic binaries will work about the same - at the time of the fork the fixups have already occured, so the pages are shared across the N forked copies of the program. You can easily see this if you have /proc mounted. A 'vnode' object below indicates a shared segment. A 'default' or 'swap' object indicates (typically) a private segment. 'default' and 'swap' objects can only be shared through fork(). With an ELF kernel: apollo:/tmp# cc hello.c -o hello -static -Wall apollo:/tmp# ./hello hello world 52021 ^Z Suspended apollo:/tmp# cat /proc/52021/map 0x8048000 0x8051000 9 12 4200249 r-x 2 1 0x0 COW NC vnode 0x8051000 0x8052000 1 0 4200253 rw- 1 0 0x2180 COW NNC vnode 0x8052000 0x8053000 1 0 4200251 rw- 2 0 0x180 NCOW NNC default 0x8053000 0x8064000 2 0 4200251 rwx 2 0 0x180 NCOW NNC default 0x28051000 0x28052000 1 0 4200254 rwx 1 0 0x2180 NCOW NNC default 0xefbde000 0xefbfe000 1 0 4200252 rwx 1 0 0x2180 NCOW NNC default apollo:/tmp# cc hello.c -o hello -Wall apollo:/tmp# ./hello hello world 52028 ^Z Suspended apollo:/tmp# cat /proc/52028/map 0x8048000 0x8049000 1 0 4200303 r-x 1 0 0x0 COW NC vnode 0x8049000 0x804a000 1 0 4200305 rw- 2 0 0x180 NCOW NNC default 0x804a000 0x805b000 2 0 4200305 rwx 2 0 0x180 NCOW NNC default 0x28049000 0x28051000 5 0 4200309 rwx 1 0 0x2180 NCOW NNC default 0x28051000 0x280bd000 51 0 1879718 r-x 27 11 0x4 COW NC vnode 0x280bd000 0x280c2000 5 0 4200310 rwx 1 0 0x2180 COW NNC vnode 0x280c2000 0x280d2000 3 0 4200311 rwx 1 0 0x2180 NCOW NNC default 0x40000000 0x4000e000 10 0 1941346 r-x 27 11 0x4 COW NC vnode 0x4000e000 0x4000f000 1 0 4200308 rw- 1 0 0x2180 COW NNC vnode 0x4000f000 0x40011000 2 0 4200306 rw- 1 0 0x2180 NCOW NNC default 0xefbde000 0xefbfe000 2 0 4200307 rwx 1 0 0x2180 NCOW NNC default Compiled A.OUT: apollo:/tmp# cc hello.c -o hello -static -Wall -aout apollo:/tmp# ./hello hello world 52042 ^Z Suspended apollo:/tmp# cat /proc/52042/map 0x1000 0xa000 9 12 4200488 r-x 2 1 0x0 COW NC vnode 0xa000 0xb000 1 0 4200492 rwx 1 0 0x2180 COW NNC vnode 0xb000 0x1d000 3 0 4200491 rwx 1 0 0x2180 NCOW NNC default 0x2000a000 0x2000b000 1 0 4200493 rwx 1 0 0x2180 NCOW NNC default 0xefbde000 0xefbfe000 1 0 4200490 rwx 1 0 0x2180 NCOW NNC default apollo:/tmp# cc hello.c -o hello -Wall -aout apollo:/tmp# ./hello hello world 52049 ^Z Suspended apollo:/tmp# cat /proc/52049/map 0x1000 0x2000 1 3 4200544 r-x 2 1 0x0 COW NC vnode 0x2000 0x3000 1 0 4200547 rwx 1 0 0x2180 COW NNC vnode 0x3000 0x18000 6 0 4200549 rwx 1 0 0x2180 NCOW NNC default 0x20002000 0x20013000 12 0 2027070 r-x 21 9 0x4 COW NC vnode 0x20013000 0x20014000 1 0 4200548 rwx 2 0 0x2180 COW NNC vnode 0x20014000 0x20015000 1 0 4200548 rwx 2 0 0x2180 COW NNC vnode 0x20015000 0x20017000 2 0 4200550 rwx 1 0 0x2180 NCOW NNC default 0x20019000 0x20085000 72 0 2023214 r-x 20 8 0x4 COW NC vnode 0x20085000 0x20089000 4 0 4200551 rwx 1 0 0x2180 COW NNC vnode 0x20089000 0x20097000 2 0 4200552 rwx 1 0 0x2180 NCOW NNC default 0xefbde000 0xefbfe000 4 0 4200546 rwx 1 0 0x2180 NCOW NNC default -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 12:25:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03664 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 12:25:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03658 for ; Sun, 3 Jan 1999 12:25:16 -0800 (PST) (envelope-from rmedmond@cris.com) Received: from newman.concentric.net (newman [207.155.184.71]) by darius.concentric.net (8.9.1a/(98/08/04 5.11)) id PAA28347; Sun, 3 Jan 1999 15:24:43 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from crc3.concentric.net (ts004d15.ksc-mo.concentric.net [206.173.129.171]) by newman.concentric.net (8.9.1a) id PAA21317; Sun, 3 Jan 1999 15:24:27 -0500 (EST) From: "Rick Edmonds" To: Subject: RE: freebsd-hackers-digest V4 #353 Date: Sun, 3 Jan 1999 14:24:25 -0600 Message-ID: <000d01be3757$0f759880$ab81adce@crc3.concentric.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <199901030701.XAA20376@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Unsubscribe bsd-hackers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 12:44:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05594 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 12:44:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cerebus.nectar.com (nectar-gw.nectar.com [204.0.249.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05589 for ; Sun, 3 Jan 1999 12:44:35 -0800 (PST) (envelope-from nectar@nectar.com) Received: (from smap@localhost) by cerebus.nectar.com (8.9.1/8.9.1) id OAA19736; Sun, 3 Jan 1999 14:44:00 -0600 (CST) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com(10.0.0.101) by cerebus.nectar.com via smap (V2.1) id xma019734; Sun, 3 Jan 99 14:43:50 -0600 Received: from spawn.nectar.com (localhost [127.0.0.1]) by spawn.nectar.com (8.9.1/8.9.1) with ESMTP id OAA10318; Sun, 3 Jan 1999 14:43:50 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Message-Id: <199901032043.OAA10318@spawn.nectar.com> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: lists/freebsd X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-pgp262.txt From: Jacques Vidrine In-reply-to: <199901031930.LAA06745@dingo.cdrom.com> References: <199901031930.LAA06745@dingo.cdrom.com> Subject: Re: Bootblocks / Bootloader Mime-Version: 1.0 Content-Type: text/plain To: Mike Smith cc: hackers@FreeBSD.ORG Date: Sun, 03 Jan 1999 14:43:50 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 3 January 1999 at 11:30, Mike Smith wrote: [snip] > The online help in the loader is your best reference (for now) for > boot.conf (soon to be loader.rc). It's still in flux, although I > expect to have to freeze it soon for 3.0.x. By the way, why isn't /boot/loader.help installed by default? Jacques Vidrine / n@nectar.com / nectar@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 Jan 3 12:53:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06469 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 12:53:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06463 for ; Sun, 3 Jan 1999 12:53:28 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA07286; Sun, 3 Jan 1999 12:49:28 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901032049.MAA07286@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jacques Vidrine cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Bootblocks / Bootloader In-reply-to: Your message of "Sun, 03 Jan 1999 14:43:50 CST." <199901032043.OAA10318@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 12:49:27 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 3 January 1999 at 11:30, Mike Smith wrote: > [snip] > > The online help in the loader is your best reference (for now) for > > boot.conf (soon to be loader.rc). It's still in flux, although I > > expect to have to freeze it soon for 3.0.x. > > By the way, why isn't /boot/loader.help installed by default? There was a perl-related problem with the script that generated it; I think that's actually been fixed, so I can turn it back on again. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 13:50:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11709 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 13:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailhost.mil.ameritech.net (mpdr0.milwaukee.wi.ameritech.net [206.141.239.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11704 for ; Sun, 3 Jan 1999 13:50:09 -0800 (PST) (envelope-from randyd@ameritech.net) Received: from ameritech.net ([209.18.22.156]) by mailhost.mil.ameritech.net (InterMail v03.02.07 118 124) with ESMTP id <19990103214225.DHVK17634@ameritech.net> for ; Sun, 3 Jan 1999 15:42:25 -0600 Message-ID: <368FE536.D6ED2B49@ameritech.net> Date: Sun, 03 Jan 1999 15:46:30 -0600 From: "Randall D. DuCharme" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: FreeBSD partition MOVED by SCO Install Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, I posted this message a few days ago to -questions. Haven't heard anything so I thought I'd try the hackers list before I 'start over'. I try to make it a practice not to directly bother hackers so please forgive the intrusion but I'm more than a little baffled by what happend and am certain there's an easy solution. I just don't know what it is. I don't subscribe to hackers so if you do respond, please write me directly. Any ideas at all are greatly appreciated! The message: A really stupid thing just happened to me. I have 3 SCSI disks in my machine. Disk 0 is a 4 gig, disk 1 and 2 are 2 gigs each. I had NT-4 on disk 0, and FreeBSD-Current on disks 1 and 2. Disk 1 was set up as follows.... sd1s1a / 25meg sd1s1b swap 120meg sd1s1e /usr ~1855 meg Disk 2 was set up as follows..... sd2s3b swap 120meg sd2s3e /usr2 ~1880 meg Both disks were "dangerously dedicated" and I always used a boot floppy to start FreeBSD. I removed NT from the first disk (disk 0) and installed SCO OpenServer 5.0.4 so I could begin work on porting a couple apps to FreeBSD for one of my business customers. The process of doing this changed the partition table of the second disk (disk 1), or the first FreeBSD disk. Booting FreeBSD now results in mounting da1s4a as /, (read only) and fails to add the swap or /usr slices. I can view, navigate, and execute programs from the root partition. FreeBSD's fdisk now shows that partition 1,2, and 3 are unused and that partition 4 is the FreeBSD partition. The geometries and partition type are correct.... it's just as if it was 'moved' from partition 1 to partition 4. The disklabel also seems to be correct.... that is, disklabel -r shows the correct slices of the correct size. I cannot mount / read-write or mount /usr at all as there are no /dev/sd1s4* devices and can't mount / read-write to create them. Disk 2 was unaffected and can be mounted normally. Is there an easy way to recover from this? I'm assuming that if I edit the partition table I'll lose everything. I have a backup so it's not a loss. I'd rather avoid all that hassle though, if possible. Many thanks in advance -- Randall D DuCharme Systems Engineer Novell, Microsoft, and UNIX Networking Support Computer Specialists Free Your Machine.... FreeBSD 414-253-9998 414-253-9919 (fax) The Power To Serve! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 14:24:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14647 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 14:24:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14642 for ; Sun, 3 Jan 1999 14:24:29 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id OAA07814; Sun, 3 Jan 1999 14:21:13 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901032221.OAA07814@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Randall D. DuCharme" cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD partition MOVED by SCO Install In-reply-to: Your message of "Sun, 03 Jan 1999 15:46:30 CST." <368FE536.D6ED2B49@ameritech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 14:21:13 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I removed NT from the first disk (disk 0) and installed SCO OpenServer > 5.0.4 so I could begin work on porting a couple apps to FreeBSD for one > of my business customers. The process of doing this changed the > partition table of the second disk (disk 1), or the first FreeBSD disk. Did you do this intentionally, or did it "just do it" for you? If the latter, you might want to gripe at SCO. > Booting FreeBSD now results in mounting da1s4a as /, (read only) and > fails to add the swap or /usr slices. I can view, navigate, and execute > programs from the root partition. FreeBSD's fdisk now shows that > partition 1,2, and 3 are unused and that partition 4 is the FreeBSD > partition. The geometries and partition type are correct.... it's just > as if it was 'moved' from partition 1 to partition 4. The disklabel > also seems to be correct.... that is, disklabel -r shows the correct > slices of the correct size. I cannot mount / read-write or mount /usr > at all as there are no /dev/sd1s4* devices and can't mount / read-write > to create them. Disk 2 was unaffected and can be mounted normally. > > Is there an easy way to recover from this? I'm assuming that if I edit > the partition table I'll lose everything. I have a backup so it's not a > loss. I'd rather avoid all that hassle though, if possible. Boot the FreeBSD installer, use the Custom menu's fdisk screen to 'dangerously dedicate' the disk again, then 'w' to write the information back out. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 14:33:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15510 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 14:33:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15505 for ; Sun, 3 Jan 1999 14:33:34 -0800 (PST) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.9.1/8.8.6) id RAA01244 for hackers@FreeBSD.ORG; Sun, 3 Jan 1999 17:33:09 -0500 (EST) Date: Sun, 3 Jan 1999 17:33:09 -0500 (EST) From: "Stephen J. Roznowski" Message-Id: <199901032233.RAA01244@istari.home.net> To: hackers@FreeBSD.ORG Subject: Why is root's crontab different? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In tracking down the cause of my "/var/log/maillog.0: No such file or directory" errors from newsyslog, I "discovered" that I had both a root crontab entry and /etc/crontab. Both of these were running newsyslog at the same time and they were conflicting with each other. My question is why is root's crontab entry treated differently (i.e. a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? Thanks, -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 14:44:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16982 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 14:44:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smarter.than.nu (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16977 for ; Sun, 3 Jan 1999 14:44:33 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from localhost (localhost [127.0.0.1]) by smarter.than.nu (8.9.1/8.9.1) with ESMTP id OAA03046; Sun, 3 Jan 1999 14:43:59 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Date: Sun, 3 Jan 1999 14:43:58 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: "Stephen J. Roznowski" cc: hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-Reply-To: <199901032233.RAA01244@istari.home.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > In tracking down the cause of my "/var/log/maillog.0: No such file > or directory" errors from newsyslog, I "discovered" that I had both > a root crontab entry and /etc/crontab. Both of these were running > newsyslog at the same time and they were conflicting with each > other. > > My question is why is root's crontab entry treated differently (i.e. > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? /etc/crontab allows you to specify the user who commands should be run as -- Brian Buchanan brian@smarter.than.nu brian@CSUA.Berkeley.EDU "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 14:55:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18038 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 14:55:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18015 for ; Sun, 3 Jan 1999 14:55:01 -0800 (PST) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.9.1/8.8.6) id RAA04742; Sun, 3 Jan 1999 17:54:31 -0500 (EST) Date: Sun, 3 Jan 1999 17:54:31 -0500 (EST) From: "Stephen J. Roznowski" Message-Id: <199901032254.RAA04742@istari.home.net> To: brian@CSUA.Berkeley.EDU Subject: Re: Why is root's crontab different? In-Reply-To: Mail from '"Brian W. Buchanan" ' dated: Sun, 3 Jan 1999 14:43:58 -0800 (PST) Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: "Brian W. Buchanan" > > On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > > In tracking down the cause of my "/var/log/maillog.0: No such file > > or directory" errors from newsyslog, I "discovered" that I had both > > a root crontab entry and /etc/crontab. Both of these were running > > newsyslog at the same time and they were conflicting with each > > other. > > > > My question is why is root's crontab entry treated differently (i.e. > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > /etc/crontab allows you to specify the user who commands should be run as I understand the difference, but why would this be better than installing crontabs for the various (system) users? (for example, news). -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 14:58:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18523 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 14:58:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18514 for ; Sun, 3 Jan 1999 14:58:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id OAA07979; Sun, 3 Jan 1999 14:55:20 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901032255.OAA07979@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Stephen J. Roznowski" cc: brian@CSUA.Berkeley.EDU, hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-reply-to: Your message of "Sun, 03 Jan 1999 17:54:31 EST." <199901032254.RAA04742@istari.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 14:55:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > From: "Brian W. Buchanan" > > > > On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > > > In tracking down the cause of my "/var/log/maillog.0: No such file > > > or directory" errors from newsyslog, I "discovered" that I had both > > > a root crontab entry and /etc/crontab. Both of these were running > > > newsyslog at the same time and they were conflicting with each > > > other. > > > > > > My question is why is root's crontab entry treated differently (i.e. > > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > > > /etc/crontab allows you to specify the user who commands should be run as > > I understand the difference, but why would this be better than installing > crontabs for the various (system) users? (for example, news). Because /etc/crontab is controlled by the adminstrator, while the user's contab is controlled by the user. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 15:01:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18729 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 15:01:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cserv.oksys.bg (ppp3.bulinfo.net [195.10.36.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18717 for ; Sun, 3 Jan 1999 15:01:11 -0800 (PST) (envelope-from ian@bulinfo.net) Received: from bulinfo.net (cserv.oksys.bg [192.72.180.21]) by cserv.oksys.bg (8.8.8/8.8.8) with ESMTP id BAA21869 for ; Mon, 4 Jan 1999 01:00:33 +0200 (EET) (envelope-from ian@bulinfo.net) Message-ID: <368FF691.B2B7B3D8@bulinfo.net> Date: Mon, 04 Jan 1999 01:00:33 +0200 From: Yani Brankov Organization: ok systems X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: bg, en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? References: <199901032233.RAA01244@istari.home.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Stephen J. Roznowski" wrote: > > My question is why is root's crontab entry treated differently (i.e. > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > /var/cron/tabs/root contains the root user crontab settings and /var/crontab contains system crontab settings. it's for convenience I think. iani -- When the people talk about computers, the word Microsoft is the most frequently used one. Guess why? :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 15:15:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19919 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 15:15:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19914 for ; Sun, 3 Jan 1999 15:15:19 -0800 (PST) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.9.1/8.8.6) id SAA04829; Sun, 3 Jan 1999 18:13:39 -0500 (EST) Date: Sun, 3 Jan 1999 18:13:39 -0500 (EST) From: "Stephen J. Roznowski" Message-Id: <199901032313.SAA04829@istari.home.net> To: ian@bulinfo.net, hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-Reply-To: Mail from 'Yani Brankov ' dated: Mon, 04 Jan 1999 01:00:33 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Yani Brankov > > "Stephen J. Roznowski" wrote: > > > > My question is why is root's crontab entry treated differently (i.e. > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > > > /var/cron/tabs/root contains the root user crontab settings and > /var/crontab contains system crontab settings. > it's for convenience I think. [Not trying to be argumentative....] In the case of the "default" files, what is the difference? /usr/src/etc/crontab only contains entries for root, no other users. [Isn't root synonymous with "system crontab settings" in this case?] Thanks, -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 15:17:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20209 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 15:17:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20204 for ; Sun, 3 Jan 1999 15:17:05 -0800 (PST) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.9.1/8.8.6) id SAA04839; Sun, 3 Jan 1999 18:15:54 -0500 (EST) Date: Sun, 3 Jan 1999 18:15:54 -0500 (EST) From: "Stephen J. Roznowski" Message-Id: <199901032315.SAA04839@istari.home.net> To: mike@smith.net.au Subject: Re: Why is root's crontab different? In-Reply-To: Mail from 'Mike Smith ' dated: Sun, 03 Jan 1999 14:55:20 -0800 Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Mike Smith > > > > From: "Brian W. Buchanan" > > > > > > On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > > > > In tracking down the cause of my "/var/log/maillog.0: No such file > > > > or directory" errors from newsyslog, I "discovered" that I had both > > > > a root crontab entry and /etc/crontab. Both of these were running > > > > newsyslog at the same time and they were conflicting with each > > > > other. > > > > > > > > My question is why is root's crontab entry treated differently (i.e. > > > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > > > > > /etc/crontab allows you to specify the user who commands should be run as > > > > I understand the difference, but why would this be better than installing > > crontabs for the various (system) users? (for example, news). > > Because /etc/crontab is controlled by the adminstrator, while the > user's contab is controlled by the user. [Not trying to be argumentative here....] In the case of root, what is the difference? [Or any of the "system users", like news, etc...] Thanks, -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 15:30:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21553 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 15:30:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cserv.oksys.bg (ppp3.bulinfo.net [195.10.36.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21546 for ; Sun, 3 Jan 1999 15:30:21 -0800 (PST) (envelope-from ian@bulinfo.net) Received: from bulinfo.net (cserv.oksys.bg [192.72.180.21]) by cserv.oksys.bg (8.8.8/8.8.8) with ESMTP id BAA25912; Mon, 4 Jan 1999 01:29:06 +0200 (EET) (envelope-from ian@bulinfo.net) Message-ID: <368FFD42.F849603C@bulinfo.net> Date: Mon, 04 Jan 1999 01:29:06 +0200 From: Yani Brankov Organization: ok systems X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: bg, en MIME-Version: 1.0 To: "Stephen J. Roznowski" , hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? References: <199901032313.SAA04829@istari.home.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Stephen J. Roznowski" wrote: > > > From: Yani Brankov > > > > "Stephen J. Roznowski" wrote: > > > > > > My question is why is root's crontab entry treated differently (i.e. > > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > > > > > > /var/cron/tabs/root contains the root user crontab settings and > > /var/crontab contains system crontab settings. > > it's for convenience I think. > > [Not trying to be argumentative....] > > In the case of the "default" files, what is the difference? > /usr/src/etc/crontab only contains entries for root, no other users. > [Isn't root synonymous with "system crontab settings" in this case?] > In this case - yes, but you may add entries for any user there. /etc/crontab duplicates the role of the user crontabs, but anyway I think it's more convenient to have all the necessary system crontab entries in one file. -- When the people talk about computers, the word Microsoft is the most frequently used one. Guess why? :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 15:52:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23909 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 15:52:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23903; Sun, 3 Jan 1999 15:52:37 -0800 (PST) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id IAA13119; Mon, 4 Jan 1999 08:52:08 +0900 (JST) To: freebsd-net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: IPsec-only KAME kit Reply-To: freebsd-net@FreeBSD.ORG X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Mon, 04 Jan 1999 08:52:07 +0900 Message-ID: <13115.915407527@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG IPsec-only KAME kit for FreeBSD 3.0-RELEASE is ready for you. The kit provides fully functional IPsec for FreeBSD 3.0-RELEASE. Please report any bugs to KAME team via KAME GNATS bug database (NOT to FreeBSD bug database). Thanks. ftp://ftp.kame.net/pub/kame/snap/kame-ipsec-19990104-fbsd30-snap.tgz itojun ------- Forwarded Message To: snap-users@kame.net X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: KAME SNAP 19980104 From: Jun-ichiro itojun Hagino Date: Mon, 04 Jan 1999 08:48:52 +0900 Message-ID: <13042.915407332@coconut.itojun.org> Sender: itojun@coconut.itojun.org A happy new year! We got the very first KAME SNAP kit for 1999. Key changes: - ucd-snmp is updated to 3.5.3. - NEW: IPsec-only (without IPv6) KAME kit for FreeBSD 3.0-RELEASE. Please test it and report troubles/bugs if any, to our GNATS bug tracking system. KAME/FreeBSD 3.0-RELEASE is under final preparations. Enjoy! itojun - --- CHANGELOG for KAME kit $Id: CHANGELOG,v 1.1.2.24.2.23.2.154.2.206.2.31 1998/12/31 11:54:07 itojun Exp $ <199812> Thu Dec 31 20:56:12 JST 1998 itojun@iijlab.net * kit/ports/ucd-snmp: upgrade base version to to ucd-snmp 3.5.3. Thu Dec 31 03:37:03 1998 Yoshinobu Inoue * kit/ports/socks64: made compilable on KAME FreeBSD 3.0. (Include if_var.h. Should be removed in the future, also with removal of in6_var.h) Wed Dec 30 22:28:58 1998 Yoshinobu Inoue * kit/src Made then compilable on KAME FreeBSD 3.0. Especially many ifdef's are added to route6d/ifmcstat.c. Tue Dec 29 18:07:52 1998 Yoshinobu Inoue * sys/net,netinet,netinet6 sync with FreeBSD3.0 as much as possible.(mainly netinet6) Fri Dec 25 22:06:04 1998 Yoshinobu Inoue * sys/netinet6/nd6_rtr.c: Added consideration of ndpr_rrf_decrvalid and ndpr_rrf_decrprefd for address lifetime initialization. Without this, prefixes allocated by prefix command will be IN6_IFF_DEPRECATED after some period of time. Fri Dec 25 17:02:08 JST 1998 itojun@iijlab.net * kit/ports/bind8 (FreeBSD): IPv6-ready bind8. named will accept queries to IPv6 UDP/TCP port 53, dig/nslookup/whatever are able to make queries toward IPv6 UDP/TCP port 53, and so forth. 1998-12-24 JINMEI, Tatuya * in6_proto.c,ip6_input.c,ip6_var.h: removed none_input(). Now a packet whose protocol is IPPROTO_NONE can safely be passed to the userland. netinet/in_proto.c was also modified. Thu Dec 24 19:40:27 1998 Yoshinobu Inoue * kit/src/libinet6/resolv/res_debug.c add ifdef of T_UINFO, T_UID, T_GID, to make it compilable on FreeBSD 3.0. 1998-12-24 JINMEI, Tatuya * probe.c (probe_init): call shutdown() after opening the probe socket to make the socket `send-only'. Thu Dec 24 11:46:38 JST 1998 itojun@iijlab.net * sys/netinet6/raw_ip6.c: setsockopt(IPV6_CHECSUM) sometimes caused SEGV due to a bug in mbuf boundary checks. It is now fixed. Thu Dec 24 03:11:19 JST 1998 itojun@iijlab.net * kit/ports/apache13: updated to use new patch. (fixed args for freeaddrinfo()) Reported by: Florent Parent Andreas Wrede ------- End of 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 Jan 3 16:22:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29034 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 16:22:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29025 for ; Sun, 3 Jan 1999 16:22:13 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA08388; Sun, 3 Jan 1999 16:18:53 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901040018.QAA08388@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Stephen J. Roznowski" cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-reply-to: Your message of "Sun, 03 Jan 1999 18:15:54 EST." <199901032315.SAA04839@istari.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 16:18:53 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > From: Mike Smith > > > > > > From: "Brian W. Buchanan" > > > > > > > > On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > > > > > In tracking down the cause of my "/var/log/maillog.0: No such file > > > > > or directory" errors from newsyslog, I "discovered" that I had both > > > > > a root crontab entry and /etc/crontab. Both of these were running > > > > > newsyslog at the same time and they were conflicting with each > > > > > other. > > > > > > > > > > My question is why is root's crontab entry treated differently (i.e. > > > > > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? > > > > > > > > /etc/crontab allows you to specify the user who commands should be run as > > > > > > I understand the difference, but why would this be better than installing > > > crontabs for the various (system) users? (for example, news). > > > > Because /etc/crontab is controlled by the adminstrator, while the > > user's contab is controlled by the user. > > [Not trying to be argumentative here....] > > In the case of root, what is the difference? [Or any of the "system users", > like news, etc...] They grow out of generalising fundamentally different approaches. The per-user crontab is a mechanism whereby any user can arrange to have cron run jobs for them. The system crontab in /etc is a mechanism whereby the administrator can arrange to have jobs run as any user. The overlap creates a little duplication of functionality, but it's by no means a conflict. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 16:28:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29514 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 16:28:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from liberty.bulinfo.net (liberty.bulinfo.net [195.10.36.71]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA29509 for ; Sun, 3 Jan 1999 16:28:24 -0800 (PST) (envelope-from ian@bulinfo.net) Received: (qmail 72900 invoked from network); 4 Jan 1999 00:27:47 -0000 Received: from gate.bulinfo.net (195.10.36.66) by liberty.bulinfo.net with SMTP; 4 Jan 1999 00:27:47 -0000 Received: (qmail 18247 invoked from network); 4 Jan 1999 00:27:41 -0000 Received: from ppp48.bulinfo.net (HELO cserv.oksys.bg) (195.10.36.93) by gate.bulinfo.net with SMTP; 4 Jan 1999 00:27:41 -0000 Received: from bulinfo.net (cserv.oksys.bg [192.72.180.21]) by cserv.oksys.bg (8.8.8/8.8.8) with ESMTP id CAA28982; Mon, 4 Jan 1999 02:20:36 +0200 (EET) (envelope-from ian@bulinfo.net) Message-ID: <36900954.DA0F0DC6@bulinfo.net> Date: Mon, 04 Jan 1999 02:20:36 +0200 From: Yani Brankov Organization: ok systems X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: bg, en MIME-Version: 1.0 To: J_Shevland@TurnAround.com.au, hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? References: <000601be3771$51802fa0$6e01a8c0@tasshev.turnaround.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > -- > > When the people talk about computers, > > the word Microsoft is the most > > frequently used one. > > Guess why? :) > > > > I don't get it... why? Excuse me everybody. I think it evaluates to TRUE now. I (bug)fixed it: -- When the people talk about troubles, the word Microsoft is the most frequently used one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 16:46:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01709 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 16:46:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01694; Sun, 3 Jan 1999 16:46:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA21303; Mon, 4 Jan 1999 01:45:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA02197; Mon, 4 Jan 1999 01:45:45 +0100 (MET) Message-ID: <19990104014545.E88411@follo.net> Date: Mon, 4 Jan 1999 01:45:45 +0100 From: Eivind Eklund To: "Daniel C. Sobral" Cc: hackers@FreeBSD.ORG Subject: Re: FICL & Perl References: <36900AE7.FB3AD249@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <36900AE7.FB3AD249@newsguy.com>; from Daniel C. Sobral on Mon, Jan 04, 1999 at 09:27:19AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm moving this to -hackers where it belong. -current is getting TWICE THE FREAKING TRAFFIC of -hackers these days. On Mon, Jan 04, 1999 at 09:27:19AM +0900, Daniel C. Sobral wrote: > Is there any interest in getting rid of the perl script in the ficl > build? It is a very legible script indeed, but not being able to set > NOPERL is quite a nuisance for me. (As a bonus, my alternative > doesn't have a small bug in Mr. Sadler's script :). Depends on the size and clarity of the replacement. Be aware that we use perl5 in other parts of the build process, too - e.g, the device config generation in the kernel build. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 17:02:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03163 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 17:02:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from WEBBSD1.turnaround.com.au (webbsd1.turnaround.com.au [203.39.138.49]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA03158 for ; Sun, 3 Jan 1999 17:02:18 -0800 (PST) (envelope-from J_Shevland@TurnAround.com.au) Received: from tasshev (dhcp110.turnaround.com.au [192.168.1.110] (may be forged)) by WEBBSD1.turnaround.com.au (8.8.7/8.8.7) with SMTP id MAA02035; Mon, 4 Jan 1999 12:06:30 +1100 (EST) (envelope-from J_Shevland@TurnAround.com.au) Reply-To: From: "Joe Shevland" To: "Yani Brankov" , Subject: RE: Why is root's crontab different? Date: Mon, 4 Jan 1999 11:59:10 +1100 Message-ID: <000d01be377d$701f4610$6e01a8c0@tasshev.turnaround.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <36900954.DA0F0DC6@bulinfo.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG That's better :) Certainly == TRUE now. ---------------------|============================= Joe Shevland | TurnAround Solutions Principal Consultant | Hobart, Australia No unsolicited email | Voice (03) 6224 9146 | http://www.TurnAround.com.au ---------------------|============================= > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Yani Brankov > Sent: Monday, January 04, 1999 11:21 AM > To: J_Shevland@TurnAround.com.au; hackers@FreeBSD.ORG > Subject: Re: Why is root's crontab different? > > > > > > > -- > > > When the people talk about computers, > > > the word Microsoft is the most > > > frequently used one. > > > Guess why? :) > > > > > > > I don't get it... why? > > Excuse me everybody. > > I think it evaluates to TRUE now. I (bug)fixed it: > > -- > When the people talk about troubles, > the word Microsoft is the most > frequently used one. > > 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 Jan 3 17:08:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03753 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 17:08:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA03748 for ; Sun, 3 Jan 1999 17:08:14 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id KAA02652; Mon, 4 Jan 1999 10:07:40 +0900 (JST) Message-ID: <36901450.B761AC7D@newsguy.com> Date: Mon, 04 Jan 1999 10:07:28 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Eivind Eklund , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL & Perl References: <36900AE7.FB3AD249@newsguy.com> <19990104014545.E88411@follo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund wrote: > > I'm moving this to -hackers where it belong. -current is getting > TWICE THE FREAKING TRAFFIC of -hackers these days. Interesting times indeed. :-) > On Mon, Jan 04, 1999 at 09:27:19AM +0900, Daniel C. Sobral wrote: > > Is there any interest in getting rid of the perl script in the ficl > > build? It is a very legible script indeed, but not being able to set > > NOPERL is quite a nuisance for me. (As a bonus, my alternative > > doesn't have a small bug in Mr. Sadler's script :). > > Depends on the size and clarity of the replacement. Be aware that we > use perl5 in other parts of the build process, too - e.g, the device > config generation in the kernel build. Well, it is about as readable as a state machine can be. I didn't even took notice of the size, but it ought to be small, and it is only used during ficl's build, so it doesn't increase a single bit of an installed world (without sources :). I considered using yacc or lex for clarity's sake, but it just didn't quite fit. The perl script currently being used is just the right thing, except it requires perl. :-) Nothing against perl, but preferably not during my buildworld. As for the device config generation, since it gets used during the kernel build, it can get whatever perl is installed in the system. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 17:27:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05545 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 17:27:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA05540 for ; Sun, 3 Jan 1999 17:27:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA55023; Sun, 3 Jan 1999 17:26:48 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Jan 1999 17:26:48 -0800 (PST) From: Matthew Dillon Message-Id: <199901040126.RAA55023@apollo.backplane.com> To: "Stephen J. Roznowski" Cc: hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In tracking down the cause of my "/var/log/maillog.0: No such file :or directory" errors from newsyslog, I "discovered" that I had both :a root crontab entry and /etc/crontab. Both of these were running :newsyslog at the same time and they were conflicting with each :other. : :My question is why is root's crontab entry treated differently (i.e. :a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? : :Thanks, :-SR The original cron program had *only* /etc/crontab. The support for it is a backwards compatibility throwback that we really don't need any more. I don't use it on any of my boxes, even for root. It still hangs around the base install because it's no-fart. i.e. nobody wants to waste time farting around with the install to change it. I suppose /etc/crontab might have some limited usefullness running cron jobs for special users that do not have real shells installed for their password entry, but I have never in my life come across a situation like that. -Matt :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 17:38:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06377 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 17:38:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from epistolic.cynic.net (epistolic.cynic.net [199.175.137.136]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06366 for ; Sun, 3 Jan 1999 17:38:38 -0800 (PST) (envelope-from cjs@cynic.net) Received: from localhost (localhost [[UNIX: localhost]]) by epistolic.cynic.net (8.9.1a/8.9.1) with SMTP id RAA09683; Sun, 3 Jan 1999 17:37:44 -0800 (PST) Date: Sun, 3 Jan 1999 17:37:43 -0800 (PST) From: Curt Sampson To: Matthew Dillon cc: "Stephen J. Roznowski" , hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-Reply-To: <199901040126.RAA55023@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 3 Jan 1999, Matthew Dillon wrote: > The original cron program had *only* /etc/crontab. The support for it > is a backwards compatibility throwback that we really don't need any > more. Right. It's not used at all under NetBSD. > I suppose > /etc/crontab might have some limited usefullness running cron jobs for > special users that do not have real shells installed for their password > entry.... You should be able to do the same with per-user crontabs by setting SHELL=/bin/sh at the beginning of the crontab. cjs -- Curt Sampson 604 801 5335 De gustibus, aut bene aut nihil. The most widely ported operating system in the world: http://www.netbsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 19:00:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12935 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 19:00:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dt087nac.san.rr.com (dt087nac.san.rr.com [24.94.19.172]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12930 for ; Sun, 3 Jan 1999 19:00:14 -0800 (PST) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt087nac.san.rr.com (8.8.8/8.8.8) with ESMTP id SAA15213; Sun, 3 Jan 1999 18:59:53 -0800 (PST) (envelope-from Studded@gorean.org) Date: Sun, 3 Jan 1999 18:59:53 -0800 (PST) From: Studded X-Sender: doug@dt087nac.san.rr.com To: "Stephen J. Roznowski" cc: hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-Reply-To: <199901032233.RAA01244@istari.home.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 3 Jan 1999, Stephen J. Roznowski wrote: > My question is why is root's crontab entry treated differently (i.e. > a file in /etc) as opposed to just having a crontab (in /var/cron/tabs)? For future reference, this question belongs in freebsd-questions. Your question is based on an incorrect premise. The crontab in /etc is the *system* crontab. The root user has a crontab just like every other user. Personally I think this is a convenience, since I don't have to sort through a bunch of seperate crontab files for "system users" when I want to see why something has gone belly up. YMMV Good luck, Doug -- *** Chief Operations Officer, DALnet IRC network *** Like desperadoes waiting for a train . . . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 19:28:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA15284 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 19:28:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA15279 for ; Sun, 3 Jan 1999 19:28:45 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA26843; Sun, 3 Jan 1999 19:21:10 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdf26841; Mon Jan 4 03:21:08 1999 Date: Sun, 3 Jan 1999 19:21:05 -0800 (PST) From: Julian Elischer To: Mohit Aron cc: freebsd-hackers@FreeBSD.ORG Subject: Re: fine-grained timers In-Reply-To: <199901031742.LAA21838@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You should use the calls acquire_timer0() and release_timer0() which are found in /sys/i386/isa/clock.c They allow you to change the underlying hardware clock frequency to a multiple of "hz" (usually 100 Hz) nad still have the system act as if the hardware were running at 'hz'. On each real h/w clock interrupt your nominated function is called. the pcaudio driver (i386/isa/pcaudio.c) uses this tu run teh hardware clock at 16000Hz which is faster than you require. Unfortunatly only one higher speed can be used at a time (of course!). On Sun, 3 Jan 1999, Mohit Aron wrote: > Hi, > I'm using FreeBSD-2.2.6. I want to make FreeBSD generate timer > interrupts with a granularity as fine as 100usecs. Since the hardclock() > operates at a 10ms granularity, its not of much use. I also want to disable > dynamically the fine-grained interrupts, so I don't want to simply modify the > granularity at which hardclock gets called. Can someone > suggest the functions or places in the kernel which I should modify to > register my own interrupt handler. Thanks, > > > > - Mohit > > 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 Jan 3 20:15:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19733 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 20:15:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19728 for ; Sun, 3 Jan 1999 20:15:28 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id WAA06198 for ; Sun, 3 Jan 1999 22:44:12 -0500 (EST) Date: Sun, 3 Jan 1999 22:44:12 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 To: hackers Subject: Help on asynchronous system trap (AST) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Can anyone enlighten me on how AST is used in FreeBSD? I want to know how AST is used to schedule events and how this mechnism is integrated into the usual system interrupt and exception handler. Any help is appreciated. -------------------------------------------------- | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | | Dept. of Computer Science, SUNY at Binghamton | -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 3 23:38:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA08370 for freebsd-hackers-outgoing; Sun, 3 Jan 1999 23:38:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA08347 for ; Sun, 3 Jan 1999 23:38:28 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id IAA05098; Mon, 4 Jan 1999 08:43:32 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Mon, 4 Jan 1999 08:43:32 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: "Daniel C. Sobral" cc: Eivind Eklund , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL & Perl In-Reply-To: <36901450.B761AC7D@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 4 Jan 1999, Daniel C. Sobral wrote: > > On Mon, Jan 04, 1999 at 09:27:19AM +0900, Daniel C. Sobral wrote: > > > Is there any interest in getting rid of the perl script in the ficl > > > build? It is a very legible script indeed, but not being able to set > > > NOPERL is quite a nuisance for me. (As a bonus, my alternative > > > doesn't have a small bug in Mr. Sadler's script :). > > > > Depends on the size and clarity of the replacement. Be aware that we > > use perl5 in other parts of the build process, too - e.g, the device > > config generation in the kernel build. > > Well, it is about as readable as a state machine can be. I didn't Ok, after this introduction, it begins to look scary to me.. :-) _What_ it's actually like, a 1.5MB Forth program? ;-) Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 00:30:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14684 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 00:30:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kma.mk.ua (kma.aip.mk.ua [193.125.86.74] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14602 for ; Mon, 4 Jan 1999 00:29:54 -0800 (PST) (envelope-from pharao@kma.mk.ua) Received: from localhost (pharao@localhost) by kma.mk.ua (8.9.1a/8.9.1) with ESMTP id KAA19685 for ; Mon, 4 Jan 1999 10:33:09 -0200 Date: Mon, 4 Jan 1999 10:33:09 -0200 (GMT+2) From: Roman Minakov To: hackers@FreeBSD.ORG Subject: SVGATextMode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi! Please, tell me the way I can start subj under FreeBSD 2.2-STABLE? May be another software exist for that? PS I want set resolution to 100x30x9 on my S3 Virge DX/GX... bye ===================================================================== Roman Minakov aka digital pharao [Team Linux] [Team Windoze MD] e-mail: pharao@kma.mk.ua ICQ: 21723828 [Team C,PERL] JuniorAPH ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 00:49:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17027 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 00:49:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA17017 for ; Mon, 4 Jan 1999 00:49:45 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id RAA09791; Mon, 4 Jan 1999 17:49:07 +0900 (JST) Message-ID: <36907EEB.1CDA8F55@newsguy.com> Date: Mon, 04 Jan 1999 17:42:19 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Andrzej Bialecki , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL & Perl References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrzej Bialecki wrote: > > > Well, it is about as readable as a state machine can be. I didn't > > Ok, after this introduction, it begins to look scary to me.. :-) _What_ > it's actually like, a 1.5MB Forth program? ;-) :-) Hey, if it is replacing a perl script, it can only be a state machine. I could do it in lex, it would become much more readable, I suppose. It might have been done in awk or with sh+sed, but I'm not sure you could call it readable. :-) It is a 10 Kb C program (plus a 1 Kb shell script with two CAT < into "\n", but with a few additional functions to annoy everyone's life (in particular, converting //-style comments into C-style comments, and quote-escaping). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 01:03:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA18845 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 01:03:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sos.freebsd.dk (sos.freebsd.dk [212.242.42.180]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18840 for ; Mon, 4 Jan 1999 01:03:38 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.9.1/8.9.1) id KAA45185; Mon, 4 Jan 1999 10:02:27 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <199901040902.KAA45185@sos.freebsd.dk> Subject: Re: SVGATextMode In-Reply-To: from Roman Minakov at "Jan 4, 1999 10:33: 9 am" To: pharao@kma.mk.ua (Roman Minakov) Date: Mon, 4 Jan 1999 10:02:27 +0100 (CET) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Roman Minakov wrote: > hi! > > Please, tell me the way I can start subj under FreeBSD 2.2-STABLE? > May be another software exist for that? You need to run something >= 3.0 to have VESA support. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@freebsd.org) FreeBSD Core Team member To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 08:23:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01945 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 08:23:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01940 for ; Mon, 4 Jan 1999 08:23:44 -0800 (PST) (envelope-from rv@fore.com) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.1/8.9.1) with ESMTP id LAA19671; Mon, 4 Jan 1999 11:22:54 -0500 (EST) Received: from sol.eng.fore.com (sol [169.144.155.73]) by mailman.fore.com (8.8.8/8.8.8) with ESMTP id LAA20098; Mon, 4 Jan 1999 11:23:10 -0500 (EST) Received: from agastya.eng.fore.com (agastya [169.144.1.196]) by sol.eng.fore.com (8.8.8/8.8.8) with ESMTP id LAA22670; Mon, 4 Jan 1999 11:22:56 -0500 (EST) Received: from localhost (rv@localhost) by agastya.eng.fore.com (8.9.1b+Sun/8.9.1) with SMTP id LAA00395; Mon, 4 Jan 1999 11:22:55 -0500 (EST) Message-Id: <199901041622.LAA00395@agastya.eng.fore.com> X-Authentication-Warning: agastya.eng.fore.com: rv owned process doing -bs X-Authentication-Warning: agastya.eng.fore.com: rv@localhost didn't use HELO protocol To: Alexander Indenbaum cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Sun automount -> Amd (4.4BSD Automounter) map convertor In-reply-to: Message from Alexander Indenbaum of "Sun, 03 Jan 1999 16:56:29 +0200." Reply-to: rv@fore.com X-Mailer: MH v6.8.3 X-LoopDetect: rv@fore.com Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Jan 1999 11:22:55 -0500 From: Rajesh Vaidheeswarran Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -- using MH template repl.format -- In a previous message, Alexander Indenbaum writes: > Hi! > > I'm looking for script which will convert Sun automount map into > Amd (4.4BSD Automounter) map to be used in NIS Makefile. > > Does such tool exist? Yes. rv #!/usr/bin/env perl # # Convert Sun automount map format to amd format # # This program expects maps with the format # # dir [ -options ] machine:/path [ # optional comment ] # ... # # and generates an equivalent amd map as follows: # # # generated by sun2amd on Fri May 21 9:16:56 1993 # # /defaults \ # type:=nfs;opts:=rw,grpid,nosuid,utimeout=600 # # ## optional comment # ## options: -options # dir \ # hostd==machine.larc.nasa.gov;type:=link;fs:=/path || \ # domain==larc.nasa.gov;rhost:=machine;rfs:=/path || \ # rhost:=machine.larc.nasa.gov;rfs:=/path # ... # # You should set the DOMAIN and DEFAULT variables to your preferences. # # $Id: sun2amd,v 1.4 1993/05/24 21:10:05 mike Exp mike $ # require "ctime.pl"; # amd domain name (doesn't have to be the DNS domain; isn't overloading great!) # Should be what you will pass to amd via the -d command-line switch. $DOMAIN='fore.com'; # amd default settings; consult the docs for what you can/should do here. # Note, in particular, that if your disk mount points follow a common scheme # you can specify ``rfs:=/common/path/${key}'' and not have to insert that # line (twice) in every entry below! $DEFAULTS='type:=nfs;opts:=rw,grpid,nosuid,utimeout=600'; # print comment header and default string printf "# generated by sun2amd on %s\n", &ctime(time); printf "/defaults \\\n %s\n\n", $DEFAULTS; # loop through map $has_options = 0; while (<>) { if (m,^(\w\S*)(\s+\-\w\S*\s+|\s+)(\w[^:]*):(\/\S*)\s*(.*),) { ($dir, $options, $machine, $path, $rest) = ($1, $2, $3, $4, $5); print "#$rest\n" if ($rest =~ m/\w/); if ($options =~ m/-/) { $options =~ s/ //g; print "## options: $options\n"; $has_options++; } print "$dir \\\n"; printf " hostd==%s.%s;type:=link;fs:=%s || \\\n", $machine, $DOMAIN, $path; printf " domain==%s;rhost:=%s;rfs:=%s || \\\n", $DOMAIN, $machine, $path; printf " rhost:=%s.%s;rfs:=%s\n\n", $machine, $DOMAIN, $path; } } if ($has_options) { print STDERR <<"OPTION_NOTE"; NOTE: $has_options entries had custom options which you will need to correct by hand. Search for the string \"## options:\" in the new map to find them. OPTION_NOTE } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 13:17:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06148 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 13:17:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06141 for ; Mon, 4 Jan 1999 13:17:02 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id QAA04630 for ; Mon, 4 Jan 1999 16:16:34 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA19668; Mon, 4 Jan 1999 16:16:33 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id QAA28139 for freebsd-hackers@freebsd.org; Mon, 4 Jan 1999 16:16:33 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199901042116.QAA28139@bb01f39.unx.sas.com> Subject: cdrecord / projected & actual sizes don't seem right To: freebsd-hackers@FreeBSD.ORG Date: Mon, 4 Jan 1999 16:16:33 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm using cdrecord 1.6.1 on a -current system. I've run into a size/time issue that I don't seem to have any luck figuring out. I am using 73 minute cd-r media. When I run cdrecord to write the isofs to the cd media, everything seems to work correctly, but the process is stopping prematurely. Could someone with more experience shed some light on where I need to look to figure out what I'm doing wrong? The sense Blk invalid msg below is also interesting. Oh well, Thanks! John # cd /cdwork && cdrecord dev=5,0 speed=4 -v cd1.image Cdrecord release 1.6.1 Copyright (C) 1995-1998 Jvrg Schilling TOC Type: 1 = CD-ROM scsidev: '5,0' scsibus: 0 target: 5 lun: 0 atapi: 0 Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : Vendor_info : 'YAMAHA ' Identifikation : 'CRW4260 ' Revision : '1.0g' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Track 01: data 587 MB Total size: 674 MB (66:48.10) = 300608 sectors Lout start: 674 MB (66:50/08) = 300608 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable ATIP start of lead in: -11080 (97:34/20) ATIP start of lead out: 335100 (74:30/00) Disk type: Cyanine, AZO or similar Manufacturer: Mitsubishi Chemical Corporation Blocks total: 335100 Blocks current: 335100 Blocks remaining: 34492 RBlocks total: 342460 RBlocks current: 342460 RBlocks remaining: 41852 Starting to write CD/DVD at speed 4 in write mode for single session. Last chance to quit, starting real write in 1 seconds. Waiting for reader process to fill input-buffer ... input-buffer ready. Starting new track at sector: 0 cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 04 2D 74 00 00 1E 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 D3 C0 00 00 0A 00 00 00 00 09 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 01 06 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x09 Qual 0x00 (track following error) Fru 0x0 Sense flags: Blk -742391808 (not valid) resid: 20480 cmd finished after 0.078s timeout 40s write track data: error after 560701440 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 Writing time: 925.598s Fixating... cdrecord: Input/output error. close track/session: scsi sendcmd: retryable error CDB: 5B 00 02 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 D1 C0 00 00 0A 00 00 00 00 09 01 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 01 06 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x09 Qual 0x01 (tracking servo failure) Fru 0x0 Sense flags: Blk -775946240 (not valid) cmd finished after 41.576s timeout 480s Fixating time: 43.587s cdrecord: fifo had 9194 puts and 9127 gets. cdrecord: fifo was 0 times empty and 9126 times full, min fill was 98%. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 14:38:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15747 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 14:38:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15719 for ; Mon, 4 Jan 1999 14:37:59 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id RAA48496; Mon, 4 Jan 1999 17:41:40 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Mon, 4 Jan 1999 17:41:40 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: "John W. DeBoskey" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: cdrecord / projected & actual sizes don't seem right In-Reply-To: <199901042116.QAA28139@bb01f39.unx.sas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 4 Jan 1999, John W. DeBoskey wrote: > Hi, > > I'm using cdrecord 1.6.1 on a -current system. I've run into > a size/time issue that I don't seem to have any luck figuring out. > > I am using 73 minute cd-r media. When I run cdrecord to write > the isofs to the cd media, everything seems to work correctly, but > the process is stopping prematurely. Could someone with more > experience shed some light on where I need to look to figure out > what I'm doing wrong? The sense Blk invalid msg below is also > interesting. i just purchased my own CD-RW, ( i think it's the same model as yours ) try running cdrecord with nice -18: (from the man page) cd /cdwork nice -18 cdrecord dev=5,0 speed=4 -v cd1.image try not to jostle (sp?) the machine while recording, what i mean is don't start up something likely to cause pageing, it'll probably ruin the burn. you may even want to run it with 'rtprio' but i haven't tried that myself yet. i just got it last night and had a bit of trouble using RW media, but i haven't tried it with 'nice -18' yet, i'll see what helps me in that situation and post about it. -Alfred > > Oh well, > Thanks! > John > > # cd /cdwork && cdrecord dev=5,0 speed=4 -v cd1.image > Cdrecord release 1.6.1 Copyright (C) 1995-1998 Jvrg Schilling > TOC Type: 1 = CD-ROM > scsidev: '5,0' > scsibus: 0 target: 5 lun: 0 > atapi: 0 > Device type : Removable CD-ROM > Version : 2 > Response Format: 2 > Capabilities : > Vendor_info : 'YAMAHA ' > Identifikation : 'CRW4260 ' > Revision : '1.0g' > Device seems to be: Generic mmc CD-RW. > Using generic SCSI-3/mmc CD-R driver (mmc_cdr). > Driver flags : SWABAUDIO > Track 01: data 587 MB > Total size: 674 MB (66:48.10) = 300608 sectors > Lout start: 674 MB (66:50/08) = 300608 sectors > Current Secsize: 2048 > ATIP info from disk: > Indicated writing power: 5 > Is not unrestricted > Is not erasable > ATIP start of lead in: -11080 (97:34/20) > ATIP start of lead out: 335100 (74:30/00) > Disk type: Cyanine, AZO or similar > Manufacturer: Mitsubishi Chemical Corporation > Blocks total: 335100 Blocks current: 335100 Blocks remaining: 34492 > RBlocks total: 342460 RBlocks current: 342460 RBlocks remaining: 41852 > Starting to write CD/DVD at speed 4 in write mode for single session. > Last chance to quit, starting real write in 1 seconds. > Waiting for reader process to fill input-buffer ... input-buffer ready. > Starting new track at sector: 0 > cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error > CDB: 2A 00 00 04 2D 74 00 00 1E 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 04 D3 C0 00 00 0A 00 00 00 00 09 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 01 06 > Sense Key: 0x4 Hardware Error, Segment 0 > Sense Code: 0x09 Qual 0x00 (track following error) Fru 0x0 > Sense flags: Blk -742391808 (not valid) > resid: 20480 > cmd finished after 0.078s timeout 40s > > write track data: error after 560701440 bytes > Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 > Writing time: 925.598s > Fixating... > cdrecord: Input/output error. close track/session: scsi sendcmd: retryable error > CDB: 5B 00 02 00 00 00 00 00 00 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 04 D1 C0 00 00 0A 00 00 00 00 09 01 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 01 06 > Sense Key: 0x4 Hardware Error, Segment 0 > Sense Code: 0x09 Qual 0x01 (tracking servo failure) Fru 0x0 > Sense flags: Blk -775946240 (not valid) > cmd finished after 41.576s timeout 480s > Fixating time: 43.587s > cdrecord: fifo had 9194 puts and 9127 gets. > cdrecord: fifo was 0 times empty and 9126 times full, min fill was 98%. > > > 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 Jan 4 15:11:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20221 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 15:11:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20216 for ; Mon, 4 Jan 1999 15:11:26 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id PAA24603; Mon, 4 Jan 1999 15:10:36 -0800 (PST) Date: Mon, 4 Jan 1999 15:10:36 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199901042310.PAA24603@math.berkeley.edu> To: grog@lemis.com Subject: Re: Finding unused functions Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's occurred to me that after rewriting some code, I have some unused > functions in a program. Are there any good automatic ways to find out > what they are, something like the warnings you get from cc about > unused variables? lint dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 15:57:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25718 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 15:57:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25712 for ; Mon, 4 Jan 1999 15:57:00 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id QAA22443 for ; Mon, 4 Jan 1999 16:56:34 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901042356.QAA22443@pluto.plutotech.com> To: hackers@FreeBSD.ORG Subject: IBM Thinkpad 770 Date: Mon, 04 Jan 1999 16:48:30 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm considering purchasing one of these guys and I'm hoping that someone out there can confirm getting FreeBSD up and running on it. It looks like XFree86 supports the Trident video chipset it uses and I would expect everything else to just fall out. Does anyone know if the acd driver will grok an ATAPI DVD-ROM drive if you use CD media? Thanks, Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 15:57:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25737 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 15:57:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25729 for ; Mon, 4 Jan 1999 15:57:04 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA06987; Mon, 4 Jan 1999 16:56:38 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd006944; Mon Jan 4 16:56:36 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA23877; Mon, 4 Jan 1999 16:56:35 -0700 (MST) From: Terry Lambert Message-Id: <199901042356.QAA23877@usr05.primenet.com> Subject: Re: tcp bug on reeBSD To: fenner@parc.xerox.com (Bill Fenner) Date: Mon, 4 Jan 1999 23:56:35 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <98Dec18.145610pst.177534@crevenia.parc.xerox.com> from "Bill Fenner" at Dec 18, 98 02:56:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you get unlucky with delayed ACK's or your client is extremely > slow, you might get > server: FIN > client: ACK > client: FIN > server: ACK Well, Winsock clients are extremely slow. They aren't very speedy, either. ;-). > but from TCP's point of view, the client's FIN isn't related to the > server's FIN; it's in response to the client application's request to > close the connection. No, you've got that backwards. The FIN-WAIT-2 stuff only happens in the case of an encapsulated protocol teardown, like the implied close by the server at the end of an HTTP transfer, or the POP3 or SMTP case, where a QUIT is sent by the client, initiating a server shutdown of the connection. When the server shuts down the connection, it expects the client to do the ACK/CTL,ACK. In the failure case, the client doesn't call shutdown(2), and since the TCP/IP implementation is user space, and sockets in Windows 95/98 are not file descriptors, there's not OS-based resource tracking (like there is in UNIX) to imply a shutdown(2) on behalf of the client application closing the descriptor (or worse, just exiting without a close at all, leaving not even the close/shutdown order inversion available for resource tracking to be implied). Yeah, they should put something in the WSOCK32.DLL thread_detach or process_detach routine to handle automatic shutdown, but Microsoft hasn't bothered to do this yet. > >This behaviour should be implemented in FreeBSD as a sysctl; you > >could call it "nt_bug_compatabile", but it's probably more correct > >to call it "patch_fin_wait_2_bug". > > You're suggesting that the timeout, instead of removing the state, > pretend that the FIN wasn't acknowledged and switch to FIN_WAIT_1 and > retransmit the "unacknowledged" FIN? Yes. Pretend you didn't get the "ACK" from the "FIN", and resend it. This will elicit either no response from the client (powered off, etc.), an RST (improper shutdown, go ahead and tear down the server end), or a "drain in progress" (e.g., an "ACK" for the "FIN" for which the "ACK" was "lost" by the server). This is basically what NT does, and it's what Paul Vixie added to his version of NetBSD (from my interpretation of his description). > >With this enabled, you can get rid of the long timeout kludge, as > >well. > > Well, you just do something different when the timeout occurs, n'est-ce > pas? No. Unless "the timeout" is reduced from 30 minutes to 2 MSL, so you're calling it the same timeout. Technically, this is a bug in the TCP protocol as defined by RFC 793, since you can't expect a client machine to not crash between the "ACK" and the "CTL,ACK", and if it does, there's no recovery possible on the server side of things. Also, a 30 minute timeout is bad. It's perfectly valid for a client to take days between the encapsulated server shutdown and the client calling shutdown(2). The downside is a lot of server to client activity. You can solve that by starting at 2 msl, and so long as you are getting "ACK"'s from the client for your repeat "FIN" for your "lost" "ACK", you can do an exponential back-off (NT does *not* do this -- they basically "FIN"-flood the client every 2 MSL until it "ACK"'s or "RST"'s). An exponential back-off is probably overkill for an initial try at the fix, unless people see link degradation as a result of the fix going in (unlikely, unless clients are doing rather evil things; you could concieve a DOS atack using an intentionally misbehaving client machine, which a 30 minute timeout *and* an exponential backoff would do a lot to resolve. You might want to change the close code, as well, letting the close context for data that may need to be retransmitted to linger, but causing it to return to the server immediately anyway so as to allow you to unload the server image and recover all but the lingering close context -- in the kernel -- for reuse). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 16:47:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02536 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 16:47:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02530 for ; Mon, 4 Jan 1999 16:47:51 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id RAA23841; Mon, 4 Jan 1999 17:47:15 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901050047.RAA23841@pluto.plutotech.com> To: David Dawes cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: IBM Thinkpad 770 In-reply-to: Your message of "Tue, 05 Jan 1999 11:29:33 +1100." <19990105112933.A10547@rf900.physics.usyd.edu.au> Date: Mon, 04 Jan 1999 17:39:10 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Mon, Jan 04, 1999 at 04:48:30PM -0700, Justin T. Gibbs wrote: >>I'm considering purchasing one of these guys and I'm hoping that someone >>out there can confirm getting FreeBSD up and running on it. It looks like >>XFree86 supports the Trident video chipset it uses and I would expect > >I'm not sure that it does. Which chip is it? There is preliminary >(untested) support for a new Trident laptop chipset about to go into >our development version, and I've seen at least one report that the >Thinkpad 770X uses that one. > >David The specs I have say it uses the Trident Cyber9397DVD chipset. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 16:48:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02704 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 16:48:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02695 for ; Mon, 4 Jan 1999 16:48:46 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA26136; Mon, 4 Jan 1999 17:48:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd026081; Mon Jan 4 17:48:00 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA25760; Mon, 4 Jan 1999 17:47:56 -0700 (MST) From: Terry Lambert Message-Id: <199901050047.RAA25760@usr05.primenet.com> Subject: Re: Joliet file system? To: casper@acc.am (Casper) Date: Tue, 5 Jan 1999 00:47:55 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <367CA2FC.3F42F288@acc.am> from "Casper" at Dec 20, 98 11:10:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can anyone give me some documents/description/standard of this file system ? I > have the same proble and wonna try to hack a cd9660 module ...... I already > analized dump of this FS , but there are a lot problems ..... > > I'll we thankful if you send any docs/URLs :) If you have access to the MSDN II Windows 95 SDK/DDK, it's in the DOCS/JOLIET.DOC file (in Word format, of course). I've discussed Joliet in rather more detail in other postings (to -current). Basically, you go to the last session on the disk to identify a Joliet CDROM, and the name stuff is all in Unicode. I guess I can break out my Windows 95 developement disk and boot a machine with an NCR controller with it if you need more info. The biggest thing you will need to do doesn't need the documentation: support session switching on a cdrom device using an ioctl() that can be called from kernel space within the FS against the device to allow the FS code to do session-groping. I've got some 3 year old code somewhere to do some of this, but it would mean a lot of tape grovelling for me to find it... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 17:09:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05972 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 17:09:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA05953 for ; Mon, 4 Jan 1999 17:09:47 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.9.1a/8.9.1) id LAA10574; Tue, 5 Jan 1999 11:29:33 +1100 (EST) Message-ID: <19990105112933.A10547@rf900.physics.usyd.edu.au> Date: Tue, 5 Jan 1999 11:29:33 +1100 From: David Dawes To: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: IBM Thinkpad 770 References: <199901042356.QAA22443@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901042356.QAA22443@pluto.plutotech.com>; from Justin T. Gibbs on Mon, Jan 04, 1999 at 04:48:30PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 04, 1999 at 04:48:30PM -0700, Justin T. Gibbs wrote: >I'm considering purchasing one of these guys and I'm hoping that someone >out there can confirm getting FreeBSD up and running on it. It looks like >XFree86 supports the Trident video chipset it uses and I would expect I'm not sure that it does. Which chip is it? There is preliminary (untested) support for a new Trident laptop chipset about to go into our development version, and I've seen at least one report that the Thinkpad 770X uses that one. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 17:11:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06297 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 17:11:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06287 for ; Mon, 4 Jan 1999 17:11:23 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.9.1a/8.9.1) id MAA10794; Tue, 5 Jan 1999 12:10:46 +1100 (EST) Message-ID: <19990105121046.F10410@rf900.physics.usyd.edu.au> Date: Tue, 5 Jan 1999 12:10:46 +1100 From: David Dawes To: "Justin T. Gibbs" Cc: hackers@FreeBSD.ORG Subject: Re: IBM Thinkpad 770 References: <19990105112933.A10547@rf900.physics.usyd.edu.au> <199901050047.RAA23841@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901050047.RAA23841@pluto.plutotech.com>; from Justin T. Gibbs on Mon, Jan 04, 1999 at 05:39:10PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 04, 1999 at 05:39:10PM -0700, Justin T. Gibbs wrote: >>On Mon, Jan 04, 1999 at 04:48:30PM -0700, Justin T. Gibbs wrote: >>>I'm considering purchasing one of these guys and I'm hoping that someone >>>out there can confirm getting FreeBSD up and running on it. It looks like >>>XFree86 supports the Trident video chipset it uses and I would expect >> >>I'm not sure that it does. Which chip is it? There is preliminary >>(untested) support for a new Trident laptop chipset about to go into >>our development version, and I've seen at least one report that the >>Thinkpad 770X uses that one. >> >>David > >The specs I have say it uses the Trident Cyber9397DVD chipset. A report I saw today indicates that the chip has a different PCI ID from the earlier (non-DVD?) Cyber9397. It may be otherwise compatible, but I haven't seen that confirmed. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 17:27:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08015 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 17:27:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08008 for ; Mon, 4 Jan 1999 17:27:54 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id SAA09000; Mon, 4 Jan 1999 18:27:20 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA01707; Mon, 4 Jan 1999 18:27:20 -0700 Date: Mon, 4 Jan 1999 18:27:20 -0700 Message-Id: <199901050127.SAA01707@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Dawes Cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: IBM Thinkpad 770 In-Reply-To: <19990105121046.F10410@rf900.physics.usyd.edu.au> References: <19990105112933.A10547@rf900.physics.usyd.edu.au> <199901050047.RAA23841@pluto.plutotech.com> <19990105121046.F10410@rf900.physics.usyd.edu.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>>I'm considering purchasing one of these guys and I'm hoping that someone > >>>out there can confirm getting FreeBSD up and running on it. It looks like > >>>XFree86 supports the Trident video chipset it uses and I would expect > >> > >>I'm not sure that it does. Which chip is it? There is preliminary > >>(untested) support for a new Trident laptop chipset about to go into > >>our development version, and I've seen at least one report that the > >>Thinkpad 770X uses that one. > >> > >>David > > > >The specs I have say it uses the Trident Cyber9397DVD chipset. > > A report I saw today indicates that the chip has a different PCI ID > from the earlier (non-DVD?) Cyber9397. It may be otherwise compatible, > but I haven't seen that confirmed. For what it's worth: .... Xi Graphics is pleased to announce fully accelerated support for the IBM Thinkpad 770X, which uses a Trident Cyber 9397 DVD chipset. This update provides fully accelerated support at 8, 16, and 24 bits per pixel. ... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 17:54:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10627 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 17:54:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from out5.ibm.net (out5.ibm.net [165.87.194.243]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10620 for ; Mon, 4 Jan 1999 17:54:34 -0800 (PST) (envelope-from mikegoe@ibm.net) Received: from Nikki (slip129-37-208-106.oh.us.ibm.net [129.37.208.106]) by out5.ibm.net (8.8.5/8.6.9) with SMTP id BAA66406 for ; Tue, 5 Jan 1999 01:54:05 GMT Message-Id: <199901050154.BAA66406@out5.ibm.net> From: "Michael G." To: "hackers@FreeBSD.ORG" Date: Mon, 04 Jan 1999 20:28:47 -0500 Reply-To: "Michael G." X-Mailer: PMMail 98 Professional (2.01.1600) For Windows 98 (4.10.1998) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: IBM Thinkpad 770 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not sure if this will help, but a few years ago I ran 2.2.x on a Thinkpad 750. I had a hard time getting X to run, but I finally did. By now I'm sure the drivers have come along. Michael G. On Mon, 04 Jan 1999 16:48:30 -0700, Justin T. Gibbs wrote: >I'm considering purchasing one of these guys and I'm hoping that someone >out there can confirm getting FreeBSD up and running on it. It looks like >XFree86 supports the Trident video chipset it uses and I would expect >everything else to just fall out. Does anyone know if the acd driver >will grok an ATAPI DVD-ROM drive if you use CD media? ------------------------------------------------------------------- ICQ #24517082 Live FreeBSD...Or Die! PIC X 10 VALUE "YES! COBOL" ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 19:16:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18311 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 19:16:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18305 for ; Mon, 4 Jan 1999 19:16:11 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA14900; Mon, 4 Jan 1999 20:15:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd014856; Mon Jan 4 20:15:39 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA02641; Mon, 4 Jan 1999 20:15:38 -0700 (MST) From: Terry Lambert Message-Id: <199901050315.UAA02641@usr05.primenet.com> Subject: Re: question about re-entrancy. To: bright@hotjobs.com (Alfred Perlstein) Date: Tue, 5 Jan 1999 03:15:38 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Alfred Perlstein" at Dec 20, 98 04:36:51 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm a bit confused. I've been watching the discussions going on about > SMP. The issue of kernel re-entrancy has been brought up many times. > > So here's the question: > > I thought the kernel was re-entrant, when a process makes a syscall it's > thread of execution enters the kernel where its arguments are validated > and careful checks are done to ensure security then the syscall is done. > > If during the system call the process is put to sleep or rescheduled, > another process may enter the kernel. As long as the splxxx() calls do > not interfere with each other you have 2 processes excuting in the kernel > at that point. (more can enter as well) > > Or.... what i'm now thinking is that once a process enters the kernel it > must run until it exits the system call. I have a problem with this > though, processes such as nfsiod/nfsd enter the kernel through a syscall > and never exit (according to design and implementation) how then are other > processes allowed into the kernel? > > Can anyone explain this a bit better? The kernel is process reentrant, but not processor reentrant. It helps if you think of CPU cycles as a consumable resource, instead of thinking of processes as work to do. There are three ways to enter the kernel: 1) System call 2) Interrupt 3) Fault Only one CPU can be in the kernel at a time. If a second CPU attempts to enter the kernel while another CPU is already in the kernel, it spins on The Big Giant Lock (tm) ("We didn't make The Big Giant Lock, we only made it Big and Giant"). In general, there are two cases to consider: 1) A CPU is already in the kernel 2) No CPU is in the kernel (all CPU's are in user space) In the first case, a fault or interrupt is given to the CPU already in the kernel (the interrupts run in virtual wire mode on the APIC's, making interrupt processing truly symmetric, unlike other OS's...); in the second, it's given to whatever CPU it's given to. In general, it's possible to modify the interrupt processing to allow both processors in at the same time. To do this, you have to make sure that the subset of the kernel runnable at interrupt time is reentrant. While not entirely trivial, this is a pretty easy task, except for entries via the system call interrupt (a call gate is much better than an interrupt for system calls from an SMP perspective in this case, since there's still the need to grab The Big Giant Lock until you discriminate the interrupt source). This hasn't been done. The tangent into spl is a red herring. The spl mechanism is basically a method of blocking operations that will "take too long" from interrupting the current operation. In other words, interrupts and faults, since that's the only thing that can take the processor away from its assigned task once in the kernel. The reason that multiple processors can't be in the kernel at the same time is a bit more complicated. Consider a hard RT (RealTime) system. In order to meet hard RT requirements, you have to be able to do kernel preemption. Basically, the idea of kernel preemption is exactly the same problem that you face trying to run two processors in the kernel at the same time, or trying to run kernel threads. Especially when you are trying to implement soloutions for RT priority inversion or trying to IPC between kernel threads. The issue raised is how you protect kernel structures that may be accessed by two processors at the same time... you have to lock against the other processor. Basically, the only preemption mechanism is faults (which can only occur from user space, except for the Pentium lockup bug workaround) and interrupts (which occur as a result of external events, like another machine sending a packet to your ethernet interface). There are a number of serious architectural issues you have to address to be able to get multiple processes in the kernel at the same time. Fortunately, there are ways to cheat: 1) Address the interrupt handler reentrancy by doing the minimal amount of work at interrupt time, and queueing the interrupt and context for the work you did for later processing (by a highest-priority kernel thread). Don't ACK (reenable) the interrupt to the controller (or APIC) until you have done the minimal processing and requeue. For shared (PCI/EISA/MCA/SBUS/Other) interrupts, process all of the devices minimal code for each device that's asserting the interrupt before you ACK it. This is the best granularity, since most of this is device bus work, and you aren't going to be able to multiply access the device bus simultaneously (you will need a Device Bus Lock for INB/OUTB/INW/OUTW). 2) Divorce the kernel stack from the proc struct. This allows you to reenter using an "entrancy instance" -- allocating a kernel stack from a pool of kernel stacks not explicitly tied to a process. This also allows you to preempt a processor running in the kernel to have it go do something else (you will need an Inactive Stack List lock and an Active Stack List Lock to allow you to grab an existing stack, or, if you are all out, allocate a new stack and add it to the stack list). Combine this with an async call gate (basically a VMS style "event flag" or "AST" mechanism), and you don't need kernel threads to spread process load over multiple processors. 3) Create per-CPU resource pools. This process is described in excruciating detail in the Dynix VM Allocator Paper (Dynix, if you will remember, sclaed to 32 CPU's without serious degradation). You allocate (and free) resources from the per CPU pool based on low (and high) watermarks, instead of contending in a global pool (you will need a Global Resource Lock for high and low watermark transfers to and from the global pool, and you will need to implement an IPI [Inter Processor Interrupt] mechanism for low resource conditions to override the watermarks during low resource conditions. Typically, there will be little or no inter-CPU contention under normal operation). This still leaves the need to have Big Giant Subsystem Locks (tm) to push down locks through the system call (trap) mechanism to each subsystem, until you eliminate context using object locks (I don't like object locks), or, preferrably, critical section locks. Object locks are a necessary evil on lists of objects that must be maintained, but lists of objects are themselves an evil, and contention in these lists can be drastically reduces by implementing a hierarchical intention mode lock manager, and breaking the lists into sections and pushing the actual objects to be locked down the hierarchy so that it's unlikely to cause contention between execution contexts (statistically, the more subnodes, the less likely you are to run into contention between any two objects, taken at random). Mostly, object lists should be done away with. Cases where this isn't possible (like the system open file table, the process list, the directory name lookup cache, etc.) gain obvious concurrency benefit from intention mode ("SIX") style locks. For objects themselves, it's easy to either make them an extension of one more level in the hierarchy (for example, directory vnodes intended to be written). You maintain an active transitive closure calculation on the lock vectors from the root as locks are added; this allows you to do deadlock detection by traversing the two nodes in the lock relationship to the root of the lock graph; otherwise, deadlock detection would be tantamount to soving the travelling salesman problem). In general, write locks are necessary, but read locks only need to be held in cases where there are coherency issues. For example, a read lock across a directory entry block while it's being copied to a user buffer (for a "snapshot" of director block contents, as is provided by the getdents(2) system call). The final issue is avoidance of cache-busting behaviour. This pretty much boils down to marking lock pages as non-cacheable, and then assuring CPU affinity for processes (or threads -- in effect, whetever you're calling your kernel execution contexts) to make sure that the L1 cache has value and that the MESI (All Intel SMP is based on MESI architecture) stays away from the "I" (Invalidate) portion of the acronym. It's a lot of work, but it's not rocket science. The most complicated piece is the lock manager; to do it right, you need a five dimensional vector relationship (an arc describing the intersection of three two dimensional vectors: the lock list held by a locking entity, the hierarchical list of lockable objects, and the relationship between multiple locking entities within a single process -- threads within a process). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 19:39:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20207 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 19:39:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20201 for ; Mon, 4 Jan 1999 19:39:25 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id UAA06330; Mon, 4 Jan 1999 20:38:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd006292; Mon Jan 4 20:38:48 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA03450; Mon, 4 Jan 1999 20:38:47 -0700 (MST) From: Terry Lambert Message-Id: <199901050338.UAA03450@usr05.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dyson@iquest.net Date: Tue, 5 Jan 1999 03:38:47 +0000 (GMT) Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199812232324.SAA26271@y.dyson.net> from "John S. Dyson" at Dec 23, 98 06:24:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Almost any negative allegations as to portability regarding the FreeBSD > VM are incorrect and mostly spin. There are features in the FreeBSD VM that > take advantage of CPU capabilities that are inherently non-portable. However, > those features are optional, and not necessary for correct operation. I > suspect that as the Alpha platform is optimized, the VM code will be tuned > to support that super-well also. I have to say that John is right; I ported the FreeBSD VM system to the PPC 603 at one point in time (he's also right about the other faults interrupting, since part of the page stuff has to be done in software there -- same issue with MIPS). The biggest problem I had was the thing was moving too fast for me to be able to track it adequately. That was probably just me (or maybe a lack of documentation describing the thing... ;-)). > Geesh, there is already support in FreeBSD for non-copy read/write to/from > the buffer cache also. It isn't complete, but is there. It only takes > someone to finish the job (which I was in the middle of.) On some machines, > that feature would definitely be a mis-feature, but on the X86, it would > be useful. Yeah, this needs to be finished... > Also, the FreeBSD VFS/VM code already supports the ability to > have non-mapped buffers (and has for 2years.) There is alot in there that > might make the complexity look excessive, but that is only because there > are features in there that are almost ready to go. Actually, I think some of the tighness of VM system integration into the VFS code is a mistake. Specifically, I think that the VM references should be macro-ized so that the underlying VM system has much less impact on the code. I'd like to see VFS modules portable between the BSD's (the main obstacle at this point is that the VM intrusions aren't generalized to ignore the underlying implementation (in the FreeBSD case, the intrusion points for cache coherency have been diked out); after that's fixed, the obstacle becomes the "cookie" crap in VOP_READDIR (it has argument order of operation issues, which is why the NetBSD AFS code won't work in FreeBSD), which should be murdered by splitting the VOP_READDIR into VOP_GETDIRBLK/VOP_GETBLKENTRY to get rid of the need for a cookie for resuming context in a directory block for NFS and too-small-user-buffer based traversals -- at the same time paving the way for kernel based globbing for about a 5 times speed increase for a SAMBA/AFS specific system call KLD module). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 19:50:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21684 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 19:50:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21677 for ; Mon, 4 Jan 1999 19:50:31 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id UAA10185; Mon, 4 Jan 1999 20:49:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd010084; Mon Jan 4 20:49:51 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA03933; Mon, 4 Jan 1999 20:49:36 -0700 (MST) From: Terry Lambert Message-Id: <199901050349.UAA03933@usr05.primenet.com> Subject: Re: Information needed on SMI To: mike@smith.net.au (Mike Smith) Date: Tue, 5 Jan 1999 03:49:36 +0000 (GMT) Cc: imp@village.org, hackers@FreeBSD.ORG In-Reply-To: <199812211740.JAA02386@dingo.cdrom.com> from "Mike Smith" at Dec 21, 98 09:40:24 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Greetings, > > I'm looking for information on the SMI bios stuff. I don't > > mean Intel's SMBios, but the SMI in "Power management: APM, SMI" that > > comes up when I boot my machine. My web searches have turned up the > > Intel spec a lot, but nothing on SMI itself (except that this or that > > computer support it). > > SMI is "system management interrupt", it causes the processor to enter > SMM ("system management mode"). You'll find documentation on it in the > Intel processor manuals, IIRC from the '486 onwards. More specifically, given the context of the question, I'm going to assume you have a Cyrix processor, like the Media/GX. Most Cyrus processors assume the SMI handler is in the BIOS (which has specific knowledge of the hardware). This means that the BIOS gets called as a result of an SMI in response to an APM event. Depending on which computer you have, the BIOS may make assumptions about how the hardware has been configured, or may expect to be called in VM86() mode by an OS that intercepts the SMI interrupt in protected mode and forwards it to the original BIOS vector. Julian has *some* information on interfacing to the SMI, but I'm not sure how much he can share. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 19:52:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22068 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 19:52:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22062 for ; Mon, 4 Jan 1999 19:52:29 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA29397; Mon, 4 Jan 1999 20:51:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd029310; Mon Jan 4 20:51:50 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA04038; Mon, 4 Jan 1999 20:51:39 -0700 (MST) From: Terry Lambert Message-Id: <199901050351.UAA04038@usr05.primenet.com> Subject: Re: Apache with dynamic modules files miserably. To: ugen@undp.org (Ugen Antsilevitch) Date: Tue, 5 Jan 1999 03:51:39 +0000 (GMT) Cc: jdp@polstra.com, hackers@FreeBSD.ORG In-Reply-To: <367EA6C2.917286BD@undp.org> from "Ugen Antsilevitch" at Dec 21, 98 02:51:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well...sorry for omitting that - it is 3.0 - RELEASE. > I just downloaded rtld.c from 3.0-CURRENT - that one seems to be dated Nov.27 . > I recompiled ld-elf.so.1 and installed it but Apache still fails. > Here is the error i get: > Cannot load /usr/local/apache/libexec/mod_env.so into server: > /usr/local/apache/lib > exec/mod_env.so: Undefined symbol "ap_palloc". > This can change depending on which module gets loaded first but function it > complains about is > one in the main source. > Any other advice will be appretiated...:) Make sure you are using an ELF mod_env.so. The lack of a leading underscore on the error message means it's looking for an ELF symbol. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:00:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22889 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:00:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22878 for ; Mon, 4 Jan 1999 20:00:27 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA05269; Mon, 4 Jan 1999 20:59:55 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd005245; Mon Jan 4 20:59:49 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA04503; Mon, 4 Jan 1999 20:59:49 -0700 (MST) From: Terry Lambert Message-Id: <199901050359.UAA04503@usr05.primenet.com> Subject: Re: inetd in realloc(): warning: junk pointer, too low to make To: lem@cantv.net (Luis =?iso-8859-1?Q?Mu=F1oz?=) Date: Tue, 5 Jan 1999 03:59:48 +0000 (GMT) Cc: spork@super-g.com, kaleb@ics.com, hackers@FreeBSD.ORG In-Reply-To: <3.0.6.32.19981221171019.008451f0@pop.cantv.net> from "Luis =?iso-8859-1?Q?Mu=F1oz?=" at Dec 21, 98 05:10:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Well, here's what sendmail does here, it's pretty scary, with those > >truncated messages about spwd.db: > > > >Dec 17 15:42:27 super-g Dec 17 15:42:27sendmail[: NOQUEUE > >Dec 17 15:51:11 super-g Dec 17 15:51:11sendmail[: /etc/spwd.db > >Dec 17 15:51:11 super-g sendmail[16594]: NOQUEUE: SYSERR(root): Out of > >memory!!: Cannot allocate memory > >Dec 17 16:30:01 super-g Dec 17 16:30:00sendmail[: /etc/spwd.db > >Dec 17 16:30:16 super-g /kernel: pid 20618 (sendmail), uid 0: exited on > >signal 11 > >Dec 17 16:30:57 super-g Dec 17 16:30:57sendmail[: /etc/spwd.db > >Dec 17 16:30:57 super-g Dec 17 16:30:57sendmail[: NOQUEUE > >Dec 17 16:30:57 super-g Dec 17 16:30:57sendmail[: /etc/spwd.db > > > >Charles > > Agreed. Are your files consistent/sane? I've never seen this > before! This is related to running out of memory. The problem occurs because clean mmap'ed pages are reaped for reuse in a swap low condition, but the "page present" bit is not correctly unset in the places where it is referenced. Effectively, this corrupts one page of the libc (which is mmap'ed) that the sendmail is linked against, and basically damages its ability to fork children. You can work around the problem by statically link sendmail and/or not running out of memory (e.g. run a newer version of Netscape, use a DISPLAY variable that disables Netscape using the MIT SHM extension, run Netscape from a remote machine using the local machine as a display, which will also prevent it from using the MIT SHM extension, or just disable the MIT SHM extension entirely). You can also workaround the problem by not allowing the reaping of pages in a mapping that references a vnode with a greater than one reference count (not an ideal workaround, admittedly, but it works). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:02:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA23235 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:02:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA23227 for ; Mon, 4 Jan 1999 20:02:14 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id VAA03426; Mon, 4 Jan 1999 21:01:48 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd003326; Mon Jan 4 21:01:36 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA04572; Mon, 4 Jan 1999 21:01:29 -0700 (MST) From: Terry Lambert Message-Id: <199901050401.VAA04572@usr05.primenet.com> Subject: Re: inetd in realloc(): warning: junk pointer, too low to make sense. To: eivind@yes.no (Eivind Eklund) Date: Tue, 5 Jan 1999 04:01:29 +0000 (GMT) Cc: kaleb@ics.com, hackers@FreeBSD.ORG In-Reply-To: <19981222023206.L14124@follo.net> from "Eivind Eklund" at Dec 22, 98 02:32:06 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My 3.0-RELEASE system, up some 17 days, is now doing this when I telnet > > (or ping, or anything else that uses inetd) to it. (I don't know how long > > it's been like this, perhaps it explains why my outgoing email seem to > > be being dropped on the floor. > > > > Do I remember correctly that there was some fix for this made shortly > > before 3.0-RELEASE? Did the fix not make it into 3.0-RELEASE? Before > > I go snag the LaG inetd sources, will that fix the problem? > > This has been fixed recently (last week, I think). Not fixed for > 3.0-RELEASE. This fixes the inetd problem, but doesn't fix the mmap "page corruption" due to a stale page reference not being revoked properly after a low swap condition causes clean pages in an mmap'ed image to be reaped out. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:09:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA23647 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:09:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA23642 for ; Mon, 4 Jan 1999 20:09:19 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by freefall.freebsd.org (8.8.8/8.8.5) with ESMTP id UAA08668 for ; Mon, 4 Jan 1999 20:09:12 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id VAA17260; Mon, 4 Jan 1999 21:08:51 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd017168; Mon Jan 4 21:08:42 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA05311; Mon, 4 Jan 1999 21:08:33 -0700 (MST) From: Terry Lambert Message-Id: <199901050408.VAA05311@usr05.primenet.com> Subject: Re: Interesting un-interruptible shell script on 3.0-RELEASE (possible sh bug?) To: cracauer@cons.org (Martin Cracauer) Date: Tue, 5 Jan 1999 04:08:33 +0000 (GMT) Cc: rivers@dignus.com, cracauer@cons.org, freebsd-hackers@freefall.cdrom.com In-Reply-To: <19981222182157.A5343@cons.org> from "Martin Cracauer" at Dec 22, 98 06:21:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What is needed here is that sh breaks the loop (instead of exiting > itself) if a child inside a loop exists with WIFSIGNALED(status). This > is not trivial to implement since you can have nested loops and want > to break the outermost. Also, I'll have to see what POSIX sais about > the issue (yes, the fat book arrived and is paid :-). > > I'll give it a shot over the holidays, for now I'll file a PR to > document the issue. Recurse. Have the loop exit with status equivalent to WIFSIGNALED(status) from the child. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:16:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA24377 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:16:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA24371 for ; Mon, 4 Jan 1999 20:16:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA91177; Mon, 4 Jan 1999 20:15:58 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Jan 1999 20:15:58 -0800 (PST) From: Matthew Dillon Message-Id: <199901050415.UAA91177@apollo.backplane.com> To: Terry Lambert Cc: eivind@yes.no (Eivind Eklund), kaleb@ics.com, hackers@FreeBSD.ORG Subject: Re: inetd in realloc(): warning: junk pointer, too low to make sense. References: <199901050401.VAA04572@usr05.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > My 3.0-RELEASE system, up some 17 days, is now doing this when I telnet :> > (or ping, or anything else that uses inetd) to it. (I don't know how long :> > it's been like this, perhaps it explains why my outgoing email seem to :> > be being dropped on the floor. :> > :> > Do I remember correctly that there was some fix for this made shortly :> > before 3.0-RELEASE? Did the fix not make it into 3.0-RELEASE? Before :> > I go snag the LaG inetd sources, will that fix the problem? :> :> This has been fixed recently (last week, I think). Not fixed for :> 3.0-RELEASE. : :This fixes the inetd problem, but doesn't fix the mmap "page corruption" :due to a stale page reference not being revoked properly after a low :swap condition causes clean pages in an mmap'ed image to be reaped out. : : Terry Lambert : terry@lambert.org Dmitrij Tejblum commited a patch to vm/swap_pager.c on December 29th that should fix that problem. Neither David Greenman nor I could quite figure out why it seemed to fix the problem but we speculated that something in vm/vm_fault.c is clearing the vm_page_t dirty bits after the swap code re-set them, resulting in a page incorrectly marked clean. Have you updated your kernel since then? Is the problem still there? If that doesn't fix, my new swap code hopefully will but I don't intend to commit it into the new -stable branch for at least a few months... it will only be in the new -current branch. We'd want to find a solution for the new -stable branch sooner then that. -Matt :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:28:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25099 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:28:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25093 for ; Mon, 4 Jan 1999 20:28:48 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id VAA24527; Mon, 4 Jan 1999 21:28:18 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd024478; Mon Jan 4 21:28:16 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA06606; Mon, 4 Jan 1999 21:28:14 -0700 (MST) From: Terry Lambert Message-Id: <199901050428.VAA06606@usr05.primenet.com> Subject: Re: vfs_bio / struct buf To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 5 Jan 1999 04:28:14 +0000 (GMT) Cc: dg@root.com, hackers@FreeBSD.ORG In-Reply-To: <199812230444.UAA10868@apollo.backplane.com> from "Matthew Dillon" at Dec 22, 98 08:44:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :The optimization is primarily for short writes (like 1 byte or a few bytes) > :so couldn't really be replaced by something that has 512 byte granularity > :without losing some performance. Granted, applications that show this > :behavior are probably broken, but that's another issue. > > Ah. Hmmm. I see the problem... the buf's need some sort of native block > size and NFS doesn't really have a native block size. Not to contrdict David, but I was under the impression that the reason for this code was not necessarily the read-before-write avoidance on small, unaligned regions, but was actually for the avoidance on aligned block sized or multiple of block size regions being written. The theory being that if you wrote a fragment of a NFS buffer size and did this sseveral times that you could just write it and not read at all. Mostly or database stuff, if I recall correctly. There's actually a byte field that's unused as far as I can tell to allow page granularity down to PAGE_SIZE/8 to be bitmapped for validity within a given page, for similar reasons. I went looking at this code when I had an MSDOS FS that used 1K blocks, but was not aligned on an even 1K boundary from the start of the device (odd cylinder size on the physical disk), which mean that every 4th 1K block spanned a page boundary (with obvious performance degradation during random access). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:32:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25637 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:32:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25557 for ; Mon, 4 Jan 1999 20:32:04 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id VAA25824; Mon, 4 Jan 1999 21:31:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd025607; Mon Jan 4 21:31:11 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA06817; Mon, 4 Jan 1999 21:31:04 -0700 (MST) From: Terry Lambert Message-Id: <199901050431.VAA06817@usr05.primenet.com> Subject: Re: ACE 4.6 on -current (still) To: oddbjorn@oddbjorn.bdc.no (Oddbjorn Steffensen) Date: Tue, 5 Jan 1999 04:31:04 +0000 (GMT) Cc: jesse@prinz-atm.CS.Uni-Magdeburg.De, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199812231102.MAA17654@oddbjorn.bdc.no> from "Oddbjorn Steffensen" at Dec 23, 98 12:02:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I already fiddled around with this about a month ago but still > > couldn't figure out what I am missing. > > I got it to work by using gcc 2.8 and uncommenting the > > // #define ACE_HAS_SIGWAIT > > line in $ACE_ROOT/ace/config-freebsd[-pthread].h. It gave > some warnings during compilation, but nothing fatal. I haven't > tested it beyond a few of the example programs, 'tho. > > This was on -CURRENT as of late November. I got it to work on 2.2.6 (and -current) using gcc 2.8.1, but back when the pthreads implementation was Draft 4.0 compliant, and not in limbo between Draft 4 and Standard (as it is now). I needed Jeremy Allison's per threads exception stack code, which is now part of the FreeBSD 2.8.1 port. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:38:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25951 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:38:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA25946 for ; Mon, 4 Jan 1999 20:38:10 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 4540 invoked from network); 5 Jan 1999 04:37:42 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 5 Jan 1999 04:37:42 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id XAA26494; Mon, 4 Jan 1999 23:37:41 -0500 (EST) Message-Id: <199901050437.XAA26494@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901050338.UAA03450@usr05.primenet.com> from Terry Lambert at "Jan 5, 99 03:38:47 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 4 Jan 1999 23:37:41 -0500 (EST) Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > The biggest problem I had was the thing was moving too fast for me > to be able to track it adequately. That was probably just me (or > maybe a lack of documentation describing the thing... ;-)). > Yep, it seems that things are now happening more slowly, but more coherently. When I was working on it, it was either a case of doing the work, or doing the docs. Things are quite stable now, and whomever has the time would possibly have a chance of tracking progress. > > > Also, the FreeBSD VFS/VM code already supports the ability to > > have non-mapped buffers (and has for 2years.) There is alot in there that > > might make the complexity look excessive, but that is only because there > > are features in there that are almost ready to go. > > Actually, I think some of the tighness of VM system integration into > the VFS code is a mistake. > I think that since the amount of interaction needed is now understood, a rearchitecting of the code would valuable. IMO, the VFS and VM code need to be bound in very intimate ways, and most seperation between the two is artificial. My guess is that it is probable that the efforts had historically been split between VFS and VM, and the interfaces were defined without both parties understanding the needs. Since that is understood now, things should be reworked. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:38:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26200 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:38:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26195 for ; Mon, 4 Jan 1999 20:38:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA91261; Mon, 4 Jan 1999 20:38:24 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Jan 1999 20:38:24 -0800 (PST) From: Matthew Dillon Message-Id: <199901050438.UAA91261@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable References: <199901050338.UAA03450@usr05.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Specifically, I think that the VM references should be macro-ized :so that the underlying VM system has much less impact on the code. : :I'd like to see VFS modules portable between the BSD's (the main :obstacle at this point is that the VM intrusions aren't generalized Well, certain things, yes... not macroized, but __inline'd. But let me deal with those sorts of optimizations since I'm hip-deep in the VM code right now. I've had to rip out half a dozen such optimizations because they (A) weren't saving very many cpu cycles, and (B) they were stale and no longer in sync with the VM algorithms, and I've put *in* other less messy __inline optimizations that save about as many cycles. Basically, on too many occassions, people have ripped out pieces of VM subroutines and manually inserted them in other VM code to avoid making a subroutine call. These sorts of optimizations not only haven't produced much in the way of performance results, many of them have destabilized the codebase as other programmers have made modifications to the procedures and 'missed' the extracted pieces of code inserted in other places. There have also been some truely serious breeches of the appropriate use of __inline - 50+ line procedures inline'd with repeated calls to them in several places in the code which do more damage to the cpu's primary cache then the measily 2% call/return cycle overhead (in a 50 line procedure) that they save. But, with appropriate use of __inline functions there are quite a few optimizations that we *CAN* make to de-proceduralized the critical path. For example, the pagerops calls (vm/vm_pager.c) are currently all discrete procedures which can easily (and will soon be) migrated to __inline's in vm/vm_pager.h. :to ignore the underlying implementation (in the FreeBSD case, the :intrusion points for cache coherency have been diked out); after :that's fixed, the obstacle becomes the "cookie" crap in VOP_READDIR :(it has argument order of operation issues, which is why the NetBSD :AFS code won't work in FreeBSD), which should be murdered by splitting :the VOP_READDIR into VOP_GETDIRBLK/VOP_GETBLKENTRY to get rid of the :need for a cookie for resuming context in a directory block for NFS :and too-small-user-buffer based traversals -- at the same time paving :the way for kernel based globbing for about a 5 times speed increase :for a SAMBA/AFS specific system call KLD module). The entire VFS interface needs to be revamped. There are multiple problems with it. The one's I will concentrate on starting a month or two from now are basically the blocking and low-memory deadlock situations that crop up when you have multiple VFS layers. I've already fixed about a half a dozen low-memory or buffer-exhaustion deadlock situations that will be committed to the new -current after the CVS tree splits - you can actually take a 30MB core dump onto an MFS filesystem on a 48MB machine using NFS based swap now while simultaniously running a vnode-eating (find /usr | xargs md5) and memory-eating (allocate/touch/loop) program. Over and over again. In anycase, anyone interested in looking at my current patch-set, which due to its complexity also includes the more seriously changed files en-toto, can look at it at: http://www.backplane.com/FreeBSD/ http://www.backplane.com/FreeBSD/dillon-swapper-A8.tgz No comments on syntax or #if 0's, please - there will be a general cleanup pass after the initial commit after the tree splits. Also ignore the stuff that isn't obviously related to the VM system, like the if_slip junk -- those aren't really part of this project. This is the stuff that I've been working on with DG and John. It is quite extensive: don't try to understand the unified diff for vm/vm_page.c or vm/swap_pager.c, look at the files included along with the diff in the tar instead. New swapper, new swap bitmap allocator, moderate vm_page_t handling changes, and lots of other junk. Not all the code has been optimized yet, though due to the removal or reduction of two major linear linked lists it's probably already much faster then the old code despite the unwinding of some of the (improperly done) manual code inlining. : Terry Lambert : terry@lambert.org Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:42:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26433 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:42:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26428; Mon, 4 Jan 1999 20:42:06 -0800 (PST) (envelope-from vicck@eudoramail.com) Received: from nemo.sni.ch (nemo.sni.ch [158.226.180.10]) by freefall.freebsd.org (8.8.8/8.8.5) with SMTP id UAA10155; Mon, 4 Jan 1999 20:41:59 -0800 (PST) Message-Id: <199901050441.UAA10155@freefall.freebsd.org> Received: from ch-klomx1.sni.ch by nemo.sni.ch via smtpd (for freefall.FreeBSD.org [204.216.27.21]) with SMTP; 5 Jan 1999 04:41:40 UT Received: (private information removed) From: "Joe" Received: (private information removed) Subject: For the Rest of Your Life, WE Will Remind You! To: groups55a@FreeBSD.ORG X-Mailer: Mozilla 4.72 [en] (Win95; I) Mime-Version: 1.0 Date: Mon, 04 Jan 1999 23:20:09 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAB26429 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Never Forget Again because THE LIFETIME REMINDER SERVICE will send you a postcard 1 week prior to every date you that want to be reminded of year after year for the rest of your life! ++++++++++++++++++++++++++++++++++++ Do you forget? Friends Birthdays? Anniversaries? When to change your oil? Your annual outdoor activities such as hunting, fishing, or camping trips? Any Important dates that you want to be reminded of? Or even reminders to do things like call your friend in Alaska once a year! ***************************************************** Purcahse your lifetime membership for a one time fee of $9.95 and we will snail mail your membership ID# and reminder form which is everything that you need to start receiving unlimited reminders in your mailbox. Yes, the number of occasions that we will remind you of each year is unlimited AND you can change your reminders at ANYTIME!! Order 24 hours a day, 7 days a week (800) 860 - 6821 ////////////////////////////////////////////////////// To be removed reply to mailto:offlst@hotbot.com?subject=remove ////////////////////////////////////////////////////// To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:42:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26568 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:42:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (sj-dsl-9-129-138.dspeed.net [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26563 for ; Mon, 4 Jan 1999 20:42:51 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id UAA88366; Mon, 4 Jan 1999 20:41:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199901050441.UAA88366@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: oddbjorn@oddbjorn.bdc.no (Oddbjorn Steffensen), jesse@prinz-atm.CS.Uni-Magdeburg.De, freebsd-hackers@FreeBSD.ORG Subject: Re: ACE 4.6 on -current (still) In-reply-to: Your message of "Tue, 05 Jan 1999 04:31:04 GMT." <199901050431.VAA06817@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jan 1999 20:41:25 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It would be cool to find out how ACE performs on -current with the linux thread patches available at: http://lt.tar.com/ Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:45:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26754 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:45:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26747 for ; Mon, 4 Jan 1999 20:45:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA91309; Mon, 4 Jan 1999 20:45:23 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Jan 1999 20:45:23 -0800 (PST) From: Matthew Dillon Message-Id: <199901050445.UAA91309@apollo.backplane.com> To: Terry Lambert Cc: dg@root.com, hackers@FreeBSD.ORG Subject: Re: vfs_bio / struct buf References: <199901050428.VAA06606@usr05.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :so couldn't really be replaced by something that has 512 byte granularity :> :without losing some performance. Granted, applications that show this :> :behavior are probably broken, but that's another issue. :> :> Ah. Hmmm. I see the problem... the buf's need some sort of native block :> size and NFS doesn't really have a native block size. : :Not to contrdict David, but I was under the impression that :the reason for this code was not necessarily the read-before-write :avoidance on small, unaligned regions, but was actually for the :avoidance on aligned block sized or multiple of block size regions :being written. The theory being that if you wrote a fragment of a :NFS buffer size and did this sseveral times that you could just write :it and not read at all. Mostly or database stuff, if I recall :correctly. : :There's actually a byte field that's unused as far as I can tell to :allow page granularity down to PAGE_SIZE/8 to be bitmapped for :validity within a given page, for similar reasons. It isn't unused! The valid and dirty bits are definitely used (and have a DEV_BSIZE granularity). For lots of things. For example, the MSDOS filesystem. The problem is that that is the best granularity that a vm_page_t can have. The validoff/validend/dirtyoff/dirtyend stuff was thrown into the bp because DEV_BSIZE'd granularity isn't good enough for NFS when you might be reading or writing just a few bytes. Read-before-write isn't the real problem, though the optimization certainly fixes that. The real problem is when you have multiple machines doing an lseek()/write() on the same file. The write() granularity must be correct or the machines will screw each other up even though they aren't writing to the same byte ranges (but are writing to the same block). :I went looking at this code when I had an MSDOS FS that used :1K blocks, but was not aligned on an even 1K boundary from the :start of the device (odd cylinder size on the physical disk), :which mean that every 4th 1K block spanned a page boundary :(with obvious performance degradation during random access). : : Terry Lambert : terry@lambert.org heh. That should be fixed now with Luoqi's commits. The bp system now understands DEV_BSIZE'd alignment properly in (hopefully) all cases. As long as it is at least 512-byte aligned it should work. I wouldn't worry about performance degredation there too much - it's all just mapping already-cached pages into bp's, but I haven't looked at it with a microscope so I can't say that for absolute sure. -Matt :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:47:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26984 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:47:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pacman.redwoodsoft.com (redwoodsoft.com [207.181.199.182]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA26979 for ; Mon, 4 Jan 1999 20:47:12 -0800 (PST) (envelope-from dnelson@pacman.redwoodsoft.com) Received: (qmail 1695 invoked by uid 1000); 5 Jan 1999 04:46:43 -0000 Date: Mon, 4 Jan 1999 20:46:43 -0800 (PST) From: Dru Nelson To: freebsd-hackers@FreeBSD.ORG Subject: UDMA in 2.2.8 - patches? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm now working with a big site and I'm moving them over to FreeBSD from Linux for stability. The unfortunate thing is that almost all of the machines use IDE drives. I haven't tried 3.0 and I don't know how stable it is yet. I want to have machines that run for many, many days and freebsd 2.[12].* has done time and time again in the past. So, I'm running 2.2.8 on some of these machines right now. It has everything I need, except for UDMA support (soft updates would be nice :-), but I can wait for that in 3.0). IDE will be OK for these machines, I'm just worried about too many interupts and not getting good IO performance. What is the outlook or possible big ugly monster involved with getting DMA or some of the EIDE features into 2.2.8 (Intel only chipsets)? I have no problem with putting something in /sys/pci to get going on this... *(I'm willing to spend some time on this)* I can rationalize adding support for DMA 2.2.8, and testing it thoroughly, I can't see going to 3.0 just yet. BTW, hdparm on linux, isn't bad. Can ide be controled dynamically from command line on 3.0? Dru Nelson Redwood City, California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 20:52:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27591 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:52:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27584 for ; Mon, 4 Jan 1999 20:52:27 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id PAA05774; Tue, 5 Jan 1999 15:21:35 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id PAA78870; Tue, 5 Jan 1999 15:21:41 +1030 (CST) Date: Tue, 5 Jan 1999 15:21:41 +1030 From: Greg Lehey To: Dru Nelson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UDMA in 2.2.8 - patches? Message-ID: <19990105152140.C78349@freebie.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Dru Nelson on Mon, Jan 04, 1999 at 08:46:43PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 4 January 1999 at 20:46:43 -0800, Dru Nelson wrote: > > Hi, > > I'm now working with a big site and I'm moving them over > to FreeBSD from Linux for stability. The unfortunate thing > is that almost all of the machines use IDE drives. > > I haven't tried 3.0 and I don't know how stable it is yet. I want > to have machines that run for many, many days and freebsd 2.[12].* > has done time and time again in the past. So, I'm running 2.2.8 on > some of these machines right now. It has everything I need, except for > UDMA support (soft updates would be nice :-), but I can wait for that in > 3.0). > > IDE will be OK for these machines, I'm just worried about too many > interupts and not getting good IO performance. > > What is the outlook or possible big ugly monster involved with > getting DMA or some of the EIDE features into 2.2.8 (Intel only > chipsets)? I have no problem with putting something in /sys/pci > to get going on this... *(I'm willing to spend some time on this)* > > I can rationalize adding support for DMA 2.2.8, and testing it thoroughly, > I can't see going to 3.0 just yet. I think that the chances are slim of getting a version of 2.2.8 with UDMA support as stable as 3.0 already is. It's not that bad. -STABLE will be out in the middle of the month. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 21:08:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA28742 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 21:08:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles182.castles.com [208.214.165.182]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA28737 for ; Mon, 4 Jan 1999 21:08:33 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id VAA00430; Mon, 4 Jan 1999 21:05:14 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901050505.VAA00430@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dru Nelson cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UDMA in 2.2.8 - patches? In-reply-to: Your message of "Mon, 04 Jan 1999 20:46:43 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jan 1999 21:05:14 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > IDE will be OK for these machines, I'm just worried about too many > interupts and not getting good IO performance. > > What is the outlook or possible big ugly monster involved with > getting DMA or some of the EIDE features into 2.2.8 (Intel only > chipsets)? I have no problem with putting something in /sys/pci > to get going on this... *(I'm willing to spend some time on this)* > > I can rationalize adding support for DMA 2.2.8, and testing it thoroughly, > I can't see going to 3.0 just yet. If you're not too worried about CPU on these machines, I'd suggest looking at trying some of the go-faster IDE flags available in 2.2.x before deciding that you need DMA. Try the 32-bit flag (reduce CPU overhead) and the multi-sector transfer count (reduce interrupt count); try 8 or 16 sectors at most. > BTW, hdparm on linux, isn't bad. Can ide be controled dynamically from > command line on 3.0? No; what would you like to tune? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 21:29:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA00894 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 21:29:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA00889 for ; Mon, 4 Jan 1999 21:29:31 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA04339; Mon, 4 Jan 1999 21:20:27 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdyu4335; Tue Jan 5 05:20:20 1999 Message-ID: <3691A110.2781E494@whistle.com> Date: Mon, 04 Jan 1999 21:20:16 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: Greg Lehey CC: Dru Nelson , freebsd-hackers@FreeBSD.ORG Subject: Re: UDMA in 2.2.8 - patches? References: <19990105152140.C78349@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > On Monday, 4 January 1999 at 20:46:43 -0800, Dru Nelson wrote: > > > > Hi, > > > > I'm now working with a big site and I'm moving them over > > to FreeBSD from Linux for stability. The unfortunate thing > > is that almost all of the machines use IDE drives. > > [...] The UDMA patches originally were for 2.2.x If you can find the original patches through the mail archives (a bit of sleuthing) you may be able to bring htem up to date. of course you may also find we don't support the hardware you have.. > I think that the chances are slim of getting a version of 2.2.8 with > UDMA support as stable as 3.0 already is. It's not that bad. -STABLE > will be out in the middle of the month. > > Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 22:11:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04903 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 22:11:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04887 for ; Mon, 4 Jan 1999 22:11:22 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id WAA10647; Mon, 4 Jan 1999 22:10:53 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id WAA26487; Mon, 4 Jan 1999 22:10:52 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199901050351.UAA04038@usr05.primenet.com> Date: Mon, 04 Jan 1999 22:10:52 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Terry Lambert Subject: Re: Apache with dynamic modules files miserably. Cc: hackers@FreeBSD.ORG, (Ugen Antsilevitch) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 05-Jan-99 Terry Lambert wrote: > > Make sure you are using an ELF mod_env.so. The modules have to be in the same object format as the main executable, and the port builds them that way. If the module was in the wrong object format, the error message would have been different. > The lack of a leading underscore on the error message means it's > looking for an ELF symbol. The a.out dynamic linker is smart enough to add the leading underscore if necessary. So that's not the problem. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 22:15:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05204 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 22:15:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Chuska.ConSys.COM (Chuska.ConSys.COM [209.141.107.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05199 for ; Mon, 4 Jan 1999 22:15:11 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (ip-17-117.prc.primenet.com [207.218.17.117]) by Chuska.ConSys.COM (8.9.1/8.9.1) with ESMTP id XAA18783 for ; Mon, 4 Jan 1999 23:14:44 -0700 (MST) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.1/8.8.7) with ESMTP id XAA01234 for ; Mon, 4 Jan 1999 23:11:53 -0700 (MST) Message-Id: <199901050611.XAA01234@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Re: ACE 4.6 on -current (still) In-reply-to: Your message of "Mon, 04 Jan 1999 20:41:25 PST." <199901050441.UAA88366@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jan 1999 23:11:53 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Both hasty@rah.star-gate.com said: > It would be cool to find out how ACE performs on -current with the > linux thread patches available at: > > http://lt.tar.com/ > > Cheers, > Amancio and tlambert@primenet.com said: > I got it to work on 2.2.6 (and -current) using gcc 2.8.1, but back > when the pthreads implementation was Draft 4.0 compliant, and not in > limbo between Draft 4 and Standard (as it is now). > > I needed Jeremy Allison's per threads exception stack code, which is > now part of the FreeBSD 2.8.1 port. comment on ACE on -current. ACE-current on FreeBSD-current works fine with the config files at www.pinyon.org/ace/config-freebsd3.h and www.pinyon.org/ace/platform-freebsd3.h These pass all of the ACE (modulo nits) tests on -current using stock cc. TAO is another matter, because the really cool things just don't work because of the *_sched* immaturity. ACE works (except for *_sched*) now. TAO is all that matters. And Richard's work may be a step in the right direction. To understand this better, we need to get MT_Cubit working. I am in the middle of proposals till the end of this week, so no more progress till next week. I have a set of config files that passes all but Conn_Test using Richard's linuxthread work. MT_Cubit fails the same way as Conn_Test. Got an interesting problem here. These config files: www.pinyon.org/ace/config-freebsd3lt.h and www.pinyon.org/ace/platform-freebsd3lt.GNU build ACE+TAO with linuxthreads-12-29-98 just fine. (and they assume egcs 1.1.1) You might need this oddball little patch to get tao_idl working: *** be_interface.cpp Thu Oct 8 23:07:37 1998 --- be_interface.cpp.new Tue Dec 29 22:05:00 1998 *************** *** 1557,1562 **** --- 1557,1563 ---- // Spawn a process for gperf. + write(ACE_STDOUT,"Ouch!\n",6); if (process_manager.spawn (process_options) == -1) ACE_ERROR_RETURN ((LM_ERROR, "Error:%p:Couldnt spawn a process for gperf program\n"), Talk to you later, when I don't have to actually *work* for a living... Cheers, Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 22:21:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05820 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 22:21:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Chuska.ConSys.COM (Chuska.ConSys.COM [209.141.107.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05815 for ; Mon, 4 Jan 1999 22:21:18 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (ip-17-117.prc.primenet.com [207.218.17.117]) by Chuska.ConSys.COM (8.9.1/8.9.1) with ESMTP id XAA18798; Mon, 4 Jan 1999 23:20:51 -0700 (MST) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.1/8.8.7) with ESMTP id XAA01381; Mon, 4 Jan 1999 23:18:00 -0700 (MST) Message-Id: <199901050618.XAA01381@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: "Russell L. Carter" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ACE 4.6 on -current (still) In-reply-to: Your message of "Mon, 04 Jan 1999 23:11:53 MST." <199901050611.XAA01234@psf.Pinyon.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jan 1999 23:18:00 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Both > > hasty@rah.star-gate.com said: > > It would be cool to find out how ACE performs on -current with the > > linux thread patches available at: > > > > http://lt.tar.com/ > > > > Cheers, > > Amancio > > and > > tlambert@primenet.com said: > > I got it to work on 2.2.6 (and -current) using gcc 2.8.1, but back > > when the pthreads implementation was Draft 4.0 compliant, and not in > > limbo between Draft 4 and Standard (as it is now). > > > > I needed Jeremy Allison's per threads exception stack code, which is > > now part of the FreeBSD 2.8.1 port. > > comment on ACE on -current. > > ACE-current on FreeBSD-current works fine with the config > files at > > www.pinyon.org/ace/config-freebsd3.h > > and > > www.pinyon.org/ace/platform-freebsd3.h ^ JKH worthy profanities... that should be www.pinyon.org/ace/platform-freebsd3.GNU Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 4 22:59:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09034 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 22:59:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09029 for ; Mon, 4 Jan 1999 22:59:31 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA17418; Mon, 4 Jan 1999 23:58:55 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <3691B82E.1D4E4B99@softweyr.com> Date: Mon, 04 Jan 1999 23:58:54 -0700 From: Wes =?iso-8859-1?Q?Peters=D4?==?iso-8859-1?Q?=40=21=EA?= =?iso-8859-1?Q?=80?==?iso-8859-1?Q?=EA?==?iso-8859-1?Q?=80=DD=E7?= =?iso-8859-1?Q?=805=EA?==?iso-8859-1?Q?=C0?==?iso-8859-1?Q?=EA?= Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901050315.UAA02641@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Alfred Perlstein wrote: > > > I'm a bit confused. I've been watching the discussions going on about > > SMP. The issue of kernel re-entrancy has been brought up many times. > > [Detailed answer elided...] > > It's a lot of work, but it's not rocket science. The most > complicated piece is the lock manager; to do it right, you need > a five dimensional vector relationship (an arc describing the > intersection of three two dimensional vectors: the lock list > held by a locking entity, the hierarchical list of lockable objects, > and the relationship between multiple locking entities within a > single process -- threads within a process). If you wish to see a working example of a microkernel using object locks, take a peek at the RTEMS kernel. It's quite portable, and supports SMP systems out of the box. See http://www.oarcorp.com/rtems/rtems.html for information. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 01:05:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA19007 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 01:05:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.149.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA19002 for ; Tue, 5 Jan 1999 01:04:56 -0800 (PST) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id UAA06723 for hackers@freebsd.org; Tue, 5 Jan 1999 20:04:22 +1100 (EDT) From: Darren Reed Message-Id: <199901050904.UAA06723@cheops.anu.edu.au> Subject: psm0 on laptops. To: hackers@FreeBSD.ORG Date: Tue, 5 Jan 1999 20:04:21 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Modern laptops with an `inbuilt' mouse as well as an external mouse port allow usage to be changed by simply "plugging in" a PS-2 mouse when running Windows. However, I noticed that FreeBSD 2.2.7 detects them both differently (generic PS/2 vs IntelliMouse) and hence if you boot up with one, you can't unplug and use the other. Is this "fixed" in -current or is there some other way to "make it work" ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 01:11:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA19541 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 01:11:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles182.castles.com [208.214.165.182]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA19536 for ; Tue, 5 Jan 1999 01:11:26 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id BAA01739; Tue, 5 Jan 1999 01:08:05 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901050908.BAA01739@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Darren Reed cc: hackers@FreeBSD.ORG Subject: Re: psm0 on laptops. In-reply-to: Your message of "Tue, 05 Jan 1999 20:04:21 +1100." <199901050904.UAA06723@cheops.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jan 1999 01:08:04 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Modern laptops with an `inbuilt' mouse as well as an external mouse > port allow usage to be changed by simply "plugging in" a PS-2 mouse > when running Windows. However, I noticed that FreeBSD 2.2.7 detects > them both differently (generic PS/2 vs IntelliMouse) and hence if you > boot up with one, you can't unplug and use the other. Is this "fixed" > in -current or is there some other way to "make it work" ? You might be able to do it by using moused and restarting it when you change mice. If that works, a little more tinkering might make it practical to have it autodetect the change... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 02:22:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA26761 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 02:22:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA26756 for ; Tue, 5 Jan 1999 02:22:19 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:6djXR7zEVqViSNRl2w7l9pomlhe4sVrS@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id TAA12656; Tue, 5 Jan 1999 19:21:22 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id TAA20647; Tue, 5 Jan 1999 19:23:43 +0900 (JST) Message-Id: <199901051023.TAA20647@zodiac.mech.utsunomiya-u.ac.jp> To: Darren Reed , Mike Smith cc: hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: psm0 on laptops. In-reply-to: Your message of "Tue, 05 Jan 1999 01:08:04 PST." <199901050908.BAA01739@dingo.cdrom.com> References: <199901050908.BAA01739@dingo.cdrom.com> Date: Tue, 05 Jan 1999 19:23:42 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Modern laptops with an `inbuilt' mouse as well as an external mouse >> port allow usage to be changed by simply "plugging in" a PS-2 mouse >> when running Windows. However, I noticed that FreeBSD 2.2.7 detects >> them both differently (generic PS/2 vs IntelliMouse) and hence if you >> boot up with one, you can't unplug and use the other. Is this "fixed" >> in -current or is there some other way to "make it work" ? > >You might be able to do it by using moused and restarting it when you >change mice. If that works, a little more tinkering might make it >practical to have it autodetect the change... Um, the psm driver does not currently support "hot plugging". If you swap PS/2 mice while the system is running, the psm driver will be confused and fail to work properly if the two mice doesn't talk the same protocol. I don't know how the W*ndows PS/2 mouse driver can detect that a new mouse has suddenly appeared at the PS/2 mouse port and switch to a different protocol. You see, both the internal PS/2 mouse/pointing device and the external device are wired to the same PS/2 mouse port... That said, you may experiment a bit as follows: The psm driver in 3.0-CURRENT has several new configuration flags, some of which may be useful. (Unfortunately they are not yet explained in the man page for psm(4) ;-< flags 0x200 With the above flag the psm driver will treat any PS/2 mouse as "generic PS/2" mouse and will use the standard PS/2 mouse protocol only. You should be able to use any PS/2 mouse, internal or external, in this configuration. However, you won't be able to use "wheel", "roller", or any other fancy features. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 03:12:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA00507 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 03:12:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA00501 for ; Tue, 5 Jan 1999 03:11:56 -0800 (PST) (envelope-from bs@adimus.de) Received: (from admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id MAA21238; Tue, 5 Jan 1999 12:00:42 +0100 (MET) Received: from mail by mx.adimus.de with local (Exim 1.92 #1) id 0zxTzU-0000rr-00; Tue, 5 Jan 1999 11:45:36 +0100 Received: from det.adimus.de(192.168.0.1) via SMTP by adimus.de, id smtpdLm3199; Tue Jan 5 11:45:30 1999 Received: from bs by det.adimus.de with local (Exim 1.92 #1) id 0zxTzO-0000xp-00; Tue, 5 Jan 1999 11:45:30 +0100 To: Yani Brankov Cc: "Stephen J. Roznowski" , hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? References: <199901032313.SAA04829@istari.home.net> <368FFD42.F849603C@bulinfo.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Benedikt Stockebrand Date: 05 Jan 1999 11:45:28 +0100 In-Reply-To: Yani Brankov's message of "Mon, 04 Jan 1999 01:29:06 +0200" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yani Brankov writes: > /etc/crontab duplicates the role of the user crontabs, but anyway I > think it's more > convenient to have all the necessary system crontab entries in one file. Aside from that it's a Good Thing[TM] to keep all configuration files in /etc --- putting them in /var will bite you as soon as you have to recover from a disk crash and find out you've never bothered to dump /var (including assorted spools and log files). And /var has a way stronger tendency to get messed up on a system crash than / has. So long, Ben -- Benedikt Stockebrand Adimus Beratungsgesellschaft für System- System Administration & Design, und Netzwerkadministration mbH & Co KG IT Security, Remote System Mgmt Universitätsstr. 142, 44799 Bochum Opinions presented are my own. Tel. (02 34) 971 971 -2, Fax -9 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 03:16:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA00841 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 03:16:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA00836; Tue, 5 Jan 1999 03:16:05 -0800 (PST) (envelope-from roger@cs.strath.ac.uk) Received: from cs.strath.ac.uk (scary.dmem.strath.ac.uk [130.159.202.5]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id LAA03008 Tue, 5 Jan 1999 11:15:23 GMT Message-ID: <3691F450.8ACEF97C@cs.strath.ac.uk> Date: Tue, 05 Jan 1999 11:15:28 +0000 From: Roger Hardiman X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) MIME-Version: 1.0 To: multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Hauppauge IR Remote Control support. Beta testers wanted. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all. BETA TESTERS WANTED for the Hauppauge WinCast/TV (WinTV/PCI) IR Remote Control support. Following a days hacking and some emails from my contacts in the Hauppauge technical team, I have the specs for the Hauppauge IR Remote Control. I'll try and work something into the bktr driver in the next week or so. Then I need to modify FXTV (with Randall's help). If you have the IR Remote Control I need you to beta test the driver. Can you email me and I'll be able to keep you informed when there is code ready to test. Thanks Roger Hardiman Strathclyde University Telepresence Group roger@cs.strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 03:23:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01534 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 03:23:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01529 for ; Tue, 5 Jan 1999 03:23:32 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id AAA21631; Wed, 6 Jan 1999 00:23:01 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id AAA06255; Wed, 6 Jan 1999 00:22:59 +1300 (NZDT) (envelope-from jabley) Date: Wed, 6 Jan 1999 00:22:59 +1300 From: Joe Abley To: Benedikt Stockebrand Cc: Yani Brankov , "Stephen J. Roznowski" , hackers@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: Why is root's crontab different? Message-ID: <19990106002259.B6168@clear.co.nz> References: <199901032313.SAA04829@istari.home.net> <368FFD42.F849603C@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Benedikt Stockebrand on Tue, Jan 05, 1999 at 11:45:28AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 05, 1999 at 11:45:28AM +0100, Benedikt Stockebrand wrote: > Yani Brankov writes: > > > /etc/crontab duplicates the role of the user crontabs, but anyway I > > think it's more > > convenient to have all the necessary system crontab entries in one file. > > Aside from that it's a Good Thing[TM] to keep all configuration files > in /etc --- putting them in /var will bite you as soon as you have to > recover from a disk crash and find out you've never bothered to dump > /var (including assorted spools and log files). And /var has a way > stronger tendency to get messed up on a system crash than / has. If you've lost /var, isn't it probably a good thing that cron isn't running? You probably have more important things to worry about :) Turning your argument around, if it _is_ desirable to have crontabs available with a minimal number of filesystems mounted, why not move /var/cron to /etc/cron and dispense with /etc/crontab? It's not as if crontabs are so variably-sized to really merit living in /var. We seem to have taken the same approach with /etc/namedb, which I have seen more often located in /var/named... But maybe that's just me. I don't know the history of this one. Just an idea anyway :) Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 04:30:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09634 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 04:30:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA09627 for ; Tue, 5 Jan 1999 04:30:56 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.8.8/8.7.3) id NAA20102; Tue, 5 Jan 1999 13:29:46 +0100 (MET) Message-ID: <19990105132945.A20085@cons.org> Date: Tue, 5 Jan 1999 13:29:45 +0100 From: Martin Cracauer To: Roland Jesse , freebsd-hackers@FreeBSD.ORG Subject: Re: ACE 4.6 on -current (still) References: <13952.15788.136215.866276@knecht> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=82I3+IH0IqGh5yIs X-Mailer: Mutt 0.93.1i In-Reply-To: <13952.15788.136215.866276@knecht>; from Roland Jesse on Wed, Dec 23, 1998 at 01:47:40AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii In <13952.15788.136215.866276@knecht>, Roland Jesse wrote: > The problem is to get ACE > (http://siesta.cs.wustl.edu/~schmidt/ACE.html) up and running on a > 3.0-RELEASE machine. I started a port of ACE a while ago. This compiles fine with the default g++ from FreeBSD, one test fails. I appended my port so far, maybe someone will finish it, you mostly need to finish the install stuff and PLIST. I could committ if the person doesn't have committ privs. Note that while it sais ACE_TAO, it is ACE only for now. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ --82I3+IH0IqGh5yIs Content-Type: application/x-tar-gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ACE+TAO.tar.gz" H4sIAKEEkjYAA+1a61OjSBD3a/gretWq88UzIYm5y95xCWrKPKwQVz9cFUVgSCgJcEB0vS3/ 9+shRONr1SoT73bnV0aYnul59fSvYQatoe8OtJ64tkRASaqoKqwBgFyRsyuAlF/zBJTLxbKs lhS5hKVkSVXWQF1mp+aYJqkVA6zZsWVbUxI/V+5qTIi/ig6tFlpu/451QVzPJ8toQ5akcqn0 rP3lEi4Oan+1UsRyFZQo5aK8BtIyOvMQP7n9N6BLriAK4zQBO/R9YqdeGMAkXw7ghnEN8kXC bcAXEic0PyZ/T72YOLXMgiWhjHlNKyVgxwQvuTyz7v5+VVZkWuBsHE7uMuaYT/wfdhgkQhiP YL1jxakXQCPPWec2UHuzhbXOl+neJchCMatclBVRqoJUrcnFWlGGcBh7JAD9awSbqMg1W8ag q3X0egGHwdOunhwf3grouDJhQxvoh71+SzfqWbccckl8rqMZA71vGq3BTM6hpNUd4E/v1wuP us5xZ/1jo9+oFwqb3/C22erfiNiKeRVbUYRzx50aunnY0Y6xdZnjopjww6nnOzUOFRonN5Cp YQ03omUTEet1vRHvxoQME4eP0jFOryOMnywmjB9X4gW2P3WISO05v498K0WzTsy8WnNe7WH3 FP7i8q6/rD6x7DhMqBbHbXS0bhVHHTtofaGKgihMUt4L0Lt8v8ZtFDa3Wl1joLXb5km/d9jX OtuwuTVrZ1vM1DB90tcPWufbYjL0AlG4p4UNPNIQqgs6EyugvyrqcXSCTb37ZTezsdnv9Qb1 9dthrUPj/LwuTpNYpO2Mdneh0bhL2zYn5IOF33B+BOodwuTiM/fRzroEzPmfOlWypKeA18Z/ 5P+iRGMB5QuZxf9V4L79J84y5vyF+A9QWbR/OYv/SonF/1Wg01RhKw+MAs6EMPpnG+pQVlVX kZyiTVRrKBVtu1Ldr6iK61bVoaNUij8iFf6UmPt/dDFa2jvg6/lfkeRK9v6HL4OM/1eBRfs3 ep2O3h28exsv8b8syXf2n8X/ilJh/L8KzJ68E4Kvf+kYX9/80L6A0M0SeG/5MMYHeUjDTJJ6 EwJWEOJ9nGUILBD8v7Ho/03daPSX0MaL/n+7/3Pr/6VKmfn/KpD5/1Z1+20UgLn3WYBrpeAl kHiTyEdhOrYC+BqkERZzwKUbMk7CuOI/iEX/P2m3jPeP/q94/5OLD/1flRTm/6tAttOWkQDz zp8Rt/5vpfZ4STuAb9j/q0h0L4j6f4W9/60CD+2fXXnLes82Xjr/U0pz+5eKxTK1fwkDAeP/ VWBnZwfeekgkhLE3KpwRB5rEBrmM9qqpUk1SsvM4juf5N1f5uLZSXtvOfdA07O9hsSxFz+mG 0xHUQcb7y9npJHHMJMxF3CdoNO4fONZhZNtUfn5eKGBidxfLNQ7a2qFxV2i3DvyZ5fv4Pwq9 ICUxb8VeOgY+8iICfNMcHPV1rWka2oFO9R9UgPqbWzPZNvBuEPL00dizvZRPyYROBUlQrflY jR9lM7i/p0iAN/yrxui5gUNc7MWT41082voE+CzuuQs65+d3k7F4KLZQ9KnZuVrJVHy0f/zo eIb/h+/Zxov8f3v+U1IVqTLjf7b/txJQOv3elwYzrjemAfTsFOQqSFJNLtfUBa7/nvo9Xldr aqVWqj7P68XqHj4n5sQuinCaZFsNv02QiENbGH+mewwOiWJi049MBCy1gRTmBYR+omK2tcax YXa0drvXMI8oMfK0lgQXNv1mIkk95PMgTMGd+v41JNOInuxDGMAB9vtPowm/zzTSMbaDfylG rwDcOJzMiDGJbdH3hvRnm7E4nY1SzEfLR7F3Sb9KGGMtJJhOZi1HVmxNzChExruGb5g1h9E4 0ptmv7/3SNbqPZYdtA6ekPYGR3ofpTe/4r9Z5we081dh8EsKQwIBsUmSWPE1WC4GMfCyfRrX +4p28YJsRye5TpCH5yEbxjgUjDEC1maP0TV2wJ4mJPYc2Jqlk+2sscxCJ3lMn09mAic9o3We 7RLFCVx6Fk57PMWlQyVJROyHRjvSDDPTMQetjv5E5qnW1vqdbKXh+igVZ0Hxo/2GgYGBgYGB gYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgeEj8S+FNRrPAFAAAA== --82I3+IH0IqGh5yIs-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 08:16:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01837 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 08:16:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01831 for ; Tue, 5 Jan 1999 08:16:23 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA14765; Tue, 5 Jan 1999 09:15:56 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA04090; Tue, 5 Jan 1999 09:15:55 -0700 Date: Tue, 5 Jan 1999 09:15:55 -0700 Message-Id: <199901051615.JAA04090@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: psm0 on laptops. In-Reply-To: <199901050904.UAA06723@cheops.anu.edu.au> References: <199901050904.UAA06723@cheops.anu.edu.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Modern laptops with an `inbuilt' mouse as well as an external mouse > port allow usage to be changed by simply "plugging in" a PS-2 mouse > when running Windows. Not on my box. You must first 'suspend' the box, then 'resume' it for this to work. Also, plugging in a mouse while the box is powered on is a good way to blow out your keyboard controller. :( > However, I noticed that FreeBSD 2.2.7 detects them both differently > (generic PS/2 vs IntelliMouse) and hence if you boot up with one, you > can't unplug and use the other. Is this "fixed" in -current or is > there some other way to "make it work" ? Not that I'm aware of. If you have it plugged in to the PS/2 port, you *can* switch to the serial version after bootup by physically switching it and re-configured X to use the serial port version. The reason it works under Windblows is because the mouse driver is a necessary part of the OS, and under FreeBSD it's just another device so the OS/userland stuff isn't integrated like under Windows. (Which also explains why unix is generally more robust, since not everything is integrated together with the OS...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 08:47:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05067 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 08:47:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA05058 for ; Tue, 5 Jan 1999 08:47:44 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id QAA12406; Tue, 5 Jan 1999 16:47:46 GMT Date: Tue, 5 Jan 1999 16:47:25 +0000 (GMT) From: Doug Rabson To: "Justin T. Gibbs" cc: hackers@FreeBSD.ORG Subject: Re: IBM Thinkpad 770 In-Reply-To: <199901042356.QAA22443@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 4 Jan 1999, Justin T. Gibbs wrote: > I'm considering purchasing one of these guys and I'm hoping that someone > out there can confirm getting FreeBSD up and running on it. It looks like > XFree86 supports the Trident video chipset it uses and I would expect > everything else to just fall out. Does anyone know if the acd driver > will grok an ATAPI DVD-ROM drive if you use CD media? I'm pretty sure it will. The old wcd driver likes the drive in my new Toshiba Tecra 8000DVD just fine and I don't expect acd to be any different. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 10:19:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15563 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 10:19:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15558 for ; Tue, 5 Jan 1999 10:19:15 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA13610; Tue, 5 Jan 1999 11:18:43 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd013400; Tue Jan 5 11:18:25 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA08069; Tue, 5 Jan 1999 11:18:19 -0700 (MST) From: Terry Lambert Message-Id: <199901051818.LAA08069@usr02.primenet.com> Subject: Re: question about re-entrancy. To: wes@softweyr.com (Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?) Date: Tue, 5 Jan 1999 18:18:18 +0000 (GMT) Cc: tlambert@primenet.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <3691B82E.1D4E4B99@softweyr.com> from "Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?" at Jan 4, 99 11:58:54 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It's a lot of work, but it's not rocket science. The most > > complicated piece is the lock manager; to do it right, you need > > a five dimensional vector relationship (an arc describing the > > intersection of three two dimensional vectors: the lock list > > held by a locking entity, the hierarchical list of lockable objects, > > and the relationship between multiple locking entities within a > > single process -- threads within a process). > > If you wish to see a working example of a microkernel using object > locks, take a peek at the RTEMS kernel. It's quite portable, and > supports SMP systems out of the box. See > > http://www.oarcorp.com/rtems/rtems.html > > for information. RTEMS has three unfortunate problems: 1) It is not uITRON compliant. There's really no reason to do an RT system that isn't uITRON compliant. It's the industry standard, and there is a lot of code (including embedded browsers) that are available for such systems. 2) It's GPL'ed. That means that the source code can't be used to prepare derivative works that have any strategic value of any kind. I'm really surprised that it was possible to GPL something supported by a DARPA grant, given the governments technology transfer requirements for such grants, but there it is. The problem here is that embedded OS's are peculiar in that ROM'ing a browser at the same time you ROM a GPL'ed OS is a little more than "mere agregation". 3) Object locks are the wrong way to address the reentrancy issue. The problem with object locks is that it puts objects that don't really need to be in a contention domain into one in order to satisfy contention in what are usually very small critical sections having to do with list manipulation of pointers to the object. This type of thinking is why most Intel based SMP OS's claim that scaling past 4 processors is "useless". What they really mean is that their SMP OS is useless for more than 4 processors. Yeah, you have to have *some* object locks for non-reentrant objects (e.g., the I/O bus), but this is pretty much limited to physical hardware limits, and isn't really applicable for, for instance, vnodes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 10:48:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18951 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 10:48:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18943 for ; Tue, 5 Jan 1999 10:48:19 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA28443; Tue, 5 Jan 1999 11:47:53 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd028335; Tue Jan 5 11:47:44 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA10199; Tue, 5 Jan 1999 11:47:29 -0700 (MST) From: Terry Lambert Message-Id: <199901051847.LAA10199@usr02.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dyson@iquest.net Date: Tue, 5 Jan 1999 18:47:29 +0000 (GMT) Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901050437.XAA26494@y.dyson.net> from "John S. Dyson" at Jan 4, 99 11:37:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Also, the FreeBSD VFS/VM code already supports the ability to > > > have non-mapped buffers (and has for 2years.) There is alot in there that > > > might make the complexity look excessive, but that is only because there > > > are features in there that are almost ready to go. > > > > Actually, I think some of the tighness of VM system integration into > > the VFS code is a mistake. > > I think that since the amount of interaction needed is now understood, > a rearchitecting of the code would valuable. IMO, the VFS and VM code > need to be bound in very intimate ways, and most seperation between > the two is artificial. My guess is that it is probable that the efforts > had historically been split between VFS and VM, and the interfaces were > defined without both parties understanding the needs. Since that is > understood now, things should be reworked. Hmmm. I don't really buy this for the general case, which I believe is still stacking layers that don't access local media. For local media FS's, things which actially do I/O through a page fault, this is probably correct. The point in abstraction, however, is not artificial, unless you only consider one *BSD. If you want to leverage the total *BSD hacker base to do FS (or any other kind of) work such that it's applicable to your particular flavor of the month of *BSD, then you need that type of abstraction. I really think that the main FS work as time goes on will be in stacking layers, and not in local media FS's. Sure, there will be some architectural work to be done; seperation of directory hierarchy management from file object management from (probably) a low level variable granularity block store on which you could build a log structured or other kind of FS. Maybe a seperation of the soft updates dependency relationship code from the actual implementation using a registration mechanism, so that going forward you can implement transactioning as a stacking layer that asserts a dependency relationship and/or resolve dependencies implied between stacking layers (e.g. for ACL support). But the amount of things you can do solely within a stacking layer is amazing. You see glimmers of that stuff, either by following John Heidemann's student's work on compressing and cryptographic layers, or even in FreeBSD with some of the stuff Peter Wemm has reportedly been doing. Yeah, a local media FS is pretty intimate with the VM system, especially in the getpages/putpages area (and, if supported as a direct interface instead of a layer on top of the getpages/putpages, bmap). But that intimacy should be formally abstract. It's a real lesson on where the rough edges are to port the entire framework to another OS. I *really* recommend that people serious about FS work try it; there's almost enough data in the O'Reilly Windows 95 IFS book to actually do the work for Windows 95. The VFS should be as free of FreeBSD'isms as the VM system should be (and is) free of i386'isms. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 10:53:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19668 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 10:53:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19657 for ; Tue, 5 Jan 1999 10:52:59 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id NAA49947; Tue, 5 Jan 1999 13:56:40 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 13:56:40 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Terry Lambert cc: Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901051818.LAA08069@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Terry Lambert wrote: > 3) Object locks are the wrong way to address the reentrancy > issue. The problem with object locks is that it puts > objects that don't really need to be in a contention > domain into one in order to satisfy contention in what > are usually very small critical sections having to do > with list manipulation of pointers to the object. This > type of thinking is why most Intel based SMP OS's claim > that scaling past 4 processors is "useless". What they > really mean is that their SMP OS is useless for more > than 4 processors. Yeah, you have to have *some* object > locks for non-reentrant objects (e.g., the I/O bus), but > this is pretty much limited to physical hardware limits, > and isn't really applicable for, for instance, vnodes. Would it work if you had a thread per processor that allows requests for object manipulation to be put into a queue? You could queue requests to remove items from a list, and to allocate new ones. then you can keep a lock on the individual objects and not the entire list. Excuse niaveness, I haven't done anything in this area, I just love thinking about it. -Alfred > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 10:59:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20428 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 10:59:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20423 for ; Tue, 5 Jan 1999 10:59:36 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA02848; Tue, 5 Jan 1999 11:59:00 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd002763; Tue Jan 5 11:58:51 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA10934; Tue, 5 Jan 1999 11:58:44 -0700 (MST) From: Terry Lambert Message-Id: <199901051858.LAA10934@usr02.primenet.com> Subject: Re: psm0 on laptops. To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Tue, 5 Jan 1999 18:58:43 +0000 (GMT) Cc: avalon@coombs.anu.edu.au, mike@smith.net.au, hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp In-Reply-To: <199901051023.TAA20647@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at Jan 5, 99 07:23:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't know how the W*ndows PS/2 mouse driver can detect that a new > mouse has suddenly appeared at the PS/2 mouse port and switch to a > different protocol. You see, both the internal PS/2 mouse/pointing > device and the external device are wired to the same PS/2 mouse > port... If you have access to the Micorsoft DDK (Device Driver Kit), it contains the Microsoft mouse driver source code. Including the code that is used to probe serial ports for mice without mucking up modems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 11:26:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23782 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 11:26:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23606; Tue, 5 Jan 1999 11:25:45 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id TAA17799; Tue, 5 Jan 1999 19:19:35 +0100 (MET) Message-ID: <19990105191830.A17756@gvr.org> Date: Tue, 5 Jan 1999 19:19:35 +0100 From: Guido van Rooij To: freebsd-hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, core@FreeBSD.ORG Subject: i2c book Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got hold of the following book: Data Handbook IC12 I2C Peripherals This is issued by Philips and describes i2c capable peripheral IC's and has a small section on general i2c stuff. I have about 8 copies of the book and can send them to interested developpers of FreeBSD i2c stuff. It does not contain programming info on these chips, but just datasheets of stuf like: TV/VCR dual sounds procesors, LCD controllers DACs, MPEG2 encoders, DTMF/modem/music tone generators etc etc. If you're interested, send a snail-mail address to me. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 11:34:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24730 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 11:34:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24725 for ; Tue, 5 Jan 1999 11:34:48 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA05460; Tue, 5 Jan 1999 12:34:09 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd005416; Tue Jan 5 12:34:07 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA13521; Tue, 5 Jan 1999 12:34:06 -0700 (MST) From: Terry Lambert Message-Id: <199901051934.MAA13521@usr02.primenet.com> Subject: Re: question about re-entrancy. To: bright@hotjobs.com (Alfred Perlstein) Date: Tue, 5 Jan 1999 19:34:06 +0000 (GMT) Cc: tlambert@primenet.com, wes@softweyr.com, hackers@FreeBSD.ORG In-Reply-To: from "Alfred Perlstein" at Jan 5, 99 01:56:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Would it work if you had a thread per processor that allows requests > for object manipulation to be put into a queue? You could queue requests > to remove items from a list, and to allocate new ones. then you > can keep a lock on the individual objects and not the entire list. Sure. But then you'd have to lock the queue object while putting things on or taking things off. 8-). > Excuse niaveness, I haven't done anything in this area, I just love > thinking about it. I think the best way of thinking of the problem is an analogy that someone told me years ago: Think of the CPU's in an SMP system as spiders crawling over the code; the more CPU's, the more spiders. Most of the code is black; it doesn't matter how many spiders are crawling ove it at the same time. Some spots in the code are red, where global lists or singular objects are being manipulated. These are weak spots in the code that can only support the weight of one spider at a time. Maybe they are a result of weak spots in the hardware (e.g., you can't have multiple CPU's issuing INB/OUTB commands such that the agregate rate exceeds the ability of the bus). Think of how you would design an OS to minimise the percentage of red vs. black. At the same time, don't make it do that the only route between black areas is a red area, if you can avoid it, or your red minimization will result in a spider traffic jam (e.g., how would hou run the keyboard driver on one CPU and the PS/2 mouse driver on another CPU and make sure the delay for the LED setting still worked?). The job is to keep all of the spider's busy, instead of lined up to cross the same weak spot. Now think of the absolutely minimal, lowest overhead method you could use to keep the spiders from running into each other in the red areas. Try to not add any overhead at all for spiders in the black areas. That's high granularity SMP. Right now, the entire FreeBSD kernel is treated as if it were red; the same for Linux. For Solaris and SVR4, all of the kernel data objects and maybe a quarter of the kernel code is treated as if it were red. For Dynix (Sequent's old BSD based OS), all of the object manipulation code is black, except when a spider has to go back to the system well to empty or fill a bucket, or when you switch spiders. 8-). Then come the questions: What are the ramifications of each spider having it's own stack? How would you implement virtual spiders (kernel threads)? Would you assign stacks to virtual spiders, too, or only to real spiders? Why? How would you guarantee that there would be a spider when something important needed one (RT support)? How would you minimize the amount of non-work movement that spiders had to do (CPU affinity, cache preservation)? How would you maximize the number of free spiders working on the same area (SMP scalability, highest possible concurrency)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 11:47:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26580 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 11:47:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26572 for ; Tue, 5 Jan 1999 11:47:02 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA16516; Tue, 5 Jan 1999 12:46:09 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA09199; Tue, 5 Jan 1999 12:46:08 -0700 Date: Tue, 5 Jan 1999 12:46:08 -0700 Message-Id: <199901051946.MAA09199@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: wes@softweyr.com (Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?), bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901051818.LAA08069@usr02.primenet.com> References: <3691B82E.1D4E4B99@softweyr.com> <199901051818.LAA08069@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you wish to see a working example of a microkernel using object > > locks, take a peek at the RTEMS kernel. It's quite portable, and > > supports SMP systems out of the box. See > > > > http://www.oarcorp.com/rtems/rtems.html > > RTEMS has three unfortunate problems: > > 1) It is not uITRON compliant. There's really no reason to > do an RT system that isn't uITRON compliant. It's the > industry standard, and there is a lot of code (including > embedded browsers) that are available for such systems. I looked up UITron on the WWW, and only got a hit from Sun, and it was lost in the noise. I have a hard time seeing this as 'Industry Standard', but I'm sure you'll feel free to explain to me how it's a standard. > 2) It's GPL'ed. I'll leave this one... > 3) Object locks are the wrong way to address the reentrancy > issue. Sometime I wonder if you just like to listen to yourself speak. Object locks *ARE* the correct way to address reentrancy issues. Having done *real* multithreaded/multi-object design for some time now, I've found that Object locks are a *much* cleaner way of designing for re-entrant code. (If you don't want something locked, you don't create an object for it...) How much *REAL* (stuff that is used by someone outside yourself) experience do you have designing multi'threaded/whatever' software to speak with such authority? > The problem with object locks is that it puts > objects that don't really need to be in a contention > domain into one in order to satisfy contention in what > are usually very small critical sections having to do > with list manipulation of pointers to the object. So you're claiming that the 'Big Giant Lock' is the better way? You can't have it both ways. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 11:55:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27910 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 11:55:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27905 for ; Tue, 5 Jan 1999 11:55:53 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA00571; Tue, 5 Jan 1999 12:55:22 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd000444; Tue Jan 5 12:55:17 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA18014; Tue, 5 Jan 1999 12:54:57 -0700 (MST) From: Terry Lambert Message-Id: <199901051954.MAA18014@usr08.primenet.com> Subject: Re: PnP PCI modem To: sthaug@nethelp.no Date: Tue, 5 Jan 1999 19:54:56 +0000 (GMT) Cc: jamie@itribe.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <14757.915110288@verdi.nethelp.no> from "sthaug@nethelp.no" at Dec 31, 98 02:18:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So, does this mean motherboards with a decent number of PCI slots will > > start appearing? > > I wouldn't count on it - I think it's more likely that you'll see more > USB equipment. > > AFAIK it's rather difficult electrically to have more than five slots in > one PCI bus. Thus if you need more, you'll need a system with more than > one system bus to PCI bridge. Thus higher cost, lower volume. This is a current issue, and is related to the chipset. Apple has a good PCI chipset, as does DEC; I believe both support 6 slots without a bridge because they have seperate lines for 6 slots. The Intel chips tend to have only 4 lines; some motherboard manufacturers double up one of the lines to get 5 slots. I suspect you could double up some of the lines on the DEC chip; don't know about the Apple. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:00:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28410 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:00:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ime.net (ime.net [209.90.192.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28349 for ; Tue, 5 Jan 1999 11:59:58 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4033.ime.net [209.90.195.43]) by ime.net (8.8.7/8.8.7) with SMTP id OAA24936; Tue, 5 Jan 1999 14:59:03 -0500 (EST) Message-Id: <4.1.19990105145650.00bf39d0@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Jan 1999 14:58:17 -0500 To: Terry Lambert , sthaug@nethelp.no From: Drew Baxter Subject: Re: PnP PCI modem Cc: jamie@itribe.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901051954.MAA18014@usr08.primenet.com> References: <14757.915110288@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 07:54 PM 1/5/99 +0000, Terry Lambert wrote: >> > So, does this mean motherboards with a decent number of PCI slots will >> > start appearing? >> >> I wouldn't count on it - I think it's more likely that you'll see more >> USB equipment. >> >> AFAIK it's rather difficult electrically to have more than five slots in >> one PCI bus. Thus if you need more, you'll need a system with more than >> one system bus to PCI bridge. Thus higher cost, lower volume. > >This is a current issue, and is related to the chipset. > >Apple has a good PCI chipset, as does DEC; I believe both support >6 slots without a bridge because they have seperate lines for 6 >slots. The Intel chips tend to have only 4 lines; some motherboard >manufacturers double up one of the lines to get 5 slots. I suspect >you could double up some of the lines on the DEC chip; don't know >about the Apple. There are boards out there with 7 PCI slots that run Pentium II's. If I remember right ASUS makes one, but don't quote me on that. It's very likely it isn't using an Intel 440 chipset at all though, probably some other company (BTC)? I find this board more practical now than I would say 2 years ago.. Because 2 years ago I still had a lot of ISA hardware. The only thing ISA now is my Sound Blaster AWE32. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:07:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29154 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:07:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29148 for ; Tue, 5 Jan 1999 12:07:29 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA00493; Tue, 5 Jan 1999 12:04:07 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901052004.MAA00493@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-reply-to: Your message of "Tue, 05 Jan 1999 18:18:18 GMT." <199901051818.LAA08069@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jan 1999 12:04:07 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 2) It's GPL'ed. That means that the source code can't be > used to prepare derivative works that have any strategic > value of any kind. I'm really surprised that it was > possible to GPL something supported by a DARPA grant, > given the governments technology transfer requirements > for such grants, but there it is. The problem here is > that embedded OS's are peculiar in that ROM'ing a browser > at the same time you ROM a GPL'ed OS is a little more > than "mere agregation". Actually, it's not really GPL'ed, and in fact its license status is extremely dubious, as it contains BSD code (the TCP/IP stack) which conflicts with the GPL. There is also a specific clause in the license which waives the linkage pollution avenue. This is one of the bad things about RTEMS. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:08:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29319 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:08:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29307 for ; Tue, 5 Jan 1999 12:08:42 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id WAA07283; Tue, 5 Jan 1999 22:07:20 +0200 (EET) Date: Tue, 5 Jan 1999 22:07:19 +0200 (EET) From: Narvi To: Nate Williams cc: Terry Lambert , Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901051946.MAA09199@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [snip] > > The problem with object locks is that it puts > > objects that don't really need to be in a contention > > domain into one in order to satisfy contention in what > > are usually very small critical sections having to do > > with list manipulation of pointers to the object. > > So you're claiming that the 'Big Giant Lock' is the better way? You > can't have it both ways. > > > > Nate The third way (about which Terry did talk) is to have locks around critical sections. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:09:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29433 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:09:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29423 for ; Tue, 5 Jan 1999 12:09:47 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA16705; Tue, 5 Jan 1999 13:08:49 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA09332; Tue, 5 Jan 1999 13:08:47 -0700 Date: Tue, 5 Jan 1999 13:08:47 -0700 Message-Id: <199901052008.NAA09332@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Narvi Cc: Nate Williams , Terry Lambert , Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: References: <199901051946.MAA09199@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [snip] > > > > The problem with object locks is that it puts > > > objects that don't really need to be in a contention > > > domain into one in order to satisfy contention in what > > > are usually very small critical sections having to do > > > with list manipulation of pointers to the object. > > > > So you're claiming that the 'Big Giant Lock' is the better way? You > > can't have it both ways. > > > > > > > > Nate > > The third way (about which Terry did talk) is to have locks around > critical sections. That *is* what an 'object lock' in RTEMS is. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:15:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00430 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:15:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA00425 for ; Tue, 5 Jan 1999 12:15:12 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 23141 invoked by uid 1001); 5 Jan 1999 20:14:39 +0000 (GMT) To: netmonger@genesis.ispace.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PnP PCI modem In-Reply-To: Your message of "Tue, 05 Jan 1999 14:58:17 -0500" References: <4.1.19990105145650.00bf39d0@genesis.ispace.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 05 Jan 1999 21:14:38 +0100 Message-ID: <23139.915567278@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There are boards out there with 7 PCI slots that run Pentium II's. If I > remember right ASUS makes one, but don't quote me on that. It's very > likely it isn't using an Intel 440 chipset at all though, probably some > other company (BTC)? I find this board more practical now than I would say > 2 years ago.. Because 2 years ago I still had a lot of ISA hardware. The > only thing ISA now is my Sound Blaster AWE32. I only found an Asus board with 6 PCI slots, the P2B-D2. And the reason it has 6 slots is because this is an I2O board. (As Asus says in their specifications: 3 primary 32-bit PCI and 3 secondary PCI slots). 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 Tue Jan 5 12:22:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01570 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:22:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ime.net (ime.net [209.90.192.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01563 for ; Tue, 5 Jan 1999 12:22:29 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4033.ime.net [209.90.195.43]) by ime.net (8.8.7/8.8.7) with SMTP id PAA01326; Tue, 5 Jan 1999 15:21:52 -0500 (EST) Message-Id: <4.1.19990105151903.00bcd230@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Jan 1999 15:21:00 -0500 To: sthaug@nethelp.no From: Drew Baxter Subject: Re: PnP PCI modem Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <23139.915567278@verdi.nethelp.no> References: <4.1.19990105145650.00bf39d0@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:14 PM 1/5/99 +0100, sthaug@nethelp.no wrote: >> There are boards out there with 7 PCI slots that run Pentium II's. If I >> remember right ASUS makes one, but don't quote me on that. It's very >> likely it isn't using an Intel 440 chipset at all though, probably some >> other company (BTC)? I find this board more practical now than I would say >> 2 years ago.. Because 2 years ago I still had a lot of ISA hardware. The >> only thing ISA now is my Sound Blaster AWE32. > >I only found an Asus board with 6 PCI slots, the P2B-D2. And the reason >it has 6 slots is because this is an I2O board. (As Asus says in their >specifications: 3 primary 32-bit PCI and 3 secondary PCI slots). That could be it.. I'd have to do some digging. I don't see me migrating to another board anytime soon.. I'd probably put another Supermicro board in to replace this P6DBS either way. This is 4-3.. Although if I remember correctly one of my Biostar Pentium boards was 5-3, which was with 1 secondary. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:32:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03306 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:32:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03301 for ; Tue, 5 Jan 1999 12:32:13 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id PAA39633; Tue, 5 Jan 1999 15:31:22 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199901052031.PAA39633@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Drew Baxter cc: Terry Lambert , sthaug@nethelp.no, jamie@itribe.net, freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: PnP PCI modem References: <14757.915110288@verdi.nethelp.no> <4.1.19990105145650.00bf39d0@genesis.ispace.com> In-reply-to: Your message of "Tue, 05 Jan 1999 14:58:17 EST." <4.1.19990105145650.00bf39d0@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jan 1999 15:31:21 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 07:54 PM 1/5/99 +0000, Terry Lambert wrote: > >> > So, does this mean motherboards with a decent number of PCI slots will > >> > start appearing? > >> > >> I wouldn't count on it - I think it's more likely that you'll see more > >> USB equipment. > >> > >> AFAIK it's rather difficult electrically to have more than five slots in > >> one PCI bus. Thus if you need more, you'll need a system with more than > >> one system bus to PCI bridge. Thus higher cost, lower volume. > > > >This is a current issue, and is related to the chipset. > > > >Apple has a good PCI chipset, as does DEC; I believe both support > >6 slots without a bridge because they have seperate lines for 6 > >slots. The Intel chips tend to have only 4 lines; some motherboard > >manufacturers double up one of the lines to get 5 slots. I suspect > >you could double up some of the lines on the DEC chip; don't know > >about the Apple. > > There are boards out there with 7 PCI slots that run Pentium II's. If I > remember right ASUS makes one, but don't quote me on that. It's very > likely it isn't using an Intel 440 chipset at all though, probably some > other company (BTC)? I find this board more practical now than I would say > 2 years ago.. Because 2 years ago I still had a lot of ISA hardware. The > only thing ISA now is my Sound Blaster AWE32. > The slot limitiation is mostly an electrical issue, having to do with bus loading issues. The PCI spec (which I don't have handy at the moment) presumes a certain number of loads; you have to count the devices on the card as well as the rather crummy connectors used. This is one reason why CompactPCI systems with their eurocard-style bus connectors can have more slots per PCI bus - the high quality connections present less of a capacitance load on the bus. I think that most AT-style boards with more than 3 or 4 PCI slots have some of the slots behind a PCI bridge, so it's really two busses. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:34:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03490 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:34:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03485 for ; Tue, 5 Jan 1999 12:34:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id UAA13116; Tue, 5 Jan 1999 20:33:43 GMT Date: Tue, 5 Jan 1999 20:33:43 +0000 (GMT) From: Doug Rabson To: Terry Lambert cc: sthaug@nethelp.no, jamie@itribe.net, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP PCI modem In-Reply-To: <199901051954.MAA18014@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Terry Lambert wrote: > > > So, does this mean motherboards with a decent number of PCI slots will > > > start appearing? > > > > I wouldn't count on it - I think it's more likely that you'll see more > > USB equipment. > > > > AFAIK it's rather difficult electrically to have more than five slots in > > one PCI bus. Thus if you need more, you'll need a system with more than > > one system bus to PCI bridge. Thus higher cost, lower volume. > > This is a current issue, and is related to the chipset. > > Apple has a good PCI chipset, as does DEC; I believe both support > 6 slots without a bridge because they have seperate lines for 6 > slots. The Intel chips tend to have only 4 lines; some motherboard > manufacturers double up one of the lines to get 5 slots. I suspect > you could double up some of the lines on the DEC chip; don't know > about the Apple. Not sure about Apple but the Dec alpha box which I have (with 6 slots) uses a pci-pci bridge. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 12:41:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04493 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 12:41:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04487 for ; Tue, 5 Jan 1999 12:41:41 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id WAA07535; Tue, 5 Jan 1999 22:40:47 +0200 (EET) Date: Tue, 5 Jan 1999 22:40:47 +0200 (EET) From: Narvi To: Nate Williams cc: Terry Lambert , Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052008.NAA09332@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Nate Williams wrote: > > [snip] > > > > > > The problem with object locks is that it puts > > > > objects that don't really need to be in a contention > > > > domain into one in order to satisfy contention in what > > > > are usually very small critical sections having to do > > > > with list manipulation of pointers to the object. > > > > > > So you're claiming that the 'Big Giant Lock' is the better way? You > > > can't have it both ways. > > > > > > > > > > > > Nate > > > > The third way (about which Terry did talk) is to have locks around > > critical sections. > > That *is* what an 'object lock' in RTEMS is. > An "object lock" is a lock associated with some object. In order to access the object, you acquire the lock. A "critical section" lock is a lock associated with a certain critical section of code. In order to enter that specific section of code, you acquire the lock. As far as I can see they aren't the same, even though they can be combined and/or mixed. > > Nate > Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 13:05:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08069 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 13:05:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from epistolic.cynic.net (epistolic.cynic.net [199.175.137.136]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08062 for ; Tue, 5 Jan 1999 13:05:13 -0800 (PST) (envelope-from cjs@cynic.net) Received: from localhost (localhost [[UNIX: localhost]]) by epistolic.cynic.net (8.9.1a/8.9.1) with SMTP id NAA15527; Tue, 5 Jan 1999 13:02:12 -0800 (PST) Date: Tue, 5 Jan 1999 13:02:11 -0800 (PST) From: Curt Sampson To: Joe Abley cc: Benedikt Stockebrand , Yani Brankov , "Stephen J. Roznowski" , hackers@FreeBSD.ORG Subject: Re: Why is root's crontab different? In-Reply-To: <19990106002259.B6168@clear.co.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, Joe Abley wrote: > Turning your argument around, if it _is_ desirable to have crontabs available > with a minimal number of filesystems mounted, why not move /var/cron to > /etc/cron and dispense with /etc/crontab? It's not as if crontabs are so > variably-sized to really merit living in /var. In fact, we're about to do that in NetBSD. The log file (previously in /var/cron/log) will be moved to /var/log/cron. The reasoning behind this is that crontabs are one of the few `permanent' pieces of information in /var. If you lose var you lose at jobs, mail, various queued stuff (uucp, printer, etc.), it's true. But if you just drop in /var from the distribution sets, your system should still keep running as it did before in the long run. So moving the cron jobs out means you don't *have* to back up var in the way that you *have* to back up /etc. cjs -- Curt Sampson 604 801 5335 De gustibus, aut bene aut nihil. The most widely ported operating system in the world: http://www.netbsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 13:13:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08970 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 13:13:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08963 for ; Tue, 5 Jan 1999 13:12:58 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA16996; Tue, 5 Jan 1999 13:43:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA09607; Tue, 5 Jan 1999 13:43:35 -0700 Date: Tue, 5 Jan 1999 13:43:35 -0700 Message-Id: <199901052043.NAA09607@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Narvi Cc: Nate Williams , Terry Lambert , Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=? , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: References: <199901052008.NAA09332@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > [snip] > > > > > > > > The problem with object locks is that it puts > > > > > objects that don't really need to be in a contention > > > > > domain into one in order to satisfy contention in what > > > > > are usually very small critical sections having to do > > > > > with list manipulation of pointers to the object. > > > > > > > > So you're claiming that the 'Big Giant Lock' is the better way? You > > > > can't have it both ways. > > > > > > > > > > > > > > > > Nate > > > > > > The third way (about which Terry did talk) is to have locks around > > > critical sections. > > > > That *is* what an 'object lock' in RTEMS is. > > > > An "object lock" is a lock associated with some object. In order to access > the object, you acquire the lock. > > A "critical section" lock is a lock associated with a certain critical > section of code. In order to enter that specific section of code, you > acquire the lock. A 'critical section of code' is a portion of the code that is accessing a shared resource, which can be protected by using an object lock. Or, better put you 'aquire a lock' before you enter the 'critical section' and 'release the lock' after you leave the critical section. (semaphores). Like I said, it's the same thing, just different terminology. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 13:31:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11555 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 13:31:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from silver.gn.iaf.nl (silver.gn.iaf.nl [193.67.144.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11517 for ; Tue, 5 Jan 1999 13:30:52 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by silver.gn.iaf.nl (8.8.8/8.8.8) with SMTP id WAA05899; Tue, 5 Jan 1999 22:30:20 +0100 Received: by uni4nn.gn.iaf.nl with UUCP id AA01801 (5.67b/IDA-1.5); Tue, 5 Jan 1999 22:19:11 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA14694; Tue, 5 Jan 1999 21:20:05 +0100 (CET) From: Wilko Bulte Message-Id: <199901052020.VAA14694@yedi.iaf.nl> Subject: Re: comments on de driver error message? In-Reply-To: <199812290433.XAA21465@pcnet1.pcnet.com> from Daniel Eischen at "Dec 28, 98 11:33:53 pm" To: eischen@vigrid.com (Daniel Eischen) Date: Tue, 5 Jan 1999 21:20:05 +0100 (CET) Cc: FreeBSD-hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Daniel Eischen wrote... Well, like I wrote last week I now have tested the whole thing with all known-good cables. Result: works much better. 2 CRC errors after 2 days of make world-ing from two different machine hammering on the same NFS server box. After taking a closer look I found that the wiring of the original cables is not correct. They have 4 wire pairs straight-thru, so 2 adjacent pins are a pair. This is not what 10[0]baseT is spec-ed... So, next step will be to borrow a crimptool and put new plugs on the cables. Thanks for helping Wilko > > de0: receive: 00:00:f8:06:07:f5: bad crc > > de0: receive: 00:00:f8:06:ab:1f: alignment error > > > > ? > > > > This is 2.2.6R on a Kingston10/100 PCI card, but I also see it on DEC DE500 > > cards in my other machines (one Pentium 100, one Alpha AXPpci33). The P100 > > and the Alpha are (almost) -current. > > We were also getting messages like this out of the de driver. > The problem turned out to be a faulty cable on one of the > other systems in our network. Hunt down the machines with > Ethernet addresses 00:00:f8:06:07:f5 and 00:00:f8:06:ab:1f > and try replacing their cables. > > Dan Eischen > eischen@vigrid.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 13:59:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17032 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 13:59:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp-gw.BayNetworks.COM (ns5.baynetworks.com [194.133.90.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17027 for ; Tue, 5 Jan 1999 13:59:13 -0800 (PST) (envelope-from bwithrow@BayNetworks.COM) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/10/10-E) with ESMTP id WAA29823; Tue, 5 Jan 1999 22:43:43 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id QAA10494; Tue, 5 Jan 1999 16:43:18 -0500 (EST) Received: from tuva.engeast.baynetworks.com (tuva [192.32.68.38]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id QAA03242; Tue, 5 Jan 1999 16:43:17 -0500 for Received: from tuva.engeast.baynetworks.com (localhost [127.0.0.1]) by tuva.engeast.baynetworks.com (8.8.8/8.8.8) with ESMTP id VAA15097; Tue, 5 Jan 1999 21:43:09 GMT (envelope-from bwithrow@tuva.engeast.baynetworks.com) Message-Id: <199901052143.VAA15097@tuva.engeast.baynetworks.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG cc: witr@rwwa.com, bwithrow@BayNetworks.COM Subject: 3.0-REL NFS interop problems redux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jan 1999 16:43:09 -0500 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I whined before about my problem where a specific NFS mount goes deaf on me for a period of time and then wakes up later. I said that I would sniff out the problem... Well I finally got my office set up so that I could get a sniffer to capture the session and I have that capture (about 600 packets). I've looked at it and I can see where it goes wrong, but I can't see *why* it is wrong. I'm wondering if there is an NFS hacker who can work with me on this. To recap, I'm using 3.0_REL but I have replaced the amutils with the latest beta of amutils (which fixes a number of amd-related problems in 3.0-REL). I log into a virtual console and I can access my (nfs-mounted, automounted) home directory. I then log into an XDM session and the login hangs accessing my home directory. If I switch back to the VT session I *also* hang accessing my home directory. The mount will "wake up" on the order of 10 minutes later. This problems is completely repeatable, with the caveat that it only happens *once* for every time I boot my machine. Even if I allow the mount of my home directory to time out the problem will *not* occur unless the system is re-booted. My home directory is served by a NAC box version 4.2a. I sniffed the wire as I logged into the XDM session and I see: Frame Delta T Length Dir Dest Address Source Address [lots deleted] 553 0.001 90 NA 192.32.68.39 192.32.61.8 554 0.000 182 NA 192.32.61.8 192.32.68.39 555 0.001 170 NA 192.32.68.39 192.32.61.8 556 0.000 166 NA 192.32.61.8 192.32.68.39 557 0.001 90 NA 192.32.68.39 192.32.61.8 558 0.655 849 NA 192.32.61.8 192.32.68.39 559 2.030 849 NA 192.32.61.8 192.32.68.39 560 4.050 885 NA 192.32.61.8 192.32.68.39 561 5.919 90 NA 192.32.72.6 192.32.68.39 562 0.004 90 NA 192.32.68.39 192.32.72.6 563 0.975 82 NA 192.32.61.8 192.32.68.39 And nothing much more happens until the mount wakes up. My workstation is 192.32.68.39 and the server is 192.32.61.8. The problem seems to begin with packets 558, 559, and 560. Full trace available upon request. Details of these packets follow: Frame 558 Date and Time: 04-Jan-99 00:05:43.606 Ethernet Header byte 0 Destination 00:00:a2:c3:39:74 48 bits Bay Networks Source 00:a0:24:97:82:2e 48 bits Ethertype 0x800 16 bits IP Header (Internet Protocol) byte 14 Version IP 4 bits Header Length 5 32-bit words 4 bits Precedence ROUTINE 3 bits Type of Service NORMAL_SERVICE 4 bits Unused 0 1 bits Total Length 1120 bytes 16 bits Identification 3589 16 bits Flags, Unused 0 1 bits Flags, DF bit MAY_FRAGMENT 1 bits Flags, MF bit LAST_FRAGMENT 1 bits Fragment Offset 0 * 8 octets 13 bits Time To Live 64 seconds/hops 8 bits Protocol UDP 8 bits Checksum 0x6718 16 bits Source Address 192.32.68.39 32 bits Destination Address 192.32.61.8 32 bits UDP Header byte 34 Source Port 0x34d 16 bits Destination Port 0x801 16 bits Length 1100 bytes 16 bits Checksum 0xda23 16 bits DATA byte 42 0: 176bdcd6 00000000 00000002 000186a3 .k.............. 10: 00000002 00000008 00000001 00000034 ...............4 20: 00000000 00000000 00000b0c 00000014 ................ 30: 00000008 00000014 00000000 00000038 ...............8 40: 0000008c 00000037 00000025 000000aa .......7...%.... 50: 000000cc 00000000 00000000 4b1f1a00 ............K... 60: af2ed92b 00000000 5fdc0d00 cc058023 ...+...._......# 70: 00000000 01ae0500 9c280800 00000000 .........(...... 80: 00000000 000003b8 000003b8 00000004 ................ 90: c0204427 00013000 124d4954 2d4d4147 . D'..0..MIT-MAG a0: 49432d43 4f4f4b49 452d3100 102c493e IC-COOKIE-1..,I> b0: 582b6a2f 21280d77 191b183c 18010000 X+j/!(.w...<.... c0: 1d6b797a 796c2e65 6e676561 73742e62 .kyzyl.engeast.b d0: 61796e65 74776f72 6b732e63 6f6d0001 aynetworks.com.. e0: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO f0: 4b49452d 3100102c 493e582b 6a2f2128 KIE-1..,I>X+j/!( 100: 0d77191b 183c1800 000004c0 20442600 .w...<...... D&. 110: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 120: 4f4b4945 2d310010 07397b42 622b2626 OKIE-1...9{Bb+&& 130: 5a03084c 31176e1a 0100001c 74757661 Z..L1.n.....tuva 140: 2e656e67 65617374 2e626179 6e657477 .engeast.baynetw 150: 6f726b73 2e636f6d 00013000 124d4954 orks.com..0..MIT 160: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 170: 1007397b 42622b26 265a0308 4c31176e ..9{Bb+&&Z..L1.n 180: 1a000000 04c0208a 7f000131 00124d49 ...... ....1..MI 190: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 1a0: 0010b6be 63a75d1a 03b0dbef b9d7c6ed ....c.]......... 1b0: 5b5f0100 000a7373 682d7365 72766572 [_....ssh-server 1c0: 00013100 124d4954 2d4d4147 49432d43 ..1..MIT-MAGIC-C 1d0: 4f4f4b49 452d3100 10b6be63 a75d1a03 OOKIE-1....c.].. 1e0: b0dbefb9 d7c6ed5b 5f000000 04c0208a .......[_..... . 1f0: 7f000132 00124d49 542d4d41 4749432d ...2..MIT-MAGIC- 200: 434f4f4b 49452d31 00103574 88e4473e COOKIE-1..5t..G> 210: a48fcaad 49db7962 be870100 000a7373 ....I.yb......ss 220: 682d7365 72766572 00013200 124d4954 h-server..2..MIT 230: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 240: 10357488 e4473ea4 8fcaad49 db7962be .5t..G>....I.yb. 250: 87000000 04c02006 fb000130 00124d49 ...... ....0..MI 260: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 270: 00101e41 8142d1fb 8c099bc6 8edf3d35 ...A.B........=5 280: c4570100 00086465 6c6f7265 616e0001 .W....delorean.. 290: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO 2a0: 4b49452d 310010c7 61e4ada4 c7d59f4d KIE-1...a......M 2b0: 7fbee210 020ded00 000004c0 20066900 ............ .i. 2c0: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 2d0: 4f4b4945 2d310010 ca22b5ea 9a06aa85 OKIE-1..."...... 2e0: 6f0aab8d 6dba92c0 01000005 726f6269 o...m.......robi 2f0: 6e000130 00124d49 542d4d41 4749432d n..0..MIT-MAGIC- 300: 434f4f4b 49452d31 00103458 53d66775 COOKIE-1..4XS.gu 310: 952a1b66 7c9f1a16 63d20000 0004c020 .*.f|...c...... 320: 06910001 3000c0 ....0.. Frame 559 Date and Time: 04-Jan-99 00:05:45.636 Ethernet Header byte 0 Destination 00:00:a2:c3:39:74 48 bits Bay Networks Source 00:a0:24:97:82:2e 48 bits Ethertype 0x800 16 bits IP Header (Internet Protocol) byte 14 Version IP 4 bits Header Length 5 32-bit words 4 bits Precedence ROUTINE 3 bits Type of Service NORMAL_SERVICE 4 bits Unused 0 1 bits Total Length 1120 bytes 16 bits Identification 3590 16 bits Flags, Unused 0 1 bits Flags, DF bit MAY_FRAGMENT 1 bits Flags, MF bit LAST_FRAGMENT 1 bits Fragment Offset 0 * 8 octets 13 bits Time To Live 64 seconds/hops 8 bits Protocol UDP 8 bits Checksum 0x6717 16 bits Source Address 192.32.68.39 32 bits Destination Address 192.32.61.8 32 bits UDP Header byte 34 Source Port 0x34d 16 bits Destination Port 0x801 16 bits Length 1100 bytes 16 bits Checksum 0xda23 16 bits DATA byte 42 0: 176bdcd6 00000000 00000002 000186a3 .k.............. 10: 00000002 00000008 00000001 00000034 ...............4 20: 00000000 00000000 00000b0c 00000014 ................ 30: 00000008 00000014 00000000 00000038 ...............8 40: 0000008c 00000037 00000025 000000aa .......7...%.... 50: 000000cc 00000000 00000000 4b1f1a00 ............K... 60: af2ed92b 00000000 5fdc0d00 cc058023 ...+...._......# 70: 00000000 01ae0500 9c280800 00000000 .........(...... 80: 00000000 000003b8 000003b8 00000004 ................ 90: c0204427 00013000 124d4954 2d4d4147 . D'..0..MIT-MAG a0: 49432d43 4f4f4b49 452d3100 102c493e IC-COOKIE-1..,I> b0: 582b6a2f 21280d77 191b183c 18010000 X+j/!(.w...<.... c0: 1d6b797a 796c2e65 6e676561 73742e62 .kyzyl.engeast.b d0: 61796e65 74776f72 6b732e63 6f6d0001 aynetworks.com.. e0: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO f0: 4b49452d 3100102c 493e582b 6a2f2128 KIE-1..,I>X+j/!( 100: 0d77191b 183c1800 000004c0 20442600 .w...<...... D&. 110: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 120: 4f4b4945 2d310010 07397b42 622b2626 OKIE-1...9{Bb+&& 130: 5a03084c 31176e1a 0100001c 74757661 Z..L1.n.....tuva 140: 2e656e67 65617374 2e626179 6e657477 .engeast.baynetw 150: 6f726b73 2e636f6d 00013000 124d4954 orks.com..0..MIT 160: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 170: 1007397b 42622b26 265a0308 4c31176e ..9{Bb+&&Z..L1.n 180: 1a000000 04c0208a 7f000131 00124d49 ...... ....1..MI 190: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 1a0: 0010b6be 63a75d1a 03b0dbef b9d7c6ed ....c.]......... 1b0: 5b5f0100 000a7373 682d7365 72766572 [_....ssh-server 1c0: 00013100 124d4954 2d4d4147 49432d43 ..1..MIT-MAGIC-C 1d0: 4f4f4b49 452d3100 10b6be63 a75d1a03 OOKIE-1....c.].. 1e0: b0dbefb9 d7c6ed5b 5f000000 04c0208a .......[_..... . 1f0: 7f000132 00124d49 542d4d41 4749432d ...2..MIT-MAGIC- 200: 434f4f4b 49452d31 00103574 88e4473e COOKIE-1..5t..G> 210: a48fcaad 49db7962 be870100 000a7373 ....I.yb......ss 220: 682d7365 72766572 00013200 124d4954 h-server..2..MIT 230: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 240: 10357488 e4473ea4 8fcaad49 db7962be .5t..G>....I.yb. 250: 87000000 04c02006 fb000130 00124d49 ...... ....0..MI 260: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 270: 00101e41 8142d1fb 8c099bc6 8edf3d35 ...A.B........=5 280: c4570100 00086465 6c6f7265 616e0001 .W....delorean.. 290: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO 2a0: 4b49452d 310010c7 61e4ada4 c7d59f4d KIE-1...a......M 2b0: 7fbee210 020ded00 000004c0 20066900 ............ .i. 2c0: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 2d0: 4f4b4945 2d310010 ca22b5ea 9a06aa85 OKIE-1..."...... 2e0: 6f0aab8d 6dba92c0 01000005 726f6269 o...m.......robi 2f0: 6e000130 00124d49 542d4d41 4749432d n..0..MIT-MAGIC- 300: 434f4f4b 49452d31 00103458 53d66775 COOKIE-1..4XS.gu 310: 952a1b66 7c9f1a16 63d20000 0004c020 .*.f|...c...... 320: 06910001 3000c0 ....0.. Frame 560 Date and Time: 04-Jan-99 00:05:49.686 Ethernet Header byte 0 Destination 00:00:a2:c3:39:74 48 bits Bay Networks Source 00:a0:24:97:82:2e 48 bits Ethertype 0x800 16 bits IP Header (Internet Protocol) byte 14 Version IP 4 bits Header Length 5 32-bit words 4 bits Precedence ROUTINE 3 bits Type of Service NORMAL_SERVICE 4 bits Unused 0 1 bits Total Length 1120 bytes 16 bits Identification 3591 16 bits Flags, Unused 0 1 bits Flags, DF bit MAY_FRAGMENT 1 bits Flags, MF bit LAST_FRAGMENT 1 bits Fragment Offset 0 * 8 octets 13 bits Time To Live 64 seconds/hops 8 bits Protocol UDP 8 bits Checksum 0x6716 16 bits Source Address 192.32.68.39 32 bits Destination Address 192.32.61.8 32 bits UDP Header byte 34 Source Port 0x34d 16 bits Destination Port 0x801 16 bits Length 1100 bytes 16 bits Checksum 0xda23 16 bits DATA byte 42 0: 176bdcd6 00000000 00000002 000186a3 .k.............. 10: 00000002 00000008 00000001 00000034 ...............4 20: 00000000 00000000 00000b0c 00000014 ................ 30: 00000008 00000014 00000000 00000038 ...............8 40: 0000008c 00000037 00000025 000000aa .......7...%.... 50: 000000cc 00000000 00000000 4b1f1a00 ............K... 60: af2ed92b 00000000 5fdc0d00 cc058023 ...+...._......# 70: 00000000 01ae0500 9c280800 00000000 .........(...... 80: 00000000 000003b8 000003b8 00000004 ................ 90: c0204427 00013000 124d4954 2d4d4147 . D'..0..MIT-MAG a0: 49432d43 4f4f4b49 452d3100 102c493e IC-COOKIE-1..,I> b0: 582b6a2f 21280d77 191b183c 18010000 X+j/!(.w...<.... c0: 1d6b797a 796c2e65 6e676561 73742e62 .kyzyl.engeast.b d0: 61796e65 74776f72 6b732e63 6f6d0001 aynetworks.com.. e0: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO f0: 4b49452d 3100102c 493e582b 6a2f2128 KIE-1..,I>X+j/!( 100: 0d77191b 183c1800 000004c0 20442600 .w...<...... D&. 110: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 120: 4f4b4945 2d310010 07397b42 622b2626 OKIE-1...9{Bb+&& 130: 5a03084c 31176e1a 0100001c 74757661 Z..L1.n.....tuva 140: 2e656e67 65617374 2e626179 6e657477 .engeast.baynetw 150: 6f726b73 2e636f6d 00013000 124d4954 orks.com..0..MIT 160: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 170: 1007397b 42622b26 265a0308 4c31176e ..9{Bb+&&Z..L1.n 180: 1a000000 04c0208a 7f000131 00124d49 ...... ....1..MI 190: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 1a0: 0010b6be 63a75d1a 03b0dbef b9d7c6ed ....c.]......... 1b0: 5b5f0100 000a7373 682d7365 72766572 [_....ssh-server 1c0: 00013100 124d4954 2d4d4147 49432d43 ..1..MIT-MAGIC-C 1d0: 4f4f4b49 452d3100 10b6be63 a75d1a03 OOKIE-1....c.].. 1e0: b0dbefb9 d7c6ed5b 5f000000 04c0208a .......[_..... . 1f0: 7f000132 00124d49 542d4d41 4749432d ...2..MIT-MAGIC- 200: 434f4f4b 49452d31 00103574 88e4473e COOKIE-1..5t..G> 210: a48fcaad 49db7962 be870100 000a7373 ....I.yb......ss 220: 682d7365 72766572 00013200 124d4954 h-server..2..MIT 230: 2d4d4147 49432d43 4f4f4b49 452d3100 -MAGIC-COOKIE-1. 240: 10357488 e4473ea4 8fcaad49 db7962be .5t..G>....I.yb. 250: 87000000 04c02006 fb000130 00124d49 ...... ....0..MI 260: 542d4d41 4749432d 434f4f4b 49452d31 T-MAGIC-COOKIE-1 270: 00101e41 8142d1fb 8c099bc6 8edf3d35 ...A.B........=5 280: c4570100 00086465 6c6f7265 616e0001 .W....delorean.. 290: 3000124d 49542d4d 41474943 2d434f4f 0..MIT-MAGIC-COO 2a0: 4b49452d 310010c7 61e4ada4 c7d59f4d KIE-1...a......M 2b0: 7fbee210 020ded00 000004c0 20066900 ............ .i. 2c0: 01300012 4d49542d 4d414749 432d434f .0..MIT-MAGIC-CO 2d0: 4f4b4945 2d310010 ca22b5ea 9a06aa85 OKIE-1..."...... 2e0: 6f0aab8d 6dba92c0 01000005 726f6269 o...m.......robi 2f0: 6e000130 00124d49 542d4d41 4749432d n..0..MIT-MAGIC- 300: 434f4f4b 49452d31 00103458 53d66775 COOKIE-1..4XS.gu 310: 952a1b66 7c9f1a16 63d20000 0004c020 .*.f|...c...... 320: 06910001 3000124d 49542d4d 41474943 ....0..MIT-MAGIC 330: 2d434f4f 4b49452d 3100109f 8c5f2a51 -COOKIE-1...._*Q 340: 1dc293c8 e111e018 4893cf ........H.. Frame 563 Date and Time: 04-Jan-99 00:05:56.586 Ethernet Header byte 0 Destination 00:00:a2:c3:39:74 48 bits Bay Networks Source 00:a0:24:97:82:2e 48 bits Ethertype 0x800 16 bits IP Header (Internet Protocol) byte 14 Version IP 4 bits Header Length 5 32-bit words 4 bits Precedence ROUTINE 3 bits Type of Service NORMAL_SERVICE 4 bits Unused 0 1 bits Total Length 68 bytes 16 bits Identification 3593 16 bits Flags, Unused 0 1 bits Flags, DF bit MAY_FRAGMENT 1 bits Flags, MF bit LAST_FRAGMENT 1 bits Fragment Offset 0 * 8 octets 13 bits Time To Live 64 seconds/hops 8 bits Protocol UDP 8 bits Checksum 0x6b30 16 bits Source Address 192.32.68.39 32 bits Destination Address 192.32.61.8 32 bits UDP Header byte 34 Source Port SUNRPC 16 bits Destination Port 0x801 16 bits Length 48 bytes 16 bits Checksum 0xe972 16 bits SUNRPC_HDR byte 42 Transfer Id 0x82040000 32 bits Type CALL 32 bits SUNRPC_CALL byte 50 RPC Version VERS_2 32 bits Program NFS 32 bits Version 2 32 bits Procedure 0 32 bits Flavor NONE 32 bits Length 0 bytes 32 bits Flavor NONE 32 bits Length 0 bytes 32 bits -- Robert Withrow -- (+1 978 916 8256) BWithrow@BayNetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:05:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17856 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:05:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA17851 for ; Tue, 5 Jan 1999 14:05:38 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 26509 invoked from network); 5 Jan 1999 22:05:09 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 5 Jan 1999 22:05:09 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id RAA01732; Tue, 5 Jan 1999 17:05:07 -0500 (EST) Message-Id: <199901052205.RAA01732@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901051847.LAA10199@usr02.primenet.com> from Terry Lambert at "Jan 5, 99 06:47:29 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 5 Jan 1999 17:05:07 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > I don't really buy this for the general case, which I believe is > still stacking layers that don't access local media. > > For local media FS's, things which actially do I/O through a page > fault, this is probably correct. > Actually, the VM approach works really well for non-local filesystems also. How do you pass a bp or vp around across systems??? Hmmm??? The VM object abstraction simply names data, and has validity info that can be passed from layer to layer. The VFS abstraction is messed up with the concept of "vnode" and "bp", etc. Those don't mean ANYTHING across machines. > > The point in abstraction, however, is not artificial, unless you > only consider one *BSD. If you want to leverage the total *BSD > hacker base to do FS (or any other kind of) work such that it's > applicable to your particular flavor of the month of *BSD, then > you need that type of abstraction. > The abstraction needs to be MESI and VM related. Throw away the old VFS concept -- it was good, but very flawed. You'll never get layering and coherency to work correctly with a VFS only scheme. If you use a VM oriented scheme, your local copy of pages can be copyin'ed or copy'outed or mmaped. If you take a VFS oriented approach, then you have to deal with something that thinks in terms of buffers that have to be somehow mmap'ed... Bzzzt... That is a terrible mess, and why the FreeBSD VM/VFS code temporarily uses buffers, but uses memory OBJECTS as the repository for data. Try putting together a coherent buffer oriented scheme -- you start ending up with LOTS of limitations and complexity due to the additional level of abstraction. Take Heidemann + VM and object oriented approaches, and you'll get something that works super well (and is practical.) Think more in terms of CORBA (even though not quite that) than uniprocessor programming. The local case can be a degenerate case of the object approach, and can short circuit to minimize copying. > > I really think that the main FS work as time goes on will be in > stacking layers, and not in local media FS's. > Again, I agree, but I am thinking totally in a distributed environment. VFS (as it is today) just doesn't work. If you rename a VM (or object) oriented scheme as VFS, then VFS is okay. VFS as it is allows (and supports) only unidirectional communication... Bzzzt, in a distributed environment. > > Yeah, a local media FS is pretty intimate with the VM system, > especially in the getpages/putpages area (and, if supported as > a direct interface instead of a layer on top of the getpages/putpages, > bmap). But that intimacy should be formally abstract. > But why add additional, and unneeded layers of abstraction, like the way that current VFS works? VFS might be good for naming (but doesn't handle the case of revocation of names correctly, does it?) See, there is just too much hackery necessary when using "VFS" for non-local systems... -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:24:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19658 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:22:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19645 for ; Tue, 5 Jan 1999 14:22:38 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id RAA50233; Tue, 5 Jan 1999 17:24:52 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 17:24:52 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Robert Withrow cc: hackers@FreeBSD.ORG, witr@rwwa.com Subject: Re: 3.0-REL NFS interop problems redux In-Reply-To: <199901052143.VAA15097@tuva.engeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Robert Withrow wrote: > I whined before about my problem where a specific NFS mount goes > deaf on me for a period of time and then wakes up later. I said > that I would sniff out the problem... Well I finally got my office > set up so that I could get a sniffer to capture the session and I have > that capture (about 600 packets). I've looked at it and I can see > where it goes wrong, but I can't see *why* it is wrong. I'm wondering > if there is an NFS hacker who can work with me on this. as a workaround, have you tried: a) tcp mounts b) nfs 3 c) cvsup'ing to a new -current (there was some problems with signals being delivered during NFS activity in -release) at work, i'm a NFS client to a solaris box and 'a' and 'b' seems to have solved my hanging problems, i used to have a NFS hang for several minutes occasionally, going tcp helped that. (however i'm not using AMD) you also may want to look into the bugfixes that were done post-release i know those aren't _solutions_ but they may be able to help Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:25:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19931 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:25:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from guppy.pond.net (guppy.pond.net [205.240.25.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19916 for ; Tue, 5 Jan 1999 14:25:21 -0800 (PST) (envelope-from dwhite@pond.net) Received: from localhost (dwhite@localhost) by guppy.pond.net (8.8.8/8.8.7) with SMTP id OAA14612 for ; Tue, 5 Jan 1999 14:13:50 -0800 (PST) Date: Tue, 5 Jan 1999 14:13:50 -0800 (PST) From: Doug White To: hackers@FreeBSD.ORG Subject: bpf select() broke? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all ... I'm posting this again since I didn't get much reply last time, and I hope to cull the BPF-meister from his hole ... Do Berkeley packet filter devices (/dev/bpfX) supposed to respond like normal files and devices to a select() system call? My experimentation (based on 2.2.7-RELEASE) shows that they don't. They don't return when they have data waiting to read and they don't return when they're ready to be written to. The bpf fd is definitely in the fd list going into the select(), so don't try to pin pilot error on this one. The code in /sys/net/bpf.c appears to support it but since I'm no kernel hacker I'm not going to trace what's going on, at least not yet. I'll try compiling my code on a relatively CURRENT box at home, but I'm not sure it's set up enough to fully test the condition. Thanx for any help. Doug White | Pacific Crest Networks Internet: dwhite@pond.net | http://www.pond.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:26:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20131 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:26:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bvcrnuxc.getmoretraffic.com (CBL-panamerican.hs.earthlink.net [208.233.115.216]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA20031 for ; Tue, 5 Jan 1999 14:26:11 -0800 (PST) (envelope-from getmoretraffic@getmoretraffic.com) From: albywxhg@getmoretraffic.com Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 05 Jan 1999 17:25:11 -0500 Subject: Protecting Your Assets from Legal Attack Message-ID: To: freebsd-hackers@FreeBSD.ORG Reply-To: getmoretraffic@getmoretraffic.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG IMPORTANT INFORMATION ON HOW TO PRESERVE YOUR ASSETS YOU WORKED HARD TO ACQUIRE THEM--- NOW LEARN HOW TO PROTECT THEM USING ASSET PROTECTION TRUSTS In our litigious society where baseless lawsuits are commonplace, it is no longer enough to simply worry about wealth accumulation. Wealth Preservation and Asset Protection Planning are now real issues. With the possibility of a single lawsuit wiping away a lifetime of savings, individuals (especially those with families), have made concerted efforts to preserve assets and assure the family estate for future generations. Experts agree that the one of the best ways to do so is with the aid of Asset Protection Trusts. An Asset Protection Trust is not the ideal plan for everyone, but where it is a good solution, professionals (doctors, lawyers, stockbrokers, etc.), owners of closely held businesses, and others who have spent a lifetime accumulating wealth can now put up formidable barriers to thwart potential creditor suits and other civil litigation. If you want to learn more about this legal option and the possibility of providing a more comprehensive protection for you and your family, just click below to obtain FREE additional information. There is NO OBLIGATION and you will receive no follow-up calls or further correspondence unless you specifically request it. All inquiries are kept CONFIDENTIAL and if requested, you are assured a response by a member of our legal staff within forty-eight (48) hours. Click on the link below and find out whether or not an Asset Protection Trust is right for you: http://getmoretraffic.com/offshorelaw ************************************************************************************* If you wish to be removed from our mailing list, we will gladly do so. Please click the REPLY button and put the word “REMOVE” in the subject line to have your name promptly deleted. ************************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:26:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20209 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:26:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from htxgxvqm.getmoretraffic.com (CBL-panamerican.hs.earthlink.net [208.233.115.216]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA20058 for ; Tue, 5 Jan 1999 14:26:15 -0800 (PST) (envelope-from getmoretraffic@getmoretraffic.com) Reply-To: getmoretraffic@getmoretraffic.com Date: Tue, 05 Jan 1999 17:25:13 -0500 Content-Type: text/plain; charset=ISO-8859-1 From: xolqkons@getmoretraffic.com Subject: Protecting Your Assets from Legal Attack Message-ID: To: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG IMPORTANT INFORMATION ON HOW TO PRESERVE YOUR ASSETS YOU WORKED HARD TO ACQUIRE THEM--- NOW LEARN HOW TO PROTECT THEM USING ASSET PROTECTION TRUSTS In our litigious society where baseless lawsuits are commonplace, it is no longer enough to simply worry about wealth accumulation. Wealth Preservation and Asset Protection Planning are now real issues. With the possibility of a single lawsuit wiping away a lifetime of savings, individuals (especially those with families), have made concerted efforts to preserve assets and assure the family estate for future generations. Experts agree that the one of the best ways to do so is with the aid of Asset Protection Trusts. An Asset Protection Trust is not the ideal plan for everyone, but where it is a good solution, professionals (doctors, lawyers, stockbrokers, etc.), owners of closely held businesses, and others who have spent a lifetime accumulating wealth can now put up formidable barriers to thwart potential creditor suits and other civil litigation. If you want to learn more about this legal option and the possibility of providing a more comprehensive protection for you and your family, just click below to obtain FREE additional information. There is NO OBLIGATION and you will receive no follow-up calls or further correspondence unless you specifically request it. All inquiries are kept CONFIDENTIAL and if requested, you are assured a response by a member of our legal staff within forty-eight (48) hours. Click on the link below and find out whether or not an Asset Protection Trust is right for you: http://getmoretraffic.com/offshorelaw ************************************************************************************* If you wish to be removed from our mailing list, we will gladly do so. Please click the REPLY button and put the word “REMOVE” in the subject line to have your name promptly deleted. ************************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:31:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21413 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:31:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21407 for ; Tue, 5 Jan 1999 14:31:53 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA10787; Tue, 5 Jan 1999 14:30:42 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA00015; Tue, 5 Jan 1999 14:30:41 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id PAA13142; Tue, 5 Jan 1999 15:30:40 -0700 Message-ID: <36929290.2909A074@softweyr.com> Date: Tue, 05 Jan 1999 15:30:40 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901051818.LAA08069@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > It's a lot of work, but it's not rocket science. The most > > > complicated piece is the lock manager; to do it right, you need > > > a five dimensional vector relationship (an arc describing the > > > intersection of three two dimensional vectors: the lock list > > > held by a locking entity, the hierarchical list of lockable objects, > > > and the relationship between multiple locking entities within a > > > single process -- threads within a process). > > > > If you wish to see a working example of a microkernel using object > > locks, take a peek at the RTEMS kernel. It's quite portable, and > > supports SMP systems out of the box. See > > > > http://www.oarcorp.com/rtems/rtems.html > > > > for information. > > RTEMS has three unfortunate problems: > > 1) It is not uITRON compliant. There's really no reason to > do an RT system that isn't uITRON compliant. It's the > industry standard, and there is a lot of code (including > embedded browsers) that are available for such systems. Except that out here in the real world uITRON isn't even on the radar screen. I know it's supposed to be big news with the Japanese companies who created it, but the numerous projects being done here in the USA don't even consider it. At all. Ever. > 2) It's GPL'ed. That means that the source code can't be > used to prepare derivative works that have any strategic > value of any kind. I'm really surprised that it was > possible to GPL something supported by a DARPA grant, > given the governments technology transfer requirements > for such grants, but there it is. The problem here is > that embedded OS's are peculiar in that ROM'ing a browser > at the same time you ROM a GPL'ed OS is a little more > than "mere agregation". If you read the RTEMS license page, it is GPL'ed with an exception, and that exception allows you to create and distribute your product, linked with RTEMS, without restraint. In effect, they're using the LGPL with no source distribution clause. The original RTEMS license was much more Berkeley like, but they found a couple of "clients" who were not contributing fixes back and it sorta ticked them off, so they went with this instead. Go figure. > 3) Object locks are the wrong way to address the reentrancy > issue. The problem with object locks is that it puts > objects that don't really need to be in a contention > domain into one in order to satisfy contention in what > are usually very small critical sections having to do > with list manipulation of pointers to the object. This > type of thinking is why most Intel based SMP OS's claim > that scaling past 4 processors is "useless". What they > really mean is that their SMP OS is useless for more > than 4 processors. Yeah, you have to have *some* object > locks for non-reentrant objects (e.g., the I/O bus), but > this is pretty much limited to physical hardware limits, > and isn't really applicable for, for instance, vnodes. Whether this is a problem or not depends on your system architecture. In embedded systems, where the interactions between parts of the architecture are generally both simpler and more limited than in a large, general- purpose computer, contention on the critical objects often is not much of a consideration, because the various system objects have such limited interactions. This is also true of, for instance, I/O processors communicating with a main system processor. RTEMS remains a good example of a working object-locking system that can scale quite easily to a moderate number of processors. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:36:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22090 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:36:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22083 for ; Tue, 5 Jan 1999 14:36:31 -0800 (PST) (envelope-from rb@gid.co.uk) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.7/8.8.7) with UUCP id WAA21901; Tue, 5 Jan 1999 22:35:42 GMT (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] by seagoon.gid.co.uk; Tue, 5 Jan 1999 22:34:49 GMT X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <199901052043.NAA09607@mt.sri.com> References: <199901052008.NAA09332@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Jan 1999 22:34:47 +0000 To: Nate Williams From: Bob Bishop Subject: Re: question about re-entrancy. Cc: Narvi , Terry Lambert , Wes Peters , bright@hotjobs.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:43 pm -0700 5/1/99, Nate Williams wrote: >A 'critical section of code' is a portion of the code that is accessing >a shared resource, which can be protected by using an object lock. Erm, make that "...accessing *one or more* shared resources.", which is why it isn't the same thing as an object lock (except in the degenerate case). -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:37:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22130 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:37:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22123 for ; Tue, 5 Jan 1999 14:36:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA97860; Tue, 5 Jan 1999 14:36:28 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 14:36:28 -0800 (PST) From: Matthew Dillon Message-Id: <199901052236.OAA97860@apollo.backplane.com> To: "John S. Dyson" Cc: tlambert@primenet.com (Terry Lambert), dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Terry Lambert said: :> :> I don't really buy this for the general case, which I believe is :> still stacking layers that don't access local media. :> :> For local media FS's, things which actially do I/O through a page :> fault, this is probably correct. :> :Actually, the VM approach works really well for non-local filesystems :also. How do you pass a bp or vp around across systems??? Hmmm??? :The VM object abstraction simply names data, and has validity info :that can be passed from layer to layer. The VFS abstraction is :messed up with the concept of "vnode" and "bp", etc. Those don't :mean ANYTHING across machines. :.. It's kinda unfair to bring Terry & freebsd-hackers in without some context - what Johh is saying is coming out of a much longer discussion that has been occuring in private email amoungst three or four of us in regards to VM/VFS system cleanups. What it comes down to is how to find the right abstraction to do the job without blowing efficiency out of the water. John has come to the conclusion (which I have also now come to, and I think a number of others too but are still worried about making such major changes to the VFS APIs and disrupting certain ongoing projects... it hasn't been put forth on -hackers or -current mainly to avoid starting a flame war) ... we've come to the conclusion that VFS is badly flawed and basically needs to be replaced. In talking about the basic I/O mechanisms to replace it with, John (and now I) have come to the conclusion that the best mechanism is to extend the vm_object_t object model into the VFS system. The VM object module is *already* heavily hacked into the VFS/BIO model to handle deficiencies in VFS/BIO. Extending the VM object model and getting rid of the VFS/BIO model actually isn't as bad as it sounds and would clean up a lot of junk. Before this came up outside our little group we were getting into a discussion as to how to appropriately extend the VM object model to cover VFS operations and maintain cache coherency (something the current VFS system doesn't do at all without a whole lot of hacking) without screwing up efficiency. This is where John's bi-directional IPC comments come into play. My current argument is to give vm_page_t an aliasing capability - vm_alias_t's are actually linked into multiple objects and can alias the same vm_page_t, and thus allows the VM system to maintain cache coherency between VFS layers up to a break point (e.g. a file fragment or a VFS device that must translate the contents of a page, such as RAID-5 or an encryption module), and then use a more sophisticated (and less efficient) model to bridge the gaps - aka a cache coherency protocol aka John's 'bidirectional IPC capability' idea. Most of the VOP-like calls would be shifted to run through vm_object_t and BIO (struct buf's) would be removed entirely. So, for example, the UFS/FFS filesystem code would run mostly through the VM system's very efficient coherency model but if it must do something extraordinary, like truncate a file, the more sophisticated coherency protocols (John's 'bidrectional IPC') would be used to pass information back up into the VM system (e.g. 'destroy these pages, dude!'). The same protocols would be used in a networked/clustered environment to do cache coherency for mmap()'d objects (and other things) across the network. -Matt :Again, I agree, but I am thinking totally in a distributed environment. :VFS (as it is today) just doesn't work. If you rename a VM (or object) :oriented scheme as VFS, then VFS is okay. VFS as it is allows (and :supports) only unidirectional communication... Bzzzt, in a distributed :environment. : :> :> Yeah, a local media FS is pretty intimate with the VM system, :> especially in the getpages/putpages area (and, if supported as :> a direct interface instead of a layer on top of the getpages/putpages, :> bmap). But that intimacy should be formally abstract. :> :But why add additional, and unneeded layers of abstraction, like the way :that current VFS works? : :VFS might be good for naming (but doesn't handle the case of revocation :of names correctly, does it?) See, there is just too much hackery necessary :when using "VFS" for non-local systems... : :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:42:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22849 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:42:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22843 for ; Tue, 5 Jan 1999 14:42:40 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA18035; Tue, 5 Jan 1999 15:42:02 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA10308; Tue, 5 Jan 1999 15:42:00 -0700 Date: Tue, 5 Jan 1999 15:42:00 -0700 Message-Id: <199901052242.PAA10308@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bob Bishop Cc: Nate Williams , Narvi , Terry Lambert , Wes Peters , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: References: <199901052008.NAA09332@mt.sri.com> <199901052043.NAA09607@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >A 'critical section of code' is a portion of the code that is accessing > >a shared resource, which can be protected by using an object lock. > > Erm, make that "...accessing *one or more* shared resources.", which is why > it isn't the same thing as an object lock (except in the degenerate case). Sure it is. The object lock is used to 'protect' the shared resources. This is multithreading/tasking 101 stuff, not rocket science. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:42:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22884 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:42:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22876 for ; Tue, 5 Jan 1999 14:42:52 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA15746; Tue, 5 Jan 1999 15:42:23 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd015719; Tue Jan 5 15:42:19 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA24752; Tue, 5 Jan 1999 15:42:05 -0700 (MST) From: Terry Lambert Message-Id: <199901052242.PAA24752@usr02.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Tue, 5 Jan 1999 22:42:04 +0000 (GMT) Cc: tlambert@primenet.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901051946.MAA09199@mt.sri.com> from "Nate Williams" at Jan 5, 99 12:46:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I looked up UITron on the WWW, and only got a hit from Sun, and it was > lost in the noise. I have a hard time seeing this as 'Industry > Standard', but I'm sure you'll feel free to explain to me how it's a > standard. Dunno what search engine you are using, but you should consider switching... http://www.cygnus.com/ecos/faq.html#14 http://www.cygnus.com/ecos/micro.html http://tron.um.u-tokyo.ac.jp/TRON/ITRON/eng-spec.html http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html http://tron.um.u-tokyo.ac.jp/TRON/ITRON/spec-e.html#ITRON3 > > 3) Object locks are the wrong way to address the reentrancy > > issue. > > Sometime I wonder if you just like to listen to yourself speak. Object > locks *ARE* the correct way to address reentrancy issues. Having done > *real* multithreaded/multi-object design for some time now, I've found > that Object locks are a *much* cleaner way of designing for re-entrant > code. (If you don't want something locked, you don't create an object > for it...) > > How much *REAL* (stuff that is used by someone outside yourself) > experience do you have designing multi'threaded/whatever' software to > speak with such authority? Novell/USG employed me for four years to work on, among other things, threading systems, FS's which had to live in SMP kernels, interprocess context sharing mechanisms, and high efficiency process architectures. Lets see. I wrote an attributed FS that ran on SVR4.x ES/MP while working for USL. It's still shipped with the NetWare for UNIX 4.x source code. If you have $150,000, Novell will sell you a license. It had to run on two SMP capable systems (SVR4 [UnixWare] and Solaris) as the reference porting platforms, and was ported to others by vendors. The intention mode lock manager is capable of 200 times as many transactions per second as Bell Labs "Tuxedo" transaction system. That's 2 orders of magnitude, if you are counting. I was on the code review team for the NUC (NetWare UNIX Client) FS for Novell/USG (the former USL), which operated in a large number of SMP kernels, and contributed, I believe significantly, to the design modifications that were arrived at. I also did the PNW process architecture using a modified (by me) version of DEC's MTS (MultiThreading Services), which is an AST-based call conversion threads scheduler written in Bliss. I made it work during a port of Mentat Streams to VMS during a project to implement the "PathWorks for VMS (NetWare)" server. You can talk to Robert Withrow about that one, since he was a contractor on the DEC side of the project. I did the file descriptor sharing code for UnixWare, Solaris, and AIX that allowed the NetWare 4.x work-to-do server processes to share open file contexts. I also came up with the streams-MUX based "hot engine scheduling". Gee, that code running on UNIX outperforms Native Netware 4.x on the exact same hardware; must have done something right there... I saved Jack Vogel's original SMP code, and partially brought it up to date -- perhaps you've heard of FreeBSD SMP, based on Peter and Steve and others hacking up Jacks code with my modifications? Along with Jeremy Allison, I brought FreeBSD pthreads into compliance with the Draft 4.0 standard. I supplied the threading model patches and other related patches to the UMICH LDAP server code that were adopted as the core code for the OpenLDAP project. I modified the "Moscow Center for SPARC Computing"'s STL to operate within a Draft 4 pthreads environment. So, Nate, what have you done that compares with actually working on code that runs in commercial SMP kernels, such that you can claim with such authority that "a *much* cleaner way of designing for re-entrant code" (which I never disputed) results in *better* *actual* *performance*? Just because object locks are an *easy* design problem doesn't mean that they will yield the best performance. They won't. We can prove this to ourselves by looking at how many processors Dynix can scale to reasonably (32) vs. how many SVR4.2 can scale to reasonably (4) before degrading more because of object lock contention than is gained by adding more processors. What we want is "better performance", not "easiest design". The latter is the reason we have The Big Giant Lock(tm) today. > > The problem with object locks is that it puts > > objects that don't really need to be in a contention > > domain into one in order to satisfy contention in what > > are usually very small critical sections having to do > > with list manipulation of pointers to the object. > > So you're claiming that the 'Big Giant Lock' is the better way? You > can't have it both ways. No. I'm claiming critical section locks tend to be held for a shorter duration than an object tends to be held (this should be intuitively obvious -- critical sections are less persistant than objects which are operated upon by both critical (redcode) and noncritical sections). Having critical sections that can be locked WITH THEIR OWN INIDIVIDUAL LOCKS is a far cry from suggesting that critical sections should be protected with The Big Giant Lock(tm). For lists, the cost of associating the lock with the list explicitly vs. implicitly is equivalent. Architecturally, it makes sense to use an exlicit association, since we need to have humans maintain the code. Please read the referenced Dynix memory allocator paper. You might also want to read "The Magic Garden Explained", "UNIX for Modern Architectures", and "UNIX Internals: The New Frontiers" for an understanding of the use of object locks in SVR4 derivatives, and the failings of the OS's that incorporate them. The "UNIX Internals" book is particularly good in the discusion of the Dynix allocator vs. the Solaris SLAB allocator (although, as I told Uresh Vahalia as I was reviewing the manuscript for Prentice Hall, I disagree with his conclusions about which is better, for the reasons I've put forward in this thread -- I prefer a hybrid that allows per CPU resource pools, per the Dynix allocator). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:46:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23435 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:46:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23423 for ; Tue, 5 Jan 1999 14:46:03 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA27998; Tue, 5 Jan 1999 15:45:28 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd027876; Tue Jan 5 15:45:24 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA24981; Tue, 5 Jan 1999 15:45:12 -0700 (MST) From: Terry Lambert Message-Id: <199901052245.PAA24981@usr02.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Tue, 5 Jan 1999 22:45:12 +0000 (GMT) Cc: narvi@haldjas.folklore.ee, nate@mt.sri.com, tlambert@primenet.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901052008.NAA09332@mt.sri.com> from "Nate Williams" at Jan 5, 99 01:08:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The third way (about which Terry did talk) is to have locks around > > critical sections. > > That *is* what an 'object lock' in RTEMS is. No. An object lock is associated with an object. A critical section lock is associated with a section of code. RTEMS uses real object locks (just like EROS or KeyKOS or ...). See my argument about the relative persistence of objects vs. critical sections. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:48:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23914 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:48:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23899 for ; Tue, 5 Jan 1999 14:48:54 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA18115; Tue, 5 Jan 1999 15:48:22 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA10395; Tue, 5 Jan 1999 15:48:22 -0700 Date: Tue, 5 Jan 1999 15:48:22 -0700 Message-Id: <199901052248.PAA10395@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052242.PAA24752@usr02.primenet.com> References: <199901051946.MAA09199@mt.sri.com> <199901052242.PAA24752@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The problem with object locks is that it puts > > > objects that don't really need to be in a contention > > > domain into one in order to satisfy contention in what > > > are usually very small critical sections having to do > > > with list manipulation of pointers to the object. > > > > So you're claiming that the 'Big Giant Lock' is the better way? You > > can't have it both ways. > > No. I'm claiming critical section locks tend to be held for a > shorter duration than an object tends to be held (this should be > intuitively obvious -- critical sections are less persistant than > objects which are operated upon by both critical (redcode) and noncritical > sections). Huh? Differentiate between 'protecting a critical section and using object locks?'. (Assumin that 'aquire' with no parameters block indefinitely until the lock is gained. If you want something else, use something else.) Object lock = new Object(); lock.aquire(); /* Critical section */ lock.release(); This is the same thing you are stating, which you claim is somehow inferior to some other way of locking down a critical section of code. (This is how you would do this in RTEMS.) > Having critical sections that can be locked WITH THEIR OWN INIDIVIDUAL > LOCKS is a far cry from suggesting that critical sections should be > protected with The Big Giant Lock(tm). And you can use 'individual locks' inside RTEMS. How is this different than 'locking down critical sections w/out using object locks'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:49:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24080 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:49:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24059 for ; Tue, 5 Jan 1999 14:49:43 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA18125; Tue, 5 Jan 1999 15:49:09 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA10421; Tue, 5 Jan 1999 15:49:08 -0700 Date: Tue, 5 Jan 1999 15:49:08 -0700 Message-Id: <199901052249.PAA10421@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052245.PAA24981@usr02.primenet.com> References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The third way (about which Terry did talk) is to have locks around > > > critical sections. > > > > That *is* what an 'object lock' in RTEMS is. > > No. An object lock is associated with an object. A critical section > lock is associated with a section of code. An object lock can be associated with a lock that does nothing but associate itself with a critical section. *sheesh* This ain't rocket science. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:50:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24218 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:50:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23977 for ; Tue, 5 Jan 1999 14:49:10 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id WAA21994; Tue, 5 Jan 1999 22:23:12 GMT (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.1/8.9.1) with ESMTP id WAA57122; Tue, 5 Jan 1999 22:23:11 GMT (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199901052223.WAA57122@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Ruslan Ermilov cc: Brian Somers , FreeBSD Hackers Subject: Re: Proposed small change to ppp(8): CONNECT -> CALLER_ID In-reply-to: Your message of "Thu, 31 Dec 1998 12:00:57 +0200." <19981231120057.A1164@ucb.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 05 Jan 1999 22:23:11 +0000 From: Brian Somers Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA24128 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, How about something like ``set proctitle USER'' ? I think it may also be useful to allow environment variable expansions too - something like ``set proctitle $CALLER_ID'' - solving the problem more generically. > Hi! > > How about logging CALLER_ID to the host field instead of CONNECT? > It looks more meaningful. Look: > > # w > 11:57 up 4 days, 12:03, 8 users, load averages: 0.58, 0.41, 0.24 > USER TTY FROM LOGIN@ IDLE WHAT > dakota c00 +02732231 11:55 1 ppp -direct > uupf17 c01 - 11:56 - - > dep05 c02 +02546701 11:51 - ppp -direct > ru p0 wks-1-250 ÓÒ 03ÐÐ - w > rost p1 rost ÓÒ 03ÐÐ 13 ftp rtuis.miem.edu.ru > rost p2 rost 10:21 1:27 ftp rtuis.miem.edu.ru > rost p3 rost 10:33 1:07 -tcsh (tcsh) > bill p4 wks-1-254 11:05 51 deco > > # last -tcuac00 > epi cuac00 +04933301 Thu Dec 31 10:53 - 10:54 (00:00) > parus cuac00 +02476691 Thu Dec 31 10:48 - 10:49 (00:00) > terhold cuac00 +02493761 Thu Dec 31 10:10 - 10:21 (00:10) > inkomplu cuac00 +02297181 Thu Dec 31 09:44 - 09:46 (00:02) > parus cuac00 +02476691 Thu Dec 31 09:19 - 09:20 (00:00) > parus cuac00 +02476691 Thu Dec 31 09:11 - 09:13 (00:01) > dakota cuac00 +02732231 Thu Dec 31 08:57 - 08:58 (00:00) > dakota cuac00 +02732231 Thu Dec 31 08:55 - 08:55 (00:00) > parus cuac00 +02476691 Thu Dec 31 08:43 - 08:44 (00:01) > steve cuac00 +02546681 Thu Dec 31 00:51 - 01:55 (01:04) > steve cuac00 +02546681 Thu Dec 31 00:46 - 00:50 (00:03) > sasha cuac00 +02719391 Thu Dec 31 00:10 - 00:42 (00:32) > sasha cuac00 +02719391 Wed Dec 30 23:12 - 00:08 (00:56) > sasha cuac00 +02719391 Wed Dec 30 22:49 - 22:53 (00:04) > sasha cuac00 +02749061 Wed Dec 30 21:44 - 21:49 (00:05) > sasha cuac00 +02749061 Wed Dec 30 21:24 - 21:41 (00:17) > sasha cuac00 +02749061 Wed Dec 30 21:14 - 21:21 (00:07) > sasha cuac00 +02719391 Wed Dec 30 20:18 - 20:36 (00:18) > sasha cuac00 +02719391 Wed Dec 30 20:08 - 20:10 (00:01) > > One-line patch is in attachment. > > BR, > -- > Ruslan Ermilov Sysadmin and DBA of the > ru@ucb.crimea.ua United Commercial Bank > +380.652.247.647 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > --AqsLC8rIMeq19msA > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="physical.c.diff" > > Index: physical.c > =================================================================== > RCS file: /usr/FreeBSD-CVS/src/usr.sbin/ppp/physical.c,v > retrieving revision 1.6 > diff -u -r1.6 physical.c > --- physical.c 1998/08/25 17:48:43 1.6 > +++ physical.c 1998/12/29 11:14:32 > @@ -196,7 +196,7 @@ > time(&ut.ut_time); > strncpy(ut.ut_name, name, sizeof ut.ut_name); > strncpy(ut.ut_line, phys->name.base, sizeof ut.ut_line); > - if ((connstr = getenv("CONNECT"))) > + if ((connstr = getenv("CALLER_ID"))) > /* mgetty sets this to the connection speed */ > strncpy(ut.ut_host, connstr, sizeof ut.ut_host); > ID0login(&ut); > > --AqsLC8rIMeq19msA-- > -- Brian , , Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 14:50:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24309 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sturm.canonware.com (canonware.com [204.107.140.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24235 for ; Tue, 5 Jan 1999 14:50:05 -0800 (PST) (envelope-from jasone@canonware.com) Received: from canonware.com (mg134-218.ricochet.net [204.179.134.218]) by sturm.canonware.com (8.8.8/8.8.8) with ESMTP id OAA23551; Tue, 5 Jan 1999 14:45:18 -0800 (PST) (envelope-from jasone@canonware.com) Message-ID: <369296F4.AE24010B@canonware.com> Date: Tue, 05 Jan 1999 14:49:24 -0800 From: Jason Evans X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) MIME-Version: 1.0 To: Kelly Yancey CC: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... References: <36881978.CFE748CD@freedomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kelly Yancey wrote: > > one more thing, a dirty secret in FreeBSD is that all threads are done as > > ONE process, if you have multiple CPUs you do not gain the advantage of > > multiple processors, you have to design a hybrid fork/thread model. > > > > Argh. Is this going to be fixed in 3.0? Does anyone intend on fixing > it? I mean, even Linux has kernel support for threads, I should think > that FreeBSD...the king of server OS'es...could at least do the same. > For the time being this isn't a problem, as I only have a single CPU, > but I'm really going to need FreeBSD to support scheduling threads on > separate processors by the time I finish the project. I *really* like > FreeBSD, but if I have to I suppose Linux will be the target platform if > 3.0 can't schedule threads independantly. Things aren't quite that simple. Linux's 1-1 kernel threads model has some problems, such as slow thread switching (as compared to a user-land threads implementation), slow thread creation, and some scalability issues I've noticed when creating large numbers of threads. To ask if FreeBSD's threads library is going to be "fixed" to work like Linux's threads library is IMO a poor question, since my observation has been that there are more performance problems that reach out and bite the programmer with LinuxThreads than with FreeBSD's user-land threads. Implementing a threads library that performs well for a wide range of applications is a very difficult (though feasible) task. Thus far, none of the free OSes have come up with such a beast. Jason -- Jason Evans Email: [jasone@canonware.com] Web: [http://www.canonware.com/~jasone] Home phone: [(650) 856-8204] Work phone: [(415) 808-8742] Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:03:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26637 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:03:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26629 for ; Tue, 5 Jan 1999 15:03:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA98165; Tue, 5 Jan 1999 15:03:03 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 15:03:03 -0800 (PST) From: Matthew Dillon Message-Id: <199901052303.PAA98165@apollo.backplane.com> To: Terry Lambert Cc: bright@hotjobs.com (Alfred Perlstein), tlambert@primenet.com, wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I think the best way of thinking of the problem is an analogy :that someone told me years ago: : :Think of the CPU's in an SMP system as spiders crawling over :the code; the more CPU's, the more spiders. : :Most of the code is black; it doesn't matter how many spiders :are crawling ove it at the same time. Some spots in the code are :red, where global lists or singular objects are being manipulated. : :These are weak spots in the code that can only support the weight :of one spider at a time. Maybe they are a result of weak spots :in the hardware (e.g., you can't have multiple CPU's issuing :INB/OUTB commands such that the agregate rate exceeds the ability :of the bus). : :Think of how you would design an OS to minimise the percentage of :red vs. black. At the same time, don't make it do that the only :... This is a really good analogy, with one change: The problem with the red zones is not so much that only one spider can go through it at a time, but of the pipelining that is achievable when you have to go through a red zone. The inability to pipeline inherently limits the number of processors you can run through the code 'simultaniously'... as long as you do not stall the pipeline, you are ok. So if you a section of code that does this (each letter designates a fine granularity lock surrounding a section of code): A B C D E You can usually assume infinite scaleability (even though it isn't really infinite). While it is true that one processor will stall for a short period when two try to get A, this tends to have a synchronizing effect so the NEXT time the two processors call A, they will tend to do it pre-synchronized and neither will stall (or they will not stall as long). The actual 'virtual' size of the pipeline depends on how various subsystems within the kernel interact with each other. The main design rule you want to follow to minimize the impact of the locks is to avoid 'loops' in the pipeline. A loop --- like the lock sequence: A B C A D E In which A loops, creates a major stall situation. If you follow the pipelining rule, you generally do not have to worry about the scaleability of fine-granularity locks. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:08:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27299 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:08:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA27294 for ; Tue, 5 Jan 1999 15:08:58 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 19645 invoked from network); 5 Jan 1999 23:08:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 5 Jan 1999 23:08:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA01859; Tue, 5 Jan 1999 18:08:11 -0500 (EST) Message-Id: <199901052308.SAA01859@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901052236.OAA97860@apollo.backplane.com> from Matthew Dillon at "Jan 5, 99 02:36:28 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 5 Jan 1999 18:08:11 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > My current argument is to give vm_page_t an aliasing capability - > vm_alias_t's are actually linked into multiple objects and can > alias the same vm_page_t, and thus allows the VM system to maintain > cache coherency between VFS layers up to a break point (e.g. a > file fragment or a VFS device that must translate the contents > of a page, such as RAID-5 or an encryption module), and then use > a more sophisticated (and less efficient) model to bridge the > gaps - aka a cache coherency protocol aka John's 'bidirectional > IPC capability' idea. > Yes, I think that is a good idea (the vm_alias_t's) which support the short circuiting of the complex layering. This is needed for efficiency on local machines. However, this allows for more distributed environements, or less well behaved filesystems, in the worst case. It is good that we are looking at a more general abstraction, and then adding (planned and structured) short-circuit mechanisms for efficiency. This is excellent!!! I think that all of us (including me) have been trying to think of ways to fit the current VFS scheme to reality. That is been irritating to me for quite a while, where I could not come to a reasonable approach or conclusion. Since my break, I have been able to stand back and look at things from a higher level, and finally I just "got tired" of the VFS scheme :-). Since working on the distributed kernel G2, I noticed that such schemes can be liberating. To build a "bidirectional" VM/VFS structure might require a little bit of a supporting infrastructure, but in the longer run, we all will be much more sane :-). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:09:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27473 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:09:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27463 for ; Tue, 5 Jan 1999 15:09:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA98255; Tue, 5 Jan 1999 15:08:57 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 15:08:57 -0800 (PST) From: Matthew Dillon Message-Id: <199901052308.PAA98255@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable References: <199901051847.LAA10199@usr02.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> had historically been split between VFS and VM, and the interfaces were :> defined without both parties understanding the needs. Since that is :> understood now, things should be reworked. : :Hmmm. : :I don't really buy this for the general case, which I believe is :still stacking layers that don't access local media. : :For local media FS's, things which actially do I/O through a page :fault, this is probably correct. Ouch.. no, get away from the 'local media' concept - it's a big time bust. If you make the distinction between hard media and soft media (or local media verses remote media), all you do is screw up the layering model. Even now, traditional hard-media-backed VFS layers such as UFS can be stacked on top of soft media layers such as MFS, which in turn is stacked on top of SWAP (which may be a hard or soft media layer itself). If you throw NFS into the fray it gets worse. It just doesn't work. Also, these sorts of schemes require both interacting VFS layers to have knowledge about each other that goes far beyond what two layers ought to know about each other. -Matt : Terry Lambert : terry@lambert.org :--- Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:18:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29128 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:18:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sydney.alpha.net.au (sydney.alpha.net.au [203.31.171.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29120 for ; Tue, 5 Jan 1999 15:18:23 -0800 (PST) (envelope-from danny@sydney.alpha.net.au) Received: (from danny@localhost) by sydney.alpha.net.au (8.8.5/8.8.5) id KAA26958; Wed, 6 Jan 1999 10:36:54 +1100 (EST) Date: Wed, 6 Jan 1999 10:36:53 +1100 (EST) From: Dan To: Brian Somers cc: Ruslan Ermilov , Brian Somers , FreeBSD Hackers Subject: Some FTP tool called Serverevu Where is the URL In-Reply-To: <199901052223.WAA57122@dev.lan.awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I am trying to look for an FTP tool called serverevu if anyone can find the URL that will be great. Please help reply to me danny@alpha.net.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:23:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29825 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:23:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29819 for ; Tue, 5 Jan 1999 15:22:57 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id SAA50320; Tue, 5 Jan 1999 18:26:35 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 18:26:35 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052303.PAA98165@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Matthew Dillon wrote: > This is a really good analogy, with one change: The problem with > the red zones is not so much that only one spider can go through > it at a time, but of the pipelining that is achievable when you > have to go through a red zone. The inability to pipeline inherently > limits the number of processors you can run through the code > 'simultaniously'... as long as you do not stall the pipeline, > you are ok. > > So if you a section of code that does this (each letter designates a > fine granularity lock surrounding a section of code): > > A B C D E > > You can usually assume infinite scaleability (even though it isn't > really infinite). While it is true that one processor will stall for > a short period when two try to get A, this tends to have a synchronizing > effect so the NEXT time the two processors call A, they will tend to do > it pre-synchronized and neither will stall (or they will not stall as > long). > > The actual 'virtual' size of the pipeline depends on how various > subsystems within the kernel interact with each other. > > The main design rule you want to follow to minimize the impact of > the locks is to avoid 'loops' in the pipeline. A loop --- like the > lock sequence: > > A B C A D E > > In which A loops, creates a major stall situation. If you follow > the pipelining rule, you generally do not have to worry about the > scaleability of fine-granularity locks. this would allow you to define let's say several oprations to be done on processes, in a somewhat OOP manner. Instead of having one lock on each process struct, you can orginize it so that a module of functions lock against each other in such a way that: functions that may munge pointers can't be in use at the same time as functions that change information in the record can not be in use at the same time as functions that return information in the record i'm unsure of the optimal way to orginize this, or if i'm totally off base anyway. thinking more about it, it seems that you would have a read-modify-write problem where an object lock is nessesary, this leads me to think i'm not thinking about this correctly... also the concept of having data move out from under a local pointer becasue of another CPU thread boggles me a bit. -Alfred > > -Matt > > Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet > Communications & God knows what else. > (Please include original email in any response) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:26:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00643 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:26:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00623 for ; Tue, 5 Jan 1999 15:26:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA11176; Tue, 5 Jan 1999 15:23:36 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA01405; Tue, 5 Jan 1999 15:23:35 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA13527; Tue, 5 Jan 1999 16:23:34 -0700 Message-ID: <36929EF6.B771B6F3@softweyr.com> Date: Tue, 05 Jan 1999 16:23:34 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams CC: Bob Bishop , Narvi , Terry Lambert , bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901052008.NAA09332@mt.sri.com> <199901052043.NAA09607@mt.sri.com> <199901052242.PAA10308@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > >A 'critical section of code' is a portion of the code that is accessing > > >a shared resource, which can be protected by using an object lock. > > > > Erm, make that "...accessing *one or more* shared resources.", which is why > > it isn't the same thing as an object lock (except in the degenerate case). > > Sure it is. The object lock is used to 'protect' the shared resources. > This is multithreading/tasking 101 stuff, not rocket science. Well, it is rocket science if you're working on Pathfinder, which had a deadly embrace problem that was diagnosed, fixed, and uploaded about halfway between Earth and Mars. But it is still elementary multi-threaded programming. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:32:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01667 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:32:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01662 for ; Tue, 5 Jan 1999 15:32:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA98527; Tue, 5 Jan 1999 15:32:29 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 15:32:29 -0800 (PST) From: Matthew Dillon Message-Id: <199901052332.PAA98527@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> So if you a section of code that does this (each letter designates a :> fine granularity lock surrounding a section of code): :> :> A B C D E :> :> A B C A D E :> : :this would allow you to define let's say several oprations to be done on :processes, in a somewhat OOP manner. : :Instead of having one lock on each process struct, you can orginize it so :that a module of functions lock against each other in such a way that: I should be more specific: The pipeline rule applies both to structural locks and code space locks. All that matters, really, is that you *NOT* break the pipeline rule. You want to try to make the granularity of the locks around the same in the *time* domain (time spent with lock held). This concept is also unrelated to whether you use a code space lock or a structural lock. Once you are sure you are following the pipelining rule, *THEN* you can try to optimize the parallism by using either code space or structural locks, depending on the situation. :thinking more about it, it seems that you would have a read-modify-write :problem where an object lock is nessesary, this leads me to think i'm not :thinking about this correctly... : :also the concept of having data move out from under a local pointer :becasue of another CPU thread boggles me a bit. : :-Alfred Generally speaking you do not want to use multi-valued locks for SMP operations. i.e. the concept of a 'shared' lock verses an 'exclusive' lock does not work well for locks used to manage SMP functions. The reason it doesn't work well is because of truely serious starvation issues -- it is virtually always more efficient for the fine-grained SMP locks as *only* exclusive locks and then work on optimizing the pipelines. course-grained locks should typically *not* be SMP locks but instead be structural locks with real blocking (the 'go to sleep' type of blocking). The exception, of course, is the One-Big-Lock model: the model is really just a big hack so the normal rules do not apply to it. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:45:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03165 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:45:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03158 for ; Tue, 5 Jan 1999 15:45:40 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA11375; Tue, 5 Jan 1999 15:43:26 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA02004; Tue, 5 Jan 1999 15:43:25 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA13660; Tue, 5 Jan 1999 16:43:24 -0700 Message-ID: <3692A39C.889BF032@softweyr.com> Date: Tue, 05 Jan 1999 16:43:24 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > > The third way (about which Terry did talk) is to have locks around > > > > critical sections. > > > > > > That *is* what an 'object lock' in RTEMS is. > > > > No. An object lock is associated with an object. A critical section > > lock is associated with a section of code. > > An object lock can be associated with a lock that does nothing but > associate itself with a critical section. This type of object is generally known as a "semaphore." > *sheesh* This ain't rocket science. No, and the problems Terry brings up are real, but only because designers have made them real. One of the biggest problems with object-locking systems is the serial acquisition of locks. Say for instance I want to transfer some data from one device to another, and I don't want to add the overhead of buffering it in memory. I acquire the read-lock on the first device, then acquire the write-lock on the second. Once both locks have been acquired, I can transfer the data and release the locks. The problem with this model, which is commonly used, is that I hold the read-lock on the first device while waiting to acquire the write-lock on the second, or vice versa. A parallel waiting system, in which another potential reader of the first device can "take away" my lock if I'm still pending for another resource, alleviates this problem. You have to avoid priority problems when doing this, but inherited priorities are a pretty well understood solution to this problem. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:46:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03297 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:46:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03273; Tue, 5 Jan 1999 15:46:09 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id AAA78885; Wed, 6 Jan 1999 00:45:34 +0100 (CET) (envelope-from des) To: Steven Ji Cc: freebsd-hackers@FreeBSD.ORG, freebsd-advocacy@FreeBSD.ORG Subject: Re: snotty quotes References: From: Dag-Erling Smorgrav Date: 06 Jan 1999 00:45:33 +0100 In-Reply-To: Steven Ji's message of "Sun, 3 Jan 1999 02:00:22 -0500 (EST)" Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Steven Ji writes: > I recently found this alleged Linus Torvalds quote on someone's sig, while > reading through a Linux mailing list archive. > > 'Ooohh.. "FreeBSD is faster over loopback, when compared to > Linux over the wire". Film at 11.' -Linus I don't see the problem with that quote. As I read it, Linus is dismissing someone who's made an inappropriate comparison of FreeBSD and Linux - of *course* FreeBSD is faster over the loopback than Linux over the wire - but the comparison is meaningless, so Linus is making fun of it. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:49:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03659 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:49:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03652 for ; Tue, 5 Jan 1999 15:49:05 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA18673; Tue, 5 Jan 1999 16:48:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA10896; Tue, 5 Jan 1999 16:48:20 -0700 Date: Tue, 5 Jan 1999 16:48:20 -0700 Message-Id: <199901052348.QAA10896@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Wes Peters Cc: Nate Williams , Terry Lambert , narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <3692A39C.889BF032@softweyr.com> References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com> <3692A39C.889BF032@softweyr.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > The third way (about which Terry did talk) is to have locks around > > > > > critical sections. > > > > > > > > That *is* what an 'object lock' in RTEMS is. > > > > > > No. An object lock is associated with an object. A critical section > > > lock is associated with a section of code. > > > > An object lock can be associated with a lock that does nothing but > > associate itself with a critical section. > > This type of object is generally known as a "semaphore." Right, I mentioned this in an early article. > > *sheesh* This ain't rocket science. > > No, and the problems Terry brings up are real, but only because designers > have made them real. One of the biggest problems with object-locking > systems is the serial acquisition of locks. Say for instance I want to > transfer some data from one device to another, and I don't want to add > the overhead of buffering it in memory. I acquire the read-lock on the > first device, then acquire the write-lock on the second. Once both locks > have been acquired, I can transfer the data and release the locks. Can you say potential 'deadlock'? I knew you could. :) > The problem with this model, which is commonly used, is that I hold the > read-lock on the first device while waiting to acquire the write-lock > on the second, or vice versa. A parallel waiting system, in which another > potential reader of the first device can "take away" my lock if I'm still > pending for another resource, alleviates this problem. You have to avoid > priority problems when doing this, but inherited priorities are a pretty > well understood solution to this problem. Right. So how else do you solve the problem of 'protecting' critical sections? I don't see how else to protect them other than using 'object locks' (however you want to call them). If you have multiple shared resources, you still need to get access to them. One of the more common ways I've seen this done is through a 'resource manager' inside of the kernel which guarantees that you 'lock down' the resources in exactly the same order. Unfortunately, this tends to be a bottleneck on highly parallel systems. ;( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:52:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04457 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:52:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04408 for ; Tue, 5 Jan 1999 15:52:40 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id SAA50359; Tue, 5 Jan 1999 18:56:19 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Tue, 5 Jan 1999 18:56:19 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901052332.PAA98527@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Matthew Dillon wrote: > :thinking more about it, it seems that you would have a read-modify-write > :problem where an object lock is nessesary, this leads me to think i'm not > :thinking about this correctly... > : > :also the concept of having data move out from under a local pointer > :becasue of another CPU thread boggles me a bit. > : > :-Alfred > > Generally speaking you do not want to use multi-valued locks for SMP > operations. i.e. the concept of a 'shared' lock verses an 'exclusive' > lock does not work well for locks used to manage SMP functions. The > reason it doesn't work well is because of truely serious starvation > issues -- it is virtually always more efficient for the fine-grained > SMP locks as *only* exclusive locks and then work on optimizing the > pipelines. You may have misunderstood me, several threads could enter a 'read' state, when a 'write' must occur no more threads are allowed into the 'read' state until the 'write' state is complete. All the readers have to drain out of their code before a write can take place. Or is this exactly what you are objecting to? > course-grained locks should typically *not* be SMP locks but instead be > structural locks with real blocking (the 'go to sleep' type of blocking). > The exception, of course, is the One-Big-Lock model: the model is really > just a big hack so the normal rules do not apply to it. Well yes, ala SunOS 4.x.x :) -Alfred -who's finding -current a better source of knowledge than his short college stint :) thanks for the patience and explanations. > > -Matt > > Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet > Communications & God knows what else. > (Please include original email in any response) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 15:54:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04953 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 15:54:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04940 for ; Tue, 5 Jan 1999 15:54:48 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA00926; Tue, 5 Jan 1999 16:54:12 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd000881; Tue Jan 5 16:54:07 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA19601; Tue, 5 Jan 1999 16:53:55 -0700 (MST) From: Terry Lambert Message-Id: <199901052353.QAA19601@usr05.primenet.com> Subject: Re: question about re-entrancy. To: wes@softweyr.com (Wes Peters) Date: Tue, 5 Jan 1999 23:53:55 +0000 (GMT) Cc: tlambert@primenet.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <36929290.2909A074@softweyr.com> from "Wes Peters" at Jan 5, 99 03:30:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Except that out here in the real world uITRON isn't even on the > radar screen. I know it's supposed to be big news with the Japanese > companies who created it, but the numerous projects being done here > in the USA don't even consider it. At all. Ever. There are actually quite a number of uITRON OS's from US companies, starting with eCOS from Cygnus, which is (basically) under a GPL derivative license. The Intel Video Phone Reference Implementation comes with a uITRON compliant OS from a US company ("Inferno" from Lucent): http://developer.intel.com/design/strong/webphone.htm So it's a bit more than a curiousity. Also, FreeBSD has strong Japanese support, and uITRON would only make it stronger. > If you read the RTEMS license page, it is GPL'ed with an exception, and > that exception allows you to create and distribute your product, linked > with RTEMS, without restraint. In effect, they're using the LGPL with > no source distribution clause. > > The original RTEMS license was much more Berkeley like, but they found > a couple of "clients" who were not contributing fixes back and it > sorta ticked them off, so they went with this instead. Go figure. Yeah. The problem is that they are using BSD TCP/IP code, and as a result, the requirement for source distribution is highly questionable. If you don't have a legally valid license to use the stuff, you don't have any license to use the stuff. > Whether this is a problem or not depends on your system architecture. In > embedded systems, where the interactions between parts of the architecture > are generally both simpler and more limited than in a large, general- > purpose computer, contention on the critical objects often is not much > of a consideration, because the various system objects have such limited > interactions. This is also true of, for instance, I/O processors > communicating with a main system processor. > > RTEMS remains a good example of a working object-locking system that > can scale quite easily to a moderate number of processors. OK, I'll buy that, if you'll buy that SVR4 is a good example of a working object-locking system that can only scale to 4 processors. ;-). The problem is that FreeBSD is more similar in the tasks it runs to SVR4 than it is to an RTOS. Even with RT features, I think this would stay true... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:01:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06458 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:01:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06438 for ; Tue, 5 Jan 1999 16:01:38 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA03396; Tue, 5 Jan 1999 15:51:28 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdOX3390; Tue Jan 5 23:51:17 1999 Date: Tue, 5 Jan 1999 15:51:13 -0800 (PST) From: Julian Elischer To: Jason Evans cc: Kelly Yancey , freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... In-Reply-To: <369296F4.AE24010B@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Jason Evans wrote: > Kelly Yancey wrote: > > > one more thing, a dirty secret in FreeBSD is that all threads are done as > > > ONE process, if you have multiple CPUs you do not gain the advantage of > > > multiple processors, you have to design a hybrid fork/thread model. > > > > > > > Argh. Is this going to be fixed in 3.0? Does anyone intend on fixing > > it? I mean, even Linux has kernel support for threads, I should think > > that FreeBSD...the king of server OS'es...could at least do the same. > > For the time being this isn't a problem, as I only have a single CPU, > > but I'm really going to need FreeBSD to support scheduling threads on > > separate processors by the time I finish the project. I *really* like > > FreeBSD, but if I have to I suppose Linux will be the target platform if > > 3.0 can't schedule threads independantly. > > Things aren't quite that simple. Linux's 1-1 kernel threads model has some > problems, such as slow thread switching (as compared to a user-land threads > implementation), slow thread creation, and some scalability issues I've > noticed when creating large numbers of threads. > > To ask if FreeBSD's threads library is going to be "fixed" to work like > Linux's threads library is IMO a poor question, since my observation has > been that there are more performance problems that reach out and bite the > programmer with LinuxThreads than with FreeBSD's user-land threads. > > Implementing a threads library that performs well for a wide range of > applications is a very difficult (though feasible) task. Thus far, none of > the free OSes have come up with such a beast. In fact we have a port of the linux threads to FreeBSD so we can do EXACTLY what they do, including the kernel support. It's being worked on as we speak. Some is already committed to -current. There is little argumant however that the ultimate is to schedule N threads over M processes where M is related to teh number of CPUs available. > > Jason > > -- > Jason Evans > Email: [jasone@canonware.com] > Web: [http://www.canonware.com/~jasone] > Home phone: [(650) 856-8204] > Work phone: [(415) 808-8742] > Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison] > > 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 Jan 5 16:02:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07138 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:02:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07124 for ; Tue, 5 Jan 1999 16:02:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA11587; Tue, 5 Jan 1999 16:00:27 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA02468; Tue, 5 Jan 1999 16:00:25 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA13793; Tue, 5 Jan 1999 17:00:23 -0700 Message-ID: <3692A797.975E8433@softweyr.com> Date: Tue, 05 Jan 1999 17:00:23 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901052008.NAA09332@mt.sri.com> <199901052245.PAA24981@usr02.primenet.com> <199901052249.PAA10421@mt.sri.com> <3692A39C.889BF032@softweyr.com> <199901052348.QAA10896@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > The problem with this model, which is commonly used, is that I hold the > > read-lock on the first device while waiting to acquire the write-lock > > on the second, or vice versa. A parallel waiting system, in which another > > potential reader of the first device can "take away" my lock if I'm still > > pending for another resource, alleviates this problem. You have to avoid > > priority problems when doing this, but inherited priorities are a pretty > > well understood solution to this problem. > > One of the more common ways I've seen this done is through a 'resource > manager' inside of the kernel which guarantees that you 'lock down' the > resources in exactly the same order. Unfortunately, this tends to be a > bottleneck on highly parallel systems. ;( I guess your "resource manager" *is* my "parallel waiting system." I've only looked at this in a deeply embedded context, where the 3 processors share a single coherent cache and transaction-oriented memory bus, so my experience may not be completely scalable. I should add that it's not working yet either. ;^) The working idea is that if I have acquired a lock on one of a set of objects, but not all of the objects (therefore I'm sleeping), a higher priority task can 'steal back' an object from me. While quite flexible, it requires *very careful attention* to priorities, and opens up avenues to deadlocks that boggle the mind. In our particular application, it is quite a neat little trick, where we have three processors and what amounts to seven input queues and seven output queues, and need to route data between 1..7 of the queues at a time. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:09:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08748 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:09:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08742 for ; Tue, 5 Jan 1999 16:09:14 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA05998; Tue, 5 Jan 1999 17:08:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd005955; Tue Jan 5 17:08:30 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA20555; Tue, 5 Jan 1999 17:08:29 -0700 (MST) From: Terry Lambert Message-Id: <199901060008.RAA20555@usr05.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Wed, 6 Jan 1999 00:08:28 +0000 (GMT) Cc: rb@gid.co.uk, nate@mt.sri.com, narvi@haldjas.folklore.ee, tlambert@primenet.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901052242.PAA10308@mt.sri.com> from "Nate Williams" at Jan 5, 99 03:42:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >A 'critical section of code' is a portion of the code that is accessing > > >a shared resource, which can be protected by using an object lock. > > > > Erm, make that "...accessing *one or more* shared resources.", which is why > > it isn't the same thing as an object lock (except in the degenerate case). > > Sure it is. The object lock is used to 'protect' the shared resources. > This is multithreading/tasking 101 stuff, not rocket science. OK. Think about it like this. I have an object that's on two lists at the same time: struct some_object { struct some_object *list_1_next; struct some_object *list_1_prev; struct some_object *list_2_next; struct some_object *list_2_prev; ... } This happens all the time with all sorts of kernel structures. If I have a lock associated with the object, I have two functions: LRU_object_on_list_1( struct some_object *objp) { LOCK(objp); move_to_head( &objp->list_1_next, list_1_head); UNLOCK(objp); } LRU_object_on_list_2( struct some_object *objp) { LOCK(objp); move_to_head( &objp->list_2_next, list_2_head); UNLOCK(objp); } Notice that I can't enter both at the same time without blocking because I'm locking the object instead of the code. Yes, this is a gross oversimplification: I could deal with this with list locks or two locks associated with the object, or whatever. But to obtain the list lock, I'd need to lock the object anyway before it was safe to dereference the pointer and acquire the lock on the list object (assuming that you had to lock the list object to remove references to it). I can't do the same thing for a user lock list and a VM page list hung of a a vm_object_t hung off a vnode, as a rather more complicated and at the same time more real example. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:14:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09441 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:14:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09432 for ; Tue, 5 Jan 1999 16:14:01 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA18927; Tue, 5 Jan 1999 17:13:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA11201; Tue, 5 Jan 1999 17:13:20 -0700 Date: Tue, 5 Jan 1999 17:13:20 -0700 Message-Id: <199901060013.RAA11201@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901060008.RAA20555@usr05.primenet.com> References: <199901052242.PAA10308@mt.sri.com> <199901060008.RAA20555@usr05.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >A 'critical section of code' is a portion of the code that is accessing > > > >a shared resource, which can be protected by using an object lock. > > > > > > Erm, make that "...accessing *one or more* shared resources.", which is why > > > it isn't the same thing as an object lock (except in the degenerate case). > > > > Sure it is. The object lock is used to 'protect' the shared resources. > > This is multithreading/tasking 101 stuff, not rocket science. > > > OK. > > Think about it like this. > > I have an object that's on two lists at the same time: > > struct some_object { > struct some_object *list_1_next; > struct some_object *list_1_prev; > struct some_object *list_2_next; > struct some_object *list_2_prev; > ... > } > > This happens all the time with all sorts of kernel structures. > > > If I have a lock associated with the object, I have two functions: > > LRU_object_on_list_1( struct some_object *objp) > { > LOCK(objp); > move_to_head( &objp->list_1_next, list_1_head); > UNLOCK(objp); > } > > LRU_object_on_list_2( struct some_object *objp) > { > LOCK(objp); > move_to_head( &objp->list_2_next, list_2_head); > UNLOCK(objp); > } > > Notice that I can't enter both at the same time without blocking > because I'm locking the object instead of the code. That's one way of doing it, yes. If the *only* place where both lists was being modified was a single piece of code, then you don't need to lock-down both lists separately, hence you could use a single lock. If you there are multiple places where the list could be locked down, you have no choice in the matter. You *must* use object locks, (or something similar to them), else you end up with the 'Big Giant Lock' problem. > Yes, this is a gross oversimplification: I could deal with this > with list locks or two locks associated with the object, or whatever. > But to obtain the list lock, I'd need to lock the object anyway > before it was safe to dereference the pointer and acquire the lock > on the list object (assuming that you had to lock the list object > to remove references to it). Right, and how do you propose to do this w/out object locks? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:20:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10041 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:20:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09997 for ; Tue, 5 Jan 1999 16:20:03 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA10921; Tue, 5 Jan 1999 17:19:35 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd010864; Tue Jan 5 17:19:32 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA20813; Tue, 5 Jan 1999 17:19:25 -0700 (MST) From: Terry Lambert Message-Id: <199901060019.RAA20813@usr05.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Wed, 6 Jan 1999 00:19:25 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901052248.PAA10395@mt.sri.com> from "Nate Williams" at Jan 5, 99 03:48:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Huh? Differentiate between 'protecting a critical section and using > object locks?'. (Assumin that 'aquire' with no parameters block > indefinitely until the lock is gained. If you want something else, use > something else.) [ ... ] > > Having critical sections that can be locked WITH THEIR OWN INIDIVIDUAL > > LOCKS is a far cry from suggesting that critical sections should be > > protected with The Big Giant Lock(tm). > > And you can use 'individual locks' inside RTEMS. How is this different > than 'locking down critical sections w/out using object locks'? See my other (recent) posting. Basically, if you lock the code, you can enter the object multiple times for non-conflicting code, but if you lock the object, you can only enter it once. So if I had one CPU responding to a disk controller interrupt to update the pages hung of a vnode as a result of a demand page, and I had another CPU that wanted to assert an advisory lock on the vnode, the second CPU would have to wait to access the vnode using object locks, but it wouldn't have to wait using critical section locks becuase the operations each CPU wanted to apply to the vnode are non-conflicting unless you artificially limit the collision domain to object granularity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:23:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10454 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:23:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10448 for ; Tue, 5 Jan 1999 16:23:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id QAA98857; Tue, 5 Jan 1999 16:22:34 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 16:22:34 -0800 (PST) From: Matthew Dillon Message-Id: <199901060022.QAA98857@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> : :> :-Alfred :> :> Generally speaking you do not want to use multi-valued locks for SMP :> operations. i.e. the concept of a 'shared' lock verses an 'exclusive' :> lock does not work well for locks used to manage SMP functions. The :> reason it doesn't work well is because of truely serious starvation :> issues -- it is virtually always more efficient for the fine-grained :> SMP locks as *only* exclusive locks and then work on optimizing the :> pipelines. : :You may have misunderstood me, several threads could enter a 'read' state, :when a 'write' must occur no more threads are allowed into the 'read' :state until the 'write' state is complete. All the readers have to drain :out of their code before a write can take place. : :Or is this exactly what you are objecting to? This is the typical hack that people make, but it isn't a good idea, especially for a fine-grained SMP lock. The reason it isn't a good idea is multi-fold fold: First, it adds complexity and cpu cycles to the locking mechanism that can often equal the complexity of the code being locked, making the result less efficient. Second, because we are talking about fine-grained SMP locks here, not course-grained locks, and it is more important to maintain the time locality of the pipeline then to try to optimize parallel readers, because even if you can use read-locks in one section of code you won't be able to use them everywhere, so parallelizing one section of code doesn't gain you anything when you have to serialize another other then destroying the time locality of the pipeline. The 'bunching' that occurs with multiple cpu's all trying for the same lock destroys the efficiency of the *hardware* cache coherency mechanisms, further slowing things down. But if the processes are already pipelined, the memory location containing the lock tends to be 'free', allowing a cpu to grab it more quickly. Third, because you have a lock starvation issue even when you block further readers unless you also block further writers in the face of a held write lock and pending reader requests. This can lead into flip-flop situations which devolve down into just doing an exclusive lock in the first place... but with a less efficient locking mechanism. You have to protect against the inefficient flip-flop situation. Fourth, when you have multiple cpu's vying for the *same* lock (the bunching, again), not only is hardware cache coherency strained but you get into the situation where cpu's can jump ahead of each other going through the same pipeline. This disrupts the pipeline further, creating temporary interlocks and more bunching down the line, destroying the time locality of the pipeline. Usually for a fine-grained SMP lock, the key issue is to be able to get and release the lock as quickly as possible. If it takes 4 cpu cycles to get a simple lock and 4 to release it in a pipeline, it might take 8 cpu cycles to get a read/write lock (and 4 to release it). When vying for the *same* lock, it might take 10 cycles to get it and 8 cycles to release it due to hardware cache coherency collisions (or even memory commit collisions!). If this is a fine-grained SMP lock, there is probably only one or two cpu's going through it even in a 128-cpu SMP machine. You want to optimize for the case that is most likely to occur and make it go as fast as possible. -Matt :> course-grained locks should typically *not* be SMP locks but instead be :> structural locks with real blocking (the 'go to sleep' type of blocking). :> The exception, of course, is the One-Big-Lock model: the model is really :> just a big hack so the normal rules do not apply to it. : :Well yes, ala SunOS 4.x.x :) : :-Alfred :-who's finding -current a better source of knowledge than his short :college stint :) : :thanks for the patience and explanations. Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:23:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10509 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:23:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10470 for ; Tue, 5 Jan 1999 16:23:09 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA19001; Tue, 5 Jan 1999 17:22:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA11275; Tue, 5 Jan 1999 17:22:36 -0700 Date: Tue, 5 Jan 1999 17:22:36 -0700 Message-Id: <199901060022.RAA11275@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901060019.RAA20813@usr05.primenet.com> References: <199901052248.PAA10395@mt.sri.com> <199901060019.RAA20813@usr05.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Huh? Differentiate between 'protecting a critical section and using > > object locks?'. (Assumin that 'aquire' with no parameters block > > indefinitely until the lock is gained. If you want something else, use > > something else.) > > [ ... ] > > > > Having critical sections that can be locked WITH THEIR OWN INIDIVIDUAL > > > LOCKS is a far cry from suggesting that critical sections should be > > > protected with The Big Giant Lock(tm). > > > > And you can use 'individual locks' inside RTEMS. How is this different > > than 'locking down critical sections w/out using object locks'? > > See my other (recent) posting. > > Basically, if you lock the code, you can enter the object multiple > times for non-conflicting code, but if you lock the object, you can > only enter it once. Not necessarily. A good locking implementation can realize that you've already gotten the lock, and can let you continue to keep it. (References, etc..) Not too difficult to do, as long as you can uniquely ID each individual 'thread of execution'. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:25:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10909 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:25:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10904 for ; Tue, 5 Jan 1999 16:25:51 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA11833; Tue, 5 Jan 1999 16:24:56 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA03090; Tue, 5 Jan 1999 16:24:55 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA14095; Tue, 5 Jan 1999 17:24:55 -0700 Message-ID: <3692AD56.224F04D4@softweyr.com> Date: Tue, 05 Jan 1999 17:24:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901052353.QAA19601@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > Except that out here in the real world uITRON isn't even on the > > radar screen. I know it's supposed to be big news with the Japanese > > companies who created it, but the numerous projects being done here > > in the USA don't even consider it. At all. Ever. > > There are actually quite a number of uITRON OS's from US companies, > starting with eCOS from Cygnus, which is (basically) under a GPL > derivative license. > > The Intel Video Phone Reference Implementation comes with a uITRON > compliant OS from a US company ("Inferno" from Lucent): > > http://developer.intel.com/design/strong/webphone.htm On the other hand, their proposed new standard for "information appliances," with which I am *intimately* familiar, is based on VxWorks which is NOT uITRON compliant, and IS the biggest-selling (32-bit) embedded OS around. Unless AMX/PalmOS has overtaken it, but they're not uITRON compatible either. > So it's a bit more than a curiousity. Also, FreeBSD has strong > Japanese support, and uITRON would only make it stronger. But only a bit more than a curioustiy. Like most standards, it seems to standardize the stuff that didn't differ that much, and remain mute on the parts where you really NEED some standards. RTEMS and VxWorks have both chosen the path of implementing the Posix real-time interface as much as possible. I believe this is probably of more near-term benefit, and probably more long-term benefit as well. It certainly makes it much more straightforward to port UNIX network servers into the embedded space. > > The original RTEMS license was much more Berkeley like, but they found > > a couple of "clients" who were not contributing fixes back and it > > sorta ticked them off, so they went with this instead. Go figure. > > Yeah. The problem is that they are using BSD TCP/IP code, and as a > result, the requirement for source distribution is highly questionable. > If you don't have a legally valid license to use the stuff, you don't > have any license to use the stuff. I've spoken with Joel about this a couple of times, but it doesn't seem that they will move to clean it up until someone calls them on it. Since the networking stack was lifted straight from FreeBSD, maybe I should put my FreeBSD-Advocate hat on and call the head honcho? Nah, it just doesn't bother me all that much. > > RTEMS remains a good example of a working object-locking system that > > can scale quite easily to a moderate number of processors. > > OK, I'll buy that, if you'll buy that SVR4 is a good example of a > working object-locking system that can only scale to 4 processors. > > ;-). Except as hacked by Sun. See, i.e., E10000. ;^) > The problem is that FreeBSD is more similar in the tasks it runs to > SVR4 than it is to an RTOS. Even with RT features, I think this > would stay true... I don't dispute that at all, just your statement that object locking is inherently bad. It's only bad if it interacts badly with the system you're trying to develop. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 16:45:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13758 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:45:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13751 for ; Tue, 5 Jan 1999 16:45:56 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA22513; Tue, 5 Jan 1999 17:45:19 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd022275; Tue Jan 5 17:44:55 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA22046; Tue, 5 Jan 1999 17:44:48 -0700 (MST) From: Terry Lambert Message-Id: <199901060044.RAA22046@usr05.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 6 Jan 1999 00:44:48 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901052308.PAA98255@apollo.backplane.com> from "Matthew Dillon" at Jan 5, 99 03:08:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :I don't really buy this for the general case, which I believe is > :still stacking layers that don't access local media. > : > :For local media FS's, things which actially do I/O through a page > :fault, this is probably correct. > > Ouch.. no, get away from the 'local media' concept - it's a big time > bust. If you make the distinction between hard media and soft media > (or local media verses remote media), all you do is screw up the layering > model. Even now, traditional hard-media-backed VFS layers such as UFS > can be stacked on top of soft media layers such as MFS, which in turn > is stacked on top of SWAP (which may be a hard or soft media layer > itself). If you throw NFS into the fray it gets worse. It just doesn't > work. Also, these sorts of schemes require both interacting VFS layers > to have knowledge about each other that goes far beyond what two > layers ought to know about each other. The distinction I'm trying to make is between VFS layers that are VFS consumers and providers, and VFS layers that that are VFS providers, but VM system consumers. VM system consumers are "local media" FS's. As soon as VFS stacking finally works in the main line FreeBSD, I expect the VFS provider and consumer layers to literally explode through the roof. Because of this, I think it's necessary to think in terms of abstracting the VM complications as much as possible. I have a real problem with the idea of VM alias objects instead of a mechanism for asking for the vnode off of which is hung the real backing object so that I can forwar VOP_GETPAGE/VOP_PUTPAGES against it. The problem is in ensuring object coherency. Here we have this enormous investment in a unified VM and buffer cache, which is mostly just a way for us to avoid the coherency complications that having seperate VM and buffer cache cause, and we're talking about doing something that will reintroduce the complications. Right now there's some obvious problems; the point of an msync() is to ensure that the buffer cache and the VM are coherent. In theory, a unified VM and buffer cache doesn't need an msync() call at all, right? Yet INN fails under FreeBSD in the file extension case unless you insert an msync() call. Yeah, you should expect to have to msync() in an SVR4 environment, and in OpenBSD and maybe NetBSD (current UVM code), but FreeBSD isn't supposed to need this. Yet it does. If a coherency problem must be solved by an explicit call to notify the OS of a boundary crossing condition, then there is a unification error, plain and simple. I think that introducing an alias object is a mistake. It's possible to get an alias object implementation correct, if you are very, very careful in your implementation. But the same can be said about mmap() coherency, and I'm not bold enough to believe that I'm the guy who saw the last problem in that area. Maybe I'm coming in in the middle of a long private discussion (it feels like it, and Julian has hinted that I am), but I think that its necessary to fix some of the things we all know are broken before we try to get tricky... my 2 cents. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:03:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16379 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:03:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16369 for ; Tue, 5 Jan 1999 17:03:31 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA16899; Tue, 5 Jan 1999 18:02:59 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd016808; Tue Jan 5 18:02:49 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA22729; Tue, 5 Jan 1999 18:02:42 -0700 (MST) From: Terry Lambert Message-Id: <199901060102.SAA22729@usr05.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Wed, 6 Jan 1999 01:02:42 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901060022.RAA11275@mt.sri.com> from "Nate Williams" at Jan 5, 99 05:22:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Basically, if you lock the code, you can enter the object multiple > > times for non-conflicting code, but if you lock the object, you can > > only enter it once. > > Not necessarily. A good locking implementation can realize that you've > already gotten the lock, and can let you continue to keep it. > (References, etc..) Not too difficult to do, as long as you can > uniquely ID each individual 'thread of execution'. This is true if you are locking from the same thread. My hidden assumption, which I guess I didn't communicate very well, even though I thought it was clear in context of the discussion is that you have two different entities trying to enter the object. A prime example of a place where this happens with great frequency is the /tmp directory, with all sorts of processes creating all sorts of temporary files. For example, a "make -j8" on an 8 CPU machine can beat the hell out of the directory vnode, and will end up not giving you the throughput you expect because of this, even though there's relatively little "real" contention for the create, since most of the time is spent in the read-traversal of the directory entry blocks already there to make sure the file that's to be created doesn't already exist. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:13:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17506 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:13:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17500 for ; Tue, 5 Jan 1999 17:13:14 -0800 (PST) (envelope-from witr@rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id UAA12204; Tue, 5 Jan 1999 20:12:36 -0500 (EST) (envelope-from witr@rwwa.com) Message-Id: <199901060112.UAA12204@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Alfred Perlstein cc: Robert Withrow , hackers@FreeBSD.ORG, witr@rwwa.com Subject: Re: 3.0-REL NFS interop problems redux In-reply-to: Your message of "Tue, 05 Jan 1999 17:24:52 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Jan 1999 20:12:35 -0500 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG bright@hotjobs.com said: :- as a workaround, have you tried: :- a) tcp mounts b) nfs 3 I can only mount the way that the AMD maps (which I don't control) mount. Our maps have about >1,000 different mount points and the maps work fine for SunOs, Solaris, Linux, Hpux, etc. People will laugh if I ask them to change the maps. :- c) cvsup'ing to a new -current (there was some problems with signals :- being delivered during NFS activity in -release) Not an option. I have to deploy a released version, with a possibly patched kernel. I'm not able to deploy a -current version. bright@hotjobs.com said: :- you also may want to look into the bugfixes that were done :- post-release Where can I found out about them? Thanks! --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:20:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18221 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:20:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18210 for ; Tue, 5 Jan 1999 17:20:02 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA23329; Tue, 5 Jan 1999 18:19:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd023223; Tue Jan 5 18:19:26 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA23425; Tue, 5 Jan 1999 18:19:09 -0700 (MST) From: Terry Lambert Message-Id: <199901060119.SAA23425@usr05.primenet.com> Subject: Re: question about re-entrancy. To: nate@mt.sri.com (Nate Williams) Date: Wed, 6 Jan 1999 01:19:09 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901060013.RAA11201@mt.sri.com> from "Nate Williams" at Jan 5, 99 05:13:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Notice that I can't enter both at the same time without blocking > > because I'm locking the object instead of the code. > > That's one way of doing it, yes. If the *only* place where both lists > was being modified was a single piece of code, then you don't need to > lock-down both lists separately, hence you could use a single lock. > > If you there are multiple places where the list could be locked down, > you have no choice in the matter. You *must* use object locks, (or > something similar to them), else you end up with the 'Big Giant Lock' > problem. I think it's a lesser problem than that, but that's just a matter of scale, not of kind, so yeah, given a specific way of looking at it, you're right. I think that having multiple places that need to lock is Bad(tm). I think that, architecturally, you need to constrain the conflict zones to avoid the problem. One way of doing this would be to use an inline accessor function and not change the code layout, but that's the same thing in all but name. If I lock code in a constrained path, and I further avoid any constrained paths as mush as I can, I think that code locks end up causing less contention. You would need to to instance "lockables" into a hierarchical relationship so that you could do very fast deadlock detection, but most of the time other CPU's would not be in the same place at the same time, so acquisition would be ~4 clocks for the common case. Consider the case where you are doing advisory locking. You could lock the object before passing it down to the common lock manager code, but this would prevent other contexts from entering the object in the FS during the whole time you are doing the lock, even if they are doing something unrelated to advisory locking. This is an artificial collision. I guess you could call the nodes in the hierarchy relationship "objects", and the locks on the lockables "object locks" if you wanted to. > > Yes, this is a gross oversimplification: I could deal with this > > with list locks or two locks associated with the object, or whatever. > > But to obtain the list lock, I'd need to lock the object anyway > > before it was safe to dereference the pointer and acquire the lock > > on the list object (assuming that you had to lock the list object > > to remove references to it). > > Right, and how do you propose to do this w/out object locks? By locking entry to the code that does the manipulation instead. I guess a function could be considered an object too... 8-). This also lets me document my lock state in and out, and ASSERT() the lock state in an out in the DIAGNOSTIC case. That's very close to the code coverage you would get from a full branch path analysis, with the side benefit that the function gets a bit of protection against obvious coding errors by making them obvious in context without a code reviewer having to get his or her head around the whole thing. A bit of an improvement in process over what you have to do when trying to go through some of the existing code, you have to admit... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:21:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18477 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:21:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18469 for ; Tue, 5 Jan 1999 17:21:53 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id SAA19556; Tue, 5 Jan 1999 18:21:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA11791; Tue, 5 Jan 1999 18:21:20 -0700 Date: Tue, 5 Jan 1999 18:21:20 -0700 Message-Id: <199901060121.SAA11791@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901060102.SAA22729@usr05.primenet.com> References: <199901060022.RAA11275@mt.sri.com> <199901060102.SAA22729@usr05.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Basically, if you lock the code, you can enter the object multiple > > > times for non-conflicting code, but if you lock the object, you can > > > only enter it once. > > > > Not necessarily. A good locking implementation can realize that you've > > already gotten the lock, and can let you continue to keep it. > > (References, etc..) Not too difficult to do, as long as you can > > uniquely ID each individual 'thread of execution'. > > This is true if you are locking from the same thread. My hidden > assumption, which I guess I didn't communicate very well, even > though I thought it was clear in context of the discussion is that > you have two different entities trying to enter the object. Fair enough. How do you determine if an object can be entered multiple times via 'non-conflicting' code? If you can determine it from the code-base, then you can also determine it for object locks. 6 of one, half-dozen of the other. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:25:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19493 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:25:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19486 for ; Tue, 5 Jan 1999 17:25:25 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id LAA12049; Wed, 6 Jan 1999 11:54:46 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199901051615.JAA04090@mt.sri.com> Date: Wed, 06 Jan 1999 11:55:33 +1030 (CST) From: "Daniel O'Connor" To: Nate Williams Subject: Re: psm0 on laptops. Cc: hackers@FreeBSD.ORG, Darren Reed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 05-Jan-99 Nate Williams wrote: > Not that I'm aware of. If you have it plugged in to the PS/2 port, you > *can* switch to the serial version after bootup by physically switching > it and re-configured X to use the serial port version. Use moused and tell X to use sysmouse, thats why its there. Then X gets events from both mice :) > The reason it works under Windblows is because the mouse driver is a > necessary part of the OS, and under FreeBSD it's just another device so > the OS/userland stuff isn't integrated like under Windows. (Which also > explains why unix is generally more robust, since not everything is > integrated together with the OS...) Its still a pitty you can't tell the psm driver to reprobe the mouse... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:28:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19903 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:28:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nu.binary.net (nu.binary.net [12.13.120.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19898 for ; Tue, 5 Jan 1999 17:28:05 -0800 (PST) (envelope-from nathan@rtfm.net) Received: from matrix.binary.net (nathan@matrix.binary.net [12.13.120.2]) by nu.binary.net (8.9.1a/8.9.0) with ESMTP id TAA18652; Tue, 5 Jan 1999 19:27:37 -0600 (CST) Received: (from nathan@localhost) by matrix.binary.net (8.9.1a/8.9.1) id TAA17273; Tue, 5 Jan 1999 19:27:36 -0600 (CST) Message-ID: <19990105202736.B16219@rtfm.net> Date: Tue, 5 Jan 1999 20:27:36 -0500 From: Nathan Dorfman To: Alfred Perlstein , "John W. DeBoskey" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: cdrecord / projected & actual sizes don't seem right References: <199901042116.QAA28139@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Alfred Perlstein on Mon, Jan 04, 1999 at 05:41:40PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 04, 1999 at 05:41:40PM -0500, Alfred Perlstein wrote: > > On Mon, 4 Jan 1999, John W. DeBoskey wrote: > > > Hi, > > > > I'm using cdrecord 1.6.1 on a -current system. I've run into > > a size/time issue that I don't seem to have any luck figuring out. > > > > I am using 73 minute cd-r media. When I run cdrecord to write > > the isofs to the cd media, everything seems to work correctly, but > > the process is stopping prematurely. Could someone with more > > experience shed some light on where I need to look to figure out > > what I'm doing wrong? The sense Blk invalid msg below is also > > interesting. > > i just purchased my own CD-RW, ( i think it's the same model as yours ) > > try running cdrecord with nice -18: (from the man page) > > cd /cdwork > nice -18 cdrecord dev=5,0 speed=4 -v cd1.image > > try not to jostle (sp?) the machine while recording, what i mean is don't > start up something likely to cause pageing, it'll probably ruin the burn. > > you may even want to run it with 'rtprio' but i haven't tried that myself > yet. > > i just got it last night and had a bit of trouble using RW media, but i > haven't tried it with 'nice -18' yet, i'll see what helps me in that > situation and post about it. I have the same CD-RW drive (Yamaha CDRW-4260), running cdrecord 1.6.1 on -current. I have no problems with burning whatsoever. I never run cdrecord with any special priorities (nice, rtprio, etc.). On the contrary, it always runs with X running, and Netscape, mp3 player, and other miscellaneous applications are sometimes open. Never any buffer overruns or anything similar, I've never even noticed the fifo dip below 95% full! John, as for your error, I have never seen it before but it looks like it writes the data fine and then chokes on fixate...nice -anything wouldn't affect this as it's not a buffer overrun but some kind of real error. How many times have you tried it? Maybe the media is faulty? Try a different brand of CD-R media and see if you get the same error? Al, as for your error, I've been using RW media with cdrecord, -current, and the CDRW4260 ever since I got it. What's the problem you're having? Maybe you're forgetting that a) you need to blank CDRW media before recording onto it, cdrecord blank=all or b) the drive writes RW media at 2x, so set speed=2. > -Alfred > > > > > Oh well, > > Thanks! > > John > > > > Fixating... > > cdrecord: Input/output error. close track/session: scsi sendcmd: retryable error > > CDB: 5B 00 02 00 00 00 00 00 00 00 > > status: 0x2 (CHECK CONDITION) > > Sense Bytes: 70 00 04 D1 C0 00 00 0A 00 00 00 00 09 01 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 01 06 > > Sense Key: 0x4 Hardware Error, Segment 0 > > Sense Code: 0x09 Qual 0x01 (tracking servo failure) Fru 0x0 > > Sense flags: Blk -775946240 (not valid) > > cmd finished after 41.576s timeout 480s > > Fixating time: 43.587s > > cdrecord: fifo had 9194 puts and 9127 gets. > > cdrecord: fifo was 0 times empty and 9126 times full, min fill was 98%. -- ________________ ___________________________________________ / Nathan Dorfman \ / "`IE4 brings the web to UNIX'? *laughing* / nathan@rtfm.net \/ Isn't that similar to Ronald McDonald bringing / finger for PGP key \ religion to the pope?" -Jamie Bowden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 17:47:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22502 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 17:47:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns3.redbacknetworks.com (mail3.redbacknetworks.com [155.53.200.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22494 for ; Tue, 5 Jan 1999 17:47:04 -0800 (PST) (envelope-from sam@redbacknetworks.com) Received: from phred.redbacknetworks.com (phred.redbacknetworks.com [155.53.144.35]) by ns3.redbacknetworks.com (8.8.8/8.8.8) with ESMTP id RAA19849; Tue, 5 Jan 1999 17:46:35 -0800 (PST) Received: (from sam@localhost) by phred.redbacknetworks.com (8.8.5/8.8.5) id RAA02359; Tue, 5 Jan 1999 17:45:45 -0800 (PST) Date: Tue, 5 Jan 1999 17:45:45 -0800 (PST) Message-Id: <199901060145.RAA02359@phred.redbacknetworks.com> From: Sam Pigg To: tor.egge@fast.no CC: hackers@FreeBSD.ORG Subject: Re: tyan S1836DLUAN >512Mb problem Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tor- Hey just wanted to let you know that your suggestions worked. I set: options "VM_KMEM_SIZE=(128*1024*1024)" options "VM_KMEM_SIZE_MAX=(128*1024*1024)" options "MAXMEM=(1024*1024)" Makefile.i386: LOAD_ADDRESS?= E0100000 and pmap.h: #ifndef NKPDE #ifdef SMP #define NKPDE 126 /* addressable number of page tables/pde's */ #else #define NKPDE 127 /* addressable number of page tables/pde's */ all the memory was finally usable. Thanks much, -Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 18:07:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25016 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 18:07:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25011 for ; Tue, 5 Jan 1999 18:07:21 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA10884 for ; Wed, 6 Jan 1999 12:36:25 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id MAA84036 for hackers@freebsd.org; Wed, 6 Jan 1999 12:36:28 +1030 (CST) Date: Wed, 6 Jan 1999 12:36:28 +1030 From: Greg Lehey To: FreeBSD Hackers Subject: Unlocking vnodes from different processes Message-ID: <19990106123627.N78349@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In Vinum, I sometimes need to lock a vnode in one process and unlock it in another. Since 3.0, I've been getting panics when I do this: panicstr: lockmgr: pid 429, not exclusive lock holder 428 unlocking Can I assume that the other parameters (flag, p) to VOP_UNLOCK will enable me to do this anyway? Also, since I don't perform the lock directly (it happens as a side-effect of opening the vnode), is there a kosher way to find out what process locked the vnode? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 18:09:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25443 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 18:09:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25437 for ; Tue, 5 Jan 1999 18:09:25 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:eH+UcvN9yE0Vu7ML0uc5ILZftr/0oJmx@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id LAA14445; Wed, 6 Jan 1999 11:08:35 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA26565; Wed, 6 Jan 1999 11:10:57 +0900 (JST) Message-Id: <199901060210.LAA26565@zodiac.mech.utsunomiya-u.ac.jp> To: Terry Lambert cc: yokota@zodiac.mech.utsunomiya-u.ac.jp, hackers@FreeBSD.ORG Subject: Re: psm0 on laptops. In-reply-to: Your message of "Tue, 05 Jan 1999 18:58:43 GMT." <199901051858.LAA10934@usr02.primenet.com> References: <199901051858.LAA10934@usr02.primenet.com> Date: Wed, 06 Jan 1999 11:10:56 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I don't know how the W*ndows PS/2 mouse driver can detect that a new >> mouse has suddenly appeared at the PS/2 mouse port and switch to a >> different protocol. You see, both the internal PS/2 mouse/pointing >> device and the external device are wired to the same PS/2 mouse >> port... > >If you have access to the Micorsoft DDK (Device Driver Kit), it >contains the Microsoft mouse driver source code. Including the >code that is used to probe serial ports for mice without mucking >up modems. We are talking about *PS/2 mice*, not serial mice. What you are referring to is probably the PnP COM device standard, which `moused' already supports. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 18:30:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27158 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 18:30:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27142 for ; Tue, 5 Jan 1999 18:30:53 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:8/csZqXD5pNoSAvKQucbw+SxNDrXKnn8@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id LAA14681; Wed, 6 Jan 1999 11:30:15 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA26934; Wed, 6 Jan 1999 11:32:37 +0900 (JST) Message-Id: <199901060232.LAA26934@zodiac.mech.utsunomiya-u.ac.jp> To: "Daniel O'Connor" cc: hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: psm0 on laptops. In-reply-to: Your message of "Wed, 06 Jan 1999 11:55:33 +1030." References: Date: Wed, 06 Jan 1999 11:32:37 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On 05-Jan-99 Nate Williams wrote: >> Not that I'm aware of. If you have it plugged in to the PS/2 port, you >> *can* switch to the serial version after bootup by physically switching >> it and re-configured X to use the serial port version. >Use moused and tell X to use sysmouse, thats why its there. >Then X gets events from both mice :) > >> The reason it works under Windblows is because the mouse driver is a >> necessary part of the OS, and under FreeBSD it's just another device so >> the OS/userland stuff isn't integrated like under Windows. (Which also >> explains why unix is generally more robust, since not everything is >> integrated together with the OS...) >Its still a pitty you can't tell the psm driver to reprobe the mouse... The psm driver can be instructed to reprobe the mouse after the system is "resumed." See the PSM_RESETAFTERSUSPEND in the man page for psm(4). But, the psm driver does not currently support PS/2 mouse reprobe while the system is up, because it is understood that the PS/2 mouse port in general is not meant for "hot plugging." Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 18:56:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29694 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 18:56:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA29674 for ; Tue, 5 Jan 1999 18:56:18 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 21466 invoked from network); 6 Jan 1999 02:55:48 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 6 Jan 1999 02:55:48 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id VAA02192; Tue, 5 Jan 1999 21:55:45 -0500 (EST) Message-Id: <199901060255.VAA02192@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901060044.RAA22046@usr05.primenet.com> from Terry Lambert at "Jan 6, 99 00:44:48 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 5 Jan 1999 21:55:45 -0500 (EST) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > :I don't really buy this for the general case, which I believe is > > :still stacking layers that don't access local media. > > : > > :For local media FS's, things which actially do I/O through a page > > :fault, this is probably correct. > > > > Ouch.. no, get away from the 'local media' concept - it's a big time > > bust. If you make the distinction between hard media and soft media > > (or local media verses remote media), all you do is screw up the layering > > model. Even now, traditional hard-media-backed VFS layers such as UFS > > can be stacked on top of soft media layers such as MFS, which in turn > > is stacked on top of SWAP (which may be a hard or soft media layer > > itself). If you throw NFS into the fray it gets worse. It just doesn't > > work. Also, these sorts of schemes require both interacting VFS layers > > to have knowledge about each other that goes far beyond what two > > layers ought to know about each other. > > The distinction I'm trying to make is between VFS layers that are VFS > consumers and providers, and VFS layers that that are VFS providers, > but VM system consumers. VM system consumers are "local media" FS's. > The VM system is a provider :-). The VFS provides only the file naming abstraction. > > The problem is in ensuring object coherency. Here we have this > enormous investment in a unified VM and buffer cache, which is mostly > just a way for us to avoid the coherency complications that having > seperate VM and buffer cache cause, and we're talking about doing > something that will reintroduce the complications. > Please look at the ideas again -- using the VM mechanisms for layering eliminate the IMPOSSIBILITY for a VFS layering scheme (as it currently is in any fashion) to provide coherence. A bidirectional object oriented scheme can easily provide coherence. Tell me, what protocol exists (or can exist) in the current VFS framework to provide coherence for mmap, or file I/O with different layers? Answer: none. Thinking of things as files begs the fact that files are all a specific instance of a memory object, let's forget about "files" and local filesystems. (I guess that it is possible for a VFS to provide coherence, at the expense of continual "sync" operations -- that is just wrong.) Think in terms of "stuff" or "objects." The only way that coherence can work in the current framework is in the non-layered and/or local case. If you get much beyond the typical filesystem structure, then problems start arising, and hacks tend to be the expedient solution. Rather than fight an existing structure, it seems that the correct thing is to rethink the structure that can architecturally provide the features needed and desired -- without hackery and special rules. > > Maybe I'm coming in in the middle of a long private discussion (it > feels like it, and Julian has hinted that I am), but I think that > its necessary to fix some of the things we all know are broken > before we try to get tricky... my 2 cents. > The problem with the VFS is that it doesn't appear to be possible to fully fix it given the goal of coherent layering. There is no sane way that a lower layer invalidation can properly propagate upwards to other consumers without treating the data (or objects) with a proper invalidation protocol. Any of the problems with the existing VFS/VM scheme have been with the intricacies of dealing with VFS special cases, and dealing with the I/O abstraction of buffers as a cache. Forget "files" and think "blobs of memory." Once the notion of file is forgotten, then shadowing, invalidation and aliasing of memory become very obvious... I wouldn't really care if the new scheme would be called "VFS", but forget vnodes and bp's... They are unnecessary and undesirable abstractions except at the lowest layers (the leaf filesystems that have those legacy concepts.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 19:04:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00843 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 19:04:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ime.net (ime.net [209.90.192.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00838 for ; Tue, 5 Jan 1999 19:04:03 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4024.ime.net [209.90.195.34]) by ime.net (8.8.7/8.8.7) with SMTP id WAA16613; Tue, 5 Jan 1999 22:03:21 -0500 (EST) Message-Id: <4.1.19990105215759.00c0b6d0@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Jan 1999 22:03:15 -0500 To: Kazutaka YOKOTA , "Daniel O'Connor" From: Drew Baxter Subject: Re: psm0 on laptops. Cc: hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp In-Reply-To: <199901060232.LAA26934@zodiac.mech.utsunomiya-u.ac.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:32 AM 1/6/99 +0900, Kazutaka YOKOTA wrote: > >>On 05-Jan-99 Nate Williams wrote: >>> Not that I'm aware of. If you have it plugged in to the PS/2 port, you >>> *can* switch to the serial version after bootup by physically switching >>> it and re-configured X to use the serial port version. >>Use moused and tell X to use sysmouse, thats why its there. >>Then X gets events from both mice :) >> >>> The reason it works under Windblows is because the mouse driver is a >>> necessary part of the OS, and under FreeBSD it's just another device so >>> the OS/userland stuff isn't integrated like under Windows. (Which also >>> explains why unix is generally more robust, since not everything is >>> integrated together with the OS...) >>Its still a pitty you can't tell the psm driver to reprobe the mouse... > >The psm driver can be instructed to reprobe the mouse after the system >is "resumed." See the PSM_RESETAFTERSUSPEND in the man page for >psm(4). > >But, the psm driver does not currently support PS/2 mouse reprobe >while the system is up, because it is understood that the PS/2 mouse >port in general is not meant for "hot plugging." I agree with that.. Because any of my desktop machines here the PS/2 port is handled by the BIOS. And the BIOS determines Keyboard/Mouse probing before bootstrap. That's what I've found anyway. My Acer laptop treats the trackpad as a separate PS/2 device if I recall.. You can actually use the mouse and the trackpad at the same time as well.. or FN+T disables the trackpad.. I think the PS/2 bus is just like any other bus, the devices are assigned an ID and then managed based on them. Explains why you can get a splitter for the 'ps/2 port' on the back of laptops too I guess. Alright, so I'm assuming a bunch of crap. The bottom line is the PS/2 ports don't like to be hot plugged, because the BIOS checks for the devices upon bootup. If you've ever seen a Packard Bell (amongst other machines) it shows "keyboard detected, mouse detected' during the initial startup, that determines if the computer has them or not right then and there... --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 19:10:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA01522 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 19:10:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA01517 for ; Tue, 5 Jan 1999 19:10:39 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id TAA16470; Tue, 5 Jan 1999 19:10:12 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id TAA36832; Tue, 5 Jan 1999 19:10:11 -0800 (PST) (envelope-from jdp@polstra.com) Date: Tue, 5 Jan 1999 19:10:11 -0800 (PST) Message-Id: <199901060310.TAA36832@vashon.polstra.com> To: jesse@prinz-atm.CS.Uni-Magdeburg.De Subject: Re: RTLD_GLOBAL in dlopen(3) Newsgroups: polstra.freebsd.hackers In-Reply-To: <13967.44598.764504.512958@knecht> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <13967.44598.764504.512958@knecht>, Roland Jesse wrote: > Hello, > > I am in the process of porting Bamboo (http://watsen.net/Bamboo/) to > FreeBSD. While doing so, I realized that the RTLD_GLOBAL flag for > dlopen() does not exist on FreeBSD (only RTLD_LAZY, RTLD_NOW, and > RTLD_NEXT do). It's not implemented yet. I've seen the Solaris documentation about namespace issues for shared libraries, but it's so ambiguous that I doubt even their developers know what really happens. Eventually I'll make a guess at it and implement something. As things stand currently in FreeBSD, RTLD_GLOBAL is in effect always set. I think the best hack for your port would be to add this: #ifndef RTLD_GLOBAL #define RTLD_GLOBAL 0 #endif John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 21:54:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19452 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 21:54:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19445 for ; Tue, 5 Jan 1999 21:54:11 -0800 (PST) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id AAA02443 for ; Wed, 6 Jan 1999 00:53:43 -0500 (EST) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA24227; Wed, 6 Jan 1999 00:53:42 -0500 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.1/8.9.1) id AAA20063; Wed, 6 Jan 1999 00:53:42 -0500 (EST) (envelope-from brdean) From: Brian Dean Message-Id: <199901060553.AAA20063@dean.pc.sas.com> Subject: Filesystem overflow ... can it be done? To: freebsd-hackers@FreeBSD.ORG Date: Wed, 6 Jan 1999 00:53:42 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Once a filesystem fills up, is there a way to have it "overflow" into another filesystem or area of storage? I want build a machine whose filesystem is memory-base, i.e., MFS_ROOT, where root, usr, var, etc, etc, is all memory based. However, I expect a goodly amount of temporary data to have to be dealt with in /tmp, but not all of the time. The primary reason for this is for fast data and program access. The machine could be booted with a BOOTP kernel, and everything downloaded into it's MFS when it comes up. The problem is that /tmp can fill up at peak times, because I can't put enough RAM in the machine to cover the expected maximum. I would be willing to lose performance in this case by having my /tmp overflow onto disk-based storage when necessary, but I wouldn't want to use disk storage all the time. For a long time now, I've used /tmp as a memory based filesystem, and the rest of the OS on disk with good performance results. I'd like to experiment with putting more of my heavily hit code into MFS and maybe take this to the extreme end of the spectrum of having everything in MFS, while still leaving enough RAM to run my processes. Some of my questions are: 1) Can nearly the same results be achieved by dedicating large amounts of memory for disk buffers? 2) I don't like the idea of consuming RAM with programs in the MFS, only to get loaded into RAM again to be executed. Gzipping my executables will help, however, this will increase the activation time, and I don't want to go to all this work to have performance lost by decompression. Maybe the answer to this would be covered in part by the first question? 3) Is this even doable with the filesystem technology in FreeBSD? A while back I remember discussions about stackable filesystems which I think might be relevant here. Thanks for any help and suggestions. -Brian -- Brian Dean Process Engineering brdean@unx.sas.com (x5235) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 5 22:16:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21741 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 22:16:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21734 for ; Tue, 5 Jan 1999 22:16:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id WAA01093; Tue, 5 Jan 1999 22:15:39 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 22:15:39 -0800 (PST) From: Matthew Dillon Message-Id: <199901060615.WAA01093@apollo.backplane.com> To: Brian Dean Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem overflow ... can it be done? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ( you emailed both -current and -hackers in two separate mails. Please email just one list ). :Hi, : :Once a filesystem fills up, is there a way to have it "overflow" into :another filesystem or area of storage? : :I want build a machine whose filesystem is memory-base, i.e., :MFS_ROOT, where root, usr, var, etc, etc, is all memory based. :However, I expect a goodly amount of temporary data to have to be :... : :The problem is that /tmp can fill up at peak times, because I can't :put enough RAM in the machine to cover the expected maximum. I would :... : :For a long time now, I've used /tmp as a memory based filesystem, and :the rest of the OS on disk with good performance results. I'd like to :experiment with putting more of my heavily hit code into MFS and maybe :... :Some of my questions are: : : 1) Can nearly the same results be achieved by dedicating large : amounts of memory for disk buffers? No, not disk buffers. However, if you enable SOFTUPDATES on the hard disk partitions you should get very close to MFS's performance. : 2) I don't like the idea of consuming RAM with programs in the : MFS, only to get loaded into RAM again to be executed. : Gzipping my executables will help, however, this will : increase the activation time, and I don't want to go to all : this work to have performance lost by decompression. Maybe : the answer to this would be covered in part by the first : question? If you use MFS, the data is duplicated. There isn't much you can do about it I'm afraid. MFS *is* swap-backed (and will do an even better job after the commits I make after the CVS tree is split), but it is still going to waste memory for active data sets. : 3) Is this even doable with the filesystem technology in : FreeBSD? A while back I remember discussions about : stackable filesystems which I think might be relevant : here. Well, I'm sure it's doable, but someone would have to write a filesystem driver to make it work. I wouldn't hold my breath. One thing that will be possible with the MFS commits after the 15th will be creating very large MFS disks and not having 'swap creap' occur when you create and delete large files. MFS is traditionally used on diskless (or low-capacity disk) machines or floppy-boot machines... diskless workstations, essentially. There are certain situations where MFS could very well improve performance - I've used it on sendmail machines to mount sendmail's dns/state cache. But, in general, using SOFTUPDATES and a real disk is going to be much more memory efficient. -Matt :Thanks for any help and suggestions. : :-Brian :-- :Brian Dean Process Engineering brdean@unx.sas.com (x5235) : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 00:45:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08467 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 00:45:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08456 for ; Wed, 6 Jan 1999 00:45:37 -0800 (PST) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.8/8.6.9) id KAA09819; Wed, 6 Jan 1999 10:45:05 +0200 (SAST) Received: by citadel via recvmail id 9760; Wed Jan 6 10:44:26 1999 From: Graham Wheeler Message-Id: <199901060852.KAA00920@cdsec.com> Subject: Re: bpf select() broke? To: dwhite@pond.net (Doug White) Date: Wed, 6 Jan 1999 10:52:48 +0200 (SAT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Doug White" at Jan 5, 99 02:13:50 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do Berkeley packet filter devices (/dev/bpfX) supposed to respond like > normal files and devices to a select() system call? > > My experimentation (based on 2.2.7-RELEASE) shows that they don't. They > don't return when they have data waiting to read and they don't return > when they're ready to be written to. The bpf fd is definitely in the fd > list going into the select(), so don't try to pin pilot error on this one. We use select on read on BPF devices for all our BPF code on 2.2.7, and it works for us. Select on write definitely doesn't work (it isn't implemented). -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Internet/Intranet Network Specialists Data Security Products WWW: http://www.cdsec.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 02:40:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA22112 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 02:40:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA22106 for ; Wed, 6 Jan 1999 02:40:38 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA28939; Wed, 6 Jan 1999 05:36:19 -0500 (EST) From: Peter Dufault Message-Id: <199901061036.FAA28939@hda.hda.com> Subject: Re: ACE 4.6 on -current (still) In-Reply-To: <199901050611.XAA01234@psf.Pinyon.ORG> from "Russell L. Carter" at "Jan 4, 99 11:11:53 pm" To: rcarter@pinyon.org (Russell L. Carter) Date: Wed, 6 Jan 1999 05:36:18 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ACE works (except for *_sched*) now. TAO is all that matters. Thanks to prodding and feedback from Richard I've put some *_sched* patches up in ftp.freebsd.org/pub/FreeBSD/development/misc/PATCHES.sched These rationalize the scheduling between rtprio, POSIX_PRIORITY_SCHEDULING, and regular time sharing, fix bugs, and move things into kern_synch. Please eyeball them. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 02:47:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA23217 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 02:47:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from csmd2.cs.uni-magdeburg.de (csmd2.CS.Uni-Magdeburg.De [141.44.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA23209 for ; Wed, 6 Jan 1999 02:47:05 -0800 (PST) (envelope-from jesse@prinz-atm.CS.Uni-Magdeburg.De) Received: from knecht.cs.uni-magdeburg.de (knecht [141.44.21.3]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id KAA24240; Wed, 6 Jan 1999 10:55:57 +0100 (MET) Received: (from jesse@localhost) by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) id KAA01483; Wed, 6 Jan 1999 10:54:18 +0100 (MET) Message-ID: <19990106105418.A1455@cs.uni-magdeburg.de> Date: Wed, 6 Jan 1999 10:54:18 +0100 From: Roland Jesse To: Martin Cracauer , freebsd-hackers@FreeBSD.ORG Subject: Re: ACE 4.6 on -current (still) References: <13952.15788.136215.866276@knecht> <19990105132945.A20085@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990105132945.A20085@cons.org>; from Martin Cracauer on Tue, Jan 05, 1999 at 01:29:45PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer wrote: > I started a port of ACE a while ago. This compiles fine with the > default g++ from FreeBSD, one test fails. Well your port does not compile on my machine (3.0-RELEASE). Getting some valueable input from this list, I got ACE compiled using egcs 1.1.1 with the downside that four tests fail (including one core dump). I will see whether or not I find the time to make a port out of it. The problem I see here is that the necessary patches include one for egcs itself. Regards, Roland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 05:18:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15263 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 05:18:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from firewall.reed.wattle.id.au (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA15258 for ; Wed, 6 Jan 1999 05:18:03 -0800 (PST) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by firewall.reed.wattle.id.au (8.9.1/8.8.7) id NAA03110 for ; Wed, 6 Jan 1999 13:17:26 GMT Received: from avalon.reed.wattle.id.au(192.168.1.1) by firewall.reed.wattle.id.au via smap (V1.3) id sma003108; Wed Jan 6 13:17:08 1999 Received: from percival.reed.wattle.id.au. (percival.reed.wattle.id.au [192.168.1.5]) by avalon.reed.wattle.id.au (8.9.0.Beta3/8.9.0.Beta3) with SMTP id AAA06968 for ; Thu, 7 Jan 1999 00:17:08 +1100 (EST) From: Darren Reed Message-Id: <199901061317.AAA06968@avalon.reed.wattle.id.au> Subject: Upgrading pains. To: hackers@FreeBSD.ORG Date: Thu, 7 Jan 1999 00:17:07 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Upgrading is noted as being a rough process, however, a one thing which make it more difficult: /var/* appears to be nuked whilst /usr and friends survive. (Either that or I did select "Y" for NEWFS which I don't recall doing). This prevents a meaningful attempt to upgrade packages, which should be easily possible with a perl script of sorts, along with losing logs, etc. btw, has anyone got a perl script to upgrade all the install packages in /var/db/pkg ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 05:21:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15768 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 05:21:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from server.noc.demon.net (server.noc.demon.net [193.195.224.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA15763 for ; Wed, 6 Jan 1999 05:21:46 -0800 (PST) (envelope-from fanf@demon.net) Received: by server.noc.demon.net; id NAA21632; Wed, 6 Jan 1999 13:21:18 GMT Received: from fanf.noc.demon.net(195.11.55.83) by inside.noc.demon.net via smap (3.2) id xma021627; Wed, 6 Jan 99 13:21:07 GMT Received: from fanf by fanf.noc.demon.net with local (Exim 1.73 #2) id 0zxstX-00060r-00; Wed, 6 Jan 1999 13:21:07 +0000 To: hackers@FreeBSD.ORG From: Tony Finch Subject: Re: pthreads question/problem... In-Reply-To: References: <369296F4.AE24010B@canonware.com> Message-Id: Date: Wed, 6 Jan 1999 13:21:07 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > >In fact we have a port of the linux threads to FreeBSD so we can do >EXACTLY what they do, including the kernel support. It's being worked on >as we speak. Some is already committed to -current. There is little >argumant however that the ultimate is to schedule N threads over M >processes where M is related to teh number of CPUs available. Sometimes you want M to be large relative to the number of CPUs because you are using threading to improve userland IO concurrency. Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 09:52:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13192 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 09:52:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13177 for ; Wed, 6 Jan 1999 09:52:24 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id KAA24079; Wed, 6 Jan 1999 10:51:53 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd023877; Wed Jan 6 10:51:45 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id KAA05827; Wed, 6 Jan 1999 10:51:19 -0700 (MST) From: Terry Lambert Message-Id: <199901061751.KAA05827@usr05.primenet.com> Subject: Re: psm0 on laptops. To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Wed, 6 Jan 1999 17:51:19 +0000 (GMT) Cc: tlambert@primenet.com, yokota@zodiac.mech.utsunomiya-u.ac.jp, hackers@FreeBSD.ORG In-Reply-To: <199901060210.LAA26565@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at Jan 6, 99 11:10:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >If you have access to the Micorsoft DDK (Device Driver Kit), it > >contains the Microsoft mouse driver source code. Including the > >code that is used to probe serial ports for mice without mucking > >up modems. > > We are talking about *PS/2 mice*, not serial mice. > > What you are referring to is probably the PnP COM device standard, > which `moused' already supports. No, I'm referring to source code for all their mouse drivers, including bus mice and PS/2 mice, not just serial mice, and the code that deals with the hot-plug correctly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 10:01:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14276 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 10:01:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14266 for ; Wed, 6 Jan 1999 10:01:05 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA16623; Wed, 6 Jan 1999 11:00:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd016531; Wed Jan 6 11:00:31 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA06390; Wed, 6 Jan 1999 11:00:23 -0700 (MST) From: Terry Lambert Message-Id: <199901061800.LAA06390@usr05.primenet.com> Subject: Re: psm0 on laptops. To: netmonger@genesis.ispace.com (Drew Baxter) Date: Wed, 6 Jan 1999 18:00:23 +0000 (GMT) Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp, doconnor@gsoft.com.au, hackers@FreeBSD.ORG In-Reply-To: <4.1.19990105215759.00c0b6d0@genesis.ispace.com> from "Drew Baxter" at Jan 5, 99 10:03:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Alright, so I'm assuming a bunch of crap. The bottom line is the PS/2 > ports don't like to be hot plugged, because the BIOS checks for the devices > upon bootup. If you've ever seen a Packard Bell (amongst other machines) > it shows "keyboard detected, mouse detected' during the initial startup, > that determines if the computer has them or not right then and there... Perfect. FreeBSD doesn't use the BIOS for this stuff. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 10:06:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14976 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 10:06:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ime.net (ime.net [209.90.192.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14960 for ; Wed, 6 Jan 1999 10:06:10 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4010.ime.net [209.90.195.20]) by ime.net (8.8.7/8.8.7) with SMTP id NAA23421; Wed, 6 Jan 1999 13:05:11 -0500 (EST) Message-Id: <4.1.19990106130324.00bfa570@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 06 Jan 1999 13:04:58 -0500 To: Terry Lambert From: Drew Baxter Subject: Re: psm0 on laptops. Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp, doconnor@gsoft.com.au, hackers@FreeBSD.ORG In-Reply-To: <199901061800.LAA06390@usr05.primenet.com> References: <4.1.19990105215759.00c0b6d0@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 06:00 PM 1/6/99 +0000, Terry Lambert wrote: >> Alright, so I'm assuming a bunch of crap. The bottom line is the PS/2 >> ports don't like to be hot plugged, because the BIOS checks for the devices >> upon bootup. If you've ever seen a Packard Bell (amongst other machines) >> it shows "keyboard detected, mouse detected' during the initial startup, >> that determines if the computer has them or not right then and there... > >Perfect. FreeBSD doesn't use the BIOS for this stuff. Alright, so it does probing on bootstrap? So what? that means if it's there it's there, if it's not its not. Same principle. Besides I do have a few boards that won't even register the mouse ports existance (I believe my Shuttle HOT-557 1.5 does this) unless there is a device attached to it. Makes sense, the PS/2 port is an 'optional component' you have to buy for 10 bucks. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 10:11:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15958 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 10:11:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15951 for ; Wed, 6 Jan 1999 10:10:59 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA20594; Wed, 6 Jan 1999 11:10:21 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd020396; Wed Jan 6 11:10:06 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA06921; Wed, 6 Jan 1999 11:09:54 -0700 (MST) From: Terry Lambert Message-Id: <199901061809.LAA06921@usr05.primenet.com> Subject: Re: Unlocking vnodes from different processes To: grog@lemis.com (Greg Lehey) Date: Wed, 6 Jan 1999 18:09:54 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990106123627.N78349@freebie.lemis.com> from "Greg Lehey" at Jan 6, 99 12:36:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In Vinum, I sometimes need to lock a vnode in one process and unlock > it in another. Since 3.0, I've been getting panics when I do this: > > panicstr: lockmgr: pid 429, not exclusive lock holder 428 unlocking Yeah; that's expected behaviour. > Can I assume that the other parameters (flag, p) to VOP_UNLOCK will > enable me to do this anyway? The p parameter is the process doing the locking or unlocking. You could technically lie to the thing about the curproc to do the unlock. I would *not* recommend this. > Also, since I don't perform the lock directly (it happens as a > side-effect of opening the vnode), is there a kosher way to find > out what process locked the vnode? You can dereference the lock and look. As long as you don't sleep, you don't give the other process an opportunity to run, and therefore the lock is not in danger of disappearing out from under you. Again, I wouldn't recommend this. It's dirty, and it'll complicate the heck out of things for somone later when they go in not expecting a dependency on the non-sleep or other side effects. Are these kernel processes? Can you maybe lock as a single kernel process, and then queue the releases to that process instead, waking the queueing process back up after the unlock? There's got to be a different approach that doesn't require yielding lock ownership between processes. Alternately, add a function to the lock manager to implement explicit yielding, and then call it to implement the yield... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 10:33:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18948 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 10:33:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18939 for ; Wed, 6 Jan 1999 10:33:53 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA05911; Thu, 7 Jan 1999 03:33:04 +0900 (JST) Message-ID: <36936A36.B6DC5CDB@newsguy.com> Date: Wed, 06 Jan 1999 22:50:46 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Drew Baxter CC: Kazutaka YOKOTA , "Daniel O'Connor" , hackers@FreeBSD.ORG Subject: Re: psm0 on laptops. References: <4.1.19990105215759.00c0b6d0@genesis.ispace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Drew Baxter wrote: > > Alright, so I'm assuming a bunch of crap. The bottom line is the PS/2 > ports don't like to be hot plugged, because the BIOS checks for the devices > upon bootup. If you've ever seen a Packard Bell (amongst other machines) > it shows "keyboard detected, mouse detected' during the initial startup, > that determines if the computer has them or not right then and there... Well, in my notebook the ps/2 mouse is hot-pluggable, and Windows never had any sort of problem detecting which I was using, external or builtin mouse, at any time. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 11:15:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23164 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 11:15:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23159 for ; Wed, 6 Jan 1999 11:15:36 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA02900; Wed, 6 Jan 1999 12:14:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd002691; Wed Jan 6 12:14:50 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA10179; Wed, 6 Jan 1999 12:14:33 -0700 (MST) From: Terry Lambert Message-Id: <199901061914.MAA10179@usr05.primenet.com> Subject: Re: psm0 on laptops. To: netmonger@genesis.ispace.com (Drew Baxter) Date: Wed, 6 Jan 1999 19:14:32 +0000 (GMT) Cc: tlambert@primenet.com, yokota@zodiac.mech.utsunomiya-u.ac.jp, doconnor@gsoft.com.au, hackers@FreeBSD.ORG In-Reply-To: <4.1.19990106130324.00bfa570@genesis.ispace.com> from "Drew Baxter" at Jan 6, 99 01:04:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Perfect. FreeBSD doesn't use the BIOS for this stuff. > > Alright, so it does probing on bootstrap? So what? that means if it's > there it's there, if it's not its not. Same principle. Besides I do have a > few boards that won't even register the mouse ports existance (I believe my > Shuttle HOT-557 1.5 does this) unless there is a device attached to it. > Makes sense, the PS/2 port is an 'optional component' you have to buy for > 10 bucks. Do you tink the arrival of IRQ 1's that the keyboard controller claims are not coming from the keyboard would be sufficient notification of a PS/2 mouse arriving? ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 11:30:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24905 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 11:30:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24900 for ; Wed, 6 Jan 1999 11:30:42 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA28319; Wed, 6 Jan 1999 12:30:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd028241; Wed Jan 6 12:30:11 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA09634; Wed, 6 Jan 1999 12:05:06 -0700 (MST) From: Terry Lambert Message-Id: <199901061905.MAA09634@usr05.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dyson@iquest.net Date: Wed, 6 Jan 1999 19:03:58 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901060255.VAA02192@y.dyson.net> from "John S. Dyson" at Jan 5, 99 09:55:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The distinction I'm trying to make is between VFS layers that are VFS > > consumers and providers, and VFS layers that that are VFS providers, > > but VM system consumers. VM system consumers are "local media" FS's. > > The VM system is a provider :-). The VFS provides only the file naming > abstraction. I know that. But there are three consumers of VFS's. Only the first one works correctly in the -current code: system calls NFS server VFS ------------ ---------- --- VFS VFS VFS In the provider case, where the VFS consumer is, you have three cases as well: VFS VFS VFS --- ---------- --- VM NFS client VFS Again, in the -current code, only the first one works correctly in the -current code. As I said before, I'm trying to distinguish third case in both situations: a VFS provider designed to consume VFS's instead of local resources. > > The problem is in ensuring object coherency. Here we have this > > enormous investment in a unified VM and buffer cache, which is mostly > > just a way for us to avoid the coherency complications that having > > seperate VM and buffer cache cause, and we're talking about doing > > something that will reintroduce the complications. > > Please look at the ideas again -- using the VM mechanisms for layering > eliminate the IMPOSSIBILITY for a VFS layering scheme (as it currently > is in any fashion) to provide coherence. A bidirectional object oriented > scheme can easily provide coherence. Tell me, what protocol exists > (or can exist) in the current VFS framework to provide coherence for > mmap, or file I/O with different layers? Answer: none. Thinking of > things as files begs the fact that files are all a specific instance > of a memory object, let's forget about "files" and local filesystems. > (I guess that it is possible for a VFS to provide coherence, at the > expense of continual "sync" operations -- that is just wrong.) Thinking in terms of a "protocol" is already thinking in terms of having to maintain coherency, instead of the coherency being implicit. It's wrong to access pages off a vnode directly without using a VOP_GETPAGES/VOP_PUTPAGES as an accessor function. If, on the other hand, all of the references are appropriately encapsulated behing an abstract interface like VOP_GETPAGES/VOP_PUTPAGES, then you don't have to hang the pages off of the objects themselves. > Think in terms of "stuff" or "objects." The only way that coherence > can work in the current framework is in the non-layered and/or local > case. If you get much beyond the typical filesystem structure, then > problems start arising, and hacks tend to be the expedient solution. > Rather than fight an existing structure, it seems that the correct > thing is to rethink the structure that can architecturally provide > the features needed and desired -- without hackery and special rules. I think that alias references are hackery of the type you are objecting to. I have no doubt that between you, Matt, and David, they can be made to work. But they are an inelegant increase in complexity that is not meritted by the situation. I think that the correct way to deal with this is to acknowledge that there will be stacking layers that only provide semantics; a directory hierarchy abstraction, or an ACL mechanism, or a quota mechanism, etc., etc.. If you look at the FFS/UFS layers interaction, you see this. The vnodes for directories, which are containers for sequences of blocks, do not originate in a different layer than the vnodes for files (also containers for sequeneces of blocks). There are VFS stacking layers you could envision that would need anonymous virtual memory. A block-by-block compression layer (a file compression layer would be solidly in the previous list), a cryptographic layer, etc.. Any layer that needs to modify the data content representation. Hell, one of my hobby horses is a layer that you'd stack on top of an NFS client to do ISO-8859-X to Unicode conversion so that a Unicode capable system could consume NFS resources from an 8-bit legacy system. But these anonymous memory aware VFS stacking layers are the exceptions, just as a VFS layer that interacts with the VM abstraction of a physical device is an exception. Most VFS stacking layers that you can envision are semantic only. And for a semantic layer it just doesn't make sense to instance an alias object instead of accessing the real object. The problem here is the BS of the default VNOPS supporting the generic getpage/putpage code, and of the NFS code using the old bmap mechanism. The generic code needs to go away. The bmap references need to go away. The way to access pages is to call the vnode's getpages/putpages, and if it is a VFS layer where you are suggesting an alias object, the default implementation is to fall thorugh to the smae functions for the vnode backing the vnode you are referencing, until the operation gets down to the vnode off which the pages are actually hung. If you need to support a "default" generic mechanism, then there has to be VOP that the mechanism can call to ask for the vnode object off which the pages are hung, a VOP_GETBACKINGVP, which each stacking layer that doesn't contain the backing vnode itself implements. If we did the "default VNOPS" approach, we would implement it as an underlying stacked vnode dereference, and the FS's that had vnodes that had pages hung off them would return the vp that they were passed. If you want to call this a "protocol", go ahead, but it doesn't need any coherency notification functions to implement, so it really doesn't meet the definition. > > Maybe I'm coming in in the middle of a long private discussion (it > > feels like it, and Julian has hinted that I am), but I think that > > its necessary to fix some of the things we all know are broken > > before we try to get tricky... my 2 cents. > > The problem with the VFS is that it doesn't appear to be possible to > fully fix it given the goal of coherent layering. There is no sane way > that a lower layer invalidation can properly propagate upwards to > other consumers without treating the data (or objects) with a proper > invalidation protocol. You don't need this. An invalidation is a return of a NULL from a VOP_GETBACKINGVP call, if an invalidation exists at all (the only case where it could exist would be the VM system using the object itself as a backing store, and the object being accessed externally to the machine where it was being accessed, e.g., an NFS serve failure. Even so, what we are talking about is a kludge to deal with the inadequaces of the error channel in the fault path, not some intrinsic need. The "deadfs" crap falls into this same category). I think the problem that you are trying to solve is implicit in the creation of aliases. If you don't create aliases, then the problem melts away. > Any of the problems with the existing VFS/VM scheme have been with the > intricacies of dealing with VFS special cases, and dealing with the > I/O abstraction of buffers as a cache. Well, this is typically where I get all worked up. I think that the existance of special cases at all is an architectural error, and therefore that attempting to deal with them instead of fixing the architecture is merely a compounding of the original error. > Forget "files" and think > "blobs of memory." Once the notion of file is forgotten, then shadowing, > invalidation and aliasing of memory become very obvious... Which is why I think the idea that a vnode and a vm object should be synonymous is wrong. Kirk called the vnode "the structure that took over the kernel". It's time to curb that dog. > I wouldn't really care if the new scheme would be called "VFS", but forget > vnodes and bp's... They are unnecessary and undesirable abstractions except > at the lowest layers (the leaf filesystems that have those legacy concepts.) A vnode is a container object through which an accessor function can get pages. It may contain pages itself, OR it may contain a reference to another vnode container. Eventually, you get down to a leaf vnode that contains pages. Mirroring the vnode stacking relationship with an alias stacking relationship is a coherency nightmare. It shouldn't be done. A vnode containing another vnode *is* a necessary abstraction. It defines a semantic boundary. That's what it's for, that's the intent of the stacking vnode architecture. To define semantic boundaries. The few cases where a vnode on top of a stacking boundary needs to make an information manipulation (e.g., running a one-time-pad transformation on encrypted data) is an exception (it's worse than an exception: you can't permit the unencrypted data to be written to swap as cleartext). Even in these cases, the primary function of the act of stacking the vnodes is *not* to obtain anonymous pages to coherency shadow the underlying contents; it's to define a semantic boundary. The anonymous pages are an implementation detail, nothing more. It's absolutely imperitive to the value of VFS stacking to preserve the idea of having an object to encapsulate semantic boundaries. The entire point of VFS stacking is to enable stacking of semantics. I think before any sweeping changes go into this area, that it should be a requirement that those proposing the changes read John Heidemann's master's thesis, and ensure that the design goals of the stacking architecture are not compromised in the change process, as they were in the original 4.4BSD integration of John's code, and as they continue to be in the various *BSD's. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 11:47:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27569 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 11:47:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ime.net (ime.net [209.90.192.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27555 for ; Wed, 6 Jan 1999 11:47:46 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4029.ime.net [209.90.195.39]) by ime.net (8.8.7/8.8.7) with SMTP id OAA19770; Wed, 6 Jan 1999 14:46:25 -0500 (EST) Message-Id: <4.1.19990106144232.00bff100@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 06 Jan 1999 14:46:17 -0500 To: Terry Lambert From: Drew Baxter Subject: Re: psm0 on laptops. Cc: tlambert@primenet.com, yokota@zodiac.mech.utsunomiya-u.ac.jp, doconnor@gsoft.com.au, hackers@FreeBSD.ORG In-Reply-To: <199901061914.MAA10179@usr05.primenet.com> References: <4.1.19990106130324.00bfa570@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 07:14 PM 1/6/99 +0000, Terry Lambert wrote: >Do you tink the arrival of IRQ 1's that the keyboard controller >claims are not coming from the keyboard would be sufficient >notification of a PS/2 mouse arriving? > >;-). > IRQ 11 is the PS/2 mouse if I recall.. perhaps I'm fuzzy on what you're trying to say. The keyboard is a regular DIN-5 port, the mouse is a ps/2 port. The bus controlling the keyboard port is a regular 32(?) pin soldered IC near the upper part of the keyboard. The PS/2 logic (if I recall correctly) is handled as a separate entity. The BIOS also controls if the PS/2 port is active or not. However if you have nothing plugged into it, it assumes that the bios setting of (active) is being used, and thus you never purchased the 'optional cable'. If there's something plugged into it, the BIOS activates the port. So Enabled/Disabled is really only based on if something is plugged into it, gotta love that fuzzy logic. Otherwise IRQ 11 is free. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 12:19:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02817 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 12:19:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA02811 for ; Wed, 6 Jan 1999 12:19:25 -0800 (PST) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id PAA23193; Wed, 6 Jan 1999 15:18:46 -0500 Date: Wed, 6 Jan 1999 15:18:45 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: root exceeding maxfiles at 64 files, which should not happen? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG kern.maxfiles: 1064 kern.maxfilesperproc: 1064 RLIMIT for root for open files is 1064. So why would I not be able to open more than 64 sockets? what am I missing? sorry to put such a stupid question to this list :-=( I have also bumped the max number of network connections to 1064 ... Version is: FreeBSD 3.0-CURRENT #0: Tue Dec 1 19:09:02 EST 1998 Thanks ron Ron Minnich |"Using Windows NT, which is known to have some rminnich@sarnoff.com | failure modes, on a warship is similar to hoping (609)-734-3120 | that luck will be in our favor"- A. Digiorgio ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 13:16:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09595 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 13:16:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09587 for ; Wed, 6 Jan 1999 13:16:23 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA14766; Wed, 6 Jan 1999 14:15:38 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd014593; Wed Jan 6 14:15:24 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA27539; Wed, 6 Jan 1999 14:15:13 -0700 (MST) From: Terry Lambert Message-Id: <199901062115.OAA27539@usr08.primenet.com> Subject: Re: Source address To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 6 Jan 1999 21:15:12 +0000 (GMT) Cc: dnelson@redwoodsoft.com, lem@cantv.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199812200103.UAA80379@whizzo.transsys.com> from "Louis A. Mamakos" at Dec 19, 98 08:03:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Except that in IOS, the "source-interface" commands cause the application > in question (snmp trap generator, syslog generator, etc), to bind to > a particular interface address on the router, rather than using whatever > interface address is associated with the exit interface on the router. > > It doesn't smash an address in the packet on the way out, and neither > should the FreeBSD kernel. There are a lot of applications that care > about the end point addresses, and zapping something behind their back > is probably going to manifest itself in interesting ways. > > Perhaps this is phrasing problem. If you were to add a sysctl to > bias the operation of the socket code to choose a specified address of > an interface, rather than the address of the outbound interface.. but > then you have to worry about the interface being up and other details. This is a generic problem in the way sockets are bound. Similar fallout from the problem is that, when you change IP addresses on interfaces, you have to restart daemons bound to the IP addresses, etc.. In general, the best possible corrective action would be to allow binding of sockets to interfaces instead of IP addresses. For a complete soloution, you'd want to be able to bind a socket to all interfaces, a specific interface, an IP address regardless of interfaces that have that address, and an interface/IP address pair. For an inetd style soloution, you'd want to add parameters on the end of the protocol field, I believe. Something like: ftp stream tcp:ed0:10.0.0.1 nowait root /usr/libexec/ftpd ftpd -l -d /home/ftp ftp stream tcp:*:141.168.5.12 nowait root /usr/libexec/ftpd ftpd -l -d /home/ftp/external Someone really needs to revisit the idea of sockets before IPV6 is widely deployed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 13:30:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10832 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 13:30:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10815 for ; Wed, 6 Jan 1999 13:30:22 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA06174; Wed, 6 Jan 1999 13:27:58 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdqY6169; Wed Jan 6 21:27:55 1999 Date: Wed, 6 Jan 1999 13:27:48 -0800 (PST) From: Julian Elischer To: Terry Lambert cc: "Louis A. Mamakos" , dnelson@redwoodsoft.com, lem@cantv.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Source address In-Reply-To: <199901062115.OAA27539@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, Terry Lambert wrote: > > Except that in IOS, the "source-interface" commands cause the application > > in question (snmp trap generator, syslog generator, etc), to bind to > > a particular interface address on the router, rather than using whatever > > interface address is associated with the exit interface on the router. > > > > It doesn't smash an address in the packet on the way out, and neither > > should the FreeBSD kernel. There are a lot of applications that care FreeBSD doesn't "smash an address" onto a packet unless you have not bound to an address. If you bind to an address that address is used. > > about the end point addresses, and zapping something behind their back > > is probably going to manifest itself in interesting ways. > > > > Perhaps this is phrasing problem. If you were to add a sysctl to > > bias the operation of the socket code to choose a specified address of > > an interface, rather than the address of the outbound interface.. but > > then you have to worry about the interface being up and other details. > > This is a generic problem in the way sockets are bound. > > Similar fallout from the problem is that, when you change IP > addresses on interfaces, you have to restart daemons bound to > the IP addresses, etc.. > > In general, the best possible corrective action would be to allow > binding of sockets to interfaces instead of IP addresses. what about interfaces with multiple adresses? > > For a complete soloution, you'd want to be able to bind a socket > to all interfaces, a specific interface, an IP address regardless of > interfaces that have that address, and an interface/IP address pair. > > For an inetd style soloution, you'd want to add parameters on the > end of the protocol field, I believe. Something like: > > ftp stream tcp:ed0:10.0.0.1 nowait root /usr/libexec/ftpd ftpd -l -d /home/ftp > ftp stream tcp:*:141.168.5.12 nowait root /usr/libexec/ftpd ftpd -l -d /home/ftp/external > > Someone really needs to revisit the idea of sockets before IPV6 is > widely deployed. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 13:42:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12033 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 13:42:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from galileo.physics.purdue.edu (galileo.physics.purdue.edu [128.210.67.225]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12020 for ; Wed, 6 Jan 1999 13:42:31 -0800 (PST) (envelope-from csg@physics.purdue.edu) Received: from physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by galileo.physics.purdue.edu (8.9.1/8.8.8) with ESMTP id QAA13257; Wed, 6 Jan 1999 16:42:00 -0500 (EST) Message-Id: <199901062142.QAA13257@galileo.physics.purdue.edu> To: freebsd-hackers@FreeBSD.ORG Cc: ajk@physics.purdue.edu, crh@physics.purdue.edu, jonsmith@physics.purdue.edu, bp@physics.purdue.edu, ab@eas.purdue.edu From: "C. Stephen Gunn" Subject: NFS problems under 3.0-RELEASE Date: Wed, 06 Jan 1999 16:41:57 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We've been experiencing crashes/hangs with NFS here recently, and finally got the chance to try and debug it today, here's what we know so far: 1) It happens during NFS writes. In our specific case, it happens when writing files to my home directory automounted off my machine when I roam to other workstations in our department. 2) If you increase the frequency of the writes, you can make it crash (actually hang) easier. While our method of choice was to run Netscape (the DB file I/O kills it usually) I've had it hang a couple of time when writing files with vi, or sending mail. Again, it only pertains to NFS. I finally got the chance today to install a DDB kernel, and get a dump/backtrace after the system hung. The backtrace showed that the kernel was in the middle of an nfs_vinvalbuf() call which in turn called vinvalbuf(). Here's the deal, the backtrace showed a valid parameters for the call to vinvalbuf() from inside nfs_vinvalbuf(), but somehow the vnode parameter to vinvalbuf() apparently got smashed. We'd hang in the middle of the tsleep() loop at the beginning of vinvalbuf() since we weren't paying attention to tsleep()'s error code of ERESTART. I merged 2-3 lines from current to check the error, and the hangs go away. This still doesn't address the problem though. Someone is smashing this vnode pointer, usually with 0x0100, as far as I can tell. I've not had the time to digest all of the nfs/vfs changes that have happened since 3.0 release, but the CVS logs didn't seem to indicate changes that might address this. At least it doesn't crash now, but it's probably a bug thats still out there. - Steve -- C. Stephen Gunn, Computer Systems Engineer Physics Computer Network, Purdue University To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 13:52:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12979 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 13:52:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12972 for ; Wed, 6 Jan 1999 13:52:32 -0800 (PST) (envelope-from witr@rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id QAA15068; Wed, 6 Jan 1999 16:54:47 -0500 (EST) (envelope-from witr@rwwa.com) Message-Id: <199901062154.QAA15068@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "C. Stephen Gunn" cc: freebsd-hackers@FreeBSD.ORG, ajk@physics.purdue.edu, crh@physics.purdue.edu, jonsmith@physics.purdue.edu, bp@physics.purdue.edu, ab@eas.purdue.edu Subject: Re: NFS problems under 3.0-RELEASE In-reply-to: Your message of "Wed, 06 Jan 1999 16:41:57 EST." <199901062142.QAA13257@galileo.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jan 1999 16:54:47 -0500 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG csg@physics.purdue.edu said: :- 1) It happens during NFS writes. In our specific case, it happens :- when writing files to my home directory automounted off my :- machine when I roam to other workstations in our department. FWIW, my NFS hangs occur under similar circumstances. I don't crash or hang the machine, however... Just NFS. --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 14:31:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16143 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 14:31:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16138 for ; Wed, 6 Jan 1999 14:31:18 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id RAA54847; Wed, 6 Jan 1999 17:35:14 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Wed, 6 Jan 1999 17:35:14 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: "C. Stephen Gunn" cc: freebsd-hackers@FreeBSD.ORG, ajk@physics.purdue.edu, crh@physics.purdue.edu, jonsmith@physics.purdue.edu, bp@physics.purdue.edu, ab@eas.purdue.edu Subject: Re: NFS problems under 3.0-RELEASE In-Reply-To: <199901062142.QAA13257@galileo.physics.purdue.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, C. Stephen Gunn wrote: > > We've been experiencing crashes/hangs with NFS here recently, and > finally got the chance to try and debug it today, here's what we > know so far: > > 1) It happens during NFS writes. In our specific case, it happens > when writing files to my home directory automounted off my > machine when I roam to other workstations in our department. > > 2) If you increase the frequency of the writes, you can make it > crash (actually hang) easier. While our method of choice was > to run Netscape (the DB file I/O kills it usually) I've had > it hang a couple of time when writing files with vi, or sending > mail. Again, it only pertains to NFS. > > I finally got the chance today to install a DDB kernel, and get a > dump/backtrace after the system hung. The backtrace showed that > the kernel was in the middle of an nfs_vinvalbuf() call which in > turn called vinvalbuf(). > > Here's the deal, the backtrace showed a valid parameters for the > call to vinvalbuf() from inside nfs_vinvalbuf(), but somehow the > vnode parameter to vinvalbuf() apparently got smashed. > > We'd hang in the middle of the tsleep() loop at the beginning of > vinvalbuf() since we weren't paying attention to tsleep()'s error > code of ERESTART. I merged 2-3 lines from current to check the > error, and the hangs go away. > > This still doesn't address the problem though. Someone is smashing > this vnode pointer, usually with 0x0100, as far as I can tell. > I've not had the time to digest all of the nfs/vfs changes that > have happened since 3.0 release, but the CVS logs didn't seem to > indicate changes that might address this. Yes, the hang was fixed, i haven't seen any data corruption here or crashes since the fix went in. Are you sure your debugging was correct or that the fix you applied didn't fix the vnode smashing? You may still experiance hangs if a program is paged out and recieves a signal while trying to page in off of NFS. I'm unsure if this is fixed. Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current > At least it doesn't crash now, but it's probably a bug thats still > out there. > > - Steve > > -- > C. Stephen Gunn, Computer Systems Engineer > Physics Computer Network, Purdue University > > 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 Jan 6 14:46:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17473 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 14:46:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA17467 for ; Wed, 6 Jan 1999 14:46:07 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id OAA24575; Wed, 6 Jan 1999 14:44:49 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id OAA19290; Wed, 6 Jan 1999 14:44:48 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id OAA01922; Wed, 6 Jan 1999 14:44:47 -0800 (PST) From: Don Lewis Message-Id: <199901062244.OAA01922@salsa.gv.tsc.tdk.com> Date: Wed, 6 Jan 1999 14:44:47 -0800 In-Reply-To: "John S. Dyson" "Re: questions/problems with vm_fault() in Stable" (Jan 5, 9:55pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: dyson@iquest.net, tlambert@primenet.com (Terry Lambert) Subject: Re: questions/problems with vm_fault() in Stable Cc: dillon@apollo.backplane.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 5, 9:55pm, "John S. Dyson" wrote: } Subject: Re: questions/problems with vm_fault() in Stable } Any of the problems with the existing VFS/VM scheme have been with the } intricacies of dealing with VFS special cases, and dealing with the } I/O abstraction of buffers as a cache. Forget "files" and think } "blobs of memory." Once the notion of file is forgotten, then shadowing, } invalidation and aliasing of memory become very obvious... One complication that comes to mind is /dev/vn*. There's a blob of memory associated with the file that's attached to this device. If you create a filesystem on this device and mount it, then each of the files in that filesystem will also have an associated blob of memory and these memory blobs are subsets of the big blob. Of course you could do something really crazy and use something like ccd to stripe a couple of /dev/vn* devices together and use the result as a filesystem ... Maybe the thing to do is to turn all the filesystems into stacking layers, including ffs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 14:59:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18444 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 14:59:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18438 for ; Wed, 6 Jan 1999 14:59:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA25909; Wed, 6 Jan 1999 14:59:19 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Jan 1999 14:59:19 -0800 (PST) From: Matthew Dillon Message-Id: <199901062259.OAA25909@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : system calls NFS server VFS : ------------ ---------- --- : VFS VFS VFS : :In the provider case, where the VFS consumer is, you have three :cases as well: : : VFS VFS VFS : --- ---------- --- : VM NFS client VFS : :Again, in the -current code, only the first one works correctly in I think you have to get away from thinking about 'consumers' and 'providers'. It is precisely this sort of thinking that screwed up the existing VFS design. The best way to abstract a VFS layer is consider that each VFS layer has a 'frontside' and 'backside'. The VFS layer should make no assumptions whatsoever as to who attaches to it on the frontside, and who it is attached to on the backside. If you really want, you could consider a 'consumer' to be the VFS layer's backside and a 'provider' to be the SAME VFS layer's frontside. So a VFS layer's backside 'consumer' is linked to another VFS layer's frontside 'provider'. And so forth. But don't try to 'type' a VFS layer -- it doesn't work. It was precisely that sort of thinking that required something like the MFS filesystem, which blurs distinctions, to be a major hack in existing kernels. The only way to do cache coherency through a multi-layered VFS design is to extend the vm_object model. You *cannot* require that a VM system use VOP_GETPAGES or VOP_PUTPAGES whenever it wants to verify the validity of a page it already has in the cache. If a page is sitting in the cache accessible to someone, that someone should be able to use the page immediately. This is why a two-way cache coherency protocol is so necessary, so things that effect coherency can be propogated back up through the layers rather then through hacks. Requiring the GET/PUTPAGES interface to be used in a cache case destroys the efficiency of the cache and, also, makes it virtually impossible to implement async I/O. The VFS layer, as it stands, cannot do async I/O - the struct buf mechanisms 'sorta' does it, but it isn't really async due to the huge number of places where the system can block even before it returns a bp. An extended vm_object and cache coherency model would, for example, allow something like MFS, VN, or VINUM to be implemented almost trivially and definitely more efficiently, even unto having filesystems relocate underlying storage on the fly. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 15:02:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18960 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 15:02:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18954 for ; Wed, 6 Jan 1999 15:02:06 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id PAA24895; Wed, 6 Jan 1999 15:01:03 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id PAA19484; Wed, 6 Jan 1999 15:01:01 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id PAA01961; Wed, 6 Jan 1999 15:00:59 -0800 (PST) From: Don Lewis Message-Id: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> Date: Wed, 6 Jan 1999 15:00:59 -0800 In-Reply-To: Terry Lambert "Re: question about re-entrancy." (Jan 6, 1:19am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , nate@mt.sri.com (Nate Williams) Subject: Re: question about re-entrancy. Cc: rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 6, 1:19am, Terry Lambert wrote: } Subject: Re: question about re-entrancy. } > If you there are multiple places where the list could be locked down, } > you have no choice in the matter. You *must* use object locks, (or } > something similar to them), else you end up with the 'Big Giant Lock' } > problem. } } I think it's a lesser problem than that, but that's just a matter of } scale, not of kind, so yeah, given a specific way of looking at it, } you're right. } } I think that having multiple places that need to lock is Bad(tm). I } think that, architecturally, you need to constrain the conflict zones } to avoid the problem. What do you do when you want to do different operations on the object while the lock is held? If you want to treat this as a critical section, then you have to use a parameter that tells the code what operation to do between the lock and unlock. } One way of doing this would be to use an inline accessor function and } not change the code layout, but that's the same thing in all but name. ... and pass it a parameter. frob_object(obj, MODIFY, ...); frob_object(obj, DELETE, ...); ... You could even use ;-) } > Right, and how do you propose to do this w/out object locks? } } By locking entry to the code that does the manipulation instead. } } I guess a function could be considered an object too... 8-). } } } This also lets me document my lock state in and out, and ASSERT() } the lock state in an out in the DIAGNOSTIC case. How do you know that someone else hasn't grabbed the lock between the time you unlock and when your ASSERT() gets executed? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 15:17:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20729 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 15:17:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20724 for ; Wed, 6 Jan 1999 15:17:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA26021; Wed, 6 Jan 1999 15:16:26 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Jan 1999 15:16:26 -0800 (PST) From: Matthew Dillon Message-Id: <199901062316.PAA26021@apollo.backplane.com> To: Don Lewis Cc: dyson@iquest.net, tlambert@primenet.com (Terry Lambert), pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :} Any of the problems with the existing VFS/VM scheme have been with the :} intricacies of dealing with VFS special cases, and dealing with the :} I/O abstraction of buffers as a cache. Forget "files" and think :} "blobs of memory." Once the notion of file is forgotten, then shadowing, :} invalidation and aliasing of memory become very obvious... : :One complication that comes to mind is /dev/vn*. There's a blob of :memory associated with the file that's attached to this device. If :you create a filesystem on this device and mount it, then each of :the files in that filesystem will also have an associated blob of :memory and these memory blobs are subsets of the big blob. Of course :you could do something really crazy and use something like ccd to :stripe a couple of /dev/vn* devices together and use the result as :a filesystem ... : :Maybe the thing to do is to turn all the filesystems into stacking :layers, including ffs. This isn't a complication at all. It is, in fact, exactly what extending the vm_object model and implementing a cache coherency model would fix. It's trivial to create associational relationships between vm_page's and vm_object's. Let me put forth an example of one way to do this. It by no means the *only* way, but it's the one I've been thinking about the most. Currently, vm_object's are multi-layered - it's the multi-layering that allows you to fork(), to map things MAP_PRIVATE, and so forth. This model allows swap backing store to be shared across a fork() until one or the other process tries to the modify a page. Without it, the per-process memory utilization would be horrendous especially considering the number of modifications made to fixup shared libraries. We could, in fact, just use the vm_object model to implement stackings such as filesystems mapped on top of VN devices mapped on top of CCD partitions, and so forth. It would be extremely inefficient, but it *could* be used that way. But we want to be efficient. The vm_object model layering is not designed to operate on a page-by-page basis. Instead it is designed to operate on larger page ranges within objects. So, what to do: Well, rather then link vm_object's together directly, we could implement vm_page aliases to allow a physical page to be mapped in more then one object at a time. This would operate strictly as a cache in order to avoid the equivalent of VOP_GETPAGES. The aliases associated with a page are chained together. This would allow a VFS layer to layer two whole vm_object's on top of each other (the caller's object and the VFS layer's object) without piecemealing the subobject. The VFS layer(s) then build up chains of VM aliases. This would work well because the VFS layer would have complete control over its own chain link and thus be able to break it (invalidate), reattach it (reallocate underlying blocks), or pass it along in information sent via the vm_object (use as an argument to a cache coherency protocol). These operations would run entirely through the VM and cache coherency protocols/call-APIs and, in my view, would be extremely optimizeable. Async I/O also becomes both possible and trivial, because a VFS layer can use a vm_alias to placemark a critical-path read or write I/O without necessarily having a real physical page to work with, and use the structure in its pass-through to a lower layer. Rather then depend on the lower layer to instantiate the controlling structures for the I/O (which is one of the areas which programmers screw up the most in the current VFS system), the controlling structure is instantiated in the VM/VFS layer making the request. In the absolute worst case, a vm_alias mechanism would *only* be used to placemark I/O requests. It would not be much more efficient then the existing VOP_GETPAGES model. In the typical case, there would be sufficient vm_alias's in the pool to keep a hold of chains of VM dependancies and allow the VM system to completely bypass (or at least greatly reduce the cost of) the VOP model for the cache case. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 15:31:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22538 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 15:31:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22529 for ; Wed, 6 Jan 1999 15:31:37 -0800 (PST) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id KAA04883; Thu, 7 Jan 1999 10:01:07 +1030 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA09341; Thu, 7 Jan 1999 10:01:07 +1030 Date: Thu, 7 Jan 1999 10:01:06 +1030 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Darren Reed Cc: hackers@FreeBSD.ORG Subject: Re: Upgrading pains. In-Reply-To: <199901061317.AAA06968@avalon.reed.wattle.id.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Darren Reed wrote: > /var/* appears to be nuked whilst /usr and friends survive. (Either that > or I did select "Y" for NEWFS which I don't recall doing). I'm pretty sure you must have done this..I haven't seen this myself or heard it from others. If you remove and then add partitions from the editor, ISTR it defaults to NEWFS=Y..perhaps this was it. > This prevents a meaningful attempt to upgrade packages, which should be > easily possible with a perl script of sorts, along with losing logs, etc. > > btw, has anyone got a perl script to upgrade all the install packages > in /var/db/pkg ? /usr/ports/sysutils/pkg_version will tell you which ones are out of date for you to upgrade by hand.. Kris ----- (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 16:03:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26891 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 16:03:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from guppy.pond.net (guppy.pond.net [205.240.25.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA26812 for ; Wed, 6 Jan 1999 16:03:21 -0800 (PST) (envelope-from dwhite@pond.net) Received: from localhost (dwhite@localhost) by guppy.pond.net (8.8.8/8.8.7) with SMTP id PAA22821; Wed, 6 Jan 1999 15:51:23 -0800 (PST) Date: Wed, 6 Jan 1999 15:51:23 -0800 (PST) From: Doug White To: Graham Wheeler cc: hackers@FreeBSD.ORG Subject: Re: bpf select() broke? In-Reply-To: <199901060852.KAA00920@cdsec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, Graham Wheeler wrote: > > Do Berkeley packet filter devices (/dev/bpfX) supposed to respond like > > normal files and devices to a select() system call? > > > > My experimentation (based on 2.2.7-RELEASE) shows that they don't. They > > don't return when they have data waiting to read and they don't return > > when they're ready to be written to. The bpf fd is definitely in the fd > > list going into the select(), so don't try to pin pilot error on this one. > > We use select on read on BPF devices for all our BPF code on 2.2.7, and it > works for us. Select on write definitely doesn't work (it isn't implemented). Select on write doesn't work, eh? I'll try that. Thanks for the information! Doug White | Pacific Crest Networks Internet: dwhite@pond.net | http://www.pond.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 16:22:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29312 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 16:22:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29298 for ; Wed, 6 Jan 1999 16:21:59 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA21755; Wed, 6 Jan 1999 16:18:40 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA28856; Wed, 6 Jan 1999 16:18:38 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA23193; Wed, 6 Jan 1999 17:18:36 -0700 Message-ID: <3693FD5C.F0941F81@softweyr.com> Date: Wed, 06 Jan 1999 17:18:36 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis CC: Terry Lambert , Nate Williams , rb@gid.co.uk, narvi@haldjas.folklore.ee, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don Lewis wrote: > > } > Right, and how do you propose to do this w/out object locks? > } > } By locking entry to the code that does the manipulation instead. Which is just a finer grain version of the Big Giant Lock. If you can't see the difference between locking an object and locking the thread accessing the object, you need to look more closely. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 16:51:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02788 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 16:51:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02783 for ; Wed, 6 Jan 1999 16:51:41 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id NAA25824; Thu, 7 Jan 1999 13:51:10 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id NAA12882; Thu, 7 Jan 1999 13:51:07 +1300 (NZDT) (envelope-from jabley) Date: Thu, 7 Jan 1999 13:51:07 +1300 From: Joe Abley To: freebsd-hackers@FreeBSD.ORG Cc: jabley@clear.co.nz Subject: setting DF bit Message-ID: <19990107135107.B12785@clear.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, How do arrange for the DF bit in the IP header to be set for a given connected socket? I was expecting to find a sockopt, but I can't find one... Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 16:56:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03568 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 16:56:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03560 for ; Wed, 6 Jan 1999 16:56:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA20924; Wed, 6 Jan 1999 17:56:23 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd020778; Wed Jan 6 17:56:09 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA02738; Wed, 6 Jan 1999 17:55:58 -0700 (MST) From: Terry Lambert Message-Id: <199901070055.RAA02738@usr09.primenet.com> Subject: Re: Source address To: julian@whistle.com (Julian Elischer) Date: Thu, 7 Jan 1999 00:55:58 +0000 (GMT) Cc: tlambert@primenet.com, louie@TransSys.COM, dnelson@redwoodsoft.com, lem@cantv.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Jan 6, 99 01:27:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is a generic problem in the way sockets are bound. > > > > Similar fallout from the problem is that, when you change IP > > addresses on interfaces, you have to restart daemons bound to > > the IP addresses, etc.. > > > > In general, the best possible corrective action would be to allow > > binding of sockets to interfaces instead of IP addresses. > > what about interfaces with multiple adresses? See below: > > For a complete soloution, you'd want to be able to bind a socket > > to all interfaces, a specific interface, an IP address regardless of > > interfaces that have that address, and an interface/IP address pair. If the set isn't inclusive, obviously, you'd need multiple lines in the inetd.conf. I don't see this as a problem, since it's not like it's something that the code deals with now, anyway. The current code binds to INADDR_ANY, which means all IP addresses on all interfaces. This is known to screw up for NFS, and it's known to screw up for the case where the same IP address is used on multiple interfaces. Using the same IP address on multiple interfaces is highly desirable for "bump on the wire" type applications, including, but not limited to, firewall, VPN, NAT, and transparent proxy applications. A more common "bum on the wire" application would make the bump have the same IP address as the exterior gateway on the interior interface, and the same IP address as the interior router on the exterior interface, since this would let you deploy "zero address count" servers. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 17:14:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06308 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 17:14:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06303 for ; Wed, 6 Jan 1999 17:14:17 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id RAA22148; Wed, 6 Jan 1999 17:13:41 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id RAA00738; Wed, 6 Jan 1999 17:13:41 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id SAA23452; Wed, 6 Jan 1999 18:13:40 -0700 Message-ID: <36940A44.89628F8B@softweyr.com> Date: Wed, 06 Jan 1999 18:13:40 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Joe Abley CC: freebsd-hackers@FreeBSD.ORG Subject: Re: setting DF bit References: <19990107135107.B12785@clear.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Abley wrote: > > Hi, > > How do arrange for the DF bit in the IP header to be set for a given > connected socket? > > I was expecting to find a sockopt, but I can't find one... And won't. "sysctl -w net.inet.ip.sourceroute 1" will turn on DF system-wide, setting it to zero (the default) will turn it back off. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 17:22:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA07218 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 17:22:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA07211 for ; Wed, 6 Jan 1999 17:21:54 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id UAA47729; Wed, 6 Jan 1999 20:21:11 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199901070121.UAA47729@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wes Peters cc: Joe Abley , freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: setting DF bit References: <19990107135107.B12785@clear.co.nz> <36940A44.89628F8B@softweyr.com> In-reply-to: Your message of "Wed, 06 Jan 1999 18:13:40 MST." <36940A44.89628F8B@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Jan 1999 20:21:10 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Joe Abley wrote: > > > > Hi, > > > > How do arrange for the DF bit in the IP header to be set for a given > > connected socket? > > > > I was expecting to find a sockopt, but I can't find one... > > And won't. "sysctl -w net.inet.ip.sourceroute 1" will turn on DF > system-wide, setting it to zero (the default) will turn it back off. > This doesn't seem right. I think the only place the kernel networking code generates packets with "DON'T FRAGMENT set in the header is when doing path MTU discovery in the TCP code. I suppose you could generate packets using a SOCK_RAW kinda socket, but that's probably not what was had in mind. If you had a socket option to enable this on e.g., UDP sockets, then you'd have to have a socket that was connect()'ed so you might get notified of MTU exceeded ICMP messages. The problem is that I don't think there's a good way of returning any of the useful data up to the application, other than listening in with an ICMP raw socket. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 18:08:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12573 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 18:08:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12567 for ; Wed, 6 Jan 1999 18:08:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA19330; Wed, 6 Jan 1999 19:08:08 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd019201; Wed Jan 6 19:07:59 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA07487; Wed, 6 Jan 1999 19:07:47 -0700 (MST) From: Terry Lambert Message-Id: <199901070207.TAA07487@usr09.primenet.com> Subject: Re: NFS problems under 3.0-RELEASE To: csg@physics.purdue.edu (C. Stephen Gunn) Date: Thu, 7 Jan 1999 02:07:47 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG, ajk@physics.purdue.edu, crh@physics.purdue.edu, jonsmith@physics.purdue.edu, bp@physics.purdue.edu, ab@eas.purdue.edu In-Reply-To: <199901062142.QAA13257@galileo.physics.purdue.edu> from "C. Stephen Gunn" at Jan 6, 99 04:41:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This still doesn't address the problem though. Someone is smashing > this vnode pointer, usually with 0x0100, as far as I can tell. > I've not had the time to digest all of the nfs/vfs changes that > have happened since 3.0 release, but the CVS logs didn't seem to > indicate changes that might address this. Dump from 32 bytes before the problem to 64 bytes after as hex. See if the corruption, in fact, contains the ethernet address of one or both machines. If it does, then what's happening is that a stack address is being used for a structure that's modified later, but the code that gave the address has already returned, somewhere in your kernel. The last place this bug occurred was in the IPFW "reject" response, where the packet was on the stack, queued for send, and then the code doing the queing returned. This resulted in random kernel stack corruption later on in whatever process was in the kernel providing the stack at the time the network interrupt occurred. I suspect there's a number of places in NFS where stack variables are used, but a buffer should have been allocated instead (and later freed by whoever was given the buffer to process). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 18:22:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13440 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 18:22:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13429 for ; Wed, 6 Jan 1999 18:22:02 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA07832; Wed, 6 Jan 1999 19:21:24 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd007788; Wed Jan 6 19:21:21 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA08125; Wed, 6 Jan 1999 19:21:18 -0700 (MST) From: Terry Lambert Message-Id: <199901070221.TAA08125@usr09.primenet.com> Subject: Re: question about re-entrancy. To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Thu, 7 Jan 1999 02:21:18 +0000 (GMT) Cc: tlambert@primenet.com, nate@mt.sri.com, rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG In-Reply-To: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jan 6, 99 03:00:59 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > } > If you there are multiple places where the list could be locked down, > } > you have no choice in the matter. You *must* use object locks, (or > } > something similar to them), else you end up with the 'Big Giant Lock' > } > problem. > } > } I think it's a lesser problem than that, but that's just a matter of > } scale, not of kind, so yeah, given a specific way of looking at it, > } you're right. > } > } I think that having multiple places that need to lock is Bad(tm). I > } think that, architecturally, you need to constrain the conflict zones > } to avoid the problem. > > What do you do when you want to do different operations on the object > while the lock is held? If you want to treat this as a critical > section, then you have to use a parameter that tells the code what > operation to do between the lock and unlock. You are locking code entrancy based on exactly that: the operation you intend to do is represented by the code you are about to run. The code that you are about to run doesn't necessarily touch all parts of the object, nor does it necessarily apply to only one object or one list of objects of which the object you intend to operate upon is a member. The "paramenter" you use to distinguish this is the identity of the lock you are holding. That lock applies to the set of operations that you intend to perform on the set of objects you intend to perform the operations upon. > } One way of doing this would be to use an inline accessor function and > } not change the code layout, but that's the same thing in all but name. > > ... and pass it a parameter. > > frob_object(obj, MODIFY, ...); > > frob_object(obj, DELETE, ...); > > ... > > You could even use ;-) You could do it this way, if you needed to marshal the data across interfaces. This is, in fact, exactly the reason that John Heideimann gave for using operation argument descriptors instead of simple parameter lists. You can know the size and byte order of a descriptor before you marshall it to another machine for use of remotely located VFS stacking layers (this is one of the examples in his thesis: how to make an NFS replacement that can operate correctly in the face of extensions to semantings that the NFS client or server layers can't know about because they were compiled before the extensions were invented; extensions like this are also the reason that a default VNOPS vector is a bad idea). > } This also lets me document my lock state in and out, and ASSERT() > } the lock state in an out in the DIAGNOSTIC case. > > How do you know that someone else hasn't grabbed the lock between > the time you unlock and when your ASSERT() gets executed? Because you are asserting that *you* have the lock or that *you* don't have the lock. If someone else has the lock, then *you* don't. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 18:32:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14130 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 18:32:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14094 for ; Wed, 6 Jan 1999 18:31:59 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA28337; Wed, 6 Jan 1999 19:31:26 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd028258; Wed Jan 6 19:31:17 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA08668; Wed, 6 Jan 1999 19:31:08 -0700 (MST) From: Terry Lambert Message-Id: <199901070231.TAA08668@usr09.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Thu, 7 Jan 1999 02:31:04 +0000 (GMT) Cc: dyson@iquest.net, tlambert@primenet.com, dillon@apollo.backplane.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901062244.OAA01922@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jan 6, 99 02:44:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > } Subject: Re: questions/problems with vm_fault() in Stable > > } Any of the problems with the existing VFS/VM scheme have been with the > } intricacies of dealing with VFS special cases, and dealing with the > } I/O abstraction of buffers as a cache. Forget "files" and think > } "blobs of memory." Once the notion of file is forgotten, then shadowing, > } invalidation and aliasing of memory become very obvious... [ ... ] > Maybe the thing to do is to turn all the filesystems into stacking > layers, including ffs. UFS *is* a stacking layer that imposed directory hierarchy on FFS. The complication doesn't arise (i.e., FFS works despite generalized stacking being shot in the head from day one of the 4.4 integration) because *the same set of vnodes are used at the same level for both layers*. This is tantamount to there being implicit object coherency between the layers. We know that implicit object coherency between stacking layers would work because we have this example where it *does* work. Put another way, any method that results in a umapfs with *any* implementations for anything other than credential-containing VOP descriptors is wrong (the VOP_BYPASS stuff is a crock; it results from some side-effects that are gratuitous. See the null_bypass() code for details on this; if SunOS can do it right, *BSD can damn well do it right). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 19:16:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21549 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 19:16:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21523 for ; Wed, 6 Jan 1999 19:16:03 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA05128; Wed, 6 Jan 1999 20:15:34 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd005075; Wed Jan 6 20:15:24 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id UAA10543; Wed, 6 Jan 1999 20:15:22 -0700 (MST) From: Terry Lambert Message-Id: <199901070315.UAA10543@usr09.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 7 Jan 1999 03:15:21 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901062259.OAA25909@apollo.backplane.com> from "Matthew Dillon" at Jan 6, 99 02:59:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think you have to get away from thinking about 'consumers' and > 'providers'. It is precisely this sort of thinking that screwed > up the existing VFS design. > > The best way to abstract a VFS layer is consider that each VFS layer > has a 'frontside' and 'backside'. I think you are confusing the definitioanl aspects of "fronside" and "backside"; the point of specifying a "consumer" at all is to define the interface on the top of the module at the top of the stack or the interface on the bottom of the module at the bottom of the stack. These particular modules are singularly uninteresting, as far as their ability to act as anything other than pigs, where "some pigs are more equal than others". They contribute relatively little to the game, other than acting as "stream head" or "stream tail" for the interesting parts of the stack. And of course as a living history of how the architecture was wedged in wrong in the first place, as you look through the various usages of "struct fileops" in the kernel: the pipe code, the socket code, and the vnops code. Why aren't pipes and sockets vnodes so that the file access interface can be normallized? Why can't I cal fcntl() on to use the F_GETOWN/F_SETOWN interfaces on a FIFO? Brain damage. > The VFS layer should make no > assumptions whatsoever as to who attaches to it on the frontside, > and who it is attached to on the backside. Fine and dandy, if you can tell me the answers to the following questions: 1) The system call layer makes VFS calls. How can I stack a VFS *on top of* the system call layer? 2) The NFS server VFS makes RPC calls. How can I stack a VFS *under* the NFS server VFS? The problem exists in streams as well. Somewhere, there has to be a stream head. And on the other end, somewhere there has to be a driver. > If you really want, you could consider a 'consumer' to be the VFS > layer's backside and a 'provider' to be the SAME VFS layer's frontside. > So a VFS layer's backside 'consumer' is linked to another VFS layer's > frontside 'provider'. And so forth. But don't try to 'type' a VFS > layer -- it doesn't work. It was precisely that sort of thinking > that required something like the MFS filesystem, which blurs distinctions, > to be a major hack in existing kernels. I'm not trying to 'type' a VFS layer. The problem is that some idiot (who was right) thought it's be faster to implement block access in FS's that need block access, instead of creating a generic "stream tail" that implemented the buffer cache interface. If they had done that, then the VOP_GETPAGES/VOP_PUTPAGES would directly access the VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE of the underling tail, and FFS could stack on top of it, and "stack" on top of other FS's (although it would only use a subset of the operations, which would pretty much result in it doing the same thing as if it wasn't stacked, unless you implemented VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE, for example to implement "vinum" as a stacking layer). > The only way to do cache coherency through a multi-layered VFS design > is to extend the vm_object model. You *cannot* require that a VM > system use VOP_GETPAGES or VOP_PUTPAGES whenever it wants to verify > the validity of a page it already has in the cache. If a page is sitting > in the cache accessible to someone, that someone should be able to use > the page immediately. This is why a two-way cache coherency protocol > is so necessary, so things that effect coherency can be propogated > back up through the layers rather then through hacks. Requiring the > GET/PUTPAGES interface to be used in a cache case destroys the efficiency > of the cache and, also, makes it virtually impossible to implement async > I/O. The VFS layer, as it stands, cannot do async I/O - the struct buf > mechanisms 'sorta' does it, but it isn't really async due to the huge > number of places where the system can block even before it returns a bp. OK. You are considering the case where I have two vnodes pointing to the same page, and I invalidate the page in the underlying vnode, and asking "how do I make the reference in the upper vnode go away?", right? The way you "make the reference in the upper vnode go away" is by not putting a blessed reference there in the first place. Problem solved. No coherency problem because the problem page is not cached in two places. The page's validity is known by whether or not it's valid bit is set. What you *do* have to do is go through the routines for VOP_GETPAGES/VOP_PUTPAGES if you want to change the status of a page that you are addressing via a vnode reference, through one or more stacking layers which may choose to translate that reference. More formally, you can't make a page accessed this way appear without doing a VOP_GETPAGES or disappear without a VOP_PUTPAGES. And that's the purpose in life of the vnode pager. > An extended vm_object and cache coherency model would, for example, > allow something like MFS, VN, or VINUM to be implemented almost trivially > and definitely more efficiently, even unto having filesystems relocate > underlying storage on the fly. You could implement these things rather trivially as it is, if the bottom end VFS was a variable granularity block store instead of a "file system" that managed its blocks directly, with the caveat that stacking something that managed block layout on anything other than a variable granularity block store layer would be pretty darn useless, since it would never invoke an inferior VOP that implemented policy. Of course, you're aiming at your foot if you do this. Consider an FS that implements ACL's via a VOP_ACL, and manages its own block layout, and then stack something like FFS (that *doesn't* implement a VOP_ACL) on top of that. Now call a system call that calls VOP_ACL, and watch it spam your FFS contents under you, as it acts unexpectedly. If you insist on seperating the block management into a stacking layer, then you will *at least* have to 'type' the stacking layers to avoid stacking a block-management-only consumer on top of another similar consumer to avoid direct block manipulation by an otherwise unprotected call. I think this would be a bad precedent, though I do like the idea of the buffer cache interface being represented as a variable granularity block store. But then, that's what devices are for. Say you don't buy this argument. OK, then what VFS does the NFS client VFS stacking layer stack on top of? It doesn't stack on top of the buffer cache. You're stuck implementing all of the service interfaces in the entire system as VOP's. Not a nice thing. Now the "head" is another intersting issue. In streams, the head is exported as a device. But in VFS stacking, the "head" is implicitly abstracted via system calls. This isn't really a bad thing, but it allows kernel engineers to do stupid things, like treating system calls that consume the VFS interface as if they were somehow something special, compared to an NFS server or a SAMBA server or an AppleTalk server, or some VFS stacking layer that consumes a VFS interface. In general, I have to say that I think you are setting yourself up for some hairy problems; at some point, you will have to make a design compromise, and if you don't go into it with this idea in your head in the first place, it's going to be a surprise instead of something you planned. Probably a nasty surprise. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 19:37:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA24638 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 19:37:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24628 for ; Wed, 6 Jan 1999 19:37:04 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA07169; Wed, 6 Jan 1999 20:36:26 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd006958; Wed Jan 6 20:36:14 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id UAA11431; Wed, 6 Jan 1999 20:35:52 -0700 (MST) From: Terry Lambert Message-Id: <199901070335.UAA11431@usr09.primenet.com> Subject: Re: pthreads question/problem... To: dot@dotat.at (Tony Finch) Date: Thu, 7 Jan 1999 03:35:52 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Tony Finch" at Jan 6, 99 01:21:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >In fact we have a port of the linux threads to FreeBSD so we can do > >EXACTLY what they do, including the kernel support. It's being worked on > >as we speak. Some is already committed to -current. There is little > >argumant however that the ultimate is to schedule N threads over M > >processes where M is related to teh number of CPUs available. > > Sometimes you want M to be large relative to the number of CPUs > because you are using threading to improve userland IO concurrency. Finish the thought: "...and you don't want to use async I/O to improve I/O concurrency because, while doing so would be less overhead than using a bunch of threads, it doesn't accomplish your *real* goal." The *real* reasons you use M threads, where M > N, are: 1) You set M := N + 1 because you haven't implemented a cooperative scheduler, and you use the "+ 1" thread to spawn other threads each time you hit a blocking operation in the kernel because you are using threads as a poor substitute for asynchronous call contexts because some idiot on the POSIX committed thought that make a duplicate incomplete subset of the existing system calls to get async I/O was a fine idea. 2) You set M > N + 1, because you want to compete with the other processes on the system as M quantum units as work instead of as N quantum units of work, and you don't care how much context switch thrashing you generate while you are doing it because your process is so important compared to the other processes (that are doing the same damn thing to try and screw your process the same way) that you're willing to be evil instead of dealing with the "scheduler class" issue like a computer scientist. Which leads to: a) Hey! Why is 90% of my time spent in "system" instead of "user", and profiling shows that it's all in the scheduler and the pager? b) You write a scheduler class to give your X server a fixed percentage of the available quantum because you don't have working set limits on a per process or per vnode basis, and your stupid linker mmap's the object files, and without a working set limit to stop it, thrashes your entire X server out of core, and your naieve soloution is to give the X server enough of the CPU that it can thrash itself back in to give the appearance of "good interactive response" to the "move mouse, wiggle cursor" problem. You call the scheduler class "fixed(*)", which the underlying problem definitely isn't. * Any similarity to UnixWare(tm), Linux, or *BSD, running or stuck thrashing pages in and out of core for no good reason, is purely intentional. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 19:46:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25944 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 19:46:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25938 for ; Wed, 6 Jan 1999 19:46:55 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA16815; Wed, 6 Jan 1999 20:46:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd016728; Wed Jan 6 20:46:12 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id UAA12014; Wed, 6 Jan 1999 20:45:44 -0700 (MST) From: Terry Lambert Message-Id: <199901070345.UAA12014@usr09.primenet.com> Subject: Re: How do I ... To: imp@village.org (Warner Losh) Date: Thu, 7 Jan 1999 03:45:43 +0000 (GMT) Cc: peter@netplex.com.au, hackers@FreeBSD.ORG In-Reply-To: <199812290558.WAA23091@harmony.village.org> from "Warner Losh" at Dec 28, 98 10:58:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I suspect that you are right. I had hoped to get away from > understanding those internals. It may make sense to have a "if_dead" > that is similar to deadfs where all "orphaned" interfaces go when they > die. Hmmm, I'll have to look at this more closely.... This is the wrong way to do this, BTW. The deadfs code is an artifact of the stupid struct fileops crap. Otherwise, it'd be possible to reference the list of "struct file"'s that have the vnode open, and you wouldn't need deadfs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 20:04:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28093 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 20:04:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28086 for ; Wed, 6 Jan 1999 20:04:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA27395; Wed, 6 Jan 1999 20:03:58 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Jan 1999 20:03:58 -0800 (PST) From: Matthew Dillon Message-Id: <199901070403.UAA27395@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The VFS layer should make no :> assumptions whatsoever as to who attaches to it on the frontside, :> and who it is attached to on the backside. : :Fine and dandy, if you can tell me the answers to the following :questions: : :1) The system call layer makes VFS calls. How can I stack a : VFS *on top of* the system call layer? The system call layer is not a VFS layer. :2) The NFS server VFS makes RPC calls. How can I stack a : VFS *under* the NFS server VFS? An NFS server in its current incarnation is not a VFS layer. :The problem exists in streams as well. Somewhere, there has to be a :stream head. And on the other end, somewhere there has to be a driver. Yes, but these are not VFS layers. They have nothing at all to do with anything. The VFS layers do not and should not know or care (A) who calls them, or (B) who they call underneath, as long as the API and protocol is followed. The point is that if you go around trying to assign special circumstances to the head or tail of VFS layers, you wind up in the same boat where we are now - where VFS layers which were never designed to terminate on anything other then hard block device now, magically, are being terminated on a soft block. For example, UFS/FFS was never designed to terminate on memory, much less swap-backed memory. Then came along MFS and suddently were (and still are) all sorts of problems. :> frontside 'provider'. And so forth. But don't try to 'type' a VFS :> layer -- it doesn't work. It was precisely that sort of thinking :> that required something like the MFS filesystem, which blurs distinctions, :> to be a major hack in existing kernels. : :I'm not trying to 'type' a VFS layer. The problem is that some :idiot (who was right) thought it's be faster to implement block :access in FS's that need block access, instead of creating a generic :"stream tail" that implemented the buffer cache interface. : :If they had done that, then the VOP_GETPAGES/VOP_PUTPAGES would :directly access the VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE of the There's nothing wrong with block access - it is, after all, what most VFS layers expect. But to implement block access only through VOP_GETPAGES/PUTPAGES is insane. That's why the vm_object model needs to be extended to encompass VFS layering - so the VM system can use it's ability to cache pages to shortcut (when possible) multiple VFS layers and to maintain cache coherency between VFS layers, and in order to get the efficiency that cache coherency gives you - much less memory waste. The GETPAGES/PUTPAGES model *cannot* maintain cache coherency across VFS layers. It doesn't work. It has never worked. That's the fraggin problem! :> The only way to do cache coherency through a multi-layered VFS design :> is to extend the vm_object model. You *cannot* require that a VM :> system use VOP_GETPAGES or VOP_PUTPAGES whenever it wants to verify :> the validity of a page it already has in the cache. If a page is sitting :... : :OK. You are considering the case where I have two vnodes pointing :to the same page, and I invalidate the page in the underlying vnode, :and asking "how do I make the reference in the upper vnode go away?", :right? : :The way you "make the reference in the upper vnode go away" is by :not putting a blessed reference there in the first place. Problem :solved. No coherency problem because the problem page is not :cached in two places. Uh, I think you missed the point. What you are basically saying is: "I don't want cache coherency".... because that is what you get. That is, in fact, what we have now, and it means that things like MFS waste a whole lot of memory double-caching pages and that it is not possible to span VFS layers across a network in any meaningful way. :The page's validity is known by whether or not it's valid bit is :set. What you *do* have to do is go through the routines for :VOP_GETPAGES/VOP_PUTPAGES if you want to change the status of a This doesn't work if the VFS layering traverses a network. Furthermore, it is *extremely* inefficient. Hell, it doesn't even maintain cache coherency even if you DO use VOP_GETPAGES/PUTPAGES. Now, Terry, if you are arguing that we don't need cache coherency, then ok ... but if you are arguing that we should have cache coherency, you need to reexamine the plate. I, and John, are arguing that a lack of cache coherency (covering both data pages and filesystem ops) is a serious stumbling block that needs to be addressed. Big time. : Terry Lambert : terry@lambert.org Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 20:22:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29425 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 20:22:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29420 for ; Wed, 6 Jan 1999 20:22:53 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA01398; Wed, 6 Jan 1999 21:22:05 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA19758; Wed, 6 Jan 1999 21:22:03 -0700 Date: Wed, 6 Jan 1999 21:22:03 -0700 Message-Id: <199901070422.VAA19758@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: Don.Lewis@tsc.tdk.com (Don Lewis), nate@mt.sri.com, rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901070221.TAA08125@usr09.primenet.com> References: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> <199901070221.TAA08125@usr09.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You are locking code entrancy based on exactly that: the operation you > intend to do is represented by the code you are about to run. The > code that you are about to run doesn't necessarily touch all parts > of the object, nor does it necessarily apply to only one object or > one list of objects of which the object you intend to operate upon > is a member. Then make what is locked 'smaller'. The lock doesn't *HAVE TO* lock down things big. I can be used to lock down any size of thing you want it to. Still, eventually you'll end up with an 'object' which is locked, which represents the smallish entity you want locked down. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 20:23:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29652 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 20:23:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA29615 for ; Wed, 6 Jan 1999 20:23:20 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 9487 invoked from network); 7 Jan 1999 04:22:49 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 7 Jan 1999 04:22:49 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id XAA00697; Wed, 6 Jan 1999 23:22:48 -0500 (EST) Message-Id: <199901070422.XAA00697@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901070315.UAA10543@usr09.primenet.com> from Terry Lambert at "Jan 7, 99 03:15:21 am" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 6 Jan 1999 23:22:48 -0500 (EST) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > I'm not trying to 'type' a VFS layer. The problem is that some > idiot (who was right) thought it's be faster to implement block > access in FS's that need block access, instead of creating a generic > "stream tail" that implemented the buffer cache interface. > > If they had done that, then the VOP_GETPAGES/VOP_PUTPAGES would > directly access the VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE of the > underling tail, and FFS could stack on top of it, and "stack" > on top of other FS's (although it would only use a subset of > the operations, which would pretty much result in it doing the > same thing as if it wasn't stacked, unless you implemented > VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE, for example to implement > "vinum" as a stacking layer). > Lots of I/O doesn't require explicit system calls (but are faults.) When mixing layering and coherent mmaps, the VFS paradigm is just not very useful. VFS as it is supports a subset of what is needed for coherency (except if lots of invalidates are passed, and even then there are problems.) If you can show where a memory coherency mechanism (like MESI) is provided inside of the VFS, then it might be possible. I cannot see it though. VFS supporting simple read/write type system calls is really different than distributed memory schemes (and coherent mmap capabilities are very similar and analogous.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 21:14:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04457 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 21:14:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from terror.hungry.com (terror.hungry.com [199.181.107.40]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA04452 for ; Wed, 6 Jan 1999 21:14:09 -0800 (PST) (envelope-from fn@hungry.com) From: fn@hungry.com Received: (qmail 27477 invoked by uid 507); 7 Jan 1999 05:13:41 -0000 Message-ID: <19990107051341.27476.qmail@terror.hungry.com> Date: 6 Jan 1999 21:13:41 -0800 To: hackers@FreeBSD.ORG Subject: Winchip. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does FreeBSD work on Winchip systems? A cursory examination of the mailing list archives (and /sys/i386/i386/*) didn't reveal anything related to it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 21:18:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04743 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 21:18:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04738 for ; Wed, 6 Jan 1999 21:18:34 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id VAA28211; Wed, 6 Jan 1999 21:17:34 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id VAA25498; Wed, 6 Jan 1999 21:17:32 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA02732; Wed, 6 Jan 1999 21:17:31 -0800 (PST) From: Don Lewis Message-Id: <199901070517.VAA02732@salsa.gv.tsc.tdk.com> Date: Wed, 6 Jan 1999 21:17:31 -0800 In-Reply-To: Terry Lambert "Re: questions/problems with vm_fault() in Stable" (Jan 7, 3:15am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: questions/problems with vm_fault() in Stable Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 7, 3:15am, Terry Lambert wrote: } Subject: Re: questions/problems with vm_fault() in Stable } You could implement these things rather trivially as it is, if the } bottom end VFS was a variable granularity block store instead of a } "file system" that managed its blocks directly, with the caveat that } stacking something that managed block layout on anything other than } a variable granularity block store layer would be pretty darn useless, } since it would never invoke an inferior VOP that implemented policy. } } Of course, you're aiming at your foot if you do this. Consider an FS } that implements ACL's via a VOP_ACL, and manages its own block layout, } and then stack something like FFS (that *doesn't* implement a VOP_ACL) } on top of that. Now call a system call that calls VOP_ACL, and watch } it spam your FFS contents under you, as it acts unexpectedly. I think it only makes sense to stack something like FFS on top of a file, which could either be a block device or just a plain file in some other filesystem. This would allow you mount a file directly and dispense with /dev/vn* and vnconfig. mount -t ufs /a/filesystem/lives/in/this/file /it/is/mounted/here FFS would allocate blocks from .../this/file and use them to store its inodes, the contents of the file in the filesystem, and so on. The filesystem that contains .../this/file would be responsible for allocating space within that filesystem to store .../this/file. You might want to enhance FFS to deallocate blocks that it doesn't need, which would have no effect if the underlying storage was a block device, but it could be used to make .../this/file sparse (but then you'd have to handle the situation where you couldn't allocate a block because the filesystem that is storing .../this/file is full). This scheme could be nested arbitrarily deeply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 21:48:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08293 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 21:48:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from buffy.aitlab.patimas.com ([202.187.239.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08285 for ; Wed, 6 Jan 1999 21:48:09 -0800 (PST) (envelope-from yth@buffy.aitlab.patimas.com) Received: from bigkahuna ([10.1.20.180]) by buffy.aitlab.patimas.com (8.8.8/8.8.8) with SMTP id NAA01193 for ; Thu, 7 Jan 1999 13:47:44 +0800 (MYT) (envelope-from yth@buffy.aitlab.patimas.com) Message-ID: <000901be3a01$489d9de0$b414010a@bigkahuna.aitlab.patimas.com> From: "Yew Thean Hoo" To: Date: Thu, 7 Jan 1999 13:47:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BE3A44.5190E4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BE3A44.5190E4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0006_01BE3A44.5190E4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0006_01BE3A44.5190E4F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 22:13:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11190 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 22:13:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA11146; Wed, 6 Jan 1999 22:13:23 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id BAA07854; Thu, 7 Jan 1999 01:20:04 -0500 From: Bill Paul Message-Id: <199901070620.BAA07854@skynet.ctr.columbia.edu> Subject: Call for testers: ASIX AX88140A fast ethernet driver To: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Date: Thu, 7 Jan 1999 01:20:03 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today I finally obtained a fast ethernet adapter with an ASIX AX88140A chip (thanks Ulf!) and have finished preliminary testing of a driver for this device. Boards based on this chip are usually very cheap and apparently can be had for $20US or less. You can obtain the driver from: http://www.freebsd.org/~wpaul/ASIX/3.0 source for FreeBSD 3.0 http://www.freebsd.org/~wpaul/ASIX/2.2 source for FreeBSD 2.2.x To add the driver to an existing system, do the following: - Download the correct version of if_ax.c and if_axreg.h for your version of FreeBSD. - Unpack the kernel source code under /usr/src. - Copy if_ax.c and if_axreg.h to /sys/pci. - Edit /sys/conf/files and add a line that says: pci/if_ax.c optional ax device-driver - Edit your kernel config file (e.g. /sys/i386/conf/GENERIC) and add a line that says: device ax0 - Configure and compile a kernel and boot it. Devices should be detected as ax0, ax1, etc... You will probably want to edit /etc/rc.conf to have the interface brought up when the system boots. The ASIX Electronics AX88140A is another DEC tulip clone (big surprise). The chip supports both serial and MII transceivers, however it does not have its own internal NWAY support so most boards based on this chip will probably include an MII-compliant NWAY-capable PHY. The main difference between the DEC tulip and the ASIX chip is that the ASIX's receive filter is not programmed by downloading a special setup frame into the transmit DMA channel. Instead, the filter is configured using two special registers. Filtering is restricted to a 64-bit multicast hash table and a single perfect filter entry for the station address. (Those who are curious can obtain a copy of the ASIX datasheet from www.asix.com.tw.) The ASIX chip has one unusual quirk, which is that the reset bit in the bus configuration register is not self-clearing: the driver has to manually clear it. Neither the real DEC tulip nor any of the clones work like this. Also, although the chip supports chaining descriptors in linked list mode, there is no 'use linked list mode' bit in the descriptor control word. Note: I cobbled the 2.2.x version of the driver together tonight and haven't actually tested it yet, having spent most of the day testing the board under 3.0. (I have verified that it compiles and tried to make sure I didn't make any serious goofs). I'm not going to be able to work on it for a while as I got tagged for jury duty, which starts tomorrow. I'm not sure how long it will last. I will of course be keeping track of e-mail during this time, but I may be a bit slow in responding. Note II: I also received a Macronix 98713 board today and finally fixed the mx driver (in -current and on the http server) to properly handle the internal NWAY registers on this chip (the mx_mii_readreg() routine wasn't quite right, and a few other things needed to be tweaked). This means that if you have a board with an original 98713 chip (as opposed to the 98713A), media autoselection and link detection should work properly now. As usual, send your reports, good or bad, to wpaul@skynet.ctr.columbia.edu. Share and enjoy! -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 22:24:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12565 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 22:24:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from PacHell.TelcoSucks.org (PacHell.TelcoSucks.org [207.90.181.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12550; Wed, 6 Jan 1999 22:24:13 -0800 (PST) (envelope-from ulf@PacHell.TelcoSucks.org) Received: (from ulf@localhost) by PacHell.TelcoSucks.org (8.9.1/8.9.1) id WAA04010; Wed, 6 Jan 1999 22:23:50 -0800 (PST) (envelope-from ulf) Message-ID: <19990106222349.S28818@TelcoSucks.org> Date: Wed, 6 Jan 1999 22:23:49 -0800 From: Ulf Zimmermann To: Bill Paul , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Call for testers: ASIX AX88140A fast ethernet driver Reply-To: ulf@Alameda.net References: <199901070620.BAA07854@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901070620.BAA07854@skynet.ctr.columbia.edu>; from Bill Paul on Thu, Jan 07, 1999 at 01:20:03AM -0500 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 3.0-19980930-BETA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 07, 1999 at 01:20:03AM -0500, Bill Paul wrote: > Today I finally obtained a fast ethernet adapter with an ASIX AX88140A > chip (thanks Ulf!) and have finished preliminary testing of a driver for > this device. Boards based on this chip are usually very cheap and > apparently can be had for $20US or less. You can obtain the driver from: $17.50 at a store in the S.F. Bay Area. > > http://www.freebsd.org/~wpaul/ASIX/3.0 source for FreeBSD 3.0 > http://www.freebsd.org/~wpaul/ASIX/2.2 source for FreeBSD 2.2.x > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 6 22:50:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15619 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 22:50:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15612 for ; Wed, 6 Jan 1999 22:50:52 -0800 (PST) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id HAA32607; Thu, 7 Jan 1999 07:50:21 +0100 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with SMTP id HAA20874; Thu, 7 Jan 1999 07:50:21 +0100 (MET) Date: Thu, 7 Jan 1999 07:50:20 +0100 (MET) From: Milan Kopacka Reply-To: Milan Kopacka To: freebsd-hackers@FreeBSD.ORG cc: Konference o transparentni proxy Subject: Specifying local IP in connect() In-Reply-To: <199901062115.OAA27539@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, for our school project I need to design and implement TCP/IP's connect() extension, which allows me to specify the local IP adress of TCP connection. The connect() call takes as an argument pointer to struct sockaddr_in , which is defined as follows: struct sockaddr_in { u_char sin_len; u_char sin_family; u_short sin_port; struct in_addr sin_addr; char sin_zero[8]; }; Here are 8 unused bytes, which can be easily used to extend connect() capabilites to specify both remote and local IP adresses. Such as: (the names are just for example, the idea is important here) struct sockaddr_in_connect_ext { u_char sin_len; u_char sin_family; u_short sin_port; struct in_addr sin_addr; struct in_addr local_addr; /* local IP */ char sin_pad[4]; /* 4 bytes left */ }; The memory holding former sin_zero field remains there deep enough, so I can in tcp_connect() kernel routine easily use specified local IP to be assigned to connection. The second thing I need to do is to allow incoming packets for these connections to be received and add some "goto ours" to ip_input() kernel routine. "Local" IP's which have not yet anything to do with our machine must not be forgotten. :) So the application has now a way to act like IP a.b.c.d while still being able to communicate with machine a.b.c.d. Now I see I have to explain our project goal. The project consists of implementing a fully transparent www proxy cache. Such a thing needs to catch connections going to www servers like proxy server. It also needs to initiate connections to www servers under the client IP adress. This can't be done without help of a router. Think about a situation like that. (client machines) | | ( router)----(transparent proxy) | | (WWW servers) Situation: client initiates the connection, router redirects it to proxy, proxy (acting like client) opens connection to WWW server and makes the rest of caching work. Proxy needs to communicate with both the servers under client's IP and with client under server's IP. However, this is impossible without the change (or improvement :) of TCP/IP on proxy machine, like that above. Please tell me * about the chance of thing like this to get into FreeBSD kernel * if somebody ever uses sin_zero to do some other work * any other ideas Thanks, Milan Kopacka -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 00:11:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA22594 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 00:11:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22587 for ; Thu, 7 Jan 1999 00:11:09 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id VAA27985; Thu, 7 Jan 1999 21:10:39 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id VAA14297; Thu, 7 Jan 1999 21:10:36 +1300 (NZDT) (envelope-from jabley) Date: Thu, 7 Jan 1999 21:10:36 +1300 From: Joe Abley To: Wes Peters Cc: freebsd-hackers@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: setting DF bit Message-ID: <19990107211036.A14269@clear.co.nz> References: <19990107135107.B12785@clear.co.nz> <36940A44.89628F8B@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <36940A44.89628F8B@softweyr.com>; from Wes Peters on Wed, Jan 06, 1999 at 06:13:40PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 06, 1999 at 06:13:40PM -0700, Wes Peters wrote: > Joe Abley wrote: > > How do arrange for the DF bit in the IP header to be set for a given > > connected socket? > > > > I was expecting to find a sockopt, but I can't find one... > > And won't. "sysctl -w net.inet.ip.sourceroute 1" will turn on DF > system-wide, setting it to zero (the default) will turn it back off. So what is the approved manner for doing a ping with the "DF" bit set? In the interests of testing, we need to set the DF bit in our icmp echo request. I do not want to set the DF bit on _everything_ though. Why do you say "won't"? Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 02:57:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06259 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 02:57:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06241 for ; Thu, 7 Jan 1999 02:56:59 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id MAA04095; Thu, 7 Jan 1999 12:55:39 +0200 (EET) Date: Thu, 7 Jan 1999 12:55:39 +0200 (EET) From: Narvi To: fn@hungry.com cc: hackers@FreeBSD.ORG Subject: Re: Winchip. In-Reply-To: <19990107051341.27476.qmail@terror.hungry.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 6 Jan 1999 fn@hungry.com wrote: > > Does FreeBSD work on Winchip systems? > > A cursory examination of the mailing list archives (and /sys/i386/i386/*) > didn't reveal anything related to it. > Haven't tested it - it is just not possible here to get any alternative x86 chips but AMD, and then probably only because of a big bunch of crazy overclockers. But I guess it should work OK, provided you have options CPU_486 & CPU_386 in the kernel. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 03:38:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09065 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 03:38:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ss1000.ms.mff.cuni.cz (ss1000.ms.mff.cuni.cz [195.113.19.221]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA09058 for ; Thu, 7 Jan 1999 03:38:07 -0800 (PST) (envelope-from mkop5230@ss1000.ms.mff.cuni.cz) Received: from beta.ms.mff.cuni.cz (mkop5230@beta.ms.mff.cuni.cz [195.113.16.70]) by ss1000.ms.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id MAA12346 for ; Thu, 7 Jan 1999 12:29:35 +0100 Received: from localhost (mkop5230@localhost) by beta.ms.mff.cuni.cz (980427.SGI.8.8.8/8.8.8) with SMTP id MAA20821 for ; Thu, 7 Jan 1999 12:29:35 +0100 (MET) Date: Thu, 7 Jan 1999 12:29:35 +0100 (MET) From: Milan Kopacka Reply-To: Milan Kopacka To: freebsd-hackers@FreeBSD.ORG Subject: Re: Specifying local IP in connect() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Milan Kopacka wrote: Hi, I'm sorry. I was taught by authorities, that the right way to specify local IP is to use bind() call. Please forget my connect() extensions :) However, the rest remained. I still need to open connections from IP x which my system regulerly doesn't have while still being able to communicate with machine x. From my point of view, the specified information (local IP) only moves to other call. Using bind() disallows me to specify local adress other from adresses assigned to one of my interfaces. netinet/in_pcb.c: (in_pcbbind()) if (ifa_ifwithaddr((struct sockaddr *)sin) == 0) return (EADDRNOTAVAIL); I think a change here + ip_input() modification will do all what I need. Adresses used in such a way don't show under any of machine interfaces, so traffic out for them is not affected and doesn't remain on my machine. The application, which needs such features is described in my previous message. Milan Kopacka -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 03:55:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA10145 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 03:55:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA10140 for ; Thu, 7 Jan 1999 03:55:03 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA09181; Thu, 7 Jan 1999 20:54:26 +0900 (JST) Message-ID: <36949B2F.33F5F54F@newsguy.com> Date: Thu, 07 Jan 1999 20:31:59 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Drew Baxter , hackers@FreeBSD.ORG Subject: Re: psm0 on laptops. References: <4.1.19990106130324.00bfa570@genesis.ispace.com> <4.1.19990106144232.00bff100@genesis.ispace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Drew Baxter wrote: > > The BIOS also controls if the PS/2 port is active or not. However if you > have nothing plugged into it, it assumes that the bios setting of (active) > is being used, and thus you never purchased the 'optional cable'. If > there's something plugged into it, the BIOS activates the port. So > Enabled/Disabled is really only based on if something is plugged into it, > gotta love that fuzzy logic. Otherwise IRQ 11 is free. And how does it work in the case of the hot pluggable ones? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 06:35:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23426 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 06:35:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailbox.reptiles.org (mailbox.reptiles.org [198.96.117.155]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA23420 for ; Thu, 7 Jan 1999 06:35:37 -0800 (PST) (envelope-from jim@reptiles.org) Received: from localhost (893 bytes) by mailbox.reptiles.org via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Thu, 7 Jan 1999 09:34:31 -0500 (EST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Nov-26) Message-Id: From: jim@reptiles.org (Jim Mercer) Subject: utility for setting PNP info in /etc/rc.conf? To: hackers@FreeBSD.ORG Date: Thu, 7 Jan 1999 09:34:31 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i've got a PNP modem in one of my servers. unfortunately, whenever i put a new kernel in place, i physically have to re-initialize the kernel using "boot -c, etc". is there a method to do this in /etc/rc.local or something? -- [ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ] [ The telephone, for those of you who have forgotten, was a commonly used ] [ communications technology in the days before electronic mail. ] [ They're still easy to find in most large cities. -- Nathaniel Borenstein ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 06:47:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24501 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 06:47:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24492; Thu, 7 Jan 1999 06:46:59 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id PAA24595; Thu, 7 Jan 1999 15:46:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA35384; Thu, 7 Jan 1999 15:46:27 +0100 (MET) Message-ID: <19990107154627.L16187@follo.net> Date: Thu, 7 Jan 1999 15:46:27 +0100 From: Eivind Eklund To: hackers@FreeBSD.ORG Subject: Adding KASSERT() - DIAGNOSTIC split Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm planning to split DIAGNOSTIC and add KASSERT(assertion, ("Panic message", ...)); to the kernel (based on discussion on -hackers about 1/2 year ago). The changes are: - Add KASSERT() - Split DIAGNOSTIC into three options - DIAGNOSTIC, INVARIANTS and INVARIANT_SUPPORT. 'INVARIANTS' will take over the documented (but not real) meaning of DIAGNOSTIC - activating kernel invariants. INVARIANT_SUPPORT is to make it possible to activate INVARIANTS for any single file in the system - it enable the compilation of functions made for checking data structures, but doesn't enable the actual checks. DIAGNOSTIC will be used to cover extra diagnostic messages, but not to enable extra panic()s. - Change the occurances of #ifdef DIAGNOSTIC in kern/ and vm/ to to #ifdef INVARIANTS, #ifdef INVARIANT_SUPPORT, #ifdef DIAGNOSTIC or KASSERT() as appropriate. Patches for all of this is already at http://www.freebsd.org/~eivind/KASSERT.patch I'll commit these changes within a couple of days unless I get objections; be warned that I'm converting a lot of DIAGNOSTIC stuff to KASSERT() form, so if I'm unlucky there may be changes in behaviour (AKA bugs) in the invariants. Consider this your heads-up WRT that. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 07:11:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26656 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 07:11:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from schuimpje.snt.utwente.nl (schuimpje.snt.utwente.nl [130.89.238.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26651 for ; Thu, 7 Jan 1999 07:11:05 -0800 (PST) (envelope-from gelderen@mediaport.org) Received: from wit395301.student.utwente.nl ([130.89.235.121]:21764 "HELO deskfix" ident: "NO-IDENT-SERVICE[2]") by schuimpje.snt.utwente.nl with SMTP id <8124-31392>; Thu, 7 Jan 1999 16:10:15 +0100 Message-ID: <013a01be3a4f$b77b6fa0$1400000a@deskfix.local> From: "Jeroen C. van Gelderen" To: Cc: "Konference o transparentni proxy" Subject: Re: Specifying local IP in connect() Date: Thu, 7 Jan 1999 16:09:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Milan Kopacka >The second thing I need to do is to allow incoming packets for these >connections to be received and add some "goto ours" to ip_input() kernel >routine. "Local" IP's which have not yet anything to do with our machine >must not be forgotten. :) > >So the application has now a way to act like IP a.b.c.d while still >being able to communicate with machine a.b.c.d. > >Now I see I have to explain our project goal. The project consists of >implementing a fully transparent www proxy cache. Such a thing needs to >catch connections going to www servers like proxy server. It also needs >to initiate connections to www servers under the client IP adress. >This can't be done without help of a router. > >Think about a situation like that. > > (client machines) > | > | > ( router)----(transparent proxy) > | > | > (WWW servers) > >Situation: client initiates the connection, router redirects it to proxy, >proxy (acting like client) opens connection to WWW server and makes the >rest of caching work. Proxy needs to communicate with both the servers >under client's IP and with client under server's IP. > >However, this is impossible without the change (or improvement :) of >TCP/IP on proxy machine, like that above. Is the set of WWW-servers you need to proxy for know in advance? If not, you have a problem: if someone requests a page @ 130.89.1.2, your proxy needs to bind to that address, but your proxy doesn't know that yet... I think it's better to run a modified router. You can easily implement your requested functionality trough a modified version of the natd daemon (i'll call it proxyd) so that you won't need any kernel changes. For the proxy you can use anything, an unmodified Squid or any other well-behaved proxy. If proxyd receives a HTTP request from a client, it forwards the request to the cache. The request forwarded is slightly modified to include the IP-address from the client in the HTTP-headers. If the cache has the object cahced it simply returns the object. Otherwise it sends out a request to the appropriate webserver. The request will contain the header-with-IP you added in the previous step. The proxyd will extract the IP-address from the request and impersonate appropriately. HTH, Cheers, Jeroen -- Jeroen C. van Gelderen -- gelderen@mediaport.org -- &[8-D}~<= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 07:18:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27381 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 07:18:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailbox.reptiles.org (mailbox.reptiles.org [198.96.117.155]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA27376 for ; Thu, 7 Jan 1999 07:18:42 -0800 (PST) (envelope-from jim@reptiles.org) Received: from localhost (6328 bytes) by mailbox.reptiles.org via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Thu, 7 Jan 1999 10:18:07 -0500 (EST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Nov-26) Message-Id: From: jim@reptiles.org (Jim Mercer) Subject: Re: utility for setting PNP info in /etc/rc.conf? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 7 Jan 1999 10:18:06 -0500 (EST) Cc: hackers@FreeBSD.ORG, paul@it.ca In-Reply-To: <199901071234.NAA08166@labinfo.iet.unipi.it> from Luigi Rizzo at "Jan 7, 99 01:34:10 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > i've got a PNP modem in one of my servers. > > > > unfortunately, whenever i put a new kernel in place, i physically have to > > re-initialize the kernel using "boot -c, etc". > > > > is there a method to do this in /etc/rc.local or something? > > with 2.2.x you put this in /kernel.config, with 3.0 there must be some > other way. > > luigi much appreciated, Luigi. after a couple other emails with Luigi, i configured my system as follows: rebuilt the kernel with: options USERCONFIG_BOOT #imply -c and parse info area modified /kernel.config as: ----------- USERCONFIG pnp 1 0 enable pnp 1 0 os pnp 1 0 port0 0x3e8 pnp 1 0 irq0 5 quit ----------- and presto, my PNP card was initialized as if i was standing in front of the server (which is several kilometers away, and i'd have to get dressed and go out into the -20C winter weather). choking.reptiles.org% dmesg Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.8-RELEASE #5: Thu Jan 7 10:08:01 EST 1999 root@choking.reptiles.org:/usr/.src/sys/compile/CHOKING CPU: Pentium/P54C (99.95-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 16777216 (16384K bytes) FreeBSD Kernel Configuration Utility - Version 1.1 Type "help" for help or "visual" to go to the visual configuration interface (requires MGA/VGA display or serial terminal capable of displaying ANSI graphics). config> pnp 1 0 enable config> pnp 1 0 os config> pnp 1 0 port0 0x3e8 config> pnp 1 0 irq0 5 config> quit avail memory = 14598144 (14256K bytes) Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0:0 chip1 rev 1 on pci0:1:0 chip2 rev 1 on pci0:1:1 chip3 rev 1 int d irq ?? on pci0:1:2 chip4 rev 1 on pci0:1:3 chip5 rev 1 on pci0:9:0 chip6 rev 1 on pci0:10:0 chip7 rev 1 on pci0:11:0 ncr0 rev 18 int a irq 11 on pci0:12:0 ncr0 waiting for scsi devices to settle (ncr0:0:0): "SEAGATE ST1480 7336" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): 5.0 MB/s (200 ns, offset 8) 411MB (842845 512 byte sectors) (ncr0:6:0): "Philips CM4xx 1.01" type 5 removable SCSI 2 cd0(ncr0:6:0): CD-ROM cd0(ncr0:6:0): asynchronous. can't get the size Probing for devices on PCI bus 1: de0 rev 35 int a irq 9 on pci1:4:0 de0: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de0: address 00:c0:95:f0:00:f4 de0: enabling 10baseT port de1 rev 35 int a irq 11 on pci1:5:0 de1: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de1: address 00:c0:95:f0:00:f5 de1: enabling 10baseT port de2 rev 35 int a irq 10 on pci1:6:0 de2: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de2: address 00:c0:95:f0:00:f6 de2: enabling 10baseT port de3 rev 35 int a irq 12 on pci1:7:0 de3: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de3: address 00:c0:95:f0:00:f7 de3: enabling 10baseT port Probing for devices on PCI bus 2: de4 rev 35 int a irq 12 on pci2:4:0 de4: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de4: address 00:c0:95:f0:03:54 de4: enabling 10baseT port de5 rev 35 int a irq 9 on pci2:5:0 de5: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de5: address 00:c0:95:f0:03:55 de5: enabling 10baseT port de6 rev 35 int a irq 11 on pci2:6:0 de6: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de6: address 00:c0:95:f0:03:56 de6: enabling 10baseT port de7 rev 35 int a irq 10 on pci2:7:0 de7: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de7: address 00:c0:95:f0:03:57 de7: enabling 10baseT port Probing for devices on PCI bus 3: de8 rev 35 int a irq 10 on pci3:4:0 de8: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de8: address 00:c0:95:f0:00:c4 de8: enabling 10baseT port de9 rev 35 int a irq 12 on pci3:5:0 de9: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de9: address 00:c0:95:f0:00:c5 de9: enabling 10baseT port de10 rev 35 int a irq 9 on pci3:6:0 de10: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de10: address 00:c0:95:f0:00:c6 de10: enabling 10baseT port de11 rev 35 int a irq 11 on pci3:7:0 de11: ZNYX ZX314 21040 [10Mb/s] pass 2.3 de11: address 00:c0:95:f0:00:c7 de11: enabling 10baseT port Probing for PnP devices: CSN 1 Vendor ID: GVC0505 [0x0505c31e] Serial 0xffffffff PnP: override config for CSN 1 LDN 0 vend_id 0x0505c31e Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 flags 0x1 on motherboard npx0: INT 16 interface Intel Pentium F00F detected, installing workaround IP packet filtering initialized, divert disabled, default to accept, logging limited to 100 packets/entry DUMMYNET initialized (980901) -- size dn_pkt 48 -- [ Jim Mercer Reptilian Research jim@reptiles.org +1 416 410-5633 ] [ The telephone, for those of you who have forgotten, was a commonly used ] [ communications technology in the days before electronic mail. ] [ They're still easy to find in most large cities. -- Nathaniel Borenstein ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 07:49:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00388 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 07:49:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles337.castles.com [208.214.167.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00383 for ; Thu, 7 Jan 1999 07:49:49 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id HAA03218; Thu, 7 Jan 1999 07:46:20 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901071546.HAA03218@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Milan Kopacka cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Specifying local IP in connect() In-reply-to: Your message of "Thu, 07 Jan 1999 12:29:35 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jan 1999 07:46:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > However, the rest remained. I still need to open connections from IP x > which my system regulerly doesn't have while still being able to > communicate with machine x. From my point of view, the specified > information (local IP) only moves to other call. This is a bad idea. Originating traffic which won't necessarily be routed back to you, and more to the point asking the system to *expect* it to be routed back to you doesn't seem to be the right way to do this. I appreciate that you're doing this as an academic exercise, however I have to ask whether you've considered the fact that what you're trying to do is largely already performed by the ipfw 'trapdoor' functionality? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 07:54:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01033 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 07:54:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from firewall.reed.wattle.id.au (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA01028 for ; Thu, 7 Jan 1999 07:54:14 -0800 (PST) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by firewall.reed.wattle.id.au (8.9.1/8.8.7) id PAA06070 for ; Thu, 7 Jan 1999 15:53:37 GMT Received: from avalon.reed.wattle.id.au(192.168.1.1) by firewall.reed.wattle.id.au via smap (V1.3) id sma006068; Thu Jan 7 15:53:10 1999 Received: from percival.reed.wattle.id.au. (percival.reed.wattle.id.au [192.168.1.5]) by avalon.reed.wattle.id.au (8.9.0.Beta3/8.9.0.Beta3) with SMTP id CAA08096 for ; Fri, 8 Jan 1999 02:52:57 +1100 (EST) From: Darren Reed Message-Id: <199901071552.CAA08096@avalon.reed.wattle.id.au> Subject: nfs problems in 2.2.8 To: hackers@FreeBSD.ORG Date: Fri, 8 Jan 1999 02:52:56 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG are there any know nfs problems in 2.2.8 or have there been many made since 2.2.7 ? I'm seeing nfs locking up when attempting to do a cvs commit over nfs (source + repository). it's being served by a sunos4 box which has caused no other troubles yet. to date. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 08:11:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02924 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 08:11:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tricord.system.pl (tricord.system.pl [195.205.185.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02914 for ; Thu, 7 Jan 1999 08:11:53 -0800 (PST) (envelope-from saper@system.pl) Received: from localhost (saper@localhost [127.0.0.1]) by tricord.system.pl (SYSTEM Internet) with SMTP id RAA08040 for ; Thu, 7 Jan 1999 17:12:22 +0100 (MET) Date: Thu, 7 Jan 1999 17:12:21 +0100 (MET) From: Marcin Cieslak To: freebsd-hackers@FreeBSD.ORG Subject: Synaptics TouchPad driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since I got a new machine equipped with TouchPad and some docs from Synaptics - I am going to enhance existing "psm" driver to fully support TouchPad capabilities. Besides, some Linux driver is out already. Please confirm that there is no one currently working on that and if there are any revolutions in PS/2 mouse driver planned. -- << Marcin Cieslak // saper@system.pl >> ----------------------------------------------------------------- SYSTEM Internet Provider http://www.system.pl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 08:26:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04481 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 08:26:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04470 for ; Thu, 7 Jan 1999 08:26:17 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id RAA01861; Thu, 7 Jan 1999 17:31:36 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 7 Jan 1999 17:31:36 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Jim Mercer cc: Luigi Rizzo , hackers@FreeBSD.ORG, paul@it.ca Subject: Re: utility for setting PNP info in /etc/rc.conf? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Jim Mercer wrote: > > > i've got a PNP modem in one of my servers. > > > > > > unfortunately, whenever i put a new kernel in place, i physically have to > > > re-initialize the kernel using "boot -c, etc". > > > > > > is there a method to do this in /etc/rc.local or something? > > > > with 2.2.x you put this in /kernel.config, with 3.0 there must be some > > other way. With 3.0.1 (assuming you run ELF kernel) you have to issue the following commands while in /boot/loader: load kernel load -t userconfig_script /kerel.config or, to place the above in /boot/boot.conf (which soon changes name to boot.rc or something.. :-) Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 08:34:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05296 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 08:34:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA05288 for ; Thu, 7 Jan 1999 08:34:18 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA07491; Fri, 8 Jan 1999 01:33:44 +0900 (JST) Message-ID: <3694E0EF.57960F84@newsguy.com> Date: Fri, 08 Jan 1999 01:29:35 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jim Mercer , hackers@FreeBSD.ORG Subject: Re: utility for setting PNP info in /etc/rc.conf? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jim Mercer wrote: > > i've got a PNP modem in one of my servers. > > unfortunately, whenever i put a new kernel in place, i physically have to > re-initialize the kernel using "boot -c, etc". > > is there a method to do this in /etc/rc.local or something? -stable or -current? The new three stage boot can do that through /boot/boot.conf, but I suppose it has not been back-ported to -stable. Alas, I think it would work with -stable kernels, though. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 09:18:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09898 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 09:18:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09893 for ; Thu, 7 Jan 1999 09:18:28 -0800 (PST) (envelope-from crossd@o2.cs.rpi.edu) Received: from o2.cs.rpi.edu (crossd@o2.cs.rpi.edu [128.113.96.156]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id MAA01995 for ; Thu, 7 Jan 1999 12:17:58 -0500 (EST) Message-Id: <199901071717.MAA01995@cs.rpi.edu> To: freebsd-hackers@FreeBSD.ORG Subject: Device Drivers for 3.0-CURRENTg Date: Thu, 07 Jan 1999 12:17:59 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A professor here is interested in having his class write a simple device driver for his class this semester. Some initial ideas I had for this would be to have it be as a KLD, so they would not have to reboot the machines to test their code (PANICs aside ;). The other idea was to have them write a 'real' driver instead of a virtual one (something that had hardware and interupts to go with it.); I had thought of writing an extreamly simple serial device. All of this would be with giving the students substantial documentation and stub functions to help them get started. I am looking for feedback, and hopefully a little help :). Is the example is /usr/share/examples/... a good starting point? -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 09:30:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11208 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 09:30:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11201 for ; Thu, 7 Jan 1999 09:30:36 -0800 (PST) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:LbMFEOFguzSNfEA8AzQ5HJTnTezYUS4s@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.1/8.9.1) with ESMTP id CAA22383; Fri, 8 Jan 1999 02:29:11 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id CAA24735; Fri, 8 Jan 1999 02:31:33 +0900 (JST) Message-Id: <199901071731.CAA24735@zodiac.mech.utsunomiya-u.ac.jp> To: Marcin Cieslak cc: freebsd-hackers@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Synaptics TouchPad driver In-reply-to: Your message of "Thu, 07 Jan 1999 17:12:21 +0100." References: Date: Fri, 08 Jan 1999 02:31:33 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Since I got a new machine equipped with TouchPad >and some docs from Synaptics - I am going to enhance >existing "psm" driver to fully support TouchPad >capabilities. Besides, some Linux driver is out already. > >Please confirm that there is no one currently working on that >and if there are any revolutions in PS/2 mouse driver >planned. No major update is planned at the moment. But there may be a minor adjustment when keyboard controller related code is updated. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 10:22:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17544 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 10:22:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17483 for ; Thu, 7 Jan 1999 10:21:58 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id TAA93573; Thu, 7 Jan 1999 19:21:26 +0100 (CET) (envelope-from des) To: hackers@FreeBSD.ORG Subject: proposed mod to ps(1) From: Dag-Erling Smorgrav Date: 07 Jan 1999 19:21:25 +0100 Message-ID: Lines: 6 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wouldn't it make sense to add an option to ps(1) to display the login class of each process? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 10:55:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21025 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 10:55:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from assurance.rstcorp.com ([206.29.49.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21017 for ; Thu, 7 Jan 1999 10:55:13 -0800 (PST) (envelope-from vshah@rstcorp.com) Received: (from uucp@localhost) by assurance.rstcorp.com (8.8.8/8.8.8) id NAA25353; Thu, 7 Jan 1999 13:54:44 -0500 Received: from sandbox.rstcorp.com(206.29.49.63) by assurance.rstcorp.com via smap (V2.0) id xma025347; Thu, 7 Jan 99 13:54:21 -0500 Received: from jabberwock.rstcorp.com (jabberwock [206.29.49.98]) by sandbox.rstcorp.com (8.8.8/8.8.8) with ESMTP id NAA05871; Thu, 7 Jan 1999 13:54:20 -0500 (EST) Received: (from vshah@localhost) by jabberwock.rstcorp.com (8.9.1/8.8.8) id NAA86615; Thu, 7 Jan 1999 13:54:21 -0500 (EST) Date: Thu, 7 Jan 1999 13:54:21 -0500 (EST) Message-Id: <199901071854.NAA86615@jabberwock.rstcorp.com> From: "Viren R. Shah" To: jim@reptiles.org (Jim Mercer) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re:utility for setting PNP info in /etc/rc.conf? In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: "Viren R. Shah" X-Face: )~y+U*K:yzjz{q<5lzpI_SVef'U.])9g[C9`1N@]u3,MHY7f*l7C)[_NjM4y4K8$uIUh|\u (K&&HS6,M!61&GMTk'mqmB/Qg]]X}"?TzsFl]"2v!bl8']dma.:^IY^a[lbOI>U:b<~FyK3q-p{HmZ mn~g.`~BE!5{2D:}Yi+\_KkWe?XaHj9$ko1k8iKLYv5*_2c8"G=?Up[}hn+7RNM(bzBZ_wWk6!Pf&B ?3Tcm7M7B~W%K/I0aX3]*=jP?aM]H6HBPT`oLk+0n^_;N\2\%|Rhy;p}34Q.jEsM\qtnxcm;ag%Nq Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Jim" == Jim Mercer writes: Jim> i've got a PNP modem in one of my servers. Jim> unfortunately, whenever i put a new kernel in place, i physically have to Jim> re-initialize the kernel using "boot -c, etc". Jim> is there a method to do this in /etc/rc.local or something? For -current, use the load command in /boot/boot.conf: load -t userconfig_script /boot/pnp.config The, in /boot/pnp.config have something like: USERCONFIG pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 quit I think a similar approach might work in -stable, putting the info in pnp.setup into /kernel.config (or /boot.config), but check the archives. Viren -- Viren R. Shah "Creeping featurism is a disease, fatal if not treated promptly" -- Don Norman in _The Design of Everyday Things_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 11:36:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25198 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 11:36:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25193 for ; Thu, 7 Jan 1999 11:36:50 -0800 (PST) (envelope-from Andrew.Atrens.atrens@nt.com) Received: from zcars01t by smtpott1; Thu, 7 Jan 1999 14:35:49 -0500 Received: from wmerh01z.ca.nortel.com by zcars01t; Thu, 7 Jan 1999 14:34:53 -0500 Received: from hcarp00g.ca.nortel.com (atrens@hcarp00g.ca.nortel.com@wmerh01z) by wmerh01z.ca.nortel.com with ESMTP (8.7.1/8.7.1) id OAA09825; Thu, 7 Jan 1999 14:34:52 -0500 (EST) Date: Thu, 7 Jan 1999 14:43:50 -0500 (EST) From: "Andrew Atrens" Reply-To: "Andrew Atrens" To: "Viren R. Shah" cc: Jim Mercer , freebsd-hackers@FreeBSD.ORG Subject: Re:utility for setting PNP info in /etc/rc.conf? In-Reply-To: <199901071854.NAA86615@jabberwock.rstcorp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This approach worked fine for me too... Prior to elfing my kernel I was using `dset' to accomplish same, but it appears to yack on the elf kernel with something cryptic like: | | --root@churchill:/usr/home/andrew-- | # dset -v | Boot image: /kernel1 | | Table: _isa_devtab_tty | ---------------------------------------------------- | dset: read | Oh well, maybe my etc directory is too out of date :) ... at any rate I prefer this new(er) approach. Andrew -- +----------------------------------------------------+ = Andrew Atrens - Nortel Networks (atrens@nortel.ca) = = P.O. Box 3511, Station C Ottawa, Canada = = = = All opinions expressed are mine, not Nortel's. = +----------------------------------------------------+ On Thu, 7 Jan 1999, Viren R. Shah wrote: > Date: Thu, 7 Jan 1999 13:54:21 -0500 (EST) > From: Viren R. Shah > To: Jim Mercer > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re:utility for setting PNP info in /etc/rc.conf? > > >>>>> "Jim" == Jim Mercer writes: > > Jim> i've got a PNP modem in one of my servers. > > Jim> unfortunately, whenever i put a new kernel in place, i physically have to > Jim> re-initialize the kernel using "boot -c, etc". > > Jim> is there a method to do this in /etc/rc.local or something? > > For -current, use the load command in /boot/boot.conf: > > load -t userconfig_script /boot/pnp.config > > The, in /boot/pnp.config have something like: > > USERCONFIG > pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 > quit > > > I think a similar approach might work in -stable, putting the info in > pnp.setup into /kernel.config (or /boot.config), but check the > archives. > > Viren > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 12:22:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00664 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 12:22:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA00652 for ; Thu, 7 Jan 1999 12:22:01 -0800 (PST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id VAA15603 for ; Thu, 7 Jan 1999 21:21:25 +0100 (MET) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma015601; Thu, 7 Jan 99 21:21:25 +0100 Received: from dibbs1.eur.cis.philips.com (dibbs1.eur.cis.philips.com [130.139.33.66]) by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with ESMTP id VAA14064 for ; Thu, 7 Jan 1999 21:21:24 +0100 (MET) Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by dibbs1.eur.cis.philips.com (8.8.8/8.8.8) with SMTP id VAA08932 for ; Thu, 7 Jan 1999 21:21:24 +0100 (MET) Received: (qmail 57911 invoked by uid 666); 7 Jan 1999 20:21:46 -0000 Date: Thu, 7 Jan 1999 21:21:46 +0100 From: Jos Backus To: freebsd-hackers@FreeBSD.ORG Subject: testmain -> ficl ? Message-ID: <19990107212146.A57893@hal.mpn.cp.philips.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since we have it in the tree anyway, would it make sense to always build/install testmain and install it as, say, /usr/bin/ficl? Perhaps that would encourage some people to start fiddling with it, e.g. to enhance the /boot stuff? -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 12:31:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01960 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 12:31:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from silver.gn.iaf.nl (silver.gn.iaf.nl [193.67.144.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01951 for ; Thu, 7 Jan 1999 12:31:26 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by silver.gn.iaf.nl (8.8.8/8.8.8) with SMTP id VAA03327; Thu, 7 Jan 1999 21:30:49 +0100 Received: by uni4nn.gn.iaf.nl with UUCP id AA28658 (5.67b/IDA-1.5); Thu, 7 Jan 1999 20:52:37 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id TAA00770; Thu, 7 Jan 1999 19:38:02 +0100 (CET) From: Wilko Bulte Message-Id: <199901071838.TAA00770@yedi.iaf.nl> Subject: Re: proposed mod to ps(1) In-Reply-To: from Dag-Erling Smorgrav at "Jan 7, 99 07:21:25 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Thu, 7 Jan 1999 19:38:02 +0100 (CET) Cc: hackers@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Dag-Erling Smorgrav wrote... > Wouldn't it make sense to add an option to ps(1) to display the login > class of each process? Seems like a good idea. Let's hope there is a spare option letter in our 26 letter alfabet ;-) Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 12:52:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04923 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 12:52:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04918; Thu, 7 Jan 1999 12:52:39 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id VAA14058; Thu, 7 Jan 1999 21:58:26 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 7 Jan 1999 21:58:26 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Andrew Atrens cc: "Viren R. Shah" , Jim Mercer , freebsd-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re:utility for setting PNP info in /etc/rc.conf? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Andrew Atrens wrote: > > This approach worked fine for me too... Prior to elfing my kernel I was > using `dset' to accomplish same, but it appears to yack on the elf kernel > with something cryptic like: Indeed, dset doesn't seem to work with ELF kernels - I'm quite surprised at it, so close to 3.0.1-R... > > load -t userconfig_script /boot/pnp.config > > > > The, in /boot/pnp.config have something like: > > > > USERCONFIG > > pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 > > quit BTW. userconfig_script doesn't need the keyword USERCONFIG. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 13:14:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08611 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 13:14:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA08602; Thu, 7 Jan 1999 13:14:45 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA09195; Thu, 7 Jan 1999 20:05:37 +0100 From: Luigi Rizzo Message-Id: <199901071905.UAA09195@labinfo.iet.unipi.it> Subject: Re: utility for setting PNP info in /etc/rc.conf? To: abial@nask.pl (Andrzej Bialecki) Date: Thu, 7 Jan 1999 20:05:37 +0100 (MET) Cc: Andrew.Atrens.atrens@nt.com, viren@rstcorp.com, jim@reptiles.org, freebsd-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Jan 7, 99 09:58:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This approach worked fine for me too... Prior to elfing my kernel I was > > using `dset' to accomplish same, but it appears to yack on the elf kernel > > with something cryptic like: > > Indeed, dset doesn't seem to work with ELF kernels - I'm quite surprised > at it, so close to 3.0.1-R... what about the "kget" thing you have in FreeBSD, Andrzej ? luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 13:25:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10092 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 13:25:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10087 for ; Thu, 7 Jan 1999 13:25:40 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA01250; Thu, 7 Jan 1999 13:22:19 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901072122.NAA01250@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Viren R. Shah" cc: jim@reptiles.org (Jim Mercer), freebsd-hackers@FreeBSD.ORG Subject: Re: utility for setting PNP info in /etc/rc.conf? In-reply-to: Your message of "Thu, 07 Jan 1999 13:54:21 EST." <199901071854.NAA86615@jabberwock.rstcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jan 1999 13:22:19 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>>>> "Jim" == Jim Mercer writes: > > Jim> i've got a PNP modem in one of my servers. > > Jim> unfortunately, whenever i put a new kernel in place, i physically have to > Jim> re-initialize the kernel using "boot -c, etc". > > Jim> is there a method to do this in /etc/rc.local or something? > > For -current, use the load command in /boot/boot.conf: > > load -t userconfig_script /boot/pnp.config > > The, in /boot/pnp.config have something like: > > USERCONFIG This line is only required in the old /kernel.config case. > pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 > quit > > > I think a similar approach might work in -stable, putting the info in > pnp.setup into /kernel.config (or /boot.config), but check the > archives. > > Viren > -- > Viren R. Shah > "Creeping featurism is a disease, fatal if not treated promptly" > -- Don Norman in _The Design of Everyday Things_ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 14:27:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18422 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 14:27:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18417 for ; Thu, 7 Jan 1999 14:27:45 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA13080; Thu, 7 Jan 1999 15:27:05 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd012903; Thu Jan 7 15:26:44 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA11860; Thu, 7 Jan 1999 15:26:37 -0700 (MST) From: Terry Lambert Message-Id: <199901072226.PAA11860@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 7 Jan 1999 22:26:37 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901070403.UAA27395@apollo.backplane.com> from "Matthew Dillon" at Jan 6, 99 08:03:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> The VFS layer should make no > :> assumptions whatsoever as to who attaches to it on the frontside, > :> and who it is attached to on the backside. > : > :Fine and dandy, if you can tell me the answers to the following > :questions: > : > :1) The system call layer makes VFS calls. How can I stack a > : VFS *on top of* the system call layer? > > The system call layer is not a VFS layer. Right. It's a VFS consumer. It has a VFS interface on its bottom end. Hence the whole consumer/provider issue. > :2) The NFS server VFS makes RPC calls. How can I stack a > : VFS *under* the NFS server VFS? > > An NFS server in its current incarnation is not a VFS layer. Right. It's also a VFS consumer and an RPC transported NFS service provider. I actually meant to say "NFS client" here; the NFS client is a VFS provider, but and RPC transport consumer. It has a VFS interface on its top end. > The point is that if you go around trying to assign special circumstances > to the head or tail of VFS layers, you wind up in the same boat where we > are now - where VFS layers which were never designed to terminate on > anything other then hard block device now, magically, are being terminated > on a soft block. For example, UFS/FFS was never designed to terminate > on memory, much less swap-backed memory. Then came along MFS and > suddently were (and still are) all sorts of problems. I'd argue that MFS is an inappropriate use of the UFS code, since the UFS code doesn't acknowledge the idea of shrinking block-backing objects, and barely (with severe fragmentation based degradation) recognizes growing block-backing objects. So the idea that there are "suddenly" problems as a result of an "unexpected but legitimate use" is predicated on the false assumption that such use is legitimate. I also believe that the canonically correct way to deal with MFS issues (if you *insist* on using an inappropriate FS architecture) is by providing a device interface to anonymous memory, and creating the FS on that "device", instead. Clean pages that haven't been written at all don't need to be instanced, and you will have the same (effectively) soloution as the current MFS soloution, but without the current MFS problems. > :I'm not trying to 'type' a VFS layer. The problem is that some > :idiot (who was right) thought it's be faster to implement block > :access in FS's that need block access, instead of creating a generic > :"stream tail" that implemented the buffer cache interface. > : > :If they had done that, then the VOP_GETPAGES/VOP_PUTPAGES would > :directly access the VOP_GETBLOCKRANGE/VOP_PUTBLOCKRANGE of the > > There's nothing wrong with block access - it is, after all, what most > VFS layers expect. But to implement block access only through > VOP_GETPAGES/PUTPAGES is insane. OK. Define another interface with a couple functions or smaller footprint, and call the functions something else. The point is that the interaction footprint for UFS/FFS right now is over 150 kernel functions. Try linking *just* the FFS/UFS/"kern/vfs*" object files to see what the kernel interface consumption exposure is for the FS. It is *hardly* the ideal of portable, abstract code. I don't care what you call the interface, so long as it meets the criteria of (1) it has a small footprint, and (2) it's sufficiently abstrract so as to not render VFS layers non-portable between OS's (for example, Rhapsody, VXWorks, FreeBSD, and Windows 98). > That's why the vm_object model > needs to be extended to encompass VFS layering - so the VM > system can use it's ability to cache pages to shortcut (when possible) > multiple VFS layers and to maintain cache coherency between VFS > layers, and in order to get the efficiency that cache coherency gives > you - much less memory waste. There's *no* memory waste, if you don't instanceincoherent copies of pages in the first place. The ability to "shortcut multiple VFS layers" is an artifact of the non-collapse of stacks. The UFS/FFS interaction is an example of a correct collape. If it the interfaces weren't skewed, NULLFS would be another example, where multiple NULLFS instances collapsed to *no* local vnode definitions, and one call boundary. Instead, you are suggesting that we instance vnodes in each NULLFS layer, and that we complicate this by associating VM object aliases with each layer instance to deal with the coherency issues that come from adding VM object aliases in the first place, and *then* we "shortcut" page references (and *only* page references, as pigs which are more equal than other references) by referncing through the alias. This is rather an insane amount of useless complexity to get around the coherency problems which wouldn't exist had you not introduced vnodes in the null stacking layer case as placeholders for your coherency mechanism, don't you think? > The GETPAGES/PUTPAGES model *cannot* maintain cache coherency across > VFS layers. It doesn't work. It has never worked. That's the fraggin > problem! Works on SunOS. Works on Solaris. If you have a source license, or sign non-disclosure, John Heidemann will show you the code. > :OK. You are considering the case where I have two vnodes pointing > :to the same page, and I invalidate the page in the underlying vnode, > :and asking "how do I make the reference in the upper vnode go away?", > :right? > : > :The way you "make the reference in the upper vnode go away" is by > :not putting a blessed reference there in the first place. Problem > :solved. No coherency problem because the problem page is not > :cached in two places. > > Uh, I think you missed the point. What you are basically saying is: > "I don't want cache coherency".... because that is what you get. That > is, in fact, what we have now, and it means that things like MFS > waste a whole lot of memory double-caching pages and that it is not > possible to span VFS layers across a network in any meaningful way. No. What I'm saying is that I don't want to allow things that result in coherency tracking problems in the first place. It's like the Aluminum plaques in an Alzheimer's sufferer: there's no proven connection between Aluminum consumption and these plaques, but it's unlikely that the human body is capable of transmuting Potassium into Aluminum, through some magical process, in the abscense of dietary Aluminum that could be used by the body in their construction. If you don't introduce the building blocks for the problem, then the problem can't be built. > :The page's validity is known by whether or not it's valid bit is > :set. What you *do* have to do is go through the routines for > :VOP_GETPAGES/VOP_PUTPAGES if you want to change the status of a > > This doesn't work if the VFS layering traverses a network. Furthermore, > it is *extremely* inefficient. So traversing a network, The issue of latency is not going to go away if you make something that's 1/1000th of the latency into 1/10,000th of the latency. You're optimizing the wrong thing, if network transport is your concern. > Hell, it doesn't even maintain cache > coherency even if you DO use VOP_GETPAGES/PUTPAGES. Not true. Add the address of the memory to be filled as an argument (it's there already), and the data from the remote end can be marshalled via the argument descriptor. > Now, Terry, if you are arguing that we don't need cache coherency, then > ok ... but if you are arguing that we should have cache coherency, you > need to reexamine the plate. If there's only one object, there's not a coherency problem. If you make more than one object, then you need explicit instead of implicit coherency. If everything you need is in the descriptor, however, then it's marshallable over *any* interface. Network, or user/kernel proxy for user space developement environment. > I, and John, are arguing that a lack of cache coherency (covering both > data pages and filesystem ops) is a serious stumbling block that needs > to be addressed. Big time. I agree with you. We just disagree about the method of addressing it. I think that the method should be similar to what Heidemann has already demonstrated as working in SunOS and Solaris. I don't think that you need to add a huge amount of parallel complexity to the VFS VM object interaction; I think, instead, you need to consider simplifying the VFS vnode interaction model so that VM complications are unnecessary. Yeah, VM aliases could be useful somewhere, but I think the VFS system is one place where they are further down an already wrong road. Think about a NULLFS layer, and how to make it truly NULL; that's the minimal set. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 15:06:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22647 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 15:06:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22641 for ; Thu, 7 Jan 1999 15:06:54 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA35328; Thu, 7 Jan 1999 15:06:21 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 15:06:21 -0800 (PST) From: Matthew Dillon Message-Id: <199901072306.PAA35328@apollo.backplane.com> To: Terry Lambert Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> on a soft block. For example, UFS/FFS was never designed to terminate :> on memory, much less swap-backed memory. Then came along MFS and :> suddently were (and still are) all sorts of problems. : :I'd argue that MFS is an inappropriate use of the UFS code, since the :UFS code doesn't acknowledge the idea of shrinking block-backing :objects, and barely (with severe fragmentation based degradation) :recognizes growing block-backing objects. I have no idea what you are talking about here. MFS operates on top of its idea of a fixed block device, just like UFS. A VOP mechanism already exists to handle block freeing and, in fact, after the 15th, MFS will start to use it.... file fragments and meta-data will still get unnecessary swap assignments, but full file blocks will not. This is a major improvement and it took me all of 40 minutes to add the support for it. Running MFS on top of a file rather then swap is another story, but running MFS with swap-backed memory for backing store works pretty well now and will work very well after the 15th. :So the idea that there are "suddenly" problems as a result of an :"unexpected but legitimate use" is predicated on the false :assumption that such use is legitimate. 'Legitimate use' is anything that more then a handful of people start using a non-feature for. If the non-feature (aka MFS) was not meant to do something in a certain way, then it should not have tried to do it. Since more then a handful of people are using MFS in ways that it was never designed to handle, but tries to handle anyway, the solution has got to be "fix MFS any any other brokeness that is preventing it from operating the way people want it to operate". You *cannot* just take the cop-out and say that since it was not originally designed for the use it is being put to now, that we should then explicitly disallow the use and break half the people using it! :I also believe that the canonically correct way to deal with MFS :issues (if you *insist* on using an inappropriate FS architecture) :is by providing a device interface to anonymous memory, and creating :the FS on that "device", instead. Clean pages that haven't been :written at all don't need to be instanced, and you will have the :same (effectively) soloution as the current MFS soloution, but :without the current MFS problems. This does not solve any of the current MFS problems, because this is *already* how MFS already works! :> There's nothing wrong with block access - it is, after all, what most :> VFS layers expect. But to implement block access only through :> VOP_GETPAGES/PUTPAGES is insane. : :OK. Define another interface with a couple functions or smaller :footprint, and call the functions something else. The point is that :the interaction footprint for UFS/FFS right now is over 150 kernel :functions. I have described it three times already. Go back in read some of my previous email. :> multiple VFS layers and to maintain cache coherency between VFS :> layers, and in order to get the efficiency that cache coherency gives :> you - much less memory waste. : :There's *no* memory waste, if you don't instanceincoherent copies :of pages in the first place. You are ignoring the point. I mmap() a file. I mmap() the block device underlying the filesystem the file resides on. I start accessing pages. Poof... no coherency, plus lots of wasted memory. You are assuming that VFS devices can be collapsed together such that the inner layers are not independantly accessible, and thus cannot be independantly accessed without going through the upper VFS layers. This is an extremely restrictive view which fails utterly in a number of already existing cases and fails even worse when you try to extend the model across a network. :The ability to "shortcut multiple VFS layers" is an artifact of :the non-collapse of stacks. The UFS/FFS interaction is an example :of a correct collape. If it the interfaces weren't skewed, NULLFS You must be joking. UFS/FFS are like twins - there is no way in hell the UFS/FFS layering model could be applied to joe random VFS layer. :would be another example, where multiple NULLFS instances collapsed :to *no* local vnode definitions, and one call boundary. Instead, :you are suggesting that we instance vnodes in each NULLFS layer, You are assuming that these things are collapsable, but very *few* VFS layers are actually collapseable. For example, there is no way you could possibly collapse RAID or encryption layer or a mirroring mid-layer. You can't collapse an MFS layer that is file-backed. You can't collapse a mirror. You can't collapse a VN device due to partition translations. In all cases the intermediate layers can be independantly accessed and, in fact, it is *desireable* to have the ability to independantly access them. :and that we complicate this by associating VM object aliases with :each layer instance to deal with the coherency issues that come :from adding VM object aliases in the first place, and *then* we :"shortcut" page references (and *only* page references, as pigs which :are more equal than other references) by referncing through the :alias. : :This is rather an insane amount of useless complexity to get around :the coherency problems which wouldn't exist had you not introduced :vnodes in the null stacking layer case as placeholders for your :coherency mechanism, don't you think? Introducing vnodes to the null stacking layer does not change the coherency problems associated with the current VFS layering one iota. You are, again, assuming that the coherency issue will be magically solved by collapsing VFS layers and ignoring the fact that most VFS layers (A) can't be collapsed, and (B) that your coherency solution fails utterly the moment you take a network hop. :> The GETPAGES/PUTPAGES model *cannot* maintain cache coherency across :> VFS layers. It doesn't work. It has never worked. That's the fraggin :> problem! : :Works on SunOS. Works on Solaris. If you have a source license, :or sign non-disclosure, John Heidemann will show you the code. Explain to me how it works rather then point me at three hours worth of research that I have to 'understand' to understand your point. :> :> Uh, I think you missed the point. What you are basically saying is: :> "I don't want cache coherency".... because that is what you get. That :> is, in fact, what we have now, and it means that things like MFS :> waste a whole lot of memory double-caching pages and that it is not :> possible to span VFS layers across a network in any meaningful way. : :No. What I'm saying is that I don't want to allow things that :result in coherency tracking problems in the first place. And I'm saying that that is a pipe dream. There are already a number of situations where coherency tracking is desireable. Extending the model across a network tops the list. Being able to use a coherent mmap() on a common NFS-served partition from N different machines, for example. Filesystem-parallel support processes such as defragger's. Filesystems mounted over shared remote block devices. Machine clusters -- and I mean *real* clusters, not the linux clustering junk -- machine clusters do not work at all without cross-network cache coherency. You can't just dispose of the issue by saying that you will magically arrange the layering such that there is no cache coherency problem. That doesn't solve any of the problems that need solving. :It's like the Aluminum plaques in an Alzheimer's sufferer: there's :no proven connection between Aluminum consumption and these plaques, :but it's unlikely that the human body is capable of transmuting :Potassium into Aluminum, through some magical process, in the :abscense of dietary Aluminum that could be used by the body in :their construction. : :If you don't introduce the building blocks for the problem, then the :problem can't be built. Precisely. Now consider the massive restrictions you have described in order to 'solve' the coherency problem. Try to solve just one case with your methodology - try to solve the case of doing a coherent mmap() on 5 different machines on the same NFS-based file.. Something that does not work at all right now. :> This doesn't work if the VFS layering traverses a network. Furthermore, :> it is *extremely* inefficient. : :So traversing a network, The issue of latency is not going to go away :if you make something that's 1/1000th of the latency into 1/10,000th :of the latency. You're optimizing the wrong thing, if network transport :is your concern. You are missing the point!!!!! You are *doubly* missing the point! FIRST, the issue when you traverse the network is NOT latency, it's CACHE COHERENCY. When you have 50 machines talking to a single file server.... situations like that. SECOND, the whole point of having the cache coherency mechanism in the first place is to AVOID having to go over the network for every operation. The whole idea is that if you have cache coherency, you can actually realistically *cache* things on the local machine and use them WITHOUT going over the network every time you need to do something!! :> Hell, it doesn't even maintain cache :> coherency even if you DO use VOP_GETPAGES/PUTPAGES. : :Not true. Add the address of the memory to be filled as an argument :(it's there already), and the data from the remote end can be :marshalled via the argument descriptor. Huh? Where's the cache? What? No cache? Are you nuts? Or are you assuming the client-side caches the object locally. But then, where's the cache coherency? Right out the window. :> Now, Terry, if you are arguing that we don't need cache coherency, then :> ok ... but if you are arguing that we should have cache coherency, you :> need to reexamine the plate. : :If there's only one object, there's not a coherency problem. If you :make more than one object, then you need explicit instead of implicit :coherency. If everything you need is in the descriptor, however, :then it's marshallable over *any* interface. Network, or user/kernel :proxy for user space developement environment. There ISN'T only one object. I will repeat that a thousand times. Your entire model assumes that there is only one object or that all the VFS layers can be collapsed. Neither assumption works. : Terry Lambert : terry@lambert.org Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 15:07:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22810 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 15:07:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA22698 for ; Thu, 7 Jan 1999 15:07:01 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 11584 invoked from network); 7 Jan 1999 23:06:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 7 Jan 1999 23:06:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA01091; Thu, 7 Jan 1999 18:06:27 -0500 (EST) Message-Id: <199901072306.SAA01091@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901072226.PAA11860@usr01.primenet.com> from Terry Lambert at "Jan 7, 99 10:26:37 pm" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 7 Jan 1999 18:06:27 -0500 (EST) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > I also believe that the canonically correct way to deal with MFS > issues (if you *insist* on using an inappropriate FS architecture) > is by providing a device interface to anonymous memory, and creating > the FS on that "device", instead. Clean pages that haven't been > written at all don't need to be instanced, and you will have the > same (effectively) soloution as the current MFS soloution, but > without the current MFS problems. > Take a look at the new filesystem created by Mark Brincombe on the NetBSD team. We are using it at work. > > Works on SunOS. Works on Solaris. If you have a source license, > or sign non-disclosure, John Heidemann will show you the code. > It must have callbacks then OR it doesn't provide mmap coherency at every node in the graph. Alot of implementations through coherency away. Abstract VM management with some of the VFS terminology or concepts is much cleaner. Filesystem vnodes just don't make sense in a general case, and struct bp makes even less sense. > > If there's only one object, there's not a coherency problem. If you > make more than one object, then you need explicit instead of implicit > coherency. If everything you need is in the descriptor, however, > then it's marshallable over *any* interface. Network, or user/kernel > proxy for user space developement environment. > The VFS code would have to have TERRIBLE performance then, if for every page fault, the datastructures are traversed from a vnode standpoint. Of course, Solaris isn't known for performance, is it? If the relationships are set-up, then the vm code can take care of things at fault time (including MESI type protocols.) > > > I agree with you. We just disagree about the method of addressing it. > I think that the method should be similar to what Heidemann has already > demonstrated as working in SunOS and Solaris. I don't think that you > need to add a huge amount of parallel complexity to the VFS VM object > interaction; I think, instead, you need to consider simplifying the > VFS vnode interaction model so that VM complications are unnecessary. > VFS means filesystem -- I suggest being more abstract than that. The capability has to be in the VM code anyway, and if you do it in a VFS layer, then you end up with excess complexity. > > Yeah, VM aliases could be useful somewhere, but I think the VFS system > is one place where they are further down an already wrong road. Think > about a NULLFS layer, and how to make it truly NULL; that's the minimal > set. > NullFS is the wrong way to do it. You have to assume at least a translation layer and all of the coherency issues associated with that. If you don't start from a general situation, then you end up adding hacks on to make it work. All VFS should provide is a file type abstraction, but it shouldn't be layered. Even thinking in terms of files forgets the fact that files are a subset of memory. If you show me where a cache or memory coherency protocol is provided by a VFS layering scheme, then you are speaking the same capabilities. Without that, coherent mmap ends up being a terrible hack. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 15:19:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23488 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 15:19:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23482 for ; Thu, 7 Jan 1999 15:19:30 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.50]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.0) with ESMTP id AAA14199 for ; Thu, 7 Jan 1999 18:22:01 +0500 Message-ID: <36954133.1F84FE76@bachue.usc.unal.edu.co> Date: Thu, 07 Jan 1999 18:20:19 -0500 From: "Pedro F. Giffuni" Organization: U. Nacional de Colombia X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: A thread-aware debugger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's gigantic, it's linux specific, but JIC someone needs this type of beast: SmartGDB is a set of modifications made to a common breakpoint-debugger to enhance and expand its capabilities http://hegel.ittc.ukans.edu/projects/smartgdb/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 15:24:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23917 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 15:24:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA23912 for ; Thu, 7 Jan 1999 15:24:56 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 1565 invoked from network); 7 Jan 1999 23:24:24 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 7 Jan 1999 23:24:24 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA01200; Thu, 7 Jan 1999 18:24:23 -0500 (EST) Message-Id: <199901072324.SAA01200@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901072306.PAA35328@apollo.backplane.com> from Matthew Dillon at "Jan 7, 99 03:06:21 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 7 Jan 1999 18:24:23 -0500 (EST) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > Huh? Where's the cache? What? No cache? Are you nuts? Or are you > assuming the client-side caches the object locally. But then, where's > the cache coherency? Right out the window. > .... > > There ISN'T only one object. I will repeat that a thousand times. > Your entire model assumes that there is only one object or that all the > VFS layers can be collapsed. Neither assumption works. > Those ARE the key points. The cool thing (and I am agreeing with you Matt) is that the VM method is an abstraction that fully supports the file I/O model also. The file I/O method doesn't support an mmap model at all (at least in a coherent way.) Rather than spending lots of time trying to make a (conventional) VFS scheme work, and adding lots of hacks to simulate coherency, we can start with a hybrid Heidemann/VM framework with proper invalidation protocols and have everything work from the beginning!!! I don't think that any of us are suggesting that the Heidemann framework be ignored. We are suggesting that it should be applied in a different way that gives us alot more flexibility and consistancy. This would allow the infrastructure to do more of the work (almost automatically supporting coherency) rather than adding hackery to a filesystem scheme to force VM mmap coherency. This scheme that Matt and I propose would simplify and truely define the interfaces. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 16:19:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01089 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 16:19:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01072; Thu, 7 Jan 1999 16:19:19 -0800 (PST) (envelope-from hern@boatracers.com) Received: from dms.at ([193.154.20.10]) by freefall.freebsd.org (8.8.8/8.8.5) with SMTP id QAA27305; Thu, 7 Jan 1999 16:19:11 -0800 (PST) Received: from harnny by dms.at (8.6.13/200.17.1.3) id BAA17908; Fri, 8 Jan 1999 01:16:45 +0100 Message-Id: <199901080016.BAA17908@dms.at> From: "Ken" Subject: Introducing HGH: The Most Powerful Anti-Obesity Drug Ever Discovered! To: groups876@dms.at X-Mailer: Mozilla 4.72 [en] (Win95; I) Mime-Version: 1.0 Date: Thu, 07 Jan 1999 18:51:25 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id QAA01073 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Most Powerful Anti-Obesity Drug Ever Discovered! This is how many physician researchers have described this incredible hormone. It revs up metabolism to youthful levels, resculptors the body by selectively reducing the fat in the waist, abdomen, hips and thighs, while at the same time increasing muscle mass! It has also been described as Cosmetic Surgery in a bottle, smoothing out facial wrinkles, restoring the elasticity, thickness and contours of youthful skin, reversing the loss of extracellular water that makes old people look like dried up prunes! It may be the most powerful aphrodisiac ever discovered reviving flagging sexuality in older men! It affects nearly every cell in our bodies, rejuvenating the skin and bones, regenerating the heart, liver, lungs, and kidneys, bringing organ and tissue function back to youthful levels! Prior to now, this miracle hormone was only available by injections through a licensed physician. It was also very expensive. But now, these near miraculous HGH effects and more can be safely enjoyed by every adult, especially if you are over forty; because our company has come out with a product which contains powerful HGH releasers, and this product is now available to the general public at a very affordable price! (Only $69.99 retail, and $50.00 wholesale, for a 16 fl.oz. bottle). To get this product at the wholesale price, you just need to register with our parent company with an application fee of only $35.00). Below are a few testimonials from people using our HGH product: “ I have been on the product for about three months now and I love it . I’ve lost around 21 pounds and have a lot more energy” ~ R.W.; Alabama “I have been taking your HGH product for 4 months and the results are astounding. I have lost 12 pounds of fat without dieting, have much more energy for my daily workout which I am also getting better results from, my hair is starting to go back to its original color, and not to offend anyone, but my sex life has gone through the roof! I will never be without a bottle of this product!” ~ J.R.; Texas. “I am recovering from a broken neck sustained two years ago … in the last 5 years I have gained up to 180 pounds. Since I started taking your product, I have gone from a size 16 to a 10 in one month and I am still loosing inches. My weight as of today is 148 pounds and I’m walking for the first time without my cane. I didn’t plan on selling this product, but people keep seeing me and end up signing up.” M.W.A .; ~ Arizona. If you will like to order this product right away, so you can start enjoying these great health benefits of HGH immediately, call our 24Hour automated Order Placement Line at: 918-748-1977. You will receive with your shipment a FREE AUDIOCASSETTE ON HGH, by a famous physician researcher and a world authority on the subject. We accept Visa , MasterCard, American Express and Discover. Your product will be shipped within 72 Hours on regular business days. To receive FREE Info about this amazing HGH product, complete the Info Request Form below -LEGIBLY PLEASE, (Best To Type It!). Fax your LEGIBLY completed form to this 24Hour dedicated Fax Line at: 918-298-4517. Note: All FREE info is sent via email ONLY! Illegibly completed forms , will regrettably not be processed! Thanks in advance for taking the time to do it right! Info Request Form: Name: _______________________________________________ Email Address: _______________________________________ Our Ref: 01/AM/04/HGH/99#1 Thank You. You will be receiving info, usually within 24 to 48 Hours on regular business days via Email from an indepedent marketing representative. @#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@# To be removed please reply to: mailto:lews67@yahoo.com?subject=remove #@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 16:45:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03754 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 16:45:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03748 for ; Thu, 7 Jan 1999 16:45:20 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA09367; Thu, 7 Jan 1999 17:44:50 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd009347; Thu Jan 7 17:44:49 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA22486; Thu, 7 Jan 1999 17:44:48 -0700 (MST) From: Terry Lambert Message-Id: <199901080044.RAA22486@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 00:44:47 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901072306.PAA35328@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 03:06:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, the MFS stuff first. > :> on a soft block. For example, UFS/FFS was never designed to terminate > :> on memory, much less swap-backed memory. Then came along MFS and > :> suddently were (and still are) all sorts of problems. > : > :I'd argue that MFS is an inappropriate use of the UFS code, since the > :UFS code doesn't acknowledge the idea of shrinking block-backing > :objects, and barely (with severe fragmentation based degradation) > :recognizes growing block-backing objects. > > I have no idea what you are talking about here. I'm saying that the MFS problems you are noting are artifacts of the implementation, not the idea, and that if you go back to first principles, and correctly implement the idea, then you won't have those problems. MFS can't give up unuse metadata pages because it's implemented on top of something that thinks that, once something has been used, it's dirty, and it has to have backing store forever afterward. The MFS problems dealing with metadata and cylinder group allocation (basically layout policy) are an artifact of the policy. MFS can't support dropping a cylinder group worth of metadata reference because FFS/UFS can't support that, because, quite simply, they weren't designed with the idea that the underlying backing store could change size. You can grow an MFS in cylinder group untis, at the cost of inequal fragmantation bias on the existing (more used than the new unused area) cylinder groups. This works because it works in FFS, too. MFS itself is a piece of crap whenit comes to juggling backing store requirements because FFS/UFS is a piece of crap under the same circumstances, and MFS is a derivative. > its idea of a fixed block device, just like UFS. A VOP > mechanism already exists to handle block freeing and, in > fact, after the 15th, MFS will start to use it.... file > fragments and meta-data will still get unnecessary swap > assignments, but full file blocks will not. This is a > major improvement and it took me all of 40 minutes to add > the support for it. This is *not* a major improvement. It's a trivial improvement which does nothing to address the issue of fragmentation. The FFS/UFS combination on a fixed backing store is relative immune to fragmentation because of the way the backing store is used via what is, in effect, a statistical hash of blocks into the available space for blocks. The recovery mechanism you outline deals with breaking pages back to the system for reuse, but *aggrivates* the fragmentation issue to an almost unholy level, which just gets worse if you try and add cylinder groups to "grow" the MFS. The *only* soloution to "the MFS problem" is an FS architecture that *expects* the underlying blocks store to break on page boundaries, and either self-defragments or otherwise is made fragmentation immune. Probably the most correct way to do this is to place the memory consumed by the FS into a seperate address space that isn't the kernel's address space, such that the kernel can feel free to relocate its pages out from under it to transparently defragment it. Note: This means that there is an interface seperation between a file as a device, and a VM using the device as a backing store. This incidently means you exit and reeenter the VM on either side of a VFS whose files are being used as a swap store (which means that there is a procedural interface instead of a VM alias in order to ensure coherency between the VM object consuming the file and the VM object backing the file on the underlying device). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 16:46:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04087 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 16:46:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04053; Thu, 7 Jan 1999 16:46:16 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id BAA14895; Fri, 8 Jan 1999 01:45:42 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.1/8.6.9) id AAA00460; Fri, 8 Jan 1999 00:40:50 +0100 (CET) Date: Fri, 8 Jan 1999 00:40:50 +0100 From: Stefan Esser To: Narvi Cc: fn@hungry.com, hackers@FreeBSD.ORG, Stefan Esser Subject: Re: Winchip. Message-ID: <19990108004050.A347@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG Mail-Followup-To: Narvi , fn@hungry.com, hackers@FreeBSD.ORG References: <19990107051341.27476.qmail@terror.hungry.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Narvi on Thu, Jan 07, 1999 at 12:55:39PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-01-07 12:55 +0200, Narvi wrote: > On 6 Jan 1999 fn@hungry.com wrote: > > Does FreeBSD work on Winchip systems? > > > > A cursory examination of the mailing list archives (and /sys/i386/i386/*) > > didn't reveal anything related to it. > > Haven't tested it - it is just not possible here to get any alternative > x86 chips but AMD, and then probably only because of a big bunch of crazy > overclockers. > > But I guess it should work OK, provided you have options CPU_486 & > CPU_386 in the kernel. I recently received 10 old original IBM Pentium machines (for free ;-) with P75 CPUs, and replaced those with WinChip W2/240 CPUs (at 4*60MHz, since those systems had 64MB of 70ns DRAM, and I was afraid they might not run with an 66MHz external clock ;-) The speed-up is impressive, a factor of 3 in some benchmark I tried. Just this evening I started the first "make world" on one of those PCs, but don't have timing results, yet. The WinChip needs a fan (those IBM machines have just a LARGE heat-sink and a fan in the front of the desktop case, this has worked so far) and a switched power regulator most probably is a plus, too. At $55 a piece, the WinChip is a good choice for 3.3V only mainboards, but I'd rather get me an AMD K6, if your mainboard supports dual-voltage CPUs. The kernel is built with CPU_686, BTW. The primary cache of the WinChip supports write-allocation, and I plan to add the necessare detection and configuration code when I have some spare time. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 17:06:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06466 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 17:06:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06460 for ; Thu, 7 Jan 1999 17:06:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA36238; Thu, 7 Jan 1999 17:06:15 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 17:06:15 -0800 (PST) From: Matthew Dillon Message-Id: <199901080106.RAA36238@apollo.backplane.com> To: Terry Lambert Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :This is *not* a major improvement. It's a trivial improvement :which does nothing to address the issue of fragmentation. The :FFS/UFS combination on a fixed backing store is relative immune :to fragmentation because of the way the backing store is used via :what is, in effect, a statistical hash of blocks into the available :space for blocks. I'm sorry, I spent two days testing this. It is a *MAJOR* improvement. Fragmentation is not an issue. While it is true that swap backing for non-data blocks (i.e. fragments, inodes, bitmaps) cannot be recovered, the fact that data blocks *CAN* is *MAJOR* improvement. Fragmentation at the datablock level is irrelevant because it only applies to cleaning dirty pages -- i.e. paging out to SWAP, and the swap code will allocate *contiguous* space for the *fragmented* data. And with the new swapper going in on the 15th, it will even reallocate swap on the fly. The on-the-fly reallocation fixes *ALL* long term fragmentation issues with paging to swap whether it is for MFS or just standard OBJT_DEFAULT or OBJT_SWAP objects. So while the data blocks may be fragmented from the point of view of the MFS 'block' device, they are not fragmented from the point of view of the swap backing store block device. :The recovery mechanism you outline deals with breaking pages back :to the system for reuse, but *aggrivates* the fragmentation issue :to an almost unholy level, which just gets worse if you try and add :cylinder groups to "grow" the MFS. No it doesn't. Explain to me how it aggravates the fragmentation issue. Remember, we *don't* *care* how 'fragmented' the file data is in MFS's device namespace. We just care how fragmented it is on physical media - the swap backing store. The swapper automatically defragments anything over a page in size. -Matt : Terry Lambert : terry@lambert.org :--- Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 17:49:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11095 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 17:49:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11090 for ; Thu, 7 Jan 1999 17:49:16 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id UAA58709; Thu, 7 Jan 1999 20:52:50 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 7 Jan 1999 20:52:50 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Terry Lambert cc: Matthew Dillon , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080044.RAA22486@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, Terry Lambert wrote: > OK, the MFS stuff first. > > > :> on a soft block. For example, UFS/FFS was never designed to terminate > > :> on memory, much less swap-backed memory. Then came along MFS and > > :> suddently were (and still are) all sorts of problems. > > : > > :I'd argue that MFS is an inappropriate use of the UFS code, since the > > :UFS code doesn't acknowledge the idea of shrinking block-backing > > :objects, and barely (with severe fragmentation based degradation) > > :recognizes growing block-backing objects. > > > > I have no idea what you are talking about here. > > I'm saying that the MFS problems you are noting are artifacts of > the implementation, not the idea, and that if you go back to > first principles, and correctly implement the idea, then you > won't have those problems. .... ... .. [snip] MFS is just lazyness, if you want it to grow/work right, you rewrite it instead of hacking FFS on top of it. or you design it in such a way that it's a device that FFS is somewhat aware of. this way when a block is asked to be filled what really happens is that the block passed in is put on the free block list and FFS is given a page of the MFS to use, when FFS pushes the block back to MFS the replaced page is put back under the vnode. MFS then becomes a device instead of a filesystem. although i think it violates some abstraction, does this make sense? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:12:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13825 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:12:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13820 for ; Thu, 7 Jan 1999 18:12:55 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA18859; Thu, 7 Jan 1999 19:11:58 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd018711; Thu Jan 7 19:11:47 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00869; Thu, 7 Jan 1999 19:11:30 -0700 (MST) From: Terry Lambert Message-Id: <199901080211.TAA00869@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 02:11:30 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901072306.PAA35328@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 03:06:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, now on the the non-MFS alias issues: > :There's *no* memory waste, if you don't instanceincoherent copies > :of pages in the first place. > > You are ignoring the point. I mmap() a file. I mmap() the block device > underlying the filesystem the file resides on. I start accessing pages. > Poof... no coherency, plus lots of wasted memory. No. You mmap the file. This instances a vnode, and a VM object using the vnode as a swap store. The VM object using the vnode as a swap store makes VOP_GETPAGES and VOP_PUTPAGES calles through the VFS interface in order to satisfy page read and write faults, respectively. For a 386, which does not support write faulting in kernel mode, this is a problem. You have to unmap the page, and handle the translation lookaside in the fault handler (welcome to the 386 complications to the copyin/copyout routines since time immemorial). The underlying VFS makes VM calls, and these go against the real (VM) backing object. It would be a mistake to try and tunnel the VM through the VFS to alias these objects to the same object. For one thing, they may not be on the same machine. I don't really understand how you expect to be able to use a file on an NFS as a swap store for a program image without a seperate local and remote copy of the object. > You are assuming that VFS devices can be collapsed together such > that the inner layers are not independantly accessible, and thus > cannot be independantly accessed without going through the upper > VFS layers. This is an extremely restrictive view which fails > utterly in a number of already existing cases and fails even > worse when you try to extend the model across a network. No, I'm not allowing aliases in the case of adjacent local layers. Consider the case of an ACL VFS stacking layer stacked on top of an NFS client and under a system call layer. If you expose the ACL layer seperate from the layer on which it is mounted, then you can access the file in two places in the directory hierarchy. The underlying NFS has vnodes that pont to NFSnodes. These have VM objects associated with them. The ACL FS stacks on top of this VFS. It *also* has vnodes. These vnodes are used as abstract credential holders, and point to the underlying vnode in the NFS. These vnodes DO *NOT* have VM objects associated with them. When someone reads or writes a page in the buffer cache from a user space program, then the fault results in a VOP_GETPAGES or VOP_PUTPAGES, repsectively. For the NFS, the information is directly accessed (with lease controls -- otherwise known as opportunity locks - for cache coherency) from the underlying vnode's VM objcts. For the ACL FS stacked on the NFS, the VOP_GETPAGES and VOP_PUTPAGES *ARE PASSED DOWN*. The entire purpose of the ACLFS is to impose access semantics on the underlying vnode objects. The way it does this is by a namespace escape of an access control file that it itself accesses by way direct calls to the underlying NFS. A (really) hidden file, in other words. If we stack a QUOTA FS on top of this, and expose it in another location in the directory hierarchy, the same rules apply. It probably even uses a similar namespace escape to hide a quota file at the root of the directory hierarchy for the mounted FS. If we stack a RESOURCE FS that turns file creations into directory creations, and supports VOP_LOOKUP based inherited flagging semantics on top of this, the same rules apply, but it's a little more complex. When a file is created, it actually creates a directory with the file name, with an internal file namesd something like "filedata" (leaving the 4 character upper case namespace for resources in the "resource fork" or the "_xxx" namespace for an underscore prefix for OS/2 extended atrtibute fors for the file. In each case, however, the requests to obtain the page for reading and writing go down to the cnode object off of which it is hung. OK, that's most FS's for which metadata is tunneled; that's pretty easy to understand. And in the last case, it doesn't really make sense to expose the FS hierarchy underlying the RESOURCE FS layer, because it exposes you to non-cache based namespace coherency problems (e.g., how do you handle someone CD'ing into a directory thats a file, and removing the "filedata" file containing the file data fork, without also removing the associated resource fork or extended attribute? ... You can't, and the VM cache coherency protocol you propose won't handle this non-VM coherency problem, either). Part II: The case where cache coherency is a real issue So now we build a cryptographic FS. It uses any CDROM as a one time pad, and does duplicate eliminatation on the CDROM data so that runs of identical data, especially 0's, are not adjacent to allow statistical analysis. At the same time, it XOR's in a repeating password so that pattern data is not differentially analyzable (we could fix this by using peephole techniques to machine-eliminate repeating patterns, and deal with comoon phrase elimination (English speakers CDROMs probably contain English text, etc.), but we're going to be lazy about the implementation. The OTPFS (One Time Pad FS) has vnode objects that stack on top of the underlying vnode objects. Now we have two problems: (1) The coherency issue can not be dealt with via aliases because the data in the decrypted form of a page can not be used. In other words, there is no direct alias between one page and the other. They are *procedurally* related, but not content-identical (we used a OTP to get around the issue of N:M byte relationships where N != M). Nevertheless, we must deal with read and write faults, and update the upper pages on the former and the lower pages on the latter. (2) Because this is sensitive data, it should not be written to persistant storage. That means that the anonymous pages can't be that anonymous. The pages can't be backed by persistant storage, only memory, and only memory that is protected from view by other processes. So you can't use a file or swap as the backing store for any dirty unencrypted pages; instead, you must reencrypt direty pages and store them out. Since you are using a OTP, if you used the same offset on the CDROM to do this, then you would compromise the pad. Therefore, you must store metadata with the offset into the pad, as well. Probably, you want to *not* write dirty data for as long as possible, since each write of a page will eat another 4k of your pad. Neither of these is amenable to the standard vmobject/vmobject alias soloution. The only way to deal with teh fault issue is procedurally. If an access is done at the intermediate layer (say because you don't want to send cleartext over the net between a remote accessor and the machine on which the data is stored), then the "getpages" needs to operate on the underlying object. In otherwords, a cached copy must be invalidated. Luckily, we do not keep a true cached copy. We merely need to check the underlying page against the upper page for timestamp when a getpages occurs on the upper level page. If the lower level page (and pad offset) has changed out from under it, then the page is updated from the lower level page. Again, we see that we must provide procedural access for page contents. The cached copy is dependent on a lower page reference, even if it does not result in a pad translation. We could simplify this considerably by requiring a pad translation for each unencrypted page reference. We don't do this for two reasons: first, because it's overhead; second, because we need to prove to ourselves that we can handle the coherency issue for multiple accessors at multiple levels, without resorting to VM page aliases. Part III: Where do we need aliases? Aliases would be useful if we wanted to tunnel page mappings between an underlying VM object and an upper level VM object using the FS which owns the underlying object as a file store object for potentially non-adjacent physical blocks. In other words, it's a VN device (file as block device) optimization that isn't strictly necessary, and, given the potential non-adjacency of the underlying blocks, probably not a useful one. The mapping maintenance overhead will drive the cost up to the point that the optimization has no value in all but special (contiguous) cases. Aliases would also be useful if one vnode directly represented the blocks of some underlying vnode. But the savings here are minimal; it would be trivial to cache the FINALVP (the vnode pointer that has the underlying VM object association) as a vnode pointer instead of a VM object alias. Dereferencing a vnode to get an alias object, and dereferencing the alias object to get the actual VM object, is no less expensive than dereferencing a vnode to get a vnode, and then dereferencing that vnode to get the actual VM object. Moreover, this type of optimization assumes a great depth of stacked vnodes. While this might occur in some specialized cases, this type of optimization is best left as an option for the VFS implementor. Indeed, one could easily envision an "ALIASFS" layer, whose sole reason for existance was to provide a vnode that cached the underlying vnode that contained the VM object, many layers below itself. A much saner implementation than introducing aliases everywhere in the expectation of a performance win of a double dereference over a stack traversal. Part IV: Conclusion So we don't need aliases in almost any cases. In the general case of an object that aliases an object, a special cacheing layer, or per layer caching can be employed. Those cases are rare. In transformational layers, such as our OTPFS, the aliases are useless because the data is not the same, and, in fact, increased anonymity of VM resources is counterproductive to the purposes of the FS. It damages their ability to do what they are intended to do. In pure semantic layers, and even in semantic layers that tunnel their information, like our ACLFS, our QUOTAFS, and our RESOURCEFS, it's useless because it would be counterproductive to use real vnodes at these layers in the first place. Using real vnodes in these layers would, in fact, add needless translational complexity (as we see in the 1992 code in /sys/miscfs/nullfs/nullfs_vnops.c to support the ugly nullfs_bypass() VOP -- something not necessary on other platforms because of more correct paging architecture). In other words, we don't need aliases, except in cases where we introduce unnecessary abstraction and complexity, for the apparent purpose of requiring aliases. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:20:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14365 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:20:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14354 for ; Thu, 7 Jan 1999 18:20:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA36593; Thu, 7 Jan 1999 18:19:34 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 18:19:34 -0800 (PST) From: Matthew Dillon Message-Id: <199901080219.SAA36593@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... :.. :[snip] : :MFS is just lazyness, if you want it to grow/work right, you rewrite it :instead of hacking FFS on top of it. : :or you design it in such a way that it's a device that FFS is somewhat :aware of. this way when a block is asked to be filled what really happens :is that the block passed in is put on the free block list and FFS is given :a page of the MFS to use, when FFS pushes the block back to MFS the :replaced page is put back under the vnode. : :MFS then becomes a device instead of a filesystem. : :although i think it violates some abstraction, does this make sense? : :-Alfred This actually does make some sense. What you are basically saying is that it should be possible for the MFS device to rename a VM page cached at a lower layer (mfsobj,page#) to a higher layer (ffs_sub_object,page#). This isn't possible with the current VFS layering. That is, the current VFS layering will pass a KVA mapped buffer down, but it does not expect the lower layer to physically replace the pages associated with the buffer with its own pages. Also, while the clean/dirty state of the page could be retained, the relationship with the lower layer's page's backing store would be lost when it renames the page ( backing store works differently depend on the type of object and cannot be transported across VFS layers ). The page, clean, dirty, or TBD (to be destroyed) state would have to eventually be passed back down to the lower layer when the upper layer is done with it... an extremely dangerous proposition. Implementing a vm_alias would solve half the problem - the lower layer would no longer have to 'loose' its reference to the page, and the upper layer can manipulate the pages in its own object space without having to worry about odd interactions with other layers. If the VFS/BIO system were then changed to *NOT* pass KVA buffers down but instead work solely with bp->b_pages[] arrays, then the upper layer could theoretically instantiate vm_alias's in the array that are initially not associated with any real VM page and pass that down to the lower layer. The lower layer could then simply [re]link the vm_alias's into the proper VM page chains, allocating new physical pages as necessary. If we were to do that, then we would have about 70% of the cache coherency problem solved too - 90% if we discount crossing a network. If the vm_aliases teardown always occurs from the top-down (either by the devices or by the vm_pageout process), pages passed back and forth in this manner would be cache coherent within any given machine. The exceptions would be, mainly, file fragments less then a page in size. Each alias would be able to maintain its own clean/dirty state to optimize teardown operations ( there would also be a general dirty state in the root vm_page ). So to round out the solution a two-way cache coherency protocol is required on top of the vm_aliasing. The protocol is necessary to handle both special cases like file fragments, and changes in coherency that propogate from the bottom-up ( for example, if some other host modifies the same file on the NFS server that you are messing with ). If we make this protocol slightly more complex, it could be made to work over a network hop as well as internally. This is effectively what John and I are putting forth as a solution (though we are debating other ways of doing the equivalent function of 'vm_alias'). -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:49:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA17378 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:49:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17373 for ; Thu, 7 Jan 1999 18:49:29 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA20897; Thu, 7 Jan 1999 19:48:59 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd020857; Thu Jan 7 19:48:51 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA03601; Thu, 7 Jan 1999 19:48:50 -0700 (MST) From: Terry Lambert Message-Id: <199901080248.TAA03601@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 02:48:50 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901072306.PAA35328@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 03:06:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Now we deal with collapsing of layers: > :would be another example, where multiple NULLFS instances collapsed > :to *no* local vnode definitions, and one call boundary. Instead, > :you are suggesting that we instance vnodes in each NULLFS layer, > > You are assuming that these things are collapsable, but very *few* > VFS layers are actually collapseable. For example, there is no way > you could possibly collapse RAID or encryption layer or a mirroring > mid-layer. You can't collapse an MFS layer that is file-backed. > You can't collapse a mirror. You can't collapse a VN device due > to partition translations. In all cases the intermediate layers > can be independantly accessed and, in fact, it is *desireable* to > have the ability to independantly access them. The intent of using non-vnode originating layers is twofold: (1) It gets rid of the coherency issues we've discussed so far. (2) It allows for layer collapse, so that the virtual code path ends up being much smaller than the real code path. The first of these has been nearly discussed to death. Suffice to say that coherency problems come from complexity, and not all complexity has value, in and of itself. The second is a more intersting posit. Consider the case of where I stack 500 NULL stacking layers on top of a mount point. If each layer transition required a vnode translation, this would take a very long time. Well, what's a NULLFS? The NULLFS is primarily a kludge to allow relocation of directories in the filesystem hierarchy. This may at first seem to be a useful and necessary function. But in fact it's a function whose utility grows out of the implementation of directory mapping into the hierarchy in the first place in the per VFS mount routines. Because the mapping of a FS into the directory hierarchy is done at FS mount time, instead of in common upper level code, there are a number of consequences. Among these are: o You have to treat the root FS mount as a special case; this is necessitated by the need to remount root as rea/write using a device that may not be the same as the device provided in the boot procedure (it may, instead, be an alias -- of a different sort than the VM aliases we have previously discussed, in this case a device alias -- which owes more to the implementation of special devices as files in a "SPECFS" than it does to necessity). o There is an artificial distinction between a root mount and an inferior mount point mount. If FS's were not distinguished in this way, but instead kept in a global table, then a general (and therefore more reliable) set of routines could map from the table into the hierarchy. This also means that some FS's can be mounted as inferior FS's within the hierarchy, but *can't* be used as the root FS. o In order to map anying into the directory hierarchy, it has to be the root of a VFS instance. This is because to access the mapping mechanism, you must invoke it by way of some VFS-specific mount code into which it has been embedded. So if we resolve this, where is the utility of the NULLFS? It lies in its ability to act as a sample implementation of a minimal semantic VFS layer. Increasing this by requiring a vnode factory in the NULLFS, and VM alias objects for the underlying VM objects greatly complicates the minimal implementation. It also precludes layer collapse, unless it's predicated on the idea of the "default" VOPS being, in effect, a NULLFS themselves. How does collapsing work? Collapsing does *not* work, as implied in the discussion by Matt, a rune-time short circuit. Collapsing is intended to occur at FS mount time. When an FS is mounted, for every VOP in the descriptor array defined in the structure in (incorrectly compile-time generated) vnode_if.c, a VOP descriptor reference is instanced. [Note: if these descriptors are sorted, as well, then we can get rid of two ponter dereferences and a lot of reformatting glue code, as well, and reference by array offset instead of descriptor pointer reverse lookup]. For VOP's defined by a VFS, the descriptor is taken from the per VFS array of descriptors. For VOP's that *aren't* defined by a VFS, the descriptor is taken from the underlying VFS upon which it is stacked, and so on, until it gets to the bottom, where the VOP's that are substituted return a "not implemented" error. What does this mean for a stack of 500 NULLFS instances? What it means is that for most VOPs (all VOPs, if the VFS architecture wasn't currently screwed up by null_bypass and some ill-considered direct references to NULLVPTOLOWERVP), the VOP's inhereit from the bottom-most VFS! It *also* means that the overhead in figuring this out occurs at the time the VFS is instanced, *not* at runtime. So what's the overhead? 499 descriptor dereferences of 1 descriptor dereference? No. 1 descriptor dereference through the instanced VOPS array. How do we address the objection: > Introducing vnodes to the null stacking layer does not change the > coherency problems associated with the current VFS layering one > iota. You are, again, assuming that the coherency issue will be > magically solved by collapsing VFS layers and ignoring the fact > that most VFS layers (A) can't be collapsed, and (B) that your coherency > solution fails utterly the moment you take a network hop. We address it by noting that most VFS layers (A) *can* be collapsed, and (B) that the coherency issues for those that *can't* be collapsed, like the NFS client VFS, or the OTPFS, *don't* have real aliases, only virtual aliases. When the collapse occurs, what happens is that the *intermediate* no-op VOP's are collapes out, even if they have intervening VOP's that *can't be collapsed out. It is this inherent call-graph reduction which makes it worthwhile to stack a large number of semantic layers in the first place, and which makes it an error to introduce vnodes to layers which don't gain any benefit from having direct VM object references and/or don't need to support semantics for the underlying layers on an per-object basis (even then, layers that need this, such as an ACLFS layer, can "cheat" by file-based tunneling to get away from the requirement; this is, in fact, what UFS does when it puts its quota file references in the in core superblock on a per FS basis instead of in a hidden file in each directory on a per-file basis). > :Works on SunOS. Works on Solaris. If you have a source license, > :or sign non-disclosure, John Heidemann will show you the code. > > Explain to me how it works rather then point me at three hours worth of > research that I have to 'understand' to understand your point. No VOP_BYPASS is needed. Because this is introduced by BSD, BSD has these problems. You can see the reasoning (which is no longer valid) for the VOP_BYPAS in /sys/miscfa/nullfs/nullfs_vnops.c in front of nullfs_bypass(). > There are already a number of situations where coherency > tracking is desireable. Extending the model across a network > tops the list. Being able to use a coherent mmap() on a common > NFS-served partition from N different machines, for example. The MNFS code for FreeBSD from the David Sarnoff Center already addresses the issue of distributed cache coherency, and does it elegantly, without introducing a whole raft of complexity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:52:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA17791 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:52:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17784 for ; Thu, 7 Jan 1999 18:52:04 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA23207; Thu, 7 Jan 1999 19:51:29 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd023140; Thu Jan 7 19:51:22 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA03819; Thu, 7 Jan 1999 19:51:21 -0700 (MST) From: Terry Lambert Message-Id: <199901080251.TAA03819@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 02:51:20 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901080106.RAA36238@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 05:06:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :The recovery mechanism you outline deals with breaking pages back > :to the system for reuse, but *aggrivates* the fragmentation issue > :to an almost unholy level, which just gets worse if you try and add > :cylinder groups to "grow" the MFS. > > No it doesn't. Explain to me how it aggravates the fragmentation > issue. Remember, we *don't* *care* how 'fragmented' the file data > is in MFS's device namespace. We just care how fragmented it is on > physical media - the swap backing store. The swapper automatically > defragments anything over a page in size. Kernel VM space fragmentation. Try to load a quiccam driver KLD that need to malloccontig. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:54:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18019 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:54:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18014 for ; Thu, 7 Jan 1999 18:54:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA36703; Thu, 7 Jan 1999 18:53:36 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 18:53:36 -0800 (PST) From: Matthew Dillon Message-Id: <199901080253.SAA36703@apollo.backplane.com> To: Terry Lambert Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :There's *no* memory waste, if you don't instanceincoherent copies :> :of pages in the first place. :> :> You are ignoring the point. I mmap() a file. I mmap() the block device :> underlying the filesystem the file resides on. I start accessing pages. :> Poof... no coherency, plus lots of wasted memory. : :No. You mmap the file. This instances a vnode, and a VM object using :the vnode as a swap store. What do you mean, no? I just gave you an example of something someone might want to do. Now you tell me how to ensure that it's coherent. Disallowing the case is not an option. You can't just ignore cases that don't fall under your model! :Consider the case of an ACL VFS stacking layer stacked on top of :an NFS client and under a system call layer. :... : :For the NFS, the information is directly accessed (with lease :controls -- otherwise known as opportunity locks - for cache :coherency) from the underlying vnode's VM objcts. : :For the ACL FS stacked on the NFS, the VOP_GETPAGES and VOP_PUTPAGES :*ARE PASSED DOWN*. The entire purpose of the ACLFS is to impose :access semantics on the underlying vnode objects. The way it does :this is by a namespace escape of an access control file that it :itself accesses by way direct calls to the underlying NFS. A :(really) hidden file, in other words. : :If we stack a QUOTA FS on top of this, and expose it in another :... :If we stack a RESOURCE FS that turns file creations into directory :... : :In each case, however, the requests to obtain the page for reading :and writing go down to the cnode object off of which it is hung. :... :easy to understand. And in the last case, it doesn't really make :sense to expose the FS hierarchy underlying the RESOURCE FS :layer, because it exposes you to non-cache based namespace coherency :problems (e.g., how do you handle someone CD'ing into a directory That is the whole point of having a cache coherency protocol. Your design is strictly top-down. You are specifically disallowing the case where someone may tap into a node underneath your 'top' node. You are saying, basically, that it is illegal to do so because your mechansism can't deal with the cache coherency problems associated with that sort of access. There's just one problem: I've given you half a dozen cases where someone might want to tap into an intermediate node. :thats a file, and removing the "filedata" file containing the file :data fork, without also removing the associated resource fork or :extended attribute? ... You can't, and the VM cache coherency :protocol you propose won't handle this non-VM coherency problem, :either). Sure it will. You are thinking top-down again. The whole point of the cache coherency protocol is that it is a two-way protocol... it propogates out from the access point and the access point does NOT have to be starting at the top. The vm_object extension ( vm_alias's or something similar ) is simply an optimization, but one that allows the VM system to do its job almost trivially. Now I suppose you could explicitly design the ACL and QUOTA layers to ignore accesses made out from underneath them, but that seems silly to me... I can think of several situations where the QUOTA layer would definitely want to be updated if someone else makes changes to files that it maps without going through it directly. :Part II: The case where cache coherency is a real issue : :So now we build a cryptographic FS. It uses any CDROM as a one :time pad, and does duplicate eliminatation on the CDROM data so :... :The OTPFS (One Time Pad FS) has vnode objects that stack on top :of the underlying vnode objects. : : :Now we have two problems: : :(1) The coherency issue can not be dealt with via aliases : because the data in the decrypted form of a page can : not be used. In other words, there is no direct alias : between one page and the other. They are *procedurally* : related, but not content-identical (we used a OTP to get : around the issue of N:M byte relationships where N != M). If you would go back and fraggin READ the original proposal, you will note that this case is explcitly covered. Terry, READ THE PROPOSAL. You aren't reading it. I have repeated the solution to this case three times so far, I'm not going to do it again. :In other words, we don't need aliases, except in cases where we :introduce unnecessary abstraction and complexity, for the apparent :purpose of requiring aliases. What you've done is taken a bunch of special cases, mostly degenerate ( and all easily covered by our proposed design ) and come to a patently incorrect conclusion about virtually every aspect of our proposed design, trying to debunk it. You then replaced it with an extremely specialized design of your own that covers ONLY those specific cases and nothing else, has all sorts of restrictions, and cannot maintain cache coherency across a network ( you are missing the point big time if you think that the NFS client-server model is what someone would want to use in a network cluster! ). You aren't thinking big enough. You aren't thinking scaleability or extensibility. You aren't thinking networking and clustering. You *definitely* aren't thinking clustering. And you dismissing efficiency as not being significant... well, I can tell you it is *extremely* significant. One of the biggest problems that cache coherency protocols try to solve is to not only make the cache coherent, but to make I/O operations efficient without losing coherency. -Matt : : Terry Lambert : terry@lambert.org :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:55:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18123 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:55:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yusufg.portal2.com (yusufg.portal2.com [203.85.226.249]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA18108 for ; Thu, 7 Jan 1999 18:55:07 -0800 (PST) (envelope-from yusufg@huge.net) Received: (qmail 27900 invoked by uid 500); 8 Jan 1999 02:54:54 -0000 Date: 8 Jan 1999 02:54:54 -0000 Message-ID: <19990108025454.27899.qmail@yusufg.portal2.com> From: "Yusuf Goolamabbas" To: openldap-devel@openldap.org, freebsd-hackers@FreeBSD.ORG CC: db@sleepycat.com Subject: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Relative FreeBSD newbie alert Hi, I downloaded Berkeley DB 2.6.4 on a FreeBSD 3.0-RELEASE system to use it with OpenLDAP Inside build_unix ../dist/configure --prefix=/usr/local/site/BerkeleyDB --enable-compat185 --enable-dump185 Since OpenLDAP is developed on a FreeBSD system, thought I would check with others. I also tried adding -ldes to LIBS and get the same warning. In particular, the warning about "unsafe" and "stupid" raised my concern. Maybe, I need to get the secure distribution of FreeBSD outside of the US, but I don't want to change from MD5 passwords test ! -f /usr/bin/ranlib || /usr/bin/ranlib libdb.a cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_dump185/db_dump185.c cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../clib/err.c cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../clib/getlong.c cc -o db_dump185 db_dump185.o err.o getlong.o -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_archive/db_archive.c cc -o db_archive db_archive.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_checkpoint/db_checkpoint.c cc -o db_checkpoint db_checkpoint.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_deadlock/db_deadlock.c cc -o db_deadlock db_deadlock.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_dump/db_dump.c cc -o db_dump db_dump.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_load/db_load.c cc -o db_load db_load.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_printlog/db_printlog.c cc -o db_printlog db_printlog.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_recover/db_recover.c cc -o db_recover db_recover.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../db_stat/db_stat.c cc -o db_stat db_stat.o err.o getlong.o libdb.a -lc_r /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. -- Yusuf Goolamabbas yusufg@huge.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 18:55:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18187 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 18:55:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18182 for ; Thu, 7 Jan 1999 18:55:55 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id VAA58800; Thu, 7 Jan 1999 21:59:29 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 7 Jan 1999 21:59:29 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080219.SAA36593@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Matthew Dillon wrote: > :... > :.. > :[snip] > : > :MFS is just lazyness, if you want it to grow/work right, you rewrite it > :instead of hacking FFS on top of it. > : > :or you design it in such a way that it's a device that FFS is somewhat > :aware of. this way when a block is asked to be filled what really happens > :is that the block passed in is put on the free block list and FFS is given > :a page of the MFS to use, when FFS pushes the block back to MFS the > :replaced page is put back under the vnode. > : > :MFS then becomes a device instead of a filesystem. > : > :although i think it violates some abstraction, does this make sense? > : > :-Alfred > > This actually does make some sense. What you are basically saying > is that it should be possible for the MFS device to rename a > VM page cached at a lower layer (mfsobj,page#) to a higher layer > (ffs_sub_object,page#). > > This isn't possible with the current VFS layering. That is, the > current VFS layering will pass a KVA mapped buffer down, but it > does not expect the lower layer to physically replace the pages > associated with the buffer with its own pages. Also, while the > clean/dirty state of the page could be retained, the relationship > with the lower layer's page's backing store would be lost when it > renames the page ( backing store works differently depend on the > type of object and cannot be transported across VFS layers ). The > page, clean, dirty, or TBD (to be destroyed) state would have to > eventually be passed back down to the lower layer when the upper layer > is done with it... an extremely dangerous proposition. um, this doesn't give us a growing MFS and i may be niave about this but consider: FFS requests a block passing in a buffer, the buffer is switched out from under the attached vnode and stored in the free list (or possibly the 'locked' list), a buffer from the Memory device is put in its place and the vnode is marked as such. FFS has the block for a while. Eventually the block is taken off the LRU list because of the nature of the LRU queue, anything removing a block must check the mark to see if it's MFS backed. In fact this could be a callback function, called in general when ANY buffers are reused allowing for other flexibilities, however, this callback may already be in place as the "flush to backing store" call that's done for traditional devices under FFS. At this point a buffer must be reattached to this vnode, it can be brought over from the free list, or perhaps the original buffer could have been placed on the 'locked' list (is this still around?) Maybe this is impossible with what we have, or doesn't make sense sorry. I _really_ need to UTSL more. :) -Alfred btw, what you and John Dyson are working on sounds trully awesome. I really hope you guys consider publishing a paper on it sometime because at that point FreeBSD will have moved so far from 4.4BSD, that the reference books become very far removed from the actual underlying system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:02:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18700 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:02:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18693 for ; Thu, 7 Jan 1999 19:02:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id TAA36778; Thu, 7 Jan 1999 19:01:25 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 19:01:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901080301.TAA36778@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :cylinder groups to "grow" the MFS. :> :> No it doesn't. Explain to me how it aggravates the fragmentation :> issue. Remember, we *don't* *care* how 'fragmented' the file data :> is in MFS's device namespace. We just care how fragmented it is on :> physical media - the swap backing store. The swapper automatically :> defragments anything over a page in size. : :Kernel VM space fragmentation. : :Try to load a quiccam driver KLD that need to malloccontig. What? That's your answer? That's a total bullshit answer and you know it. You are blaming the fragmentation of *physical* memory on subsystems that only use virtual mappings? Give me a break. MFS has nothing to do with physical memory fragmentation... that's a function of the fact that the VM page allocator doesn't give a damn about physical memory fragmentation. It has NOTHING whatsoever to do with MFS or any other VFS layer. Just doing a 'find /usr -type f | xargs md5' will fragment physical memory as badly as MFS might. If you need contiguous physical memory and can't preallocate it, then go and write a defragmenter that reassigns pages. It would not be too difficult - you just force the pager to cycle pages through the cache and organize the free queue to repack them. Right now the free queue's are a kind of LRUish design combined with the page-coloring code. This has NOTHING to do with MFS. Nada. Zilch. None. Zero. : Terry Lambert : terry@lambert.org :--- Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:04:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA19007 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:04:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from codine.icr.com.au (codine.icr.com.au [203.17.49.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18998 for ; Thu, 7 Jan 1999 19:04:16 -0800 (PST) (envelope-from dale@icr.com.au) Received: from sparc.icr.com.au (sparc.icr.com.au [203.17.49.112]) by codine.icr.com.au (8.9.1/8.9.1) with ESMTP id NAA13640 for ; Fri, 8 Jan 1999 13:03:47 +1000 (EST) (envelope-from dale@icr.com.au) Received: from sun1 (roadrunner.secure.icr.com.au [203.37.247.6]) by sparc.icr.com.au (8.8.8+3.0Wbeta13/8.8.8) with SMTP id NAA10535 for ; Fri, 8 Jan 1999 13:18:56 +1000 (EST) (envelope-from dale@icr.com.au) Message-ID: <03eb01be3ab3$6c00c7a0$06f725cb@sun1.icr.com.au> Reply-To: "Dale Walker" From: "Dale Walker" To: Date: Fri, 8 Jan 1999 13:03:09 +1000 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG auth 1f53309e unsubscribe freebsd-hackers dale@icr.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:04:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA19025 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:04:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sicily.odyssey.cs.cmu.edu (SICILY.ODYSSEY.CS.CMU.EDU [128.2.185.138]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA19006 for ; Thu, 7 Jan 1999 19:04:19 -0800 (PST) (envelope-from rvb+@sicily.odyssey.cs.cmu.edu) To: Jos Backus Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: testmain -> ficl ? References: <19990107212146.A57893@hal.mpn.cp.philips.com> From: "Robert V. Baron" Date: 07 Jan 1999 22:03:18 -0500 In-Reply-To: Jos Backus's message of Thu, 7 Jan 1999 21:21:46 +0100 Message-ID: Lines: 20 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jos Backus writes: > Since we have it in the tree anyway, would it make sense to always > build/install testmain and install it as, say, /usr/bin/ficl? Perhaps that > would encourage some people to start fiddling with it, e.g. to enhance the > /boot stuff? A few suggestions: How about a "cat" or "more" command. How about a "kldloaded" predicate. Suppose I want to load the coda coda.ko iff I don't have a kernel with it built in. But then when coda is in the kernel it is not an klm; it is the kernel. So the simplest way to do this is to rather have an "nm command" which returns the address and a testable predicate value indicating whether the lookup succeeded. I'd type: (if (not (nm "coda_vnodeop_entries")) (load "coda")) [obviously, I don't speak forth ... yet] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:05:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA19158 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:05:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA19153 for ; Thu, 7 Jan 1999 19:05:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id TAA36826; Thu, 7 Jan 1999 19:04:44 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 19:04:44 -0800 (PST) From: Matthew Dillon Message-Id: <199901080304.TAA36826@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Now we deal with collapsing of layers: Anything that you can trivially collapse is a degenerate case and thus a relatively easy problem to solve no matter what design you use. Even the current design can almost handle it. Using NullFS as example is ridiculous -- NullFS is about as degenerate as case as you can get. Using it to prove a point makes no sense. Use something complex that requires cache coherency and prove your point with that - except you refuse to consider any stacking cases where cache coherency might be an issue. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:19:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20660 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:19:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20653 for ; Thu, 7 Jan 1999 19:19:34 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id UAA15365; Thu, 7 Jan 1999 20:18:54 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd015340; Thu Jan 7 20:18:49 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id UAA06106; Thu, 7 Jan 1999 20:18:48 -0700 (MST) From: Terry Lambert Message-Id: <199901080318.UAA06106@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 03:18:48 +0000 (GMT) Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901080253.SAA36703@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 06:53:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> :There's *no* memory waste, if you don't instanceincoherent copies > :> :of pages in the first place. > :> > :> You are ignoring the point. I mmap() a file. I mmap() the > :> block device underlying the filesystem the file resides on. > :> I start accessing pages. Poof... no coherency, plus lots of > :> wasted memory. > : > :No. You mmap the file. This instances a vnode, and a VM object using > :the vnode as a swap store. > > What do you mean, no? I just gave you an example of something someone > might want to do. > > Now you tell me how to ensure that it's coherent. Disallowing the > case is not an option. You can't just ignore cases that don't fall > under your model! This particular case, the one where you treat a device node as if it were something other than a vnode (and therefore an FS object and therefore subjecting VOP_GETPAGE/VOP_PUTPAGES to semantic override) and somehow exempt is bogus. You can't ensure that accesses to the underlying device don't break the rules of the FS which is mounted on this device. In general, this is my objection to Julian's "slice" architecture, which requires some user space program to do partitioning instead of an abstract ioctl or fcntl interface to a partition agent. The kernel already knows about the frigging partition table (or disklabel or DOS extendend partitiotn table or SVRR VTOC or *whatever*), and we insist on not using this fact, and instead we insist that we have to teach one program for each of these damn things how to do raw disk access, and further we have to implement some ungodly lock and notify coherency menchanism so we can engage in this stupidity in the first place. I would say that the FS that implements device file semantics is responsible for dealing with this issue by forcing direct accesses up through the FS on which its mounted. In the "slice" code case, this would be tantamount to not allowing a partition to be deleted if someone is using it. For an FS mounted on a raw device simultaneous to raw device access, I'd argue that it's the responsibility of the device FS to respect opportunity locks as if they were non-advisory. If an FS is on a physical device, it owns the damn thing. If you want to distribute this among 50 machines, then you implement an FS that a variable granularity block store, and has no other semantics other than a distributed cache coherency mechanism, and you mount your FS *on top of it*, and let *it* worry about the problem. > :In each case, however, the requests to obtain the page for reading > :and writing go down to the cnode object off of which it is hung. > :... > :easy to understand. And in the last case, it doesn't really make > :sense to expose the FS hierarchy underlying the RESOURCE FS > :layer, because it exposes you to non-cache based namespace coherency > :problems (e.g., how do you handle someone CD'ing into a directory > > That is the whole point of having a cache coherency protocol. > > Your design is strictly top-down. You are specifically disallowing the > case where someone may tap into a node underneath your 'top' node. > You are saying, basically, that it is illegal to do so because your > mechansism can't deal with the cache coherency problems associated with > that sort of access. > > There's just one problem: I've given you half a dozen cases where > someone might want to tap into an intermediate node. No, I'm saying a VM cache coherency mechanism isn't going to do snot-all to ensure that any semantic coherency of any kind other than VM cache coherency is maintained, and that that's not good enough to allow non-semantic access to the underlying substrata. If I have a semantic layer, it doesn't *matter* if I access the layers underneath it. All I', doing is ignoring the semantic constraints. This is a very different thing than ignoring the implied contract between a non-semantic layer and the layer underneath it to not change data in unexpected ways. For a semantic layer that imposed quotas, access to anything other than the quota file would not screw things up (so long as the upper layer asked for Andrew-style notifications and the lower layer agreed to supply them). For the quota file itself, there needs to be the concept of an exclusivity lock for non-semantic regions/data. Right now, we have a mechanism for doing this on a per-file basis. I'd have no real objection to requiring support for non-advisory range locking by VFS consumers of VFS providers (be the consumer the system call layer or a QUOTAFS intent on not having its quota file screwed with out from under it, or an ACLFS intent on ensuring that the ACLsemantics are obeyed, with no exceptions by some schmuck with a promiscuous view onto the underlying directory space). > :thats a file, and removing the "filedata" file containing the file > :data fork, without also removing the associated resource fork or > :extended attribute? ... You can't, and the VM cache coherency > :protocol you propose won't handle this non-VM coherency problem, > :either). > > Sure it will. You are thinking top-down again. The whole point of > the cache coherency protocol is that it is a two-way protocol... it > propogates out from the access point and the access point does NOT > have to be starting at the top. The vm_object extension ( vm_alias's > or something similar ) is simply an optimization, but one that allows > the VM system to do its job almost trivially. Now I suppose you > could explicitly design the ACL and QUOTA layers to ignore accesses > made out from underneath them, but that seems silly to me... I can > think of several situations where the QUOTA layer would definitely want > to be updated if someone else makes changes to files that it maps > without going through it directly. My answer to that is locking and Andrew-style notifications. My personal preference for this would be to only expose the underlying FS layer through a notification layer -- disallow the notification layer from the underlying FS having promiscous exposure, and allow mounting on top of either a non-exposed OR a notification layer that may or may not be exposed. > If you would go back and fraggin READ the original proposal, you > will note that this case is explcitly covered. > > Terry, READ THE PROPOSAL. You aren't reading it. I have repeated > the solution to this case three times so far, I'm not going to do it > again. Give me a URL. It must have occured in non-hackers private mail. [ ... ] > You then replaced it with an extremely specialized design of > your own that covers ONLY those specific cases and nothing > else, has all sorts of restrictions, and cannot maintain > cache coherency across a network ( you are missing the point big time > if you think that the NFS client-server model is what someone would > want to use in a network cluster! ). (1) Not *my* proposal. (2) MNFS manages distribute cache coherency across a network within the context of the existing framework. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:21:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20893 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:21:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20888 for ; Thu, 7 Jan 1999 19:21:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id TAA36935; Thu, 7 Jan 1999 19:20:54 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 19:20:54 -0800 (PST) From: Matthew Dillon Message-Id: <199901080320.TAA36935@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :um, this doesn't give us a growing MFS and i may be niave about this but :consider: : :FFS requests a block passing in a buffer, the buffer is switched out from :under the attached vnode and stored in the free list (or possibly the :'locked' list), a buffer from the Memory device is put in its place and :the vnode is marked as such. : :FFS has the block for a while. : :Eventually the block is taken off the LRU list because of the nature of :the LRU queue, anything removing a block must check the mark to see if :it's MFS backed. Which buffer? The one MFS passed back or the original one that was replaced? I assume you mean that the original buffer is freed and we are now talking about the one MFS passed back, currently under control of FFS, is no longer being used and eventually is ready to be freed again. :In fact this could be a callback function, called in general when ANY :buffers are reused allowing for other flexibilities, however, this :callback may already be in place as the "flush to backing store" :call that's done for traditional devices under FFS. In order for the callback to work, especially if you intend this mechanism to work across VFS layers, the original 'source' of the buffer must be recorded in the vm_page_t. Otherwise the callback doesn't know who to call. :At this point a buffer must be reattached to this vnode, it can be brought :over from the free list, or perhaps the original buffer could have been :placed on the 'locked' list (is this still around?) Anything put on a 'free' list is gone. Or you are mis-defining the function of the 'free' list... it isn't really a free list. The problem with renaming a page isn't with the page being ripped out from the upper VFS layer, but the fact that the lower VFS layer is removing the page from its own map and thus 'looses' track of it - something a vm_alias would solve neatly. -Matt :Maybe this is impossible with what we have, or doesn't make sense sorry. :I _really_ need to UTSL more. :) : :-Alfred : :btw, what you and John Dyson are working on sounds trully awesome. I :really hope you guys consider publishing a paper on it sometime because at :that point FreeBSD will have moved so far from 4.4BSD, that the reference :books become very far removed from the actual underlying system. That is an excellent idea. The VFS stuff we are flame festing over now is not something under immediate development... I'm spending the next 3 months cleaning up the existing VM system first, but something is going to happen at some point down the line. The current situation cannot be scaled or extended easily and it is also way too easy for programmers to make mistakes -- VOP_GETPAGES and VOP_PUTPAGES alone have so many assumed side effects (as to how objects and pages are locked and what state they should be in on return) that it's a wonder there aren't more bugs. I could hack in vm_alias's in about two days, but that doesn't mean I should. I figure by the time I'm done fixing the VM system, the proper course of action to take in regards to VFS/BIO will be more apparent. ( By 'fixing' I mean mainly removing low memory deadlocks, low memory special cases, and removing cross dependancy 'bypasses' and special cases from the vm_pager and vm_object APIs ). I'll include the README that iterates what has been fixed so far (and will be committed on the 15th or 16th after the tree is split) -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) * Complete replacement of swap pager (vm/swap_pager.c) The swap pager has been completely replaced. The new pager uses the new blist bitmap allocator and is able to allocate and deallocate swap from its bitmap without blocking anywhere. Additionally, the new pager is able to avoid memory deadlock situations and as a consequence we have simplified a number of other areas of the VM system. Also vm/vm_swap.c was changed... the swap device block size is now PAGE_SIZE'd. This simplifies code throughout both modules. * Addition of bitmap management module, kern/subr_blist.c Used by the swap system. (the old rlist module has been depreciated). Could be used for other things. * ripped out vm_object_t->paging_offset This field was hacked in all over the source to optimize out a single swap_pager_copy() command in vm/vm_map.c. I've ripped out the optimization because it really doesn't improve performance with the new swapper. * added vm_page_t->swapblk The swapblk for resident pages is stored in the vm_page_t rather then in swap metadata. This field can also be used by other pagers, not just the swap pager. * removed low-memory checks in a couple of places There are a few places, such as in vm/vm_fault.c, where the system will stall a process if memory is low. The problem is that if you have a memory-hogging process this tends to lock up all other processes, making it impossible to login to the machine for fork/exec new programs. The result is an effective lockup. * getpbuf()/relpbuf() - added subsystem limits A new argument has been added, a pointer to an integer counter which is decrmented on getpbuf() and incremented on relpbuf(). getpbuf() will block if the counter is 0. This is on top of blocking when the global buffer pool is exhausted. This feature is required to prevent any one subsystem from hogging pbuf's, which can lockup the machine in a low-memory situation (or lockup the machine, period). * Fixed madvise(). madvise() was badly broken, but people didn't notice it because it wasn't actually trying to free pages immediately so processes had a chance to recover from its mistakes. At the moment madvise() really tries to free the page, but we will probably back off and just clean the page and move it into the cache after testing is complete. * Major revamping of vm/vm_pageout.c Fixed a number of blocking and deadlock situations in pageout.c, mainly relate to the swapper and to the vnode pager. * Major revamping of vm/vm_page.c vm_page_free() has been revamped along with a bunch of other routines. Also, added pager callbacks vm_pager_page_inserted() and vm_pager_page_removed() and shoehorned them into vm_page_insert() and vm_page_free() and such. vm_page_remove()'s functionality has changed and it is now a static function. vm_page_alloc() has been revamped. Removed unnecessary inlining of code. We now formally free cache pages before reusing them (also necessary since the mechanism of freeing a page has changed). Added vm_await() and vm_page_asleep() functions - will be used later. * Major revamping of MFS filesystem code. Now supports VOP_FREEBLKS and handles low-memory conditions better as a side effect of changes made elsewhere. Also added protection of MFS queue at splbio(). * Added device-block-to-page-block and page-block-to-device-block conversions to sys/param.h * Added u_daddr_t to sys/types.h - unsigned version of daddr_t (used by new swap code) * Greatly simplified vm_object_t's swap-related fields, making the structure a little smaller. * Simplified vm_page_t->hashq. Changed the doubly-linked list to a singly linked list, doubled the size of the hash table ( without doubling the storage), and this change also simplifies a bunch of critical path code. * Removed vm_object_t->page_hint. It was slowing things down instead of speeding things up. * Inlined a number of critical vm_pager routines. ----- OTHER CHANGES ----- * Added M_ASLEEP functionality to malloc (this is for later) * Changed malloc flag M_KERNEL to M_USE_RESERVE * Fixed uipc_usrreq.c sorflush() call to make sure it's a socket - it might not be. * vm_meter does not count device objects (such as /dev/mem), because these really skew the results and make vmstat less useful. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:31:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21773 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:31:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21763 for ; Thu, 7 Jan 1999 19:31:24 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id UAA16328; Thu, 7 Jan 1999 20:30:52 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd016283; Thu Jan 7 20:30:51 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id UAA06973; Thu, 7 Jan 1999 20:30:49 -0700 (MST) From: Terry Lambert Message-Id: <199901080330.UAA06973@usr01.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 03:30:49 +0000 (GMT) Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901080253.SAA36703@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 06:53:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian has just made an ultimately sensible proposal... Because you're just down the road (or I'm just up the road), and because John Dyson is in town occasionally, we ough to get together and hash this out over a whiteboard some time when John is in town, and that will save all of us from wearing our fingers down to nubs trying to portray 1000 pictures in 1,000,000 type-written words. Anyone else who's interested in hammering things out should feel free too. Julian has offered to referee, and we can go eat food, which is always a good idea... Of course, Julian's always pushing for a FreeBSD Conference, so this might be him trying sideways for something like that... ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:43:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22813 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:43:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22804 for ; Thu, 7 Jan 1999 19:43:08 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id EAA95877; Fri, 8 Jan 1999 04:42:37 +0100 (CET) (envelope-from des) To: hackers@FreeBSD.ORG Subject: /usr/bin/ftp From: Dag-Erling Smorgrav Date: 08 Jan 1999 04:42:36 +0100 Message-ID: Lines: 17 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There was a discussion about FTP clients on #FreeBSD today, and in connection with that I discussion I noticed that there are bugs in ftp(1)'s argument handling. For instance, "dir |more", which is suggested in the man page as an example of piping, doesn't work - it requires one argument in front of the one with the pipe (so "dir . |more" works) I also noticed that there's a lot of redundancy in cmds.c - practically each command is implemented as a separate function that does its own argument parsing, even though most of them have nearly the same syntax. Whaddya say, is ftp(1) due for a revamp? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:48:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA23517 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:48:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA23510 for ; Thu, 7 Jan 1999 19:48:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id TAA37034; Thu, 7 Jan 1999 19:47:28 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 19:47:28 -0800 (PST) From: Matthew Dillon Message-Id: <199901080347.TAA37034@apollo.backplane.com> To: Terry Lambert Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :........... : :My personal preference for this would be to only expose the :underlying FS layer through a notification layer -- disallow :the notification layer from the underlying FS having promiscous :exposure, and allow mounting on top of either a non-exposed OR :a notification layer that may or may not be exposed. The answer is that you need a general purpose cache coherency protocol that you can count on to propogate throughout the VFS layering. *NOT* an ad-hoc implemention in one VFS layer and another ad-hoc implementation in another. What the VFS layer does on its backend -- if implementing a network protocol such as AFS, NFS, CODA, or something like that, is up to it. Those protocols may have their own cache coherency protocols for their network interfaces, but is has very little to do with the cache coherency protocol that needs to be implemented between VFS layers. :(2) MNFS manages distribute cache coherency across a network : within the context of the existing framework. MNFS is an externalized protocol, just as CODA and standard NFS are. What they implement in their network layer is very different from what they have to deal with in their VFS layer. For example, lets say you export a UFS filesystem via MNFS. Ok, fine... now lets say you import an MNFS filesystem and then re-export it to another machine, and that machine imports it and then re-export it to yet another machine. Will cache coherency be maintained across the chain with MNFS? Without a general cache-coherency protocol for inter-layer VFS it can't unless MNFS short-circuits the protocol. Fine, so now mix protocols... you have a combination of MNFS, AFS, and CODA mounts done in a chain. Lets say each one of these has cache coherency. Will the coherency be maintained across the chain? Nope, it won't. Not unless the VFS layer implements a general cache coherency protocol that these filesystems use. The real power of building a cache coherency protocol into the VFS layering is that it allows you to do things you may not have thought of yet. -Matt : Terry Lambert : terry@lambert.org Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 19:56:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA24281 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 19:56:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24276 for ; Thu, 7 Jan 1999 19:56:36 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id TAA16399; Thu, 7 Jan 1999 19:56:00 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id TAA17941; Thu, 7 Jan 1999 19:55:59 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA05878; Thu, 7 Jan 1999 19:55:58 -0800 (PST) From: Don Lewis Message-Id: <199901080355.TAA05878@salsa.gv.tsc.tdk.com> Date: Thu, 7 Jan 1999 19:55:58 -0800 In-Reply-To: Terry Lambert "Re: questions/problems with vm_fault() in Stable" (Jan 8, 2:48am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: questions/problems with vm_fault() in Stable Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 8, 2:48am, Terry Lambert wrote: } Subject: Re: questions/problems with vm_fault() in Stable } The second is a more intersting posit. } } Consider the case of where I stack 500 NULL stacking layers on } top of a mount point. If each layer transition required a vnode } translation, this would take a very long time. Heidemann's paper also talks about featherweight layers ... } How does collapsing work? } } Collapsing does *not* work, as implied in the discussion by Matt, } a rune-time short circuit. } } Collapsing is intended to occur at FS mount time. } } When an FS is mounted, for every VOP in the descriptor array } defined in the structure in (incorrectly compile-time generated) } vnode_if.c, a VOP descriptor reference is instanced. [Note: if } these descriptors are sorted, as well, then we can get rid of } two ponter dereferences and a lot of reformatting glue code, as } well, and reference by array offset instead of descriptor pointer } reverse lookup]. } } For VOP's defined by a VFS, the descriptor is taken from the per } VFS array of descriptors. } } For VOP's that *aren't* defined by a VFS, the descriptor is taken } from the underlying VFS upon which it is stacked, and so on, until } it gets to the bottom, where the VOP's that are substituted return } a "not implemented" error. What if there is more than one underlying filesystem? mount a FFS filesystem on /a mount an NFS filesystem on /a/b NULLFS mount /a on /n For a VOP not defined for NULLFS, you want to use the FFS VOP for /n/c and the NFS VOP for /n/a/b/c } What does this mean for a stack of 500 NULLFS instances? } } What it means is that for most VOPs (all VOPs, if the VFS architecture } wasn't currently screwed up by null_bypass and some ill-considered } direct references to NULLVPTOLOWERVP), the VOP's inhereit from the } bottom-most VFS! } } It *also* means that the overhead in figuring this out occurs at } the time the VFS is instanced, *not* at runtime. What happens if /a/b is mounted after /a is mounted on /n? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 20:34:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27931 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 20:34:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27924 for ; Thu, 7 Jan 1999 20:34:42 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id XAA58912; Thu, 7 Jan 1999 23:38:28 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 7 Jan 1999 23:38:27 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080320.TAA36935@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Matthew Dillon wrote: > :um, this doesn't give us a growing MFS and i may be niave about this but > :consider: > : > :FFS requests a block passing in a buffer, the buffer is switched out from > :under the attached vnode and stored in the free list (or possibly the > :'locked' list), a buffer from the Memory device is put in its place and > :the vnode is marked as such. > : > :FFS has the block for a while. > : > :Eventually the block is taken off the LRU list because of the nature of > :the LRU queue, anything removing a block must check the mark to see if > :it's MFS backed. > > Which buffer? The one MFS passed back or the original one that was > replaced? I assume you mean that the original buffer is freed and > we are now talking about the one MFS passed back, currently under > control of FFS, is no longer being used and eventually is ready > to be freed again. Yes, I just thought of a simple idea that may make this a reality, ALL pages returned by MFS are marked dirty so that they are 'flushed' to the MFS disk no matter what. Really nothing is done except the fact that the FFS can not 'steal' pages from the MFS and try to reuse them because they DO belong to the MFS. Just an idea for zero copy. (well single copy, kernel to process, instead of kernel to kernel to process) I think what would have to happen is that MFS would be two parts, a very simple 'vn' over memory driver and a system that would 'taint' the arguments passed into it to ensure that they aren't stolen and hock'd off as a clean buffer. > :In fact this could be a callback function, called in general when ANY > :buffers are reused allowing for other flexibilities, however, this > :callback may already be in place as the "flush to backing store" > :call that's done for traditional devices under FFS. > > In order for the callback to work, especially if you intend this > mechanism to work across VFS layers, the original 'source' of the > buffer must be recorded in the vm_page_t. Otherwise the callback > doesn't know who to call. I _think_ i understand. :/ > > :At this point a buffer must be reattached to this vnode, it can be brought > :over from the free list, or perhaps the original buffer could have been > :placed on the 'locked' list (is this still around?) > > Anything put on a 'free' list is gone. Or you are mis-defining the > function of the 'free' list... it isn't really a free list. I'm sorry, i think i meant the front of the LRU list, ready for reuse. > > The problem with renaming a page isn't with the page being ripped out > from the upper VFS layer, but the fact that the lower VFS layer is > removing the page from its own map and thus 'looses' track of it - > something a vm_alias would solve neatly. I'm not arguing against your proposals. What I understand I find very appealing, I just had an observation about MFS that might be applicable. > > -Matt > > :Maybe this is impossible with what we have, or doesn't make sense sorry. > :I _really_ need to UTSL more. :) > : > :-Alfred > : > :btw, what you and John Dyson are working on sounds trully awesome. I > :really hope you guys consider publishing a paper on it sometime because at > :that point FreeBSD will have moved so far from 4.4BSD, that the reference > :books become very far removed from the actual underlying system. > > That is an excellent idea. The VFS stuff we are flame festing over now > is not something under immediate development... I'm spending the next > 3 months cleaning up the existing VM system first, but something is ... > * vm_meter does not count device objects (such as /dev/mem), because > these really skew the results and make vmstat less useful. > Keep us updated. :) I think i'm finally gaining some insight to how these things work. It sounds like it will be great. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 20:48:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29857 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 20:48:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from abyssinian.sleepycat.com (sleepycat.com [199.103.241.218]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA29850 for ; Thu, 7 Jan 1999 20:48:19 -0800 (PST) (envelope-from db@abyssinian.sleepycat.com) Received: (from db@localhost) by abyssinian.sleepycat.com (8.8.8/8.8.8) id XAA23708; Thu, 7 Jan 1999 23:47:48 -0500 (EST) Date: Thu, 7 Jan 1999 23:47:48 -0500 (EST) From: Sleepycat Software Message-Id: <199901080447.XAA23708@abyssinian.sleepycat.com> To: yusufg@huge.net Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 Cc: freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../clib/getlong.c > cc -o db_dump185 db_dump185.o err.o getlong.o -lc_r > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. This is not a Berkeley DB error. Berkeley DB does not use gets(). Regards, Amy Adams =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Amy Adams Berkeley DB Product Manager Sleepycat Software Inc. db@sleepycat.com 394 E. Riding Dr. +1-617-633-2429 Carlisle, MA 01741 http://www.sleepycat.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 20:53:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00854 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 20:53:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00849 for ; Thu, 7 Jan 1999 20:53:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA37668; Thu, 7 Jan 1999 20:53:25 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 20:53:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901080453.UAA37668@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> Which buffer? The one MFS passed back or the original one that was :> replaced? I assume you mean that the original buffer is freed and :> we are now talking about the one MFS passed back, currently under :> control of FFS, is no longer being used and eventually is ready :> to be freed again. : :Yes, I just thought of a simple idea that may make this a reality, ALL :pages returned by MFS are marked dirty so that they are 'flushed' to the :MFS disk no matter what. : :Really nothing is done except the fact that the FFS can not 'steal' pages :from the MFS and try to reuse them because they DO belong to the MFS. : :Just an idea for zero copy. (well single copy, kernel to process, instead :of kernel to kernel to process) Ick. We can't just mark them dirty, it would cost too much. The most common filesystem operation is a read. We do not want to force reads to generate writes back out to swap, which is what marking the page dirty would do. :> from the upper VFS layer, but the fact that the lower VFS layer is :> removing the page from its own map and thus 'looses' track of it - :> something a vm_alias would solve neatly. : :I'm not arguing against your proposals. What I understand I find very :appealing, I just had an observation about MFS that might be applicable. :... :It sounds like it will be great. : :-Alfred Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 21:11:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03012 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 21:11:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03000 for ; Thu, 7 Jan 1999 21:11:49 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id AAA63146; Fri, 8 Jan 1999 00:15:52 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Fri, 8 Jan 1999 00:15:52 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: freebsd-hackers@FreeBSD.ORG Subject: (mfs idea) Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080453.UAA37668@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i trimmed the cc so as to avoid death threats :) On Thu, 7 Jan 1999, Matthew Dillon wrote: > :> > :> Which buffer? The one MFS passed back or the original one that was > :> replaced? I assume you mean that the original buffer is freed and > :> we are now talking about the one MFS passed back, currently under > :> control of FFS, is no longer being used and eventually is ready > :> to be freed again. > : > :Yes, I just thought of a simple idea that may make this a reality, ALL > :pages returned by MFS are marked dirty so that they are 'flushed' to the > :MFS disk no matter what. > : > :Really nothing is done except the fact that the FFS can not 'steal' pages > :from the MFS and try to reuse them because they DO belong to the MFS. > : > :Just an idea for zero copy. (well single copy, kernel to process, instead > :of kernel to kernel to process) > > Ick. We can't just mark them dirty, it would cost too much. The > most common filesystem operation is a read. We do not want to force > reads to generate writes back out to swap, which is what marking the > page dirty would do. I'm still unsure about my proposal, but i _know_ you misunderstood me :) The buffer is just marked as dirty so that the FFS doesn't overwrite it. MFS _must_ reclaim them into it's own address space to avoid being overwritten. Since i assume that when a buffer is flushed it should then be free you have to 'give something back' What you give back is either dependant on what you did with the original buffer you replaced, you either had: a) hid/put it on the locked list, so now you just retrieve it and spam it under the vnode. (simple lookup & pointer swap) b) overcommited and put it on the LRU list, you must now traverse the LRU looking for pages that are not MFS, force them out and return the non MFS buffers to the vnode. (buffer chain traversal) (*) the mfs still has to contend with normal processes for memory, however when one of it's pages is in the buffer-cache it must be 'locked' so a buffer is not spammed onto swap, as i don't think the buffer cache can handle not being in memory. (*) since freebsd's vm/cache is dynamic it should be able to handle a disapearing buffer midway in the LRU (or maybe this is already done, or just can't be done :( ) -Alfred > Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet > Communications & God knows what else. > (Please include original email in any response) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 21:23:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04345 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 21:23:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA04340 for ; Thu, 7 Jan 1999 21:23:55 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 5197 invoked from network); 8 Jan 1999 05:23:22 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 8 Jan 1999 05:23:22 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id AAA00601; Fri, 8 Jan 1999 00:23:23 -0500 (EST) Message-Id: <199901080523.AAA00601@y.dyson.net> Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080251.TAA03819@usr01.primenet.com> from Terry Lambert at "Jan 8, 99 02:51:20 am" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 8 Jan 1999 00:23:22 -0500 (EST) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > :The recovery mechanism you outline deals with breaking pages back > > :to the system for reuse, but *aggrivates* the fragmentation issue > > :to an almost unholy level, which just gets worse if you try and add > > :cylinder groups to "grow" the MFS. > > > > No it doesn't. Explain to me how it aggravates the fragmentation > > issue. Remember, we *don't* *care* how 'fragmented' the file data > > is in MFS's device namespace. We just care how fragmented it is on > > physical media - the swap backing store. The swapper automatically > > defragments anything over a page in size. > > Kernel VM space fragmentation. > > Try to load a quiccam driver KLD that need to malloccontig. > Aiiieee!!! The kernel doesn't care about virtual addresses at all, and the issue of malloccontig is only an issue of not going to the trouble of reallocating KVA space. This has NOTHING to do with pages used for storage: KVA (kernel virtual address) space is highly decoupled from memory, and in fact is more expensive in many ways than bulk memory. The system in general has little or no support for contiguous memory, and that issue is orthogonal to any of the discussions herein (other than the bogusness of synthetic entities such as bp's that imply often unneeded kernel KVA mappings.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 21:32:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05518 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 21:32:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA05510 for ; Thu, 7 Jan 1999 21:32:19 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id QAA25748; Fri, 8 Jan 1999 16:33:52 +1100 (EST) (envelope-from jb) From: John Birrell Message-Id: <199901080533.QAA25748@cimlogic.com.au> Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 In-Reply-To: <199901080447.XAA23708@abyssinian.sleepycat.com> from Sleepycat Software at "Jan 7, 1999 11:47:48 pm" To: db@abyssinian.sleepycat.com (Sleepycat Software) Date: Fri, 8 Jan 1999 16:33:52 +1100 (EST) Cc: yusufg@huge.net, freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sleepycat Software wrote: > > cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../clib/getlong.c > > cc -o db_dump185 db_dump185.o err.o getlong.o -lc_r > > /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. > > This is not a Berkeley DB error. Berkeley DB does not use gets(). Not commenting on the gets() warning, but the link line above links db_dump185 against libc_r _and_ libc which is most certainly not what is intended. If the application is threaded, pass `-pthread' to gcc and it will link against libc_r /instead/ of libc. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 22:08:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA08602 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 22:08:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA08597 for ; Thu, 7 Jan 1999 22:08:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id WAA37994; Thu, 7 Jan 1999 22:08:22 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 22:08:22 -0800 (PST) From: Matthew Dillon Message-Id: <199901080608.WAA37994@apollo.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: (mfs idea) Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The buffer is just marked as dirty so that the FFS doesn't overwrite it. :MFS _must_ reclaim them into it's own address space to avoid being :overwritten. : :Since i assume that when a buffer is flushed it should then be free :you have to 'give something back' :... I think I understand. The problem is that the system has no clue that the vm_page needs to be returned to MFS. Once MFS gives the page away, that is the end of the matter as far as the system is concerned. Now, of course, we could *make* the system aware that it needs to do something special with the page -- but if we do not create a generally useful mechanism it would be nothing more then a bad hack. Any mechanism that we would create to handle this situation would have to handle moving the page across an arbitrary number of VFS layers, and then either handed back down through the same layers or handed back to the original layer... we cannot assume it will be moved across only two VFS layers. Essentially, the vm_alias mechanism that I described would be able to handle this sort of situation. Could we hack in something simpler? Probably, but it might not be generic enough to be useable in other situations. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 22:48:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11529 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 22:48:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11524 for ; Thu, 7 Jan 1999 22:48:06 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id BAA63241; Fri, 8 Jan 1999 01:52:09 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Fri, 8 Jan 1999 01:52:09 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Matthew Dillon cc: freebsd-hackers@FreeBSD.ORG Subject: Re: (mfs idea) Re: questions/problems with vm_fault() in Stable In-Reply-To: <199901080608.WAA37994@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Matthew Dillon wrote: > :The buffer is just marked as dirty so that the FFS doesn't overwrite it. > :MFS _must_ reclaim them into it's own address space to avoid being > :overwritten. > : > :Since i assume that when a buffer is flushed it should then be free > :you have to 'give something back' > :... > > I think I understand. The problem is that the system has no clue that > the vm_page needs to be returned to MFS. Once MFS gives the page away, > that is the end of the matter as far as the system is concerned. When a block device fills in a buffer and it is then written to causing it to become dirty, doesn't it have to be flushed to the same device it was fetched from? Since MFS is a pseudo device _and_ a filesystem, won't all dirty pages actually be handed back eventually to the device portion of the code? Doing a lookup can determine if the buffer is actually part of the newfs process, or just a formulated write... (this would be a memory to memory copy, or MFS could steal this buffer and traverse the LRU to force out a buffer to return.) You are saying that the dirty buffer can be lost to the MFS, if this is possible, then how do the other filesystems maintain stability if they can possibly never be flushed out? > Now, of course, we could *make* the system aware that it needs to do > something special with the page -- but if we do not create a generally > useful mechanism it would be nothing more then a bad hack. Any mechanism > that we would create to handle this situation would have to handle > moving the page across an arbitrary number of VFS layers, and then either > handed back down through the same layers or handed back to the original > layer... we cannot assume it will be moved across only two VFS layers. since MFS is a bottom layer, the pages can be moved around as much as you want, with the stipulation that since it's dirty it always must be sent back to be flushed out... which is where the swap is of actual address space for buffer pages is done... i think it's more of a hack in the MFS than the general filesystem code, all that has to be done is that the buffers (which are really just pages of the mfs allocation) are always marked dirty so they make their way back to the storage (the address space of the mfs entity) > Essentially, the vm_alias mechanism that I described would be able to > handle this sort of situation. Could we hack in something simpler? > Probably, but it might not be generic enough to be useable in other > situations. A _real_ MFS is always good, one that has a maximum size, and doesn't need to satisfy the FFS's optimizations for mass storage and does zero copy. I was just wondering if it's possible to do this as a temporary improvement? I really need to understand and read the code more, consider me off your back for the time being. :) thanks, -Alfred > > -Matt > > > Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet > Communications & God knows what else. > (Please include original email in any response) > > 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 Jan 7 22:52:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12132 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 22:52:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12123 for ; Thu, 7 Jan 1999 22:52:29 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id RAA14225 for ; Fri, 8 Jan 1999 17:21:57 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 08 Jan 1999 17:22:18 +1030 (CST) From: "Daniel O'Connor" To: freebsd-hackers@FreeBSD.ORG Subject: Joliet Patches Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I notice that the Joliet thread in the PR database (kern/5038) is getting kind of large.. There are like 4 sets of patches in it now :) Byung Yang updated it for 3.0-RELEASE, so maybe it could be committed sometime soon? :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 22:53:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12225 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 22:53:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles115.castles.com [208.214.165.115]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12220 for ; Thu, 7 Jan 1999 22:53:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id WAA00544; Thu, 7 Jan 1999 22:50:02 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901080650.WAA00544@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Robert V. Baron" cc: Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: testmain -> ficl ? In-reply-to: Your message of "07 Jan 1999 22:03:18 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jan 1999 22:50:02 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Jos Backus writes: > > > Since we have it in the tree anyway, would it make sense to always > > build/install testmain and install it as, say, /usr/bin/ficl? Perhaps that > > would encourage some people to start fiddling with it, e.g. to enhance the > > /boot stuff? > A few suggestions: > How about a "cat" or "more" command. > > How about a "kldloaded" predicate. Suppose I want to load the coda > coda.ko iff I don't have a kernel with it built in. But then when > coda is in the kernel it is not an klm; it is the kernel. So the simplest > way to do this is to rather have an "nm command" which returns the > address and a testable predicate value indicating whether the lookup > succeeded. I'd type: > (if (not (nm "coda_vnodeop_entries")) > (load "coda")) > [obviously, I don't speak forth ... yet] Actually, if Coda properly registers itself as a module even when compiled into the kernel, the preload loaded Coda module will be ignored. That's obviously undesirable. The problem here is that there's not (yet) suitable metainformation associated with modules to allow the loader to check the kernel for what it already contains. There are various reasons for this not having been included; my excuse right now is that I wanted to fix linker sets for KLDs first, but in fact this metainformation can be incorporated regardless, so I should probably just bite the bullet and do it - we've already more or less agreed on how it can look. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 22:56:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12433 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 22:56:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles115.castles.com [208.214.165.115]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12428 for ; Thu, 7 Jan 1999 22:56:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id WAA00573; Thu, 7 Jan 1999 22:52:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901080652.WAA00573@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav cc: hackers@FreeBSD.ORG Subject: Re: /usr/bin/ftp In-reply-to: Your message of "08 Jan 1999 04:42:36 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Jan 1999 22:52:33 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There was a discussion about FTP clients on #FreeBSD today, and in > connection with that I discussion I noticed that there are bugs in > ftp(1)'s argument handling. For instance, "dir |more", which is > suggested in the man page as an example of piping, doesn't work - it > requires one argument in front of the one with the pipe (so "dir . > |more" works) > > I also noticed that there's a lot of redundancy in cmds.c - > practically each command is implemented as a separate function that > does its own argument parsing, even though most of them have nearly > the same syntax. > > Whaddya say, is ftp(1) due for a revamp? Check to make sure that the NetBSD folks haven't already gone down this path (the last major update was a sync with some of their good work), and then MHO is that you should wield the knife. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 7 23:57:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18647 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 23:57:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18639 for ; Thu, 7 Jan 1999 23:57:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id XAA38476; Thu, 7 Jan 1999 23:56:44 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 23:56:44 -0800 (PST) From: Matthew Dillon Message-Id: <199901080756.XAA38476@apollo.backplane.com> To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: (mfs idea) Re: questions/problems with vm_fault() in Stable References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :When a block device fills in a buffer and it is then written to causing it :to become dirty, doesn't it have to be flushed to the same device it was :fetched from? : :Since MFS is a pseudo device _and_ a filesystem, won't all dirty pages :actually be handed back eventually to the device portion of the code? :Doing a lookup can determine if the buffer is actually part of the newfs :process, or just a formulated write... (this would be a memory to memory :copy, or MFS could steal this buffer and traverse the LRU to force out a :buffer to return.) : :You are saying that the dirty buffer can be lost to the MFS, if this is :possible, then how do the other filesystems maintain stability if they :can possibly never be flushed out? No, it doesn't work that way. Filling the buffer does not necessary make the pages associated with the buffer dirty. They are... but only temporarily. The caller marks them clean after the I/O is complete because, really, that is what they are. Ultimately, 'dirty' is an indication that a writeback is required. When a filesystem issues a read from a lower level device, those blocks are NOT dirty because the filesystem can throw them away at any time and re-read them again. So when the filesystem issues the read, it clears the dirty bit on the page on completion of the read. Thus if the dirty bit is set later it means that the filesystem *modified* something and that a writeback is required. Otherwise it wouldn't know. :since MFS is a bottom layer, the pages can be moved around as much as you :want, with the stipulation that since it's dirty it always must be sent MFS is not the bottom layer. Swap is the bottom layer. Or a another file (and then even it may not be the bottom layer). You can use a file as backing store for an MFS filesystem. It doesn't have to be swap. Swap itself might be mounted on a VN device and also not be the bottom layer. The problem with all these layers is that you wind up doing actual data copying to get pages between them with VOP calls unless you can forward the VOP_STRATEGY call (which is what the vn device does)... but MFS can't do this, there is nowhere to forward the call to. If the point of the exercise is to avoid that and to pass the page directly up from a lower layer to a higher layer, you can't just play tricks with the dirty bits - you will lose state. You have to tag the page with the original information before you 'rename' it up to a higher level, so at some point in the future someone trying to free the page will notice the tag and know to call back down. :i think it's more of a hack in the MFS than the general filesystem code, :all that has to be done is that the buffers (which are really just pages :of the mfs allocation) are always marked dirty so they make their way back :to the storage (the address space of the mfs entity) No, it isn't so simple. The only thing MFS owns is its address space. The buffers passed to it in an I/O request are *NOT* owned by MFS and are *NOT* part of it's 'disk's address space. For any given I/O, there are *TWO* pages involved... the page passed to MFS in the I/O request, and the page representing the MFS disk image that MFS owns. At the moment, MFS physically copies data from one page to the other. This maintains the clean/dirty status of the MFS disk page and allows the caller to maintain the clean/dirty status of the page it passes to MFS independantly (and the caller always marks it's own pages clean after issuing the read). If the purpose of the exercise is to avoid the data copy, MFS would have to replace the caller's page with its own. The only way to do that is for MFS to *rename* the page -- remove it from MFS's VM object and add it to the callers while at the same time throwing away the page supplied by the caller. At that point, the page is no longer owned by MFS and the caller can do anything it likes with it, including destroying the previous clean/dirty state of the page. If we force the caller to mark the page dirty, we can succeed in getting it to commit the page back to MFS some time later but at a huge cost - because MFS would not be able to tell whether the page actually needs to be written back to swap or not. Reading a file would result in dirtying pages and re-writing swap, which is not desireable. :A _real_ MFS is always good, one that has a maximum size, and doesn't need :to satisfy the FFS's optimizations for mass storage and does zero copy. : :I was just wondering if it's possible to do this as a temporary :improvement? No. Sorry. :I really need to understand and read the code more, consider me off your :back for the time being. :) : :thanks, :-Alfred Suggested reading: /usr/src/sys/ufs/mfs/*.c /usr/src/sys/vm/vnode_pager.c ( read vnode_pager_generic_getpages() ) -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 01:52:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA00830 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 01:52:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA00824 for ; Fri, 8 Jan 1999 01:52:11 -0800 (PST) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.8.8/8.8.8) with SMTP id RAA22502 for ; Fri, 8 Jan 1999 17:51:29 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id RAA04160; Fri, 8 Jan 1999 17:51:29 +0800 Message-Id: <199901080951.RAA04160@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: The ongoing influx of SPAM into the lists. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jan 1999 17:51:15 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have refrained from whinging about each & every bit of spam that ends up in these mailing lists, as it usually just adds to the noise. Now, I've had a gutful. Can we please move it to subscriber only postings? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 02:02:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA02082 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 02:02:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA02073 for ; Fri, 8 Jan 1999 02:02:07 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.2/8.9.2) with ESMTP id KAA05020; Fri, 8 Jan 1999 10:01:22 GMT Message-ID: <3695D746.82223F3F@tdx.co.uk> Date: Fri, 08 Jan 1999 10:00:38 +0000 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hocking-Senior Programmer PGS Tensor Perth CC: hackers@FreeBSD.ORG Subject: Re: The ongoing influx of SPAM into the lists. References: <199901080951.RAA04160@ariadne.tensor.pgs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > I have refrained from whinging about each & every bit of spam that ends up in > these mailing lists, as it usually just adds to the noise. Now, I've had a > gutful. Can we please move it to subscriber only postings? > > Stephen Only if we have to? - I know a few people who have 'intermittent' net access / freemail accounts, and have to make do... I've looked through the headers, and mailed the ISP's involved (including the ones that promiscuously relay) - I'd suggest a few more people do that first and see what happens, before we go and get draconian... ;-) -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 02:18:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA03363 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 02:18:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA03341; Fri, 8 Jan 1999 02:18:21 -0800 (PST) (envelope-from lorenzaj@agcs.com) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.1/8.9.1) with ESMTP id DAA27484; Fri, 8 Jan 1999 03:15:57 -0700 (MST) Posted-Date: Fri, 8 Jan 1999 03:15:57 -0700 (MST) Received: from agcs.com ([130.131.46.155]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA757; Fri, 8 Jan 1999 03:17:51 -0700 Message-ID: <3695DB4D.ECA7464B@agcs.com> Date: Fri, 08 Jan 1999 03:17:49 -0700 From: "Juan Lorenzana" Organization: AG Communication Systems X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd,comp.unix.questions To: lorenzaj@agcs.com, hackers@FreeBSD.ORG, questions@FreeBSD.ORG Subject: FreeBSD 2.2.2 Hanging Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a FreeBSD 2.2.2 installation running on a PII 333 with 512 Megs of ram and 1024 Megs of swap. Due to the nature of the application running on it, we can not upgrade. The kernel is configured for 256 megs of ram, but that is because I thought I might have other issues (bounce buffers) that might be kludging everything up. maxusers is set to 64, maxmem to 256, and I have a few shared memory options but other than that, I have the basic GENERIC kernel. The box uses the vx0 driver for a 3COM905 card running 100 M/bits full duplex and has a Mylex BT-958 SCSI controller with an IBM 4 gig disk with S.M.A.R.T. enabled. The system runs as an nfs client and therefore runs nfsiod -n 4 I am mounting from another FreeBSD box with /sbin/mount -t nfs -o -i,-s,-w=1024 nfs_serv:/u /u or /sbin/mount -t nfs -o -i,-s,-w=1024,-r=8192 nfs_serv:/u /u it does not matter. The nfs server has max open set to 512 which should break RPC calls (but this was working fine before). The nfs server has a raid volume with two partition and mounts both with -noatime for better performance. The nfs client machine hangs and I do not know why. The symptoms are as follows: Console hangs (takes no input nor produces output), tcp/ip stack is still up and responds to ping. Telnet only gets this far _ Trying 192.168.22.193... Connected to host246.agcs.com. Escape character is '^]'. That's it. cntl-alt-delete will sometime reboot but not always. Any ideas what I might be running into? I have looked at pstat -T, netstat -m, swapinfo, top, but nothing out of the normal and it does not look like I hit an limits. I have set up the login.conf file so that both root and default users have infinity (unlimited) everything. I did this because I thought I was hitting some type of limit that was not showing up in the pstat, netstat, nor fstat. I do not know what to do next. Any ideas would be appreciated. I have ktrace enabled, but do not know how to use it. I suspect that maybe there is an nfs issue with the FreeBSD NFS server having maxopen set to 512 and possible rpc issues. I had the nfs client (machine that hangs) set that way for a while, but that did not make things better nor worse. The system just gets to a point where everything stop working, and there is plenty of memory left, and no signs of trouble nor a panic in the logs. I have swapped out the memory as well as the ethernet card once before. Thanks for any help you can offer. Please email with ideas or suggestions. Thanks again and I hope I posted this question to the right areas. Regards, -- Juan Lorenzana AG Communication Systems Phoenix, AZ 602-582-7442 lorenzaj@agcs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 02:20:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA03677 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 02:20:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA03663 for ; Fri, 8 Jan 1999 02:19:54 -0800 (PST) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id UAA18647; Fri, 8 Jan 1999 20:49:18 +1030 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA10707; Fri, 8 Jan 1999 20:49:13 +1030 Date: Fri, 8 Jan 1999 20:49:13 +1030 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Karl Pielorz Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , hackers@FreeBSD.ORG Subject: Re: The ongoing influx of SPAM into the lists. In-Reply-To: <3695D746.82223F3F@tdx.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, Karl Pielorz wrote: > Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > > I have refrained from whinging about each & every bit of spam that ends up in > > these mailing lists, as it usually just adds to the noise. Now, I've had a > > gutful. Can we please move it to subscriber only postings? > > > > Stephen > > Only if we have to? - I know a few people who have 'intermittent' net access / > freemail accounts, and have to make do... > > I've looked through the headers, and mailed the ISP's involved (including the > ones that promiscuously relay) - I'd suggest a few more people do that first The spam content of the freebsd lists is actually quite low. I subscribed to fetchmail-announce and got spammed through there 6 times during the first night (all ended up in the bit-bucket thanks to procmail). That's an example of what happens on an unfiltered mailing list :-) (I think f-a has since been closed to posting). I also always complain to the systems which originate/relay spam (except when it's obviously a purchased domain owned by the spammer, in which case his upstream provider), and usually get results (at least, according to the automated feedback I get :) I'd be interested to hear statistics of how much mail gets bounced off the hub spam filters.. Kris ----- (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 02:52:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06831 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 02:52:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smarter.than.nu (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06825 for ; Fri, 8 Jan 1999 02:52:41 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from localhost (localhost [127.0.0.1]) by smarter.than.nu (8.9.1/8.9.1) with ESMTP id CAA93224; Fri, 8 Jan 1999 02:51:53 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Date: Fri, 8 Jan 1999 02:51:53 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu Reply-To: freebsd-chat@FreeBSD.ORG To: Stephen Hocking-Senior Programmer PGS Tensor Perth cc: hackers@FreeBSD.ORG Subject: Re: The ongoing influx of SPAM into the lists. In-Reply-To: <199901080951.RAA04160@ariadne.tensor.pgs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I have refrained from whinging about each & every bit of spam that ends up in > these mailing lists, as it usually just adds to the noise. Now, I've had a > gutful. Can we please move it to subscriber only postings? I have a suggestion that would accomplish the same goal but still allow people to post from a different address than they subscribe to: Filter posts that do not fit at least one of these criteria: - From: header contains an e-mail address subscribed to the list. - To: or Cc: header includes the list's address. As most spam is bulkmailed without changing the To: header for each recipient, this will filter out 99% of the spam, while still allowing non-subscribed people to post, so long as it isn't a Bcc. Acceptable compromise? -- Brian Buchanan brian@smarter.than.nu brian@CSUA.Berkeley.EDU "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:28:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09948 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:28:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA09942 for ; Fri, 8 Jan 1999 03:28:54 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 2.02 #1) id 0zya5Y-0002dx-00 (Debian); Fri, 8 Jan 1999 11:28:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13973.60376.9845.729115@chiark.greenend.org.uk> Date: Fri, 8 Jan 1999 11:28:24 +0000 (GMT) From: dot@dotat.at (Tony Finch) To: hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... In-Reply-To: <199901070335.UAA11431@usr09.primenet.com> References: <199901070335.UAA11431@usr09.primenet.com> X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > > Sometimes you want M to be large relative to the number of CPUs > > because you are using threading to improve userland IO concurrency. > > Finish the thought: > > "...and you don't want to use async I/O to improve I/O > concurrency because, while doing so would be less overhead > than using a bunch of threads, it doesn't accomplish > your *real* goal." The other reason for not using aio is because the aio calls do not cover the whole range of system calls that block (open, close, stat, unlink, etc...). I don't see how you can fix that without either using some sort of fork or adding stuff to the API. Tony. -- f.a.n.finch fanf@demon.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:37:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA10531 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:37:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA10526; Fri, 8 Jan 1999 03:37:05 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id MAA06662; Fri, 8 Jan 1999 12:39:42 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 8 Jan 1999 12:39:41 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Luigi Rizzo cc: Andrew.Atrens.atrens@nt.com, viren@rstcorp.com, jim@reptiles.org, freebsd-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: utility for setting PNP info in /etc/rc.conf? In-Reply-To: <199901071905.UAA09195@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 7 Jan 1999, Luigi Rizzo wrote: > > > This approach worked fine for me too... Prior to elfing my kernel I was > > > using `dset' to accomplish same, but it appears to yack on the elf kernel > > > with something cryptic like: > > > > Indeed, dset doesn't seem to work with ELF kernels - I'm quite surprised > > at it, so close to 3.0.1-R... > > what about the "kget" thing you have in FreeBSD, Andrzej ? "kget" also stopped working with difficult to debug problem (stack frame gets corrupted, and I really don't see why). Anyway, in the meantime I added new sysctl machdep.uc_devlist which retrieves list of devices which has been changed during UserConfig session. IMHO, this is the proper way to do it anyway, instead of dirty hacks with /dev/kmem, symbols list etc. etc. So, my development copy of "kget" works just fine again, and what with dset - I don't know. "kget" doesn't write this stuff back to the kernel image (what a disgusting idea...), it just creates /kernel.config. If we come to conclusion that this is what dset should do as well, we can simply rename kget->dset. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:50:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11836 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:50:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11829 for ; Fri, 8 Jan 1999 03:50:18 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA24208; Fri, 8 Jan 1999 20:49:45 +0900 (JST) Message-ID: <3695C1B9.ED86E609@newsguy.com> Date: Fri, 08 Jan 1999 17:28:41 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: PR database Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there anyway to automatically receive messages sent to one category of the PR database (not being a committer)? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:50:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11842 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:50:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11826 for ; Fri, 8 Jan 1999 03:50:16 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA24187; Fri, 8 Jan 1999 20:49:36 +0900 (JST) Message-ID: <3695BE8B.C4EDB7B4@newsguy.com> Date: Fri, 08 Jan 1999 17:15:07 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jos Backus CC: freebsd-hackers@FreeBSD.ORG Subject: Re: testmain -> ficl ? References: <19990107212146.A57893@hal.mpn.cp.philips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jos Backus wrote: > > Since we have it in the tree anyway, would it make sense to always > build/install testmain and install it as, say, /usr/bin/ficl? Perhaps that > would encourage some people to start fiddling with it, e.g. to enhance the > /boot stuff? I'd have prefered a userland loader... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:50:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11864 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:50:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11851 for ; Fri, 8 Jan 1999 03:50:24 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA24192; Fri, 8 Jan 1999 20:49:39 +0900 (JST) Message-ID: <3695BF17.F21E24CE@newsguy.com> Date: Fri, 08 Jan 1999 17:17:27 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Robert V. Baron" , hackers@FreeBSD.ORG Subject: Re: testmain -> ficl ? References: <19990107212146.A57893@hal.mpn.cp.philips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Robert V. Baron" wrote: > > A few suggestions: > How about a "cat" or "more" command. > > How about a "kldloaded" predicate. Suppose I want to load the coda > coda.ko iff I don't have a kernel with it built in. But then when > coda is in the kernel it is not an klm; it is the kernel. So the simplest > way to do this is to rather have an "nm command" which returns the > address and a testable predicate value indicating whether the lookup > succeeded. I'd type: > (if (not (nm "coda_vnodeop_entries")) > (load "coda")) > [obviously, I don't speak forth ... yet] Adding to queue... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 03:50:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11880 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 03:50:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11874 for ; Fri, 8 Jan 1999 03:50:29 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA24223; Fri, 8 Jan 1999 20:49:53 +0900 (JST) Message-ID: <3695D856.43EC54EB@newsguy.com> Date: Fri, 08 Jan 1999 19:05:10 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Wilko Bulte , hackers@FreeBSD.ORG Subject: Re: proposed mod to ps(1) References: <199901071838.TAA00770@yedi.iaf.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote: > > Seems like a good idea. Let's hope there is a spare option letter in our > 26 letter alfabet ;-) Hey, what were uppercase letters made for? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 05:00:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19932 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 05:00:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19924 for ; Fri, 8 Jan 1999 05:00:35 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id OAA21614; Fri, 8 Jan 1999 14:05:45 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 8 Jan 1999 14:05:44 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: "Daniel C. Sobral" cc: Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: testmain -> ficl ? In-Reply-To: <3695BE8B.C4EDB7B4@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, Daniel C. Sobral wrote: > Jos Backus wrote: > > > > Since we have it in the tree anyway, would it make sense to always > > build/install testmain and install it as, say, /usr/bin/ficl? Perhaps that > > would encourage some people to start fiddling with it, e.g. to enhance the > > /boot stuff? > > I'd have prefered a userland loader... :-) What do you mean? The only thing that comes to my mind is an emulator of the real bootloader, so that you could test things. Well, userland bootloader -> KLD is kind of one. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 05:37:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA24263 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 05:37:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.1.8]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA24257 for ; Fri, 8 Jan 1999 05:37:10 -0800 (PST) (envelope-from dholland@cs.toronto.edu) Received: from qew.cs.toronto.edu ([128.100.1.13]) by yonge.cs.toronto.edu with SMTP id <86505-9276>; Fri, 8 Jan 1999 08:36:31 -0500 Received: by qew.cs.toronto.edu id <37768-15540>; Fri, 8 Jan 1999 08:36:15 -0500 Subject: Re: /usr/bin/ftp From: David Holland To: mike@smith.net.au (Mike Smith) Date: Fri, 8 Jan 1999 08:36:11 -0500 Cc: des@flood.ping.uio.no, hackers@FreeBSD.ORG In-Reply-To: <199901080652.WAA00573@dingo.cdrom.com> from "Mike Smith" at Jan 8, 99 01:52:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <99Jan8.083615edt.37768-15540@qew.cs.toronto.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Whaddya say, is ftp(1) due for a revamp? > > Check to make sure that the NetBSD folks haven't already gone down this > path (the last major update was a sync with some of their good work), > and then MHO is that you should wield the knife. Yes. You might want to look at the linux one too (which was cleaned up to some extent by yours truly at one point) but it diverged a long time ago and may be too different for diffing to be worthwhile. -- - David A. Holland | (please continue to send non-list mail to dholland@cs.utoronto.ca | dholland@hcs.harvard.edu. yes, I moved.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 05:47:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25385 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 05:47:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25374 for ; Fri, 8 Jan 1999 05:47:11 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id OAA97248; Fri, 8 Jan 1999 14:46:27 +0100 (CET) (envelope-from des) To: "Ron G. Minnich" Cc: hackers@FreeBSD.ORG Subject: Re: root exceeding maxfiles at 64 files, which should not happen? References: From: Dag-Erling Smorgrav Date: 08 Jan 1999 14:46:26 +0100 In-Reply-To: "Ron G. Minnich"'s message of "Wed, 6 Jan 1999 15:18:45 -0500 (EST)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Ron G. Minnich" writes: > So why would I not be able to open more than 64 sockets? what am I > missing? sorry to put such a stupid question to this list :-=( > I have also bumped the max number of network connections to 1064 ... man login.conf DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 05:53:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA26283 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 05:53:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA26278 for ; Fri, 8 Jan 1999 05:53:32 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id OAA97277; Fri, 8 Jan 1999 14:52:54 +0100 (CET) (envelope-from des) To: "Viren R. Shah" Cc: jim@reptiles.org (Jim Mercer), freebsd-hackers@FreeBSD.ORG Subject: Re: utility for setting PNP info in /etc/rc.conf? References: <199901071854.NAA86615@jabberwock.rstcorp.com> From: Dag-Erling Smorgrav Date: 08 Jan 1999 14:52:53 +0100 In-Reply-To: "Viren R. Shah"'s message of "Thu, 7 Jan 1999 13:54:21 -0500 (EST)" Message-ID: Lines: 32 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Viren R. Shah" writes: > For -current, use the load command in /boot/boot.conf: > > load -t userconfig_script /boot/pnp.config > > The, in /boot/pnp.config have something like: > > USERCONFIG > pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 > quit Foo! /boot/boot.conf should contain: load /kernel load -t userconfig_script /boot/pnp.config autoboot 5 (the last line is optional - who knows, maybe you like having to type "boot" every time) /boot/pnp.config should not contain the "USERCONFIG", and "quit" is superfluous. For FreeBSD-stable, create a /kernel.config file which contains: USERCONFIG pnp 1 1 os enable port0 0x534 port2 0x220 port3 0xe0d irq0 10 drq0 1 drq1 6 quit DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 05:59:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA26785 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 05:59:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA26780 for ; Fri, 8 Jan 1999 05:59:44 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id OAA97288; Fri, 8 Jan 1999 14:59:02 +0100 (CET) (envelope-from des) To: "Daniel C. Sobral" Cc: hackers@FreeBSD.ORG Subject: Re: PR database References: <3695C1B9.ED86E609@newsguy.com> From: Dag-Erling Smorgrav Date: 08 Jan 1999 14:59:01 +0100 In-Reply-To: "Daniel C. Sobral"'s message of "Fri, 08 Jan 1999 17:28:41 +0900" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > Is there anyway to automatically receive messages sent to one > category of the PR database (not being a committer)? echo subscribe freebsd-bugs | sendmail majordomo@freebsd.org DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 08:29:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14992 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 08:29:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles244.castles.com [208.214.165.244]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA14982 for ; Fri, 8 Jan 1999 08:29:02 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id IAA03057; Fri, 8 Jan 1999 08:25:14 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901081625.IAA03057@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav cc: "Viren R. Shah" , jim@reptiles.org (Jim Mercer), freebsd-hackers@FreeBSD.ORG Subject: Re: utility for setting PNP info in /etc/rc.conf? In-reply-to: Your message of "08 Jan 1999 14:52:53 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jan 1999 08:25:13 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Foo! /boot/boot.conf should contain: > > load /kernel > load -t userconfig_script /boot/pnp.config > autoboot 5 > > (the last line is optional - who knows, maybe you like having to type > "boot" every time) Actually, if boot.conf doesn't set $autoboot_delay to NO (it should accept -1 as NO, but it doesn't yet), there is an implicit 'autoboot $autoboot_delay' at the end of the file. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 10:12:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00475 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 10:12:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00465 for ; Fri, 8 Jan 1999 10:12:44 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA25316; Sat, 9 Jan 1999 03:11:51 +0900 (JST) Message-ID: <369647B1.89FCAB87@newsguy.com> Date: Sat, 09 Jan 1999 03:00:17 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Terry Lambert CC: Matthew Dillon , pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable References: <199901080330.UAA06973@usr01.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Because you're just down the road (or I'm just up the road), > and because John Dyson is in town occasionally, we ough to get > together and hash this out over a whiteboard some time when John > is in town, and that will save all of us from wearing our > fingers down to nubs trying to portray 1000 pictures in 1,000,000 > type-written words. Damn it... and we interested lurkers lose all of it! :-( :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 10:13:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00612 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 10:13:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00605 for ; Fri, 8 Jan 1999 10:13:26 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA25310; Sat, 9 Jan 1999 03:11:46 +0900 (JST) Message-ID: <36964682.7CC589E2@newsguy.com> Date: Sat, 09 Jan 1999 02:55:14 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon CC: Alfred Perlstein , Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable References: <199901080320.TAA36935@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Added vm_await() and vm_page_asleep() functions - will be used later. ^^^^^^^^ Is this asynchronous wait? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 10:52:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06835 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 10:52:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06826 for ; Fri, 8 Jan 1999 10:52:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id KAA42951; Fri, 8 Jan 1999 10:51:48 -0800 (PST) (envelope-from dillon) Date: Fri, 8 Jan 1999 10:51:48 -0800 (PST) From: Matthew Dillon Message-Id: <199901081851.KAA42951@apollo.backplane.com> To: "Daniel C. Sobral" Cc: Terry Lambert , pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Terry Lambert wrote: :> :> Because you're just down the road (or I'm just up the road), :> and because John Dyson is in town occasionally, we ough to get :> together and hash this out over a whiteboard some time when John :.. :Damn it... and we interested lurkers lose all of it! :-( :-) : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com Well, I'll be at the BAFUG meeting. Apart from that, I'm full-up next week (and won't even be in california after thursday for a few days). If we miss out at BAFUG we could meet the week after next. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 10:59:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07907 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 10:59:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA07902 for ; Fri, 8 Jan 1999 10:59:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id KAA42987; Fri, 8 Jan 1999 10:59:04 -0800 (PST) (envelope-from dillon) Date: Fri, 8 Jan 1999 10:59:04 -0800 (PST) From: Matthew Dillon Message-Id: <199901081859.KAA42987@apollo.backplane.com> To: "Daniel C. Sobral" Cc: Alfred Perlstein , Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Added vm_await() and vm_page_asleep() functions - will be used later. : ^^^^^^^^ : :Is this asynchronous wait? It's a semi-synchronous wait. It is highly experimental - nothing uses it yet, not even my VM commits after the 15th. Basically asleep()/await() and then a new flag to the memory subsystem (and other subsytems, eventually). asleep() works like tsleep() in that it puts the process on a sleep queue, but it does *NOT* put the process to sleep. It returns immediately. The idea is that some deep-down procedure that would otherwise block can now asleep() and return a temporary error which propogates back up through the call chain, unwinding any locks as it goes. The high level procedure that started the whole mess gets the temporary failure and if it wants to retry the operation it calls await() and then retries. The initial use of the capability is going to be in the VM system to get rid of *all* remaining blocking situations in vm/vm_pageout.c and to clean up vm/vm_fault.c and other VM entities that might block while holding locks ( vm/vm_fault.c must go out of its way right now to release locks when it retries to avoid deadlock situations. It's a mess ). The general use of the capability will be to remove all blocking situations from the deepest subroutines in the kernel - to move them up a procedure call level or two, which will allow us to start to migrate SMP locks deeper into the kernel without having to build brain farts. -Matt :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 11:04:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08728 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 11:04:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA08723 for ; Fri, 8 Jan 1999 11:04:36 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id LAA08749; Fri, 8 Jan 1999 11:02:08 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA15961; Fri, 8 Jan 1999 11:02:00 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id MAA07250; Fri, 8 Jan 1999 12:01:52 -0700 Message-ID: <36965620.AE681203@softweyr.com> Date: Fri, 08 Jan 1999 12:01:52 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon CC: "Daniel C. Sobral" , Terry Lambert , pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable References: <199901081851.KAA42951@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :Terry Lambert wrote: > :> > :> Because you're just down the road (or I'm just up the road), > :> and because John Dyson is in town occasionally, we ough to get > :> together and hash this out over a whiteboard some time when John > > Well, I'll be at the BAFUG meeting. Apart from that, I'm full-up next > week (and won't even be in california after thursday for a few days). > If we miss out at BAFUG we could meet the week after next. Perhaps a "shared whiteboard" application would help? Don't we have one somewhere for FreeBSD? -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 11:11:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09771 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 11:11:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA09759 for ; Fri, 8 Jan 1999 11:11:27 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA12291; Fri, 8 Jan 1999 18:03:11 +0100 From: Luigi Rizzo Message-Id: <199901081703.SAA12291@labinfo.iet.unipi.it> Subject: Re: questions/problems with vm_fault() in Stable To: wes@softweyr.com (Wes Peters) Date: Fri, 8 Jan 1999 18:03:11 +0100 (MET) Cc: dillon@apollo.backplane.com, dcs@newsguy.com, tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <36965620.AE681203@softweyr.com> from "Wes Peters" at Jan 8, 99 12:01:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps a "shared whiteboard" application would help? Don't we have > one somewhere for FreeBSD? mbone/wb -- but there is nothing like audio interaction (mbone/vat !) luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 11:29:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12137 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 11:29:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12130 for ; Fri, 8 Jan 1999 11:29:05 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA07761; Fri, 8 Jan 1999 12:28:20 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd007632; Fri Jan 8 12:28:04 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id MAA22492; Fri, 8 Jan 1999 12:27:58 -0700 (MST) From: Terry Lambert Message-Id: <199901081927.MAA22492@usr09.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 8 Jan 1999 19:27:57 +0000 (GMT) Cc: tlambert@primenet.com, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901080347.TAA37034@apollo.backplane.com> from "Matthew Dillon" at Jan 7, 99 07:47:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The answer is that you need a general purpose cache coherency protocol > that you can count on to propogate throughout the VFS layering. *NOT* > an ad-hoc implemention in one VFS layer and another ad-hoc implementation > in another. What the VFS layer does on its backend -- if implementing > a network protocol such as AFS, NFS, CODA, or something like that, is > up to it. Those protocols may have their own cache coherency protocols > for their network interfaces, but is has very little to do with the > cache coherency protocol that needs to be implemented between VFS > layers. This is what "Choices" from the University of Kentucky does. It supports object inheritance between FS implementations. In one demonstration in 1994, I saw quotas implemented in about 8 minutes. I think that object modelling is going to far. Basically, "If all you have are ``design patterns'', then everything looks like an object". This seems to be an illness in modern CS education, one that came in with VMS and the idea that memory and CPU cycles are free. I'm willing to be convinced the other way, but if the underlying goal is generalized object inheritance, then there's no reason to reinvent it, since examples abound in FS research. I really think that maybe it's time to contact John directly about his design. Have you read the thesis? It's at: ftp://ftp.cs.ucla.edu/pub/ficus/heidemann_thesis.ps.gz This is basically the design document for the VFS stacking architecture document. It'd be nice to identify the design goals you have in addition to the design goals in the architecture document, and for everyone to have an understanding of how the current implementation falls short of the architecture document. FWIW, I'm not happy with the code in FreeBSD either, but I'm unhappy with it from the perspective that it falls far short of the intended design for no good reason, not dissatisfaction with the design itself. I think that's a rather important distinction. > :(2) MNFS manages distribute cache coherency across a network > : within the context of the existing framework. > > MNFS is an externalized protocol, just as CODA and standard NFS > are. What they implement in their network layer is very different > from what they have to deal with in their VFS layer. > > For example, lets say you export a UFS filesystem via MNFS. Ok, fine... > now lets say you import an MNFS filesystem and then re-export it to > another machine, and that machine imports it and then re-export > it to yet another machine. Will cache coherency be maintained across > the chain with MNFS? Without a general cache-coherency protocol for > inter-layer VFS it can't unless MNFS short-circuits the protocol. This is a long standing argument. Basically, this is the argument between hosted FS's, or more generally, hosted OS's, vs. native applications competing with the hosting software. This is the Linux argument about user space NFS services or the SAMBA argument about user space CIFS services or the NetWare argument about user space NCP services. It's also about the argument about whether I should be able to reexport something that I import, or should the final client be "forced" to do its import from the original source, and avoid the coherency problem entirely. The general NFS answer (except on Linux) is to force the client to go to the original source. The general NetWare answer is to allow only local FS's to be exported. The general SAMBA answer is to allow the export, with the caveat that the coherency battle has already been lost because the OS's hosting the server don't export an opportunity locking mechanism (on 4.4BSD, this could be implemented by externalizing the VOP_LEASE mechanism to user space), nor do most host environments support mandatory locking. I think the biggest problem here is mandatory locking, and that's not addressed. > Fine, so now mix protocols... you have a combination of MNFS, AFS, and > CODA mounts done in a chain. Lets say each one of these has cache > coherency. Will the coherency be maintained across the chain? Nope, > it won't. Not unless the VFS layer implements a general cache > coherency protocol that these filesystems use. My answer would be "don't do this". You already have a problem in the SAMBA and AFS server cases that's unresolvable: how do I ensure that the semantics of my server (e.g., mandatory file range locks) are observed by other programs running in the hosting environment? The answer is "I can't". There are some things you just can't do if you allow user space programs access to the network at all, and assert all of the preconditions that have been asserted. If I provide a cooperating layer in the kernel for mandatory lock enforcement of file region access (for example), then in order for it to be effective, I *can't* (not "shouldn't") expose the layers stacked underneath it, and expect to be able to interoperate my client machine's applications with local applications in the host environment that aren't the server itself. > The real power of building a cache coherency protocol into the VFS > layering is that it allows you to do things you may not have thought of > yet. I agree. My preference for such a protocol, however, would be to not limit it to only cached VM information. One could consider the soft updates mechanism as a cache coherency protocol that is more general. When an FS is instanced, you would instantiate a dependency graph for the VFS layer, thinking of the VFS in terms of events. The nodes on the graph are inter-object dependency resolution functions. You can see the existing soft updates framework fitting in as a small subset of this mechanism. But this mechanism would be able to resolve dependencies between stacking layers as well, by specifying inter-VOP dependency relationships, and conflict resolver code for that. Consider: Say I want to implement a stacking layer that supports transactioning. How do I do this without engaging in a two stage object/index commit protocol, using VOP's, which destroys the actual utility of having Soft Updates in the underlying FS on which the transactiong layer is stacked? The only way I can do this reasonably (since otherwise transaction updates must be ordered, and the only ordering that operates between VFS layers is synchronous VOP completion) is to implement a hook mechanism whereby the dependency graph can be dynamically extended, and conflicts between adjacent edges (each describing an ordering dependency) have conflict resolution handler code provided. *This* is a general cache coherency mechanism, without tying the idea of a cached object abritraily to merely "VM". The only problem with this is... any group of 2 to 4 people looking for a PhD? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 11:45:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14455 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 11:45:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pacman.redwoodsoft.com (redwoodsoft.com [207.181.199.182]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA14438 for ; Fri, 8 Jan 1999 11:45:56 -0800 (PST) (envelope-from dnelson@pacman.redwoodsoft.com) Received: (qmail 8483 invoked by uid 1000); 8 Jan 1999 19:45:25 -0000 Date: Fri, 8 Jan 1999 11:45:25 -0800 (PST) From: Dru Nelson To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Source address In-Reply-To: <199901070055.RAA02738@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > For a complete soloution, you'd want to be able to bind a socket > > > to all interfaces, a specific interface, an IP address regardless of > > > interfaces that have that address, and an interface/IP address pair. I would really like to see somehting like this as well. For example, I would like INADDR_ANY to bind to a particular interface/ip address (say on a net 10.x.x.x). Then Apache or other services could bind to specific addresses (the outside world). This would make security a little easier without having to turn on ipfw or modify a lot of standard applications to do specific binding. Dru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 12:01:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16838 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 12:01:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16827 for ; Fri, 8 Jan 1999 12:01:06 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id NAA11450; Fri, 8 Jan 1999 13:00:31 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd011304; Fri Jan 8 13:00:11 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA23516; Fri, 8 Jan 1999 13:00:04 -0700 (MST) From: Terry Lambert Message-Id: <199901082000.NAA23516@usr09.primenet.com> Subject: Re: questions/problems with vm_fault() in Stable To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 8 Jan 1999 20:00:04 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199901080355.TAA05878@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jan 7, 99 07:55:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What if there is more than one underlying filesystem? > > mount a FFS filesystem on /a > mount an NFS filesystem on /a/b > NULLFS mount /a on /n > > For a VOP not defined for NULLFS, you want to use the FFS VOP for > /n/c and the NFS VOP for /n/a/b/c Mountpoint traversal isn't really a problem. The bigger problem is with multiplexing (like union) and de-muxing (like a nullfs exposure of a subdir). I think these layers are synchronization points. > } What does this mean for a stack of 500 NULLFS instances? > } > } What it means is that for most VOPs (all VOPs, if the VFS architecture > } wasn't currently screwed up by null_bypass and some ill-considered > } direct references to NULLVPTOLOWERVP), the VOP's inhereit from the > } bottom-most VFS! > } > } It *also* means that the overhead in figuring this out occurs at > } the time the VFS is instanced, *not* at runtime. > > What happens if /a/b is mounted after /a is mounted on /n? Mount point traversal is applied before semantic layer traversal. A layer stacked on something that have a covered vnode applies to the covering vnode. Consider a stacking layer that puts an "x" in front of every file name. If you mount: mount FFS on /a mount NFS on /a/b "xing-FS" mount /a on /n and each of the first two FS's has a file named "fred" in it, then you see: /a/fred /a/b/fred /n/xfred /n/b/xfred (/or /n/xb/xfred, if directories are files 8-)) If, instead, you mount: mount FFS on /a "xing-FS" mount /a on /n mount NFS on /n/b then you see: /a/fred no /a/b/fred /n/xfred /n/b/fred Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 12:52:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23445 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 12:52:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA23437 for ; Fri, 8 Jan 1999 12:52:07 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id PAA13189 for ; Fri, 8 Jan 1999 15:51:32 -0500 (EST) Date: Fri, 8 Jan 1999 15:51:32 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 To: hackers Subject: ATM documentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, is there any documentation of developing ATM drivers on FreeBSD? Thanks for any help. -------------------------------------------------- | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | | Dept. of Computer Science, SUNY at Binghamton | -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 14:18:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03353 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 14:18:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from abyssinian.sleepycat.com (sleepycat.com [199.103.241.218]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA03347 for ; Fri, 8 Jan 1999 14:18:51 -0800 (PST) (envelope-from db@abyssinian.sleepycat.com) Received: (from db@localhost) by abyssinian.sleepycat.com (8.8.8/8.8.8) id RAA29040; Fri, 8 Jan 1999 17:18:19 -0500 (EST) Date: Fri, 8 Jan 1999 17:18:19 -0500 (EST) From: Sleepycat Software Message-Id: <199901082218.RAA29040@abyssinian.sleepycat.com> To: jb@cimlogic.com.au Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 Cc: freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org, yusufg@huge.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sleepycat Software wrote: >>> cc -c -O -I. -I../dist/../include -D_THREAD_SAFE ../dist/../clib/getlong.c >>> cc -o db_dump185 db_dump185.o err.o getlong.o -lc_r >>> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. >> >> This is not a Berkeley DB error. Berkeley DB does not use gets(). > > Not commenting on the gets() warning, but the link line above links > db_dump185 against libc_r _and_ libc which is most certainly not what is > intended. If the application is threaded, pass `-pthread' to gcc and > it will link against libc_r /instead/ of libc. We were told that, for thread-safe programs under FreeBSD, we should add -D_THREAD_SAFE to the C pre-processor flags, and load against -lc_r. Is that not correct? Is there a preferred method of guaranteeing thread safety within the Berkeley DB library? Regards, Amy Adams =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Amy Adams Berkeley DB Product Manager Sleepycat Software Inc. db@sleepycat.com 394 E. Riding Dr. +1-617-633-2429 Carlisle, MA 01741 http://www.sleepycat.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 14:27:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04312 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 14:27:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04303 for ; Fri, 8 Jan 1999 14:27:06 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id JAA00644; Sat, 9 Jan 1999 09:29:09 +1100 (EST) (envelope-from jb) From: John Birrell Message-Id: <199901082229.JAA00644@cimlogic.com.au> Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 In-Reply-To: <199901082218.RAA29040@abyssinian.sleepycat.com> from Sleepycat Software at "Jan 8, 1999 5:18:19 pm" To: db@abyssinian.sleepycat.com (Sleepycat Software) Date: Sat, 9 Jan 1999 09:29:09 +1100 (EST) Cc: jb@cimlogic.com.au, freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org, yusufg@huge.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sleepycat Software wrote: > We were told that, for thread-safe programs under FreeBSD, > we should add -D_THREAD_SAFE to the C pre-processor flags, > and load against -lc_r. Is that not correct? Linking against both libc and libc_r will cause strange results. Using gcc -pthread is the correct way. > Is there a > preferred method of guaranteeing thread safety within the > Berkeley DB library? Other than compiling with -D_THREAD_SAFE on FreeBSD, normal thread safety rules apply. Don't use global variables. Make all functions re-entrant. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 14:31:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05108 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 14:31:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05096 for ; Fri, 8 Jan 1999 14:31:47 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.8.8/8.8.8) id VAA08985; Fri, 8 Jan 1999 21:12:04 GMT (envelope-from nik) Date: Fri, 8 Jan 1999 21:12:04 +0000 From: Nik Clayton To: Terry Lambert Cc: Matthew Dillon , pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <19990108211204.A1820@catkin.nothing-going-on.org> References: <199901080253.SAA36703@apollo.backplane.com> <199901080330.UAA06973@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901080330.UAA06973@usr01.primenet.com>; from Terry Lambert on Fri, Jan 08, 1999 at 03:30:49AM +0000 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 08, 1999 at 03:30:49AM +0000, Terry Lambert wrote: > Because you're just down the road (or I'm just up the road), > and because John Dyson is in town occasionally, we ough to get > together and hash this out over a whiteboard some time when John > is in town, and that will save all of us from wearing our > fingers down to nubs trying to portray 1000 pictures in 1,000,000 > type-written words. > > Anyone else who's interested in hammering things out should feel > free too. Someone, please take a video camera! And then QuickTime it our something. I always learn a lot from these threads. I'm never sure exactly what it is I'm learning, but I learn a lot of it. N -- subterra superque womblia liber To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 14:34:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05328 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 14:34:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from abyssinian.sleepycat.com (sleepycat.com [199.103.241.218]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05321 for ; Fri, 8 Jan 1999 14:34:44 -0800 (PST) (envelope-from db@abyssinian.sleepycat.com) Received: (from db@localhost) by abyssinian.sleepycat.com (8.8.8/8.8.8) id RAA29270; Fri, 8 Jan 1999 17:34:09 -0500 (EST) Date: Fri, 8 Jan 1999 17:34:09 -0500 (EST) From: Sleepycat Software Message-Id: <199901082234.RAA29270@abyssinian.sleepycat.com> To: jb@cimlogic.com.au Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 Cc: freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org, yusufg@huge.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sleepycat Software wrote: >> We were told that, for thread-safe programs under FreeBSD, >> we should add -D_THREAD_SAFE to the C pre-processor flags, >> and load against -lc_r. Is that not correct? > > Linking against both libc and libc_r will cause strange results. > Using gcc -pthread is the correct way. Thank you! This will be fixed in our next release. Regards, Amy Adams =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Amy Adams Berkeley DB Product Manager Sleepycat Software Inc. db@sleepycat.com 394 E. Riding Dr. +1-617-633-2429 Carlisle, MA 01741 http://www.sleepycat.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 15:18:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA09659 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 15:18:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09654 for ; Fri, 8 Jan 1999 15:18:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA21727; Fri, 8 Jan 1999 16:17:44 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd021543; Fri Jan 8 16:17:30 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA19479; Fri, 8 Jan 1999 16:17:16 -0700 (MST) From: Terry Lambert Message-Id: <199901082317.QAA19479@usr05.primenet.com> Subject: Re: pthreads question/problem... To: dot@dotat.at (Tony Finch) Date: Fri, 8 Jan 1999 23:17:15 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <13973.60376.9845.729115@chiark.greenend.org.uk> from "Tony Finch" at Jan 8, 99 11:28:24 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Sometimes you want M to be large relative to the number of CPUs > > > because you are using threading to improve userland IO concurrency. > > > > Finish the thought: > > > > "...and you don't want to use async I/O to improve I/O > > concurrency because, while doing so would be less overhead > > than using a bunch of threads, it doesn't accomplish > > your *real* goal." > > The other reason for not using aio is because the aio calls do not > cover the whole range of system calls that block (open, close, stat, > unlink, etc...). I don't see how you can fix that without either using > some sort of fork or adding stuff to the API. Actually, that's the reason for implementing the POSIX AIO calls as library entry points that make use of async call gates, instead of jamming the things into the poor kernel's overstuffed bowels... the POSIX AIO interface only applies to a subset of calls, and thus is pretty frigging useless. The whole migration to kernel threads has been ill-thought out. From what I can tell so far, the reasoning is so that we can use a precompiled version of glibc.so that makes Linux system calls, instead of compiling our own version of glibc.so that Linux programs use, and which has entry points for the Linux system calls that wrap what are actually FreeBSD system calls instead. The disadvantage of this, of course, is that you need less Linux emulator code in the kernel... (that was me being facaetious). This is a general case of kernel bloat. There's really no topological difference between call conversion threads that can be signal preempted by a user space scheduler, and Linux kernel threads that are preempted by the kernel scheduler. The only real difference is SMP scalability (which isn't resolved in the least by Linux kernel threaded applications that have any technical reason to be implemented as threaded instead of as seperate processes), and that requires user space cooperation and a lot of scheduler work unrelated to Linux kernel threads. Put another way, changing the saving the registers and changing the stack and the program counter is the same whether it occur in user or kernel space; why people make such a big deal about where this happens is really beyond me; it has to be related to their misunderstanding of rfunctional decomposition a part of the problem solving process.... It seems to me that this is nothing more than additional kernel bloat whose sole purpose is to enable FreeBSD to run Linux code that depends on static linking or unrecompiled Linux shared libraries, which is of dubious value at best. >From that perspective, it would be a hell of a lot more valuable to do Solaris kernel threads emulation, and get 1000 times as many applications (including a JAVA, a JDK, an a SWING and AWT implementation that doesn't require paying Sun $500,000 (or whatever) to actually use in real life). You could also approach Solaris the same way: provide a FreeBSD system call calling version of a libc.so that looks like Solaris binaries expect it to look. The additional advantage of this is that you would no longer need a Solaris license to run Solaris binaries on FreeBSD (which is a good reason to install Solaris instead of FreeBSD,since you're paying for Solaris anyway). Even better would be to replace the FreeBSD manifest constants, as necessary, to bring the FreeBSD ABI into line with the Solaris ABI, so that code will "just run". The only real remaining question is whether I namelist and document the Solaris libraries, and someone else implements them, or vice versa (I'd prefer vice versa, since then "someone else" can be in Germany and thus beyond any legal reproach, and implementation could use help and scales to more people more easily...). The manifest constants in the headers are, of course, published, regardless of what the license claims, at least for anyone in the jurisdiction of the US 5th circuit court of appeals. Since that doesn't stop them from suing, it would be nice if a German could look at documenting them, too. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 15:22:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10654 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 15:22:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10649 for ; Fri, 8 Jan 1999 15:22:54 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA06419; Fri, 8 Jan 1999 16:22:03 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd006366; Fri Jan 8 16:21:53 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA19744; Fri, 8 Jan 1999 16:21:36 -0700 (MST) From: Terry Lambert Message-Id: <199901082321.QAA19744@usr05.primenet.com> Subject: Re: Strange warnings when compiling Berkeley DB on FreeBSD 3.0 To: jb@cimlogic.com.au (John Birrell) Date: Fri, 8 Jan 1999 23:21:35 +0000 (GMT) Cc: db@abyssinian.sleepycat.com, jb@cimlogic.com.au, freebsd-hackers@FreeBSD.ORG, openldap-devel@openldap.org, yusufg@huge.net In-Reply-To: <199901082229.JAA00644@cimlogic.com.au> from "John Birrell" at Jan 9, 99 09:29:09 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Linking against both libc and libc_r will cause strange results. > Using gcc -pthread is the correct way. Why? Is libc weak symbol support broken, or is libc_r incomplete? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 18:04:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA26514 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 18:04:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26509 for ; Fri, 8 Jan 1999 18:04:35 -0800 (PST) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id SAA26065 for ; Fri, 8 Jan 1999 18:04:05 -0800 (PST) Date: Fri, 8 Jan 1999 18:04:05 -0800 (PST) From: Ian Kallen To: freebsd-hackers@FreeBSD.ORG Subject: login classes & resource limits under cron Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On a 2.2.7 system... I'm consuming a bunch of resources on this machine, root's cronjobs are unaffected but mine are unable to fork. So I thought a quick fix would be to specify the root class for myself in master.passwd, so I vipw'd and modified my record accordingly but to no effect. I've read the man page for login.conf, I just don't see this adequately explained. How does cron read the resource limits from login.conf? FWIW, I tried modifying the default class too but to no avail. Is it because this of the limits that were in effect when I started this big honking resource consuming job? I'd thought that if I specify a different class or upped the limits in the default class, I'd "re-allocate" more resource availability to my user id. Hmmm... puzzled, -Ian -- Ian Kallen ICQ: 17073910 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 8 19:55:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA07844 for freebsd-hackers-outgoing; Fri, 8 Jan 1999 19:55:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA07839 for ; Fri, 8 Jan 1999 19:55:37 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id TAA01720; Fri, 8 Jan 1999 19:54:43 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id TAA11231; Fri, 8 Jan 1999 19:54:42 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA08830; Fri, 8 Jan 1999 19:54:41 -0800 (PST) From: Don Lewis Message-Id: <199901090354.TAA08830@salsa.gv.tsc.tdk.com> Date: Fri, 8 Jan 1999 19:54:41 -0800 In-Reply-To: Terry Lambert "Re: questions/problems with vm_fault() in Stable" (Jan 8, 7:27pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: questions/problems with vm_fault() in Stable Cc: pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 8, 7:27pm, Terry Lambert wrote: } Subject: Re: questions/problems with vm_fault() in Stable } I really think that maybe it's time to contact John directly about } his design. Have you read the thesis? It's at: } } ftp://ftp.cs.ucla.edu/pub/ficus/heidemann_thesis.ps.gz } } This is basically the design document for the VFS stacking } architecture document. He's also got a newer document online: ftp://ftp.cs.ucla.edu/tech-report/95-reports/950032.2.ps.Z To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 09:22:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18840 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 09:22:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mtu.ru (ns.mtu.ru [195.34.32.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18816; Sat, 9 Jan 1999 09:22:05 -0800 (PST) (envelope-from daktaklakpak@mtu-net.ru) Received: from dan (dial51251.mtu-net.ru [195.34.51.251]) by ns.mtu.ru (8.9.1/8.8.8) with SMTP id UAA17651; Sat, 9 Jan 1999 20:24:47 +0300 (MSK) Message-ID: <01e301be3bf4$19fa0fb0$0100a8c0@dan.space_net> From: "Dan Shebunin" To: Cc: Subject: Problems with IDE CD-ROM under FreeBSD Date: Sat, 9 Jan 1999 20:01:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! And excuse me about my poor English. Here is my problem: I have IDE CD installed as master on secondary IDE controller. Sys messages during system boot phase: ------ wdc1: unit 0 (atapi): , removable, intr, iordy atapi1.0: unknown phase ------ After logging in, I try to mount CD: #mount /cdrom cd9660: /dev/wcd0c: Invalid argument or #mount_cd9660 /dev/wdc0c /cdrom cd9660: /dev/wcd0c: Invalid argument e.t.c... The worse is SYSINSTALL can mount my CD, and even read packages from it. So, why can't I use mount? P.S. /etc/fstab is ok. (it never changed after install) P.P.S. /dev/wcd0c exists (and sysinstal mount to it perfectly) P.P.P.S. The disc is in drive and ready to go :) Have a nice CONNECT! Dan. (daktaklakpak@public.mtu.ru) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 09:22:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18862 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 09:22:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mtu.ru (ns.mtu.ru [195.34.32.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18819; Sat, 9 Jan 1999 09:22:06 -0800 (PST) (envelope-from daktaklakpak@mtu-net.ru) Received: from dan (dial51251.mtu-net.ru [195.34.51.251]) by ns.mtu.ru (8.9.1/8.8.8) with SMTP id UAA17655; Sat, 9 Jan 1999 20:24:49 +0300 (MSK) Message-ID: <01e401be3bf4$1ae88e60$0100a8c0@dan.space_net> From: "Dan Shebunin" To: Cc: Subject: Problems with DEC PCI Ethernet undef FreeBSD Date: Sat, 9 Jan 1999 20:17:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! And excuse me about my poor English. Description: I have DEC PCI Ethernet card installed in my computer. During system boot phase this card is deteced by de0 device driver. But after loggin' in I can't use PING, TRACEROUTE, e.t.c. TCPDUMP writes otuput only for PING 192.168.0.0 (my net is 192.168.0.0), for any other PING's, TCPDUMP is silent. I have noticed, that card act so badly, if it has OACTIVE flag set ([...] means 'skipped'): #ifconfig de0 flags=[...]<[...],OACTIVE,[...]> After booting Win95 on the same computer (it's dual boot system FreeBSD<->Win95) and rebooting it (soft reboot), the flag OACTIVE disappears and all PINGs etc work just fine! So, how can I initialize my network card in FreeBSD, or should I use Win95 as a big ugly "card reset program" for this purpose? Have a nice CONNECT! Dan. (daktaklakpak@public.mtu.ru) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 10:24:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24181 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 10:24:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ozz.etrust.ru ([195.2.84.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA24161; Sat, 9 Jan 1999 10:24:05 -0800 (PST) (envelope-from osa@etrust.ru) Received: from localhost (localhost [127.0.0.1]) by ozz.etrust.ru (8.9.1/8.9.1) with ESMTP id VAA17009; Sat, 9 Jan 1999 21:22:02 +0300 (MSK) (envelope-from osa@etrust.ru) Date: Sat, 9 Jan 1999 21:22:01 +0300 (MSK) From: oZZ!!! To: Dan Shebunin cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Problems with IDE CD-ROM under FreeBSD In-Reply-To: <01e301be3bf4$19fa0fb0$0100a8c0@dan.space_net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 9 Jan 1999, Dan Shebunin wrote: > Hi! And excuse me about my poor English. > > Here is my problem: > I have IDE CD installed as master on secondary IDE controller. > Sys messages during system boot phase: > ------ > wdc1: unit 0 (atapi): , removable, intr, iordy > atapi1.0: unknown phase > ------ > > After logging in, I try to mount CD: > #mount /cdrom > cd9660: /dev/wcd0c: Invalid argument > > or > > #mount_cd9660 /dev/wdc0c /cdrom > cd9660: /dev/wcd0c: Invalid argument > e.t.c... > > The worse is SYSINSTALL can mount my CD, and even read packages from it. > So, why can't I use mount? > > P.S. /etc/fstab is ok. (it never changed after install) > P.P.S. /dev/wcd0c exists (and sysinstal mount to it perfectly) > P.P.P.S. The disc is in drive and ready to go :) > If your version of FreeBSD is 3.0-current -> use acd.. See /sys/i386/LINT for more info. > > Have a nice CONNECT! > Dan. (daktaklakpak@public.mtu.ru) > Rgdz, Sergey A. Osokin aka oZZ, osa@etrust.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 10:32:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24951 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 10:32:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pop02.globecomm.net (pop02.globecomm.net [206.253.129.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA24934; Sat, 9 Jan 1999 10:32:19 -0800 (PST) (envelope-from skjellyfetti@iname.com) Received: from iname.com (dialup-tc-3-2.minn.net [208.16.84.198]) by pop02.globecomm.net (8.9.0/8.8.0) with ESMTP id NAA13437; Sat, 9 Jan 1999 13:32:07 -0500 (EST) Message-ID: <36979FAF.CA88A529@iname.com> Date: Sat, 09 Jan 1999 12:28:00 -0600 From: Mark Kobussen X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Dan Shebunin CC: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Problems with IDE CD-ROM under FreeBSD References: <01e301be3bf4$19fa0fb0$0100a8c0@dan.space_net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi! And excuse me about my poor English. Don't worry about it. =) Nothing wrong with learning another language! > Here is my problem: > I have IDE CD installed as master on secondary IDE controller. > Sys messages during system boot phase: > ------ > wdc1: unit 0 (atapi): , removable, intr, iordy > atapi1.0: unknown phase > ------ I'm just a newbie - so it's a possibility that I could be horrendously wrong. But to try: #mount_cd9660 /dev/wdc1 /cdrom Notice the sys message during boot: wdc1. Looks like you're trying to mount the CD drive on the primary IDE controller. There is probably a way to fix it so that it recognizes wdc1 by using #mount /cdrom, but the only way I can think of is by adding an alias. Oh, and don't worry about the unknown phase message. My CD-ROM reports that at boot-up as well, although I have no problems mounting it using #mount /cdrom. It's also an IDE drive, except mounted on the primary EIDE controller as a slave. -- Mark Kobussen IS - Honeywell, SGP Division mkobusse@sgp.honeywell.com skjellyfetti@iname.com ICQ#11860734 /* '94 Mitsubishi Eclipse NT 1.8L */ /* Fender Stratocaster: Tex-Mex, 3-Tone Sunburst */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 13:33:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17446 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 13:33:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17405 for ; Sat, 9 Jan 1999 13:32:55 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id WAA09180; Sat, 9 Jan 1999 22:37:35 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Sat, 9 Jan 1999 22:37:35 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Nik Clayton cc: Terry Lambert , Matthew Dillon , pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable In-Reply-To: <19990108211204.A1820@catkin.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, Nik Clayton wrote: > > Anyone else who's interested in hammering things out should feel > > free too. > > Someone, please take a video camera! And then QuickTime it our something. > > I always learn a lot from these threads. I'm never sure exactly what it > is I'm learning, but I learn a lot of it. ROTFL! Yes, I have exactly the same feeling :-)) Anyway, even though I don't understand all of it, it's useful to follow the discussion - maybe some time later I'll make something out of it... Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 13:34:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18004 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 13:34:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17835 for ; Sat, 9 Jan 1999 13:33:41 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id WAA09184; Sat, 9 Jan 1999 22:39:09 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Sat, 9 Jan 1999 22:39:09 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: zhihuizhang cc: hackers Subject: Re: ATM documentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 8 Jan 1999, zhihuizhang wrote: > > Hi, is there any documentation of developing ATM drivers on FreeBSD? I think there were some docs at Chuck Cranor's web site. You can also look at the exisiting drivers (natm and netatm) in the tree. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 15:05:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25736 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 15:05:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from link.cpt.nsc.iafrica.com (link.cpt.nsc.iafrica.com [196.31.1.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25727 for ; Sat, 9 Jan 1999 15:05:43 -0800 (PST) (envelope-from khetan@link.freebsd.os.org.za) To: (original recipient in envelope at link.cpt.nsc.iafrica.com) X-Disclaimer: Contents of this e-mail are the writer's opinion X-Disclaimer2: and may not be quoted, re-produced or forwarded X-Disclaimer3: (in part or whole) without the author's permission. Received: from localhost (khetan@localhost) by link.cpt.nsc.iafrica.com (8.9.1+3.1W/8.9.1a/smtpfeed 0.83) with SMTP id BAA27178 for ; Sun, 10 Jan 1999 01:05:04 +0200 (SAT) (envelope-from khetan@link.freebsd.os.org.za) Date: Sun, 10 Jan 1999 01:05:00 +0200 (SAT) From: Khetan Gajjar X-Sender: khetan@link.cpt.nsc.iafrica.com Reply-To: Khetan Gajjar To: hackers@FreeBSD.ORG Subject: ftp.gulf.net not accepting anonymous connections ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. >From my latest -current sources, I see that /usr/src/etc/mail/Makefile still refers to fetching ips.txt and domains.txt from ftp.gulf.net gulf.net's ftp server doesn't accept anonymous connections; [chain] ~# ftp ftp.gulf.net Connected to kingfish.neworleans.gulf.net. 220 kingfish.neworleans.gulf.net FTP server (Version wu-2.4(1) Fri Jan 17 12:05: 30 MST 1997) ready. Name (ftp.gulf.net:root): ftp 530 User ftp unknown. ftp: Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> user (username) anonymous 530 User anonymous unknown. Login failed. ftp> quit 221 Goodbye. [chain] ~# For at least the last two months now, their ftp server doesn't accept anonymous connections. I tried phoning them to ask if they had a alternative site/location, but just got some dumb comptuer-controlled voice. Seeing that I was paying International rates, I hung up after three minutes of not getting any nearer to a human. --- Khetan Gajjar (!kg1779) * khetan@iafrica.com ; khetan@os.org.za http://www.os.org.za/~khetan * Talk/Finger khetan@chain.freebsd.os.org.za FreeBSD enthusiast * http://www2.za.freebsd.org/ Security-wise, NT is a OS with a "kick me" sign taped to it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 15:12:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26341 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 15:12:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from link.cpt.nsc.iafrica.com (link.cpt.nsc.iafrica.com [196.31.1.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26271 for ; Sat, 9 Jan 1999 15:11:13 -0800 (PST) (envelope-from khetan@link.freebsd.os.org.za) To: (original recipient in envelope at link.cpt.nsc.iafrica.com) X-Disclaimer: Contents of this e-mail are the writer's opinion X-Disclaimer2: and may not be quoted, re-produced or forwarded X-Disclaimer3: (in part or whole) without the author's permission. Received: from localhost (khetan@localhost) by link.cpt.nsc.iafrica.com (8.9.1+3.1W/8.9.1a/smtpfeed 0.83) with SMTP id BAA27246; Sun, 10 Jan 1999 01:10:28 +0200 (SAT) (envelope-from khetan@link.freebsd.os.org.za) Date: Sun, 10 Jan 1999 01:10:25 +0200 (SAT) From: Khetan Gajjar X-Sender: khetan@link.cpt.nsc.iafrica.com Reply-To: Khetan Gajjar To: Nathan Dorfman cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG, "John W. DeBoskey" Subject: Re: cdrecord / projected & actual sizes don't seem right In-Reply-To: <19990105202736.B16219@rtfm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 5 Jan 1999, Nathan Dorfman wrote: >Al, as for your error, I've been using RW media with cdrecord, -current, >and the CDRW4260 ever since I got it. What's the problem you're having? >Maybe you're forgetting that a) you need to blank CDRW media before recording >onto it, cdrecord blank=all or b) the drive writes RW media at 2x, so set >speed=2. I'd also advise updating the firmware on your drive : at scbus0 target 6 lun 0 (pass2,cd0) Other than that, I've done nothing special, and it all works perfectly on a two month old -current writing at both 2x and 1x. --- Khetan Gajjar (!kg1779) * khetan@iafrica.com ; khetan@os.org.za http://www.os.org.za/~khetan * Talk/Finger khetan@chain.freebsd.os.org.za FreeBSD enthusiast * http://www2.za.freebsd.org/ Security-wise, NT is a OS with a "kick me" sign taped to it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 15:20:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26886 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 15:20:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from liberty.bulinfo.net (liberty.bulinfo.net [195.10.36.71]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA26878 for ; Sat, 9 Jan 1999 15:20:20 -0800 (PST) (envelope-from ian@bulinfo.net) Received: (qmail 67166 invoked from network); 9 Jan 1999 23:19:37 -0000 Received: from gate.bulinfo.net (195.10.36.66) by liberty.bulinfo.net with SMTP; 9 Jan 1999 23:19:37 -0000 Received: (qmail 8034 invoked from network); 9 Jan 1999 23:19:33 -0000 Received: from ppp1.bulinfo.net (HELO cserv.oksys.bg) (195.10.36.98) by gate.bulinfo.net with SMTP; 9 Jan 1999 23:19:33 -0000 Received: from bulinfo.net (cserv.oksys.bg [192.72.180.21]) by cserv.oksys.bg (8.8.8/8.8.8) with ESMTP id BAA08371; Sun, 10 Jan 1999 01:19:33 +0200 (EET) (envelope-from ian@bulinfo.net) Message-ID: <3697E405.5AE2DCE5@bulinfo.net> Date: Sun, 10 Jan 1999 01:19:33 +0200 From: Iani Brankov Organization: ok systems X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-STABLE i386) X-Accept-Language: bg, en MIME-Version: 1.0 To: Dan Shebunin CC: freebsd-hackers Subject: Re: Problems with IDE CD-ROM under FreeBSD References: <01e301be3bf4$19fa0fb0$0100a8c0@dan.space_net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Shebunin wrote: > > After logging in, I try to mount CD: > #mount /cdrom > cd9660: /dev/wcd0c: Invalid argument > > or > > #mount_cd9660 /dev/wdc0c /cdrom > cd9660: /dev/wcd0c: Invalid argument > e.t.c... It seems you don't have iso9660 FS in the kernel or as lkm. check for option "CD9660" in your current kernel configuretion file. By the way Mark makes a mistake: wdc != wcd at all. > > The worse is SYSINSTALL can mount my CD, and even read packages from it. > So, why can't I use mount? > If the reason is absence of cdrom fs emulation, yes - it's possible. good luck :) -- When the people talk about troubles, the word Microsoft is the most frequently used one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 16:30:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05266 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 16:30:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05250 for ; Sat, 9 Jan 1999 16:30:54 -0800 (PST) (envelope-from dmlb@ragnet.demon.co.uk) Received: from [158.152.46.40] (helo=ragnet.demon.co.uk) by post.mail.demon.net with smtp (Exim 2.10 #2) id 0zz8lp-00044n-00 for freebsd-hackers@freebsd.org; Sun, 10 Jan 1999 00:30:21 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 1.82 #1) id 0zz5uo-0000pj-00; Sat, 9 Jan 1999 21:27:26 +0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 09 Jan 1999 21:27:26 -0000 (GMT) From: Duncan Barclay To: freebsd-hackers@FreeBSD.ORG Subject: FICL and setting BTX variables Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I've been playing with the new boot blocks and I am trying to extend the example menu code so that I can boot different kernels from different drives. However, I can't work out what the voodoo is to set BTX (I think) variables from with ficl. I need to set curdev based upon which drive I want to boot from, the example code below falls over. /usr/share/examples/.../menu.4th ... dup 49 = if drop 1 25 at-xy cr ." Loading 2.2.6 kernel. Please wait..." cr set num_ide_disks=1 set curdev=disk2s1a: boot then I tried a few of the obvious things like s" disk2s1a constant curdev but it doesn't work. Once I get it working I'll submit my menu's as another example. Thanks Duncan PS. FWIW /boot/loader seems to load my 2.2.6 kernels fine. --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 20:23:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25635 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 20:23:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25630 for ; Sat, 9 Jan 1999 20:23:19 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA04142; Sun, 10 Jan 1999 13:22:33 +0900 (JST) Message-ID: <36982AA2.3F0FBE1B@newsguy.com> Date: Sun, 10 Jan 1999 13:20:50 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Duncan Barclay CC: freebsd-hackers@FreeBSD.ORG Subject: Re: FICL and setting BTX variables References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Duncan Barclay wrote: > > However, I can't work out what the voodoo is to set BTX (I think) variables > from with ficl. I need to set curdev based upon which drive I want to boot > from, the example code below falls over. > > /usr/share/examples/.../menu.4th ... > dup 49 = if > drop > 1 25 at-xy cr > ." Loading 2.2.6 kernel. Please wait..." cr > set num_ide_disks=1 > set curdev=disk2s1a: > boot > then > > I tried a few of the obvious things like > s" disk2s1a constant curdev > but it doesn't work. > > Once I get it working I'll submit my menu's as another example. Thanks This is being worked on. Well, it would be being worked on if I had got a single second opinion on how to proceed, but... Right now you can get around the problem in a somewhat clumsy way. We intend to let you do it in a non-clumsy way, we just haven't decided what way would that be. For now, you can do the following: s" set num_ide_disks=1" evaluate drop s" set currdev=disk2s1a:" evaluate drop s" boot" evaluate drop Better yet, though would be: s" load ${kernelname}" evaluate if s" boot" evaluate abort else ... Notes: * Right now, all builtins return 1 if no error happened, 0 otherwise (btw, Jordan, ANS specifies all bits 1 as the "true" value :). It is my intention to change this behavior. In fact, I have already submitted the patches. If I have it my way, errors will use THROW instead. * Right now, you can't set a variable to the name of another variable. For instance, the default value of prompt is "${currdev}". Well, you'll find there is no way to set it to that value. There is no escape character in the parser, and \ are silently removed with a few exceptions (\\ is translated to \, but still does not escape anything). Quotes also won't help you there, as they only have impact on how spaces are interpreted. I have also submitted patches to deal with this. * Right now (yeah, I'm emphasizing it :), EVALUATE doesn't work according to specs. It will silently ignore the count passed, and will process the string as a null-terminated string. Needless to say, I hope :-), I intend to fix this too. Alas, I haven't submitted this patch yet. Anyway, if you want to create strings to be evaluated, remember to zero terminate them. You can create a wrapper for the builtin commands to make things a little bit easier. I have submitted such a hack to... to -current, I think. Search for my messages to -current in december and you'll find it easily. With it, you can then do something like: s" /etc" s" -l" 2 wrap" ls" \ That is, pass parameters \ as separate strings, \ instead of having to \ evaluate a single string Notice, this hack is entirely in Forth, and has been tested against the loader, so you don't have to patch loader's source to use it. I hope this helped. Feel free to forward me any questions concerning ficl. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com "Heart like a Gabriel, pure and white as ivory, soul like a lucifer, black and cold as a piece of lead." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 21:06:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA29878 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 21:06:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA29868; Sat, 9 Jan 1999 21:06:09 -0800 (PST) (envelope-from shocking@bandicoot.prth.tensor.pgs.com) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.8.8/8.8.8) with SMTP id NAA10990; Sun, 10 Jan 1999 13:05:27 +0800 (WST) Received: by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id NAA05628; Sun, 10 Jan 1999 13:05:26 +0800 Date: Sun, 10 Jan 1999 13:05:26 +0800 From: shocking@prth.pgs.com (Stephen Hocking-Senior Programmer PGS Tensor Perth) Message-Id: <199901100505.NAA05628@ariadne.tensor.pgs.com> To: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Support for Netgear ethernet cards Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know if the Netgear series of ethernet cards (PCI, 10/100Mb/s) is supported by the current bunch of drivers? I had a look at the card and couldn't see any familiar names silk-screened on the chips, with main chip having NetGear splattered all over it. Stephen PS - They're going dirt cheap at a local PC place. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 21:43:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03519 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 21:43:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles156.castles.com [208.214.165.156]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03505; Sat, 9 Jan 1999 21:43:14 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id VAA03464; Sat, 9 Jan 1999 21:39:39 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901100539.VAA03464@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: shocking@prth.pgs.com (Stephen Hocking-Senior Programmer PGS Tensor Perth) cc: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Support for Netgear ethernet cards In-reply-to: Your message of "Sun, 10 Jan 1999 13:05:26 +0800." <199901100505.NAA05628@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 21:39:38 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anyone know if the Netgear series of ethernet cards (PCI, 10/100Mb/s) > is supported by the current bunch of drivers? I had a look at the > card and couldn't see any familiar names silk-screened on the chips, > with main chip having NetGear splattered all over it. Yes; as Bill recently posted, we now have support either in the tree or available as addons from Bill's page (www.freebsd.org/~wpaul) for prettymuch all of the 100Mbps chipsets. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 21:50:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03962 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 21:50:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from out4.ibm.net (out4.ibm.net [165.87.194.239]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03957 for ; Sat, 9 Jan 1999 21:50:47 -0800 (PST) (envelope-from mikegoe@ibm.net) Received: from Nikki (slip129-37-208-240.oh.us.ibm.net [129.37.208.240]) by out4.ibm.net (8.8.5/8.6.9) with SMTP id FAA70988 for ; Sun, 10 Jan 1999 05:50:13 GMT Message-Id: <199901100550.FAA70988@out4.ibm.net> From: "Michael G." To: "freebsd-hackers@FreeBSD.ORG" Date: Sun, 10 Jan 1999 00:45:43 -0500 Reply-To: "Michael G." X-Mailer: PMMail 98 Professional (2.01.1600) For Windows 98 (4.10.1998) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: FreeBSD Cluster Size Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm building a chart that describes the different file formats and how the cluster size is dependent on the partition size (except ofcourse for HPFS). What I need to know is what is the cluster size for the FreeBSD 3.0-RELEASE? If you know..please do tell Thanks. Michael G. ------------------------------------------------------------------- ICQ #24517082 Live FreeBSD...Or Die! PIC X 10 VALUE "YES! COBOL" ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 21:59:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04675 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 21:59:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04670 for ; Sat, 9 Jan 1999 21:59:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA80951; Sat, 9 Jan 1999 21:59:01 -0800 (PST) (envelope-from dillon) Date: Sat, 9 Jan 1999 21:59:01 -0800 (PST) From: Matthew Dillon Message-Id: <199901100559.VAA80951@apollo.backplane.com> To: "Michael G." Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: FreeBSD Cluster Size Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm building a chart that describes the different file :formats and how the cluster size is dependent on the :partition size (except ofcourse for HPFS). What I need to :know is what is the cluster size for the FreeBSD :3.0-RELEASE? : :If you know..please do tell : :Thanks. : :Michael G. There is nothing specific to FreeBSD 2.x or 3.x that changes the layout of typical filesystem types. For UFS/FFS, you can mess around with the parameters to newfs to get pretty much whatever layout you want. UFS/FFS puts restrictions on various parameters, but they tend to be relative restrictions, so you can scale the parameters as you like. See 'man newfs' and 'man tunefs'. Also, after 3.0 release, the reallocblks code was fixed and reenabled in UFS/FFS so, effectively, you get a defragger now too. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 22:00:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04995 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 22:00:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04973 for ; Sat, 9 Jan 1999 22:00:02 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id QAA06162; Sun, 10 Jan 1999 16:29:22 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id QAA15164; Sun, 10 Jan 1999 16:29:14 +1030 (CST) Date: Sun, 10 Jan 1999 16:29:13 +1030 From: Greg Lehey To: "Michael G." Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: FreeBSD Cluster Size Message-ID: <19990110162913.J8886@freebie.lemis.com> References: <199901100550.FAA70988@out4.ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901100550.FAA70988@out4.ibm.net>; from Michael G. on Sun, Jan 10, 1999 at 12:45:43AM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 10 January 1999 at 0:45:43 -0500, Michael G. wrote: > I'm building a chart that describes the different file > formats and how the cluster size is dependent on the > partition size (except ofcourse for HPFS). What I need to > know is what is the cluster size for the FreeBSD > 3.0-RELEASE? I'm sorry, I don't understand what you mean by ``cluster''. The UFS file system stores file data in blocks and fragments, and metadata in inodes. It's described in /usr/share/doc/smm/05.fastfs/paper.*. Typically, block sizes are 4kB or 8 kB, and the corresponding fragments sizes are 512 bytes and 1 kB. > PIC X 10 VALUE "YES! COBOL" What language is this? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 22:21:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA06130 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 22:21:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06125 for ; Sat, 9 Jan 1999 22:21:48 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id BAA83523; Sun, 10 Jan 1999 01:25:54 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Sun, 10 Jan 1999 01:25:54 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Greg Lehey cc: "Michael G." , "freebsd-hackers@FreeBSD.ORG" Subject: Re: FreeBSD Cluster Size In-Reply-To: <19990110162913.J8886@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 10 Jan 1999, Greg Lehey wrote: > On Sunday, 10 January 1999 at 0:45:43 -0500, Michael G. wrote: > > I'm building a chart that describes the different file > > formats and how the cluster size is dependent on the > > partition size (except ofcourse for HPFS). What I need to > > know is what is the cluster size for the FreeBSD > > 3.0-RELEASE? > > I'm sorry, I don't understand what you mean by ``cluster''. The UFS > file system stores file data in blocks and fragments, and metadata in > inodes. It's described in /usr/share/doc/smm/05.fastfs/paper.*. > Typically, block sizes are 4kB or 8 kB, and the corresponding > fragments sizes are 512 bytes and 1 kB. > What he's asking about is if FreeBSD has the same lame problems like DOS (which it does NOT) where if your partition is > x blocks then the minimum block allocation increases. In MS-DOG systems eventually the minimum block size becomes 64k and since DOG doesn't allow for FFS 'frags' you tend to waste quite a bit of space. Anyway in FreeBSD generally the block size is 8k no matter how large the partition, however this IS tuneable depending on what characteristics you desire. You can go higher but then frags get really bad can't you? > > PIC X 10 VALUE "YES! COBOL" > > What language is this? Isn't it COBOL? :) -Alfred > > Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 9 22:57:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09600 for freebsd-hackers-outgoing; Sat, 9 Jan 1999 22:57:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles156.castles.com [208.214.165.156]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09594 for ; Sat, 9 Jan 1999 22:57:40 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id WAA03803; Sat, 9 Jan 1999 22:54:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901100654.WAA03803@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Michael G." cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: FreeBSD Cluster Size In-reply-to: Your message of "Sun, 10 Jan 1999 00:45:43 EST." <199901100550.FAA70988@out4.ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 22:54:10 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm building a chart that describes the different file > formats and how the cluster size is dependent on the > partition size (except ofcourse for HPFS). What I need to > know is what is the cluster size for the FreeBSD > 3.0-RELEASE? > > If you know..please do tell We don't use clusters, so the answer isn't that simple. By default, the FreeBSD filesystem uses 8kB blocks and 1kB frags, however these values are tunable. You're welcome to ask what blocks and frags are if you need to know; for the purpose of space wastage, the frag is the smallest allocation unit. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message