From vandys@glare.cisco.com Thu Feb 3 15:29:43 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00549; Thu, 3 Feb 1994 15:29:42 -0800 Received: from localhost by glare.cisco.com with SMTP id AA12224 (5.67a/IDA-1.5 for ); Thu, 3 Feb 1994 14:59:17 -0800 Message-Id: <199402032259.AA12224@glare.cisco.com> To: vsta@cisco.com Subject: Complete VSTa mailing list archives Date: Thu, 03 Feb 1994 14:59:17 -0800 From: Andrew Valencia Thanks to the efforts of Abbie (abbie@dcsd.sj.nec.com) we now have a complete archive of the VSTa mailing list. It's on ftp.cisco.com:vandys/vsta, see the files V*.gz. I expect it will be mirrored to the usual places within a day or so. Enjoy! (Thanks, Abbie) Andy From vandys@glare.cisco.com Sun Feb 6 19:30:45 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id TAA01038; Sun, 6 Feb 1994 19:30:44 -0800 Received: from localhost by glare.cisco.com with SMTP id AA10817 (5.67a/IDA-1.5 for ); Sun, 6 Feb 1994 19:00:37 -0800 Message-Id: <199402070300.AA10817@glare.cisco.com> To: vsta@cisco.com Subject: Patch for v1.2 Date: Sun, 06 Feb 1994 19:00:37 -0800 From: Andrew Valencia Here's a patch for libc/malloc.c. Don't even ask me how I found it. If you have been using malloc() to get lots of > 4K chunks of memory, this bug might cause you to suffer subtle memory corruption problems. Andy *** c:/tmp/T0AA.AAA Sun Feb 06 19:53:34 1994 --- malloc.c Sun Feb 06 19:47:38 1994 *************** *** 312,324 **** char *p; uint x, pgs; /* * Fill in per-page information */ ! pgs = btorp(size); p = alloc_pages(pgs); set_size(p, b-buckets); /* * Parcel as many chunks as will fit out of the memory */ --- 312,324 ---- char *p; uint x, pgs; /* * Fill in per-page information */ ! pgs = btorp(b->b_size); p = alloc_pages(pgs); set_size(p, b-buckets); /* * Parcel as many chunks as will fit out of the memory */ From vandys@glare.cisco.com Mon Feb 7 16:26:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA01231; Mon, 7 Feb 1994 16:26:57 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA05065 (8.6.4/IDA-1.5 for ); Mon, 7 Feb 1994 15:56:49 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id IAA25287; Tue, 8 Feb 1994 08:56:42 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA26101; Tue, 8 Feb 1994 08:56:38 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940203.2) id AA22160; Tue, 8 Feb 1994 08:56:37 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00383; Tue, 8 Feb 94 08:56:00 +0900 Date: Tue, 8 Feb 94 08:56:00 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402072356.AA00383@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Projects This is a list of ongoing projects, and who's working on them. If there are any changes you'd like made, please let me know. ------------------------- Project List -----+------------------------------ TASK | WHO --------------------------------------------+------------------------------ VSTa file system (Non-Unix) | vandys@cisco.com - Basic system available. Needs support | for versioning etc. | Window System (Non-X11) | nick@nsis.cl.nec.co.jp - Comprises of /dev/bitblt, a graphics | server, and mado, the windowing system | proper. A basic bitblt is working, and | coding on MADO has progressing. | Debugger | vandys@cisco.com - ADB like debugger is in testing. GDB | will be ported soon. | SCSI disk server | myl@genrad.com, - Prototype is in testing | RS232c server | vandys@cisco.com - Beta is in testing | Joystick Server | dave@humbug.demon.co.uk - Beta is out | Native boot (ie. boot from disk) | dave@humbug.demon.co.uk - Floppy is done. HDD in development | RPC/Server description language | nick@nsis.cl.nec.co.jp - Based on CORBA IDL. Work has begun. | Update/expand libc (and include files) | rob@cygnus.com (??) Shared libraries | Network server | dave@computone.com /proc server (for use with ps etc.) | Update kbd so key mappings can be downloaded| (planned)nick@nsis.cl.nec.co.jp Porting of applications (make, emacs, ...) | Unix/Linux file systems | Math emulator (inside kernel? server?) | --------------------------------------------+------------------------------- From vandys@glare.cisco.com Mon Feb 7 20:10:31 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01251; Mon, 7 Feb 1994 20:10:29 -0800 Received: from localhost by glare.cisco.com with SMTP id AA29041 (5.67a/IDA-1.5 for ); Mon, 7 Feb 1994 19:40:28 -0800 Message-Id: <199402080340.AA29041@glare.cisco.com> To: vsta@cisco.com Subject: Another patch Date: Mon, 07 Feb 1994 19:40:28 -0800 From: Andrew Valencia This bug will show up as vmap depletion (the kernel has a general purpose pool of virtual addresses, organized as a resource map named "vmap"). Most likely you'll just see a system hang, although you can punch out to the kernel debugger. You'll find a process sleep'ing with a "wchan" of vmap_sema. This bug is caused by the fact that the early VM system didn't need a virtual address for the root page table of PTEs. When I converted to virtual addresses, I didn't switch the cleanup code to free the virtual address--it still just freed the physical page. Apply this to os/mach/hat.c Andy *** c:/tmp/T0AA.AAA Mon Feb 07 20:32:50 1994 --- hat.c Mon Feb 07 20:18:30 1994 *************** *** 121,133 **** bit <<= 1; } /* * Free root and map */ ! free_page(btop(vas->v_hat.h_cr3)); free(vas->v_hat.h_map); } /* * hat_addtrans() * Add a translation given a view --- 121,133 ---- bit <<= 1; } /* * Free root and map */ ! free(vas->v_hat.h_vcr3); free(vas->v_hat.h_map); } /* * hat_addtrans() * Add a translation given a view From vandys@glare.cisco.com Mon Feb 7 23:01:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id XAA01268; Mon, 7 Feb 1994 23:01:07 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA15923 (8.6.4/IDA-1.5 for ); Mon, 7 Feb 1994 22:31:06 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA25043; Mon, 7 Feb 94 22:05:41 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA16819; Mon, 7 Feb 94 23:05:40 MST Message-Id: <9402080605.AA16819@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Mon, 7 Feb 1994 23:05:40 MST In-Reply-To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) "Projects" (Feb 8, 8:56am) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol), vsta@cisco.com Subject: Re: Projects From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Subject: Projects > Update/expand libc (and include files) | rob@cygnus.com (??) This is more adding support to GNU development tools for VSTa. LD and the binutils are done, and will be in the next net release of the binutils. (any day now they tell me :-) I added support to GCC and GAS, and I'm trying to debug the GCC port (it installs wrong, which may be merely a symtom). These all work as a cross development from any Unix host (I run it on sun4 and Linux) and hopefully this work will make it easier to be self hosting, which is the next priority. > Shared libraries | Ultimately. Also set up new ftp archive for vsta and other embeded systems tools on ftp.cygnus.com:pub/embedded/vsta. I keep it mirrored from cisco. - rob - From vandys@glare.cisco.com Tue Feb 8 05:43:18 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id FAA01371; Tue, 8 Feb 1994 05:43:16 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA00658 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 05:13:17 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA28083; Tue, 8 Feb 1994 08:13:16 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18567; Tue, 8 Feb 1994 08:13:13 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402081313.AA18567@world.std.com> Subject: Re: Projects To: vsta@cisco.com Date: Tue, 8 Feb 1994 08:13:13 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1092 > This is a list of ongoing projects, and who's working on them. If > there are any changes you'd like made, please let me know. > > ------------------------- Project List -----+------------------------------ > TASK | WHO > --------------------------------------------+------------------------------ : : > SCSI disk server | myl@genrad.com, > - Prototype is in testing | Since the driver is part of the latest VSTa distribution, I think it might be fair to say that the status is "initial version has been released, working on enhancements". Also, please change my email address to larz@world.std.com. Thanks. > RPC/Server description language | nick@nsis.cl.nec.co.jp > - Based on CORBA IDL. Work has begun. | This sounds interesting. Has it been discussed in this mailing list before? Perhaps I missed it. Anyway, would mind filling us in on some of the details, such as what is COBRA and how it might affect existing servers? Mike Larson larz@world.std.com From vandys@glare.cisco.com Tue Feb 8 06:13:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id GAA01375; Tue, 8 Feb 1994 06:13:32 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA01304 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 05:43:34 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA01239; Tue, 8 Feb 1994 08:43:30 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA26568; Tue, 8 Feb 1994 08:43:27 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402081343.AA26568@world.std.com> Subject: readline in rc To: vsta@cisco.com Date: Tue, 8 Feb 1994 08:43:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 302 Hi, Has any one hooked readline into the rc shell yet? If so, did you use GNU readline, or (as suggested in the rc readme file) "a supplied readline-like system by Simmule Turner"? Is there an ftp-able VSTa rc w/ readline capabilities somewhere? Thanks. Mike Larson larz@world.std.com From vandys@glare.cisco.com Tue Feb 8 08:26:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA01388; Tue, 8 Feb 1994 08:26:18 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA04934 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 07:56:20 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA11995; Tue, 8 Feb 94 07:56:18 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA17704; Tue, 8 Feb 94 08:56:17 MST Message-Id: <9402081556.AA17704@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 8 Feb 1994 08:56:16 MST In-Reply-To: larz@world.std.com (Mike A Larson) "readline in rc" (Feb 8, 8:43am) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: larz@world.std.com (Mike A Larson), vsta@cisco.com Subject: Re: readline in rc From: larz@world.std.com (Mike A Larson) Subject: readline in rc > Has any one hooked readline into the rc shell yet? If so, did you use GNU > readline, or (as suggested in the rc readme file) "a supplied readline-like > system by Simmule Turner"? Is there an ftp-able VSTa rc w/ readline > capabilities somewhere? I'd actually like to port bash, or the minix POSIX conforming shell. Then all the GNU configuration shell scripts will work! :-) - rob - From vandys@glare.cisco.com Tue Feb 8 08:48:29 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with SMTP id IAA01392; Tue, 8 Feb 1994 08:48:28 -0800 Received: from hof (hof.daimi.aau.dk) by dirt.cisco.com with SMTP id AA19544 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 08:18:29 -0800 Received: by hof (Linux Smail3.1.28.1 #14) id m0pTv81-000ICaC; Tue, 8 Feb 94 17:17 MET Message-Id: Date: Tue, 8 Feb 94 17:17 MET From: tthorn%hof@hof.daimi.aau.dk (Tommy Thorn) To: vsta@cisco.com Subject: Re: readline in rc In-Reply-To: <9402081556.AA17704@darkstar.cygnus.com> References: <9402081556.AA17704@darkstar.cygnus.com> Reply-To: Tommy.Thorn@daimi.aau.dk Rob Savoye writes: > I'd actually like to port bash, or the minix POSIX conforming shell. Then > all the GNU configuration shell scripts will work! :-) > > - rob - $0.02 Is the minix shell free software? The PD ksh might be a better bet, as it's far smaller than bash. /Tommy From vandys@glare.cisco.com Tue Feb 8 09:11:48 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01400; Tue, 8 Feb 1994 09:11:47 -0800 Received: from gipsy.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA06686 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 08:41:47 -0800 Received: by gipsy.vmars.tuwien.ac.at id AA03166 (5.64+/IDA-1.3.4 for vsta@cisco.com); Tue, 8 Feb 94 17:41:21 +0100 From: Peter Holzer Message-Id: <9402081641.AA03166@gipsy.vmars.tuwien.ac.at> Subject: Re: readline in rc To: vsta@cisco.com Date: Tue, 8 Feb 94 17:41:20 MET In-Reply-To: <9402081556.AA17704@darkstar.cygnus.com>; from "Rob Savoye" at Feb 8, 94 8:56 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Rob Savoye) wrote: > I'd actually like to port bash, or the minix POSIX conforming shell. Then > all the GNU configuration shell scripts will work! :-) I had some troubles with the Minix shell and configure scripts in the past. I am not sure whether this was the fault of the shell or the scripts (they used funny constructs not documented in any man page I have yet seen). Besides I am not sure about the copyright status of the Minix shell. The files contain neither copyright notices nor the name of an author, so they are probably copyrighted by Prentice Hall. I am using ash now in Minix to run scripts and zsh for interactive use. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Tue Feb 8 09:42:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01412; Tue, 8 Feb 1994 09:42:10 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA08073 (8.6.4/IDA-1.5 for ); Tue, 8 Feb 1994 09:12:13 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA14009; Tue, 8 Feb 94 09:12:10 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA17922; Tue, 8 Feb 94 10:12:08 MST Message-Id: <9402081712.AA17922@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 8 Feb 1994 10:12:08 MST In-Reply-To: Peter Holzer "Re: readline in rc" (Feb 8, 5:41pm) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: hp@vmars.vmars.tuwien.ac.at, vsta@cisco.com Subject: Re: readline in rc From: Peter Holzer Subject: Re: readline in rc > You (Rob Savoye) wrote: > > > I'd actually like to port bash, or the minix POSIX conforming shell. Then > > all the GNU configuration shell scripts will work! :-) > > I had some troubles with the Minix shell and configure scripts in the > past. I am not sure whether this was the fault of the shell or the > scripts (they used funny constructs not documented in any man page I > have yet seen). I'm thinking of the one that was also ported to DOS as part of the gnuish project. I'm not sure what it's called. I have a good collection of shells (in sources) on darkstar.cygnus.com:pub/shells. Most GNU configure scripts are writtne to run under any V7 bourne shell. Till we get a good shell ported, we'll be stuck tweaking Makefiles by hand. I'd prefer to port bash, but I doubt it'll be trivial. > I am using ash now in Minix to run scripts and zsh for interactive use. Having never used either of these, what are they like ? - rob - From vandys@glare.cisco.com Wed Feb 9 01:40:31 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id BAA00128; Wed, 9 Feb 1994 01:40:29 -0800 Received: from gipsy.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA10347 (8.6.4/IDA-1.5 for ); Wed, 9 Feb 1994 01:11:12 -0800 Received: by gipsy.vmars.tuwien.ac.at id AA01340 (5.64+/IDA-1.3.4 for vsta@cisco.com); Wed, 9 Feb 94 09:55:13 +0100 From: Peter Holzer Message-Id: <9402090855.AA01340@gipsy.vmars.tuwien.ac.at> Subject: Re: readline in rc To: hp@vmars.vmars.tuwien.ac.at, vsta@cisco.com Date: Wed, 9 Feb 94 9:55:12 MET In-Reply-To: <9402081712.AA17922@darkstar.cygnus.com>; from "Rob Savoye" at Feb 8, 94 10:12 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Rob Savoye) wrote: > > > I am using ash now in Minix to run scripts and zsh for interactive use. > > Having never used either of these, what are they like ? > Ash is a bourne shell clone. I am not sure where it comes from, but it could be from bsd net-2. Zsh is ksh with some extensions and csh-like history thrown in. Has very good command-line edition and file completion. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Wed Feb 9 03:27:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id DAA00221; Wed, 9 Feb 1994 03:27:15 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA12745 (8.6.4/IDA-1.5 for ); Wed, 9 Feb 1994 02:57:55 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa18439; 9 Feb 94 10:47 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pUCSP-00063jC; Wed, 9 Feb 94 10:47 GMT Message-Id: From: Dave Hudson Subject: Re: readline in rc To: VSTa mailing list Date: Wed, 9 Feb 1994 10:47:45 +0000 (GMT) In-Reply-To: <9402090855.AA01340@gipsy.vmars.tuwien.ac.at> from "Peter Holzer" at Feb 9, 94 09:55:12 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: 751 Peter Holzer wrote: > > You (Rob Savoye) wrote: > > > > > I am using ash now in Minix to run scripts and zsh for interactive use. > > > > Having never used either of these, what are they like ? > > > > Ash is a bourne shell clone. I am not sure where it comes from, but it > could be from bsd net-2. Zsh is ksh with some extensions and csh-like > history thrown in. Has very good command-line edition and file > completion. I use ash (from bsd) on my Linux boot floppies - it's quite small at around 62k and has about 500k sources. The only thing I've found is that it has a nasty habit of locking up every now and then (this could be a Linux problem). Generally it's pretty robust (although I miss not having a command line editor) Dave From vandys@glare.cisco.com Wed Feb 9 09:06:13 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00288; Wed, 9 Feb 1994 09:06:09 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA24307 (8.6.4/IDA-1.5 for ); Wed, 9 Feb 1994 08:36:44 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA15274; Wed, 9 Feb 94 08:05:11 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA23262; Wed, 9 Feb 94 09:05:08 MST Message-Id: <9402091605.AA23262@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Wed, 9 Feb 1994 09:05:08 MST In-Reply-To: Dave Hudson "Re: readline in rc" (Feb 9, 10:47am) 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: readline in rc From: Dave Hudson Subject: Re: readline in rc > I use ash (from bsd) on my Linux boot floppies - it's quite small at around > 62k and has about 500k sources. The only thing I've found is that it has a > nasty habit of locking up every now and then (this could be a Linux > problem). Generally it's pretty robust (although I miss not having a > command line editor) I was just hoping to use a shell to bootstrap all the GNU shell and file utils to be self-hosting. Then I could hopefully get bash to compile, and then be able to configure gcc and gdb. - rob - From vandys@glare.cisco.com Mon Feb 14 00:16:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id AAA01163; Mon, 14 Feb 1994 00:16:02 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA11022 (8.6.4/IDA-1.5 for ); Sun, 13 Feb 1994 23:47:14 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id QAA16156; Mon, 14 Feb 1994 16:46:57 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA09372; Mon, 14 Feb 1994 16:46:54 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940203.2) id AA17240; Mon, 14 Feb 1994 16:46:53 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA02398; Mon, 14 Feb 94 02:46:13 -0500 Date: Mon, 14 Feb 94 02:46:13 -0500 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402140746.AA02398@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Runes I am about to implement the rune handling code for VSTa, because MADO and bitblt depend on it. I have basically decided the following: 1) A rune will be 16 bits and use Unicode 2) The I/O of runes will support UTF/2 as the core, and EUC, JIS, and whatever else eventually. These are all multi-byte formats. Before I start coding, I'd like to hear comments on the following: 1) Is it necessary to implement the ANSI-defined wchar_t functions (it seems few people use them)? 2) Does anyone see a need to support locales? From my experience, they offer little benefit to the average user, as users seldom understand them, and if they do understand them, the locale implementation is usually limited. My initial reaction is to provide similar functionality to the normal string library, and to use similarly named functions, and to add a few extra convenience functions. For example, I plan to offer runelen(), to return the number of runes, and runeblen() to return the number of bytes a rune string takes up, and conversion between rune and multibyte strings. If anyone has any comments now, please offer them. I have been too busy recently to do much with MADO, but I have some free time coming up, so I hope to make some headway. I have also started toying with the CORBA IDL compiler from SunSoft, with the eventual aim of using it as a base for server definitions and RPC definitions (ie. define a server in IDL, and then the compiler would generate the server skeleton, and code to access it). MADO has priority over this, so progress gere will be slow initially. nick From vandys@glare.cisco.com Thu Feb 17 19:16:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id TAA00620; Thu, 17 Feb 1994 19:16:39 -0800 Received: from relay2.UU.NET by hubbub.cisco.com with SMTP id AA11263 (8.6.4/IDA-1.5 for ); Thu, 17 Feb 1994 18:48:44 -0800 Received: from world.std.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwdsl04090; Thu, 17 Feb 94 21:48:41 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18315; Thu, 17 Feb 1994 21:48:21 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402180248.AA18315@world.std.com> Subject: malloc: find_chunk To: vsta@cisco.com Date: Thu, 17 Feb 1994 21:48:21 -0500 (EST) Cc: larz@world.std.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 269 Hi, When I try compile sim154x.c (part of the SCSI driver) while running the latest version of VSTa, I get the following message from cpp: malloc: find_chunk: no chunk Could cpp benefit from the latest patch to malloc? Mike Larson larz@world.std.com From vandys@glare.cisco.com Thu Feb 17 20:18:17 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00629; Thu, 17 Feb 1994 20:18:16 -0800 Received: from localhost by glare.cisco.com with SMTP id AA28409 (5.67a/IDA-1.5 for ); Thu, 17 Feb 1994 19:50:21 -0800 Message-Id: <199402180350.AA28409@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: malloc: find_chunk In-Reply-To: Your message of "Thu, 17 Feb 1994 21:48:21 EST." <199402180248.AA18315@world.std.com> Date: Thu, 17 Feb 1994 19:50:20 -0800 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >When I try compile sim154x.c (part of the SCSI driver) while running >the latest version of VSTa, I get the following message from cpp: > malloc: find_chunk: no chunk >Could cpp benefit from the latest patch to malloc? Apparently so. I saw the same failure, and rebuilding cpp with the latest library fixes the problem. I've placed it in: ftp.cisco.com:vandys/vsta/cpp.z and updated the readme accordingly. Let me know if you still see problems! Thanks, Andy From vandys@glare.cisco.com Wed Feb 23 16:48:31 1994 Received: from dustbin.cisco.com (dustbin.cisco.com [131.108.1.27]) by amri.cisco.com (8.3/8.3) with SMTP id QAA01607; Wed, 23 Feb 1994 16:48:28 -0800 Received: from post.demon.co.uk by dustbin.cisco.com with SMTP id AA20533 (8.6.4/IDA-1.5 for ); Wed, 23 Feb 1994 16:21:01 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21879; 24 Feb 94 0:08 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pZTZt-0002r9C; Thu, 24 Feb 94 00:05 GMT Message-Id: From: Dave Hudson Subject: boot fs update To: VSTa mailing list Date: Thu, 24 Feb 1994 00:05:17 +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: 2923 I've mentioned some of this to Andy earlier today and he suggested sending a development summary to the list (in case you're interested). I've finally managed to get a hour to complete the first pass at a modified bfs :-) The code now allows me create a boot fs, mount it and use it (all tested on top of a dosfs). The inode handling has been completely revamped so that when the server is run it takes a very simple set of details from the valid directory entries (with only 128 entries this isn't exactly time consuming) and creates a copy in memory of the details and puts links from neighbouring files (forwards and backwards). Each node in the list of allocated files (ie a file that has at least one block allocated) is responsible for managing any space that may be generated immediately after itself and before its neighbour (or the end of the fs in the case of the last file). The root inode is in this list so that it can catch any blocks that are freed up by deleting files immediately adjacent to it. My idea here is that no unmanaged holes can appear in the fs and that if a file wishes to expand it simply looks at whether there's enough free space between it and it's nearest neighbour (this makes block management very simple). What I've been thinking is that in the event of there not being enough space adjacent to the file it should be possible to try and do something simple to make space rather than have to compact the whole fs (eg grab space off a neighbouring file), but this is an optimisation for the moment - my next task is bfsck (file system checker) and bfspack (file system compaction proggy). If there are any comments on what I've done/am propsing to do I'd be grateful for them (the only fs work I've done before was writing mkdosfs for Linux - and this only involves writing a boot parameter block, an empty FAT table and an empty root directory - which was much simpler!) Once I complete the bfs utils I want to test bfs on a physical partition instead of on top of dos - has anything been done to generate a library version of fdisk.[ch] (as used in the scsi and wd code)? If not it would seem to make sense for me to generate a library version of this and modify wd to use this (so I can include the bfs ID field). From this point I need to modify my floppy bootstrap/setup routine so that instead of just reading one prebuilt file it will do the building itself. This may take a week or two (depending on how much I need to do for my real job). This bootstrap code currently uses the Linux as86/ld86 real mode assembler and linker (written by Bruce Evans). I'll be porting this code (plus a few new patches Bruce sent me to VSTa this weekend with any luck. I'd anticipate that there'll be a whole series of enhancements to this basic boot code over the next few months, but the first version should make it possible to boot VSTa without using DOS. Regards, Dave From vandys@glare.cisco.com Thu Feb 24 13:40:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id NAA01747; Thu, 24 Feb 1994 13:40:16 -0800 Received: from ds1.gl.umbc.edu by hubbub.cisco.com with SMTP id AA04611 (8.6.4/IDA-1.5 for ); Thu, 24 Feb 1994 13:13:00 -0800 Received: from rpc38.gl.umbc.edu (vijay@rpc38.gl.umbc.edu [130.85.60.58]) by ds1.gl.umbc.edu (8.6.5/8.6.5) with ESMTP id QAA05176 for ; Thu, 24 Feb 1994 16:12:58 -0500 Received: from localhost (vijay@localhost) by rpc38.gl.umbc.edu (8.6.5/8.6.5) id QAA04115; Thu, 24 Feb 1994 16:12:54 -0500 Date: Thu, 24 Feb 1994 16:12:53 -0500 (EST) From: Vijay Gill To: vsta list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there a newer paper than ftp.cisco.com:/vandys/vsta/vsta_intro.ps? Please reply directly as I may not be subscribed to the mailing list yet Thank you -- Vijay Gill |The (paying) customer is always right. wrath@cs.umbc.edu | - Piercarlo Grandi vijay@gl.umbc.edu | Eagles may soar, but weasels don't get These are my opinions only. | sucked into jet engines. From vandys@glare.cisco.com Thu Feb 24 20:10:50 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01767; Thu, 24 Feb 1994 20:10:48 -0800 Received: from localhost by glare.cisco.com with SMTP id AA04528 (5.67a/IDA-1.5 for ); Thu, 24 Feb 1994 19:43:34 -0800 Message-Id: <199402250343.AA04528@glare.cisco.com> To: Vijay Gill Cc: vsta list In-Reply-To: Your message of "Thu, 24 Feb 1994 16:12:53 EST." Date: Thu, 24 Feb 1994 19:43:34 -0800 From: Andrew Valencia [Vijay Gill writes:] >Is there a newer paper than ftp.cisco.com:/vandys/vsta/vsta_intro.ps? First, welcome to the mailing list! I've actually been pondering writing a much more informative document, and the call for submissions for the Usenix OS Design & Implementation symposium is making me think it's more than time. I know that the paper would be much more interesting if we had begun to do distributed stuff yet, so I'm a little undecided if it's time to do it yet. Andy From vandys@glare.cisco.com Thu Feb 24 20:23:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01770; Thu, 24 Feb 1994 20:23:31 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA20907 (8.6.4/IDA-1.5 for ); Thu, 24 Feb 1994 19:56:10 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id MAA12312; Fri, 25 Feb 1994 12:56:01 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA25916; Fri, 25 Feb 1994 12:55:59 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA19500; Fri, 25 Feb 1994 12:55:57 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00906; Fri, 25 Feb 94 12:55:11 +0900 Date: Fri, 25 Feb 94 12:55:11 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402250355.AA00906@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Distributed systems Andy says: >would be much more interesting if we had begun to do distributed stuff >yet, so I'm a little undecided if it's time to do it yet. Speaking of which, has anyone done any work with networking code and/or passing messages across the rs232c driver? Is there much infrastructure for message forwarding across hosts yet? I think now the biggest concern is getting a self-hosting system up and running isn't it? I for one would like to be able to boot into VSTa, and do my work there (when I get my new machine of course). From vandys@glare.cisco.com Thu Feb 24 20:29:37 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01774; Thu, 24 Feb 1994 20:29:36 -0800 Received: from ds1.gl.umbc.edu by hubbub.cisco.com with SMTP id AA21085 (8.6.4/IDA-1.5 for ); Thu, 24 Feb 1994 20:02:22 -0800 Received: from umbc8.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by ds1.gl.umbc.edu (8.6.5/8.6.5) with ESMTP id XAA13399 for ; Thu, 24 Feb 1994 23:02:20 -0500 Received: from localhost (vijay@localhost) by umbc8.umbc.edu (8.6.5/8.6.5) id XAA06016; Thu, 24 Feb 1994 23:02:19 -0500 Date: Thu, 24 Feb 1994 23:02:16 -0500 (EST) From: Vijay Gill Subject: Re: your mail (Paper on VSTa) To: vsta list In-Reply-To: <199402250343.AA04528@glare.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > and the call for submissions for the Usenix OS Design & Implementation > symposium is making me think it's more than time. I know that the paper > would be much more interesting if we had begun to do distributed stuff > yet, so I'm a little undecided if it's time to do it yet. What is the general consensus on writing up the paper, some documentation etc and putting pointers onto the various linux/BSD groups? Seeing how linux literally exploded into primetime has left me wondering if something like VSTa (which is desgined to be portable from the start) could not attract a larger community of programmers/evangelists, (perhaps a port to the Amiga ;) ) ? An aside, how big is the kernel? I know QNX 4.2 kernel is around 8 Kb. Vijay Gill |The (paying) customer is always right. wrath@cs.umbc.edu | - Piercarlo Grandi vijay@gl.umbc.edu | Eagles may soar, but weasels don't get These are my opinions only. | sucked into jet engines. From vandys@glare.cisco.com Fri Feb 25 06:03:23 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id GAA01812; Fri, 25 Feb 1994 06:03:20 -0800 Received: from inesc.inesc.pt by hubbub.cisco.com with SMTP id AA09339 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 05:34:24 -0800 Received: from inesc.inesc.pt by inesc.inesc.pt with SMTP; id AA24321 (5.67a/SunOS4.1.3); Fri, 25 Feb 1994 14:30:24 +0100 Message-Id: <199402251330.AA24321@inesc.inesc.pt> Received: from freya.inesc.pt (actually localhost) by freya.inesc.pt with SMTP (PP); Fri, 25 Feb 1994 14:31:55 +0000 To: Andrew Valencia Cc: vsta list In-Reply-To: Your message of "Thu, 24 Feb 1994 19:43:34 MET." <199402250343.AA04528@glare.cisco.com> Date: Fri, 25 Feb 1994 14:31:50 +0100 From: Werner Vogels > I've actually been pondering writing a much more informative document, > and the call for submissions for the Usenix OS Design & Implementation > symposium is making me think it's more than time. I know that the paper > would be much more interesting if we had begun to do distributed stuff > yet, so I'm a little undecided if it's time to do it yet. Andy, I think some things need attention before starting to present this work at conferences. I've spend the last two weeks reading through the vsta-list archive, reading the code and did some live playing with vsta. But it has only been two weeks and I didn't do any really serious devlopment on it so forgive me if some of my comments have their origine in not been involved from the start. [ And don't worry to much about the work implications of my comments, I may contribute quite a few things myself. ] 1. real-time One of the reasons why I was initially atracted to vsta was that it was published as a "real-time" (micro-kernel) OS. But when going through the code and looking and the primitives and system calls I couldn't really find a good justification for the "real-time" title. Although you seperate real-time from background threads and timesharing threads the scheduling policy you implement is strictly FIFO on the threads. This is not sufficient to implement any real-time environment. To accomodate the required real-time functionality we need to augment the tfork system call to carry real-time thread attributes. The attributes will carry information like wether the thread is periodic or not, the period, the deadline(s), estimated exution time, start time, preemptibility constraints, etc. A number of scheduling mechanisms are needed to be able to give system implementors a good choice; I would want at least rate monotonic, earliest dealine and leat laxity. The other urgent items needed, are to supply the user space threads with synchronization mechanisms. Currently we only have them in the kernel. If you want to implement these with the possibility to offer priority inversion protocols like priority ceilings, etc these primitives will have to come from the kernel not a user level threads synch implementation, as they have to closely cooperate with the scheduler. Personaly if think we also need primitives to indicate preempatble regions, etc. And also mechanisms to freeze all pages owned by a process/thread to avoid page faults for that process. If the VSTa community is very eager to comply to POSIX we should try to get as much of 1003.4(a) (real-time extensions) into the interface (and of course functionality in the design). With respect to the scheduling there is a POSIX requirment to at least support FIFO and RR scheduling. I would want to add at least rate monotomic, earliest deadline first and least laxity first. I think we should give priority to real-time thread scheduling (1003.4a) over the implementation of traditional real-time process scheduling (1003.4). This off course means that we need a pthread interface to the kernel threads. If cut out most of the signal stuff the pthread defeinition isn't much different from any other thread interface, expect that it has explicit real-time assignment hooks. 2. distribution. Support for distribution is essential. And treating it as an "add-on" feature may turn out to be a fundamental mistake. As a good micro-kernel should do VSTa leaves it all to the user space to implement things, but until now we have had not so very good experiences with user level implementations of protocols stacks. Although Chris Maeda's work was great he still arrived at times comparable to monolithic Mach and Ultrix. And we also know by now that the way the packet filter/demultiplexer is build and is able to interact with the device is crucial to get the better performance. As is the quest to avoid crossing protection domains while moving the message through the protocols. [Maybe you can comment on this Chris? as it is more your cup of tea]. The packetfilter is an engineering issue, but basic support for the domain crossing of data could become could an excellent feature of VSTa which would avoid a lot of performance problems. Especially network file servers could benefit from this. We could also learn from Mach what not to do if you want to extended you port & port capability space across a cluster of machines. As an intemediate solution we could adapt the x-kernel as the network server while working on better (real-time, non-real-time, etc) mechanisms. The port of the xkernel is trivial as soon the mutex's etc are available to user space. Be aware that the xkernel performance is bad and some of the protocols are not fully implemented, but it would be a relatively easy start. If we could solve these two problems and show extensive measurements of all parts of the kernel, you would have good material for a paper. -- Werner From vandys@glare.cisco.com Fri Feb 25 07:16:23 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id HAA01821; Fri, 25 Feb 1994 07:16:22 -0800 Received: from localhost by glare.cisco.com with SMTP id AA22656 (5.67a/IDA-1.5 for ); Fri, 25 Feb 1994 06:48:51 -0800 Message-Id: <199402251448.AA22656@glare.cisco.com> To: robert@par.univie.ac.at (Robert Mayer - Student) Cc: vsta@cisco.com Subject: Re: VSTa In-Reply-To: Your message of "Fri, 25 Feb 1994 15:24:09 +0100." <9402251424.AA18059@par.univie.ac.at> Date: Fri, 25 Feb 1994 06:48:51 -0800 From: Andrew Valencia [robert@par.univie.ac.at (Robert Mayer - Student) writes:] >Hi Andy, >sorry for posting this directly to you, but I can't seem to reach >vsta-request@amri.cisco.com to put me on the mailing list. Due to all the sendmail cracking which happens, all Cisco's E-mail now filters through vsta@cisco.com/vsta-request@cisco.com. If you use those addresses, things should work. >I think I have found a bug in the DOS filesystem server, which prevents the >second half of the FAT to be flushed correctly: > >in fat.c line 138 it says: >dirtymapsize = roundup(nclust, SECSZ) / SECSZ; > >but instead it should be: >dirtymapsize = roundup(nclust * sizeof (ushort), SECSZ) / SECSZ; > >because for every cluster on disk there are 16 bits in the FAT, not 8. >Also fat_dirty is never cleared, but this is not dangerous. Ick! I will pursue this ASAP. Thanks, and welcome to the list! Andy Valencia From vandys@glare.cisco.com Fri Feb 25 09:04:21 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01832; Fri, 25 Feb 1994 09:04:20 -0800 Received: from annexstein (annexstein.csm.uc.edu) by hubbub.cisco.com with SMTP id AA15101 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 08:37:08 -0800 Received: from localhost (humberto@localhost) by annexstein (8.6.5/8.6.4) id LAA00319; Fri, 25 Feb 1994 11:28:42 -0500 Date: Fri, 25 Feb 1994 11:28:42 -0500 From: Humberto Ortiz Zuazaga Message-Id: <199402251628.LAA00319@annexstein> To: vsta@cisco.com In-Reply-To: <199402251448.AA22656@glare.cisco.com> (message from Andrew Valencia on Fri, 25 Feb 1994 06:48:51 -0800) Subject: VSTa FAT problems >>>>> "AV" == Andrew Valencia writes: AV> [robert@par.univie.ac.at (Robert Mayer - Student) writes:] >> I think I have found a bug in the DOS filesystem server, which >> prevents the second half of the FAT to be flushed correctly: [[bug deleted]] AV> I will pursue this ASAP. I may have a related problem. I have a 10 Mb DOS partition on my hard drive, and it only has a 12 bit fat. My initial experiments with VSTa cause kernel panics when I write to the filesystem: file rw.c line 253. I don't know which rw.c though ;-) (I assumed the dosfs rw.c). I must say I don't know if this is a real bug, because I didn't install a clean VSTa due to lack of space. I instead installed vsta_fs and then copied standalone.tar to /boot, after fiddling with boot.lst and /etc/* i got it to boot, but it will panic after several disk writes. (I can write a hello world program and sometimes complete the compile, but often an intermediate write will fail). Since I also get filesystem corruption I've been reluctant to test further. My wife's laptop also gets sporadic filesystem corruption (directories turn into files, files get truncated), but no kernel panics, and she has a 16 bit fat, but her disk is practically full, so perhaps it's the caused by a real bug, and not my instalation. Humberto Ortiz Zuazaga zuazaga@ucunix.san.uc.edu From vandys@glare.cisco.com Fri Feb 25 09:33:42 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01836; Fri, 25 Feb 1994 09:33:40 -0800 Received: from localhost by glare.cisco.com with SMTP id AA27271 (5.67a/IDA-1.5 for ); Fri, 25 Feb 1994 09:06:29 -0800 Message-Id: <199402251706.AA27271@glare.cisco.com> To: Humberto Ortiz Zuazaga Cc: vsta@cisco.com Subject: Re: VSTa FAT problems In-Reply-To: Your message of "Fri, 25 Feb 1994 11:28:42 EST." <199402251628.LAA00319@annexstein> Date: Fri, 25 Feb 1994 09:06:28 -0800 From: Andrew Valencia [Humberto Ortiz Zuazaga writes:] >I may have a related problem. I have a 10 Mb DOS partition on my hard >drive, and it only has a 12 bit fat. My initial experiments with VSTa >cause kernel panics when I write to the filesystem: Oops, I bet your kernel stayed up. Of course, if the only disk-based filesystem you have goes down, this is small comfort, I'm sure! :-) >file rw.c line 253. >I don't know which rw.c though ;-) (I assumed the dosfs rw.c). It probably dropped you into the kernel debugger (with DEBUG, the kernel currently drops into the debugger so you can look around). A "pr" command would list the running/runnable procs; the one with state O would be the one who has just taken an un-handled event). >I must say I don't know if this is a real bug, because I didn't >install a clean VSTa due to lack of space. I instead installed >vsta_fs and then copied standalone.tar to /boot, after fiddling with >boot.lst and /etc/* i got it to boot, but it will panic after several >disk writes. (I can write a hello world program and sometimes complete >the compile, but often an intermediate write will fail). Probably a bug. :-( >My wife's laptop also gets sporadic filesystem corruption (directories >turn into files, files get truncated), but no kernel panics, and she >has a 16 bit fat, but her disk is practically full, so perhaps it's >the caused by a real bug, and not my instalation. Well, I would have observe that my DOS filesystem code (I wrote it from scratch) is a little more immature than Microsoft's. I've been over the code a lot, since it's the most heavily used filesystem. But obviously after a while you start to see what you "know" is there, thus it's very helpful for others to take a look. Regards, Andy From vandys@glare.cisco.com Fri Feb 25 09:51:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01842; Fri, 25 Feb 1994 09:51:04 -0800 Received: from annexstein.csm.uc.edu by hubbub.cisco.com with SMTP id AA17318 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 09:23:52 -0800 Received: from localhost (humberto@localhost) by annexstein.csm.uc.edu (8.6.5/8.6.4) id MAA00365; Fri, 25 Feb 1994 12:15:24 -0500 Date: Fri, 25 Feb 1994 12:15:24 -0500 From: Humberto Ortiz Zuazaga Message-Id: <199402251715.MAA00365@annexstein.csm.uc.edu> To: vsta@cisco.com In-Reply-To: <199402251706.AA27271@glare.cisco.com> (message from Andrew Valencia on Fri, 25 Feb 1994 09:06:28 -0800) Subject: Re: VSTa FAT problems >>>>> "AV" == Andrew Valencia writes: AV> [Humberto Ortiz Zuazaga AV> writes:] >> experiments with VSTa cause kernel panics when I write to the >> filesystem: AV> Oops, I bet your kernel stayed up. Of course, if the only Actually, it did, but dumped me to the debugger. >> file rw.c line 253. I don't know which rw.c though ;-) (I >> assumed the dosfs rw.c). AV> It probably dropped you into the kernel debugger (with DEBUG, AV> the kernel currently drops into the debugger so you can look AV> around). A "pr" command would list the running/runnable AV> procs; the one with state O would be the one who has just AV> taken an un-handled event). Yes, that's what I guessed, it worked nicely. AV> Well, I would have observe that my DOS filesystem code (I AV> wrote it from scratch) is a little more immature than AV> Microsoft's. I've been over the code a lot, since it's the AV> most heavily used filesystem. But obviously after a while you AV> start to see what you "know" is there, thus it's very helpful AV> for others to take a look. I'll see if I can get a sparc hosted cross compiler going and give it a shot with the patched dos fs code, that way at least my wife's laptop should be able to self host. I don't know if I can grok the filesystem code enough to make a difference though. Humberto Ortiz Zuazaga zuazaga@ucunix.san.uc.edu From vandys@glare.cisco.com Fri Feb 25 09:55:47 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01846; Fri, 25 Feb 1994 09:55:45 -0800 Received: from localhost by glare.cisco.com with SMTP id AA28540 (5.67a/IDA-1.5 for ); Fri, 25 Feb 1994 09:28:35 -0800 Message-Id: <199402251728.AA28540@glare.cisco.com> To: Humberto Ortiz Zuazaga Cc: vsta@cisco.com Subject: Re: VSTa FAT problems In-Reply-To: Your message of "Fri, 25 Feb 1994 12:15:24 EST." <199402251715.MAA00365@annexstein.csm.uc.edu> Date: Fri, 25 Feb 1994 09:28:34 -0800 From: Andrew Valencia [Humberto Ortiz Zuazaga writes:] > AV> It probably dropped you into the kernel debugger (with DEBUG, > AV> the kernel currently drops into the debugger so you can look > AV> around). A "pr" command would list the running/runnable > AV> procs; the one with state O would be the one who has just > AV> taken an un-handled event). >Yes, that's what I guessed, it worked nicely. BTW, if your process is something less critical, you just enter the "q" (quit) command, and the debugger exits, allowing the OS to resume. Andy From vandys@glare.cisco.com Fri Feb 25 12:23:47 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id MAA01892; Fri, 25 Feb 1994 12:23:45 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA24722 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 11:56:34 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA06567; Fri, 25 Feb 94 11:56:32 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA25404; Fri, 25 Feb 94 12:56:30 MST Message-Id: <9402251956.AA25404@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 25 Feb 1994 12:56:30 MST In-Reply-To: Andrew Valencia "" (Feb 25, 11:36am) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , Werner Vogels Cc: vsta list > I'd be interested in really fleshing this out, but it might be a little > long to warrant the mailing list. Feel free to switch to my E-mail address > (vandys@cisco.com) and let's hammer out a lot more detail on this. Hey! This is interesting stuff. :-) - rob - From vandys@glare.cisco.com Fri Feb 25 12:03:52 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id MAA01889; Fri, 25 Feb 1994 12:03:49 -0800 Received: from localhost by glare.cisco.com with SMTP id AA07723 (5.67a/IDA-1.5 for ); Fri, 25 Feb 1994 11:36:39 -0800 Message-Id: <199402251936.AA07723@glare.cisco.com> To: Werner Vogels Cc: vsta list In-Reply-To: Your message of "Fri, 25 Feb 1994 14:31:50 +0100." <199402251330.AA24321@inesc.inesc.pt> Date: Fri, 25 Feb 1994 11:36:38 -0800 From: Andrew Valencia [Werner Vogels writes:] First of all, thank you for writing! It sounds like you might be able to add some very valuable functionality. >One of the reasons why I was initially atracted to vsta was that it was >published as a "real-time" (micro-kernel) OS. But when going through the >code and looking and the primitives and system calls I couldn't >really find a good justification for the "real-time" title. Well, the system was written offering a non-degrading scheduling task, and the kernel code was written to allow preemption. In my paper I tried to call out some of the synergy between what a microkernel needs and what certain real time features provide. My experience with real-time/embedded systems has been mostly product-oriented, in networking, using "old school" real-time features which have been around since well before the HP-1000 (my first RT system). >Although you seperate real-time from background threads and timesharing >threads the scheduling policy you implement is strictly FIFO on the threads. >This is not sufficient to implement any real-time environment. From my experience, I wondered if a simple round-robin queue of tasks, capable of preempting non "real time", would be sufficient. VSTa was mostly written to explore the opportunities in NOT doing something again, just because it was done that way before. Thus, I was interested in running with my single queue for a bit, and finding out IF and WHY it breaks. We can always add more queues/priorities. No, I won't take bets as to whether they're actually needed! :-) >To accomodate the required real-time functionality we need to augment the >tfork system call... I'm a little nervous. The kernel is currently tiny, and does an OK job. Actually, it needs its non-user priority mechanism fixed (more below), but it really runs rather well. I would rather beg off certain classes of real-time problems than have the kernel grow to encompass all possible scenarios. >... I would want at least rate monotonic, >earliest dealine and leat laxity. Hmmm, do you think we could do those in 1K (process debugging took 2K, so maybe 2K is OK)? >The other urgent items needed, are to supply the user space threads with >synchronization mechanisms. Currently we only have them in the kernel. >If you want to implement these with the possibility to offer priority >inversion protocols like priority ceilings, etc these primitives will have to >come from the kernel not a user level threads synch implementation, as >they have to closely cooperate with the scheduler. Yeah, I knew those were needed. One of our folks has written a user-level flavor, but it has all the usual limitations of a user-level implementation. We just haven't *needed* them yet, and each time I ponder writing them I spiral down in the trade-offs of queueing, fairness, starvation (back-end promotion--just say no!), and failure recovery. I guess I've mostly been waiting for somebody to need the mechanism, so I could use the need to guide the implementation. >Personaly if think we also need primitives to indicate preempatble regions, >etc. And also mechanisms to freeze all pages owned by a process/thread to >avoid page faults for that process. We can do this--I had to in order to keep from dying when the disk server or swap manager swapped out their own pages. It's a minimal implementation, but then, that's the point. >If the VSTa community is very eager to comply to POSIX we should try to get >as much of 1003.4(a) (real-time extensions) into the interface (and of course >functionality in the design). With respect to the scheduling there is a >POSIX requirment to at least support FIFO and RR scheduling. I would want to >add at least rate monotomic, earliest deadline first and least laxity first. Actually, we use POSIX as a guide-in-default; if we don't have a reason to do it differently, we'll do it POSIX. Thus, the formatted-print routine has the obvious name, but our events and protection deviate wildly. >I think we should give priority to real-time thread scheduling (1003.4a) over >the implementation of traditional real-time process scheduling (1003.4). This >off course means that we need a pthread interface to the kernel threads. If >cut out most of the signal stuff the pthread defeinition isn't much different >from any other thread interface, expect that it has explicit real-time >assignment hooks. We need an explicit preemption mask/allow mechanism (I use a hack now), and we need to check and preempt when the last spinlock is released. I think the interrupt handling code might have its hook in place, but that needs a check. I haven't worked with this stuff since I wrote it. Once this stuff is doing its stuff, we can spend more time on getting the policy part right. New kernel bugs will pop up when you start preempting in earnest. >Support for distribution is essential. And treating it as an "add-on" feature >may turn out to be a fundamental mistake. As a good micro-kernel should do >VSTa leaves it all to the user space to implement things, but until now we >have had not so very good experiences with user level implementations of >protocols stacks. Although Chris Maeda's work was great he still arrived >at times comparable to monolithic Mach and Ultrix. And we also know by now >that the way the packet filter/demultiplexer is build and is able to >interact with the device is crucial to get the better performance. As is the >quest to avoid crossing protection domains while moving the message through >the protocols. [Maybe you can comment on this Chris? as it is more your cup >of tea]. I *knew* that, all things being equal, my system would be slower because it has to switch processes to provide system services. There are lots of monolithic kernels, and most of the rest associate interrupt handling with a privileged mode of execution. The only question is whether it's still fast enough that you don't really care. I decided to run with the pure concept, and get what performance I could find. My context switching and scheduling paths are reasonably lean, and the result is, well, at least tolerable. >The packetfilter is an engineering issue, but basic support for the domain >crossing of data could become could an excellent feature of VSTa which would >avoid a lot of performance problems. Especially network file servers could >benefit from this. I pondered this issue, and decided to diverge from QNX. VSTa provides a inter-system pipe; if you want to talk across the net, you hook up with the guy who knows how to go out across the net. I'd like to have a go at doing this all in user space; it's big, it's complex, it would be a real pity to add it to the ring 0 code. >We could also learn from Mach what not to do if you want to extended you port >& port capability space across a cluster of machines. Hmmm, I just can't place a paper talking about this. Could you forward a reference? You're right; it sounds like I should read it. >As an intemediate solution we could adapt the x-kernel as the network >server while working on better (real-time, non-real-time, etc) mechanisms. >The port of the xkernel is trivial as soon the mutex's etc are available >to user space. Be aware that the xkernel performance is bad and some of the >protocols are not fully implemented, but it would be a relatively easy start. I was actually thinking of running KA9Q in a task. One of our folks already has an Ethernet driver (mostly, I'm told) running, so it should be easy to fire up Phil's stuff and do some basic networking. Then hack up the naming server, and do a little magic to the local port number name space so you can map part of it out to a remote destination. Of course, I'd like to reach more about Mach's experiences in this area, then revisit this. I'd be interested in really fleshing this out, but it might be a little long to warrant the mailing list. Feel free to switch to my E-mail address (vandys@cisco.com) and let's hammer out a lot more detail on this. Thanks for writing! Andy Valencia From vandys@glare.cisco.com Fri Feb 25 20:15:13 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01929; Fri, 25 Feb 1994 20:15:12 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA12524 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 19:48:04 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA08134; Fri, 25 Feb 1994 22:48:01 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA06922; Fri, 25 Feb 1994 22:47:57 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402260347.AA06922@world.std.com> Subject: threads To: vsta@cisco.com Date: Fri, 25 Feb 1994 22:47:56 -0500 (EST) Cc: larz@world.std.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1298 [Werner Vogels writes:] >I think we should give priority to real-time thread scheduling (1003.4a) over >the implementation of traditional real-time process scheduling (1003.4). This >off course means that we need a pthread interface to the kernel threads. If >cut out most of the signal stuff the pthread defeinition isn't much different >from any other thread interface, expect that it has explicit real-time >assignment hooks. Before too much effort is put into threads, we should consider whether existing mechanisms could be modified to handle (much of) the functionality provided by threads. Specifically, I'm thinking about something like the Plan 9 rfork primitive. Quoting from a News article posted by Rob Pike to comp.os.research a while ago: "...a primitive called rfork takes an argument that specifies which resources a process holds are to be shared with its child and which are to be copied or created anew. The resources include memory (stack is always copied), file descriptors, file name space, Unix-style environment variables, etc." If something like this were to be implemented in VSTa, and assuming that context switch times are relatively small, wouldn't the need for threads (mostly) go away? Mike Larson larz@world.std.com From vandys@glare.cisco.com Fri Feb 25 20:53:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01939; Fri, 25 Feb 1994 20:53:52 -0800 Received: from ds1.gl.umbc.edu by hubbub.cisco.com with SMTP id AA13231 (8.6.4/IDA-1.5 for ); Fri, 25 Feb 1994 20:26:44 -0800 Received: from umbc8.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by ds1.gl.umbc.edu (8.6.5/8.6.5) with ESMTP id XAA21150 for ; Fri, 25 Feb 1994 23:26:41 -0500 Received: from localhost (vijay@localhost) by umbc8.umbc.edu (8.6.5/8.6.5) id XAA27400; Fri, 25 Feb 1994 23:26:39 -0500 Date: Fri, 25 Feb 1994 23:26:39 -0500 (EST) From: Vijay Gill Subject: Re: threads To: vsta list In-Reply-To: <199402260347.AA06922@world.std.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Before too much effort is put into threads, we should consider whether > existing mechanisms could be modified to handle (much of) the > functionality provided by threads. Specifically, I'm thinking about I second this. To paraphrase from memory, a news post I read a while ago: Threads fix the symptom, not the problem (context switching is too slow). Instead of making threads, make the processes simpler and easier to context switch. In this day and age with MMU hardware, protection, shared memory etc, why implement something like a thread with the attendant loss of functionality for debugging (such as memory protection), etc. Threads hark back to the days when there was no hardware protection. vijay vijay@umbc.edu From vandys@glare.cisco.com Fri Feb 25 20:52:20 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA01936; Fri, 25 Feb 1994 20:52:19 -0800 Received: from localhost by glare.cisco.com with SMTP id AA00839 (5.67a/IDA-1.5 for ); Fri, 25 Feb 1994 20:25:11 -0800 Message-Id: <199402260425.AA00839@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: threads In-Reply-To: Your message of "Fri, 25 Feb 1994 22:47:56 EST." <199402260347.AA06922@world.std.com> Date: Fri, 25 Feb 1994 20:25:10 -0800 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >Before too much effort is put into threads, we should consider whether >existing mechanisms could be modified to handle (much of) the >functionality provided by threads. Specifically, I'm thinking about >something like the Plan 9 rfork primitive. I pondered this, but came to realize that generality does not beget simplicity. My favorite example is select(), an OS primitive which those of us in the real-time and/or multiprocessor operating system development and maintenance world have come to dread. Try making it (1) SMP safe, (2) preemptible, (3) fast, and (4) scalable all at the same time. And yet it is the most common mechanism used by servers in a socket environment. It is not entirely an accident that a VSTa server's msg_receive() accesses a single port which multiplexes its clients. In the case of VSTa, there are code paths which are substantially simplified by the knowledge that they are only accessible from the context of the last thread of execution under a process. The more variations you permit, the more general, larger, and harder to maintain your code becomes. Of course, some of the kernel features in Plan9 have been moved up into the C library (mount tables) or out to a user mode server (environment variables). Sharing becomes a user mode policy, not a system one. This leaves Plan9 options concerning: - Maintaining the wait() connection with your parent - Process signal (event) group - Open file (connection) table - Address space Of these, a VSTa thread does not interact with wait() (although the process containing it will when the last thread exit()s). Threads or processes may receive events (if process, each thread receives it). All threads interact with the single open connection table, and all threads share the same virtual address space. So far, VSTa threads have worked out pretty well in practice in my drivers and in Nick's windowing system. The biggest hole, discussed today, is that VSTa needs to, but does not yet, offer a mutual exclusion service to allow threads to efficiently interact. Andy From vandys@glare.cisco.com Sat Feb 26 04:22:45 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA02002; Sat, 26 Feb 1994 04:22:43 -0800 Received: from inesc.inesc.pt by hubbub.cisco.com with SMTP id AA23990 (8.6.4/IDA-1.5 for ); Sat, 26 Feb 1994 03:55:35 -0800 Received: from inesc.inesc.pt by inesc.inesc.pt with SMTP; id AA11297 (5.67a/SunOS4.1.3); Sat, 26 Feb 1994 12:54:13 +0100 Received: from localhost by ra.inesc.pt (4.1/SunOS4.1.3) id AA08369; Sat, 26 Feb 94 12:55:52 +0100 Message-Id: <9402261155.AA08369@ra.inesc.pt> To: vsta@cisco.com Subject: Re: threads In-Reply-To: Your message of "Fri, 25 Feb 94 22:47:56 EST." <199402260347.AA06922@world.std.com> Date: Sat, 26 Feb 94 12:55:51 +0100 From: Werner Vogels >Before too much effort is put into threads, we should consider whether >existing mechanisms could be modified to handle (much of) the >functionality provided by threads. Specifically, I'm thinking about >something like the Plan 9 rfork primitive. My view: I would want threads even in the case where we would have rfork(), (you emulate threads on it or whatever.) and rfork would be as efficient as promised. I use threads for a number of reasons: (1) they allow me to think in parrallel execution of my code in a very simple way (2) It easier for me to develop a system that allows 200.000 threads sharing an address space than 200.000 processes leaning on the mmu for protection sharing (3) non-realtime threads scheduling can be done in a simple user-level package that can give the developer of the application full control the way he wants his parralel tasks to be scheduled given the timeslice he gets from the OS, (4) building synchronization methods for threads are cheaper than for full processes for the same reason as (3). Threads have been arround for a long time, we called them Tasks in ADA and everybody was exteremely happy with them. We build some great systems with it without anybody complaining that we actually shouldn't use them but should fix the ADA compiler so we could have full ADA processes (yech) communicating with each other to build parrallel applications. Rob Pike stated that we don't understand fork() and exec(0 very well and that that is the main reason for us not to use them. Programming with rfork() (I've done it, I have plan9 on some local machines here) is much more complicated then calling a simple thread create function. My argument is that the problem is C that give us the problems here. Every more complicated issue has to come from a library and thus provides us with 20 different options. If we would be implementing VSTa in ADA or Modula we would just happily use threads because the language allows us to in an easy wasy. If C threads interfaces are kept simple they can provide the same programming support and joy of parrallelism. Debugging threads programs is often painfull, but this is because our debuggers are not very well suited for them. Put thread handling in there from the beginning and you will survive very well. -- Werner From vandys@glare.cisco.com Sat Feb 26 14:30:46 1994 Received: from barley.cisco.com (barley.cisco.com [131.108.13.143]) by amri.cisco.com (8.3/8.3) with SMTP id OAA02050; Sat, 26 Feb 1994 14:30:45 -0800 Received: by barley.cisco.com id AA19303 (5.67a/IDA-1.5 for vsta@amri.cisco.com); Sat, 26 Feb 1994 14:03:41 -0800 Date: Sat, 26 Feb 1994 14:03:41 -0800 From: Andrew Valencia Message-Id: <199402262203.AA19303@barley.cisco.com> To: vsta@cisco.com Subject: Patch #3--urgent The following is the patch format of the bug you saw go by on the mailing list yesterday. It's a real bug, and it'll corrupt your DOS filesystem, so please apply this patch if you haven't patched it on your own already. The original bug-fixer (Robert Mayer) supplied the appropriate fix, this is the same thing as a patch. Andy p.s. If Robert's ever in town I *will* buy him a beer for this one! *** c:/tmp/T0AA.AAA Sat Feb 26 14:55:32 1994 --- fat.c Sat Feb 26 14:50:58 1994 *************** *** 132,144 **** (dirents * sizeof(struct directory))/SECSZ; data0 *= SECSZ; /* * Get map of dirty sectors in FAT */ ! dirtymapsize = roundup(nclust, SECSZ) / SECSZ; dirtymap = malloc(dirtymapsize); ASSERT(dirtymap, "fat_init: dirtymap"); bzero(dirtymap, dirtymapsize); /* * Convert FAT-12 to FAT-16 --- 132,144 ---- (dirents * sizeof(struct directory))/SECSZ; data0 *= SECSZ; /* * Get map of dirty sectors in FAT */ ! dirtymapsize = roundup(nclust*sizeof(ushort), SECSZ) / SECSZ; dirtymap = malloc(dirtymapsize); ASSERT(dirtymap, "fat_init: dirtymap"); bzero(dirtymap, dirtymapsize); /* * Convert FAT-12 to FAT-16 From vandys@glare.cisco.com Sat Feb 26 16:09:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA02064; Sat, 26 Feb 1994 16:09:38 -0800 Received: from sole.cs.washington.edu by hubbub.cisco.com with SMTP id AA07346 (8.6.4/IDA-1.5 for ); Sat, 26 Feb 1994 15:42:34 -0800 Received: from localhost (localhost [127.0.0.1]) by sole.cs.washington.edu (8.6.4/7.1ws+) with SMTP id PAA23894; Sat, 26 Feb 1994 15:42:25 -0800 To: Werner Vogels Cc: vsta@cisco.com In-Reply-To: Your message of "Fri, 25 Feb 1994 14:31:50 +0100." <199402251330.AA24321@inesc.inesc.pt> Date: Sat, 26 Feb 1994 15:42:23 PST Message-Id: <23892.762306143@sole.cs.washington.edu> From: Chris Maeda Date: Fri, 25 Feb 1994 14:31:50 +0100 To: Andrew Valencia cc: vsta list From: Werner Vogels 2. distribution. Support for distribution is essential. And treating it as an "add-on" feature may turn out to be a fundamental mistake. As a good micro-kernel should do VSTa leaves it all to the user space to implement things, but until now we have had not so very good experiences with user level implementations of protocols stacks. Although Chris Maeda's work was great he still arrived at times comparable to monolithic Mach and Ultrix. And we also know by now that the way the packet filter/demultiplexer is build and is able to interact with the device is crucial to get the better performance. As is the quest to avoid crossing protection domains while moving the message through the protocols. [Maybe you can comment on this Chris? as it is more your cup of tea]. Well, no one ever said microkernels could get better performance than monolithic kernels. Microkernels are supposed to give you a more flexible system. We're still trying to figure out if that flexibility can be delivered with an acceptable performance cost. Right now, the answer is maybe. We know one way to do it for networking; for my thesis, I'm trying to determine if the approach I used for networking will work in general. There are a couple things that might help I/O performance. As you mention, one is a mechanism to transfer data across protection boundaries. A lightweight mechanim to transfer control would also be useful. Two papers to read for ideas are Peter Druschel's 1993 SOSP paper on fbufs (ftp from cs.arizona.edu:/xkernel/fbufs.ps) and Brian Bershad's work on Lightweight RPC (in ACM Transactions on Computer Systems, sometime in 1990, 1991, or 1992). Quick LPC in Windows NT is actually an implementation of Bershad's LRPC ideas. Another useful mechanism would be a way to quickly call interrupt handlers in user space. (You might have already examined some of these issues in vsta; I haven't had a chance to do much with the system lately.) By the way, thanks for the compliment. We could also learn from Mach what not to do if you want to extended you port & port capability space across a cluster of machines. A good place to start is the network IPC work at Arizona (cs.arizona.edu:/xkernel/usenix93.ps). The implemented Mach IPC in the xkernel and talk about some hard parts encountered when implementing the mach port semantics in a distributed environment. The fundamental problem with Mach IPC is that it violates Butler Lampson's rule of thumb that you shouldn't treat the local and remote case the same in a distributed system. A reasonable solution for IPC might be LRPC in the local case, and some kind of location-transparent network IPC in the remote case. V and Amoeba are possible sources of inspiration for the latter. Regards, Chris Maeda From vandys@glare.cisco.com Sun Feb 27 07:03:50 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id HAA02339; Sun, 27 Feb 1994 07:03:49 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA04709 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 06:36:42 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA14146; Sun, 27 Feb 1994 09:36:39 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA19639; Sun, 27 Feb 1994 09:36:37 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402271436.AA19639@world.std.com> Subject: Re: threads To: vsta@cisco.com Date: Sun, 27 Feb 1994 09:36:37 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2539 [Andrew Valencia writes] > I pondered this, but came to realize that generality does not beget > simplicity. ... [good reasons why it is better not make existing > interfaces all things to all people] Let me rephrase my question in a different way. Assume for a momemt that a) process context switch time is very fast under VSTA, b) there is a mechanism for sharing resources, in particular for sharing memory between processes (a useful thing anyway). Then my question is: given a) and b) above, does a thread package buy you anything? And if it does, is it worth the additional effort/code? [Werner Vogels writes] > My view: I would want threads even in the case where we would have > rfork(), (you emulate threads on it or whatever.) and rfork would be > as efficient as promised. I use threads for a number of reasons: (1) they > allow me to think in parrallel execution of my code in a very simple > way (2) It easier for me to develop a system that allows 200.000 threads > sharing an address space than 200.000 processes leaning on the mmu for > protection sharing (3) non-realtime threads scheduling can be done in a > simple user-level package that can give the developer of the application > full control the way he wants his parralel tasks to be scheduled given > the timeslice he gets from the OS, (4) building synchronization methods > for threads are cheaper than for full processes for the same reason as (3). (1) agreed. But, as you mention, it may be possible to emulate a threads library using existing process-level interfaces (does anyone know how QNX supports POSIX threads?) (2) OK, here's an example where a threads are better than processes. But I wonder if it is common to need so many threads/processes. Two applications that I have worked on recently, for example, use in the order of 5 - 10 processes. (3) this is true for a user-level threads library. Is it true for a kernel-supported threads environment? (4) from an implementation standpoint or execution standpoint? If the answer is implementation, this leads me to an important question: will VSTa ever support process level synchronization primitives? If so, then aren't threads-specific synchronization primitives redundant? Both Andy and Werner point out that threads are useful. I'm sure that this is true. But I think its useful to ask the following question: can we support a reasonable variety of applications with a minimum amount of redundancy? Mike Larson larz@world.std.com From vandys@glare.cisco.com Sun Feb 27 10:08:25 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA02368; Sun, 27 Feb 1994 10:08:24 -0800 Received: from ds1.gl.umbc.edu by hubbub.cisco.com with SMTP id AA07826 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 09:41:25 -0800 Received: from rpc30.gl.umbc.edu (vijay@rpc30.gl.umbc.edu [130.85.60.50]) by ds1.gl.umbc.edu (8.6.5/8.6.5) with ESMTP id MAA08831; Sun, 27 Feb 1994 12:41:22 -0500 Received: from localhost (vijay@localhost) by rpc30.gl.umbc.edu (8.6.5/8.6.5) id MAA15451; Sun, 27 Feb 1994 12:41:21 -0500 Date: Sun, 27 Feb 1994 12:41:21 -0500 (EST) From: Vijay Gill Subject: Re: threads To: Mike A Larson Cc: vsta@cisco.com In-Reply-To: <199402271436.AA19639@world.std.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mike A Larson: > > (1) agreed. But, as you mention, it may be possible to emulate a > threads library using existing process-level interfaces (does anyone > know how QNX supports POSIX threads?) I correspond extensively with both Dan Hildebrand and Dan T Dodge. Right now, they are waiting on the Posix committee to finalize the threads spec before implementing them. The design of QNX is such that it doesn't matter if its a process or a thread, they will both be switched in the same time. vijay gill vijay@umbc.edu From vandys@glare.cisco.com Sun Feb 27 10:59:13 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA02376; Sun, 27 Feb 1994 10:59:11 -0800 Received: from inesc.inesc.pt by hubbub.cisco.com with SMTP id AA08599 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 10:32:08 -0800 Received: from inesc.inesc.pt by inesc.inesc.pt with SMTP; id AA03384 (5.67a/SunOS4.1.3); Sun, 27 Feb 1994 19:30:43 +0100 Received: from dogen.inesc.pt by freya.inesc.pt with SMTP (PP); Sun, 27 Feb 1994 19:32:18 +0000 Message-Id: Date: Sun, 27 Feb 94 16:52:23 PST Reply-To: Werner Vogels From: Werner Vogels To: vsta@cisco.com Subject: Re: threads Mike Larson writes: > Let me rephrase my question in a different way. Assume for a momemt > that a) process context switch time is very fast under VSTA, b) there > is a mechanism for sharing resources, in particular for sharing memory > between processes (a useful thing anyway). Then my question is: given > a) and b) above, does a thread package buy you anything? And if it > does, is it worth the additional effort/code? Your assumptions are based on the idea (Rob Pike & friends share your view, so you are in good company) that threads are only there to fix performance problems that existed in heavy weight OS's like SVr4. I do not agree with this point of view. Threads, in my eyes, are an abstraction that gives easy access to parallelism to the programmer and as such have proven their right of existence in many other environments and programming languages (who where there before "forking" became a problem). Threads have become much more popular and visible since the wider availability of multiprocessor systems: threads were no longer an "nice programming abstraction" but they actually could buy you additonal cycles by exploiting the available parallel power. > But, as you mention, it may be possible to emulate a > threads library using existing process-level interfaces I think you have four options: 1. you want threads only as a nice programming abstraction. In this you would probably not be bothered wheter your run-time system forks shared memory processes or uses a coroutine like structure to manage the threads of control. (Sun LWP and Tom Doepner's Brown threads are simple examples, Presto and FastThreads (UW) more elaborate ones). 2. you want your application to have full control over your scheduling. You allocate a number of processors to an adress space, notify the thread runtime system of the current state and let the run-time system figure out the best way to schedule the threads. This is done in Tom Anderson's "scheduler activations" and also available for Mach. The new OS build in the Pegasus project (Mullender and Leslie) explores this method even more deeper. The kernel needs to be "process aware", but not really "thread aware". 3. you want to explore parallelism as much as possible but are satisfied with the system handling this for you and you do not have a system that does (2). Your runtime systems either interfaces with kernel threads that are wired to different processors or you use a shared memory process interface (that also can be allocated to different processors). 4. you want real-time thread support. Forget all previous options. The only way to achieve system wide predictable scheduling is to have the kernel manage the threads. Interaction between the synchronization management and the scheduler are also inevitable. A hierachical organization where the processes are "real-timed" and the process run-time system manages the threads like in the previous options is in some "very soft" cases possible (for ex. dedicated multi media systems). But in general anything else then centralized threads for real-time is a no-no. My main problem with the shared memory process approach is that I do not really believe that process context switches will ever be as cheap as thread switching. In the process case you still have to manage some vm mapping and do some domain protection work. But the worst thing is that in most cases the TLB contents will be lost, which will be the death of your system performance wise. Thread scheduling normally is saving a few registers and loading the new ones and off you go. If VSTa wants to focus on real real-time (I'll start a "thread" on that ones this one dies out) it will be difficult to avoid the last option where your threads will have to be kernel based. In other cases I think a "scheduler activations" approach would be extremely elegant. > 2) OK, here's an example where a threads are better than processes. > But I wonder if it is common to need so many threads/processes. Two > applications that I have worked on recently, for example, use in the > order of 5 - 10 processes. Many threads, etc: everything that you can describe as "highly parallel" Distributed object stores, telecommunications switches, banking/money exhange applications, etc. I must admit I exaggerated a bit by use 200.000, threads, commonly in the telecommunication switch applications we don't get further than invoking 2.000 - 8.000 threads per second. The object stores are much more complex, have more threads, but most of them are suspended on some communication channel. especially in the case of the fast running of threads like in the telecom switches keeping the TLB happy is essential. having the same physicall to virtual mapping all the time helps a lot. > (3) this is true for a user-level threads library. Is it true for > a kernel-supported threads environment? No, kernel threads obviously cost more than user level ones. This is the whole idea behind the scheduler activations work. If you do not need explicite kernel scheduling (like in real-time) you should leave it to the application run-time system. > (4) from an implementation standpoint or execution standpoint? If > the answer is implementation, this leads me to an important question: > will VSTa ever support process level synchronization primitives? > If so, then aren't threads-specific synchronization primitives > redundant? Again it all depends where you do it. Buidling user level synchronization is in principle not very difficult if you can avoid to be preempted when accessing the synchronization primitives. It is also extremely cheap. Process synchronization is the worst case because your synchronization object have to be available system wide. But in principle they do not have to be much less efficient that kernel scheduled thread synchronization. For the latter you can make a number of optimalizations as threads synchronizations primitives only are used to be used with one resource container. > But I think its useful to ask the following question: can > we support a reasonable variety of applications with a minimum amount of > redundancy? if you want to serve predictable & deterministic real-time applications as well as regular time sharing applications you'll have to decide what to put in run-time support systems and what in the kernel. In general the strigent timing constraints of real-time apllications will be the most demanding wrt kernel support. Remember that the only thing the kernel schedules in VSTa is threads, processes are only there to indicate the shared resources among threads. -- Werner PS with respect to the QNX question, the last thing I heard they are waiting for the 1003.4a spec to become more stable. Which could mean many more years. From vandys@glare.cisco.com Sun Feb 27 15:18:17 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with SMTP id PAA02416; Sun, 27 Feb 1994 15:18:15 -0800 From: john%bilton@bilton.demon.co.uk Received: from bilton (bilton.demon.co.uk) by dirt.cisco.com with SMTP id AA01146 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 14:51:13 -0800 Received: by bilton (Linux Smail3.1.28.1 #14) id m0pau3P-0008YiC; Sun, 27 Feb 94 22:33 GMT Message-Id: Date: Sun, 27 Feb 94 22:33 GMT To: vsta@cisco.com Subject: How did VSTA start? Just out of interest I was wondering where VSTA started? Which part was written first? What is the least part of an operating system you can have? From vandys@glare.cisco.com Sun Feb 27 16:07:31 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id QAA02424; Sun, 27 Feb 1994 16:07:29 -0800 Received: from localhost by glare.cisco.com with SMTP id AA23868 (5.67a/IDA-1.5 for ); Sun, 27 Feb 1994 15:40:31 -0800 Message-Id: <199402272340.AA23868@glare.cisco.com> To: john%bilton@bilton.demon.co.uk Cc: vsta@cisco.com Subject: Re: How did VSTA start? In-Reply-To: Your message of "Sun, 27 Feb 1994 22:33:00 GMT." Date: Sun, 27 Feb 1994 15:40:31 -0800 From: Andrew Valencia [john%bilton@bilton.demon.co.uk writes:] >Just out of interest I was wondering where VSTA started? Which part was >written first? What is the least part of an operating system you can >have? Oh, boy. Here goes my daily message! First, I will keep all discussion here on the list until the volume grows large enough to warrant its own list, private E-mail, or whatever. Please don't feel like you have to unsubscribe just to control the volume of E-mail; let me know privately and I'll take care of it. Real-time support: I wanted enough RT support to do com port drivers and such in user mode. I never really intended to add the RT support needed to allow implementation of "hard" RT systems, that is a Phalanx system or other scary thing where you *need* *guarantees* about which parts get processed how. Of course, VSTa has become more than my own interests; I opened it up so it can benefit from other people's expertise. If somebody gives me patches to add better RT support, my only objective would be to keep the microkernel "micro". Threads/scheduling: I implemented the kind of thread which my own experience indicated I would want. The hierarchical scheduler lends itself well to this organization--threads exist in common below a single node representing the process. POSIX yield() (or whatever they named it this week) would be very gratifying to code up! Distribution: I still don't think I want to put distributed messaging into the kernel. If a client writes a message to a server: Client -> Server I really don't see why we can't implement this as: SystemA | System B Client -> (TCP server -> LAN) -> (LAN -> TCP server) -> Server | The much more interesting question is what kind of smoke and mirrors are needed to cause such a connection to come into existence without a lot of explicit, networking-oriented commands on the part of a client. My current guess is that the namer process becomes a lot more complex, and perhaps interacts with the kernel port_name->server mechanism. VSTa development: I wrote the data structures, and then the messaging interface. I coded a server (BFS, I think), modifying the messaging interface as needed to make writing the server reasonable. I then wrote up some messaging emulation routines, and could then run BFS under DOS with myself typing in things to make it look like BFS had clients coming in over VSTa. I wrote the console, keyboard, and then I think I started in on the kernel. The first thing the kernel ever ran was a single process which put a * out on the COM1 port. Next was a process writing "Hello, world" to the console server, which displayed it on the screen. After that was a walking *'s thing to run the messaging system at full speed. I hope you all had a pleasant weekend! I spent several hours of it starting a port of BSD's "ash", as well as putting multi-console support into the console display server. A couple tweaks to the keyboard driver, and you should be able to toggle between sessions using ALT-F1 and such. You still don't get signals, though--we need a REAL server for that, and I'm hoping MADO will soon be available to do the job. Andy From vandys@glare.cisco.com Sun Feb 27 16:34:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA02432; Sun, 27 Feb 1994 16:34:57 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA14373 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 16:07:59 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id JAA16653; Mon, 28 Feb 1994 09:07:54 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA15394; Mon, 28 Feb 1994 09:07:53 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA02147; Mon, 28 Feb 1994 09:07:51 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00622; Mon, 28 Feb 94 09:07:03 +0900 Date: Mon, 28 Feb 94 09:07:03 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402280007.AA00622@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Threads Andy says: >So far, VSTa threads have worked out pretty well in practice in my >drivers and in Nick's windowing system. The biggest hole, discussed >today, is that VSTa needs to, but does not yet, offer a mutual >exclusion service to allow threads to efficiently interact. I must agree with this. I find that threads in VSTa fit my needs very well. I think threads are generally used to allow the programmer to make the parallism of many programs explicit, and the VSTa system goes just far enough that one can simply fork off the threads, and then think of each thread as a seperate program. As Andys noted, mutual exclusive primitives are needed to make it truly easy: I've been faking it somewhat (in a non-portable way), but such support should probably be offered by VSTa itself. One question about threads in VSTa: A thread is created by giving the address of a function to execute. Is returning from that function allowed? I have assumed it is not... From vandys@glare.cisco.com Sun Feb 27 16:44:03 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id QAA02435; Sun, 27 Feb 1994 16:44:02 -0800 Received: from localhost by glare.cisco.com with SMTP id AA24474 (5.67a/IDA-1.5 for ); Sun, 27 Feb 1994 16:17:04 -0800 Message-Id: <199402280017.AA24474@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Threads In-Reply-To: Your message of "Mon, 28 Feb 1994 09:07:03 +0900." <9402280007.AA00622@europa.nsis.cl.nec.co.jp> Date: Sun, 27 Feb 1994 16:17:04 -0800 From: Andrew Valencia [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >One question about threads in VSTa: A thread is created by giving the >address of a function to execute. Is returning from that function >allowed? I have assumed it is not... Emphatically not! First, I don't copy the stack, which is a savings. Copy-on-write is fine, but you're going to write all over your stack, so pay now or pay later, you'll still pay. But since threads share address space, copying stacks is a loss anyway--all those neat frame pointers and stuff would point to the old stack, not the new one. Thus, tfork(routine) sets up a fresh (empty) stack and starts you running at the given routine. Now, I *wish* I'd allowed a second argument, so that "routine" would be entered as: routine(void *arg) { ... } As currently there's no easy, reentrant way to send args to your new thread. Somewhat incompatible, but worth it? Andy From vandys@glare.cisco.com Sun Feb 27 17:00:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id RAA02443; Sun, 27 Feb 1994 17:00:57 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA14863 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 16:33:59 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id JAA17889; Mon, 28 Feb 1994 09:33:56 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA16291; Mon, 28 Feb 1994 09:33:55 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA02672; Mon, 28 Feb 1994 09:33:52 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00749; Mon, 28 Feb 94 09:33:03 +0900 Date: Mon, 28 Feb 94 09:33:03 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402280033.AA00749@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Threads Andy writes: >you running at the given routine. Now, I *wish* I'd allowed a second >argument, so that "routine" would be entered as: > >routine(void *arg) >{ > ... >} > >As currently there's no easy, reentrant way to send args to your new >thread. Somewhat incompatible, but worth it? It might be a nice feature, but in all honesty, I don't know how useful it would be. When I think use threads, I try to think of them as a complete, self-sufficient entity of their own, which communicate via some IPC mechanism (currently a shared event queue in MADO). As such, none of the threads in MADO would benefit from this at all. Other opinions are welcome of course :-) From vandys@glare.cisco.com Sun Feb 27 17:24:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id RAA02453; Sun, 27 Feb 1994 17:24:06 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA15383 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 16:57:01 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id JAA19085; Mon, 28 Feb 1994 09:56:59 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA17132; Mon, 28 Feb 1994 09:56:57 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA04765; Mon, 28 Feb 1994 09:56:56 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00881; Mon, 28 Feb 94 09:56:08 +0900 Date: Mon, 28 Feb 94 09:56:08 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402280056.AA00881@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Distributed systems Andy said earlier that he'd like to see distributed systems implemented in user space. I agree, because I feel that it will take quite a lot of trial and error to hit upon a scheme than works well in all cases, and flexibility will be important (and VSTa allows servers to be killed or replaced at runtime). Once things are working well, performance could be analysed to see whether a kernel implementation is needed or not. I imagined a similar architecture to Andy outlined, and from what I can see, the biggest problem will probably be in the naming scheme used for message forwarding. If a file-based naming system is used (arguably a good idea, even for distributed object systems like DOE), then hacking namer, and then writing a multiplexing server to run above the TCP/IP or rs232c server would seem to be enough to get something running. The only problem with such a system would be that every system would need to be running a local copy the multiplexing server so they can understand where the messages should be sent... From vandys@glare.cisco.com Sun Feb 27 22:20:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id WAA02513; Sun, 27 Feb 1994 22:20:48 -0800 Received: from Sun.COM by hubbub.cisco.com with SMTP id AA21270 (8.6.4/IDA-1.5 for ); Sun, 27 Feb 1994 21:53:52 -0800 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11203; Sun, 27 Feb 94 21:52:56 PST Received: from burgess.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14429; Sun, 27 Feb 94 21:52:07 PST Received: by burgess.Eng.Sun.COM (4.1/SMI-4.1) id AA04861; Sun, 27 Feb 94 21:55:57 PST Date: Sun, 27 Feb 94 21:55:57 PST From: Jacob.Levy@Eng.Sun.COM (Jacob Levy) Message-Id: <9402280555.AA04861@burgess.Eng.Sun.COM> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com In-Reply-To: <9402280056.AA00881@europa.nsis.cl.nec.co.jp> Subject: Distributed systems Reply-To: jyl@toss.Eng.Sun.COM I agree strongly that things like inter-machine communication should be implemented in user space. That way you don't have to worry in the kernel about managing things that point at things in other machines. It makes management of resources simpler (local) for the kernel. Of course SOMEONE still has to worry about it, but (a) it ain't Andy :-) and (b) several different schemes can coexist, in the spirit of "let a thousand flowers bloom". About threads and synchronization: the recent discussion on this list certainly is welcome and niot too high-volume (or high pitched :-). Personally I am firmly a believer of capability based systems. There, access is shared when you decide to share it with someone. Add messages and you've got all the synchronization you are ever going to need. Can't close without a shameless plug for stuff I like that Sun is doing: I encourage everyone seriously interested in how to iplement distributed secure systems to familiarize themselves with the Spring work at Sun. Monday I'll be posting an email address where requests for papers may be sent. The recent SOSP Proceedings also has a slew of Spring work in it. --JYL From vandys@glare.cisco.com Mon Feb 28 04:57:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA02619; Mon, 28 Feb 1994 04:57:13 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA29985 (8.6.4/IDA-1.5 for ); Mon, 28 Feb 1994 04:30:18 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA09597; Mon, 28 Feb 1994 07:30:15 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA10877; Mon, 28 Feb 1994 07:30:12 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199402281230.AA10877@world.std.com> Subject: Re: threads To: vsta@cisco.com Date: Mon, 28 Feb 1994 07:30:12 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 856 [Werner Vogels writes] > If VSTa wants to focus on real real-time (I'll start a "thread" on that ones > this one dies out) ... OK, Werner would like to focus on real real-time and I should spend more time working on the SCSI driver :-). So lets close this thread and get on with it. From my standpoint, there are two important issues related to this discussion. 1) before we add a new feature to VSTa, we should ask the following questions: What problem will adding this feature solve? Could the problem be solved just as well using existing features or features that are very likely to be added to VSTa in the future? 2) process context switch time must always be fast and threads should not, in general, be used to compensate for situations where process context switch time does not meet expectations. Mike Larson From vandys@glare.cisco.com Mon Feb 28 05:19:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id FAA02622; Mon, 28 Feb 1994 05:19:56 -0800 Received: from junior.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA00488 (8.6.4/IDA-1.5 for ); Mon, 28 Feb 1994 04:52:59 -0800 Received: by junior.vmars.tuwien.ac.at (5.65/DEC-Ultrix/4.3) id AA05239; Mon, 28 Feb 1994 13:52:45 +0100 From: hp@vmars.tuwien.ac.at (Peter Holzer) Message-Id: <9402281252.AA05239@junior.vmars.tuwien.ac.at> Subject: Re: Runes To: vsta@cisco.com Date: Mon, 28 Feb 94 11:52:44 GMT-1:00 In-Reply-To: <9402140746.AA02398@europa.nsis.cl.nec.co.jp>; from "Gavin Thomas Nicol" at Feb 14, 94 2:46 am Reply-To: hp@vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Gavin Thomas Nicol) wrote: > > I am about to implement the rune handling code for VSTa, because MADO > and bitblt depend on it. I have basically decided the following: > > 1) A rune will be 16 bits and use Unicode > 2) The I/O of runes will support UTF/2 as the core, and EUC, JIS, and > whatever else eventually. These are all multi-byte formats. Good. > Before I start coding, I'd like to hear comments on the following: > > 1) Is it necessary to implement the ANSI-defined wchar_t functions (it > seems few people use them)? I didn't write any programs with wide characters yet, so I don't know. All those funcions seem to be very simple, so they can easily be implemented as needed. > 2) Does anyone see a need to support locales? From my experience, they > offer little benefit to the average user, as users seldom > understand them, and if they do understand them, the locale > implementation is usually limited. The only thing I expect from a locale is a way to change collating sequences. This is important since accented characters are not in a useful order for most (all?) languages. Lowercase/uppercase-mappings are probably not locale-dependend. I don't care much for currency-signs, decimal point/comma and similar things. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers