From vandys@glare.cisco.com Tue Jan 10 06:12:28 1995 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA02379; Tue, 10 Jan 1995 06:12:24 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA03046 for ; Tue, 10 Jan 1995 06:43:28 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA18675; Tue, 10 Jan 1995 15:43:56 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA10182; Tue, 10 Jan 1995 15:43:50 +0100 Date: Tue, 10 Jan 1995 15:43:50 +0100 Message-Id: <9501101443.AA10182@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: is malloc thread save? From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I'm going to extend the sever support library to support multithreaded servers. From a quick view I guess that the malloc in libc is not thread save. Am I right? Thanx Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Tue Jan 10 17:29:19 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA02448; Tue, 10 Jan 1995 17:29:18 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id SAA10888 for ; Tue, 10 Jan 1995 18:01:17 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id LAA15478 for vsta@cisco.com; Tue, 10 Jan 1995 11:51:48 -0700 Date: Tue, 10 Jan 1995 11:51:48 -0700 From: Gary Shea Message-Id: <199501101851.LAA15478@xmission.xmission.com> To: vsta@cisco.com Subject: Reality check This is directed to Andy, but I felt it was best to post it publicly. Andy, in order to decide whose changes my code should respond to, I need to know where you stand on changes that you have expressed differences with. What is going to happen if someone creates code which is not in accordance with your desires? I'd like a clear policy here. My perspective is: It's your system, I'm happy to work within your preferences because I get a lot out of doing it. But there are competing influences at the moment, and while all will be resolved in time, I want guidelines to clarify what that resolution will look like, so I can avoid wasted effort now. Thanks! Gary From vandys@glare.cisco.com Tue Jan 10 17:45:13 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA02452; Tue, 10 Jan 1995 17:45:12 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id SAA12103; Tue, 10 Jan 1995 18:17:11 -0800 Message-Id: <199501110217.SAA12103@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Gary Shea Cc: vsta@cisco.com Subject: Re: Reality check In-Reply-To: Your message of "Tue, 10 Jan 1995 11:51:48 MST." <199501101851.LAA15478@xmission.xmission.com> Date: Tue, 10 Jan 1995 18:17:11 -0800 From: Andrew Valencia [Gary Shea writes:] >Andy, in order to decide whose changes my code should respond to, >I need to know where you stand on changes that you have expressed >differences with. What is going to happen if someone creates code >which is not in accordance with your desires? I'd like a clear policy >here. Well, there's no easy answer. For instance, I had 0 interest in floating point, but Dave Hudson wanted it. He did it, and gave me the diffs. I delayed. He re-merged them, and did a bunch of other great stuff. So they ended up in the system. On the other hand, I've had a couple folks propose making the C library thread-safe. I object on the grounds that it penalizes >99% of our code (the single-threaded model) for the good of the < 1%. The <1% should bear the cost. So if you add all the locks and semaphores and extra complexity for resource allocation, I'm going to insist it goes to a secondary C library, or be a wrapper, or something like that. >My perspective is: It's your system, I'm happy to work within your >preferences because I get a lot out of doing it. But there are >competing influences at the moment, and while all will be resolved >in time, I want guidelines to clarify what that resolution will look >like, so I can avoid wasted effort now. I value all contributions. This is a free system, and unless we're having fun (at least most of the time), well, we all know how to do less fun stuff, and make money to boot. Against this is the values which make VSTa stand out: wherever possible, VSTa chooses the simple/elegant 75% solution against the complex/bloated 99% solution. Where somebody *needs* the 99% solution, I look for a way to localize the impact of meeting the 99% solution. For instance, our "make" is tiny. Sometimes you need the full GNU make semantics. So there's a port of GNU make "gmake". But the system standard one remains the small/simple/fast one. I've resisted moving forward to a newer GNU C compiler; they have gotten amazingly huge. Then somebody came forward with lcc--which in some ways is the "VSTa of C compilers", as it were (although we need to get the register allocation working for i386). So now I can make *that* "cc", and have the simple/efficient/small compiler, which makes me much happier to roll GCC forward to its full/latest/greatest 2.X majesty. So please don't take offense when I start dancing around while figuring out how to handle a new issue. It's just that if you fiddle with an issue for a while, you can usually find a better yet less obvious way to fit it into the whole. Regards, Andy From vandys@glare.cisco.com Wed Jan 11 04:34:28 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA02519; Wed, 11 Jan 1995 04:34:27 -0800 Received: from edil.dcae.pub.ro ([141.85.128.250]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA09741 for ; Wed, 11 Jan 1995 05:06:18 -0800 Received: by edil.dcae.pub.ro (AIX 3.2/UCB 5.64/4.06) id AA20499; Wed, 11 Jan 1995 15:00:25 +0300 From: mseritan@edil.dcae.pub.ro (Marius Seritan) Message-Id: <9501111200.AA20499@edil.dcae.pub.ro> To: vsta@cisco.com Subject: faq Date: Wed, 11 Jan 95 15:00:25 +0300 Hi, I am a new comer to VSTa and I can't get it up on my machine. I tried to look in the mailing list archive but I couldn't sort it out. Is there any FAQ laying somewhere on the net? I get the following stuff on screen: ---------------- c:\vsta\boot>go Boot vsta: 69600+36864+5736 Tasks: cons namer wd swap dos init Launch at 0x1020 ---------------- And that's all. The last line is one of the last lines of the booter so I think there is a problem somewhere in the kernel (or maybe on the console, there is some disk activity). As my first DOS partition is a very small one I was only able to place the following directories on harddisk C: etc, bin, lib. I tried to boot on another computer. Unfortunatelly the dos partition is the 3rd one and VSTa doesn't like it either. From vandys@glare.cisco.com Wed Jan 11 09:53:49 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA02541; Wed, 11 Jan 1995 09:53:48 -0800 Received: from nightfly.rme.com (nightfly.rme.com [198.30.235.9]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA25932 for ; Wed, 11 Jan 1995 10:25:48 -0800 Received: (from matt@localhost) by nightfly.rme.com (8.6.9/8.6.9) id NAA06987 for vsta@cisco.com; Wed, 11 Jan 1995 13:25:39 -0500 From: Matt Emerson Message-Id: <199501111825.NAA06987@nightfly.rme.com> Subject: setjmp/longjmp and sparc To: vsta@cisco.com Date: Wed, 11 Jan 1995 13:25:39 -0500 (EST) Content-Type: text Content-Length: 618 well, i might as well reveal my stupidity now, and get it over with. i don't understand how setjmp/longjmp are used to switch contexts in sched.c. on a sparc, setjmp just saves the caller's stack pointer, frame pointer, and return pc; longjmp simply unwinds the call stack by popping register windows until it finds the matching frame. i take it that a jmp_buf saves a lot more stuff (like an almost-complete copy of the register file) on other architectures? i think my ignorance of how setjmp/longjmp works on other machines is part of my problem in understanding what's going on. -matt -- http://www.rme.com/ From vandys@glare.cisco.com Wed Jan 11 10:13:36 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02545; Wed, 11 Jan 1995 10:13:35 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA15618; Wed, 11 Jan 1995 10:45:38 -0800 Message-Id: <199501111845.KAA15618@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Matt Emerson Cc: vsta@cisco.com Subject: Re: setjmp/longjmp and sparc In-Reply-To: Your message of "Wed, 11 Jan 1995 13:25:39 EST." <199501111825.NAA06987@nightfly.rme.com> Date: Wed, 11 Jan 1995 10:45:37 -0800 From: Andrew Valencia [Matt Emerson writes:] >i don't understand how setjmp/longjmp are used to >switch contexts in sched.c. Unlike classic UNIX, VSTa does not have all kernel stacks exist at the same address. Thus, when you want to switch processes, you simply need to swap register values to point at a new stack (and restore whatever other registers restore you to the corresponding execution context). The changing of VM context to a new process mostly impacts the *user* portion of the address space; the kernel portion is identical across all processes. >on a sparc, setjmp just saves the caller's stack pointer, >frame pointer, and return pc; longjmp simply unwinds the >call stack by popping register windows until it finds the >matching frame. As I understand Sparc (never done kernel work for it, but read a little about it), the CPU has a window of stack space which is implemented with register-level performance. Thus, the i386-like dichotomy between registers and stack variables is a little fuzzier. >i take it that a jmp_buf saves a lot more stuff (like an >almost-complete copy of the register file) on other >architectures? i think my ignorance of how setjmp/longjmp >works on other machines is part of my problem in understanding >what's going on. And since the "register file" is basically just a portion of the stack context, restoring stack context should be all that's needed. I assume there's still a collection of stuff towards the top of the stack which you pop off as a part of returning to user mode? Andy From vandys@glare.cisco.com Wed Jan 11 11:47:59 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA02557; Wed, 11 Jan 1995 11:47:58 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA21843; Wed, 11 Jan 1995 12:20:00 -0800 Message-Id: <199501112020.MAA21843@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: mseritan@edil.dcae.pub.ro (Marius Seritan) Cc: vsta@cisco.com Subject: Re: faq In-Reply-To: Your message of "Wed, 11 Jan 1995 15:00:25 +0300." <9501111200.AA20499@edil.dcae.pub.ro> Date: Wed, 11 Jan 1995 12:19:59 -0800 From: Andrew Valencia [mseritan@edil.dcae.pub.ro (Marius Seritan) writes:] >c:\vsta\boot>go >Boot vsta: 69600+36864+5736 >Tasks: cons namer wd swap dos init >Launch at 0x1020 >And that's all. A common cause of this is to have your video card in monochrome text mode. Try switching to "cons -mono" in boot/boot.lst. You will also have to recompile the kernel debugger if you want to use it (it accesses the screen directly). Andy From vandys@glare.cisco.com Thu Jan 12 06:23:39 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA02737; Thu, 12 Jan 1995 06:23:37 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA23518 for ; Thu, 12 Jan 1995 06:55:25 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28197; Thu, 12 Jan 1995 15:56:30 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA07779; Thu, 12 Jan 1995 15:56:15 +0100 Date: Thu, 12 Jan 1995 15:56:15 +0100 Message-Id: <9501121456.AA07779@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Problem with libc rebuild From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I have some problems with the rebuild of the libc. If I do it as the first step after a rebuild, it usually happen to work. (Not sure wheter it happend to hang one or two times). But if I do something and go later to rebuild the thing it will hang in building libc.a. I get Library ld.a at 0x6000000 (or something like that) Library libc.a at 60001000 (or similar) then it hangs. I know that this usually take a long time, but not 20 minutes. Maybe it is importend to say, all I did was to start a program which happend to exit with 2. Any idea? /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Thu Jan 12 06:41:32 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA02741; Thu, 12 Jan 1995 06:41:31 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA24135 for ; Thu, 12 Jan 1995 07:13:26 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA28614; Thu, 12 Jan 1995 16:14:24 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA40237; Thu, 12 Jan 1995 16:14:14 +0100 Date: Thu, 12 Jan 1995 16:14:14 +0100 Message-Id: <9501121514.AA40237@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: namer_find seem not to work in libc From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I tied to move the following code into libc. If I use it from a nomal .o file it works, but if I move it into the libc (and put a entry into libc.db) it seems, that namer_find hangs. sema sema_new() { static port_name semaport = 0; if( semaport == 0 ) { semaport = namer_find(theSemaName); if (semaport < 0) { perror("namer_find no semaphore server registert"); exit(1); } } return msg_connect(semaport, ACC_WRITE ); } ????? Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Thu Jan 12 14:02:45 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02781; Thu, 12 Jan 1995 14:02:44 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA18649 for ; Thu, 12 Jan 1995 14:34:53 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA06421; Thu, 12 Jan 95 17:34:21 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA03028; Thu, 12 Jan 95 17:34:19 EST Received: from devserv.bedford.progress.COM (devserv-e4) by proserv.bedford.progress.COM (4.1/psc2.2) id AA06234; Thu, 12 Jan 95 17:34:19 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA22038; Thu, 12 Jan 95 17:34:16 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA03540; Thu, 12 Jan 95 17:34:14 EST Date: Thu, 12 Jan 95 17:34:14 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9501121734.ZM3538@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: LCC Compiler Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have seen several messages talking about using the LCC compiler for VSTa. I have been using the compiler for several months on a Sparc and I really do like it. There are some interesting little problems, especially with wacky code that uses lots of convoluted macros, but all in all the compiler is quite reliable. However, the Intel 80x86 backend emits assembler code in Intel format but the GAS assembler on both Linux and VSTa uses a Motorola format. Has someone rewritten the backend to emit in Motorola format? Or are you using a translator step between the compiler and assembler? Enquiring minds want to know...:-) -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Thu Jan 12 19:52:54 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA02806; Thu, 12 Jan 1995 19:52:49 -0800 Received: from netcom10.netcom.com (hjb@netcom10.netcom.com [192.100.81.120]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id UAA05087 for ; Thu, 12 Jan 1995 20:25:00 -0800 Received: by netcom10.netcom.com (8.6.9/Netcom) id UAA27864; Thu, 12 Jan 1995 20:23:17 -0800 From: hjb@netcom.com (Hwa-Jin Bae) Message-Id: <199501130423.UAA27864@netcom10.netcom.com> Subject: Re: LCC Compiler To: koogler@bedford.progress.com (David Koogler) Date: Thu, 12 Jan 1995 20:23:17 -0800 (PST) Cc: vsta@cisco.com In-Reply-To: <9501121734.ZM3538@crozet> from "David Koogler" at Jan 12, 95 05:34:14 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1330 > > I have seen several messages talking about using the LCC compiler for VSTa. I > have been using the compiler for several months on a Sparc and I really do like > it. There are some interesting little problems, especially with wacky code > that uses lots of convoluted macros, but all in all the compiler is quite > reliable. are you using 3.1 or 3.2? > > However, the Intel 80x86 backend emits assembler code in Intel format but the > GAS assembler on both Linux and VSTa uses a Motorola format. Has someone > rewritten the backend to emit in Motorola format? Or are you using a > translator step between the compiler and assembler? > > Enquiring minds want to know...:-) > it's not "intel" vs. "motorola" format. it's "mit" vs. "others" format. the existing backend in lcc for x86 arch is intended for DOS, i believe, and the machine desriptions seems to be fore microsoft style assemblers. there are patches and hacks you can do to this and make it unix compatible -- make it generate gas compatible "mit" output, but not gas compatible "morotola" output ;-) a potential problem with using LCC -- it lacks m68k backend currently. i've talked to david hansen and he says there is no such thing currently. -- Hwa-Jin Bae (hjb@netcom.com) Peaceful Star, 4001 San Leandro St. #3, Oakland, CA 94601 (510)436-2884 From vandys@glare.cisco.com Fri Jan 13 00:57:41 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA02824; Fri, 13 Jan 1995 00:57:39 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA14799 for ; Fri, 13 Jan 1995 01:29:47 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04765; 13 Jan 95 9:29 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rSiFe-0002jvC; Fri, 13 Jan 95 09:24 GMT Message-Id: From: Dave Hudson Subject: Kernel performance issues To: VSTa mailing list Date: Fri, 13 Jan 1995 09:24:58 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 945 Hi all, I've just about completed my first round of performance tweaking on the kernel, but I have a question and a request. As a lot of people seem keen to use lcc I'm trying hard to avoid the default use of inlined functions or assembly code - can anyone tell me if either of these facilities are likely to be added to lcc in the near future? For performance, using function implementations for some of the assembly code is a real loss (about 15% on context switch times on my 486 systems). Incidently I think I mentioned before that I needed gcc 2.x for these facilities, but I realised yesterday that the current 1.42 release does these as well. Now to my request: I don't have access to a well configured 386 system, and I'd like to see what performance differences are acheived on a 386 from the tweaked kernel code. If anyone has a 386 and can spare half an hour to run some comparison tests I'd be grateful. Regards, Dave From vandys@glare.cisco.com Fri Jan 13 01:59:13 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA02832; Fri, 13 Jan 1995 01:59:12 -0800 Received: from edil.dcae.pub.ro (edil.dcae.pub.ro [141.85.128.46]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA16417 for ; Fri, 13 Jan 1995 02:31:17 -0800 From: mseritan@edil.dcae.pub.ro Received: from jupiter.dcae.pub.ro by edil.dcae.pub.ro (AIX 3.2/UCB 5.64/4.06) id AA16063; Fri, 13 Jan 1995 11:59:08 +0300 Received: by jupiter.dcae.pub.ro (AIX 3.2/UCB 5.64/4.05) id AA16346; Fri, 13 Jan 1995 11:51:32 +0300 Message-Id: <9501130851.AA16346@jupiter.dcae.pub.ro> To: vsta@cisco.com Subject: booting on a mono display Date: Fri, 13 Jan 95 11:51:32 +0300 Hi, Sorry for yesterday message about problems with a monochrome display. The problem went away when I said `mode mono' before `boot vsta'. Maybe I will try to figure about what happens and I will patch the cons server. Marius Marius Seritan about me From vandys@glare.cisco.com Sat Jan 14 04:48:32 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA03022; Sat, 14 Jan 1995 04:48:30 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA04956 for ; Sat, 14 Jan 1995 05:20:50 -0800 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id IAA03319; Sat, 14 Jan 1995 08:20:48 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA13985; Sat, 14 Jan 1995 08:21:11 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199501141321.AA13985@world.std.com> Subject: SCSI tape driver alpha test To: vsta@cisco.com Date: Sat, 14 Jan 1995 08:21:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 289 Hi, I should have an SCSI/CAM server alpha test package ready in a day or two. The new server includes SCSI tape support. Please send me email if you're intrested in testing the new server. BTW - what will the next version of VSTa be called (1.3.3 or 1.4)? Thanks. Mike Larson From vandys@glare.cisco.com Sat Jan 14 07:24:17 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03033; Sat, 14 Jan 1995 07:24:16 -0800 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA07965 for ; Sat, 14 Jan 1995 07:56:36 -0800 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.9/8.6.9) id KAA00538; Sat, 14 Jan 1995 10:44:49 -0500 Date: Sat, 14 Jan 1995 10:44:48 -0500 From: Kethi-Reddy Vanier Subject: vme bus, 68040....... To: vsta@cisco.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am wondering if vsta is ported to 68040/68030. We have nine 68040/vme bus borards. They are sitting there and getting dusty. I am wondering if I can connect them in a loosely coupled manner, and run vsta on all nine of them. Hopefully it will be configured in such a manner, the end user will see it as a one machine. Any help or guidance is appriciated. Thank to all in advance. VAnier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca BEng, Computer Systems. (4th year) From vandys@glare.cisco.com Sat Jan 14 16:57:24 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA03058; Sat, 14 Jan 1995 13:10:38 -0800 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA15616 for ; Sat, 14 Jan 1995 13:42:54 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA13641; Sat, 14 Jan 1995 22:44:08 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA46913; Sat, 14 Jan 1995 22:44:00 +0100 Date: Sat, 14 Jan 1995 22:44:00 +0100 Message-Id: <9501142144.AA46913@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Need Help! From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I don't understand VSTa anymore. I used to think that, if a server dies all it's client will see an I/O error. The same effect should be achieved if a server does a msg_disconnect to it's main port. Thus I wrote a server thread which - on request to die - does a msg_disconnect to it's main port (and then exit()s). But this doesn't seem to send an I/O error to all the client ports I've cloned. Even the client which sent the msg to die hangs in the msg_send it did. What have I missed? Thanx for any help. Hopfully I don't have to wait until Andy is back from vacation. Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Sun Jan 15 09:27:18 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00163; Sun, 15 Jan 1995 09:27:17 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA10768; Sun, 15 Jan 1995 10:01:16 -0800 Message-Id: <199501151801.KAA10768@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Kethi-Reddy Vanier Cc: vsta@cisco.com Subject: Re: vme bus, 68040....... In-Reply-To: Your message of "Sat, 14 Jan 1995 10:44:48 EST." Date: Sun, 15 Jan 1995 10:01:16 -0800 From: Andrew Valencia [Kethi-Reddy Vanier writes:] > I am wondering if vsta is ported to 68040/68030. We have nine >68040/vme bus borards. They are sitting there and getting dusty. I am >wondering if I can connect them in a loosely coupled manner, and run >vsta on all nine of them. Hopefully it will be configured in such a >manner, the end user will see it as a one machine. Yes, a port to the 68030 Amiga is running pretty well, at last report from Hawaii (newsham@aloha.net). The port was done with an older rev of VSTa, and he's been planning on doing a merge/update soon. Note that the '040 does not support two-level PTE format, only three. There will be incremental work to support the '040, I expect. Clustering is currently not done. We believe that we are putting the right tools in place, but... "In theory there's no difference between theory and practice, but in practice, there is". :-) Regards, Andy Valencia From vandys@glare.cisco.com Mon Jan 16 01:38:45 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA00206; Mon, 16 Jan 1995 01:38:43 -0800 Received: from trefle.saclay.cea.fr ([132.166.128.101]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id CAA12037 for ; Mon, 16 Jan 1995 02:12:41 -0800 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.9/ CEANET-ROUTER-3.0) with ESMTP id LAA28167 for ; Mon, 16 Jan 1995 11:12:20 +0100 Received: from rosser.serma.cea.fr by oeillet.saclay.cea.fr (8.6.9/ CEANET-ROUTER-3.0) with SMTP id LAA05494 for ; Mon, 16 Jan 1995 11:14:12 +0100 Received: by rosser.serma.cea.fr (5.0/CEANET.2.0.1) id AA01535; Mon, 16 Jan 1995 11:12:40 --100 Date: Mon, 16 Jan 1995 11:12:40 --100 From: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Message-Id: <9501161012.AA01535@rosser.serma.cea.fr> To: vsta@cisco.com Subject: hello again Content-Length: 758 Hello All VSTa users. I subscribed to this mailing list, but didn't recieve anything since the beginning of the year. I'm the guy who ported (an ealry alpha code) linux ext2fs to VSTa. Happy New Year to everyone. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile.starynkevitch@cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Mon Jan 16 04:34:24 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00330; Mon, 16 Jan 1995 04:34:23 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id FAA00442; Mon, 16 Jan 1995 05:08:27 -0800 Message-Id: <199501161308.FAA00442@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Cc: vsta@cisco.com Subject: Re: -my alpha ext2fs server- In-Reply-To: Your message of "Mon, 16 Jan 1995 13:58:06." <9501161258.AA01770@rosser.serma.cea.fr> Date: Mon, 16 Jan 1995 05:08:27 -0800 From: Andrew Valencia [basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) writes:] >Also, could the mailing list maintainer check out that i'm still on >it? (my logical email adress is basile.starynkevitch@cea.fr, aliasing >my physical email of basile@soleil.serma.cea.fr). Please send administrative requests to vsta-request@cisco.com instead. No, you weren't, and yes, you are now. Regards, Andy From vandys@glare.cisco.com Mon Jan 16 04:26:50 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00320; Mon, 16 Jan 1995 04:26:49 -0800 Received: from trefle.saclay.cea.fr (trefle.saclay.cea.fr [132.166.128.101]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA23176 for ; Mon, 16 Jan 1995 05:00:50 -0800 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.9/ CEANET-ROUTER-3.0) with ESMTP id NAA07291 ; Mon, 16 Jan 1995 13:57:47 +0100 Received: from rosser.serma.cea.fr by oeillet.saclay.cea.fr (8.6.9/ CEANET-ROUTER-3.0) with SMTP id NAA13946 ; Mon, 16 Jan 1995 13:59:38 +0100 Received: by rosser.serma.cea.fr (5.0/CEANET.2.0.1) id AA01770; Mon, 16 Jan 1995 13:58:06 --100 Date: Mon, 16 Jan 1995 13:58:06 --100 From: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Message-Id: <9501161258.AA01770@rosser.serma.cea.fr> To: mseritan@edil.dcae.pub.ro Cc: vsta@cisco.com In-Reply-To: <9501161137.AA15376@edil.dcae.pub.ro> (mseritan@edil.dcae.pub.ro) Subject: -my alpha ext2fs server- Content-Length: 1385 Also, could the mailing list maintainer check out that i'm still on it? (my logical email adress is basile.starynkevitch@cea.fr, aliasing my physical email of basile@soleil.serma.cea.fr). Thanks to the courtesy of Markus Friedl msfriedl@cip.informatik.uni-erlangen.de, my Alpha ext2fs server is available at ftp://131.188.190.131/pub/VSTa/e2fs This alpha code is a port of R.Card ext2fs filesystem to VSTa, as a VSTa filesystem server. This first release is buggy, cross-compiled with gcc-2.6.2 and binutils-2.5.1 on a Linux host, and supports only read-only ext2 filesystems. Don't use it except for testing. I'm still waiting report on it. I'm VSTa-ling and Linux-ing at home only. I didn't touch any byte of this code since its release. I'm waiting for comments, suggestions, reactions, etc. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile.starynkevitch@cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Mon Jan 16 09:55:33 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00373; Mon, 16 Jan 1995 09:55:32 -0800 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA08365; Mon, 16 Jan 1995 10:29:36 -0800 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.9/8.6.9) id NAA00124; Mon, 16 Jan 1995 13:16:46 -0500 Date: Mon, 16 Jan 1995 13:16:45 -0500 From: Kethi-Reddy Vanier Subject: Re: vme bus, 68040....... To: Andrew Valencia Cc: vsta@cisco.com In-Reply-To: <199501151801.KAA10768@glare.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 15 Jan 1995, Andrew Valencia wrote: > [Kethi-Reddy Vanier writes:] > > > I am wondering if vsta is ported to 68040/68030. We have nine > >68040/vme bus borards. They are sitting there and getting dusty. I am > Yes, a port to the 68030 Amiga is running pretty well, at last report from > Hawaii (newsham@aloha.net). The port was done with an older rev of VSTa, > and he's been planning on doing a merge/update soon. Where is the VSTA for 68030 is located. i.e ftp sites. Thanks to all Vanier From vandys@glare.cisco.com Wed Jan 18 05:59:50 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00537; Wed, 18 Jan 1995 05:59:49 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA26943 for ; Wed, 18 Jan 1995 06:34:02 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21601; 18 Jan 95 13:54 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rUant-0002jRC; Wed, 18 Jan 95 13:52 GMT Message-Id: From: Dave Hudson Subject: Context switch times To: VSTa mailing list Date: Wed, 18 Jan 1995 13:52:05 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 526 Hi All, I'm still working on the performance of the VSTa kernel and now some of the library functions as well, but I was wondering if anyone has a list of context switch times for other O/S's? Someone mentioned a comparison that was posted on comp.arch over a year ago - does anyone know if that's archived somewhere? BTW in case anyone's interested, I'm now working on DX/2-66 with 256k of L2 cache (not a particularly good cache design though), and I now have perf1 showing a switch time of 105 us. Regards, Dave From vandys@glare.cisco.com Wed Jan 18 06:41:59 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00541; Wed, 18 Jan 1995 06:41:57 -0800 Received: from simon.cs.cornell.edu (SIMON.CS.CORNELL.EDU [128.84.154.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA28567 for ; Wed, 18 Jan 1995 07:16:14 -0800 Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.9/R1.01) with ESMTP id KAA05314; Wed, 18 Jan 1995 10:15:54 -0500 Received: from gungnir.cs.cornell.edu (GUNGNIR.CS.CORNELL.EDU [128.84.218.57]) by cloyd.cs.cornell.edu (8.6.9/M1.4) with ESMTP id KAA16824; Wed, 18 Jan 1995 10:15:55 -0500 Received: (vogels@localhost) by gungnir.cs.cornell.edu (8.6.9/C1.00) id KAA14020; Wed, 18 Jan 1995 10:15:38 -0500 Message-Id: <199501181515.KAA14020@gungnir.cs.cornell.edu> To: Dave Hudson Cc: VSTa mailing list Subject: Re: Context switch times In-Reply-To: Your message of "Wed, 18 Jan 1995 13:52:05 GMT." Date: Wed, 18 Jan 1995 10:15:37 -0500 From: Werner Vogels > I'm still working on the performance of the VSTa kernel and now some of the > library functions as well, but I was wondering if anyone has a list of > context switch times for other O/S's? Host OS Mhz Null 2-proc 8-proc Syscall ctxsw ctxsw --------- ------------- ---- ------- ------ ------ rs6000 AIX 2 62 23 20 32 mako HP-UX A.09.01 65 22 25 29 seahorse HP-UX A.09.03 99 14 47 55 snake HP-UX A.09.01 66 21 40 38 IP22 IRIX 5.3 198 11 66 94 pentium Linux 1.1.54 91 3 25 42 alpha OSF1 V2.1 182 13 54 85 ss20 SunOS 5.4 50 9 37 52 results produced by lmbench (Larry McVoy, lm@sgi.com). -- Werner From vandys@glare.cisco.com Wed Jan 18 07:39:47 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00549; Wed, 18 Jan 1995 07:39:46 -0800 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA01024 for ; Wed, 18 Jan 1995 08:14:01 -0800 Received: from genesis.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA10870 (5.67b8/IDA-1.5 for ); Wed, 18 Jan 1995 10:13:40 -0600 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id KAA12172 for vsta@cisco.com; Wed, 18 Jan 1995 10:15:44 -0600 From: David Jeske Message-Id: <199501181615.KAA12172@genesis.isdn.uiuc.edu> Subject: Performance Information To: vsta@cisco.com Date: Wed, 18 Jan 1995 10:15:43 -0600 (CST) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 4021 L M B E N C H 1 . 0 S U M M A R Y ------------------------------------ Processor, Processes - times in microseconds -------------------------------------------- Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc Syscall Process Process Process lat ctxsw ctxsw --------- ------------- ---- ------- ------- ------- ------- ---- ------ ------ rs6000 AIX 2 62 23 2.0K 7.3K 23K 3817 20 32 seahorse HP-UX A.09.03 99 14 3.6K 10.1K 18K 116 25 29 snake HP-UX A.09.01 66 21 2.6K 5.7K 17K 156 47 55 IP22 IRIX 5.3 198 11 3.1K 8.0K 19K 260 40 38 pentium Linux 1.1.54 91 3 3.3K 15.4K 49K 33 66 94 alpha OSF1 V2.1 182 13 4.8K 16.1K 43K 172 25 42 ss20.50 SunOS 5.4 50 9 10.7K 57.5K 113K 130 54 85 ss20.61 SunOS 5.4 61 7 8.0K 45.8K 87K 104 37 52 *Local* Communication latencies in microseconds ----------------------------------------------- Host OS Pipe UDP RPC/ TCP RPC/ UDP TCP --------- ------------- ------- ------- ------- ------- ------- rs6000 AIX 2 143 385 820 498 1054 seahorse HP-UX A.09.03 193 244 832 262 812 snake HP-UX A.09.01 296 403 1195 367 1142 IP22 IRIX 5.3 131 313 671 278 641 pentium Linux 1.1.54 157 658 1030 1164 1591 alpha OSF1 V2.1 185 404 718 428 851 ss20.50 SunOS 5.4 194 590 935 560 1196 ss20.61 SunOS 5.4 150 414 622 335 784 *Local* Communication bandwidths in megabytes/second ---------------------------------------------------- Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem reread reread (libc) (hand) read write --------- ------------- ---- ---- ------ ------ ------ ------ ---- ----- rs6000 AIX 2 34 6.0 76.1 63.0 81 120 99 169 seahorse HP-UX A.09.03 38 35.2 44.7 32.1 25 31 49 52 snake HP-UX A.09.01 19 17.8 34.4 22.3 22 24 45 39 IP22 IRIX 5.3 34 22.1 32.3 43.7 32 31 69 66 pentium Linux 1.1.54 13 2.4 9.8 4.7 18 18 48 32 alpha OSF1 V2.1 32 12.1 39.4 22.7 39 41 76 78 ss20.50 SunOS 5.4 11 11.0 22.9 30.0 26 31 80 62 ss20.61 SunOS 5.4 24 19.5 31.0 30.7 23 24 59 40 Memory latencies in nanoseconds (WARNING - may not be correct, check graphs) -------------------------------------------- Host OS Mhz L1 $ L2 $ Main mem TLB Guesses --------- ------------- --- ---- ---- -------- --- ------- rs6000 AIX 2 61 15 229 247 776 No L2 cache? seahorse HP-UX A.09.03 98 10 10 393 481 No L1 cache? snake HP-UX A.09.01 65 15 15 378 1051 No L1 cache? IP22 IRIX 5.3 197 10 76 1018 1129 pentium Linux 1.1.54 90 11 294 439 1254 alpha OSF1 V2.1 182 10 56 321 452 ss20.50 SunOS 5.4 49 20 284 291 575 No L2 cache? ss20.61 SunOS 5.4 60 16 115 816 961 -- --- Larry McVoy (415) 390-1804 lm@sgi.com -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Wed Jan 18 09:08:44 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00567; Wed, 18 Jan 1995 09:08:41 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA06663 for ; Wed, 18 Jan 1995 09:42:38 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25618; Wed, 18 Jan 1995 18:43:22 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA39408; Wed, 18 Jan 1995 18:43:12 +0100 Date: Wed, 18 Jan 1995 18:43:12 +0100 Message-Id: <9501181743.AA39408@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Help with waitpit() needed. From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I tried to shot a thread (by notify(0,pid,EKILL)) and then to wait until it is really dead. Obviewsly I failed to write the right code. What I did was: waitpid(pid,&exitcode,0); But this dosn't seem to wait for the dead. What have I missed. Thanx /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Thu Jan 19 08:30:23 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00760; Thu, 19 Jan 1995 08:30:21 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA03487; Thu, 19 Jan 1995 09:03:57 -0800 Message-Id: <199501191703.JAA03487@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: dave@humbug.demon.co.uk Cc: vsta@amri.cisco.com Subject: Performance Date: Thu, 19 Jan 1995 09:03:57 -0800 From: Andrew Valencia Bizarre. I've had ~4 unsubscribes since you made your performance posting. There's lies, damn lies, and performance numbers, but I guess some people still base decisions on'em. :-) >> I'm going to be on vacation for 1-2 weeks. I'll have my laptop along, and >> have been fixing the swapping portion of VSTa. I've found a couple bugs so >> far, but it's still not quite right. >That will be good to see. Have you implemented a reserved pool for the >memory allocations yet? This seemed a favourite solution at one point, but >I wondered if you'd thought of another way of doing things. The page stealing code is *really* broken. I haven't found it yet, but it looks like it might involve the references made by the pseudo-view during message passing. I still think pure page stealing will cover most of the needs which otherwise would require a special pool. We'll see. >>[inlining] >> I agree, it's a powerful improvement to the language. Presumably we'll see >> an iteration of ANSI C which adds it. >I hope so, as yesterday I found it could save me another 5% or so, but >macroising the code in question would be really nasty as some of it's quite >long (but only used once or twice). Let's agree kernel source can require gcc (but not 2.X-only features, for now) and get the performance. >On a quick test I ran yesterday, gcc running with no inlining showed itself >to produce code about 25-30% slower than with inlining. I assume lcc would >give about the same performance (based on what everyone tells me). I'm >begining to wonder if (for now at least) lcc is such a good idea for the >kernel? (can't you tell that I'm starting to see my performance figures >catching up my Linux system :-)) lcc is pretty awful--no register allocation. Hopefully this will be fixed, it looked like it was only the implicit register use for string functions which messed up the code generator. >Actually on a serious note, I've been pondering performance of message >passing generally. Assuming that there was hardware support I think it >would soon dominate calls within monolithic kernels, but I've been looking >at code complexity. It appears that a lot of monolithic kernel drivers have >to jump through hoops to ensure that preemption doesn't kill them, whereas >our drivers don't seem to need this, just letting the kernel handle this >instead. I'm beginning to sympathise with the QNX claims that we can visit >the kernel more often and still end up with as a good a level of >performance. I suspect this is largely because optimising monolithic kernel >code would be far more difficult (our 5 minute modify, rebuild, reboot and >test cycle is pretty impressive really) - I'd never really thought about it >before. If you *really* want to give Linux a bad day, try measuring dispatch latency on a busy system. Which reminds me, we need to enable kernel preemption. :-) Linux is enjoying the benefits of a non-reentrant monolithic kernel, but it crashes on the rocks badly if it hits memory leaks or stale memory references (fun in a shared kernel address space), needs to dispatch something while a kernel thread is active (fork() is usually one of the most painful), or (heh!) wants to run on multiple processors. For some of this, we're just paying the price for now (as we compare performance with systems using simplifying assumptions) but the enabling technologies underneath should pay off over time. >> [omit frame pointer] >> This makes stacks almost unreadable in a crash. OK if you have no kernel >> debugger & no DEBUG. >I suspected as much, but it might be worth a thought in a "production" >appliction. Agreed. >On my quest for yet more performance I've found a real gotcha that to a >lesser extent affects server operations, but particularly affects kernel >code - the hash table manipulations. Looking at the assembly output we >generate a long divide operand. This costs 40 clocks on either a 386, 486 >or a Pentium. From what I understand, a lot of the RISC world needs to do >this in software, so it's not a particularly desireable feature. Ok, I'll take a look at this. I think your idea of moving it up to a power of two makes a lot of sense. We could just store a hash mask. The only hesitation I feel is some dusty corner of my mind remembers being told that sometimes a prime is the best modulo for hash functions. But I certainly haven't used that to date. >I got some time last night to generate assembly output for all of the >kernel. I grepped it all for div instructions as they're really nasty (2.5 >us on a 386sx-16), and found that apart from in the kernel debugger (not >really a problem) we have one each in use in the malloc() and free() code, >one in perm_ctl(), and one in pick_run(). In free()? Why? The one in malloc() should probably be handled by using a big gnarly ?: construct to divine the right bucket index at compile time. The sizes passed are usually constants (which flattens the ?: down to a constant) and the binary search otherwise is probably better than the current code anyway. See how BSD's kernel malloc (malloc.h, in particular) does it. >I must admit, I'm very surprised that I haven't really found any major >improvements that I can make (apart from the inlining of the p_lock() and >v_lock() functions) that will individually give me more than a couple of >percent at best. That said though, I now have a kernel that even with >debugging turned on is nearly twice as fast at a lot of things than when I >started, and I haven't yet recompiled the servers with the improved library >code. This just means I was (usually) not asleep at the keyboard while writing VSTa. I suspect that *big* wins to be had after your excellent work (which is necessary, and thanks much for your efforts!) are in some design modifications. Kernel continuations (where a thread switches directly over to the context of the "other" side of a client/server interaction) showed a big win in Mach 3.0. Your tests are using RT processes? Otherwise the hierarchical scheduler will slow you down (although the "cheated" queue sidesteps much of this for non-CPU-bound scenarios). A special path for messaging with small/no buffers is the only other change I've come up with. Can you generate ASCII files from your analyzer trace? I'd be interested in traces of a zero-length message exchange for: msg_send()..swtch() swtch()..msg_send() (return) msg_receive()..swtch() swtch()..msg_receive() (return) msg_reply()..swtch() swtch()..msg_reply() (return) And again for a one-byte message. Also, a: msg_receive() (return)..page_fault (return) can give me an idea of what it takes to bring in a page on demand. If you can dump symbols to your disassembler on the analyzer, cool, otherwise nm(1) it and I'll hack up something to interpose the symbolic values here. I've Cc'ed the list as there appears to be some interest on performance tuning. Regards, Andy From vandys@glare.cisco.com Thu Jan 19 09:20:01 1995 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00764; Thu, 19 Jan 1995 09:19:59 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA13642; Thu, 19 Jan 1995 09:54:16 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa02304; 19 Jan 95 17:31 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rV0hj-0002mSC; Thu, 19 Jan 95 17:31 GMT Message-Id: From: Dave Hudson Subject: Re: Performance To: Andy Valencia Date: Thu, 19 Jan 1995 17:31:27 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4465 Andrew Valencia wrote: > > Bizarre. I've had ~4 unsubscribes since you made your performance posting. > There's lies, damn lies, and performance numbers, but I guess some people > still base decisions on'em. :-) Well I hope people aren't basing too much on my figures as they're based on 3 kernel calls per 2 switches and involve messaging activity. I noticed from a note to me yesterday that the 5us switch on QNX uses sched_yield() - I think maybe I need to write a new benchmark (just think of all those missing message copies and mallocs :-)). FWIW on my DX/2-66 I show just under 100us now, but I should be able to halve that (easily) if I reconstruct my test. > >>[inlining] > >> I agree, it's a powerful improvement to the language. Presumably we'll see > >> an iteration of ANSI C which adds it. > >I hope so, as yesterday I found it could save me another 5% or so, but > >macroising the code in question would be really nasty as some of it's quite > >long (but only used once or twice). > > Let's agree kernel source can require gcc (but not 2.X-only features, for > now) and get the performance. OK, everything so far seems OK except for one inline assembly construct which I believe also fails in gcc 2.6.2 (sounds like I need to work this one out and mail the gcc buglist). > If you *really* want to give Linux a bad day, try measuring dispatch latency > on a busy system. Which reminds me, we need to enable kernel preemption. > :-) Linux is enjoying the benefits of a non-reentrant monolithic kernel, > but it crashes on the rocks badly if it hits memory leaks or stale memory > references (fun in a shared kernel address space), needs to dispatch > something while a kernel thread is active (fork() is usually one of the most > painful), or (heh!) wants to run on multiple processors. Funny, I was only thinking of moving that check_preempt() line today :-) > For some of this, we're just paying the price for now (as we compare > performance with systems using simplifying assumptions) but the enabling > technologies underneath should pay off over time. Like atomic locking (which is where I seem to have my gcc buglet). This and the mutex code could be really tweaked for single processor use! > >On my quest for yet more performance I've found a real gotcha that to a > >lesser extent affects server operations, but particularly affects kernel > >code - the hash table manipulations. Looking at the assembly output we > >generate a long divide operand. This costs 40 clocks on either a 386, 486 > >or a Pentium. From what I understand, a lot of the RISC world needs to do > >this in software, so it's not a particularly desireable feature. > > Ok, I'll take a look at this. I think your idea of moving it up to a power > of two makes a lot of sense. We could just store a hash mask. The only > hesitation I feel is some dusty corner of my mind remembers being told that > sometimes a prime is the best modulo for hash functions. But I certainly > haven't used that to date. > > >I got some time last night to generate assembly output for all of the > >kernel. I grepped it all for div instructions as they're really nasty (2.5 > >us on a 386sx-16), and found that apart from in the kernel debugger (not > >really a problem) we have one each in use in the malloc() and free() code, > >one in perm_ctl(), and one in pick_run(). > > In free()? Why? > > The one in malloc() should probably be handled by using a big gnarly ?: > construct to divine the right bucket index at compile time. The sizes > passed are usually constants (which flattens the ?: down to a constant) and > the binary search otherwise is probably better than the current code anyway. > See how BSD's kernel malloc (malloc.h, in particular) does it. > Fixed these already, but I'm not sure whether the hash changes have helped that much. I think two of the divs were caused by the use of % operators - anyway, one disappears by using a shift instead, and I tweaked the malloc code and got rid of the other. I'll take a look at the malloc stuff you mentioned - it looks a good idea. > Can you generate ASCII files from your analyzer trace? I'd be interested in > traces of a zero-length message exchange for: I'll see what I can do - I ought to at least be able to get at the dissassembled output and write a script to insert values. > I've Cc'ed the list as there appears to be some interest on performance > tuning. Regards, Dave From vandys@glare.cisco.com Thu Jan 19 12:32:52 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00798; Thu, 19 Jan 1995 12:32:51 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA18492; Thu, 19 Jan 1995 13:07:14 -0800 Message-Id: <199501192107.NAA18492@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com Subject: Re: Performance In-Reply-To: Your message of "Thu, 19 Jan 1995 10:27:01 -1000." Date: Thu, 19 Jan 1995 13:07:13 -0800 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] >I recently heard of an ISP that switched from NetBSD to Linux using the >same hardware. The users said that it ran slower under a twenty user >load than with NetBSD. Let's please not let this degenerate into a Linux versus NetBSD shouting match. The only reason I mentioned Linux was that it makes a fine stick in the sand. If we don't hit Linux's performance in some area, we can go look at how Linux does it, maybe get some good ideas. And fair is fair. If the Linux folks find good ideas in VSTa, I think all SW benefits from the synergy. Regards, Andy From vandys@glare.cisco.com Thu Jan 19 14:01:54 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00807; Thu, 19 Jan 1995 14:01:53 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA06015; Thu, 19 Jan 1995 14:36:07 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa11425; 19 Jan 95 20:29 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rV3Nb-0003HlC; Thu, 19 Jan 95 20:22 GMT Message-Id: From: Dave Hudson Subject: Re: Performance To: Greg Hudson Date: Thu, 19 Jan 1995 20:22:51 +0000 (GMT) Cc: VSTa mailing list , Andy Valencia In-Reply-To: <199501191850.NAA08412@glacier.MIT.EDU> from "Greg Hudson" at Jan 19, 95 01:50:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1286 Hi, Greg Hudson wrote: > > The problem is when you're hashing a lot of keys which happen to be > divisible by N, where N is a smallish number. If you're using a prime > modulus, this doesn't cause a problem, but if you're using a power of > 2 modulus and N is, say, 4, then you're only going to wind up using > 25% of your hash buckets. Hmm, this is something I've never looked at before, but having just quickly looked at a couple of references I think you've explained why I saw no real advantage from what I did with the hashing. > One solution is to use a multiplicative hashing function, as described > by Knuth on pp. 508-512 of volume 3 of _The Art of Computer > Programming_. The immediate problem I see is that with such a large multiplier we still end up executing a really expensive opcode (almost identical to the div), although I guess it may be faster for CPUs with no divide instruction. One thing that does spring to mind though is that if I analyse the keys we're using and ensure that they're sufficiently randomised for our purposes then we'll still get a good spread. I think I'll look at the current values ASAP. I know the current code makes an attempt at this with the shift and xor op, but perhaps the shift's no large enough say. Regards, Dave From vandys@glare.cisco.com Thu Jan 19 21:21:03 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA00828; Thu, 19 Jan 1995 21:21:01 -0800 Received: from titan.np.ac.sg (ngps@titan.np.ac.sg [153.20.24.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA26390 for ; Thu, 19 Jan 1995 21:55:26 -0800 Message-Id: <199501200555.VAA26390@hubbub.cisco.com> Subject: Cannot login on 1.3.2 To: vsta@cisco.com Date: Fri, 20 Jan 1995 13:52:19 +0800 (SST) From: Ng Pheng Siong Cc: ngps@np.ac.sg (Ng Pheng Siong) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 600 Hi. I have previously had VSTa running on my machine. Unfortunately it developed h/d problems, and I had to clean the disk. I've just downloaded and installed 1.3.2. Everything seems to start up fine until I try to login: just hangs. I have tried sh, testsh, and rc. I can ^Z to the debugger and reboot. Just to be sure I don't have bad binaries, here are checksums: SVR4 sum: 51937 113 sh FreeBSD cksum: 1746210383 57348 sh Where should I start looking? TIA. Cheers. - PS -- Ng Pheng Siong * ngps@np.ac.sg * (65) 460 6769 Computer Centre, Ngee Ann Polytechnic, Singapore From vandys@glare.cisco.com Thu Jan 19 21:42:29 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA00832; Thu, 19 Jan 1995 21:42:28 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id WAA26972; Thu, 19 Jan 1995 22:16:52 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rVCdX-000a0LC; Thu, 19 Jan 95 20:15 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Re: Performance To: vandys@cisco.com (Andrew Valencia) Date: Thu, 19 Jan 1995 20:15:55 -1000 (HST) Cc: newsham@aloha.net, vsta@cisco.com In-Reply-To: <199501192107.NAA18492@glare.cisco.com> from "Andrew Valencia" at Jan 19, 95 01:07:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 543 > >I recently heard of an ISP that switched from NetBSD to Linux using the > >same hardware. The users said that it ran slower under a twenty user > >load than with NetBSD. > > Let's please not let this degenerate into a Linux versus NetBSD shouting > match. I'm sorry if anyone got the wrong impression. I'm truly interested in an explanation. From everything I hear linux beats NetBSD hands down in a one-user environment. I was shocked when someone mentioned that under a 20user load it seemed faster. > Regards, > Andy From vandys@glare.cisco.com Fri Jan 20 05:18:35 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00887; Fri, 20 Jan 1995 05:18:33 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id FAA28318; Fri, 20 Jan 1995 05:52:37 -0800 Message-Id: <199501201352.FAA28318@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ng Pheng Siong Cc: vsta@cisco.com Subject: Re: Cannot login on 1.3.2 In-Reply-To: Your message of "Fri, 20 Jan 1995 13:52:19 +0800." <199501200555.VAA26390@hubbub.cisco.com> Date: Fri, 20 Jan 1995 05:52:37 -0800 From: Andrew Valencia [Ng Pheng Siong writes:] >I've just downloaded and installed 1.3.2. Everything seems to start >up fine until I try to login: just hangs. I have tried sh, testsh, >and rc. I can ^Z to the debugger and reboot. There's a bug with the permissions used to protect the namer entry fs/root. Make sure your account has sys.sys (1.1) access and you'll be able to login. This hit in 1.3.2 because the shared library loader needs to find the root filesystem to get the first-level library loader (/vsta/lib/ld.shl). Sorry for the problems, Andy From vandys@glare.cisco.com Fri Jan 20 06:34:08 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00898; Fri, 20 Jan 1995 06:34:07 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA23408 for ; Fri, 20 Jan 1995 07:08:31 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08237; 20 Jan 95 14:22 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rVIwv-0002mvC; Fri, 20 Jan 95 13:00 GMT Message-Id: From: Dave Hudson Subject: Re: Performance To: ghudson@MIT.EDU Date: Fri, 20 Jan 1995 13:00:21 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: from "dave" at Jan 19, 95 08:22:51 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1274 Hi again, dave wrote: > > Greg Hudson wrote: > > > > The problem is when you're hashing a lot of keys which happen to be > > divisible by N, where N is a smallish number. If you're using a prime > > modulus, this doesn't cause a problem, but if you're using a power of > > 2 modulus and N is, say, 4, then you're only going to wind up using > > 25% of your hash buckets. This statement deserves a virtual beer :-) > One thing that does spring to mind though is that if I analyse the keys > we're using and ensure that they're sufficiently randomised for our purposes > then we'll still get a good spread. I think I'll look at the current values > ASAP. I know the current code makes an attempt at this with the shift and > xor op, but perhaps the shift's no large enough say. I just looked at the portref hashing within the msg_reply() code and found that our portrefs are neatly aligned on 64 byte boundaries - oops! I've generated a slight patch to my non-dividing code that mangles the keys so that the portrefs now go in different places in the hash table and done a small tweak to the code in msg_reply(). My switch times are now down to 53 us from 54 on my DX/4 (compiled under gcc 1.42 - 2.6.2's good for another 4 or 5 us reduction). Regards, Dave From vandys@glare.cisco.com Fri Jan 20 06:35:39 1995 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00901; Fri, 20 Jan 1995 06:35:38 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA19068 for ; Fri, 20 Jan 1995 07:09:50 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08301; 20 Jan 95 14:22 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rVKCu-0002mwC; Fri, 20 Jan 95 14:20 GMT Message-Id: From: Dave Hudson Subject: A different performance measure To: VSTa mailing list Date: Fri, 20 Jan 1995 14:20:56 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1066 Hi All, After some discussions earlier this week about other ways context switch times can be measured I thought I ought to go and see how fast VSTa really is. I modified the perf1 code to use sched_yield() instead of the messaging engine (sched_yield() should be available in the next full release of VSTa). The code also runs in the "real-time" scheduler queue, which whilst it gets a higher priority than the normal timeshare mode seems slow for some reason (so I'll look into this as well now). Running with my DX/4-100 test system and a kernel built under gcc 1.42, this is now showing 15 us context switches :-) (measured over 1M switch ops). The same system with a DX/2-66 (not the same system I usually mention for a DX/2) shows 21 us. FWIW with this DX/2 system I get a perf1 figure of 75 us. As I was after the best figures though I recompiled under gcc 2.5.7 and scored 19.7 us on the DX/2 and 14.7 us on the DX/4 for the sched_yield() switch times. As I think has been mentioned there are lies, damn lies and benchmarks :-) Regards, Dave From vandys@glare.cisco.com Fri Jan 20 09:48:13 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00919; Fri, 20 Jan 1995 09:48:11 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA05174 for ; Fri, 20 Jan 1995 10:22:38 -0800 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id NAA24885; Fri, 20 Jan 1995 13:22:36 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA06867; Fri, 20 Jan 1995 13:23:00 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199501201823.AA06867@world.std.com> Subject: Re: A different performance measure To: vsta@cisco.com Date: Fri, 20 Jan 1995 13:23:00 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 923 Hi, First, I would like to congratulate Dave, Andy, and all others that have worked to reduce context switch times. This work should a very positive impact on overall system performance. [Dave Hudson writes] > Running with my DX/4-100 test system and a kernel built under gcc 1.42, this > is now showing 15 us context switches :-) (measured over 1M switch ops). > The same system with a DX/2-66 (not the same system I usually mention for a > DX/2) shows 21 us. FWIW with this DX/2 system I get a perf1 figure of 75 > us. perf1 attempts to measure the time to do a context switch + the time to send a message that doesn't contain any data. Now, the difference between the 21 us number and the 75 us number is awfully big. Is the 54 us difference totally due to the messaging overhead? Or perhaps the perf1/sched_yield() measuring something different that the old perf1? Mike Larson From vandys@glare.cisco.com Fri Jan 20 10:14:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00923; Fri, 20 Jan 1995 10:14:10 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA07000 for ; Fri, 20 Jan 1995 10:48:37 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA00110; Fri, 20 Jan 95 13:47:43 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA23680; Fri, 20 Jan 95 13:47:40 EST Received: from devserv.bedford.progress.COM (devserv-e4) by proserv.bedford.progress.COM (4.1/psc2.2) id AA25517; Fri, 20 Jan 95 13:47:38 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA23845; Fri, 20 Jan 95 13:47:37 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA04396; Fri, 20 Jan 95 13:47:35 EST Date: Fri, 20 Jan 95 13:47:35 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9501201347.ZM4394@crozet> In-Reply-To: Dave Hudson "A different performance measure" (Jan 20, 14:20) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Dave Hudson Subject: Re: A different performance measure Cc: vsta@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii The new numbers look a lot more reasonable! I just could not see how a context switch could take 100uS, except maybe on a 6-Mhz 80286. On a related point, I saw this note on comp.linux.development.system and thought I should pass it along: > From: pjensen@csi.compuserve.com (Phil Jensen) > Subject: code alignment - mod 16 vs mod 4 > Date: 19 Jan 1995 11:43:56 -0500 > > As this may affect kernel efficiency, I thought I'd ask: in my (Slackware) > 1.0.9 kernel, the compiler obviously used an alignment of 16, but the loader > used 4. So as you read through zSystem.map, for a while all the entry points > end in 4, then c, then 0... If 16-byte alignment is worth doing, it's worth > doing right - this way just wastes space. So I ask - is this still happening? > Another compilation thing - has anyone ever actually benchmarked kernel speed > with and without -fomit-frame-pointer? I haven't, but I've looked at SIZE, > which is about 3% LARGER with -fomit... Why? Every frame reference is one > byte longer (the "s-i-b" byte - necessary to get references off of %esp). I have seen a lot of applications compiled for Linux where -fomit-frame-pointer is a common optimization. Using s-i-b references are not particularly fast, especial as Intel applied various RISC optimizations which speed up the simple instructions (register-to-register, mem-displacement-to-register, and the like). Any of the complex indexing modes are penalized and tend to run slower. The joys of overlapped instruction execution and its associated lockout problems. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Sat Jan 21 07:37:10 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01078; Sat, 21 Jan 1995 07:37:09 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA27651 for ; Sat, 21 Jan 1995 08:02:30 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08605; 21 Jan 95 16:02 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rVheV-0003HCC; Sat, 21 Jan 95 15:22 GMT Message-Id: From: Dave Hudson Subject: Re: A different performance measure To: Mike Larson Date: Sat, 21 Jan 1995 15:22:59 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1658 Hi, Mike A Larson wrote: > > perf1 attempts to measure the time to do a context switch + the time to > send a message that doesn't contain any data. Now, the difference between > the 21 us number and the 75 us number is awfully big. Is the 54 us > difference totally due to the messaging overhead? Or perhaps the > perf1/sched_yield() measuring something different that the old perf1? Well, at least part of the difference is that with perf1 we enter kernel space 3 times as opposed to 2 for sched_yield(). In addition there's extra overhead since sched_yield() is really sched_op() called with a single parameter, whereas msg send, receive and reply take 2 each. Then we also have to look at the message mappings done within the kernel and the memory allocations used to manage these. Certainly one of the points I've looked at this week was the malloc work since these involve a fair amount of work deciding on which memory bucket to use. I think this is certainly something worthy of some speedup work - if we look at the debug version of malloc we already tell the kernel malloc which data we're allocating so maybe this can be used as a speedup hint. I think the main thing is that I've found no real design flaws, and that > 100% speedup is really lots of little things. Now I know how much overhead the messaging is placing on us it becomes easier to look for optimisations. I think the other point is that whilst context switch times are important we shouldn't loose sight of what they really give us - perhaps now would be a good time to port something like iozone and see how fast something more tangible really is. Regards, Dave From vandys@glare.cisco.com Sat Jan 21 07:29:31 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01075; Sat, 21 Jan 1995 07:29:29 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA27654 for ; Sat, 21 Jan 1995 08:02:54 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08634; 21 Jan 95 16:02 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rViAL-0003HDC; Sat, 21 Jan 95 15:55 GMT Message-Id: From: Dave Hudson Subject: Re: A different performance measure To: David Koogler Date: Sat, 21 Jan 1995 15:55:53 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9501201347.ZM4394@crozet> from "David Koogler" at Jan 20, 95 01:47:35 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4771 Hi, David Koogler wrote: > > The new numbers look a lot more reasonable! I just could not see how a context > switch could take 100uS, except maybe on a 6-Mhz 80286. As I just mentioned in my reply to Mike there's toom for improvement yet, but I think we have to keep a sense of proportion. When Mike tested a kernel for me last week on a 16MHz 386sx he saw a 1.4ms switch time drop to about 750us, but only improved throughput by 5-10% on file I/O. > On a related point, I saw this note on comp.linux.development.system and > thought I should pass it along: > > > From: pjensen@csi.compuserve.com (Phil Jensen) > > Subject: code alignment - mod 16 vs mod 4 > > Date: 19 Jan 1995 11:43:56 -0500 > > > > As this may affect kernel efficiency, I thought I'd ask: in my (Slackware) > > 1.0.9 kernel, the compiler obviously used an alignment of 16, but the loader > > used 4. So as you read through zSystem.map, for a while all the entry points > > end in 4, then c, then 0... If 16-byte alignment is worth doing, it's worth > > doing right - this way just wastes space. So I ask - is this still > happening? A lot of this is down to compile time switch settings. Linux is normally built with -m486 which 16 byte aligns functions and does some other 4 byte alignment. It also changes some of the frame handling opcodes since some code sequences are faster than others. This is basically as described in Appendix G of the 486 Programmer's Reference Manual. In reality this is not always a good thing, but on the whole leads to faster code (one of my earlier "optimised" kernels was actually 10% *slower* with -m486, but now it's about 4% faster). There's been quite a good discussion on some of these sort of points on comp.arch since I subscribed to it a week or so ago - basically padding functions makes them very easy to prefetch (a very big win on clock multiplied CPUs), but reduced the amount of real code in the L1 cache (a big loss). > > Another compilation thing - has anyone ever actually benchmarked kernel speed > > with and without -fomit-frame-pointer? I haven't, but I've looked at SIZE, > > which is about 3% LARGER with -fomit... Why? Every frame reference is one > > byte longer (the "s-i-b" byte - necessary to get references off of %esp). > > I have seen a lot of applications compiled for Linux where -fomit-frame-pointer > is a common optimization. Using s-i-b references are not particularly fast, > especial as Intel applied various RISC optimizations which speed up the simple > instructions (register-to-register, mem-displacement-to-register, and the > like). > Any of the complex indexing modes are penalized and tend to run slower. The > joys of overlapped instruction execution and its associated lockout problems. -fomit-frame-pointer is a huge win for small functions, but these are much better off being inlined anyway :-) It's also a win if we can do most things with register variables, but deciding which should and shouldn't be compiled this way is very difficult. As for speed, I rebuilt a kernel a couple of days ago with all files -fomit-frame-pointer and it was 5% slower than with the frame pointer there. Not that inlining is the answer to everything - on a 486 the worsened cache performance can actually lead to some horrendous CPU stalls while new code is prefetched. I've now got a couple of really good examples of where on a 486 it's appalling. As another general comment I think it is well worth considering the difference in initial design aims for say QNX or Linux against VSTa. VSTa set out to be ported to other architectures and with an initial design requirement to support SMP. I could easily create a very much faster VSTa kernel simply by limiting my ultimate goal to being a fast x86 single CPU O/S - immediately the mutexing code could be made much faster, and there'd be no messing around with per-cpu structures. In the long run, I think VSTa has a more appropriate design to cope with the systems that I expect we'll be seeing in the next few years. Just going off subject for a while, the laws of physics are rapidly getting to the stage where single CPUs will run out of steam, and even now I invariably have to consider the rather finite speed of electrons (approx 3-4 inches per ns in a PCB seems a good rule of thumb) when working on fast motherboards :-) Looking at things like the PCI bus spec, reflections are now assumed to be the norm rather than the result of poor design, and going to much wider buses gives little except increased silicon package costs and more complex (read more expensive) motherboards. Regards, Dave PS. If anyone wishes to comment on that last paragraph I think it would be better to take it off the mailing list (for now at least). From vandys@glare.cisco.com Sat Jan 21 12:28:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01098; Sat, 21 Jan 1995 12:28:45 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id NAA05218 for ; Sat, 21 Jan 1995 13:03:20 -0800 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id QAA13081; Sat, 21 Jan 1995 16:03:18 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA14080; Sat, 21 Jan 1995 16:03:44 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199501212103.AA14080@world.std.com> Subject: Re: A different performance measure To: vsta@cisco.com Date: Sat, 21 Jan 1995 16:03:43 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1139 Hi, Dave Hudson writes: >David Koogler wrote: >> >> The new numbers look a lot more reasonable! I just could not see how a context >> switch could take 100uS, except maybe on a 6-Mhz 80286. > >As I just mentioned in my reply to Mike there's toom for improvement yet, >but I think we have to keep a sense of proportion. When Mike tested a >kernel for me last week on a 16MHz 386sx he saw a 1.4ms switch time drop to >about 750us, but only improved throughput by 5-10% on file I/O. Note that this test measured the time to do sequential I/O to a file on a DOS filesystem. For this test, the time it takes to do an I/O is dominated by overheads other than the context switch time (eg., overheads associated with a relatively small I/O size). Still, it was nice to see a I/O performance improvement by just dropping in a new kernel (easy for me to say). Given a more highly tuned I/O system, however, the context switch time would likely take up a larger percentage of the total I/O time. In this case, improvements to context switch time would have a greater impact on I/O performance. Mike Larson From vandys@glare.cisco.com Sat Jan 21 15:21:37 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA01109; Sat, 21 Jan 1995 15:21:35 -0800 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA08981 for ; Sat, 21 Jan 1995 15:56:10 -0800 Received: from genesis.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA03020 (5.67b8/IDA-1.5 for ); Sat, 21 Jan 1995 17:55:47 -0600 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id RAA09728 for vsta@cisco.com; Sat, 21 Jan 1995 17:57:52 -0600 From: David Jeske Message-Id: <199501212357.RAA09728@genesis.isdn.uiuc.edu> Subject: A radical idea in OSs To: vsta@cisco.com Date: Sat, 21 Jan 1995 17:57:51 -0600 (CST) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4360 I would like to know what you all think of this idea. I would keep it all to myself and try to make a fortune off it (or just try it at least) but it occured to me that VSTa would probably be a good candidate for the base of something like this, and since VSTa is GPL, it would too be GPL, so here's the idea. Currently the world is huddled around DOS as an OS for 486 class PCs. Windows is also highly used. However, there are still applications which write for DOS directly because they want to get the full speed out of the machine. Mostly games, but not only games. Now, just forget for a moment the Microsoft juggernaut. Imagine a very bare bones 32bit operating system. One which provided basic functionality the way DOS does (or rather, how it should). One which provided standard ways to access all the items on your computer. The hard drive, keyboard, screen. However, it dosn't have to stop there. Sound drivers (or should i say servers) could easily handle sound in a unified way. This has already been done in Windows. Many people would rather write applications for Windows because the drivers are all already there. However, when one wants to write an app which does not use the Windows GUI, you lose EVERYTHING, you can't use WIndows sound drivers, or networking, or anything. Now, everyone is using this bare bones 32bit "microkernel" with servers loaded for a few things, like a BIOS hard drive driver (or a high performance one if one was available), a sound card driver, mouse driver. You get the picture. (yes, I know "ha ha, everyone is using it my ass." Just go with me here). Now you have the SAME microkernel which ships with a big UNIX compatible OS. You can run the SAME applications on it. you can run X, you have networking, you have everything. You have the support of the application vendors behind the "basic" 32bit version, but you get all the nice thrills of a real system. Now, you have one of the new Dual Pentium Machines. Down the hall they got one for a server, and you got jealous and bought one for youself. You run the SAME microkernel, and you can run the SAME applications as the guy across the street at your competitor (who your beating the pants off BTW) who can only afford a 386. Does this sound like a decent idea? I mean, if you forget that Microsoft practically owns the intel world for just a second... It dosn't stop there... Now that PowerPCs are going to be shipping soon (?? well.. somewhere in the near future) Everyone is going to be trying to go through the painstaking decision of whether to port to PowerPC. Luckily people porting to OS/2 for PPC from OS/2 for Intel probably will have a smooth ride. But nobody with DOS applications is going to bother, since OS/2 PPC users can already run them in emulation. But emulation stinks, we all know it. Everyone wants native applications. So you bought yourself a PPC machine, even though there were no applications out for it. You run the SAME microkernel (although admittedly, recompiled for PPC) as you did on the 386/40 and on the dual P90 machine. The guys down the street at XYZ software just recompiled and started shipping a PPC version. I'm sure you get the idea... Does this sound like something that is worth looking into? Obviously it is not something which is guaranteed to be feasable because there are too many "but DOS is everywhere" and "but Win95 is going to be good enough, even though you can't have full screen 32bit sessions" type arguments. A system like this could easily be built on a VSTa type microkernel, and if done right would be very easy to use at the low levels, and allow you to expand your system as necessary. Clearly VSTa is not at a point at which this is possible yet, and I'm sure many of you would rather tell people who run MSDOS where to go... It would not even have to be VSTa for that matter, but VSTa does have some important strong points for this. Portable, SMP, microkernel. What do you think? Please no flames.. if you think that Microsoft should own the world, or that they will no matter what we do.. please keep it to yourself. -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Sun Jan 22 07:18:29 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01176; Sun, 22 Jan 1995 07:18:27 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA06380 for ; Sun, 22 Jan 1995 07:53:01 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA27992; Sun, 22 Jan 1995 16:54:12 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA46826; Sun, 22 Jan 1995 16:54:00 +0100 Date: Sun, 22 Jan 1995 16:54:00 +0100 Message-Id: <9501221554.AA46826@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Problem with message system From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I ran into a serious problem with the message system. Assume I have a "normal" client / server interaction pending. If I kill the client process, the kernel generates a M_ABORT for the server. The sever answers and the client will receive the signal. If I kill the server the kernel ensures that all pending requests see an I/O error. But I have a thread acting as a server for threads of the same process. If I kill the process I see no way to ensure that all pending requests get rolled back. Thus my process works fine except I try to kill it. Then it'll hang forever. Any idea how to solve that? A second question: While I see (at the moment) no solution for the above I can't exit my process in a really clean way anyway. I tried to notify() the client threads (which correctly generates the M_ABORT) then wait until they are gone and then notify() the server thread. Unfortunatly I'm either to stupid to call wait_pid() correct or it doesn't work right. Anyway if I call wait_pid() it immediately returns. Thus I'm going to kill the server thread before all the M_ABORT's are done:-( Currently I just sleep() for 2 seconds after the wait_pid() to give them a chance, but that's certainly not the solution I'm looking for. Here the essential code snippet: long t=tfork(somthing); ... notify(0,t,EKILL); wait_pit(????); Any help appreciated. Thanx /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Sun Jan 22 07:48:05 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01180; Sun, 22 Jan 1995 07:48:04 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA21157; Sun, 22 Jan 1995 08:22:43 -0800 Message-Id: <199501221622.IAA21157@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com Subject: Re: Problem with message system In-Reply-To: Your message of "Sun, 22 Jan 1995 16:54:00 +0100." <9501221554.AA46826@ibch01.inf.tu-dresden.de> Date: Sun, 22 Jan 1995 08:22:42 -0800 From: Andrew Valencia [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] >But I have a thread acting as a server for threads of the same process. >If I kill the process I see no way to ensure that all pending requests >get rolled back. Thus my process works fine except I try to kill it. >Then it'll hang forever. I don't think you've found the real problem yet. The networking daemon uses the same technique, and work OK. I bet if you do a "ps" after you kill the process, you'll see the process still there with "nthread" reduced by one. Kill it again, and I bet "nthread" goes down by another. When you get all the threads, I bet you'll see the process exit. >A second question: While I see (at the moment) no solution for the >above I can't exit my process in a really clean way anyway. I tried >to notify() the client threads (which correctly generates the M_ABORT) >then wait until they are gone and then notify() the server thread. >Unfortunatly I'm either to stupid to call wait_pid() correct or it >doesn't work right. Anyway if I call wait_pid() it immediately >returns. Thus I'm going to kill the server thread before all the >M_ABORT's are done:-( Currently I just sleep() for 2 seconds after the >wait_pid() to give them a chance, but that's certainly not the >solution I'm looking for. There certainly could be a bug in the waitpid() code--there used to be, in any case. If you can find a line: *ip = encode(ep); Instead of the line: *ip = encode(&e); Then patch it to the latter. Otherwise I guess it's a new bug. Another way to handle this is to use the waits() system call directly (instead of through POSIX emulation). This'll at least tell you if it's the wait/waitpid emulation, or a problem with the underlying process death handling. Andy From vandys@glare.cisco.com Sun Jan 22 08:00:36 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01184; Sun, 22 Jan 1995 08:00:35 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA21331; Sun, 22 Jan 1995 08:35:14 -0800 Message-Id: <199501221635.IAA21331@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: brtmac@ksu.ksu.edu Cc: vsta@cisco.com Subject: Re: VSTa networking questions In-Reply-To: Your message of "Thu, 15 Dec 1994 13:11:30 CST." <9412151911.AA13618@mort> Date: Sun, 22 Jan 1995 08:35:14 -0800 From: Andrew Valencia [brtmac@ksu.ksu.edu writes:] >Okay, I finally got my hands on an ne2000 clone card. It works fine >with DOS packet drivers. The ne server recognizes it and it appears >to be working. I can mount the server on /net and do: > cat /net/0 >or > cat /net/800 >and it starts spitting things out, so I'm assuming that it's working >at least somewhat. Hi, sorry for the delay in answering. I'm just now catching up on my "todo" list for VSTa. Anyway, yes, it looks like your card is healthy. >My question is, what to do from here? I've tried running 'net', the >ka9q stuff, but can't seem to figure out the magic set of commands to >get it to do anything. Can someone tell me how to configure it to talk >to the ne server? Mount the card on /dev/eth. Now enter the commands: attach eth eth0 1500 ip addr 198.92.29.53 route add default eth0 host baruk domain suffix cisco.com domain addserver 131.108.1.111 (put in your own IP address, domain nameserver, hostname, and domain name) You can also put this stuff in a file and then start "net" with the filename as an argument. >Second, what is the status of the TCP/IP server? Is it in a working >state at all? I wouldn't mind doing some debugging if I can get some >source to play with. I don't quite feel like reinventing the wheel >though. It works well enough to telnet and ftp around. It has a bug quitting from ftp mode, so you can consider it "operational/buggy". It also desperately needs to offer a /net/{tcp,icmp,udp} service so it can be used as a general networking resource. I started coding this but it has a ways to go. >One final question, which doesn't really have to deal with networking >in particular. How does the kernel decide who can access io ports? >I was able to run the ne server while logged with with ids: > 3.101(101), 1.1(101) >I haven't quite got ids and capabilities totally figured out yet, though >I've got the basics figured out okay. However, it would seem to me that >only should be able to access io ports. Well, root *could* access the I/O ports, but only because "root" is somebody with a zero-length ability, which dominates sys.sys (1.1) and he thus gets anything which anybody else would get. See isroot() and issys() in os/kern/misc.c (and that will lead you over to libc/permsup.c). Andy From vandys@glare.cisco.com Mon Jan 23 19:54:33 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01401; Mon, 23 Jan 1995 19:54:32 -0800 Received: from sole.cs.washington.edu (sole.cs.washington.edu [128.95.2.95]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id UAA08997 for ; Mon, 23 Jan 1995 20:29:21 -0800 Received: from localhost (localhost [127.0.0.1]) by sole.cs.washington.edu (8.6.9/7.2ws+) with SMTP id UAA15469; Mon, 23 Jan 1995 20:29:19 -0800 To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: A radical idea in OSs In-Reply-To: Your message of "Sat, 21 Jan 1995 17:57:51 CST." <199501212357.RAA09728@genesis.isdn.uiuc.edu> Date: Mon, 23 Jan 1995 20:29:17 PST Message-Id: <15467.790921757@sole.cs.washington.edu> From: Chris Maeda Date: Sat, 21 Jan 1995 17:57:51 CST To: vsta@cisco.com From: David Jeske Subject: A radical idea in OSs Does this sound like a decent idea? I mean, if you forget that Microsoft practically owns the intel world for just a second... It's a great idea. People have been trying to do this for years. Unfortunately, no one is very successful for the very reason that you would rather ignore. People buy OS's to run applications. No one will buy VSTa until there is a substantial base of applications that you can run on it. But no one will port to VSTa until there is a substantial installed base who are willing to pay money for application software. An obvious way around this is to be binary compatible with a large number of applications (IBM's strategy for OS/2) so that porting is not required. For example, the ability to run Win32 apps on VSTa would be worth some money. However I doubt any of us could muster the resources required to achieve it. Chris Maeda From vandys@glare.cisco.com Fri Jan 27 06:00:59 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00479; Fri, 27 Jan 1995 06:00:58 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA28945 for ; Fri, 27 Jan 1995 06:36:59 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa25080; 27 Jan 95 14:35 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rXrpZ-0003EjC; Fri, 27 Jan 95 14:39 GMT Message-Id: From: Dave Hudson Subject: More performance notes.. To: VSTa mailing list Date: Fri, 27 Jan 1995 14:39:21 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2094 Hi All, I thought I'd just mention where I'm up to with the kernel optimisations. I've now got the context switch time as measured by perf1 on my DX/4 cached system down to 51 us under gcc 1.42 (although 2.6.2 doesn't actually help that much - sometimes it produces slower executing code on a 486 :-)). I've also clobbered a couple of minor problems with the kernel debugger and the kernel print routines. David Koogler mailed me a port of IOzone which I've modified slightly (just the timings, not the tests). I compared results on my system between the standard 1.3.2 kernel and the one I now have. My 2.5" drive doesn't have any write cache, and only 8k of read cache, so it's not what it could be, but here are some fairly representative results (only difference is the kernel - note k/s is 1000 bytes per sec, not 1024 bytes per sec): v1.3.2 standard: Test file size Record size Write rate Read rate 1 MB 512 98k/s 455k/s 1 MB 1024 99k/s 537k/s 1 MB 4096 101k/s 635k/s 1 MB 32768 109k/s 676k/s 1 MB 65536 109k/s 537k/s <- ??? 8 MB 512 77k/s 551k/s 8 MB 1024 78k/s 696k/s 8 MB 4096 78k/s 847k/s 8 MB 32768 80k/s 887k/s 8 MB 65536 80k/s 687k/s < - ??? New faster kernel: Test file size Record size Write rate Read rate 1 MB 512 101k/s 599k/s 1 MB 1024 103k/s 676k/s 1 MB 4096 103k/s 748k/s 1 MB 32768 109k/s 748k/s 1 MB 65536 109k/s 723k/s 8 MB 512 78k/s 776k/s 8 MB 1024 79k/s 911k/s 8 MB 4096 79k/s 1004k/s 8 MB 32768 80k/s 1010k/s 8 MB 65536 80k/s 1010k/s To be fair, the 1.3.2 standard kernel has debugging turned on - with debugging on in my kernel the results are somewhere on the positive side, in-between - here are some results: Test file size Record size Write rate Read rate 1 MB 512 101k/s 537k/s 1 MB 1024 102k/s 635k/s 1 MB 4096 104k/s 699k/s 1 MB 32768 110k/s 748k/s 1 MB 65536 113k/s 635k/s < - ??? Anyway, I know there's still room for improvement in the kernel, but I think maybe finding ways of speeding up the dos and wd servers might be a good idea now :-) Regards, Dave From vandys@glare.cisco.com Mon Jan 30 10:41:12 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01028; Mon, 30 Jan 1995 10:41:10 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA26337 for ; Mon, 30 Jan 1995 11:17:34 -0800 Message-Id: <199501301917.LAA26337@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Next release Date: Mon, 30 Jan 1995 11:17:33 -0800 From: Andrew Valencia I'm very close to a maintenance release of VSTa, it's down to a single DOS filesystem corruption bug I'm chasing. When I nail that, I'll drop out a 1.3.3, and will promptly begin assembling Dave's performance work, swap enhancements, POSIX enhancements, and a bunch of FSF ports for 1.4. Regards, Andy From vandys@glare.cisco.com Mon Jan 30 10:29:25 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01024; Mon, 30 Jan 1995 10:29:24 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA08608 for ; Mon, 30 Jan 1995 11:05:41 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa13274; 30 Jan 95 17:33 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rZ04I-00036vC; Mon, 30 Jan 95 17:39 GMT Message-Id: From: Dave Hudson Subject: More performance comments.. To: VSTa mailing list Date: Mon, 30 Jan 1995 17:39:14 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2027 Hi All, I thought I'd report the latest performance results I've acheived, and mention a couple of things I found over the weekend. I now have perf1 showing 47 microseconds, and my perf2 (sched_yield based) code showing around 13 microseconds per context switch on my cached DX/4-100 system. This is with a kernel built under gcc 2.5.7 and Linux. IOzone is showing a speedup of around 1% on writes and 6% on reads for the 1MByte file test. I've optimised a few more code sequences (which should help all CPUs), but I realised two things about the 486 stuff I've been working on: 1) Better results come from statically linked test programs (should have been obvious really), although the results I've quoted are all for dynamically linked code. 2) GNU C and GNU ld don't seem to get 486 code alignment right :-( This one is something that might prove interesting for some of the other free 486 O/S's (I've already verified the same problem under Linux, gcc-2.6.2 and binutils-2.5.2). Basically, the 486 needs function entry points to be cache-line aligned (16 bytes) to save potential prefetch stalls. gcc 2.x inserts ".align 4" directives to achieve this, and the resulting object files are thus aligned correctly. Unfortunately it doesn't ensure that the text sizes of the object files are also 16 byte aligned. When ld links the code it concatenates the text spaces of the object files and thus gives unaligned executables (on a recent Linux kernel I found that "cat /proc/ksyms" say, shows function alignments on 4 byte boundaries, not 16). In my testing I've found poor alignment can cost 5 or 6 microseconds on a DX/2-66 running perf1. For now I've got round the problem by adding a 16 byte static function at the end of all of my kernel files to guarantee the alignment of the object files. FWIW at the moment this is only relevant to cross-compiled code as gcc 1.42 doesn't do 486 code generation, but all of my code will still build native under VSTa (it's just not quite as fast). Regards, Dave From vandys@glare.cisco.com Mon Jan 30 12:12:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01046; Mon, 30 Jan 1995 12:12:54 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA15624 for ; Mon, 30 Jan 1995 12:49:18 -0800 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id MAA01195; Mon, 30 Jan 1995 12:49:02 -0800 Message-Id: <199501302049.MAA01195@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Mon, 30 Jan 1995 12:49:02 PST In-Reply-To: Dave Hudson ' More performance comments.. Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Dave Hudson , VSTa mailing list Subject: Re: More performance comments.. From: Dave Hudson Subject: More performance comments.. > 2) GNU C and GNU ld don't seem to get 486 code alignment right :-( This one > is something that might prove interesting for some of the other free 486 The assembler should be padding the section out to a multiple of 16 bytes, when .align 4 is specified and an object file format is used that doesn't include a section alignment field in its headers. Howdy. Dave, here's the ansswer I got back from the GAS maintainer. You found a bug! :-) I'll post the patch when I get it. Just as a note, starting with what will be GCC 2.7.0, (possibly earlier) all the code to build a VSTa native or cross compiler is part of the FSF's net release. I managed to get all the patches approved. - rob - From vandys@glare.cisco.com Mon Jan 30 14:47:55 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01073; Mon, 30 Jan 1995 14:46:24 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA25919 for ; Mon, 30 Jan 1995 15:22:47 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rZ5OW-000ZzTC; Mon, 30 Jan 95 13:20 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Re: VSTa To: kjetilja@stud.cs.uit.no (Kjetil Jacobsen) Date: Mon, 30 Jan 1995 13:20:28 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <199501301324.AA152362284@tklab4.cs.uit.no> from "Kjetil Jacobsen" at Jan 30, 95 02:24:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 480 > Hello. > > cards, and I'd really like to see VSTa running on one of these. Would > it be possible to have the current 030 source-tree (preferably ftp) so > I could try to get it compiled (and, sometime, perhaps running). I > believe people here could make some valuable contributions to the > porting itself, too. I have put up a snapshot of my source tree for ftp: ftp.aloha.net:/users/newsham/vsta.tar.gz > /kjetil/ enjoy. Tim N. From vandys@glare.cisco.com Tue Jan 31 11:02:51 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01203; Tue, 31 Jan 1995 11:02:50 -0800 Received: from mercan.cmpe.boun.edu.tr (arslan@mercan.cmpe.boun.edu.tr [193.140.196.80]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA28685 for ; Tue, 31 Jan 1995 11:39:10 -0800 From: arslan@mercan.cmpe.boun.edu.tr Received: (from arslan@localhost) by mercan.cmpe.boun.edu.tr (8.6.9/8.6.9) id VAA04108; Tue, 31 Jan 1995 21:43:35 +0300 Date: Tue, 31 Jan 1995 21:43:35 +0300 Subject: How can I boot Vsta from Linux. To: Vsta mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi ,, I am using Linux OS ,but I am interested of Operating systems as a whole so I want to look at Vsta OS.BUt there is a problem I do not have DOS(and I can not simply install dos -some tehnical problems ..-) Can I boot vsta from Linux or better Can I boot Vsta directly from a boot manager ?? Please help me ... Gunay Arslan. From vandys@glare.cisco.com Tue Jan 31 19:22:24 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01244; Tue, 31 Jan 1995 19:22:23 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id TAA08650; Tue, 31 Jan 1995 19:58:54 -0800 Message-Id: <199502010358.TAA08650@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: booting from DOS 6.2 In-Reply-To: Your message of "Tue, 31 Jan 1995 22:52:01." <199502010352.AA18391@world.std.com> Date: Tue, 31 Jan 1995 19:58:53 -0800 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >What does the following message mean? > Must be in REAL mode (not V86) to boot VSTa >I get the message when I try to boot VSTa from DOS 6.2. Booting >VSTa from DOS 3.2 doesn't have this problem. It usually means you have emm386 active. emm386 runs the CPU in V86 mode so it can do tricks like remapping pages, but V86 mode keeps VSTa from being able to take over the hardware, so the boot loader bails if it detects this situation. Andy From vandys@glare.cisco.com Tue Jan 31 19:17:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01241; Tue, 31 Jan 1995 19:17:45 -0800 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA26973 for ; Tue, 31 Jan 1995 19:53:34 -0800 Received: from world.std.com by relay1.UU.NET with SMTP id QQybdn26711; Tue, 31 Jan 1995 22:52:53 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18391; Tue, 31 Jan 1995 22:52:01 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199502010352.AA18391@world.std.com> Subject: booting from DOS 6.2 To: vsta@cisco.com Date: Tue, 31 Jan 1995 22:52:01 +73900 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 230 Hi, What does the following message mean? Must be in REAL mode (not V86) to boot VSTa I get the message when I try to boot VSTa from DOS 6.2. Booting VSTa from DOS 3.2 doesn't have this problem. Thanks. Mike Larson From vandys@glare.cisco.com Sat Feb 4 11:00:03 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01875; Sat, 4 Feb 1995 11:00:02 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA21084 for ; Sat, 4 Feb 1995 11:36:55 -0800 Message-Id: <199502041936.LAA21084@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: VSTa v1.3.3 now available Date: Sat, 04 Feb 1995 11:36:54 -0800 From: Andrew Valencia Hi, folks. I found my filesystem bug (an optimization which broke if you truncated a file and then grew it out to its exact same length, and your allocated block chain was different than before). So v1.3.3 is now available on ftp.cisco.com in vandys/vsta, and presumably on its mirrors soon. It has fixes for some shared library bugs, a couple optimizations, command line editing for canonical input mode, ~/~user path handling, and various and sundry other goodies. See the doc/features.txt file for an attempt at a list of these changes. Most of Dave Hudson's performance enhancements will appear in 1.4, as will the rest of his POSIX enhancements. Maybe I'll shoot to get more networking running for 1.4. Mike Larson's tape driver is also targeted for 1.4. Enjoy! Andy Valencia From vandys@glare.cisco.com Sun Feb 5 11:51:14 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01989; Sun, 5 Feb 1995 11:51:13 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA23821 for ; Sun, 5 Feb 1995 12:28:12 -0800 Message-Id: <199502052028.MAA23821@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: ftp.cisco.com sick Date: Sun, 05 Feb 1995 12:28:12 -0800 From: Andrew Valencia Our anonymous FTP server here appears to be sick. I've pushed the distribution out to ftp.crystald.com:incoming/vandys for those who are having trouble reaching the regular site. Andy From vandys@glare.cisco.com Sun Feb 5 22:47:02 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA02051; Sun, 5 Feb 1995 22:47:00 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA10859 for ; Sun, 5 Feb 1995 23:24:02 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rbNna-000a0qC; Sun, 5 Feb 95 21:23 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: seperate of bins and source To: vsta@cisco.com (VSTa Mailing List) Date: Sun, 5 Feb 1995 21:23:50 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 526 Hi, Each time I download vsta I have to remove all the binaries from the sources (since I dont need them and dont have the space for them). This is much harder since the files are all mixed in with the sources. Could we seperate sources from binaries? I already have my sources seperated from my binaries as: boot/binaries -> boot.bin (?) libc/*.a -> lib bin.src -> bin it might even be nicer to have sources in a seperate tree but this probably makes developing harder. Tim N. From vandys@glare.cisco.com Mon Feb 6 11:15:17 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA02263; Mon, 6 Feb 1995 11:15:16 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA17893 for ; Mon, 6 Feb 1995 11:52:17 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA01951; Mon, 6 Feb 95 14:52:15 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA18547; Mon, 6 Feb 95 14:52:13 EST Received: from devserv.bedford.progress.COM (devserv-e3) by proserv.bedford.progress.COM (4.1/psc2.2) id AA22703; Mon, 6 Feb 95 14:52:12 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA10321; Mon, 6 Feb 95 14:52:11 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA01294; Mon, 6 Feb 95 14:52:10 EST Date: Mon, 6 Feb 95 14:52:10 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9502061452.ZM1292@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: VSTa 1.33 Hangs During Booting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii When trying to boot version 1.33, the basic servers (cons, wd, and dos) come up and announce themselves through syslog. However, things seem to hang when init starts running. In my previous attempt with an out-of-the-box boot with version 1.32, I had the same sort of hang. By recompiling all of the binaries which used shared libraries, I managed to get everything up and running. As a quick check, I substituted the version 1.32 init and rebooted. It did try to bring up the other servers (tmpfs, nulldev, runrc, etc.) but the system hung up with every process in the SLEEP state. Note that I have not got to a login, so it can't be the sys.sys problem. I can continue on by recompiling everything with static libraries, but something is wrong. Any ideas? -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Mon Feb 6 12:41:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02278; Mon, 6 Feb 1995 12:41:45 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA23212 for ; Mon, 6 Feb 1995 13:18:48 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA04329; Mon, 6 Feb 95 16:18:40 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA20863; Mon, 6 Feb 95 16:18:39 EST Received: from devserv.bedford.progress.COM (devserv-e2) by proserv.bedford.progress.COM (4.1/psc2.2) id AA26260; Mon, 6 Feb 95 16:18:38 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA11119; Mon, 6 Feb 95 15:49:42 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA01300; Mon, 6 Feb 95 15:49:41 EST Date: Mon, 6 Feb 95 15:49:41 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9502061549.ZM1298@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Boot problem with VSTa 1.33 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ooops! My problem turns out to be my brain! I did not set up a /vsta/lib directory containing the shared library images. When a process, linked with shared library attempts to run, it can't find the library loader and/or the library image. It looks like a minimal VSTa system needs /vsta/boot, /vsta/bin, /vsta/etc, and /vsta/lib. Now, to go on and find some real bugs...:-> -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Tue Feb 7 10:14:31 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02415; Tue, 7 Feb 1995 10:14:29 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA06710 for ; Tue, 7 Feb 1995 10:51:30 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA19322; Tue, 7 Feb 1995 19:53:00 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA36188; Tue, 7 Feb 1995 19:53:50 +0100 Date: Tue, 7 Feb 1995 19:53:50 +0100 Message-Id: <9502071853.AA36188@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Problem with v133 From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, just downloaded version 1.3.3 but I can't boot it. On first attempt init complained to be unable to open /vsta/etc/inittab, boot process 8 died and I found myself droped into the kernel debugger. Thus I changed boot.lst to lauch the testsh. Then I successfully mounted 1 on /namer found fs/root to be 1025 and mounted it on /. Now I did an ls, works. cd'd to vsta, ls, works. But whenever I cd into a second subdir and do an ls there the dos server dies. Any idea? /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Tue Feb 7 10:52:20 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02422; Tue, 7 Feb 1995 10:52:18 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA04913; Tue, 7 Feb 1995 11:29:27 -0800 Message-Id: <199502071929.LAA04913@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: vsta@amri.cisco.com Subject: Re: VSTa v1.3.3 now available In-Reply-To: Your message of "Tue, 07 Feb 1995 10:10:18 PST." Date: Tue, 07 Feb 1995 11:29:26 -0800 From: Andrew Valencia [agc@uts.amdahl.com (Alistair G. Crooks) writes:] >1. There's a bug in ar which truncates the time - the fix is: >/vsta/bin.src/binutl/ar.c >575c575 >< printf (" %2d/%2d %6d %12.12s %4.4s %s\n", >--- >> printf (" %2d/%2d %6d %12.12s %5.5s %s\n", Hmm, I'll take a look at this tonight. >2. Most of the Makefiles I could find reference ../../libc/crt0.o >which for me doesn't exist - the only one I could find was in ../../lib/crt0.o Yes, the source tree builds from source. So you need to build the library source (which includes crt0.o) in libc/ before you build servers which would link in the C library. >3. How do I interrupt a command (this is in the sh)? Neither control-c >or delete seem to work for me. You use the terminal monitor. Which isn't written. :-( We had hoped this would be an application under MADO (the windowing system). >4. When I log in, the password is echoed as asterisks. This is occasionally >an asterisk for every character typed, but usually an asterisk for every >character typed so far. I haven't had time to look into this yet. It *should* be a random number of *'s per character. It was an amusing feature from Plato which I brought over since I was writing login from scratch anyway. >5. I've brought over the xargs, m4, and tr commands from NetBSD. If there's >any interest in these, I can put them up for ftp. I wanted tr working so that >I can run the configure scripts produced by autoconf, so that I can get more >things working under vsta. Yes, I'll be happy to add them to the ported software archive. >Please don't take these comments as criticism. I really like vsta, and can >see the distance it's come since I first got a hold of 1.0. Thanks! >As a side note - I'm visiting the Bay Area at the moment - if there are any >vsta people who would like to get together and swap horror stories, and just >generally chat, drop me a line. I work down in San Jose weekdays, and live in San Mateo. If you're over in the Amdahl sprawl in Santa Clara then you're very close by. Let's swing onto E-mail to plan something. You can see my "primary development machine"--a 2.94 pound subnotebook. :-) Regards, Andy From vandys@glare.cisco.com Tue Feb 7 10:46:59 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02419; Tue, 7 Feb 1995 10:46:58 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA04594; Tue, 7 Feb 1995 11:24:07 -0800 Message-Id: <199502071924.LAA04594@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com Subject: Re: Problem with v133 In-Reply-To: Your message of "Tue, 07 Feb 1995 19:53:50 +0100." <9502071853.AA36188@ibch01.inf.tu-dresden.de> Date: Tue, 07 Feb 1995 11:24:07 -0800 From: Andrew Valencia [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] >Now I did an ls, works. cd'd to vsta, ls, works. But whenever I cd >into a second subdir and do an ls there the dos server dies. You need to gather a stack backtrace of the DOS server, along with the output of "tf". Obviously, I was able to cd down multiple levels of directories, so it's not a generic problem. Andy From vandys@glare.cisco.com Tue Feb 7 11:38:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA02430; Tue, 7 Feb 1995 11:38:08 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA12813 for ; Tue, 7 Feb 1995 12:15:11 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rbwJN-000a1BC; Tue, 7 Feb 95 10:14 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: to Dave Hudson To: vsta@cisco.com (VSTa Mailing List) Date: Tue, 7 Feb 1995 10:14:57 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 14999 I don't have Dave Hudson's email address handy. Sorry for posting this to everyone. The two files included have the implementation of the interpretted ISR routines I am using. Dave, I forgot to include those two files at the end of the response. Here they are. Tim N. # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # isr.c # isr.h # echo x - isr.c sed 's/^X//' >isr.c << 'END-of-isr.c' X X/* X * isr.c X * Routines for connecting interrupts to the messaging interface X */ X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X Xextern volatile struct CIA *CIAAbase, *CIABbase; Xextern volatile struct Custom *CUSTOMbase; X X/* X * Per-IRQ information on who to call when an IRQ is entered X */ Xstruct isr_msg { X struct port *i_port; X struct sysmsg i_msg; X}; Xstatic struct isr_msg handler[MAX_ISR]; Xchar handlers[MAX_ISR]; Xulong strayintr = 0, dupintr = 0; X X/* X * ISR-routine tables X */ X#define NUM_ISR_ROUTINES 8 X#define ISR_PORTS_TAB 0 X#define ISR_EXTER_TAB 1 X#define NUM_ISR_TABLES 2 X#define isr_to_tab(x) ((x) == ISR_PORTS ? ISR_PORTS_TAB : ISR_EXTER_TAB) X#define tab_to_isr(x) ((x) == ISR_PORTS_TAB ? ISR_PORTS : ISR_EXTER) X Xstruct isr_routine { X struct port *i_port; X struct sysmsg i_msg; X u_int *code; X}; Xstatic struct isr_routine routines[NUM_ISR_TABLES][NUM_ISR_ROUTINES]; X X/* X * masks of enabled interupts. start off with all disabled X */ Xushort custom_mask = 0x0000; Xushort ciaa_mask = 0x00; Xushort ciab_mask = 0x00; X X/* X * Mask determining who can do these sort of operations X */ X#define IOPRIV_ISR (1) /* Can vector ISR's */ X#define IOPRIV_IO (2) /* Can do I/O instructions */ Xstruct prot io_prot = { X 2, X 0, X {1, 1}, X {0, IOPRIV_ISR | IOPRIV_IO} X}; X X/* X * isr_interupts() X * Turn on/off Interupts for an ISR X * X * keep the interupt masks updated. X * XXX should we use a table instead? X */ Xisr_interrupts(int isr, int on) X{ X unsigned char ciabit; X unsigned long intena; X X switch(isr) { X case ISR_TBE: intena = INTF_TBE; break; X case ISR_DSKBLK: intena = INTF_DSKBLK; break; X case ISR_SOFTINT: intena = INTF_SOFTINT; break; X case ISR_PORTS: intena = INTF_PORTS; break; X X /* CIA A */ X case ISR_A_TA: X case ISR_A_TB: X case ISR_A_ALARM: X case ISR_A_SP: X case ISR_A_FLG: X ciabit = 1 << (isr - ISR_A_TA); X if(on) { X ciabit |= CIA_ICR_IR_SC; X ciaa_mask |= ciabit; X } else X ciaa_mask &= ~ciabit; X CIAAbase->icr = ciabit; X intena = INTF_PORTS; X break; X X case ISR_BLIT: intena = INTF_BLIT; break; X case ISR_COPER: intena = INTF_COPER; break; X case ISR_VERTB: intena = INTF_VERTB; break; X case ISR_AUD0: intena = INTF_AUD0; break; X case ISR_AUD1: intena = INTF_AUD1; break; X case ISR_AUD2: intena = INTF_AUD2; break; X case ISR_AUD3: intena = INTF_AUD3; break; X case ISR_RBF: intena = INTF_RBF; break; X case ISR_DSKSYNC: intena = INTF_DSKSYNC; break; X case ISR_EXTER: intena = INTF_EXTER; break; X X /* CIA B */ X case ISR_B_TA: X case ISR_B_TB: X case ISR_B_ALARM: X case ISR_B_SP: X case ISR_B_FLG: X ciabit = 1 << (isr - ISR_B_TA); X if(on) { X ciabit |= CIA_ICR_IR_SC; X ciab_mask |= ciabit; X } else X ciab_mask &= ~ciabit; X CIABbase->icr = ciabit; X intena = INTF_EXTER; X break; X X case ISR_NMI: /* not maskable */ X break; X } X X if(on) { X intena |= INTF_SETCLR; X custom_mask |= intena; X } else X custom_mask &= intena; X CUSTOMbase->intena = intena; X} X X/* X * enable_isr() X * Connect an ISR to a port X */ Xenable_isr(port_t arg_port, int isr) X{ X struct sysmsg *sm; X struct port *port; X int error = 0; X struct proc *p = curthread->t_proc; X extern struct port *find_port(); X X /* X * Check for permission X */ X if (!issys()) { X return(-1); X } X X /* X * Validate port, lock it X */ X port = find_port(p, arg_port); X if (!port) { X return(-1); X } X X /* X * Check ISR #, make sure the slot's available X * note: ISR_PORTS and ISR_EXTER are special X */ X if ((isr < 0) || (isr >= MAX_ISR) || X (isr == ISR_PORTS) || (isr == ISR_EXTER)) { X error = err(EINVAL); X goto out; X } X if (handlers[isr]) { X error = err(EBUSY); X goto out; X } X X /* X * Initialize the message X */ X sm = &handler[isr].i_msg; X sm->m_op = 0; X sm->m_nseg = sm->m_arg = sm->m_arg1 = 0; X sm->m_sender = 0; X X /* X * Put it in the handler slot X */ X handler[isr].i_port = port; X X /* X * Flag port as having an IRQ handler X */ X port->p_flags |= P_ISR; X handlers[isr] = 1; X X /* X * Enable this interrupt vector X */ X isr_interrupts(isr, 1); X Xout: X v_lock(&port->p_lock, SPL0); X v_sema(&port->p_sema); X return(error); X} X X/* X * enable isr and install an isr routine X */ Xenable_isr_routine(port_t arg_port, int isr, void *code, int len) X{ X struct sysmsg *sm; X struct port *port; X struct isr_routine *table; X int i, error = 0; X struct proc *p = curthread->t_proc; X extern struct port *find_port(); X X /* X * Check for permission X */ X if (!issys()) { X return(-1); X } X X /* X * Validate port, lock it X */ X port = find_port(p, arg_port); X if (!port) { X return(-1); X } X X /* X * get table X */ X if(isr != ISR_PORTS && isr != ISR_EXTER) { X error = err(EINVAL); X goto out; X } X table = routines[isr_to_tab(isr)]; X X /* X * find empty slot in table X */ X for(i = 0; i < NUM_ISR_ROUTINES; i++) { X if(table[i].code == 0) X break; X } X if(i == NUM_ISR_ROUTINES) { X error = err(EBUSY); X goto out; X } X X /* X * copy in the code X */ X table[i].code = (u_int *)MALLOC(len * 4, 0); /* XXX type */ X if(copyin(code, table[i].code, len * 4)) { X FREE(table[i].code, 0); /* XXX type */ X table[i].code = 0; X error = err(EFAULT); X goto out; X } X X /* X * Initialize the message X */ X sm = &table[i].i_msg; X sm->m_op = 0; X sm->m_nseg = sm->m_arg = sm->m_arg1 = 0; X sm->m_sender = 0; X X /* X * hook up the port X */ X table[i].i_port = port; X X /* X * Flag port as having an IRQ handler X */ X port->p_flags |= P_ISR; X handlers[isr]++; X X /* X * Enable this interrupt vector if not done already X */ X if(handlers[isr] > 1) X isr_interrupts(isr, 1); X Xout: X v_lock(&port->p_lock, SPL0); X v_sema(&port->p_sema); X return(error); X} X X/* X * disable_isr() X * Disable all ISR reporting to the given port X */ Xvoid Xdisable_isr(struct port *port) X{ X int x, tab, isr; X struct isr_msg *i; X struct isr_routine *ir; X X for (x = 0, i = handler; x < MAX_ISR; ++x,++i) { X if (i->i_port == port) { X /* X * Shut off this interrupt vector X */ X isr_interrupts(x, 0); X X /* X * Remove handler X */ X handlers[x] = 0; X i->i_port = 0; X } X } X X /* X * Check isr-routines X */ X for(tab = 0; tab < NUM_ISR_TABLES; tab++) { X isr = tab_to_isr(tab); X X for(x = 0; x < NUM_ISR_ROUTINES; x++) { X ir = &routines[tab][x]; X if(ir->i_port == port) { X /* X * decrement references X * and disable if last handler X */ X handlers[isr]--; X if(handlers[isr] == 0) X isr_interrupts(isr, 0); X FREE(ir->code, 0); /* XXX type */ X ir->code = 0; X ir->i_port = 0; X } X } X } X} X X#ifdef nope X/* X * enable_io() X * Enable I/O instructions for the current thread X * X * For now, just use the IOPL field of the user's eflags. We *could* X * use the I/O bitmap, but I hear it has bugs, and I don't feel like X * chasing them just yet. X */ Xenable_io(int arg_low, int arg_high) X{ X struct trapframe *f = curthread->t_uregs; X struct proc *p = curthread->t_proc; X X ASSERT(f, "enable_io: no uregs"); X X /* X * Check for permission X */ X p_sema(&p->p_sema, PRILO); X if (!(perm_calc(p->p_ids, PROCPERMS, &io_prot) & IOPRIV_IO)) { X v_sema(&p->p_sema); X return(err(EPERM)); X } X v_sema(&p->p_sema); X X /* X * He checks out--turn on all bits in IOPL--this means X * level 3 (user mode) can do I/O instructions. X */ X f->eflags |= F_IOPL; X return(0); X} X#endif /* nope */ X X/* X * deliver_isr_routine() X * Run each ISR routine for this isr and deliver an ISR X * X * Unlike deliver_isr we pass a return value from the return X * with the ISR message in the arg1 field. deliver_isr keeps X * a count of the number of undelivered interupts in this field X */ Xdeliver_isr_routine(int isr) X{ X int i, tab, ret, found; X struct isr_routine *ir; X struct sysmsg *sm; X extern void queue_msg(); X X ASSERT_DEBUG(isr == ISR_EXTER || isr == ISR_PORTS, X "deliver_isr_routine: bad isr"); X tab = isr_to_tab(isr); X X found = 0; X ir = &routines[tab][0]; X for(i = 0; i < NUM_ISR_ROUTINES; i++, ir++) { X if(ir->code) { X found = run_pcode(ir->code, &ret); X if(found) X break; X } X } X X if(found) { X /* X * If the m_op field is 0, this message isn't currently X * queued. Set m_op and queue it. X */ X sm = &ir->i_msg; X if (sm->m_op == 0) { X sm->m_op = M_ISR; X sm->m_arg = isr; X sm->m_arg1 = ret; X queue_msg(ir->i_port, sm); X return(1); X } else { X /* X * nothing we can do here X * normally we would increment arg1 X * to keep count of undelivered ints X * but we had to steal arg1 for ret value X */ X return(1); X } X } X return(0); X} X X/* X * deliver_isr() X * See if given ISR has a handler; call it if so X * X * Return 1 if a handler was found, 0 otherwise. X */ Xdeliver_isr(int isr) X{ X struct sysmsg *sm; X extern void queue_msg(); X X /* X * Check if ISR is too big X */ Xif(isr > MAX_ISR) X printf("isr %d\n", isr); X ASSERT_DEBUG(isr <= MAX_ISR, "deliver_isr: bad isr"); X X /* X * Anybody registered? X */ X if (handlers[isr] == 0) { Xprintf("[%d]", isr); Xreturn(0); X ASSERT(handlers[isr], "deliver isr: no handler"); X strayintr += 1; X return(0); X } X X /* X * If the m_op field is 0, this message isn't currently X * queued. Set m_op and queue it. X */ X sm = &handler[isr].i_msg; X if (sm->m_op == 0) { X sm->m_op = M_ISR; X sm->m_arg = isr; X sm->m_arg1 = 1; X queue_msg(handler[isr].i_port, sm); X return(1); X } X X /* X * Otherwise it's still languishing there. Bump the X * m_arg field to tell them how many times they missed. X */ X sm->m_arg1 += 1; X dupintr += 1; X return(1); X} X X/* X * start_clock() X * Enable clock ticks now that we're ready X */ Xvoid Xstart_clock(void) X{ X ushort interval; X uchar x; X X /* we should already be at spl 7 */ X spl(7); X X#ifdef PAL X interval = (709379 / HZ) - 1; X#else /* NTSC */ X interval = (715909 / HZ) - 1; X#endif X X /* load interval */ X CIABbase->talo = interval & 0xff; X CIABbase->tahi = interval >> 8; X X /* X * timer on - X * allow Timer A interrupts from CIA B X * make sure all other CIA B interrupts X * are off X */ X CIABbase->cra = 0x01; X CIABbase->crb = 0x00; X CIABbase->icr = ~CIA_ICR_IR_SC; X isr_interrupts(ISR_B_TA, 1); X X /* clear any pending interrupts */ X x = CIABbase->icr; X X /* allow interupts */ X spl(0); X} X X/* X * Interpret Code and return true or false X * in addition on a true return the retvalue X * may bet set to something meaningful X */ Xint Xrun_pcode(buf, retval) Xu_int *buf, *retval; X{ X u_int i = 0, accum = 0; X u_int *ip; X u_short *sp; X u_char *cp; X X i = 0; X while(1) switch(buf[i++]) { X case P_NOP: X break; X case P_RETURN_MINE: X *retval = 0; X return(1); X case P_RETURN_NOTMINE: X return(0); X case P_RETURN_MINE_DATA: X *retval = buf[i++]; X return(1); X case P_RETURN_MINE_ACC: X *retval = accum; X return(1); X case P_READ_ADDR_1: X cp = (u_char *)ptov(buf[i++]); X accum = *cp; X break; X case P_READ_ADDR_2: X sp = (u_short *)ptov(buf[i++]); X accum = *sp; X break; X case P_READ_ADDR_4: X ip = (u_int *)ptov(buf[i++]); X accum = *ip; X break; X case P_WRITE_ADDR_1: X cp = (u_char *)ptov(buf[i++]); X *cp = accum; X break; X case P_WRITE_ADDR_2: X sp = (u_short *)ptov(buf[i++]); X *sp = accum; X break; X case P_WRITE_ADDR_4: X ip = (u_int *)ptov(buf[i++]); X *ip = accum; X break; X case P_AND_DATA: X accum &= buf[i++]; X break; X case P_OR_DATA: X accum |= buf[i++]; X break; X case P_IF_TRUE: X if(accum == 0) X i++; X break; X case P_IF_FALSE: X if(accum != 0) X i++; X break; X case P_DATA: X accum = buf[i++]; X break; X default: X printf("run_pcode: unknown opcode %x\n", buf[i-1]); X return(0); X } X} X END-of-isr.c echo x - isr.h sed 's/^X//' >isr.h << 'END-of-isr.h' X#ifndef _MACHISR_H X#define _MACHISR_H X/* X * isr.h X * Breakdown of possible interupts X */ X X/* interupt vectors */ X#define LOINT 24 X#define HIINT 31 X X/* X * registerable interupts X * of these, ISR_PORTS and ISR_EXTER are X * special. To use them register an isr routine X */ X#define ISR_TBE 1 /* serial transmit buffer empty */ X#define ISR_DSKBLK 2 /* disk block transfered */ X#define ISR_SOFTINT 3 /* software interupt */ X#define ISR_PORTS 4 /* unspecified PORTS interupt */ X#define ISR_A_TA 5 /* PORTS CIA A timer A */ X#define ISR_A_TB 6 /* CIA A timer B */ X#define ISR_A_ALARM 7 /* CIA A alarm */ X#define ISR_A_SP 8 /* CIA A serial port */ X#define ISR_A_FLG 9 /* CIA A flag */ X#define ISR_BLIT 10 /* blitter */ X#define ISR_COPER 11 /* copper */ X#define ISR_VERTB 12 /* vertical blank */ X#define ISR_AUD0 13 /* audio channel 0 */ X#define ISR_AUD1 14 /* audio channel 1 */ X#define ISR_AUD2 15 /* audio channel 2 */ X#define ISR_AUD3 16 /* audio channel 3 */ X#define ISR_RBF 17 /* serial receive buffer full */ X#define ISR_DSKSYNC 18 /* disk sync pattern found */ X#define ISR_EXTER 19 /* unspecified EXTER interupt */ X#define ISR_B_TA 20 /* EXTER CIA B timer A - *** used by system */ X#define ISR_B_TB 21 /* CIA B timer B */ X#define ISR_B_ALARM 22 /* CIA B alarm */ X#define ISR_B_SP 23 /* CIA B serial port */ X#define ISR_B_FLG 24 /* CIA B flag */ X#define ISR_NMI 25 /* non-maskable interupt */ X#define MAX_ISR ISR_NMI X X/* X * ISR Routine Pseudo-Code Opcodes. X */ X#define P_NOP 0 /* 0 args */ X#define P_RETURN_MINE 1 /* 0 args */ X#define P_RETURN_NOTMINE 2 /* 0 args */ X#define P_RETURN_MINE_DATA 3 /* 1 arg */ X#define P_RETURN_MINE_ACC 4 /* 0 args */ X#define P_READ_ADDR_1 5 /* 1 arg */ X#define P_READ_ADDR_2 6 /* 1 arg */ X#define P_READ_ADDR_4 7 /* 1 arg */ X#define P_WRITE_ADDR_1 8 /* 1 arg */ X#define P_WRITE_ADDR_2 9 /* 1 arg */ X#define P_WRITE_ADDR_4 10 /* 1 arg */ X#define P_AND_DATA 11 /* 1 arg */ X#define P_OR_DATA 12 /* 1 arg */ X#define P_IF_TRUE 13 /* 1 arg - instruction */ X#define P_IF_FALSE 14 /* 1 arg - instruction */ X#define P_DATA 15 /* 1 arg */ X X#endif /* _MACHISR_H */ END-of-isr.h exit From vandys@glare.cisco.com Wed Feb 8 21:11:23 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA02704; Wed, 8 Feb 1995 21:11:22 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA05271 for ; Wed, 8 Feb 1995 21:48:40 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rcRjr-000a1AC; Wed, 8 Feb 95 19:48 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Neat Stuff To: vsta@cisco.com (VSTa Mailing List) Date: Wed, 8 Feb 1995 19:48:23 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 842 Hi, I'm reading out of an overview of research projects at UWashington: ".. A new system Opal, attempts to exploit the potential of wide-address architectures - processors with 64 bits or more of addressing such as the MIPS R4000 and the DEC Alpha. "In Opal, all applications execute in one address space. This facilitates sharing: a pointer means the same thing to all applications. The key point is that having a single address space does not compromoise protection: each application executes in a private domain; the fact that an application can generate an address does not mean that in can read or write that address. Protection domains are composed of multiple segments; segments are the basic unit of sharing." Anyone looking at the Alpha platform? :-) Tim N. From vandys@glare.cisco.com Fri Feb 10 10:57:52 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA02986; Fri, 10 Feb 1995 10:57:51 -0800 Received: from sol.we.lc.ehu.es (sol.we.lc.ehu.es [158.227.6.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA14324 for ; Fri, 10 Feb 1995 11:35:13 -0800 Received: from sirius.we.lc.ehu.es by sol.we.lc.ehu.es (5.0/SMI-SVR4) id AA08123; Fri, 10 Feb 1995 20:34:26 +0100 From: borjam@we.lc.ehu.es (Borja Marcos) Message-Id: <9502101934.AA08123@sol.we.lc.ehu.es> Subject: vsta and group communication To: vsta@cisco.com Date: Fri, 10 Feb 95 20:40:58 MET X-Mailer: ELM [version 2.3 PL11] Content-Length: 730 Hello, I'm interested on distributed algorithms and have found (finally) a freely available operating system. I'm considering adding group communication and some synchronization mechanisms to vsta. Has anyone already done it? It anyone doing it? I'm thinking about group communication facilities similar to Amoeba's. Regards, Borja. -- ******************************************************************* Borja Marcos | Preferred: borjam@we.lc.ehu.es Alangoeta, 11, 1. izq. | Others: m_d_l_p_b@euskom.spritel.es 48990 - Algorta (Vizcaya) | 100015.3502@compuserve.com SPAIN | CIS: 100015,3502 ****************************************************************** From vandys@glare.cisco.com Fri Feb 10 15:20:22 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA03017; Fri, 10 Feb 1995 15:20:21 -0800 Received: from sol.we.lc.ehu.es (sol.we.lc.ehu.es [158.227.6.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA03761 for ; Fri, 10 Feb 1995 15:57:43 -0800 Received: from sirius.we.lc.ehu.es by sol.we.lc.ehu.es (5.0/SMI-SVR4) id AA09343; Sat, 11 Feb 1995 00:56:55 +0100 From: borjam@we.lc.ehu.es (Borja Marcos) Message-Id: <9502102356.AA09343@sol.we.lc.ehu.es> Subject: Re: vsta and group communication To: vsta@cisco.com Date: Sat, 11 Feb 95 1:03:30 MET In-Reply-To: <199502102029.MAA14872@glare.cisco.com>; from "Andrew Valencia" at Feb 10, 95 12:29 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 1187 Andrew Valencia writes: > > [borjam@we.lc.ehu.es (Borja Marcos) writes:] > > > I'm interested on distributed algorithms and have found > >(finally) a freely available operating system. I'm considering > >adding group communication and some synchronization > >mechanisms to vsta. Has anyone already done it? > > A fellow did a very simple semaphore filesystem. Another did a > thread/shared address space mutex mechanism. > > >It anyone > >doing it? I'm thinking about group communication facilities > >similar to Amoeba's. > > I'm not familiar with this; can you point me to a paper? The mechanism used in Amoeba is described in ftp.cs.vu.nl:/pub/amoeba/amoeba_papers/group94.ps.z I'm interested on fault-tolerant redundant systems, and this paper describes an excellent protocol. Borja. -- ******************************************************************* Borja Marcos | Preferred: borjam@we.lc.ehu.es Alangoeta, 11, 1. izq. | Others: m_d_l_p_b@euskom.spritel.es 48990 - Algorta (Vizcaya) | 100015.3502@compuserve.com SPAIN | CIS: 100015,3502 ****************************************************************** From vandys@glare.cisco.com Fri Feb 10 21:50:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA03050; Fri, 10 Feb 1995 21:50:11 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id WAA21126 for ; Fri, 10 Feb 1995 22:27:40 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa29568; 11 Feb 95 6:27 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rdAVj-0002pqC; Sat, 11 Feb 95 05:36 GMT Message-Id: From: Dave Hudson Subject: Performance work status To: VSTa mailing list Date: Sat, 11 Feb 1995 05:36:47 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Hi All, I think I mentioned a few weeks back that the next major area for improvement would be the messaging engine code. Since then I've found some quite neat optimisations and now have the perf1 score on my DX/4-100 system down to 33.5 microseconds - in addition general messaging operations (connects, disconnects, paging, etc) should also be faster. I've also tinkered with an idea that I seem to remember Joerg Wittenberger suggested of having a msg_reply_receive() function to avoid the transition into kernel space twice - with just a simple version that does this by calling msg_reply() and msg_receive() in turn we get about 1.5 us of saving - I'll play around with this some more (expanding out the code) as it may save us some vital usecs. Regards, Dave From vandys@glare.cisco.com Sat Feb 11 13:48:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA03190; Sat, 11 Feb 1995 13:48:19 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA23813 for ; Sat, 11 Feb 1995 14:25:52 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rdQFv-000a1KC; Sat, 11 Feb 95 12:25 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: ATOMIC_* functions (again :) To: vsta@cisco.com (VSTa Mailing List) Date: Sat, 11 Feb 1995 12:25:31 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 753 Hi, I am looking over the new sources (vsta132) and noticed that the atomic increment and decrement functions are still not being used properly: os/kern/ port.c short (struct proc).p_nopen pset.c ushort (struct pset).p_refs these two will have problems if long is 64 bits: malloc.c ulong xclock.c ulong (struct percpu).cp_ticks os/mach several routines manipulate ushort (struct percpu).pc_locks The routines themselves increment "long" (4 byte) quantities. I need these fixed for the amiga version. I was using ATOMIC_INCW/DECW() and ATOMIC_INCL/DECL() in my original code. Let me know what you will be using so I can keep my code consistent with the main tree. Tim N. From vandys@glare.cisco.com Sat Feb 11 14:08:41 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA03200; Sat, 11 Feb 1995 14:08:40 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA26370; Sat, 11 Feb 1995 14:46:13 -0800 Message-Id: <199502112246.OAA26370@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: ATOMIC_* functions (again :) In-Reply-To: Your message of "Sat, 11 Feb 1995 12:25:31 -1000." Date: Sat, 11 Feb 1995 14:46:13 -0800 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] > I am looking over the new sources (vsta132) and noticed that the >atomic increment and decrement functions are still not being used >properly: 1.3.2, or the latest, 1.3.3? > os/kern/ > port.c short (struct proc).p_nopen > pset.c ushort (struct pset).p_refs There are prototypes for the atomic functions now, so hopefully I can't have strayed too far. p_nopen is a long, and is handled with the longword version. p_refs is a short, and is handled with the short version. > these two will have problems if long is 64 bits: > malloc.c ulong > xclock.c ulong (struct percpu).cp_ticks I'm afraid I don't follow. The ATOMIC_INCL()/ATOMIC_DECL() have prototypes for a longword argument. So you have to pass it a compatible (as defined by ANSI C) type, which I *think* I do. malloc.c only uses these for n_alloc[], which is a longword array. If longs become 64 bits, the array elements do, too. The actual assembly code has to change, but that's to be expected if you make such a fundamental change. > os/mach > several routines manipulate ushort (struct percpu).pc_locks They all use ATOMIC_INCW/DECW, right? >The routines themselves increment "long" (4 byte) quantities. >I need these fixed for the amiga version. I have a definite feeling you're not looking at the current code. Could you download 1.3.3 from ftp.cisco.com:vandys/vsta and double check? >I was using ATOMIC_INCW/DECW() and ATOMIC_INCL/DECL() in my >original code. Let me know what you will be using so I >can keep my code consistent with the main tree. From include/sys/mutex.h: extern void ATOMIC_INCW(volatile ushort *); extern void ATOMIC_DECW(volatile ushort *); extern void ATOMIC_INCL(volatile ulong *); extern void ATOMIC_DECL(volatile ulong *); extern void ATOMIC_INC(volatile uint *); extern void ATOMIC_DEC(volatile uint *); I guess I should have warned you what release I folded your comments into. Sorry for the confusion! Andy From vandys@glare.cisco.com Sun Feb 12 15:30:51 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA03301; Sun, 12 Feb 1995 15:30:50 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id QAA14074 for ; Sun, 12 Feb 1995 16:08:27 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rdoKi-000a1dC; Sun, 12 Feb 95 14:08 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Multiple Architecture source tree To: vsta@cisco.com (VSTa Mailing List) Date: Sun, 12 Feb 1995 14:08:04 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1762 Hi, I'm now merging my amiga code into the 1.3.3 source tree. In my previous tree I took over the tree and made it work with my system. This time around I'm trying to do it right to allow support for several architectures in the same tree. Right now I have: boot.amiga boot.i386 bin.src include/* include/mach.i386 include/mach.amiga libc/* libc/mach.i386 libc/mach.amiga os/* os/dbg.i386 os/dbg.amiga os/mach.i386 os/mach.amiga srv/* srv/mach.i386 srv/mach.amiga etc... Andy mentioned that the machine dependant directories would be symlinks. I am having some problems fitting into this mold: the os/make directory is a shared directory. I modified the config program to take an optional arch parameter. This parameter specifies a subdirectory to get the 'files', 'objs', 'make.head' and 'make.tail' directories if specified. This allows the files and definitions to be different for each arch. libc. My libc makefile was hacked up a bit. The mach directory under libc doesnt have a makefile and so the libc makefile accesses the mach directory directly. I do not have the same list of files in this directory as the i386 port. I also make a libkern.a library and moved utility routines out of locore.s. My 'ar' program also doesnt support all the same flags and so I had added an ARFLAGS variable in my makefile (this last problem is minor and will go away when I compile native or use the same toolset). Anyway the end result is that my makefile for libc is different in a few places and cant easily be shared between archs. Is there a simple solution? I personally think a tree where all the mach dependant device drivers, kernel code and librarires were under on directory would be better. Tim N. From vandys@glare.cisco.com Mon Feb 13 09:42:28 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03478; Mon, 13 Feb 1995 09:42:27 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA01204; Mon, 13 Feb 1995 10:20:10 -0800 Message-Id: <199502131820.KAA01204@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: Multiple Architecture source tree In-Reply-To: Your message of "Sun, 12 Feb 1995 14:08:04 -1000." Date: Mon, 13 Feb 1995 10:20:09 -0800 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] >...[multiple architecture source tree]... I'm planning on using symbolic links. Where you currently see "../mach/" you would instead see "../@MACH/". @MACH expands to the value of the environment variable "MACH" for a given process. During bootup we would put "isa386", "amiga68k", and so forth as a global value for the MACH environment variable. >the os/make directory is a shared directory. I modified the >config program to take an optional arch parameter. This parameter >specifies a subdirectory to get the 'files', 'objs', 'make.head' >and 'make.tail' directories if specified. This allows the files >and definitions to be different for each arch. How about an "include @MACH/makefile" in the main one? >libc. My libc makefile was hacked up a bit. The mach directory >under libc doesnt have a makefile and so the libc makefile >accesses the mach directory directly. I do not have the same >list of files in this directory as the i386 port. I also >make a libkern.a library and moved utility routines out of >locore.s. My 'ar' program also doesnt support all the same >flags and so I had added an ARFLAGS variable in my makefile >(this last problem is minor and will go away when I compile >native or use the same toolset). Anyway the end result >is that my makefile for libc is different in a few places >and cant easily be shared between archs. Is there a simple >solution? It seems like another makefile include might handle this as well? >I personally think a tree where all the mach dependant device >drivers, kernel code and librarires were under on directory >would be better. I lived with such a tree for HP/UX's command source. It wasn't that great. I've generally been happier with mach/ (@MACH/) subdirectories and all source for a given command (or kernel) in close proximity. Regards, Andy From vandys@glare.cisco.com Tue Feb 14 02:12:27 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA03558; Tue, 14 Feb 1995 02:12:26 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA11263 for ; Tue, 14 Feb 1995 02:50:13 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa13139; 14 Feb 95 10:21 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0reKQz-0003UeC; Tue, 14 Feb 95 10:24 GMT Message-Id: From: Dave Hudson Subject: Changing the clock speed To: VSTa mailing list Date: Tue, 14 Feb 1995 10:24:40 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 540 Hi All, Has anyone got an opinion about changing the value of HZ to 100 from 20? I've done some quick tests (BTW this also involved changing RUN_TICKS to give 4 swtch's per second instead of 3.333) on a 486SX-25 and it adds an overhead of about 0.3 microseconds per context switch under perf1 and on a DX/4-100 it's about 0.1. Extrapolating back I guess this means about 2 microseconds on a 386SX-16 (assuming around a 500 microsecond switch time). The improved accuracy for timing events is really quite useful. Regards, Dave From vandys@glare.cisco.com Tue Feb 14 05:53:33 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA03599; Tue, 14 Feb 1995 05:53:32 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA27284 for ; Tue, 14 Feb 1995 06:31:20 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA12415; Tue, 14 Feb 95 09:31:18 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA19253; Tue, 14 Feb 95 09:31:16 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA22141; Tue, 14 Feb 95 09:31:16 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA04478; Tue, 14 Feb 95 09:31:15 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA03575; Tue, 14 Feb 95 09:31:14 EST Date: Tue, 14 Feb 95 09:31:14 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9502140931.ZM3573@crozet> In-Reply-To: Dave Hudson "Changing the clock speed" (Feb 14, 10:24) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Re: Changing the clock speed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Funny, I have been considering making the same change. The 18.2 ticks per second of the IBM PC is rather coarse. It was acceptable for slow machines like 8088's and 80286's but is not acceptable for today's higher speeds. In fact almost every machine I worked with since the early 1970's used either 60HZ or 100HZ as the basic interval. For accurate performance measurements it is also important to calibrate the interval timer. I am thinking along the lines of using the Real Time Clock as a standard and then measuring the interval against the RTC. On most machines, the RTC drift is on the order of a few seconds per day or about a minute per month. Time drifts on this order are acceptable for determining the exact count needed by the interval timer on a specific machine. By using a common calibration algorithm we can more reliably compare performance results. Also note that by calibrating the clock, we can also get a performance metric a la Linux's BogoMips. By normalizing any performance measure against the BogoMips, we can see the true costs/benefits of VSTa and its algorithms in a machine independent fashion. Now all I have to do is to implement the calibrator...:-> -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Tue Feb 14 07:42:21 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03611; Tue, 14 Feb 1995 07:42:20 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA03111 for ; Tue, 14 Feb 1995 08:20:09 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10471; 14 Feb 95 15:45 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rePH4-0003UxC; Tue, 14 Feb 95 15:34 GMT Message-Id: From: Dave Hudson Subject: Re: Changing the clock speed To: David Koogler Date: Tue, 14 Feb 1995 15:34:45 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9502140931.ZM3573@crozet> from "David Koogler" at Feb 14, 95 09:31:14 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1557 David Koogler wrote: > > Funny, I have been considering making the same change. The 18.2 ticks per > second of the IBM PC is rather coarse. It was acceptable for slow machines > like 8088's and 80286's but is not acceptable for today's higher speeds. In > fact almost every machine I worked with since the early 1970's used either 60HZ > or 100HZ as the basic interval. Ouch 60 Hz - I'd rather have my mains frequency of 50 Hz :-) FWIW we are currently using 20 Hz as it's more accurate than the 18.2 we originally had (that was my first patch for VSTa in fact :-)) > For accurate performance measurements it is also important to calibrate the > interval timer. I am thinking along the lines of using the Real Time Clock as > a standard and then measuring the interval against the RTC. On most machines, > the RTC drift is on the order of a few seconds per day or about a minute per > month. I think you'll find an awful lot of machines that are *much* less accurate than that - typically 250 ppm (about 8 mins per month). The other thing is that unfortunately this is usually *very* temperature dependent. I think if I wanted really accurate time info I'd go for NTP (when we have the tcp server) or some sort of radio standard synchronisation instead (although this tends to be rather country specific unfortunately). In reality I'm not sure that an error of < 0.1% is really too important for basic performance measurements - anything else and I'd prefer to use an independent calibrated frequency reference instead. Regards, Dave From vandys@glare.cisco.com Tue Feb 14 07:58:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03614; Tue, 14 Feb 1995 07:58:10 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA04025 for ; Tue, 14 Feb 1995 08:35:59 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA15803; Tue, 14 Feb 95 11:35:57 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA29620; Tue, 14 Feb 95 11:35:54 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA28828; Tue, 14 Feb 95 11:35:54 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA06664; Tue, 14 Feb 95 11:35:53 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA03689; Tue, 14 Feb 95 11:35:52 EST Date: Tue, 14 Feb 95 11:35:52 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9502141135.ZM3687@crozet> In-Reply-To: Dave Hudson "Re: Changing the clock speed" (Feb 14, 15:34) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Re: Changing the clock speed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii A frequency counter? Yes, that is the best way to get a calibrated clock. One technique I saw for MS/DOS and calibrating against the U.S. NIST atomic clock was to pulse one of the parallel port status lines (Ready to Send?) on each clock tick. Just hook the frequency counter up to the status line and directly read off the clock rate. I agree that the RTC drift can be rather high, depending on the manufacturer. Most of the high-end equipment, such as Compaq, have rather low drift rates but some of the other clones can be really nasty. However, over just a short period of time, say 1 to 5 minutes, the RTC should be reasonable. Personally, I wish the PC designers had used the "main's" frequency as the time basis rather than the internal crystal. The electric power grid has to maintain a frequency error rate of something less than 1 ppm, or else the entire grid can collapse. A simple notch filter and a zero-crossing detector gives you the external clock reference...much cheaper than the crystal oscillator and interval timer chip on the PC. Most of the minicomputers used just such a simple time reference (thus the 60HZ interval on the PDP-11 and Unix). If your interested, I can look up the source code for calling NIST and setting the clock. I believe there are several other international standards organizations with similar facilities. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Tue Feb 14 08:12:29 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA03618; Tue, 14 Feb 1995 08:12:27 -0800 Received: from wsrcom.wsr.ac.at ([143.130.16.8]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA05042 for ; Tue, 14 Feb 1995 08:49:46 -0800 Message-Id: <199502141649.IAA05042@hubbub.cisco.com> Received: from wsrdb.wsr.ac.at by wsrcom.wsr.ac.at with ESMTP (1.37.109.14/16.2) id AA079900578; Tue, 14 Feb 1995 17:49:39 +0100 Received: by wsrdb.wsr.ac.at (1.37.109.14/16.2) id AA233960578; Tue, 14 Feb 1995 17:49:38 +0100 From: Peter Holzer Subject: Re: Changing the clock speed To: vsta@cisco.com Date: Tue, 14 Feb 1995 17:49:37 +0100 (MEZ) In-Reply-To: <9502140931.ZM3573@crozet> from "David Koogler" at Feb 14, 95 09:31:14 am Reply-To: hp@vmars.tuwien.ac.at Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2068 > For accurate performance measurements it is also important to calibrate the > interval timer. I am thinking along the lines of using the Real Time Clock as > a standard and then measuring the interval against the RTC. On most machines, > the RTC drift is on the order of a few seconds per day or about a minute per > month. > Time drifts on this order are acceptable for determining the exact count needed > by the interval timer on a specific machine. By using a common calibration > algorithm we can more reliably compare performance results. In my experience the internal timer of a PC is more accurate than the RTC clock. If anything you would have to calibrate the RTC against the internal timer. Also note that you cannot set the timer interval very precicely. If you want an interval of about 10 ms, the counter has a value of about 12000, which means that increasing or decreasing it by 1 changes the error per day by about 8 seconds. You can work around this by maintaining the time at a very fine level (e.g. at nanoseconds) and then determine the length of a clock interval at that resolution (so after calibration you find that a clock interval is 10,000,538 ns, for example). > Also note that by calibrating the clock, we can also get a performance metric a > la Linux's BogoMips. How do you do that? You are just comparing one counter against another, none of which has anything to do with CPU speed. > By normalizing any performance measure against the > BogoMips, we can see the true costs/benefits of VSTa and its algorithms in a > machine independent fashion. No, please don't use BogoMips for anything which looks even remotely like a benchmark. What do you think the `Bogo' stands for? BogoMips measures only a few instructions, and the measurement is intended as a base for delay loops which use the same instructions. hp -- _ | Peter Holzer | hp@vmars.tuwien.ac.at | hjp@wsr.ac.at |_|_) |------------------------------------------------------ | | | There are lies, damned lies, and benchmarks. __/ | -- anon. From vandys@glare.cisco.com Tue Feb 14 10:24:04 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA03648; Tue, 14 Feb 1995 10:24:02 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA16413 for ; Tue, 14 Feb 1995 11:01:51 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA19808; Tue, 14 Feb 95 14:01:49 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA04434; Tue, 14 Feb 95 14:01:47 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA05246; Tue, 14 Feb 95 14:01:46 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA09018; Tue, 14 Feb 95 14:01:43 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA04061; Tue, 14 Feb 95 14:01:42 EST Date: Tue, 14 Feb 95 14:01:42 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9502141401.ZM4059@crozet> In-Reply-To: Peter Holzer "Re: Changing the clock speed" (Feb 14, 17:49) References: <199502141649.IAA05042@hubbub.cisco.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Re: Changing the clock speed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Peter Holzer brought up some interesting observations and criticisms: 1). Don't use BogoMips. I agree that the Linux BogoMips metric is not very useful in and of itself. However the measure is relatively easy to make, easy to understand, and does not require any external equipment. I can easily hook up a frequency counter to an I/O port or pick out the signal from the CPU and use that as a metric. Not everyone is so equipped. What we need is some method to characterize the performance of a machine against many others that are running VSTa in order to normalize performance metrics. The PC hardware provides only two devices for measuring elapsed time. The only way I can see to get an idea of a machine's performance is to run some set of instructions and see how far the interval timer and/or RTC counted during the execution. This metric is crude but easily reproduced any machine regardless of configuration. 2). Why calibrate the RTC against the interval timer? I want to tune the number that I place into the interval timer. Under MS/DOS, the CPU just allows the timer to roll-over and accepts the 1/18.2 second period. If I want a higher rate, I need to set the counter to a different value. What value do I use? Without an external time reference of any sort I can only guess (divide 0xFFFF by 5 to get a 100HZ period). That number needs adjusting to account for the overhead in processing the interrupt and resetting the counter. Why not write a calibrator that runs for a given period of time (as determined by the RTC) and then see how many times the interval timer ticked? Long term accuracy is not required, only good short term accuracy. Note that the error on the interval timer's absolute rate depends upon a crystal oscillator circuit. Typical crystal's have a frequency output error of between 1% to 5% (cheap clones have lousy crystals :->). No matter what I do, the interval timer will never give accurate measures over long time periods, but it is useful for short period measures. 3). You can't set the interval timer interval very precisely. I absolutely agree with you. I'm not looking for microsecond resolution, but something more on the order of 10 milliseconds is more appropriate. For more precise measures, I hook up my frequency counter which is rated to 100mHZ with a 0.1 ppm error rate. P.S. I have always hated the PC's interval timer implementation. Besides the accuracy problems, the timer is limited to 16-bits and runs a very odd-ball frequency. For industrial control work which needs accurate time, I use one of the digital I/O and timer cards. The cards have 1MHz 1% clocks and, by ganging the counters together, a 48-bit range. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Tue Feb 14 10:46:08 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA03664; Tue, 14 Feb 1995 10:46:07 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA04932; Tue, 14 Feb 1995 11:23:57 -0800 Message-Id: <199502141923.LAA04932@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: VSTa mailing list Subject: Re: Changing the clock speed In-Reply-To: Your message of "Tue, 14 Feb 1995 10:24:40 GMT." Date: Tue, 14 Feb 1995 11:23:56 -0800 From: Andrew Valencia [Dave Hudson writes:] >Has anyone got an opinion about changing the value of HZ to 100 from 20? A couple of observations. First, increasing clock frequency to improve timer resolution is the wrong way to go. As was noted, if you need better resolution, you should use an interval timer in conjunction with your system clock. Second, increasing clock frequency to reduce latency between context switches generally indicates that you should fix your preemption code instead. With the current kernel, we will preempt immediately (that is, not wait for next clock interrupt) if a real-time process becomes runnable and the current process is not real-time. We will similarly preempt if a "cheated" process becomes runnable and the current process is neither real-time nor "cheated". "cheated" is defined as a process which gave up the CPU before his CPU allocation was consumed, and has been giving the CPU up in this manner for a certain amount of time into the past. This causes interactive applications to be responsive in preference to CPU-bound applications. See the "cheated" flag and queue, as well as the "oink" counter ("oink", in English, refers to the sound a pig makes :->). With these two aspects covered (plus or minus a bug fix and tweaking!), are there any other aspects of system performance which really call for us to up the clock frequency? As Dave measured, there is a real overhead cost in taking more interrupts--we should do so only when the alternatives have been exhausted. Andy From vandys@glare.cisco.com Tue Feb 14 11:42:32 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA03672; Tue, 14 Feb 1995 11:42:31 -0800 Received: from simon.cs.cornell.edu (SIMON.CS.CORNELL.EDU [128.84.154.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA22644 for ; Tue, 14 Feb 1995 12:20:22 -0800 Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.9/R1.01) with SMTP id PAA04532 for ; Tue, 14 Feb 1995 15:20:20 -0500 Received: from ECLAIR4.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA07312; Tue, 14 Feb 95 15:20:25 -0500 Received: (vogels@localhost) by eclair4.cs.cornell.edu (8.6.9/C1.00) id PAA01291; Tue, 14 Feb 1995 15:20:18 -0500 Message-Id: <199502142020.PAA01291@eclair4.cs.cornell.edu> To: VSTa mailing list Subject: Re: Changing the clock speed In-Reply-To: Your message of "Tue, 14 Feb 1995 11:23:56 PST." <199502141923.LAA04932@glare.cisco.com> Date: Tue, 14 Feb 1995 15:20:18 -0500 From: Werner Vogels [I didn't read the sources on this so I apologize if I am slighty wrong] The problem of getting accurate time information is not a problem of the interrupt frequency. Quite a number of traditional OS indeed return time information based on a time variable that gets incremented at every clock interrupt. BSD even created a uniquetime call to assure that two subsequent invocations of the time reading routine would return a unique time (even though it didn't represent the real time). The way to do it right is to *read* your clock/timer at every call and use that information in combination with the global time variable to produce a more accurate timer. On the 386 family machines you can also do this, you can read out the 8253 register for timer0 to find out how many ticks have passed since the last interrupt. This way you get a microsecond timer resolution without changing you interrupt frequency. example code for this: ftp://ftp.ee.lbl.gov/microtime-i386.tar.Z -- Werner From vandys@glare.cisco.com Wed Feb 15 01:11:31 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA03786; Wed, 15 Feb 1995 01:11:30 -0800 Received: from oeillet.saclay.cea.fr ([132.166.192.213]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id BAA06426 for ; Wed, 15 Feb 1995 01:49:23 -0800 Received: from rosser.serma.cea.fr by oeillet.saclay.cea.fr (8.6.9/ CEANET-ROUTER-3.0) with SMTP id KAA04139 for ; Wed, 15 Feb 1995 10:49:42 +0100 Received: by rosser.serma.cea.fr (5.0/CEANET.2.0.1) id AA00345; Wed, 15 Feb 1995 09:21:50 --100 Date: Wed, 15 Feb 1995 09:21:50 --100 From: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Message-Id: <9502150821.AA00345@rosser.serma.cea.fr> To: VSTa mailing list Subject: vsta on biprocessors pentium Content-Length: 0 Hello all. Some manufacturers are making biprocessors pentium 90 motherboards. I'm considering buying such a thing. Does it make sense? Are such motherboards useable? Can VSTa be easily adapted to biprocessor operations? Can these motherboards run (in monoprocessor mode) popular OSes such as Linux? Does anyone have hints, feature to check (eg cache consistency between both processors), motherboard brands to avoid, etc? -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 46.65.45.53 email: basile.starynkevitch@cea.fr (redirected to basile@soleil.serma.cea.fr); N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Feb 15 05:58:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA03851; Wed, 15 Feb 1995 05:58:55 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA25430; Wed, 15 Feb 1995 06:36:48 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa29602; 15 Feb 95 12:15 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0reic3-0003VZC; Wed, 15 Feb 95 12:13 GMT Message-Id: From: Dave Hudson Subject: Re: Changing the clock speed To: Andrew Valencia Date: Wed, 15 Feb 1995 12:13:43 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199502141923.LAA04932@glare.cisco.com> from "Andrew Valencia" at Feb 14, 95 11:23:56 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1772 Hi Andy, Andrew Valencia wrote: > > >Has anyone got an opinion about changing the value of HZ to 100 from 20? > > A couple of observations. That's why I asked :-) > First, increasing clock frequency to improve timer resolution is the wrong > way to go. As was noted, if you need better resolution, you should use an > interval timer in conjunction with your system clock. Quite true - I did things this way 'cos it was quick and easy to do. I'm now looking at using the interval timer instead, although it means some of the clock code will be inlined from the mach dir instead of all living in the kern directory. Something does ring bells with me about problems with the interval timer for this sort of activity, but I guess we'll see how it goes. > Second, increasing clock frequency to reduce latency between context > switches generally indicates that you should fix your preemption code > instead. With the current kernel, we will preempt immediately (that is, not Well there was never really any intention to move to preempting faster (4 Hz just sounds nicer than 3.33 :-)) Realistically I want to look at some of the queue handling to cope with these sorts of issues (I've seen some great priority inversions with some of my test code). > With these two aspects covered (plus or minus a bug fix and tweaking!), are > there any other aspects of system performance which really call for us to up > the clock frequency? As Dave measured, there is a real overhead cost in > taking more interrupts--we should do so only when the alternatives have been > exhausted. I can't now see any need for a change. In fact I've now realised there's another optimisation I can do for the clock handler which will make things even faster :-) Regards, Dave From vandys@glare.cisco.com Wed Feb 15 07:12:24 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03860; Wed, 15 Feb 1995 07:12:20 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA29355 for ; Wed, 15 Feb 1995 07:49:38 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA29051; Wed, 15 Feb 1995 16:50:04 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA32325; Wed, 15 Feb 1995 16:48:44 +0100 Date: Wed, 15 Feb 1995 16:48:44 +0100 Message-Id: <9502151548.AA32325@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Time meansurement From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi all, from all the posters regarding time meansurement I think I 'announce' this. I'm not quite sure whether it is really worth. At least it concerns the other way around. I didn't bother with exact time, but with comparable time at one machine (to find bottlenecks in algorithms). In the Pentium 90 I'm currently running VSTa at, I have a board on the ISA bus which provides a 32 bit start/stop counter clocked by a 40 MHz crystal. (And I know nothing about the accuracy of the crystal.) This gives the chance to compare short time (with the overhead of one ISA-i/o to start/stop the counter). If someone is interested I could run some test. I modifiied the perf1 to report the time take for each msg_send(). here the firt 10 lines of the output (it's a litle outdated, this test has been run with V132): Ticks (40 MHz): 12675 = 316875 ns Ticks (40 MHz): 14840 = 371000 ns Ticks (40 MHz): 11094 = 277350 ns Ticks (40 MHz): 11094 = 277350 ns Ticks (40 MHz): 11105 = 277625 ns Ticks (40 MHz): 11207 = 280175 ns Ticks (40 MHz): 11190 = 279750 ns Ticks (40 MHz): 11110 = 277750 ns Ticks (40 MHz): 11094 = 277350 ns BTW: The board is not a 'standard' board (but commercial available). It's quite less loaded with the task above and it would coust almost as much as the PC. /Jerry ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Wed Feb 15 12:12:45 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03922; Wed, 15 Feb 1995 12:12:43 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA20414 for ; Wed, 15 Feb 1995 12:50:39 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa09256; 15 Feb 95 17:22 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0renPt-0003VhC; Wed, 15 Feb 95 17:21 GMT Message-Id: From: Dave Hudson Subject: More on timer work To: VSTa mailing list Date: Wed, 15 Feb 1995 17:21:29 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 978 Hi All, Just to let you know I've borrowed the Linux code for the microsecond interval timer (which showed me where I made a mistake in some similar code 4 or 5 years ago :-() - I'm now back at 20 Hz and running fine (although I'm still running at 4 Hz for timeslices - it's easier to count with :-)). BTW - going back to part of the reason I wanted to do all this I've got my latest context switch benchmarks compiled with no DEBUG flag, but with the kernel debugger: CPU 486DX/4-100 486DX/4-100 486SX-25 L2 Cache 256k W-back 0k 256k W-back perf1 (messaging): 32.0 us 45.6 us 94.0 us perf2 (yielding): 10.6 us 15.2 us 34.0 us Note that the DX/4 system is based on a design about 2 years newer than the 486SX (and has a faster memory subsystem). If anyone wants 100 Hz ticks though, they'll simply have to change HZ in mach/param.h as I left the code that keeps us to 4Hz scheduling in place (and this will allow for 10 ms alarm events). Regards, Dave From vandys@glare.cisco.com Thu Feb 16 04:59:44 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA04100; Thu, 16 Feb 1995 04:59:43 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA17709 for ; Thu, 16 Feb 1995 05:37:43 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa11082; 16 Feb 95 13:31 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rf6HF-00037oC; Thu, 16 Feb 95 13:29 GMT Message-Id: From: Dave Hudson Subject: Performance of the dos fs To: VSTa mailing list Date: Thu, 16 Feb 1995 13:29:49 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 444 Hi All, Has anyone taken a look at the dos fs code with a view to performance? I ran some quick IOzone tests last night and noticed that whilst I'm hitting about 75% of raw disk read performance through the dosfs, I'm only getting about 20% of the performance for writes. On a slightly unrelated point - can anyone tell me how much faster or slower gcc 1.42 is at compiling things compared to say gcc 2.5.x or 2.6.x? Regards, Dave From vandys@glare.cisco.com Thu Feb 16 06:33:04 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA04109; Thu, 16 Feb 1995 06:33:03 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA23000 for ; Thu, 16 Feb 1995 07:11:04 -0800 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id HAA15044; Thu, 16 Feb 1995 07:10:30 -0800 Message-Id: <199502161510.HAA15044@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Thu, 16 Feb 1995 07:10:30 PST In-Reply-To: Dave Hudson ' Performance of the dos fs Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Dave Hudson , VSTa mailing list Subject: Re: Performance of the dos fs From: Dave Hudson Subject: Performance of the dos fs > On a slightly unrelated point - can anyone tell me how much faster or slower > gcc 1.42 is at compiling things compared to say gcc 2.5.x or 2.6.x? Quite a bit. GCC 1.42 was much leaner and meaner! :-) We've recently started running gcc through gcov and gprof. We hope to make it run faster, cause it's a bloated beast these days. - rob - From vandys@glare.cisco.com Thu Feb 16 09:43:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA04142; Thu, 16 Feb 1995 09:43:10 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA05596 for ; Thu, 16 Feb 1995 10:21:02 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA06327; Thu, 16 Feb 1995 19:20:35 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA42069; Thu, 16 Feb 1995 19:55:04 +0100 Date: Thu, 16 Feb 1995 19:55:04 +0100 Message-Id: <9502161855.AA42069@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Problem with kernel without debug From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, did anybody hit the same problem as me? Dave posted some very good timings, while I find the standard v133 kernel eating something between 256 to 271 us per msg_send() (with some peaks down to 178us). Thus I thought I should meansure it for the kernel compiled without DEBUG. Easy to do: I removed the -DDEBUG from the makefile recompiled, booted by godb.bat and: Assertion failed line 118 file ../mach/trap.c trap: kernel fault [Kernel debugger] >tf Trap type PGFLT err 0x2 eip 0x10:0x697d eax 0x0 ebx 0x0 ecx 0x1fff800 edx 0x1fff800 esi 0x0 edi 0x1ff98c0 esp 0xc02f78:0x1fff800 ebp 0xc02f4c eflags 0x10002 >bt [....] trap... retuser(0x1ff9940... called from msg_receive+d4 msg_receive(0x20, 0x7fffff70, 0x401148, 0x20) called from syscall+e0 syscall(0xc02fc0) callde from trap+31 trap(0x2b002b, 0x0, 0x0, 0x7fffffa4) called from trap_common+10 Anyone how knows? /Jerry ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | http://www.inf.tu-dresden.de/~jw6 Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 From vandys@glare.cisco.com Thu Feb 16 16:03:36 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA04218; Thu, 16 Feb 1995 16:03:34 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA18021; Thu, 16 Feb 1995 16:41:37 -0800 Message-Id: <199502170041.QAA18021@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Cc: VSTa mailing list Subject: Re: vsta on biprocessors pentium In-Reply-To: Your message of "Wed, 15 Feb 1995 09:21:50." <9502150821.AA00345@rosser.serma.cea.fr> Date: Thu, 16 Feb 1995 16:41:37 -0800 From: Andrew Valencia [basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) writes:] >Some manufacturers are making biprocessors pentium 90 motherboards. >I'm considering buying such a thing. >Does it make sense? >Are such motherboards useable? I'm told (by friends in the PC system business) that the current breed of dual-Pentium motherboards are pretty bad. Some of them which have come out in the last month or two are better. >Can VSTa be easily adapted to biprocessor operations? Yes. It's a simple matter of programming. :-) >Can these motherboards run (in monoprocessor mode) popular OSes such >as Linux? I understand that one of the CPUs remains offline until you take a particular action. >Does anyone have hints, feature to check (eg cache consistency between >both processors), motherboard brands to avoid, etc? You want a coherent physical cache if at all possible. Bus snooping is higly desirable, otherwise you have to be shooting down cache lines as you do DMA. I'll try and ping my friends about particular brands. Andy From vandys@glare.cisco.com Fri Feb 17 03:49:49 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA04284; Fri, 17 Feb 1995 03:49:48 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA08911 for ; Fri, 17 Feb 1995 04:27:53 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa03703; 17 Feb 95 12:27 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rfRc1-000398C; Fri, 17 Feb 95 12:16 GMT Message-Id: From: Dave Hudson Subject: Re: Problem with kernel without debug To: VSTa mailing list Date: Fri, 17 Feb 1995 12:16:41 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1020 Hi, Joerg Wittenberger wrote: > > Hi, > > did anybody hit the same problem as me? Yes - it's one of the things I clobbered in the 260k's worth of diffs I mailed to Andy yesterday :-) > Dave posted some very good timings, while I find the standard v133 > kernel eating something between 256 to 271 us per msg_send() (with > some peaks down to 178us). Thus I thought I should meansure it for the > kernel compiled without DEBUG. Typically it costs us between 15 and 20%, although when you get in cache handling on a 486 this can sometimes work for us and speed up some ops. 15-20 is a good rule of thumb. > Easy to do: I removed the -DDEBUG from the makefile recompiled, booted > by godb.bat and: I can't remember exactly what the issue was here, but I think there was a tlb flush operation that wasn't handled correctly. If you're interested I can mail you my latest development kernel - this should be a much simpler task than before as all the proc stuff from 1.3.3 will work with it. Regards, Dave From vandys@glare.cisco.com Fri Feb 17 07:59:08 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA04309; Fri, 17 Feb 1995 07:59:07 -0800 Received: from obelix.cs.UMD.EDU (obelix.cs.umd.edu [128.8.128.192]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA23228; Fri, 17 Feb 1995 08:37:13 -0800 Received: by obelix.cs.UMD.EDU (8.6.9/UMIACS-0.9/04-05-88) id LAA06222; Fri, 17 Feb 1995 11:37:11 -0500 Message-Id: <199502171637.LAA06222@obelix.cs.UMD.EDU> To: Andrew Valencia Cc: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH), VSTa mailing list Subject: Re: vsta on biprocessors pentium Date: Fri, 17 Feb 1995 11:37:10 -0500 From: James da Silva Andy writes: > [basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) writes:] > > >Some manufacturers are making biprocessors pentium 90 motherboards. > >I'm considering buying such a thing. > >Does it make sense? > >Are such motherboards useable? > > I'm told (by friends in the PC system business) that the current breed of > dual-Pentium motherboards are pretty bad. Some of them which have come out > in the last month or two are better. One big problem is that that the current low-end crop share the L2 cache, so the amount of parallelism you get is limited to the extent that the pentiums run out of their internal cache. I've heard numbers like 15%-20%. > >Can these motherboards run (in monoprocessor mode) popular OSes such > >as Linux? > > I understand that one of the CPUs remains offline until you take a > particular action. Yes, definitely - the second processor has to be explicitly activated. > >Does anyone have hints, feature to check (eg cache consistency between > >both processors), motherboard brands to avoid, etc? > > You want a coherent physical cache if at all possible. Bus snooping is > higly desirable, otherwise you have to be shooting down cache lines as > you do DMA. The Intel MP Spec, which these boards adhere to, requires that the hardware maintain cache coherency, transparent to the OS. The OS does have to do TLB shootdowns. You can get the Intel MP spec in postscript from the Intel on-line document repository at www.intel.com. You do have to fill out a 'registration' form to get access to the documents. The intel pentium book also has a chapter detailing the on-chip APIC and multiprocessing support. I just bought an ASUS P54NP4 dual processor board, but I haven't started MP hacking on it yet. At least the first processor runs well. :-) With just 15-20% performance improvement, for double the cost, I wouldn't recommend the shared L2 cache dual pentiums to anyone, UNLESS you specifically want to hack on SMP support on the cheap, like me. Jaime ............................................................................... : James da Silva : UCMP Computer Science Dept. : Stand on my shoulders, : : jds@cs.umd.edu : http://www.cs.umd.edu/~jds : not on my toes. : From vandys@glare.cisco.com Wed Feb 22 07:13:28 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA04906; Wed, 22 Feb 1995 07:13:27 -0800 Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA29462 for ; Wed, 22 Feb 1995 07:52:04 -0800 Received: by atc.boeing.com (5.57) id AA28655; Wed, 22 Feb 95 07:56:32 -0800 Received: from elvis.ds.boeing.com by splinter.boeing.com with SMTP (1.37.109.14/16.2) id AA015468260; Wed, 22 Feb 1995 07:51:01 -0800 Received: from wyeth.ds.boeing.com by elvis.ds.boeing.com (4.1/SMI-4.1) id AA27719; Wed, 22 Feb 95 07:34:29 PST Received: by wyeth.ds.boeing.com (920330.SGI/931108.SGI.AUTO.ANONFTP) for @elvis.ds.boeing.com:vsta@cisco.com id AA20711; Wed, 22 Feb 95 07:51:55 -0800 Date: Wed, 22 Feb 95 07:51:55 -0800 From: blair@wyeth.ds.boeing.com (Rick Blair) Message-Id: <9502221551.AA20711@wyeth.ds.boeing.com> To: vsta@cisco.com Subject: Help with Booting To All; I seem to have a small problem with booting Vsta. system 486Dx2 66 clone 1 IDE hard disk VGA card and monitor DOS 5 after typeing go in the boot directory I get I/O error read wanted 16384 got 8160. This appears after Init is printed. Thanks in advance. Stumped in Seattle Rick *************************************************** * email: blair@elvis.ds.boeing.com * * voice: (206)773-8962 * * usSnail: P.O. Box 3707 M/S 3E-28 * * Seattle, Wa 98124 * * * *Disclaimer: The contents of this message in no * * way reflects the Opinions either real* * or imaginary of the Boeing Company. * * All Opinions/rantings are my own and * * only I am responsible for them. * *************************************************** From vandys@glare.cisco.com Wed Feb 22 10:33:59 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA04924; Wed, 22 Feb 1995 10:33:58 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA27358; Wed, 22 Feb 1995 11:12:33 -0800 Message-Id: <199502221912.LAA27358@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: blair@wyeth.ds.boeing.com (Rick Blair) Cc: vsta@cisco.com Subject: Re: Help with Booting In-Reply-To: Your message of "Wed, 22 Feb 1995 07:51:55 PST." <9502221551.AA20711@wyeth.ds.boeing.com> Date: Wed, 22 Feb 1995 11:12:32 -0800 From: Andrew Valencia [blair@wyeth.ds.boeing.com (Rick Blair) writes:] >I get I/O error read wanted 16384 got 8160. >This appears after Init is printed. You mean the message: I/O error during read: want %d got %d I assume. It appears that your files have gotten corrupted somehow. This is a DOS C program doing a filesystem read of a DOS file. Either the file was truncated somehow, or you have a TSR interfering with the I/O. Andy From vandys@glare.cisco.com Wed Feb 22 17:06:41 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA04980; Wed, 22 Feb 1995 17:06:40 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA14014 for ; Wed, 22 Feb 1995 17:45:16 -0800 Received: from punt.demon.co.uk by post.demon.co.uk id ac08065; 22 Feb 95 23:45 GMT Received: from humbug.demon.co.uk by punt.demon.co.uk id aa21146; 22 Feb 95 21:17 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rhO6Z-0002agC; Wed, 22 Feb 95 20:56 GMT Message-Id: From: Dave Hudson Subject: Re: Help with Booting To: blair@wyeth.ds.boeing.com Date: Wed, 22 Feb 1995 20:56:15 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 678 Hi, Rick Blair wrote: > > I get I/O error read wanted 16384 got 8160. > > This appears after Init is printed. The problem sounds like one of the boot files listed in boot.lst (or maybe the kernel file "vsta") isn't quite right. If it's the error I believe it is then one of the files is probably too short as "seg.c" is reporting that it expected more data. Another alternative could be that one of the files has a data corruption in its a.out header. With a standard 1.3.3 system I reckon the file sizes should be: vsta - 106496 namer - 45056 cons - 49152 wd - 49152 dos - 57344 swap - 40960 init - 40960 Let me know if it's something else :-) Regards, Dave From vandys@glare.cisco.com Wed Feb 22 20:34:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA04994; Wed, 22 Feb 1995 20:34:08 -0800 Received: from ogion.mcs.kent.edu (ogion.mcs.kent.edu [131.123.2.53]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA24036 for ; Wed, 22 Feb 1995 21:12:46 -0800 Received: from localhost.ARPA by ogion.mcs.kent.edu (930416.SGI/92.09.25) id AA25166; Thu, 23 Feb 95 00:07:16 -0500 Message-Id: <9502230507.AA25166@ogion.mcs.kent.edu> Reply-To: sjc@mcs.kent.edu To: Andy Bond , Roy Campbell , John Carter , Ray Cline , "David W. Forslund" , Richard Freund , James Griffioen , Andrew Grimshaw , Debra Hensgen , Pete Keleher , Ted Lewis , Darrell Long , Shawn Ostermann , Larry Peterson , Paul Pierce , Peter Reiher , Vince Russo , Mukesh Singhal , Vaidy Sunderam , Jonathan Turner , Steve Wheat , Raj Yavatkar , SASOS mailing list , VSTa mailing list From: "Steve Chapin" Zevon-Of-The-Day: Accidentally Like a Martyr Subject: CFP: HICSS-29 minitrack on parallel/dist. OS Date: Thu, 23 Feb 1995 00:07:16 -0500 Sender: sjc@mcs.kent.edu Folks, Enclosed is a CFP for a minitrack that Barney Maccabe and I are running at the next HICSS. We cordially invite you to submit a paper or consider being a referee for us. C'mon out and visit Maui! Regards, sc -- Call For Papers and Referees in The Parallel and Distributed Operating Systems Minitrack of the 29th Hawaii International Conference on System Sciences, HICSS-29 Maui, Hawaii - January 3-6, 1996 ********************************************************************* We are seeking manuscripts and referees for our minitrack in Parallel and Distributed Operating Systems at HICSS-29. We are especially interested in papers in the following areas: o heterogeneous multiprocessor operating systems: program representation for multiple architectures, architecture-independent operating system services, and scheduling in heterogeneous distributed systems; o low-overhead protocols for high-speed networks: ATM networks, lightweight remote procedure call, and active messages; o parallel operating systems in general: support for repartitionable parallel architectures, parallel operating system structure, message-passing operating systems, and locking mechanisms; o distributed operating systems in general: microkernel organization, distributed deadlock detection, distributed mutual exclusion, and transaction support; o distributed shared memory: coherency mechanisms, scalable approaches to DSM, and single address space operating systems; o cache coherency in multiprocessor systems: operating system support for extensible caching policies, and new cache coherence protocols; o and scheduling in multiprocessor systems: local and global scheduling, dynamic and static scheduling, and scheduling for meta-systems. Those papers selected for presentation will appear in the Conference Proceedings, published by the IEEE Computer Society. We are finalizing arrangements for the best papers from this minitrack to appear in a special issue of IEEE Parallel and Distributed Technology. Submit your 300-word (one page) abstract to Steve Chapin (see address below). Persons interested in refereeing in these areas should contact the minitrack coordinators directly. Electronic submission of PostScript or ASCII abstracts is preferred. Details on submissions of full papers will be released at a later date. COORDINATORS ------------ Steve J. Chapin Department of Mathematics and Computer Science Kent State University Kent, OH 44242 sjc@mcs.kent.edu Arthur B. Maccabe Department of Computer Science University of New Mexico Albuquerque, NM 87131-1386 maccabe@cs.unm.edu 1995 Deadlines ************** o A 300-word abstract by March 15 o Feedback to author on abstract by April 3 o Eight copies of the manuscript by June 1 o Notification of accepted papers by August 31 o Camera-ready copies of accepted manuscripts are due by October 2 Steve Chapin Barney Maccabe sjc@mcs.kent.edu maccabe@cs.unm.edu From vandys@glare.cisco.com Thu Feb 23 07:32:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA05146; Thu, 23 Feb 1995 07:32:19 -0800 Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA00826; Thu, 23 Feb 1995 08:11:00 -0800 Received: by atc.boeing.com (5.57) id AA17170; Thu, 23 Feb 95 08:15:29 -0800 Received: from elvis.ds.boeing.com by splinter.boeing.com with SMTP (1.37.109.14/16.2) id AA078685804; Thu, 23 Feb 1995 08:10:04 -0800 Received: from wyeth.ds.boeing.com by elvis.ds.boeing.com (4.1/SMI-4.1) id AA12464; Thu, 23 Feb 95 07:53:25 PST Received: by wyeth.ds.boeing.com (920330.SGI/931108.SGI.AUTO.ANONFTP) for @elvis.ds.boeing.com:vsta@cisco.com id AA08830; Thu, 23 Feb 95 08:09:03 -0800 Date: Thu, 23 Feb 95 08:09:03 -0800 From: blair@wyeth.ds.boeing.com (Rick Blair) Message-Id: <9502231609.AA08830@wyeth.ds.boeing.com> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: <199502221912.LAA27358@glare.cisco.com> (message from Andrew Valencia on Wed, 22 Feb 1995 11:12:32 -0800) Subject: Re: Help with Booting Andy, Thanks for your help! I made a boot disk and loaded only the minimum needed to boot dos. All is now Right with the world. Thanks. I also wish to thank all who came to my aid. I look forward to corresponding with this list in the future. Thanks Rick -- *************************************************** * email: blair@elvis.ds.boeing.com * * voice: (206)773-8962 * * usSnail: P.O. Box 3707 M/S 3E-28 * * Seattle, Wa 98124 * * * *Disclaimer: The contents of this message in no * * way reflects the Opinions either real* * or imaginary of the Boeing Company. * * All Opinions/rantings are my own and * * only I am responsible for them. * *************************************************** From vandys@glare.cisco.com Tue Feb 28 21:07:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA05994; Tue, 28 Feb 1995 21:07:11 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id VAA25144 for ; Tue, 28 Feb 1995 21:46:25 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.10/8.6.10) id WAA02012 for vsta@cisco.com; Tue, 28 Feb 1995 22:46:21 -0700 Date: Tue, 28 Feb 1995 22:46:21 -0700 From: Gary Shea Message-Id: <199503010546.WAA02012@xmission.xmission.com> To: vsta@cisco.com Subject: vsta 1.3.3 feedback Content-Length: 766 Just installed and built vsta 1.3.3. Most impressive improvement! 1) I can build the shared libraries now! Used to die (out of memory). 2) Only crashed once (out of memory) on the build, as opposed to something like 8 times for 1.3.2. 3) ls no longer prints out the contents of files. And sorting... wow! 4) rcs! One possible bug. I added my semaphore stuff to the libc makefile and rebuilt. When I went to compile the test program, it would only link with -lc_s -- not specifying a library (i.e., defaulting to -lc) resulted in linker errors. Seems like libc.a isn't getting properly rebuilt? I don't know if anything has changed since in 1.3.2 I had to use libc.a, and I'd hacked the 1.3.2 makefile to eliminate libc_s.a. Nice work everyone! Gary From vandys@glare.cisco.com Wed Mar 1 05:47:57 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA06112; Wed, 1 Mar 1995 05:47:55 -0800 Received: from fcr.fcr.com (fcr.FCR.Com [198.6.104.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id GAA29947 for ; Wed, 1 Mar 1995 06:27:12 -0800 Received: from foxharp.UUCP by fcr.fcr.com (8.6.9/8.6.9) with UUCP id JAA22442 for vsta@cisco.com; Wed, 1 Mar 1995 09:27:11 -0500 Received: from foxharp.UUCP by fcr.fcr.com (8.6.9/8.6.9) with UUCP id JAA22442 for vsta@cisco.com; Wed, 1 Mar 1995 09:27:11 -0500 Received: by foxharp: id m0rjp8q-0004EPC; Wed, 1 Mar 95 09:12 EST Message-Id: To: vsta@cisco.com Subject: Re: vsta 1.3.3 feedback In-Reply-To: shea's message of Tue, 28 Feb 1995 22:46:21 -0700. <199503010546.WAA02012@xmission.xmission.com> Reply-To: pgf@foxharp.boston.ma.us Date: Wed, 01 Mar 1995 09:12:40 -0500 From: Paul Fox > > 4) rcs! > if anyone's interested, i have a set of patches for RCS 5.6 which let one build against a "search path" of rcs branches, using branches that are further down the path as "backstops", which would contain the stable files that you're not changing while working on some particular feature. you could set up, for instance: RCS_BRANCHES="my_stuff .his_build .vsta_133" to force rcs to first find files on the branch "my_stuff", then from "his_build", and finally from the release. the '.' characters mark the 2nd and 3rd branches as "read-only", so you don't inadvertently check something in on them. i know CVS accomplishes much of this as well, but it's a much bigger system than this. i only mention these patches because the number of people developing vsta is fairly small, and the amount of code is fairly small, and at my last company we found this system of branches, along with the standard rcsmerge tools to be pretty workable for a small group of developers.... paul --------------------- paul fox, pgf@foxharp.boston.ma.us (arlington, ma) "And where were you at 00:00:00 GMT, January 1, 1970?" From vandys@glare.cisco.com Wed Mar 1 06:48:04 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA06126; Wed, 1 Mar 1995 06:48:03 -0800 Received: from mercan.cmpe.boun.edu.tr (arslan@mercan.cmpe.boun.edu.tr [193.140.196.80]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id HAA04201 for ; Wed, 1 Mar 1995 07:26:53 -0800 Received: (from arslan@localhost) by mercan.cmpe.boun.edu.tr (8.6.10/8.6.9) id RAA06669; Wed, 1 Mar 1995 17:32:19 +0300 Date: Wed, 1 Mar 1995 17:32:18 +0300 (EET) From: Gunay Arslan - CompeC baskani To: Paul Fox Cc: vsta@cisco.com Subject: Re: vsta 1.3.3 feedback In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Where can I find first versions of VSTA OS ?? I am a student yet ,and I wonder the source code of it.I want to look at the main principle of the Vsta system ( I need small code size ) Gunay Arslan From vandys@glare.cisco.com Wed Mar 1 07:12:03 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA06132; Wed, 1 Mar 1995 07:12:02 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA05661 for ; Wed, 1 Mar 1995 07:51:15 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA20292; Wed, 1 Mar 95 10:51:10 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA26130; Wed, 1 Mar 95 10:51:07 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA20542; Wed, 1 Mar 95 10:51:05 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA16643; Wed, 1 Mar 95 10:51:04 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA15485; Wed, 1 Mar 95 10:51:02 EST Date: Wed, 1 Mar 95 10:51:02 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503011051.ZM15483@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Debugging a Boot Server Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I am trying to debug a boot server and I want how to attach ADB directly to the server, or the procedure for killing off the server and restarting it under ADB. Right now I am using syslog to print out tracing messages, but the turnaround time between debugging sessions is a little long. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Wed Mar 1 08:29:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA06146; Wed, 1 Mar 1995 08:29:11 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA11909 for ; Wed, 1 Mar 1995 09:08:27 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21723; 1 Mar 95 17:06 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rjroU-0003H6C; Wed, 1 Mar 95 17:03 GMT Message-Id: From: Dave Hudson Subject: Re: Debugging a Boot Server To: David Koogler Date: Wed, 1 Mar 1995 17:03:50 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9503011051.ZM15483@crozet> from "David Koogler" at Mar 1, 95 10:51:02 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 465 Hi, David Koogler wrote: > > I am trying to debug a boot server and I want how to attach ADB directly to the > server, or the procedure for killing off the server and restarting it under > ADB. > Right now I am using syslog to print out tracing messages, but the turnaround > time between debugging sessions is a little long. For say wd (with a pid 4), try: adb /vsta/boot/wd 4 It works best if the a.out image isn't stripped though. Regards, Dave From vandys@glare.cisco.com Wed Mar 1 10:36:32 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA06180; Wed, 1 Mar 1995 10:36:31 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA09252; Wed, 1 Mar 1995 11:15:48 -0800 Message-Id: <199503011915.LAA09252@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: koogler@bedford.progress.com (David Koogler) Cc: vsta@cisco.com Subject: Re: Debugging a Boot Server In-Reply-To: Your message of "Wed, 01 Mar 1995 10:51:02 EST." <9503011051.ZM15483@crozet> Date: Wed, 01 Mar 1995 11:15:48 -0800 From: Andrew Valencia [koogler@bedford.progress.com (David Koogler) writes:] >I am trying to debug a boot server and I want how to attach ADB directly to th >e >server, or the procedure for killing off the server and restarting it under >ADB. >Right now I am using syslog to print out tracing messages, but the turnaround >time between debugging sessions is a little long. Note that if you're attaching to, say, the wd or dos server, you probably want to copy the a.out for the server AND the adb command to /tmp, and run/debug from there. Otherwise you can deadlock when your a.out stops for the debugger and your debugger process page faults a page in from the filesystem which is stopped. Andy From vandys@glare.cisco.com Fri Mar 3 06:52:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA06652; Fri, 3 Mar 1995 06:52:47 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA09018 for ; Fri, 3 Mar 1995 07:32:13 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA22275; Fri, 3 Mar 95 10:32:05 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA21038; Fri, 3 Mar 95 10:32:01 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA17477; Fri, 3 Mar 95 10:31:58 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA14307; Fri, 3 Mar 95 10:31:58 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA18457; Fri, 3 Mar 95 10:31:56 EST Date: Fri, 3 Mar 95 10:31:56 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503031031.ZM18455@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Linking: /vsta/lib or /vsta/libc? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii What directory should we be linking against: /vsta/lib or /vsta/libc? I would expect to link with the first directory, since that is where the libraries get installed by the Makefile found in /vsta/libc. However, most of the Makefiles for the servers and applications refer to /vsta/libc. Though the two directories are generally equivalent, consistent usage removes a some unnecessary confusion. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Fri Mar 3 09:51:54 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA06677; Fri, 3 Mar 1995 09:51:53 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA19437; Fri, 3 Mar 1995 10:31:22 -0800 Message-Id: <199503031831.KAA19437@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: koogler@bedford.progress.com (David Koogler) Cc: vsta@cisco.com Subject: Re: Linking: /vsta/lib or /vsta/libc? In-Reply-To: Your message of "Fri, 03 Mar 1995 10:31:56 EST." <9503031031.ZM18455@crozet> Date: Fri, 03 Mar 1995 10:31:21 -0800 From: Andrew Valencia [koogler@bedford.progress.com (David Koogler) writes:] >What directory should we be linking against: /vsta/lib or /vsta/libc? I would >expect to link with the first directory, since that is where the libraries get >installed by the Makefile found in /vsta/libc. However, most of the Makefiles >for the servers and applications refer to /vsta/libc. Though the two >directories are generally equivalent, consistent usage removes a some >unnecessary confusion. You have to draw a distinction between compiles done by a user under an installed operating system, and the build process for the operating system itself. /vsta/libc is the source, and holds the .o/.a's as built from current source. Other directories use this, so that when you're done you have a set of executables which are compiled and linked against the latest libraries and objects as built from current source. When this is all happy & good, you then install them in /vsta/lib. Then innocent gcc's from your home directory, for instance, compile and link against the installed versions of the objects. Handwave for include files. They should be broken out similarly, but aren't (yet). Andy From vandys@glare.cisco.com Fri Mar 3 11:48:17 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA06702; Fri, 3 Mar 1995 11:48:14 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA03303 for ; Fri, 3 Mar 1995 12:27:43 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rkdwJ-000uK3C; Fri, 3 Mar 95 10:27 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Re: Linking: /vsta/lib or /vsta/libc? To: koogler@bedford.progress.com (David Koogler) Date: Fri, 3 Mar 1995 10:27:07 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <9503031031.ZM18455@crozet> from "David Koogler" at Mar 3, 95 10:31:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 796 > What directory should we be linking against: /vsta/lib or /vsta/libc? I would > expect to link with the first directory, since that is where the libraries get > installed by the Makefile found in /vsta/libc. However, most of the Makefiles > for the servers and applications refer to /vsta/libc. Though the two > directories are generally equivalent, consistent usage removes a some > unnecessary confusion. The source directory is named libc. The libs should be copied over to the lib directory and programs should link against the copies in lib. I'm not sure why all the servers link against libc. Perhaps it was to make it easier to rebuild as the libs were evolving. This was one of the first things I changed in my copy of the tree. > David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Sun Mar 5 20:22:23 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA07010; Sun, 5 Mar 1995 20:22:22 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA23341; Sun, 5 Mar 1995 21:02:01 -0800 Message-Id: <199503060502.VAA23341@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: Kernel diffs In-Reply-To: Your message of "Mon, 06 Mar 1995 01:27:24 GMT." Date: Sun, 05 Mar 1995 21:02:00 -0800 From: Andrew Valencia (This is Cc to the list, as some of this might be of general interest) Hi, Dave. Got your performance diffs (+ my hacks to your diffs) running over the weekend. Biggest problem was the new sm_to_m() didn't move the sender back into m_sender, leaving the servers rather clueless as to what value to msg_accept(). I'm still digging through the rest of the diffs you sent to figure out how it was working for you. syscall argument handling was indeed broken, as was copyin/copyout, which no longer used the t_probe to protect themselves. This was all rather hidden by the fault handling code, which assumed that any reference to a virtual address in the 0x80000000..0xffffffff range should result in the current process being killed. Very questionable in any case, but spectacular when it happens from an interrupt handler with no current process! MALLOC()/FREE() are now inline (if not DEBUG) accesses to the buckets. The code is good, but gcc 2.X would do better, as 1.X has limitations in static evaluation within nested inline functions. Limitations with expansion of nested inline functions in general, in fact. Perhaps it's finally time to move on to 2.X, although I fear my 8 meg machine is too small. If I can't compile on my laptop development will take a big hit; I do most of my work riding the train to work. How big *is* 2.X, anyway? I also finally got around to the source reorg, with os->src/os, bin.src->src/bin, libc->src/lib, and the source parts of boot->src/boot. bin.src/test is now much more sensibly src/bin/cmds. We should sync up with source very soon, to avoid drift as much as possible. A friend has assembled a 50 Mhz 486 box for use by the VSTa project on the Internet. It's outside the firewall, so we can implement any networking scheme we'd like. I'd like to export the /vsta filesystem and allow folks to do source code control over a networked VSTa filesystem. This requires the small matter of a /inet server and some sort of scheme for mapping the filesystem protocol onto TCP messages. I think having that box sitting there will bother me until I get it running! Oh, yes, fgetc() wasn't binary clean. Those internal stdio buffers should be uchar. I wrote a quick strings(1) which made this obvious. Regards, Andy From vandys@glare.cisco.com Sun Mar 5 22:40:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA07021; Sun, 5 Mar 1995 22:40:10 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA19607 for ; Sun, 5 Mar 1995 23:19:54 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rlX4r-000uKgC; Sun, 5 Mar 95 21:19 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Amiga progress To: vsta@cisco.com (VSTa Mailing List) Date: Sun, 5 Mar 1995 21:19:36 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1275 Hi, I got a couple of hours in this weekend. I finally got init + login + sh up and running. This is all on the 1.3.3 source base. I have the normal processes being run from init: env, pipe, tmpfs, etc.. though I havent tested them all out yet. Was able to login, run hello.c and logout and do it all again. I didn't fix any VM bugs so either the VM problem I was having before was due to the old version of vsta I was based on or compiler problems or some subtle bug in another part of the system. I am starting to suspect my compiler. It is pretty old (gcc2.2.2 which I had on my system for a few years now). I have noticed some other strange problems that go away when I make simple changes and recompile and then come back again a bit later after more recompiles. Anyway.. I'm in a pretty good mood and thought I'd share. Still lots of work to do: cleanup of just about everything I've done merge my dos server with 1.3.3 merge my cam with 1.3.3 get cons2 working instead of cons/kbd smart boot program that doesnt have compiled in parameters amiga server to arbitrate amiga-specific resources. The filesystem seems a bit slow. I think its both the dos server and endian conversions and my cam code. Tim N. From vandys@glare.cisco.com Mon Mar 6 02:20:34 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA07119; Mon, 6 Mar 1995 02:20:32 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA28700; Mon, 6 Mar 1995 03:00:16 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa00635; 6 Mar 95 10:59 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rlaQa-0003LMC; Mon, 6 Mar 95 10:54 GMT Message-Id: From: Dave Hudson Subject: Re: Kernel diffs To: Andrew Valencia Date: Mon, 6 Mar 1995 10:54:16 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199503060502.VAA23341@glare.cisco.com> from "Andrew Valencia" at Mar 5, 95 09:02:00 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1352 Hi Andy, Andrew Valencia wrote: > I just thought about this one a little more... > syscall argument handling was indeed broken, as was copyin/copyout, which no > longer used the t_probe to protect themselves. This was all rather hidden > by the fault handling code, which assumed that any reference to a virtual > address in the 0x80000000..0xffffffff range should result in the current > process being killed. Very questionable in any case, but spectacular when > it happens from an interrupt handler with no current process! Two things puzzle me a little about this - if a process attempts to use an invalid pointer reference when calling a syscall I'd have thought it pretty reasonable to notify a fault? It's trying to do something naughty - much as if it was trying to do a NULL pointer reference. The query is what circumstances would cause one of our interrupt handlers to attempt to do anything with user-space? I thought all we did was queue an interrupt message, or call hardclock()? I guess it's not a great problem as the copyin()/copyout() code can be made to inline the t_probe stuff reasonably easily (I had it do this a while back), but I'm trying to understand what I missed. I've clocked up days of uptime without seeing any problems with this code - both with heavy (loadavg > 5) and no loading). Regards, Dave From vandys@glare.cisco.com Mon Mar 6 14:27:32 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA07193; Mon, 6 Mar 1995 14:27:31 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA25042 for ; Mon, 6 Mar 1995 15:07:12 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA23851; Mon, 6 Mar 95 18:07:01 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA05023; Mon, 6 Mar 95 18:06:59 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA28644; Mon, 6 Mar 95 18:06:59 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA09090; Mon, 6 Mar 95 18:06:58 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA20813; Mon, 6 Mar 95 18:06:53 EST Date: Mon, 6 Mar 95 18:06:53 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503061806.ZM20811@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Reading the Console Keyboard Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm trying to find a way to read the console keyboard directly, without having to wait and without having to hit return. It should be simple, but I can not find a straight forward example. I would think that I could open a read-only connection with the console and request single characters at a time (using the no block option). Unfortunately I just can't seem to get all of the right pieces together to write the code. I desperately need an example -- help! -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Mon Mar 6 14:42:22 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA07197; Mon, 6 Mar 1995 14:42:20 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA21321; Mon, 6 Mar 1995 15:22:06 -0800 Message-Id: <199503062322.PAA21321@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: koogler@bedford.progress.com (David Koogler) Cc: vsta@cisco.com Subject: Re: Reading the Console Keyboard In-Reply-To: Your message of "Mon, 06 Mar 1995 18:06:53 EST." <9503061806.ZM20811@crozet> Date: Mon, 06 Mar 1995 15:22:05 -0800 From: Andrew Valencia [koogler@bedford.progress.com (David Koogler) writes:] >I'm trying to find a way to read the console keyboard directly, without having >to wait and without having to hit return. It should be simple, but I can not >find a straight forward example. Well, if you don't mind building a VSTa request directly... #include #include main() { port_t port; struct msg m; uchar buf[128]; int x, y; /* * Open port to console server, screen #0 */ port = path_open("tty/cons:0"); /* * Or use port attached to standard input * port = __fd_port(0); */ /* * Here's your chance to do some typeahead */ printf("Type some stuff\n"); sleep(1); /* * Send read request, "everything you have" (m_arg == 0) */ m.m_op = FS_READ | M_READ; m.m_arg = 0; m.m_nseg = 1; m.m_buf = buf; m.m_buflen = sizeof(buf); x = msg_send(port, &m); /* * Dump it */ printf("Got back %d\n", x); for (y = 0; y < x; ++y) { printf(" %02x", buf[y]); } printf("\n"); return(0); } From vandys@glare.cisco.com Mon Mar 6 15:14:37 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA07201; Mon, 6 Mar 1995 15:14:35 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id PAA28256 for ; Mon, 6 Mar 1995 15:54:23 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.10/8.6.10) id QAA18379; Mon, 6 Mar 1995 16:54:10 -0700 Date: Mon, 6 Mar 1995 16:54:10 -0700 From: Gary Shea Message-Id: <199503062354.QAA18379@xmission.xmission.com> To: vsta@cisco.com Subject: semaphores, thread-safe alloc wrappers Cc: shea@xmission.xmission.com Content-Length: 1664 The thread-synchronization tools finally seem to be working. Check 'em out: ftp://ftp.xmission.com/pub/users/s/shea/tsema.tz The readme has an annotated manifest, duplicated below: include/slock.h // spinlock def'ns include/libsem.h // fixed-length-queue sema def'ns include/tsafe.h // alloc/free wrapper def'ns include/tsema.h // user semaphore def'ns include/sys/tsleep.h // tsleep/twake sys calls libc/slock.c // spinlock implementations libc/libsem.c // fixed-length-queue sema implementation libc/tsafe.c // alloc/free wrapper functions libc/tsema.c // user semaphore implementation libc/mach/slockasm.s // spinlock test'n'set os/kern/tsleep.c // tsleep/twake implementation /gts/libsem/makefile // test code /gts/libsem/tl.c /gts/tsema/makefile // test code /gts/tsema/ts.c ../d.133 // patches for clean vsta.1.3.3 The tsema semaphore implementation is much simpler than the original -- at this point it's little more than libsem with the data structures hidden and no limit on the number of threads in the queue. The cost is a thread-safe malloc every time a thread must be queued. If you want the fastest possible semaphore or need to allocate the semaphore statically, AND you can bound the max number of threads the semaphore will need to queue, use the libsem implementation. Otherwise the tsema implementation is a bit simpler. The alloc/free wrappers are protected by a libsem semaphore. Its queue size is configurable BEFORE any wrapper function has been called. Threads beyond the queue size are put to sleep until there's queue space. Now I finally get to start working on the asynchronous buffer cache! Gary From vandys@glare.cisco.com Tue Mar 7 09:01:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA07326; Tue, 7 Mar 1995 09:01:45 -0800 Received: from ns-1.csn.net (root@ns-1.csn.net [199.117.27.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA00927 for ; Tue, 7 Mar 1995 09:41:36 -0800 Received: by ns-1.csn.net with UUCP id AA15268 (5.65c/IDA-1.4.4 for vsta@cisco.com); Tue, 7 Mar 1995 10:41:29 -0700 Received: by loon.probita.com (5.57/Probita 2/6/94) id AA12106; Tue, 7 Mar 95 08:16:13 -0700 Date: Tue, 7 Mar 95 08:16:13 -0700 From: blund@probita.com (Bob Lund) Message-Id: <9503071516.AA12106@loon.probita.com> To: vsta@cisco.com Subject: Vsta on Linux I recall seeing a reference to building vsta on linux and running it (vsta) on the linux file system. I am interested in pursuing this but unfortunately, I cannot find that reference anywhere. I'd appreciate any information on this topic and pointers to ftp sites for the code (if it exists), Thanks in advance Bob Lund blund@probita.com From vandys@glare.cisco.com Tue Mar 7 23:30:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA07417; Tue, 7 Mar 1995 23:30:41 -0800 Received: from trefle.saclay.cea.fr ([132.166.128.101]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id AAA29898 for ; Wed, 8 Mar 1995 00:10:35 -0800 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with ESMTP id JAA16153 for ; Wed, 8 Mar 1995 09:10:04 +0100 Received: from rosser.serma.cea.fr by oeillet.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with SMTP id JAA08576 ; Wed, 8 Mar 1995 09:11:24 +0100 Received: by rosser.serma.cea.fr (5.0/CEANET.2.0.1) id AA00545; Wed, 8 Mar 1995 09:11:01 --100 Date: Wed, 8 Mar 1995 09:11:01 --100 Message-Id: <9503080811.AA00545@rosser.serma.cea.fr> From: basile.starynkevitch@cea.fr To: blund@probita.com (Bob Lund) Cc: vsta@cisco.com Subject: Re: Vsta on Linux In-Reply-To: <9503071516.AA12106@loon.probita.com> References: <9503071516.AA12106@loon.probita.com> Content-Length: 4064 >>>>> "Bob" == Bob Lund writes: Bob> I recall seeing a reference to building vsta on linux and Bob> running it (vsta) on the linux file system. I am interested Bob> in pursuing this but unfortunately, I cannot find that Bob> reference anywhere. Bob> I'd appreciate any information on this topic and pointers to Bob> ftp sites for the code (if it exists), I'm the guy who did that, (with some help by others). But let me more precise; i've never talk about linux (syscalls) emulation. I just coded an ext2fs file server, compatible with Linux ext2fs filesystems. Currently it is for read-only filesystems. I cross-developped it (cross-compiling and cross-linking on Linux). I didn't have any feedback about it, so I didn't touched it since. If one person is interested by having ext2fs and test it I will continue (if time and God permits) to code it. Probably, the next goal is adding read-write access. But I want to have at least one person interested in testing (and someday using) it. The server was writter for vsta1.3.2; I didn't switch yet to 1.3.3! I wrote >> >> Date: Mon, 28 Nov 1994 10:36:35 --100 >> From: basile (Basile STARYNKEVITCH) >> To: VSTa mailing list >> Cc: Dave Hudson , >> Markus Friedl >> Subject: the first ALPHA release of ext2fs VSTa 0.1 -for testers only >> Content-Type: text >> Content-Length: 11360 >> >> >> Hello all, >> >> I'm annoucing the first alpha release of an ext2fs file server for >> VSTa. This is available by ftp to ftp://131.188.190.131/ with >> kind ftp hospitality from Markus Friedl (CIP 92) >> . >> >> I can also email gnu zipped uuencoded diff files to the >> e2fsprogs-0.5b-WIP.tar.gz distribution. >> >> >> ***************************************************************************** >> >> Announcing Extfs-VSTa 0.1 ALPHA (for testers only) >> -------------------------------------------------- >> >> This is the first announce of my first alpha release of extfs-VSTa, a >> port of Linux ext2fs file system to VSTa. This is *NOT* a public >> release, but only a release for ALPHA testers only. It is based upon >> (and contains) e2fsprogs-0.5b-WIP.tar.gz available on several Linux >> ftp sites. This is a derivative work of, since it is based upon, e2fs >> and libext2fs by Theodore Y. Ts'o and Remy Card (contained in this >> e2fsprogs-0.5b-WIP.tar.gz gnu zipped tar file). >> >> >> This is distributed >> >> as e2fs_0_1.tgz, a 341327 GNU zipped tar file containing the full modified >> e2fsprogs-0.5b-WIP.tar.gz file tree with my vsta extensions. >> >> or >> >> as e2fs.diff and e2fsvsta.diff as patches to be applied to the >> original e2fsprogs-0.5b-WIP.tar.gz. e2fs.diff (40070 bytes) contains >> the patches to e2fsprogs files (mostly adding #include >> ). e2fsvsta.diff ( 76449 bytes) is a patch file for >> creating the vsta specific source code files; it should be applied >> after the e2fs.diff patch file. >> >> I'm putting the files on ftp://131.188.190.131/incoming with kind >> permission of Markus Friedl (CIP 92)" >> . >> Actually it is on the same ftp site in /pub/VSTa/e2fs directory. ---------------------------------------------------------------------- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 46.65.45.53 email: basile.starynkevitch@cea.fr (redirected to basile@soleil.serma.cea.fr); ---------------------------------------------------------------------- N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Mon Mar 13 23:19:54 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA00482; Mon, 13 Mar 1995 23:19:53 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id AAA01771 for ; Tue, 14 Mar 1995 00:04:25 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Tue, 14 Mar 1995 18:04:19 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA26631; Tue, 14 Mar 95 18:04:38 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA04057; Tue, 14 Mar 1995 18:04:09 +1000 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199503140804.AA04057@sour.sw.oz.au> Subject: VSTa and chroot To: vsta@cisco.com (VSTa list) Date: Tue, 14 Mar 1995 18:04:08 +1000 (EST) Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Cc: vsta@cisco.com (VSTa list) Subject: Re: VSTa and chroot In-Reply-To: Your message of "Tue, 14 Mar 1995 18:04:08 +1000." <199503140804.AA04057@sour.sw.oz.au> Date: Tue, 14 Mar 1995 09:43:46 -0800 From: Andrew Valencia [jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) writes:] >I suppose what I'm really saying is "I still don't really understand >VSTa's permission/id system yet". Can you easily set up a filesystem >or part of a tree so that that is the entire universe as far as >one group of programs is concerned? It doesn't really matter if >they can tell they're in a restricted domain, so long as they can't >get out. One idea I've toyed with is adding a bitmask to the system calls and another bitmask to the process. A process could only invoke system calls if ((proc->p_mask & s->s_mask) != 0). For your scenario, the msg_connect() system call should be disabled. The process could then walk down current mount points, but could not access new servers. Other possibilities are disabling fork()/tfork()/clone() (perhaps a couple others). This would create an execution environment in which a process could serve requests but not much else. I see such restrictions as being mostly voluntary. A server would set up the minimal environment needed and then cut off its ability to access further resources. This would control damage in the event of a process being compromised due to malicious access. Andy From vandys@glare.cisco.com Tue Mar 14 11:43:19 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00611; Tue, 14 Mar 1995 11:43:18 -0800 Received: from mercan.cmpe.boun.edu.tr (arslan@mercan.cmpe.boun.edu.tr [193.140.196.80]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id MAA25320 for ; Tue, 14 Mar 1995 12:27:36 -0800 Received: (from arslan@localhost) by mercan.cmpe.boun.edu.tr (8.6.10/8.6.9) id WAA02438; Tue, 14 Mar 1995 22:32:54 +0300 Date: Tue, 14 Mar 1995 22:32:53 +0300 (EET) From: Gunay Arslan - CompeC baskani To: Vsta mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there a HTML home page for VSTA ???? I need it .. ______________________________________________________________________________ Gunay Arslan | CompeC Club Director ( Computer Club ) email: | URL http://mercan.cmpe.boun.edu.tr/~arslan gunay@boun.edu.tr | Bogazici University arslan@mercan.cmpe.boun.edu.tr | tel.0-212-2631540-1781 Istanbul/Turkey -------------------------------------------------------------------------------- From vandys@glare.cisco.com Wed Mar 15 05:02:32 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00697; Wed, 15 Mar 1995 05:02:31 -0800 Received: from sartre.minerva.bah.com (sartre.minerva.bah.com [156.80.175.13]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA05407 for ; Wed, 15 Mar 1995 05:47:17 -0800 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA29066; Wed, 15 Mar 95 08:47:51 -0500 Date: Wed, 15 Mar 95 08:47:51 -0500 From: Erik Quanstrom Message-Id: <9503151347.AA29066@sartre.minerva.bah.com> To: vsta@cisco.com Subject: server-based auth >One idea I've toyed with is adding a bitmask to the system calls and another >bitmask to the process. A process could only invoke system calls if >((proc->p_mask & s->s_mask) != 0). >For your scenario, the msg_connect() system call should be disabled. The >process could then walk down current mount points, but could not access new >servers. Other possibilities are disabling fork()/tfork()/clone() (perhaps >a couple others). This would create an execution environment in which a >process could serve requests but not much else. why not let the servers themselves do the authentication, a la the 9p? as in the message set Tauth Rauth erik From vandys@glare.cisco.com Wed Mar 15 07:07:30 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00704; Wed, 15 Mar 1995 07:07:28 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id HAA12620 for ; Wed, 15 Mar 1995 07:52:14 -0800 Received: from punt.demon.co.uk by post.demon.co.uk id js24814; 15 Mar 95 15:37 GMT Received: from humbug.demon.co.uk by punt.demon.co.uk id aa04719; 14 Mar 95 9:56 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0roSwh-00039aC; Tue, 14 Mar 95 09:31 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa and chroot To: Jeremy Fitzhardinge Date: Tue, 14 Mar 1995 09:31:18 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199503140804.AA04057@sour.sw.oz.au> from "Jeremy Fitzhardinge" at Mar 14, 95 06:04:08 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1229 Hi, Jeremy Fitzhardinge wrote: > > VSTa, of course, doesn't have the notion of chroot or any way of > implementing it: if mount tables are just libc constructs and > anyone can talk to a filesystem port then there's no point. Is > there, however, some way of doing something similar? Well to get the same effect we simply change our mount point to be partway through a fs hierarchy. An example would be that I can make server fs/dos1 (which say has the same dir structure as a standard vsta source tree) have an effective root of say /vsta/extern by mounting fs/dos1:vsta/extern as / > After a little more thought, it seems like you'd do it by creating > a new directory tree as the "chrooted" domain with an extra number > on the end of the ownership and run the processes in there with > the extra ID. This would prevent them from getting out so long > as there are no other filesystems with the same or more permissive > id. (Does this make any sense?) Effectively yes - the only thing that strikes me as a potential problem is the default ID offered by most fs's. For example the dos fs offers a default read permission on all files and dirs. Andy, any offers on how to get round this one? Regards, Dave From vandys@glare.cisco.com Wed Mar 15 12:30:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00737; Wed, 15 Mar 1995 12:30:55 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id NAA10085 for ; Wed, 15 Mar 1995 13:15:41 -0800 Received: from punt.demon.co.uk by post.demon.co.uk id ca25999; 15 Mar 95 21:11 GMT Received: from humbug.demon.co.uk by punt.demon.co.uk id aa03948; 14 Mar 95 16:14 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0roZE3-00039UC; Tue, 14 Mar 95 16:13 GMT Message-Id: From: Dave Hudson Subject: Joystick server code To: VSTa mailing list Date: Tue, 14 Mar 1995 16:13:39 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 468 Hi All, I'm just about to reimplement some of the internals of the joystick server. Some of what I'd like to do may not be 100% compatible with existing client code. I don't think anyone else is really using this code (I only wrote it to prove I could write a server :-)), but if you are, please let me know. FWIW with the kernel diffs I sent Andy for the timer code for v1.4 it should at least let me make the joystick code more reliable. Regards, Dave From vandys@glare.cisco.com Thu Mar 16 11:38:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01033; Thu, 16 Mar 1995 11:38:47 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id MAA18690 for ; Thu, 16 Mar 1995 12:23:31 -0800 Received: from punt.demon.co.uk by post.demon.co.uk id rg15343; 16 Mar 95 20:14 GMT Received: from humbug.demon.co.uk by punt.demon.co.uk id ab21699; 16 Mar 95 9:23 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rpBbV-00037pC; Thu, 16 Mar 95 09:12 GMT Message-Id: From: Dave Hudson Subject: Re: server-based auth To: Erik Quanstrom Date: Thu, 16 Mar 1995 09:12:25 +0000 (GMT) Cc: vsta@cisco.com In-Reply-To: <9503151347.AA29066@sartre.minerva.bah.com> from "Erik Quanstrom" at Mar 15, 95 08:47:51 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1741 Hi, Erik Quanstrom wrote: > > >For your scenario, the msg_connect() system call should be disabled. The > >process could then walk down current mount points, but could not access new > >servers. Other possibilities are disabling fork()/tfork()/clone() (perhaps > >a couple others). This would create an execution environment in which a > >process could serve requests but not much else. > > why not let the servers themselves do the authentication, a la > the 9p? as in the message set The problem would be that most servers have certain default permissions that allow all users to be able to see certain things (albeit usually read-only). In this case we don't really want that to happen. By disabling the msg_connect() mechanism we stop a process from establishing any new connections and thus accessing anything that they don't currently have access to. Thinking about this it would appear that we ought to be able to define another standard ID (much like the sys.sys id) that doesn't have the right to perform certain system calls. Perhaps this should be a no-one id that any user can create? Anyway the idea would be that a user who execs a firewall type process would establish the limited connections under their normal id and then relinquish this completely in favour of the limited id (easy to do) I don't think this should cause any security risks as the no-one id doesn't allow anyone to do anything new - if the disabling is done correctly (as in login) there's no way to get back once we're running as no-one :-) The other nice thing about this is that we can allocate each no-one a sub-id that means they can't possibly mess about with each other's work. Have I missed anything drastic? Regards, Dave From vandys@glare.cisco.com Thu Mar 16 12:12:51 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01044; Thu, 16 Mar 1995 12:12:50 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA27046; Thu, 16 Mar 1995 12:57:43 -0800 Message-Id: <199503162057.MAA27046@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@cisco.com Subject: Re: server-based auth In-Reply-To: Your message of "Thu, 16 Mar 1995 09:12:25 GMT." Date: Thu, 16 Mar 1995 12:57:43 -0800 From: Andrew Valencia [Dave Hudson writes:] >I don't think this should cause any security risks as the no-one id doesn't >allow anyone to do anything new - if the disabling is done correctly (as in >login) there's no way to get back once we're running as no-one :-) The >other nice thing about this is that we can allocate each no-one a sub-id >that means they can't possibly mess about with each other's work. >Have I missed anything drastic? Denial of service attacks (create ports, consume PID's, memory, etc.). Sending of signals. ptrace. Also, as you noted, the default read permissions in some circumstances. A per-syscall bitmask is also probably at least as fast as checking for a particular ID. I'm not sure about the technique of issuing sub-id "nobody" ID's. If they can subvert the main "nobody" ID even once then all the benefits of doing this are lost. A lot of its value would seem to reside on convention. It's amusing to imagine what a process with one open file and all system calls except exit() and msg_send() disabled. Assume he's using the background CPU priority. He can calculate and write his results, but nothing else. How would you write code to break out of this? Or if not break out, how would you most disrupt the system? Andy From vandys@glare.cisco.com Fri Mar 17 00:06:35 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA01124; Fri, 17 Mar 1995 00:06:35 -0800 Received: from sartre.minerva.bah.com (sartre.minerva.bah.com [156.80.175.13]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id AAA12700 for ; Fri, 17 Mar 1995 00:51:31 -0800 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA05281; Fri, 17 Mar 95 03:47:52 -0500 Date: Fri, 17 Mar 95 03:47:52 -0500 From: Erik Quanstrom Message-Id: <9503170847.AA05281@sartre.minerva.bah.com> Subject: disrupting the system Apparently-To: >It's amusing to imagine what a process with one open file and all system >calls except exit() and msg_send() disabled. Assume he's using the >background CPU priority. He can calculate and write his results, but >nothing else. >How would you write code to break out of this? Or if not break out, how >would you most disrupt the system? fill up the disk. From vandys@glare.cisco.com Fri Mar 17 11:08:00 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01208; Fri, 17 Mar 1995 11:07:59 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id LAA28315 for ; Fri, 17 Mar 1995 11:52:59 -0800 Received: from xmission.xmission.com (shea@localhost [127.0.0.1]) by xmission.xmission.com (8.6.10/8.6.10) with ESMTP id MAA29477 for ; Fri, 17 Mar 1995 12:52:48 -0700 Message-Id: <199503171952.MAA29477@xmission.xmission.com> To: vsta@cisco.com Subject: thread-safe version of the libc hash In-reply-to: Your message of "Mon, 20 Feb 1995 16:52:16 EST." Date: Fri, 17 Mar 1995 12:52:43 -0700 From: Gary Shea Hi All -- I have a version of Andy's hash library package which is thread safe. Let me know if you need it. Gary From vandys@glare.cisco.com Fri Mar 17 22:17:38 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA01310; Fri, 17 Mar 1995 22:17:37 -0800 Received: from wonderland.apana.org.au (michael@wonderland.apana.org.au [203.3.126.65]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id XAA08338 for ; Fri, 17 Mar 1995 23:02:26 -0800 Received: (from michael@localhost) by wonderland.apana.org.au (8.6.10/8.6.9) id QAA27362 for vsta@cisco.com; Sat, 18 Mar 1995 16:59:27 +1000 From: Michael Watkin Message-Id: <199503180659.QAA27362@wonderland.apana.org.au> Subject: Greetings To: vsta@cisco.com Date: Sat, 18 Mar 1995 16:59:26 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 522 Hello everyone, I've been interested in VSTa for a while but have only just had the time to ftp the whole bunch and install it and get it running. And from what I've used, I like it. I'd also like to help out with any projects that need doing. I've been programming in C/C++ for the past 7 years and would like to do something constructive for a change :) So does someone have a list of projects that need doing, or a list of projects already under-taken so that I shouldn't go and re-invent the wheel?? Thanks... From vandys@glare.cisco.com Sat Mar 18 17:17:25 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA01436; Sat, 18 Mar 1995 17:17:23 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id SAA22211 for ; Sat, 18 Mar 1995 18:02:30 -0800 Message-Id: <199503190202.SAA22211@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: VSTa work in progress Date: Sat, 18 Mar 1995 18:02:30 -0800 From: Andrew Valencia Hi, all. I've continued on the performance work Dave did and now have a "fast path" for system calls with zero, one, two, or three arguments (which is all the important ones). I'm now moving the source around a bit more to accomodate the 68030 Amiga port as well as a 68040 multibus port I'm doing. Today I added the "include" directive to "make" so that I can break Makefiles like the one for libc into portable and platform-specific parts. I also put a networked VSTa machine up on the Internet. I should configure it for FTP, but for now you can at least ping vsta.crystald.com and know that it's a VSTa machine sending back your ICMP echo. Welcome to Michael Watkin! Finding projects on VSTa is never much of a challenge.... If you have access to a network you might consider fixing up the KA9Q port I did and then adding a /inet filesystem server to it so we can bring up more networking services. Other activities are porting a late-model gcc 2.X over, perhaps pitching in on the windowing system MADO, or porting over some other LAN interface drivers (I did ne2000, but there are others just as common). Regards, Andy Valencia From vandys@glare.cisco.com Sun Mar 19 08:01:05 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01510; Sun, 19 Mar 1995 08:01:04 -0800 Received: from sartre.minerva.bah.com (sartre.minerva.bah.com [156.80.175.13]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id IAA07954 for ; Sun, 19 Mar 1995 08:46:14 -0800 Received: from pigsnose by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA09340; Sun, 19 Mar 95 11:41:18 -0500 Date: Sun, 19 Mar 95 11:41:18 -0500 From: Erik Quanstrom Message-Id: <9503191641.AA09340@sartre.minerva.bah.com> Subject: re: server based auth Apparently-To: >> why not let the servers themselves do the authentication, a la >> the 9p? as in the message set >The problem would be that most servers have certain default permissions that >allow all users to be able to see certain things (albeit usually read-only). i don't see this as a problem as it can be solved in two ways. 1] don't do that. if you really don't mean to give everybody access to something, then don't. if you allow networked access to vsta services, then you really don't want this and it's going to be a bigger problem later on. 2] continue to allow read-only access to unauthenticated connections. but require authentication if you want to write. From vandys@glare.cisco.com Mon Mar 20 09:05:27 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01697; Mon, 20 Mar 1995 09:05:26 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id JAA23122 for ; Mon, 20 Mar 1995 09:50:42 -0800 Received: from world.std.com by europe.std.com (8.6.11/Spike-8-1.0) id MAA21291; Mon, 20 Mar 1995 12:50:40 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA09934; Mon, 20 Mar 1995 12:50:49 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199503201750.AA09934@world.std.com> Subject: Re: VSTa work in progress To: vsta@cisco.com Date: Mon, 20 Mar 1995 12:50:49 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 322 Hi, Andy Valencia wrote: > Welcome to Michael Watkin! Finding projects on VSTa is never much of a > challenge.... Long ago there was an occasional mailing about the list of ongoing VSTa projects. Personally, I thought this information was useful. Does any have a current list of ongoing projects? Mike Larson From vandys@glare.cisco.com Thu Mar 23 09:42:22 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA02200; Thu, 23 Mar 1995 09:42:21 -0800 Received: from ebt-inc.ebt.com (kirk.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA27385 for ; Thu, 23 Mar 1995 10:27:55 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id NAA00132; Thu, 23 Mar 1995 13:30:06 -0500 Date: Thu, 23 Mar 1995 13:30:06 -0500 From: Gavin Nicol Message-Id: <199503231830.NAA00132@ebt-inc.ebt.com> To: vsta@cisco.com Subject: Project list I'm going to revive the project list. As such, if anyone has a project idea, or if you are working on a project, please send me some email. I'll aim for sending out the project list in both HTML and ASCII once every two weeks. From vandys@glare.cisco.com Fri Mar 24 03:13:06 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA02285; Fri, 24 Mar 1995 03:13:00 -0800 Received: from trefle.saclay.cea.fr (trefle.saclay.cea.fr [132.166.128.101]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id DAA18828 for ; Fri, 24 Mar 1995 03:58:32 -0800 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with ESMTP id MAA01655 for ; Fri, 24 Mar 1995 12:57:59 +0100 Received: from soleil.serma.cea.fr by oeillet.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with SMTP id MAA16041 for ; Fri, 24 Mar 1995 12:59:39 +0100 Received: from rosser.serma.cea.fr by soleil.serma.cea.fr (5.0/CEANET.2.0.1) id AA02754; Fri, 24 Mar 1995 12:58:26 --100 Received: by rosser.serma.cea.fr (5.x/SMI-SVR4) id AA03211; Fri, 24 Mar 1995 12:58:22 +0100 Date: Fri, 24 Mar 1995 12:58:22 +0100 Message-Id: <9503241158.AA03211@rosser.serma.cea.fr> From: basile.starynkevitch@cea.fr To: vsta@cisco.com Subject: Dynamic Loading in VSTa content-length: 1300 -- Hello All, As far as I know, dynamic linking is not yet available in VSTa (1.3.3). I believe that it should be there, because it has many interesting usages. I also hope that it will be used by many VSTa software, including shells; for instance, a frequently used shell function could be compiled (either by hand, ie by coding it into C, or perhaps one day automatically) into a dynamically loaded library and loaded. I know that VSTa has shared libraries (but i didn't looked inside them) and these are related to dynamic loading or linking. ---------------------------------------------------------------------- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 46.65.45.53 email: basile.starynkevitch@cea.fr (redirected to basile@soleil.serma.cea.fr); ---------------------------------------------------------------------- N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a **small pertinent part** of my mail in all answers Veuillez citer une **petite partie pertinente** de mon courrier dans vos reponses From vandys@glare.cisco.com Fri Mar 24 06:38:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA02299; Fri, 24 Mar 1995 06:38:45 -0800 Received: from pscgate (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id HAA29630 for ; Fri, 24 Mar 1995 07:24:21 -0800 Received: from progress.progress.COM by pscgate (4.1/pscgate1.1) id AA00634; Fri, 24 Mar 95 10:24:17 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA06527; Fri, 24 Mar 95 10:23:57 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA21925; Fri, 24 Mar 95 10:23:57 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA28972; Fri, 24 Mar 95 10:23:55 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA06682; Fri, 24 Mar 95 10:23:55 EST Date: Fri, 24 Mar 95 10:23:55 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503241023.ZM6680@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Scanning Environment Variables Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm in the process of porting an application to VSTa and this application accesses the environment via getenv() and a character array pointer. I have also seen on MS/DOS applications where the third argument to main() was a character array pointer. VSTa uses an environment server. The C runtime library has a routine for looking up the value of a variable. However there does not seem to be a routine for scanning the whole set of environment variables. Any ideas? -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Fri Mar 24 07:33:31 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02306; Fri, 24 Mar 1995 07:33:30 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA25807; Fri, 24 Mar 1995 08:19:09 -0800 Message-Id: <199503241619.IAA25807@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: koogler@bedford.progress.com (David Koogler) Cc: vsta@cisco.com Subject: Re: Scanning Environment Variables In-Reply-To: Your message of "Fri, 24 Mar 1995 10:23:55 EST." <9503241023.ZM6680@crozet> Date: Fri, 24 Mar 1995 08:19:09 -0800 From: Andrew Valencia [koogler@bedford.progress.com (David Koogler) writes:] >... However there >does not seem to be a routine for scanning the whole set of environment >variables. This is a side effect of there not being "the" environment. Your process lives in a global hierarchy of variables; I guess you could get a list of all the environment variable names with something like: vars="" dir="/env/namer/$USER/#" while test "$dir" != "" do cd $dir vars=$vars" "`echo *` dir=`echo $dir | sed 's|\(.*\)/.*|\1'` done vars=`echo $vars | tr ' ' '\12' | sort -u` Note that this is an expensive operation; it also loses the ability to see global environment variables change. What kind of application is it? I've only run into this with shells, and shells usually *benefit* from avoiding the manual handling of all those variables. Andy From vandys@glare.cisco.com Fri Mar 24 07:56:53 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02310; Fri, 24 Mar 1995 07:56:52 -0800 Received: from pscgate (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id IAA05395; Fri, 24 Mar 1995 08:42:29 -0800 Received: from progress.progress.COM by pscgate (4.1/pscgate1.1) id AA02582; Fri, 24 Mar 95 11:42:27 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA11937; Fri, 24 Mar 95 11:42:25 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA26646; Fri, 24 Mar 95 11:42:25 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA00443; Fri, 24 Mar 95 11:42:24 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA06822; Fri, 24 Mar 95 11:42:23 EST Date: Fri, 24 Mar 95 11:42:23 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503241142.ZM6820@crozet> In-Reply-To: Andrew Valencia "Re: Scanning Environment Variables" (Mar 24, 8:19) References: <199503241619.IAA25807@glare.cisco.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Andrew Valencia Subject: Re: Scanning Environment Variables Cc: vsta@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii The application is JAM, which is a make replacement. It needs to scan the environment to establish the initial control variable state (CC and the like). I have not read the code too closely, so I am not sure if I could rework its search functions to access the environment variables one at time using the runtime library routine. The 2.6.2 GNU C driver (gcc) also accesses the enivornment in a fashion similar to JAM, so I imagine there may be other applications that need this facility. A shell script could work, but I find it rather clumsy. I would much rather have some iterator routines that could walk the environment, much like the dirent routines allows me to walk directory trees. An aside: I find the idea of a tree-structured environment to be quite fascinating. My current customer uses a very complex set of macros to set up an operating environment for the various revisions of their product. Having a set of parallel environments, one for each different configuration, would be a real boon. To switch environment, I would only need to move to a different point in the tree. The tree structured environment is so direct and so simple, and yet quite flexible, that I am going to spend more time to study it. -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Fri Mar 24 12:28:43 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02368; Fri, 24 Mar 1995 12:28:42 -0800 Received: from pscgate (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id NAA02102 for ; Fri, 24 Mar 1995 13:14:14 -0800 Received: from progress.progress.COM by pscgate (4.1/pscgate1.1) id AA09309; Fri, 24 Mar 95 16:13:58 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA12615; Fri, 24 Mar 95 12:04:37 EST Received: from devserv.bedford.progress.COM (devserv-e7) by proserv.bedford.progress.COM (4.1/psc2.2) id AA27967; Fri, 24 Mar 95 12:04:37 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA01192; Fri, 24 Mar 95 12:04:36 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA06870; Fri, 24 Mar 95 12:04:34 EST Date: Fri, 24 Mar 95 12:04:34 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9503241204.ZM6868@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: Sbrk function Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii The VSTa runtime library does not have sbrk(). There are functions like alloc_core() and alloc_pages() that I could use to simulate sbrk(). I do not yet understand the operation of these two functions, partiularly the on-page control data structure 'chunk'. The gcc 2.6.2 driver needs sbrk() and I am wondering if anyone has implemented it, or how to go about replacing it? -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Fri Mar 24 12:43:19 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02378; Fri, 24 Mar 1995 12:43:18 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA13724; Fri, 24 Mar 1995 13:28:58 -0800 Message-Id: <199503242128.NAA13724@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: koogler@bedford.progress.com (David Koogler) Cc: vsta@cisco.com Subject: Re: Sbrk function In-Reply-To: Your message of "Fri, 24 Mar 1995 12:04:34 EST." <9503241204.ZM6868@crozet> Date: Fri, 24 Mar 1995 13:28:57 -0800 From: Andrew Valencia [koogler@bedford.progress.com (David Koogler) writes:] >The gcc 2.6.2 driver needs sbrk() and I am wondering if anyone has implemented >it, or how to go about replacing it? (Long pause while I go look at my gcc-2.4 tree) My, not very portable, is it? But that's just a flag to print memory, so why don't you just drop it? Or did somebody come up with some *other* use for sbrk()? I can pull down some 2.6.2 sources if necessary. sbrk() comes from the days when your address space was small (64k) and was organized as: 0 etext edata end sbrk(0) 0xFFFF Text....Date....BSS.....Heap..... ........Stack So sbrk(0) was your way of asking where the heap currently ended. With a VM operating system with a sparse 32-bit address space, the question makes very little sense at all. Andy