From pat%wesson@joyce.cs.su.OZ.AU Fri Nov 5 12:03:15 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14403; Fri, 5 Nov 93 12:03:14 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14396; Fri, 5 Nov 93 12:03:40 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02737(netkeeper.sj.nec.com ); Fri, 5 Nov 93 12:03:39 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23650(archimedes.inoc.sj.nec.com ); Fri, 5 Nov 93 12:03:37 -0800 Received: from amri.cisco.com by hubbub.cisco.com with SMTP id AA00566 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 11:54:20 -0800 Received: from hubbub.cisco.com by amri.cisco.com (AA00232); Fri, 5 Nov 93 12:39:31 -0800 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA00508 (5.67a/IDA-1.5 for ); Fri, 5 Nov 1993 11:52:17 -0800 Received: from wesson by joyce.cs.su.OZ.AU (mail from pat for vsta@cisco.com) with MHSnet; Sat, 06 Nov 1993 06:52:16 +1100 Received: from wesson by garion.it.com.au with smtp (Smail3.1.28.1 #3) id m0ovXFX-0000Yb5; Sat, 6 Nov 93 03:55 WST Message-Id: From: pat%wesson@joyce.cs.su.OZ.AU (Pat Mackinlay) Subject: Re: Serial mouse To: hp@vmars.vmars.tuwien.ac.at Date: Sat, 6 Nov 1993 03:49:04 +0000 () Cc: vsta@cisco.com In-Reply-To: <9311051602.AA11817@quasi.vmars.tuwien.ac.at> from "Peter Holzer" at Nov 5, 93 05:02:17 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 654 Status: OR > > The best documentation I can come up with on the mouse protocol is actually > > the source to the abovementioned program "selection". This program basically > But beware that there are two kinds of serial mice for PCs: two-button > mice (Microsoft) and three-button mice (PC-Systems). I think selection > only handles the former. If needed I can dig up the sources of Mini-X Selection-1.5 (the version I sent to Nick) can handle both the Microsoft and Mouse Systems mouse protocols. It has support for some other types (ps/2, logitech etc), but I suspect that these mice simply use the same protocol with a different physical interface. -- Pat. From vandys@cisco.com Wed Nov 17 09:54:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21271; Wed, 17 Nov 93 09:53:38 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01182; Wed, 17 Nov 93 09:54:13 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08158(netkeeper.sj.nec.com ); Wed, 17 Nov 93 09:54:11 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18598(archimedes.inoc.sj.nec.com ); Wed, 17 Nov 93 09:54:09 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.13.56]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00065; Wed, 17 Nov 1993 10:20:11 -0800 Received: from localhost by glare.cisco.com with SMTP id AA28603 (5.67a/IDA-1.5 for ); Wed, 17 Nov 1993 09:35:16 -0800 Message-Id: <199311171735.AA28603@glare.cisco.com> To: vsta@cisco.com Subject: v1.1 beta now available Date: Wed, 17 Nov 1993 09:35:15 -0800 From: Andrew Valencia Status: OR Hi, folks. I have just placed the v1.1 beta version of VSTa on ftp.cisco.com:vandys/vsta. This version includes the long filename/contiguous allocation filesystem, numerous bug fixes, a source reorganization, an on-screen kernel debugger, lots more routines for the C library, and many new commands. It also adds passing of arguments to boot servers, and fixes numerous compatibility issues with the WD/IDE driver and the GNU C compiler. Give it a spin and let me know what you find! :-) Andy Valencia vandys@cisco.com From Remy.Card@masi.ibp.fr Wed Nov 17 10:39:20 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21827; Wed, 17 Nov 93 10:39:18 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01537; Wed, 17 Nov 93 10:39:54 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16426(netkeeper.sj.nec.com ); Wed, 17 Nov 93 10:39:53 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18771(archimedes.inoc.sj.nec.com ); Wed, 17 Nov 93 10:39:50 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00139; Wed, 17 Nov 1993 11:05:27 -0800 Received: from ibp.ibp.fr by hubbub.cisco.com with SMTP id AA12116 (8.6.4/IDA-1.5 for ); Wed, 17 Nov 1993 10:20:26 -0800 Received: from masi.ibp.fr by ibp.ibp.fr (5.65/ibp-1.0) at Wed, 17 Nov 1993 19:19:53 +0100 Received: from ares.ibp.fr by masi.ibp.fr (5.65/masi-1.2) at Wed, 17 Nov 1993 18:19:35 GMT From: Remy.Card@masi.ibp.fr (Remy CARD) Message-Id: <199311171819.AA03188@masi.ibp.fr> Subject: Re: v1.1 beta now available To: vandys@cisco.com (Andrew Valencia) Date: Wed, 17 Nov 1993 19:19:37 +0000 (GMT) Cc: vsta@cisco.com In-Reply-To: from "Andrew Valencia" at Nov 17, 93 09:35:15 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 619 Status: OR > > Hi, folks. > > I have just placed the v1.1 beta version of VSTa on ftp.cisco.com:vandys/vsta. > This version includes the long filename/contiguous allocation filesystem, > numerous bug fixes, a source reorganization, an on-screen kernel debugger, > lots more routines for the C library, and many new commands. It also adds > passing of arguments to boot servers, and fixes numerous compatibility issues > with the WD/IDE driver and the GNU C compiler. This version is also available from ftp.ibp.fr (which mirrors VSTa) in the directory /pub/vsta. > > > Andy Valencia > vandys@cisco.com > Remy From kphung@hkueee.hku.hk Fri Nov 19 08:32:56 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11082; Fri, 19 Nov 93 08:32:40 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09087; Fri, 19 Nov 93 08:33:18 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11340(netkeeper.sj.nec.com ); Fri, 19 Nov 93 08:33:17 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24500(archimedes.inoc.sj.nec.com ); Fri, 19 Nov 93 08:33:12 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00072; Fri, 19 Nov 1993 09:02:33 -0800 From: kphung@hkueee.hku.hk Received: from YALEVM.YCC.YALE.EDU by hubbub.cisco.com with SMTP id AA08527 (8.6.4/IDA-1.5 for ); Fri, 19 Nov 1993 05:53:24 -0800 Received: from HKUJNT.BITNET by YaleVM.YCC.Yale.Edu (IBM VM SMTP V2R2) with BSMTP id 3440; Fri, 19 Nov 93 08:53:02 EST Received: from hkueee.hku.hk by HKUJNT.BITNET; Fri, 19 Nov 93 21:53 +0800 Received: by hkueee.hku.hk (4.1/SMI-4.1) id AA02745; Fri, 19 Nov 93 21:51:14 HKT Date: Fri, 19 Nov 93 21:51:14 HKT Subject: boot.exe problem To: vsta@cisco.com Message-Id: <9311191351.AA02745@hkueee.hku.hk> X-Envelope-To: vsta@cisco.com Status: OR >That is the routine which actually starts VSTa. Have you verified >that it dies IN that routine, or is it possible that it has actually >switched from there into VSTa itself, and is dying in 32-bit mode >running the VSTa kernel? Yeap, I think that your suggestion is right and the problem is mostly happened in the boot file system as I tried to stop in the very beginning of the initialisation in the kernel. It still reboots my 386. Ah, I find that you have said the root file system is installed at the first partition, but my configuration is rather complicated with a Linux installed on the same harddisk. I would want to see if my configuration should run VSTa or not. Please give comments or remedies. 1. Linux Loader (LILO) is installed which can allow me to select a partition to bootstrap. 2. partition 1 and 2 are installed by Linux. 3. partition 3 is a normal DRDOS 6.0. 4. partition 4 is a compressed superstor drive of DRDOS. 5. both VSTa and DJGPP are in partition 4 ( D: of DRDOS ). I think such complexities should be the source of problem. >>Now, I would like to ask if I can get some FAQs or document concerning >>the boot.exe and allow me to have some background before hacking into >>the codes. Anyany, I would muuuuuuch appreciate if you can give me >>any hints or refernece. >I have an overview of the boot process which I wrote up a while ago. >I hope it'll help you get started debugging! > > Andy Valencia Thank you for the document in boot.exe. Should I get more docs about VSTa? Any comments or suggestions are welcome from those trying VSTa in there PC. Starry Hung kphung@hkueee.hku.hk From larz@world.std.com Mon Nov 22 10:38:11 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29066; Mon, 22 Nov 93 10:38:10 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21170; Mon, 22 Nov 93 10:38:51 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22480(netkeeper.sj.nec.com ); Mon, 22 Nov 93 10:38:50 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01183(archimedes.inoc.sj.nec.com ); Mon, 22 Nov 93 10:38:48 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00093; Mon, 22 Nov 1993 11:13:35 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA06438 (8.6.4/IDA-1.5 for ); Mon, 22 Nov 1993 10:29:37 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA02761; Mon, 22 Nov 1993 13:29:33 -0500 Date: Mon, 22 Nov 1993 13:29:33 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199311221829.AA02761@world.std.com> To: vsta@cisco.com Subject: cache control primitives Status: OR Hi, I don't see any primitives for flushing/invalidating the processor cache. Are there cache control functions available to device drivers that do DMA? Or are cache control functions not necessary because: 1) the VSTa kernel handles this automatically 2) not needed for the 386 based PC's. Thanks. Mike Larson (larz@world.std.com - new email address) From vandys@cisco.com Mon Nov 22 10:41:53 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29074; Mon, 22 Nov 93 10:41:52 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21187; Mon, 22 Nov 93 10:42:33 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22535(netkeeper.sj.nec.com ); Mon, 22 Nov 93 10:42:32 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01187(archimedes.inoc.sj.nec.com ); Mon, 22 Nov 93 10:42:29 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00096; Mon, 22 Nov 1993 11:19:10 -0800 Received: from localhost by glare.cisco.com with SMTP id AA26074 (5.67a/IDA-1.5 for ); Mon, 22 Nov 1993 10:35:13 -0800 Message-Id: <199311221835.AA26074@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: cache control primitives In-Reply-To: Your message of "Mon, 22 Nov 1993 13:29:33 EST." <199311221829.AA02761@world.std.com> Date: Mon, 22 Nov 1993 10:35:12 -0800 From: Andrew Valencia Status: OR [larz@world.std.com (Mike A Larson) writes:] >[cache control for DMA drivers not needed...] > 1) the VSTa kernel handles this automatically > 2) not needed for the 386 based PC's. The latter. All PC's I have ever worked on run with physical cache, write-through, which flushes itself when it sees DMA to its addresses. Therefore, there is no need to even abstract the concept; when I do a port to a machine with a non-snooping or virtual cache, I will have to add a port-specific interface to provide such control. A virtual cache will add the additional unpleasantness of having the hat_* layer in mach/ have to avoid aliasing. I believe all the hooks are in place for a hat_* layer to do this, but again (due to i386/ISA architecture) I've never had to actually implement this. Regards, Andy From nick@nsis.cl.nec.co.jp Tue Nov 23 20:10:03 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08452; Tue, 23 Nov 93 20:10:02 PST Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26837; Tue, 23 Nov 93 20:10:51 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10881(netkeeper.sj.nec.com ); Tue, 23 Nov 93 20:10:49 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06419(archimedes.inoc.sj.nec.com ); Tue, 23 Nov 93 20:10:47 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00075; Tue, 23 Nov 1993 20:34:34 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA24583 (8.6.4/IDA-1.5 for ); Tue, 23 Nov 1993 16:32:49 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA22724; Wed, 24 Nov 1993 09:32:39 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA08528; Wed, 24 Nov 1993 09:32:38 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931119.1) id AA20502; Wed, 24 Nov 1993 09:32:36 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA01754; Wed, 24 Nov 93 09:32:34 JST Date: Wed, 24 Nov 93 09:32:34 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311240032.AA01754@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Update Status: OR Ok. Here is the current project list, and a few odds and sods. ------------------------- Project List -----+------------------------------ TASK | WHO --------------------------------------------+------------------------------ VSTa file system (Non-Unix) | vandys@cisco.com - Beta version in VSTa 1.1 | Window System (Non-X11) | nick@nsis.cl.nec.co.jp Update kbd so key mappings can be downloaded| nick@nsis.cl.nec.co.jp Mouse driver | nick@nsis.cl.nec.co.jp - Written. IBM code needs testing. | Update wd to handle various IDE drives | ???? Shared libraries | /proc server (for use with ps etc.) | Debugger (using /proc??) | Unix/Linux file systems | Math emulator (inside kernel? server?) | Update/expand libc (and include files) | SCSI disk server | myl@genrad.com, ... Network server | dave@computone.com RS232c server | Rune handling code (based on BSD 4.4 code?) | Porting of applications (make, emacs, ...) | --------------------------------------------+------------------------------- Question: Can we mmap() files/ports into the memory map of a process. The reason I'm asking is that I've been thinking about an Object Oriented File System (basically just a persistant object store), and mmaping seems to be one of the easiest ways to achieve it. Actually, I have been thinking about objects a lot recently, and VSTa seems to be an ideal platform to experiment with. MADO Status: Things are coming along. I'm almost finished rewriting the server interface to bitblt. Once that's done, I'll rewrite the keyboard driver, and then start on MADO itself. Bitblt still has many parts unfinished (graphics primitives especially), and there is no IBM driver yet. If anyone is interested in working on these areas, let me know! The main reason for the slowness is that I have spent a lot of time on fonts. I have finally got fonts to a reasonably usable level, and have converted 200+ font files from X11. The font naming scheme is similar to X11.... From vandys@cisco.com Tue Nov 23 20:27:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08463; Tue, 23 Nov 93 20:27:16 PST Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26876; Tue, 23 Nov 93 20:28:05 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11063(netkeeper.sj.nec.com ); Tue, 23 Nov 93 20:28:04 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06434(archimedes.inoc.sj.nec.com ); Tue, 23 Nov 93 20:28:01 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00081; Tue, 23 Nov 1993 20:55:25 -0800 Received: from localhost by glare.cisco.com with SMTP id AA21334 (5.67a/IDA-1.5 for ); Tue, 23 Nov 1993 20:11:43 -0800 Message-Id: <199311240411.AA21334@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Update In-Reply-To: Your message of "Wed, 24 Nov 1993 09:32:34 +0200." <9311240032.AA01754@silk1.nsis.cl.nec.co.jp> Date: Tue, 23 Nov 1993 20:11:41 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] > Can we mmap() files/ports into the memory map of a process. The >reason I'm asking is that I've been thinking about an Object Oriented >File System (basically just a persistant object store), and mmaping >seems to be one of the easiest ways to achieve it. Actually, I have been >thinking about objects a lot recently, and VSTa seems to be an ideal >platform to experiment with. I use mmap() to provide exec()'ing of files. I support read-only demand-filled views of a file, and I support copy-on-write views. I omit read/write file access because (1) for it to be coherent with all other processes, each and every server would have to be built using mmap(), (2) since granularity is at the page size, it doesn't scale across networks well, and (3) when you want to page a dirty page out, you have to write it back to the server--which, being a user process, may not complete your I/O in any finite amount of time. So, coherent mmap()'ed access to files does not simplify servers, does not simplify your kernel, does not scale to networked configurations, and can easily be detrimental to overall system stability. For these reasons, I decided to omit the feature. If you want to experiment with such a function, you should probably start with os/kern/pset_fod.c. This is the pset layer which maps the filling of page slots down onto an underlying fileserver. Right now he panics if he sees a dirty page which he should write out--change that to do an I/O back out to the server, and you should be in business. Other thoughts. Once you have that, you need to ponder when things should get sync()'ed out. You probably don't want to wait for the paging system, because he only does it when memory gets low. You also need to ponder what happens if your server task doesn't complete the I/O--there's only so many threads for doing async pageouts. You should consider how to cache the pset, along the lines of what I do for mapped a.out's. Otherwise all the data will be flushed and freed, and you'll have to re-fill the pages from the server if you mmap() it again. I think the kernel assumes the server will do DMA, so be careful if you try handing back I/O's to a filesystem. I used to be a rabid fan of memory-based communication; in fact, I worked on the original project which became the Scalable Coherent Interface standard. I've since had lots of experience with both MIMD and messaging systems, and I guess I've pretty much been converted! :-) Andy From nick@nsis.cl.nec.co.jp Tue Nov 23 21:05:21 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08478; Tue, 23 Nov 93 21:05:20 PST Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26969; Tue, 23 Nov 93 21:06:09 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11406(netkeeper.sj.nec.com ); Tue, 23 Nov 93 21:06:08 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06469(archimedes.inoc.sj.nec.com ); Tue, 23 Nov 93 21:06:06 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id VAA00086; Tue, 23 Nov 1993 21:30:52 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA29406 (8.6.4/IDA-1.5 for ); Tue, 23 Nov 1993 20:46:57 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA14792; Wed, 24 Nov 1993 13:46:44 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA23747; Wed, 24 Nov 1993 13:46:42 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931119.1) id AA05842; Wed, 24 Nov 1993 13:46:41 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA08192; Wed, 24 Nov 93 13:46:40 JST Date: Wed, 24 Nov 93 13:46:40 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311240446.AA08192@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Update Status: OR >So, coherent mmap()'ed access to files does not simplify servers, does >not simplify your kernel, does not scale to networked configurations, >and can easily be detrimental to overall system stability. For these >reasons, I decided to omit the feature. If you want to experiment with Hmm, good reasons to not have the feature. Anyway, I certainly won't be working on this until I have a viable MADO running, so I'll think a bit more. Given the above, something like CORBA might be better, as it's inherently messaging... BTW: How does mach handle disks? I understood that it basically regarded the entire disk as memory. How does it handle disks across a network? From vandys@cisco.com Fri Nov 26 08:31:25 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02545; Fri, 26 Nov 93 08:31:24 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06827; Fri, 26 Nov 93 08:32:26 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29655(netkeeper.sj.nec.com ); Fri, 26 Nov 93 08:32:25 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA10994(archimedes.inoc.sj.nec.com ); Fri, 26 Nov 93 08:32:23 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00075; Fri, 26 Nov 1993 09:06:43 -0800 Received: from localhost by glare.cisco.com with SMTP id AA27857 (5.67a/IDA-1.5 for ); Fri, 26 Nov 1993 08:23:29 -0800 Message-Id: <199311261623.AA27857@glare.cisco.com> To: vsta@cisco.com Subject: Various things Date: Fri, 26 Nov 1993 08:23:29 -0800 From: Andrew Valencia Status: OR I've been cooking up some new stuff for VSTa of late. First, at the urging of one of the newest VSTa sites, I wrote an RS-232 driver, fixed up login, fixed a couple C library bugs, and am running VSTa in a true multi-user configuration for the first time. I have also assembled a much-requested "standalone boot" kit so you can boot up a basic VSTa configuration without having to rebuild the world from scratch. This kit was first assembled when I was shopping for a laptop and wanted to check for compatibility--it all fits on a floppy, so I could just boot off the floppy and verify keyboard/screen/disk. If you want to check it out, it's ftp.cisco.com:vandys/vsta/stand*. The shell used is from bin/testsh; it's not much of an interactive shell, but it's pretty good for messing around with messages, mount points, etc. Finally, I've started work on debugger support. The kernel will provide peek/poke, breakpoints, read/write registers, plus optionally the ability to cause the program to breakpoint on each syscall and each signal. The interface will work for multi-threaded programs, which adds a certain amount of challenge to the coding task. I'm going to bring it up with an adb-like program, and port gdb once it's working. Andy From nick@nsis.cl.nec.co.jp Mon Nov 29 08:11:16 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16097; Mon, 29 Nov 93 08:11:15 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17965; Mon, 29 Nov 93 08:12:33 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09470(netkeeper.sj.nec.com ); Mon, 29 Nov 93 08:12:32 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13281(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 08:12:30 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00064; Mon, 29 Nov 1993 08:45:14 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA07045 (8.6.4/IDA-1.5 for ); Sun, 28 Nov 1993 15:29:08 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA00738; Mon, 29 Nov 1993 08:29:03 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA01266; Mon, 29 Nov 1993 08:29:02 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA08891; Mon, 29 Nov 1993 08:29:01 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA10084; Mon, 29 Nov 93 08:29:01 JST Date: Mon, 29 Nov 93 08:29:01 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311282329.AA10084@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Fri, 26 Nov 1993 08:23:29 -0800 <199311261623.AA27857@glare.cisco.com> Subject: Various things Status: OR >I have also assembled a much-requested "standalone boot" kit so you can >boot up a basic VSTa configuration without having to rebuild the world I guess this still uses DOS to boot? I've done a little work on a VSTa boot floppy. I think I've figured out how to build the boot image (ie. how to lay it out, and how to pass parameters, the basic boot cycle, etc.) This is all pretty simple, we just emulate what boot.exe does. >Finally, I've started work on debugger support. The kernel will provide >peek/poke, breakpoints, read/write registers, plus optionally the ability >to cause the program to breakpoint on each syscall and each signal. The >interface will work for multi-threaded programs, which adds a certain amount >of challenge to the coding task. I'm going to bring it up with an adb-like >program, and port gdb once it's working. Having a debugger will be a big help. One idea I liked a lot in plan9 was the /proc file system. For those who don't know what it is, it's a filesystem containing stuff related to the processes. Use /proc, you can read process memory, set breakpoints, etc. etc. From what I've seen, in plan 9, when a process breaks, it hangs around, rather than dumping core. The debugger then attaches itself to /proc to see what's up. I think /proc would be useful. Once the debuggin hooks are in, it'd be a good project for someone. nick From vandys@cisco.com Mon Nov 29 08:22:24 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16122; Mon, 29 Nov 93 08:22:23 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17997; Mon, 29 Nov 93 08:23:42 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09551(netkeeper.sj.nec.com ); Mon, 29 Nov 93 08:23:41 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13314(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 08:23:39 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00067; Mon, 29 Nov 1993 08:58:19 -0800 Received: from localhost by glare.cisco.com with SMTP id AA05176 (5.67a/IDA-1.5 for ); Mon, 29 Nov 1993 08:15:39 -0800 Message-Id: <199311291615.AA05176@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Various things In-Reply-To: Your message of "Mon, 29 Nov 1993 08:29:01 +0200." <9311282329.AA10084@silk1.nsis.cl.nec.co.jp> Date: Mon, 29 Nov 1993 08:15:38 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >I guess this still uses DOS to boot? I've done a little work on a VSTa >boot floppy. I think I've figured out how to build the boot image (ie. >how to lay it out, and how to pass parameters, the basic boot cycle, >etc.) This is all pretty simple, we just emulate what boot.exe does. Yes, the "standalone" boot floppy still uses DOS. I will cheerfully integrate a true standalone boot into the source tree, although I suspect that a DOS-based boot will continue to be available. >Having a debugger will be a big help. One idea I liked a lot in plan9 >was the /proc file system. For those who don't know what it is, it's a >filesystem containing stuff related to the processes. Use /proc, you >can read process memory, set breakpoints, etc. etc. From what I've >seen, in plan 9, when a process breaks, it hangs around, rather than >dumping core. The debugger then attaches itself to /proc to see what's >up. I think /proc would be useful. Once the debuggin hooks are in, >it'd be a good project for someone. Yes, I like parts of Plan9 as well--especially the avoidance of core files. When you consider exactly how nebulous a filesystem can be in VSTa, it makes even more sense. I've been thinking about /proc, and I think I am starting to get a clue how to do it. Rather than dump all that code into the kernel, I think the kernel should offer a process-status syscall, and a debugger syscall. These are binary interfaces, not messaging, with no insulation from the endianness of the machine or such. The /proc server, then, drives this binary interface in one direction, and serves connections out to the rest of the world in the other direction. He provides a machine-independent interface, handles string massaging, byte swapping, and so forth. I have the machine-independent part of the debugger written. Last night I was reviewing the i386 debug registers and the T-bit. It looks like I should have the kernel part written in another day--then I have to throw together an assembly-oriented debugger so I can exercise it. I can steal the symbol table handling stuff from dbsym.c, which should help. Andy From rob@darkstar.cygnus.com Mon Nov 29 10:00:14 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16399; Mon, 29 Nov 93 10:00:13 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18395; Mon, 29 Nov 93 10:01:32 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29866(netkeeper.sj.nec.com ); Mon, 29 Nov 93 10:01:31 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13691(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 10:01:28 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00113; Mon, 29 Nov 1993 10:34:14 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA20697 (8.6.4/IDA-1.5 for ); Mon, 29 Nov 1993 09:51:33 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA10054; Mon, 29 Nov 93 09:51:30 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA25583; Mon, 29 Nov 93 10:51:29 MST Message-Id: <9311291751.AA25583@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Mon, 29 Nov 1993 10:51:29 MST In-Reply-To: Andrew Valencia "Re: Various things" (Nov 29, 8:15am) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Subject: Re: Various things Cc: vsta@cisco.com Status: OR From: Andrew Valencia Subject: Re: Various things > >Having a debugger will be a big help. One idea I liked a lot in plan9 > >was the /proc file system. For those who don't know what it is, it's a > >filesystem containing stuff related to the processes. Use /proc, you > >can read process memory, set breakpoints, etc. etc. From what I've > > I've been thinking about /proc, and I think I am starting to get a clue > how to do it. Rather than dump all that code into the kernel, I think GDB knows how to talk use a /proc for it's target end. The other thing would be to look at the new gdbserver too. If you get /proc working, I can take a shot at seeing how GDB does under VSTa. Should be a fun project. :-) - rob - From nick@nsis.cl.nec.co.jp Mon Nov 29 15:36:27 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18003; Mon, 29 Nov 93 15:36:25 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19734; Mon, 29 Nov 93 15:37:40 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09262(netkeeper.sj.nec.com ); Mon, 29 Nov 93 15:37:36 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14944(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 15:37:34 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00180; Mon, 29 Nov 1993 15:59:48 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA03116 (8.6.4/IDA-1.5 for ); Mon, 29 Nov 1993 15:16:50 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA02732; Tue, 30 Nov 1993 08:16:45 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA20790; Tue, 30 Nov 1993 08:16:45 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA01157; Tue, 30 Nov 1993 08:16:44 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA25082; Tue, 30 Nov 93 08:16:43 JST Date: Tue, 30 Nov 93 08:16:43 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311292316.AA25082@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: /proc and debuggers Status: OR Rob mentioned that gdb knows about /proc file systems. I have no idea about what format it expects. Rob, could you please send out a bit more info? >I've been thinking about /proc, and I think I am starting to get a clue >how to do it. Rather than dump all that code into the kernel, I think >the kernel should offer a process-status syscall, and a debugger syscall. >These are binary interfaces, not messaging, with no insulation from the >endianness of the machine or such. The /proc server, then, drives this >binary interface in one direction, and serves connections out to the >rest of the world in the other direction. He provides a machine-independent >interface, handles string massaging, byte swapping, and so forth. I wonder whether /proc should be global or per-user? Anyway, I agree with the basic outline above. I guess this could also be used for ps like commands? Coding has started on MADO. I'm going to write an X based library that emulates bitblt calls, and then write many parts of MADO using that (in particular, window redrawing etc). If anyone knows a graphics guru who has time to kill writing wide-line support etc. let me know! From vandys@cisco.com Mon Nov 29 15:40:07 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18017; Mon, 29 Nov 93 15:40:05 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19750; Mon, 29 Nov 93 15:41:22 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09293(netkeeper.sj.nec.com ); Mon, 29 Nov 93 15:41:19 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14948(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 15:41:17 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00187; Mon, 29 Nov 1993 16:07:29 -0800 Received: from localhost by glare.cisco.com with SMTP id AA29279 (5.67a/IDA-1.5 for ); Mon, 29 Nov 1993 15:24:50 -0800 Message-Id: <199311292324.AA29279@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: /proc and debuggers In-Reply-To: Your message of "Tue, 30 Nov 1993 08:16:43 +0200." <9311292316.AA25082@silk1.nsis.cl.nec.co.jp> Date: Mon, 29 Nov 1993 15:24:50 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Rob mentioned that gdb knows about /proc file systems. I have no idea >about what format it expects. Rob, could you please send out a bit >more info? If this /proc is anything like the one from UNIX V.4, it is a real morass of ioctl()'s of all sorts. Plan9's is quite a bit better, although you can tell that I didn't agree with them about the ctl/ and data/ thing, nor do I believe that kernels should understand a.out formats. The /proc server could synthesize such a thing, but at a loss of portability. Andy From rob@darkstar.cygnus.com Mon Nov 29 15:55:50 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18028; Mon, 29 Nov 93 15:55:48 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19896; Mon, 29 Nov 93 15:57:07 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09587(netkeeper.sj.nec.com ); Mon, 29 Nov 93 15:57:06 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14987(archimedes.inoc.sj.nec.com ); Mon, 29 Nov 93 15:57:01 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00194; Mon, 29 Nov 1993 16:23:27 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA03792 (8.6.4/IDA-1.5 for ); Mon, 29 Nov 1993 15:40:47 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA26981; Mon, 29 Nov 93 15:40:45 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA27255; Mon, 29 Nov 93 16:40:44 MST Message-Id: <9311292340.AA27255@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Mon, 29 Nov 1993 16:40:43 MST In-Reply-To: Andrew Valencia "Re: /proc and debuggers" (Nov 29, 3:24pm) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Subject: Re: /proc and debuggers Cc: vsta@cisco.com Status: OR From: Andrew Valencia Subject: Re: /proc and debuggers > >about what format it expects. Rob, could you please send out a bit > >more info? I haven't played with this section of code, (I've been stuck writing embedded support over serial lines :-) I'll see what I can dig up. > a.out formats. The /proc server could synthesize such a thing, but > at a loss of portability. It'd probably be easier to implement ptrace(). For most target environemnts GDB only requires the ability to read/write memory and set/clear breakpoints. - rob - From larz@world.std.com Tue Nov 30 09:29:31 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00391; Tue, 30 Nov 93 09:29:29 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00455; Tue, 30 Nov 93 09:30:49 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21400(netkeeper.sj.nec.com ); Tue, 30 Nov 93 09:30:45 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16315(archimedes.inoc.sj.nec.com ); Tue, 30 Nov 93 09:30:41 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00066; Tue, 30 Nov 1993 09:59:07 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA24186 (8.6.4/IDA-1.5 for ); Tue, 30 Nov 1993 09:04:35 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA02392; Tue, 30 Nov 1993 12:04:30 -0500 Date: Tue, 30 Nov 1993 12:04:30 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199311301704.AA02392@world.std.com> To: vsta@cisco.com Subject: SCSI status Status: OR Hi. Here's a status report on the VSTa SCSI driver followed by the SCSI driver's README file for those interested in how the driver is organized. Status ------ Enough code has been written so that the XPT function xpt_init() can find out what SCSI devices are attached. This involves telling SIM drivers (the Adaptec 154x driver, for now) to initialize, formatting CAM CCB's to initiate INQUIRY operations, and starting and completing I/O for the INQUIRY. As implied above, a minimal SIM level driver for the Adaptec 154x exists (I currently own an Adaptec 1542C, BTW). The driver talks to the adaptor's registers, sets up DMA, handles interrupts, and does various initialization and housekeeping functions. In addition, code has been written to handle VSTa messages (the only message used right now is M_ISR, however), do namer registration, and other server setup functions (lots of this code was copied from wd). Now here's the TODO list for a minimal disk-only SCSI driver: 1) write handlers for all VSTa messages (ie, M_CONNECT, ..., FS_READ, FS_WRITE, ...). Finish the PDRV disk code. 2) clean up error reporting and debug printing code. 3) handle scatter/gather in the SIM 154x driver. 4) partition tables. 5) SIM I/O completion code. Note that the initial SCSI driver will have a number of limitations, including: 1) disk support only. 2) single server - we had talked in the past about having seperate PDRV and XPT/SIM servers. For now, however, everything will run in one process. 3) etc. And now, the README File: Welcome to SCSI/CAM for VSTa. This file contains a short description of the VSTa CAM environment and the list of files associated with the VSTa SCSI/CAM driver. What is CAM? ------------ >From the SCSI FAQ: QUESTION: What is CAM? ANSWER From: ctjones@bnr.ca (Clifton Jones) ==== Common Access Method. It is a proposed ANSI standard to make it easier to program SCSI applications by encapsulating the SCSI functions into a standardized calling convention. In CAM, the disk and tape drivers are called peripheral drivers (PDRV's for short). At the top, PDRV's system level interface similar to that of any other device driver in the operating system (open/close/read/write/ioctl entry points for *nix, for example). PDRV's do their job by sending SCSI commands down to the next CAM layer, called the transport (or XPT) layer. The commands are contained in a data structure called a CCB (CAM Control Block). One of the jobs of the XPT layer is to route requests from the PDRV's above to one of the SCSI Interface Modules (SIM's) below. There may be more than one SIM per system. SIM's contain HBA (or dumb SCSI chip, etc.) specific code. The 154x code is a SIM module, for example. Quick VSTa SCSI/CAM Description ------------------------------- The VSTa SCSI/CAM driver is loosley divided into three parts: code that is relatively generic, code that is specific to VSTa, and hardware specific code. The generic code is simply a library of functions which may be called by, or which may call functions in the VSTa code. The generic functions include open/close/read/write/ioctl PDRV functions, most of the XPT layer, and the "top part" the SIM layer (schedule the next request, start a request, complete a request). The VSTa specific code is responsible for sending and receiving messages, interfacing with the operating system, dispatching to the appropriate CAM code, and various utilities. The hardware specific code is the "bottom" part of the SIM layer, which interfaces to host adaptor hardware. Note that an attempt has been made to package the necessary VSTa interfaces in a different module. This may ease ports of drivers for host adaptors not currently supported by VSTa. Source File Description ----------------------- cam.h - generic CAM definitions camvsta.h - VSTa CAM definitions (constants, macros, etc.) insque.h - C library insque/remque definitions scsi.h - generic SCSI definitions scsivsta.h - VSTa SCSI definitions (some typedef's) camdata.c - configuration data camutil.c - CAM utility functions (format { CDB, CDB } headers, start I/O, etc.) camvsta.c - VSTa CAM utilities (allocate memory, enable_io, enable_isr, page_wire, etc.) insque.c - C library insque/remque pdisk.c - peripheral disk driver pdskvsta.c - VSTa specific peripheral disk driver code (main(), resides here, for now) sim.c - generic CAM SIM code sim154x.c - the Adaptec 154x SIM driver vstautil.c - misc. utility functions (parse a device name, etc.) xpt.c - CAM XPT code From cmaeda@cs.washington.edu Tue Nov 30 14:34:20 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01183; Tue, 30 Nov 93 14:34:19 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01497; Tue, 30 Nov 93 14:35:44 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18541(netkeeper.sj.nec.com ); Tue, 30 Nov 93 14:35:43 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17233(archimedes.inoc.sj.nec.com ); Tue, 30 Nov 93 14:35:40 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00139; Tue, 30 Nov 1993 15:08:33 -0800 From: cmaeda@cs.washington.edu Received: from june.cs.washington.edu by hubbub.cisco.com with SMTP id AA07754 (8.6.4/IDA-1.5 for ); Tue, 30 Nov 1993 14:26:05 -0800 Received: from localhost (localhost [127.0.0.1]) by june.cs.washington.edu (8.6.4/7.1ju+) with SMTP id OAA15889; Tue, 30 Nov 1993 14:26:26 -0800 To: Gavin Thomas Nicol Cc: vsta@cisco.com Subject: Re: Update In-Reply-To: Your message of "Wed, 24 Nov 93 09:32:34 +0200." <9311240032.AA01754@silk1.nsis.cl.nec.co.jp> Date: Tue, 30 Nov 93 14:26:26 -0800 Message-Id: <15886.754698386@june.cs.washington.edu> Status: OR Date: Wed, 24 Nov 93 09:32:34 +0200 To: vsta@cisco.com From: Gavin Thomas Nicol Subject: Update Question: Can we mmap() files/ports into the memory map of a process. The reason I'm asking is that I've been thinking about an Object Oriented File System (basically just a persistant object store), and mmaping seems to be one of the easiest ways to achieve it. Not really. Read "Transaction Processing" by Gray and Reuter. The problem with a mapped file interface to a persistent store is that there is no obvious way to control when pages get fetched from and flushed to disk. From nick@nsis.cl.nec.co.jp Tue Nov 30 15:54:40 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01404; Tue, 30 Nov 93 15:54:38 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01750; Tue, 30 Nov 93 15:56:03 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19622(netkeeper.sj.nec.com ); Tue, 30 Nov 93 15:56:02 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17513(archimedes.inoc.sj.nec.com ); Tue, 30 Nov 93 15:55:59 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00167; Tue, 30 Nov 1993 16:26:53 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA10383 (8.6.4/IDA-1.5 for ); Tue, 30 Nov 1993 15:44:25 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA05825; Wed, 1 Dec 1993 08:44:22 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA09626; Wed, 1 Dec 1993 08:44:21 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA18345; Wed, 1 Dec 1993 08:44:20 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA10588; Wed, 1 Dec 93 08:44:19 JST Date: Wed, 1 Dec 93 08:44:19 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9311302344.AA10588@silk1.nsis.cl.nec.co.jp> To: larz@world.std.com Cc: vsta@cisco.com In-Reply-To: Mike A Larson's message of Tue, 30 Nov 1993 12:04:30 -0500 <199311301704.AA02392@world.std.com> Subject: SCSI status Status: OR Well, it sounds like things are progressing nicely. A couple of points: >Now here's the TODO list for a minimal disk-only SCSI driver: > > 1) write handlers for all VSTa messages (ie, M_CONNECT, ..., > FS_READ, FS_WRITE, ...). Finish the PDRV disk code. I've found that most of the M_* messages can be copied from elsewhere. They tend to be fairly generic in what they do (I could be missing something though). Most of this code in bitblt, and the mouse driver we just slightly modified versions of other code. >Note that the initial SCSI driver will have a number of limitations, >including: > 1) disk support only. > > 2) single server - we had talked in the past about having > seperate PDRV and XPT/SIM servers. For now, however, > everything will run in one process. I guess both of these could be changed easily later? From larz@world.std.com Wed Dec 1 08:53:46 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14443; Wed, 1 Dec 93 08:53:43 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04683; Wed, 1 Dec 93 08:55:10 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA06551(netkeeper.sj.nec.com ); Wed, 1 Dec 93 08:55:08 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA19380(archimedes.inoc.sj.nec.com ); Wed, 1 Dec 93 08:55:06 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00064; Wed, 1 Dec 1993 09:27:29 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA25280 (8.6.4/IDA-1.5 for ); Wed, 1 Dec 1993 06:48:43 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA03674; Wed, 1 Dec 1993 09:48:42 -0500 Date: Wed, 1 Dec 1993 09:48:42 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199312011448.AA03674@world.std.com> To: vsta@cisco.com Subject: Re: SCSI status Status: OR larz>>Note that the initial SCSI driver will have a number of limitations, larz>>including: larz>> 1) disk support only. larz>> larz>> 2) single server - we had talked in the past about having larz>> seperate PDRV and XPT/SIM servers. For now, however, larz>> everything will run in one process. nick>I guess both of these could be changed easily later? Yes, the CAM driver can be split into separate PDRV and XPT/SIM processes later. I think this is one of the nice things about CAM - its division of labor divided between 3 well defined layers. The middle layer, the XPT, is responsible for delivering CCB's from the PDRV's to the SIM's. In theory, the PDRV's and SIM's don't care how the CCB's are delivered. In practice, the following issues will have to be addressed to implement the split: 1) how to get CCB's from the PDRV's to the SIM's (we touched upon this subject in our earlier discussions) 2) asynchronous and I/O completion callbacks 3) what XPT functionality resides in the PDRV's? At the very least, there needs to be function interfaces that reside in the PDRV's that send message requests from the PDRV to the XPT/SIM. 4) data structures that may be shared among processes 5) how to handle multiple XPT/SIM processes (for multiple types of host adaptor cards). I don't think any of the issues are difficult ones, but they will take time to implement. Right now, I'd rather spend my time working on a solid, but somewhat less dynamically configurable, single server solution and leave the multi server solution to another revision of the driver. Mike Larson From vandys@cisco.com Wed Dec 1 15:33:12 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15534; Wed, 1 Dec 93 15:33:10 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05987; Wed, 1 Dec 93 15:34:41 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04678(netkeeper.sj.nec.com ); Wed, 1 Dec 93 15:34:40 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA20994(archimedes.inoc.sj.nec.com ); Wed, 1 Dec 93 15:34:37 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00080; Wed, 1 Dec 1993 16:02:36 -0800 Received: from localhost by glare.cisco.com with SMTP id AA02606 (5.67a/IDA-1.5 for ); Wed, 1 Dec 1993 15:20:14 -0800 Message-Id: <199312012320.AA02606@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: write() In-Reply-To: Your message of "Thu, 02 Dec 1993 08:09:55 +0200." <9312012309.AA24590@silk1.nsis.cl.nec.co.jp> Date: Wed, 01 Dec 1993 15:20:14 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >I've been putting bitblt through some tests, and I keep getting write >errors. In many cases, it doesn't happen, but when I send a lot of >messages one after the other, it appears. For example: in the line >test, I write 56 bytes, followed by 22 bytes. After doing this around >6 times, I get write errors, and they seem to be caused by msg_send(). >(In the above it's not clear, but I use write() for sending messages, >not msg_send()) Of course, your server isn't advertising a type of 'c' any more, is he? What error do you get back? Or do you get short write counts, but not an actual -1 with strerror() set? You can leave a dbg_enter() call in msg_err(), and catch whoever's setting the error. Trace their stack back, and you'll know why (hopefully). BTW, do you know how to trace user stacks from the kernel debugger? All you do is a "tf" to see the user's registers (assuming he's the current process). Then or in 0x80000000 to the current value of EBP (user is at 2 GB in reality, and kernel sees it this way). Then do a "dv 2". The first word is the next EBP up on the stack, the second is the EIP from the call. Iterate, or'ing in 0x8000000 to each EBP and dumping the stack. A poor man's stack backtrace! If you note them, you can jump back into DOS, use debug32, and turn each recorded EIP into a source line number. You can do sort of the same thing to an arbitrary process, but it involves looking up the right pview in his vas, finding the right page in the pset under the pview, and finding the physical page(s) for the stack. Once you know the physical page, you can contruct the appropriate physical address from the EBP value, and do "dp 2" to see it. Using current proc and virtual addresses is, of course, much easier. Or wait until I have adb running. With adoptive process debugging and breakpoints, life should get much easier. Andy From nick@nsis.cl.nec.co.jp Wed Dec 1 15:36:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15549; Wed, 1 Dec 93 15:36:16 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06005; Wed, 1 Dec 93 15:37:43 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04728(netkeeper.sj.nec.com ); Wed, 1 Dec 93 15:37:40 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21010(archimedes.inoc.sj.nec.com ); Wed, 1 Dec 93 15:37:38 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00083; Wed, 1 Dec 1993 16:10:35 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA14386 (8.6.4/IDA-1.5 for ); Wed, 1 Dec 1993 15:28:17 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA22136; Thu, 2 Dec 1993 08:28:14 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA20963; Thu, 2 Dec 1993 08:28:13 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA29796; Thu, 2 Dec 1993 08:28:12 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA24735; Thu, 2 Dec 93 08:28:11 JST Date: Thu, 2 Dec 93 08:28:11 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312012328.AA24735@silk1.nsis.cl.nec.co.jp> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Wed, 01 Dec 1993 15:20:14 -0800 <199312012320.AA02606@glare.cisco.com> Subject: write() Status: OR The server is currently type "X", and the error is -1, not short byte counts. I traced things into libc as far as msg_send(), and added a printf to bitblt to see what messages are coming in. I'll give the stack trace a whirl. Are ther any bugs that were fixed in 1.1 that were fixed that might cause this? From vandys@cisco.com Thu Dec 9 08:00:43 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00230; Thu, 9 Dec 93 08:00:42 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00346; Thu, 9 Dec 93 08:11:56 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA20090(netkeeper.sj.nec.com ); Thu, 9 Dec 93 08:11:55 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA10729(archimedes.inoc.sj.nec.com ); Thu, 9 Dec 93 08:11:53 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00064; Thu, 9 Dec 1993 08:37:04 -0800 Received: from localhost by glare.cisco.com with SMTP id AA29100 (5.67a/IDA-1.5 for ); Thu, 9 Dec 1993 07:56:16 -0800 Message-Id: <199312091556.AA29100@glare.cisco.com> To: vsta@cisco.com Subject: Debugger for VSTa Date: Thu, 09 Dec 1993 07:56:16 -0800 From: Andrew Valencia Status: OR Hello, I have the first phases of process debugging working under VSTa. I can dynamically attach to a process, select when it'll break and talk with the debugger, and examine his memory. If the debugger dies, the child correctly clears himself out of the debugging state, and continues. This weekend, I'll start playing with single stepping and breakpoints. The kernel code for these is written, but not yet exercised. The debug interface is not ptrace()-ish at all. ptrace() is only used to pick a process and attach. Using ptrace(), you indicate a port name; the child (debugged) process connects and communicates using the usual VSTa messaging techniques. Thus, I get to leverage all the existing code for handling race conditions, multiple threads, and dying processes. The debugger, while talking to the child, merely acts as a server receiving messages and sending responses. Andy From nick@nsis.cl.nec.co.jp Thu Dec 9 17:00:44 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03948; Thu, 9 Dec 93 17:00:43 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02417; Thu, 9 Dec 93 17:11:59 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22266(netkeeper.sj.nec.com ); Thu, 9 Dec 93 17:11:58 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13326(archimedes.inoc.sj.nec.com ); Thu, 9 Dec 93 17:11:54 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00181; Thu, 9 Dec 1993 17:40:31 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA00401 (8.6.4/IDA-1.5 for ); Thu, 9 Dec 1993 16:59:39 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA05775; Fri, 10 Dec 1993 09:59:26 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA18823; Fri, 10 Dec 1993 09:59:25 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA02811; Fri, 10 Dec 1993 09:59:24 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA03377; Fri, 10 Dec 93 09:59:22 JST Date: Fri, 10 Dec 93 09:59:22 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312100059.AA03377@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Thu, 09 Dec 1993 07:56:16 -0800 <199312091556.AA29100@glare.cisco.com> Subject: Debugger for VSTa Status: OR > The debug interface is not ptrace()-ish at all. ptrace() is only >used to pick a process and attach. Using ptrace(), you indicate a port >name; the child (debugged) process connects and communicates using the >usual VSTa messaging techniques. Thus, I get to leverage all the existing >code for handling race conditions, multiple threads, and dying processes. >The debugger, while talking to the child, merely acts as a server receiving >messages and sending responses. Hmm. Remote debugging should be dead easy then. When the protocol is pretty well developed, could you please send it out to the list? A debugger will be nice to have. I just spent the last week tracking down a bug caused by writing 2 bytes in the wrong order. The bug showed up only after about 50 other messages were sent/received. A debugger would have been a great help! From vandys@cisco.com Thu Dec 9 18:29:27 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04486; Thu, 9 Dec 93 18:29:26 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02662; Thu, 9 Dec 93 18:40:42 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23501(netkeeper.sj.nec.com ); Thu, 9 Dec 93 18:40:41 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13597(archimedes.inoc.sj.nec.com ); Thu, 9 Dec 93 18:40:39 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id TAA00189; Thu, 9 Dec 1993 19:04:56 -0800 Received: from localhost by glare.cisco.com with SMTP id AA14829 (5.67a/IDA-1.5 for ); Thu, 9 Dec 1993 18:24:11 -0800 Message-Id: <199312100224.AA14829@glare.cisco.com> To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: Debugger for VSTa In-Reply-To: Your message of "Fri, 10 Dec 1993 11:50:58 +1100." <199312100054.AA25299@hsa.hsa.com.au> Date: Thu, 09 Dec 1993 18:24:10 -0800 From: Andrew Valencia Status: OR [Jonathon Tidswell writes:] >As I understood your second paragraph the child(debugged or debuggee) is >actively participating in the debugging. >How does this work in the case of serious stuff ups in intialisation code of >a process that you wish to debug ? >The problem could equally be shown in the case of a single threaded process >that is blocking unexpectedly. Aha, you're the second person to ask, so I'm Cc'ing the list. The child drops into a client loop inside the kernel; he does not voluntarily relinquish control. The loop just sends a request to the debugger, and acts on the response which he gets. The debugger is a classic message handling loop in user mode, but the client/debugee is all kernel code. He can be as hosed as he'd like, you can still examine him. BTW, it looks like the kernel part of ptrace() cost me 2K. It's #ifdef'ed, so it also can be omitted entirely. Andy From vandys@cisco.com Fri Dec 10 19:24:35 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00296; Fri, 10 Dec 93 19:24:34 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06603; Fri, 10 Dec 93 17:19:43 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01717(netkeeper.sj.nec.com ); Fri, 10 Dec 93 17:19:42 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16144(archimedes.inoc.sj.nec.com ); Fri, 10 Dec 93 17:19:40 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00115; Fri, 10 Dec 1993 17:48:59 -0800 Received: from localhost by glare.cisco.com with SMTP id AA08675 (5.67a/IDA-1.5 for ); Fri, 10 Dec 1993 17:08:25 -0800 Message-Id: <199312110108.AA08675@glare.cisco.com> To: vsta@cisco.com Subject: VSTa debugging Date: Fri, 10 Dec 1993 17:08:24 -0800 From: Andrew Valencia Status: OR I have attach, register dump, single-step, and continue working now. I just tried my breakpoint code--the system slows to a crawl, I guess I've gotten something wrong. Probably not clearing the debug registers up before context switches correctly or something. I'll get breakpoints working, add a C stack backtrace, and then make this available for others. Hey, Rob, ready to do your gdb port yet? :-) Andy From rob@darkstar.cygnus.com Fri Dec 10 19:24:22 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00249; Fri, 10 Dec 93 19:24:21 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06693; Fri, 10 Dec 93 17:44:58 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01897(netkeeper.sj.nec.com ); Fri, 10 Dec 93 17:44:57 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16209(archimedes.inoc.sj.nec.com ); Fri, 10 Dec 93 17:44:54 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id SAA00123; Fri, 10 Dec 1993 18:11:02 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA04706 (8.6.4/IDA-1.5 for ); Fri, 10 Dec 1993 17:30:26 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA03653; Fri, 10 Dec 93 17:30:23 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA10955; Fri, 10 Dec 93 18:30:22 MST Message-Id: <9312110130.AA10955@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 10 Dec 1993 18:30:21 MST In-Reply-To: Andrew Valencia "VSTa debugging" (Dec 10, 5:08pm) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , vsta@cisco.com Subject: Re: VSTa debugging Status: OR From: Andrew Valencia Subject: VSTa debugging > Hey, Rob, ready to do your gdb port yet? :-) I was going to give it a shot over the holiday. At the least I hope to figure out if it can be done at this point. Just if you're interested, I grabbed the docs for Linux that explain how /proc works. Look in darkstar.cygnus.com:/pub/linux/LDP/kernel-hackers-guide. - rob - From larz@world.std.com Tue Dec 14 15:28:52 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04123; Tue, 14 Dec 93 15:28:51 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23391; Tue, 14 Dec 93 15:29:54 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA29729(netkeeper.sj.nec.com ); Tue, 14 Dec 93 15:29:53 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23687(archimedes.inoc.sj.nec.com ); Tue, 14 Dec 93 15:29:51 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00099; Tue, 14 Dec 1993 15:57:02 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA25803 (8.6.4/IDA-1.5 for ); Tue, 14 Dec 1993 05:46:23 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA18927; Tue, 14 Dec 1993 08:46:17 -0500 Date: Tue, 14 Dec 1993 08:46:17 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199312141346.AA18927@world.std.com> To: vsta@cisco.com Subject: SCSI status Status: OR Hi, Just a quick update on the SCSI driver status. Right now, the SCSI disk driver is running as the block device server for the filesystem server - Vsta is talking SCSI! There are a few things that need to be done before the driver is released for testing. The biggest addition is that code needs to be written to break up large transfers (I had to change MAX_WIRED from 4 to 16 to boot Vsta on my SCSI disk). There are also a number of small cleanup items to do. I'll keep you updated. Mike Larson larz@world.std.com From vandys@cisco.com Tue Dec 14 16:37:29 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04408; Tue, 14 Dec 93 16:37:28 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23585; Tue, 14 Dec 93 16:38:32 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01079(netkeeper.sj.nec.com ); Tue, 14 Dec 93 16:38:29 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23931(archimedes.inoc.sj.nec.com ); Tue, 14 Dec 93 16:38:26 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00110; Tue, 14 Dec 1993 17:04:10 -0800 Received: from localhost by glare.cisco.com with SMTP id AA28617 (5.67a/IDA-1.5); Tue, 14 Dec 1993 15:34:02 -0800 Message-Id: <199312142334.AA28617@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: SCSI status In-Reply-To: Your message of "Tue, 14 Dec 1993 08:46:17 EST." <199312141346.AA18927@world.std.com> Date: Tue, 14 Dec 1993 15:34:01 -0800 From: Andrew Valencia Status: OR [larz@world.std.com (Mike A Larson) writes:] >Just a quick update on the SCSI driver status. Right now, the SCSI >disk driver is running as the block device server for the filesystem >server - Vsta is talking SCSI! Congratulations! When you're done cleaning up the server and are ready for some other folks to play with it, I'd like to bundle it into 1.3. 1.3 is shaping up to be: - SCSI disk support - RS-232 driver - Process debugging - Some bug fixes in the filesystem and C library Anybody else? :-) Andy From nick@nsis.cl.nec.co.jp Tue Dec 14 16:48:22 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04428; Tue, 14 Dec 93 16:48:21 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23623; Tue, 14 Dec 93 16:49:25 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01286(netkeeper.sj.nec.com ); Tue, 14 Dec 93 16:49:24 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23988(archimedes.inoc.sj.nec.com ); Tue, 14 Dec 93 16:49:21 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00113; Tue, 14 Dec 1993 17:11:35 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA01775 (8.6.4/IDA-1.5 for ); Tue, 14 Dec 1993 16:31:38 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA21292; Wed, 15 Dec 1993 09:31:31 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA20171; Wed, 15 Dec 1993 09:31:30 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931124.1) id AA00497; Wed, 15 Dec 1993 09:31:29 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA00861; Wed, 15 Dec 93 09:31:27 JST Date: Wed, 15 Dec 93 09:31:27 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312150031.AA00861@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: VSTa 1.3 Status: OR Well, one addition I'd like to see if the PIO library, and the beta mouse driver I wrote. I'd like people to test it and knock the bugs out of it. nick From vandys@cisco.com Tue Dec 14 19:39:48 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04784; Tue, 14 Dec 93 19:39:48 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24079; Tue, 14 Dec 93 19:40:52 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03479(netkeeper.sj.nec.com ); Tue, 14 Dec 93 19:40:51 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24307(archimedes.inoc.sj.nec.com ); Tue, 14 Dec 93 19:40:48 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00122; Tue, 14 Dec 1993 20:10:30 -0800 Received: from localhost by glare.cisco.com with SMTP id AA22956 (5.67a/IDA-1.5 for ); Tue, 14 Dec 1993 19:30:42 -0800 Message-Id: <199312150330.AA22956@glare.cisco.com> To: vsta@cisco.com Subject: debugger Date: Tue, 14 Dec 1993 19:30:41 -0800 From: Andrew Valencia Status: OR I have all the debugger features up and running: breakpoints, C stack backtrace, single step, break on anything/event/exit, and memory inspection. I've written a subset adb clone, and it can debug both programs started under it as well as arbitrary processes on the system. I'm testing this by using it to bring up the mouse driver written by Gavin Thomas Nicol. The mouse driver isn't really useful until we get the window manager, but it'll be helpful if various folks try the driver with their mouse, and report back on any problems they see. I'll include this in the 1.3 release as well. Andy From eagle@zk3.dec.com Wed Dec 15 13:50:24 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13355; Wed, 15 Dec 93 13:50:23 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28501; Wed, 15 Dec 93 13:51:32 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA09694(netkeeper.sj.nec.com ); Wed, 15 Dec 93 13:51:31 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26255(archimedes.inoc.sj.nec.com ); Wed, 15 Dec 93 13:51:28 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id OAA00083; Wed, 15 Dec 1993 14:17:54 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by hubbub.cisco.com with SMTP id AA25438 (8.6.4/IDA-1.5 for ); Wed, 15 Dec 1993 13:38:15 -0800 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA19789; Wed, 15 Dec 1993 16:38:14 -0500 Received: by wasted.zk3.dec.com; id AA05745; Wed, 15 Dec 1993 16:33:53 -0500 Date: Wed, 15 Dec 1993 16:33:53 -0500 From: David Eagle USG Message-Id: <9312152133.AA05745@wasted.zk3.dec.com> Apparently-To: vsta@cisco.com Status: OR I was just added to the mailing list yesterday and get the VSTa files by anonymous ftp. I unzipped/untarred them on a UNIX machine and looked over everything. However, I did not see the most important part - the Detailed Design Specification. I also did not see any Programmer's Guide describing the system calls available under VSTa. Where can these documents be ftp'd from? Please don't tell me "VSTa is yet another UNIX clone" and supports all the UNIX system calls (fork, exec, read, write, etc.). I was looking for a completely new operating system - one that did not care about backwards compatibility. Is this not what VSTa is? From vandys@cisco.com Wed Dec 15 17:04:42 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19100; Wed, 15 Dec 93 17:04:41 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29476; Wed, 15 Dec 93 17:05:49 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12503(netkeeper.sj.nec.com ); Wed, 15 Dec 93 17:05:47 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26939(archimedes.inoc.sj.nec.com ); Wed, 15 Dec 93 17:05:45 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00103; Wed, 15 Dec 1993 17:34:29 -0800 Received: from localhost by glare.cisco.com with SMTP id AA15190 (5.67a/IDA-1.5 for ); Wed, 15 Dec 1993 16:54:50 -0800 Message-Id: <199312160054.AA15190@glare.cisco.com> To: vandys@cisco.com Cc: vsta@cisco.com Subject: vsta In-Reply-To: Your message of "Wed, 15 Dec 1993 16:33:53 EST." <9312152133.AA05745@wasted.zk3.dec.com> Date: Wed, 15 Dec 1993 16:54:50 -0800 From: Andrew Valencia Status: OR [David Eagle USG writes:] >.... However, I did not see the most important >part - the Detailed Design Specification. I also did not see any >Programmer's Guide describing the system calls available under VSTa. >... >I was looking for a completely new operating system - one that did >not care about backwards compatibility. Is this not what VSTa is? Yes, and because of this, VSTa is run as an experimental platform. If we decided everything up front, and then coded to our specification, it would be a lot harder to really push the limits. Consider VSTa a prototype, with the hope on my part that much of the prototype code will be a part of the final system. Because of this, there is no design specification. Neither is there a programmer's guide. Yet. Things are settling down quite a bit, so perhaps the time will soon come where I bang out documentation for each part of the system, and each interface to the microkernel. As always, I would also welcome help in creating such things! If you code-read the system, you should find it consistently commented. If something is elusive, please ask. Adding and fixing comments is just as valid an activity as adding/fixing code. Andy From nick@nsis.cl.nec.co.jp Wed Dec 15 16:00:07 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18629; Wed, 15 Dec 93 16:00:06 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA29199; Wed, 15 Dec 93 16:01:15 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11506(netkeeper.sj.nec.com ); Wed, 15 Dec 93 16:01:13 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26666(archimedes.inoc.sj.nec.com ); Wed, 15 Dec 93 16:01:11 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00090; Wed, 15 Dec 1993 16:28:17 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA01474 (8.6.4/IDA-1.5 for ); Wed, 15 Dec 1993 15:48:31 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA13427; Thu, 16 Dec 1993 08:48:22 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA01294; Thu, 16 Dec 1993 08:48:21 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931215.1) id AA25367; Thu, 16 Dec 1993 08:48:20 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA12828; Thu, 16 Dec 93 08:48:19 JST Date: Thu, 16 Dec 93 08:48:19 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312152348.AA12828@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Detailed design spec etc. Status: OR >I was just added to the mailing list yesterday and get the VSTa files >by anonymous ftp. I unzipped/untarred them on a UNIX machine and >looked over everything. Good >However, I did not see the most important >part - the Detailed Design Specification. I also did not see any >Programmer's Guide describing the system calls available under VSTa. >Where can these documents be ftp'd from? Please don't tell me >"VSTa is yet another UNIX clone" and supports all the UNIX system >calls (fork, exec, read, write, etc.). So far the only documentation for VSTa is a paper by Andy, and the source. So you have to "Use the source Luke". A goal of VSTa is to be POSIX compliant, or nearly so. That means that for user programs, it will appear to be close to Unix. The underlying system architecture is completely different however. >I was looking for a completely new operating system - one that did >not care about backwards compatibility. Is this not what VSTa is? This is what VSTa is. Andy's extent based file system is nothing like most Unix file systems. I am writing a windowing system that is nothing like X, or Windows. One day I plan to write a persistent object store, and experiment with a truly object oriented operating system; one that should support distributed computing seamlessly. VSTa is *very* easy to understand. I must admit to being a fan of VSTa. Why? I have ported Linux, BSD386, Minix and Wendin DOS to the NEC hardware. I have messed around with Mach. When I first saw VSTa, I fell in love with the design. I often thought about writing my own OS, and even got most of the specs done. VSTa is similar to the design ideas I had, but so much more as well... From dave@humbug.demon.co.uk Thu Dec 16 09:09:54 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26410; Thu, 16 Dec 93 09:09:53 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02937; Thu, 16 Dec 93 09:11:05 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA22053(netkeeper.sj.nec.com ); Thu, 16 Dec 93 09:11:04 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28419(archimedes.inoc.sj.nec.com ); Thu, 16 Dec 93 09:11:00 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00064; Thu, 16 Dec 1993 09:31:52 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA17065 (8.6.4/IDA-1.5 for ); Thu, 16 Dec 1993 01:50:55 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04498; 16 Dec 93 9:48 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pAFHq-0008fGC; Thu, 16 Dec 93 09:46 GMT Message-Id: From: Dave Hudson Subject: What's under development? To: vsta@cisco.com Date: Thu, 16 Dec 1993 09:46:21 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1081 Status: OR I'm new to VSTa, and I'd like to find out what sort of things are currently under development. I understand that a few developments have been announced on this list - does anyone have archived copies, or can anyone point me at an archive ftp site? I'd really like to know which devices are being worked on, as I've just switched to VSTa for a project at work and I'd like to get as much support for the following as soon as possible: Video cards running in graphics mode Adaptec 1542 SCSI cards Ethernet cards (particularly 3c509 and NE2000) Sound cards (particularly Pro Audio Spectrum 16) If any of these aren't being looked at then it would seem a good place for me to start - I've already have the programming info as I was going to write the whole thing from scratch until I heard about VSTa from the Linux news groups. Has there been any discussion of how to handle devices under SCSI, such as how to keep the target specific code separated from the SCSI card specific code? Many thanks, Dave Hudson dave@humbug.demon.co.uk D.J.Hudson.kid0109@oasis.icl.co.uk From larz@world.std.com Thu Dec 16 09:58:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26795; Thu, 16 Dec 93 09:58:16 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03159; Thu, 16 Dec 93 09:59:29 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12618(netkeeper.sj.nec.com ); Thu, 16 Dec 93 09:59:27 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28656(archimedes.inoc.sj.nec.com ); Thu, 16 Dec 93 09:59:24 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00099; Thu, 16 Dec 1993 10:16:43 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA01198 (8.6.4/IDA-1.5 for ); Thu, 16 Dec 1993 09:37:14 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA02294; Thu, 16 Dec 1993 12:30:10 -0500 Date: Thu, 16 Dec 1993 12:30:10 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199312161730.AA02294@world.std.com> To: vsta@cisco.com Subject: Re: What's under development? Status: OR Dave Hudson writes: > ... > Has there been any discussion of how to handle devices under SCSI, such as > how to keep the target specific code separated from the SCSI card specific > code? > Dave, I'm writing the SCSI driver for VSTa. I'm implementing the driver to the CAM (Common Access Method) specification, so to answer your question, we have had that discussion. Target specific code is handled by a layer called the peripheral driver layer. Each type of device (disk, tape, etc.) is handled by a different peripheral driver. SCSI card specific code is handled by the SIM (SCSI Interface Module) layer. In between the two layers is the XPT (transport) layer, which is responsible for routing requests from the peripheral drivers down to the appropriate SIM. As far as status of the driver goes - a peripheral disk driver is up and running, talking (via XPT calls) to a SIM driver for the Adaptec 1542C (as far as I know, this should also work for the 154xB too). There are still a few things left to code before its ready for prime time, including the breaking up of large I/O transfers into smaller ones and various cleanup items. Hope this helps. Mike Larson larz@world.std.com From nick@nsis.cl.nec.co.jp Thu Dec 16 15:25:09 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA28980; Thu, 16 Dec 93 15:25:08 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA04416; Thu, 16 Dec 93 15:26:22 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21142(netkeeper.sj.nec.com ); Thu, 16 Dec 93 15:26:21 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA29923(archimedes.inoc.sj.nec.com ); Thu, 16 Dec 93 15:26:18 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00115; Thu, 16 Dec 1993 15:51:03 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA17603 (8.6.4/IDA-1.5 for ); Thu, 16 Dec 1993 15:11:35 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA07165; Fri, 17 Dec 1993 08:11:26 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA24476; Fri, 17 Dec 1993 08:11:25 +0900 Received: from silk1.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931215.1) id AA15922; Fri, 17 Dec 1993 08:11:24 +0900 Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.61) id AA27320; Fri, 17 Dec 93 08:11:23 JST Date: Fri, 17 Dec 93 08:11:23 JST From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312162311.AA27320@silk1.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Dave Hudson's message of Thu, 16 Dec 1993 09:46:21 +0000 (GMT) Subject: What's under development? Status: OR Here's the latest list: ------------------------- 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 begun. | Update wd to handle various IDE drives | ???? - Done?? | 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 | 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?) | --------------------------------------------+------------------------------- I'm still looking for someone to work on a VGA port of bitblt. Preferrably, someone who understands how to write wide-line code etc. From vandys@cisco.com Fri Dec 17 09:16:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06616; Fri, 17 Dec 93 09:16:16 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08754; Fri, 17 Dec 93 09:17:34 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02498(netkeeper.sj.nec.com ); Fri, 17 Dec 93 09:17:33 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01782(archimedes.inoc.sj.nec.com ); Fri, 17 Dec 93 09:17:29 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00064; Fri, 17 Dec 1993 09:36:59 -0800 Received: from localhost by glare.cisco.com with SMTP id AA28075 (5.67a/IDA-1.5 for ); Fri, 17 Dec 1993 08:57:38 -0800 Message-Id: <199312171657.AA28075@glare.cisco.com> To: Dave Hudson Cc: vsta@cisco.com Subject: Re: DJGPP and VSTa In-Reply-To: Your message of "Fri, 17 Dec 1993 15:44:38 GMT." Date: Fri, 17 Dec 1993 08:57:37 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >Unless I'm very badly mistaken, VSTa expects a.out format code, but the >latest version of DJGPP has switched to COFF. I wanted to use 111 because >it supports GCC 2.5.X, and I'm running 2.5.7 on Linux because of a number of >reported problems building reliable Linux kernels. I had heard rumors to this effect, sorry to hear them confirmed. :-( We've never had problems building reliable kernels on any release of GCC that I've ever tried--as you've probably seen by now, I try to keep things simple. >Has anyone else reported this sort of problem, or have I missed something? I only heard little rumblings. DJGPP used to be an asset, but between the rockiness of GCC (especially built-in functions, which ones are built-in, and their definition) and now DJGPP rambling all over the place, perhaps the next release should focus on an entirely native build process. The biggest hole which comes to mind is the lack of an RCS port for VSTa. RCS (last I looked) uses some horrendous shell script to do its configuration. I'll have to see what would be involved in getting this to work under VSTa. Andy From tthorn@daimi.aau.dk Fri Dec 17 10:50:03 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06723; Fri, 17 Dec 93 10:50:02 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09050; Fri, 17 Dec 93 10:51:20 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27146(netkeeper.sj.nec.com ); Fri, 17 Dec 93 10:51:19 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02191(archimedes.inoc.sj.nec.com ); Fri, 17 Dec 93 10:51:16 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00070; Fri, 17 Dec 1993 11:18:12 -0800 Received: from avignon.daimi.aau.dk by hubbub.cisco.com with SMTP id AA16660 (8.6.4/IDA-1.5 for ); Fri, 17 Dec 1993 10:38:50 -0800 Received: by avignon.daimi.aau.dk id AA27129 (5.65c8/IDA-1.4.4 for vsta@cisco.com); Fri, 17 Dec 1993 19:38:41 +0100 Date: Fri, 17 Dec 1993 19:38:41 +0100 From: Tommy Thorn Message-Id: <199312171838.AA27129@avignon.daimi.aau.dk> To: vsta@cisco.com Cc: poe@daimi.aau.dk Subject: Re: DJGPP and VSTa Reply-To: Tommy.Thorn@daimi.aau.dk Status: OR Hi all, Just curious: Why was VSTa initially developed in DOS? Wasn't Linux aviable/good enough at the start of development? Anyway we're trying to build VSTa under Linux right now and it runs fairly smooth, except for linking. Has anyone had any success? The closed we got so far is 'ld -nostdlib -Tdata 40000 -Ttext 1020 -N' and a handcrafted perl script to bring things together, but it also fails to run. (We use the standalone package and only tries to build standsh.) Alternatively, why can't I get standsh to run binaries? I've unpacked standalone.tz and all of vsta_fs.tz. I do exactly as stand.README tells me to. I can even see the binary, but when I try: % cd /bin % ls login rc cat ...... cpp roff % run ./date ./date: invalid Error code: -1 waits: no entry % And this is no matter which binary and no matter how I specify the path. Doing: % set PATH /bin % run date date: unknown error Error code: -1 waits: no entry % didn't help much either. What can be wrong? /Tommy Thorn From vandys@cisco.com Fri Dec 17 11:03:09 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06737; Fri, 17 Dec 93 11:03:08 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09080; Fri, 17 Dec 93 11:04:27 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27484(netkeeper.sj.nec.com ); Fri, 17 Dec 93 11:04:26 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02353(archimedes.inoc.sj.nec.com ); Fri, 17 Dec 93 11:04:23 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00073; Fri, 17 Dec 1993 11:29:04 -0800 Received: from localhost by glare.cisco.com with SMTP id AA03669 (5.67a/IDA-1.5 for ); Fri, 17 Dec 1993 10:49:48 -0800 Message-Id: <199312171849.AA03669@glare.cisco.com> To: Tommy.Thorn@daimi.aau.dk Cc: vsta@cisco.com, poe@daimi.aau.dk Subject: Re: DJGPP and VSTa In-Reply-To: Your message of "Fri, 17 Dec 1993 19:38:41 +0100." <199312171838.AA27129@avignon.daimi.aau.dk> Date: Fri, 17 Dec 1993 10:49:47 -0800 From: Andrew Valencia Status: OR [Tommy Thorn writes:] >Just curious: Why was VSTa initially developed in DOS? Wasn't Linux >aviable/good enough at the start of development? At the time I started, no, Linux wasn't good enough. Also, my ultimate plan was to simply use DOS as a bootstrap loader. DOS is simpler, smaller, and more widely available than Linux. It makes a good bootstrap loader. Linux makes a better operating system, no argument about that. >Anyway we're trying to build VSTa under Linux right now and it runs >fairly smooth, except for linking. Has anyone had any success? >The closed we got so far is 'ld -nostdlib -Tdata 40000 -Ttext 1020 -N' >and a handcrafted perl script to bring things together, but >it also fails to run. (We use the standalone package and only tries >to build standsh.) More details on what "fails to run" could help. It sounds like you're trying to place things at the right locations. The a.out header MUST be present at 0x1000, BTW. VSTa reads it because djgpp did not assign reliable values to, ummm, I think it was "etext". From memory, I think it was set to the first byte beyond the end of text in 1.X, and to the start of data in 2.X. So you couldn't reliably tell how big your text was (which VSTa needs to know, when it sets up his kernel mappings), so I figured why not put the a.out header down where it lives anyway, and just get the text size from there? >% cd /bin >% run ./date Try "path /bin", then "run date". standsh doesn't use the "true" execvp(), so even "./program" might not work. Since ls works, I'm assuming you have things mounted in their correct places already. >% set PATH /bin standsh doesn't use the environment server, which is what "set" talks to. If you had started an "rc", he would've inherited this, though. >What can be wrong? standsh is what's wrong! :-( I actually considered throwing it out, but it's still useful when things get very, very sick. Its built-in path command will probably get things working for you. Andy From dave@humbug.demon.co.uk Sun Dec 19 19:50:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22213; Sun, 19 Dec 93 19:50:35 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18495; Sun, 19 Dec 93 19:52:06 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10945(netkeeper.sj.nec.com ); Sun, 19 Dec 93 19:52:03 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05616(archimedes.inoc.sj.nec.com ); Sun, 19 Dec 93 19:51:58 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00070; Sun, 19 Dec 1993 20:05:35 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA09078 (8.6.4/IDA-1.5 for ); Sun, 19 Dec 1993 12:49:28 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10894; 19 Dec 93 20:45 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pBUuL-000J38C; Sun, 19 Dec 93 20:39 GMT Message-Id: From: Dave Hudson Subject: Re: DJGPP and VSTa To: Tommy.Thorn@daimi.aau.dk Date: Sun, 19 Dec 1993 20:39:16 +0000 (GMT) Cc: vsta@cisco.com In-Reply-To: <199312171838.AA27129@avignon.daimi.aau.dk> from "Tommy Thorn" at Dec 17, 93 07:38:41 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1152 Status: OR Tommy Thorn wrote: > > Anyway we're trying to build VSTa under Linux right now and it runs > fairly smooth, except for linking. Has anyone had any success? > The closed we got so far is 'ld -nostdlib -Tdata 40000 -Ttext 1020 -N' > and a handcrafted perl script to bring things together, but > it also fails to run. (We use the standalone package and only tries > to build standsh.) > Aha, I've had a similar problem. The problem seems to be the way that the GNU binutils have been created for Linux. There was a package announced on the 30th November 1993 to allow binaries to be built for DJGPP. You'll find it on "sunsite.unc.edu" in "/pub/Linux/devel/msdos/go32crs.tgz". The only important bits really are the the "go32-ld" and "go32-ar" binaries. There are also instructions on how to build the binutils this way. Using these and a Linux version of GCC 2.5.7, I've just built and tested the VSTA kernel, and I didn't need the extra command line parameters. So far it would seem that all that needs to be done is to modify the makefiles. Hope this helps, Regards, Dave Hudson dave@humbug.demon.co.uk D.J.Hudson.kid0109@oasis.icl.co.uk From tthorn@daimi.aau.dk Sun Dec 19 19:50:36 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22212; Sun, 19 Dec 93 19:50:35 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18494; Sun, 19 Dec 93 19:52:06 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10946(netkeeper.sj.nec.com ); Sun, 19 Dec 93 19:52:03 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05615(archimedes.inoc.sj.nec.com ); Sun, 19 Dec 93 19:51:58 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00067; Sun, 19 Dec 1993 20:05:32 -0800 Received: from avignon.daimi.aau.dk by hubbub.cisco.com with SMTP id AA09401 (8.6.4/IDA-1.5 for ); Sun, 19 Dec 1993 13:11:13 -0800 Received: by avignon.daimi.aau.dk id AA27860 (5.65c8/IDA-1.4.4 for vsta@cisco.com); Sun, 19 Dec 1993 22:10:56 +0100 Date: Sun, 19 Dec 1993 22:10:56 +0100 From: Tommy Thorn Message-Id: <199312192110.AA27860@avignon.daimi.aau.dk> To: Dave Hudson Cc: vsta@cisco.com Subject: Re: DJGPP and VSTa In-Reply-To: References: <199312171838.AA27129@avignon.daimi.aau.dk> Reply-To: Tommy.Thorn@daimi.aau.dk Status: OR I wrote: > Anyway we're trying to build VSTa under Linux right now and it runs > fairly smooth, except for linking. Has anyone had any success? Dave Hudson writes: > Aha, I've had a similar problem. The problem seems to be the way that the > GNU binutils have been created for Linux. There was a package announced on > the 30th November 1993 to allow binaries to be built for DJGPP. You'll find > it on "sunsite.unc.edu" in "/pub/Linux/devel/msdos/go32crs.tgz". The only > important bits really are the the "go32-ld" and "go32-ar" binaries. There > are also instructions on how to build the binutils this way. Using these > and a Linux version of GCC 2.5.7, I've just built and tested the VSTA > kernel, and I didn't need the extra command line parameters. > > So far it would seem that all that needs to be done is to modify the > makefiles. Yes, I found out I could just './configure --target=i386-go32 --host..' for binutils a every thing was fine. Now my binaries works. There's just a couple of places where cpp is used to generate assembler files, using macros like this: #define foo(a,b) a##b: Unfortunatly, with the newer cpp foo(alpha,bravo) results in: alphabravo : ^ Notice the space which never gas don't like. The easy fix: cpp .. blabla.S | sed -e 's/ :/:/' > blabla.s works fine. /Tommy From vandys@cisco.com Sun Dec 19 20:51:45 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22227; Sun, 19 Dec 93 20:51:44 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18628; Sun, 19 Dec 93 20:53:16 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11476(netkeeper.sj.nec.com ); Sun, 19 Dec 93 20:53:14 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05672(archimedes.inoc.sj.nec.com ); Sun, 19 Dec 93 20:53:11 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id VAA00093; Sun, 19 Dec 1993 21:21:51 -0800 Received: from localhost by glare.cisco.com with SMTP id AA18618 (5.67a/IDA-1.5 for ); Sun, 19 Dec 1993 20:42:54 -0800 Message-Id: <199312200442.AA18618@glare.cisco.com> To: pat@wesson.it.com.au (Pat Mackinlay) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: Writing a new filing system... In-Reply-To: Your message of "Sun, 19 Dec 1993 16:55:10 +0800." Date: Sun, 19 Dec 1993 20:38:23 -0800 From: Andrew Valencia Status: OR [pat@wesson.it.com.au (Pat Mackinlay) writes:] >Presuming one of the existing servers is chosen, I'm unsure exactly how >I should handle things like permission/owndership conversion, and also >the multitude of "special" files available under the Minix fs. I'd look at srv/dos for an example of a (very) simple way of doing a filesystem without permissions. VSTa only uses UIDs for indicating *why* you got abilities; a UID does not represent any abilities in itself. It's more of an accounting concept. srv/tmpfs and srv/vstafs show how to do "full" VSTa protection handling. If you map ownership in a Minix filesystem somehow, then you could participate fully as a VSTa filesystem. There's a fairly simple way to do this mapping, I'll write you some prototype code when you're ready to think about it. >Presumably >devices should just be ignored, but what about fifos and sockets? FIFOs are done in the pipe server, and probably shouldn't go anywhere else. Sockets beg the question of networking--a very deep question, but again one which probably shouldn't be embedded in a disk-oriented filesystem. >Should >I just ignore these as well, or is there some way of passing them off to >the relevant (pipe fs) server(s)? Should I bother? I wouldn't bother. :-) So far as I can tell, we're in the current mess with UNIX because there was "the" filesystem, and "everything's a file". So we started loading all sorts of non-filesystem stuff into the filesystem. Even as we were doing so, the joys of multiple filesystem types became realized. The result is a mishmash, duplicated features, and interesting side effects. For instance, you can't do named pipes in /tmp on a Sun box. Usually. On a related note, I'm starting to ponder how to do file locking. I'm pretty sure it calls for its own server, but I can clearly see how locking needs to be associated with some unique file. But the operating system doesn't even *know* about files, so how do we talk about unique ones? Do unrelated servers have to trust each other? Is there some underlying concept which unifies this? I'm pretty sure I don't want servers getting cluttered with file locking. I've seen what it does in UNIX, and I'm very interested in not repeating it. I'm pretty sure I can do it with smoke and mirrors in the C library. Once I figure it out. >Obviously, I really have no idea what I'm doing here , but I'm >doing this mainly as an exercise to find out how it should be done. Any >advice anyone could give me would be much appreciated. Thanks in advance. It should make a neat project! I'd recommend forgetting all the protection stuff, get the basic filesystem talking first. After that you can fiddle with protection, perhaps teach srv/mach/wd about the Minix partition types, maybe even move some of that out to lib/ so the upcoming SCSI disk support can share it. Regards, Andy From dave@humbug.demon.co.uk Sun Dec 19 23:50:33 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22338; Sun, 19 Dec 93 23:50:33 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19053; Sun, 19 Dec 93 23:52:06 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA13032(netkeeper.sj.nec.com ); Sun, 19 Dec 93 23:52:04 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05874(archimedes.inoc.sj.nec.com ); Sun, 19 Dec 93 23:52:01 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id AAA00107; Mon, 20 Dec 1993 00:21:27 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA17398 (8.6.4/IDA-1.5 for ); Sun, 19 Dec 1993 23:42:38 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa06003; 20 Dec 93 7:35 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pBehF-000J37C; Mon, 20 Dec 93 07:06 GMT Message-Id: From: Dave Hudson Subject: Re: DJGPP and VSTa To: Tommy.Thorn@daimi.aau.dk Date: Mon, 20 Dec 1993 07:06:25 +0000 (GMT) Cc: vsta@cisco.com In-Reply-To: <199312192110.AA27860@avignon.daimi.aau.dk> from "Tommy Thorn" at Dec 19, 93 10:10:56 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 496 Status: OR Tommy Thorn wrote: > > I wrote: > > > Anyway we're trying to build VSTa under Linux right now and it runs > > fairly smooth, except for linking. Has anyone had any success? > > which never gas don't like. The easy fix: > > cpp .. blabla.S | sed -e 's/ :/:/' > blabla.s > > works fine. > > /Tommy > Yes, my solution to this problem was to change something like: foo##bar: into foo##bar##: This seems to keep gas happy - I guess GCC must have changed at some time. Regards, Dave From pat@wesson.it.com.au Mon Dec 20 10:51:12 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23238; Mon, 20 Dec 93 10:51:11 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21023; Mon, 20 Dec 93 10:52:46 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA13338(netkeeper.sj.nec.com ); Mon, 20 Dec 93 10:52:44 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06978(archimedes.inoc.sj.nec.com ); Mon, 20 Dec 93 10:52:42 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00225; Mon, 20 Dec 1993 11:20:29 -0800 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA08657 (8.6.4/IDA-1.5 for ); Mon, 20 Dec 1993 10:41:44 -0800 Received: from wesson.it.com.au by joyce.cs.su.OZ.AU (mail from pat for vsta@cisco.com) with MHSnet; Tue, 21 Dec 1993 05:41:42 +1100 Received: from wesson by garion.it.com.au with smtp (Smail3.1.28.1 #3) id m0pBpXP-00016R5; Tue, 21 Dec 93 02:40 WST Message-Id: From: pat@wesson.it.com.au (Pat Mackinlay) Subject: Filing system again... To: vsta@cisco.com (VSTa Mailing List) Date: Tue, 21 Dec 1993 02:40:29 +0800 (WST) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1653 Status: OR I've had a few replies about my intended implementation of a Minix filing system server for VSTa. I should probably just clear up here that I don't intend in any way for this to become a "real" filing system. As far as I can see, Andy's vstafs is going to be far better suited to general VSTa work, and I don't really intend to spend a lot of time performance-tuning this server. The main reasons for doing it, as I said before, were to learn how it's done, and because I have ready references in the Linux source and the Minix book. One other reason to do it is that it will allow me to transfer data between Linux and VSTa with ease, without having to munge names as with the FAT based filing systems. So, essentially, the focus is on compatibility rather than performance (although I'll try and make the performance adequate). Ok, I now have another important implementation question. Where should the disk caching/buffering be done? From a novice's standpoint, it would seem logical to have a "cache server" sitting between the physical disk servers and the filing systems, but I suspect that introducing another context switch on I/O would not be a very smart idea. So, that leaves the filing system servers or the disk device servers. Which is it to be? I haven't looked closely enough to be sure yet, but I suspect that currently the filing systems all maintain their own buffering information. Is this correct? Is this the right way to go? Am I way off track? Thanks for the replies people, it's comforting to know that there are plenty of people out there who know more than I do about this . -- pat -- empty space is wasted space. From dpezely@bvu-lads.loral.com Mon Dec 20 10:27:00 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23197; Mon, 20 Dec 93 10:26:59 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20948; Mon, 20 Dec 93 10:28:35 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA12939(netkeeper.sj.nec.com ); Mon, 20 Dec 93 10:28:33 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06864(archimedes.inoc.sj.nec.com ); Mon, 20 Dec 93 10:28:29 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00214; Mon, 20 Dec 1993 10:54:11 -0800 Received: from sparky.bvu-lads.loral.com by hubbub.cisco.com with SMTP id AA07145 (8.6.4/IDA-1.5 for ); Mon, 20 Dec 1993 10:15:25 -0800 Received: by sparky.bvu-lads.loral.com (5.65a/BVU-4.0) id AA23212; Mon, 20 Dec 93 10:05:58 -0800 Message-Id: <9312201805.AA23212@sparky.bvu-lads.loral.com> To: pat@wesson.it.com.au (Pat Mackinlay) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: Writing a new filing system... In-Reply-To: Your message of "Sun, 19 Dec 93 16:55:10 +0800." Date: Mon, 20 Dec 93 10:05:56 -0800 From: Daniel Pezely Status: OR >Anyhow, not knowing much about filing systems, I'm looking for a bit of >advice on where to start. pick up: Leffler, McKusick, Karels, Quarterman, _The Design and Implementation of the 4.3BSD UNIX Operating System_, 1989, Addison Wesley Publishing Co [06196] ISBN 0-201-06196-1 aka `The' bsd book aka the berkeley daemon book (from picture on the cover, a la the compiler `dragon' book) poke your favoitie Archie site for tech papers on the fast file system. I can't reach archie from my site today for some reason, but i'm pretty sure searching on the key ``fast-fil'' will locate some papers. scour sunsite.unc.edu for os papers from Sun. their file system is similar (enough) to the bsd fast file system, likewise for NFS docs (rfc?). i'll feed you some tech papers when i get a chance, but it may be a while... -pez From tor@tss.no Mon Dec 20 04:15:09 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22816; Mon, 20 Dec 93 04:15:08 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19841; Mon, 20 Dec 93 04:16:41 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA14981(netkeeper.sj.nec.com ); Mon, 20 Dec 93 04:16:39 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA06050(archimedes.inoc.sj.nec.com ); Mon, 20 Dec 93 04:16:36 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA00196; Mon, 20 Dec 1993 04:36:29 -0800 Received: from benoni.Uit.No by hubbub.cisco.com with SMTP id AA23212 (8.6.4/IDA-1.5 for ); Mon, 20 Dec 1993 03:57:37 -0800 Received: from benoni by ppenoni.uit.no with SMTP (PP) id <09225-0@ppenoni.uit.no>; Mon, 20 Dec 1993 12:57:28 +0000 Received: from unas.tss.no by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) id AAbenoni09221; Mon, 20 Dec 1993 12:57:26 +0100 Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA22631; Mon, 20 Dec 93 12:48:19 +0100 Message-Id: <9312201148.AA22631@unas.tss.no> From: tor@tss.no (Tor Arntsen) Date: Mon, 20 Dec 1993 12:48:17 +0100 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: vsta@cisco.com Subject: CPP (Was: Re: DJGPP and VSTa) Status: OR On Dec 19, 10:10pm, Tommy Thorn wrote: [...] >#define foo(a,b) a##b: > >Unfortunatly, with the newer cpp foo(alpha,bravo) results in: > >alphabravo : > ^ Notice the space [...] cpp -traditional will fix this for GNU cpp I believe. Tor (tor@tss.no) From vandys@cisco.com Mon Dec 20 11:19:33 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23556; Mon, 20 Dec 93 11:19:32 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21128; Mon, 20 Dec 93 11:21:08 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA13799(netkeeper.sj.nec.com ); Mon, 20 Dec 93 11:21:06 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07121(archimedes.inoc.sj.nec.com ); Mon, 20 Dec 93 11:21:02 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00229; Mon, 20 Dec 1993 11:45:36 -0800 Received: from localhost by glare.cisco.com with SMTP id AA15936 (5.67a/IDA-1.5 for ); Mon, 20 Dec 1993 11:06:50 -0800 Message-Id: <199312201906.AA15936@glare.cisco.com> To: pat@wesson.it.com.au (Pat Mackinlay) Cc: vsta@cisco.com Subject: Re: Filing system again... In-Reply-To: Your message of "Tue, 21 Dec 1993 02:40:29 +0800." Date: Mon, 20 Dec 1993 11:06:49 -0800 From: Andrew Valencia Status: OR [pat@wesson.it.com.au (Pat Mackinlay) writes:] >Ok, I now have another important implementation question. Where should the >disk caching/buffering be done? In the server. More in a second. >From a novice's standpoint, it would seem >logical to have a "cache server" sitting between the physical disk servers >and the filing systems You assume that there is a caching algorithm which works for all filesystems. In fact, once you start thinking about caching on a per-filesystem basis, it quickly becomes apparently that there are great advantages to doing your cache design on a per-filesystem basis. Both srv/tmpfs and srv/vstafs have unique cache handling because of this. For a fairly generic filesystem, take the buffer handling from the DOS filesystem. I have a patch for it, though, which will follow shortly. Andy From pat@wesson.it.com.au Sun Dec 19 20:11:42 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA22221; Sun, 19 Dec 93 20:11:42 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18544; Sun, 19 Dec 93 20:13:14 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11159(netkeeper.sj.nec.com ); Sun, 19 Dec 93 20:13:12 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05632(archimedes.inoc.sj.nec.com ); Sun, 19 Dec 93 20:13:05 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00086; Sun, 19 Dec 1993 20:30:03 -0800 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA28174 (8.6.4/IDA-1.5 for ); Sun, 19 Dec 1993 00:58:32 -0800 Received: from wesson.it.com.au by joyce.cs.su.OZ.AU (mail from pat for vsta@cisco.com) with MHSnet; Sun, 19 Dec 1993 19:58:31 +1100 Received: from wesson by garion.it.com.au with smtp (Smail3.1.28.1 #3) id m0pBJxr-00016c5; Sun, 19 Dec 93 16:58 WST Message-Id: From: pat@wesson.it.com.au (Pat Mackinlay) Subject: Writing a new filing system... To: vsta@cisco.com (VSTa Mailing List) Date: Sun, 19 Dec 1993 16:55:10 +0800 (WST) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1328 Status: OR I'm at the first stages of thinking about writing a new filing system server, mainly so I learn how it's done. I've decided to pick on the Minix fs, mainly because I have good documentation in Tanenbaum's Minix book, and another reasonable implementation in Linux's version. Anyhow, not knowing much about filing systems, I'm looking for a bit of advice on where to start. I'd expect that copying one of the existing servers would get the basics up pretty quickly, but which one would be best to start with? I'm not planning a particularly high-performance implementation, just something that will let me read and write to existing Minix filing systems. Presuming one of the existing servers is chosen, I'm unsure exactly how I should handle things like permission/owndership conversion, and also the multitude of "special" files available under the Minix fs. Presumably devices should just be ignored, but what about fifos and sockets? Should I just ignore these as well, or is there some way of passing them off to the relevant (pipe fs) server(s)? Should I bother? Obviously, I really have no idea what I'm doing here , but I'm doing this mainly as an exercise to find out how it should be done. Any advice anyone could give me would be much appreciated. Thanks in advance. -- pat -- empty space is wasted space. From nick@nsis.cl.nec.co.jp Mon Dec 20 15:52:17 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09104; Mon, 20 Dec 93 15:52:16 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21997; Mon, 20 Dec 93 15:53:53 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA17321(netkeeper.sj.nec.com ); Mon, 20 Dec 93 15:53:51 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA07934(archimedes.inoc.sj.nec.com ); Mon, 20 Dec 93 15:53:48 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00258; Mon, 20 Dec 1993 16:24:08 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA01826 (8.6.4/IDA-1.5 for ); Mon, 20 Dec 1993 15:45:20 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA16687; Tue, 21 Dec 1993 08:44:34 +0900 Received: from nsis.cl.nec.co.jp (nsis) by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA07640; Tue, 21 Dec 1993 08:44:33 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931217.1) id AA16103; Tue, 21 Dec 1993 08:44:32 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00460; Tue, 21 Dec 93 08:44:18 +0900 Date: Tue, 21 Dec 93 08:44:18 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312202344.AA00460@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Linux based build etc. Status: OR It's very good to see people with a working build under Linux. One other thing that might be worth looking at is creating a VSTa image that could be written to floppy. I did do some work on it, and basically all you have to do is follow what boot.exe does, but instead of writing to memory, write to disk. This will build up a memory image. Of course, a boot block, and initialization code need to be tacked onto the front of the image, but they're generally trivial. nick From tthorn@daimi.aau.dk Tue Dec 21 04:43:14 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12806; Tue, 21 Dec 93 04:43:13 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24117; Tue, 21 Dec 93 04:44:53 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25001(netkeeper.sj.nec.com ); Tue, 21 Dec 93 04:44:50 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09081(archimedes.inoc.sj.nec.com ); Tue, 21 Dec 93 04:44:46 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id FAA00371; Tue, 21 Dec 1993 05:14:36 -0800 Received: from avignon.daimi.aau.dk by hubbub.cisco.com with SMTP id AA25401 (8.6.4/IDA-1.5 for ); Tue, 21 Dec 1993 04:35:54 -0800 Received: by avignon.daimi.aau.dk id AA14445 (5.65c8/IDA-1.4.4 for vsta@cisco.com); Tue, 21 Dec 1993 13:34:52 +0100 Date: Tue, 21 Dec 1993 13:34:52 +0100 From: Tommy Thorn Message-Id: <199312211234.AA14445@avignon.daimi.aau.dk> To: vsta@cisco.com Subject: Re: Filing system again... In-Reply-To: <199312201906.AA15936@glare.cisco.com> References: <199312201906.AA15936@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Status: OR Andrew Valencia writes: > [pat@wesson.it.com.au (Pat Mackinlay) writes:] > > >Ok, I now have another important implementation question. Where should the > >disk caching/buffering be done? > > In the server. More in a second. > > >From a novice's standpoint, it would seem > >logical to have a "cache server" sitting between the physical disk servers > >and the filing systems > > You assume that there is a caching algorithm which works for all filesystems. > In fact, once you start thinking about caching on a per-filesystem basis, > it quickly becomes apparently that there are great advantages to doing your > cache design on a per-filesystem basis. Both srv/tmpfs and srv/vstafs have > unique cache handling because of this. Doesn't prevent a dynamic buffer cache? A big loss in my view. > Andy From vandys@cisco.com Tue Dec 21 08:55:58 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16142; Tue, 21 Dec 93 08:55:57 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24777; Tue, 21 Dec 93 08:57:38 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27971(netkeeper.sj.nec.com ); Tue, 21 Dec 93 08:57:35 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA09488(archimedes.inoc.sj.nec.com ); Tue, 21 Dec 93 08:57:33 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00382; Tue, 21 Dec 1993 09:26:03 -0800 Received: from localhost by glare.cisco.com with SMTP id AA11752 (5.67a/IDA-1.5 for ); Tue, 21 Dec 1993 08:47:23 -0800 Message-Id: <199312211647.AA11752@glare.cisco.com> To: Tommy.Thorn@daimi.aau.dk Cc: vsta@cisco.com Subject: Re: Filing system again... In-Reply-To: Your message of "Tue, 21 Dec 1993 13:34:52 +0100." <199312211234.AA14445@avignon.daimi.aau.dk> Date: Tue, 21 Dec 1993 08:47:23 -0800 From: Andrew Valencia Status: OR [Tommy Thorn writes:] > > ... Both srv/tmpfs and srv/vstafs have > > unique cache handling because of this. >Doesn't prevent a dynamic buffer cache? A big loss in my view. If I'm parsing this correctly, you're saying "But how do we do a dynamic buffer cache?" I'm open to suggestions. I will point out that the size of the cache within each filesystem is much bigger than I would have made it in a traditional kernel. Since the buffers are in virtual memory, it will in essence be grown or shrunk in response to the overall system memory availability. It gets this feature without *any* server code complication at all. Arguably, the reason you limit the size of a virtual memory-based cache is simply to bound the consumption of swap space. Other thoughts are welcome; the buffer cache story is by no means complete! Andy From vandys@cisco.com Thu Dec 23 17:24:55 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11034; Thu, 23 Dec 93 17:24:54 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07781; Thu, 23 Dec 93 17:26:12 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15057(netkeeper.sj.nec.com ); Thu, 23 Dec 93 17:26:45 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01477(archimedes.inoc.sj.nec.com ); Thu, 23 Dec 93 17:26:41 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA00064; Thu, 23 Dec 1993 17:55:35 -0800 Received: from localhost by glare.cisco.com with SMTP id AA04598 (5.67a/IDA-1.5 for ); Thu, 23 Dec 1993 17:17:30 -0800 Message-Id: <199312240117.AA04598@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: SCSI Date: Thu, 23 Dec 1993 17:17:30 -0800 From: Andrew Valencia Status: OR [Mike gave me an Alpha copy of his SCSI work] It's up! It doesn't appear to be splitting I/O into 64K chunks; I'm getting I/O failures instead. I bet your FAT table isn't 126976 bytes, is it? :-) Well, my 260 meg DOS partition isn't named "FATBOY" for nothing! We need to fix that up eventually, but I'm going to change the DOS filesystem for now. All he does once he's running is sector I/O, so it seems silly to have him doing this one humongous I/O up front. Once he's running the only way he'll generate an I/O this big is if a whole bunch of your FAT was modified all at once. Not too likely. This is great! You've enhanced VSTa in a way which will be appreciated for a long time to come. Thanks for the outstanding Christmas present. Regards, Andy From larz@world.std.com Thu Dec 23 18:54:40 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11209; Thu, 23 Dec 93 18:54:39 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07988; Thu, 23 Dec 93 18:55:57 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA15930(netkeeper.sj.nec.com ); Thu, 23 Dec 93 18:56:30 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01587(archimedes.inoc.sj.nec.com ); Thu, 23 Dec 93 18:56:27 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id TAA00076; Thu, 23 Dec 1993 19:26:05 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA26494 (8.6.4/IDA-1.5 for ); Thu, 23 Dec 1993 18:48:00 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA29044; Thu, 23 Dec 1993 21:47:57 -0500 Date: Thu, 23 Dec 1993 21:47:57 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199312240247.AA29044@world.std.com> To: vsta@cisco.com Subject: Re: SCSI Status: OR Andrew Valencia writes: > It's up! Great! Its nice to know that the driver is up and running on another system and I haven't coded anything that's grossly dependent on my particular hardware setup. > It doesn't appear to be splitting I/O into 64K chunks; I'm getting > I/O failures instead. I bet your FAT table isn't 126976 bytes, is it? :-) > Well, my 260 meg DOS partition isn't named "FATBOY" for nothing! The driver should be splitting I/O up into 4K chunks (cam_maxio). Is there a 64K boundry problem on PC's that I'm not aware of? > We need to fix that up eventually, but I'm going to change the DOS > filesystem for now. All he does once he's running is sector I/O, so > it seems silly to have him doing this one humongous I/O up front. Once > he's running the only way he'll generate an I/O this big is if a whole > bunch of your FAT was modified all at once. Not too likely. Your right, but the driver should be able to handle large disk I/O requests without a problem (tape I/O is another issue). Mike Larson From nick@nsis.cl.nec.co.jp Thu Dec 23 19:30:45 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11230; Thu, 23 Dec 93 19:30:44 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08075; Thu, 23 Dec 93 19:32:02 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16190(netkeeper.sj.nec.com ); Thu, 23 Dec 93 19:32:35 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01643(archimedes.inoc.sj.nec.com ); Thu, 23 Dec 93 19:32:32 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00080; Thu, 23 Dec 1993 20:02:14 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA26998 (8.6.4/IDA-1.5 for ); Thu, 23 Dec 1993 19:24:06 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA11047; Fri, 24 Dec 1993 12:24:02 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA23284; Fri, 24 Dec 1993 12:24:01 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931217.1) id AA27290; Fri, 24 Dec 1993 12:24:00 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA01196; Fri, 24 Dec 93 12:23:45 +0900 Date: Fri, 24 Dec 93 12:23:45 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312240323.AA01196@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: A few things Status: OR Well, some good news. Dave Hudson has taken over the task of creating an IBM version of bitblt, and on finishing off the uncompleted areas. This gives me more time to work on MADO. BTW. The "look" of MADO windows will be similar to fvwm. For myself, I have a few questions: 1) In VSTa, is it possible for a server to handle it's own page faults, or do they all go to swap (via the well known port ID)? 2) How is a process marked memory locked? 3) Given that CONS is a special port number, and CONS is mounted on /dev/cons, is unmounting /dev/cons, and then mouting a new /dev/cons over top sufficient to redirect messages? My guess is that it is not because CONS is a well known port. Is there a clean way to overcome this? From rob@darkstar.cygnus.com Fri Dec 24 08:02:42 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17517; Fri, 24 Dec 93 08:02:40 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10198; Fri, 24 Dec 93 08:03:58 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21273(netkeeper.sj.nec.com ); Fri, 24 Dec 93 08:04:34 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02149(archimedes.inoc.sj.nec.com ); Fri, 24 Dec 93 08:04:32 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00197; Fri, 24 Dec 1993 08:34:02 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA08347 (8.6.4/IDA-1.5 for ); Fri, 24 Dec 1993 07:56:00 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA29604; Fri, 24 Dec 93 07:55:58 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA18035; Fri, 24 Dec 93 08:55:57 MST Message-Id: <9312241555.AA18035@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 24 Dec 1993 08:55:56 MST Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: vsta@cisco.com Subject: Linker script for GNU cross tools Status: OR Here's a linker script that can be used with either a stock FSF i386-aout tool chain or djgpp. Save this script as "vsta.ld" and when you invoke gcc, use -Tvsta.ld. You can use it from just ld, but you'll need a complete path. I hope to crank out a whole tool chain for vsta that'll run on sun4 and Linux. (and more). This script sets up the entry point, and the memory map. (etext is always in the right place :-) It also sets up G++ tables for when I get that up. Hacker hints, build a "i386-aout" tool chain from the FSF and install it. in /usr/local/i386-aout/lib put vsta.ld and copy the vsta crt0.o there. (named crt0-vsta.o) replace the existing libc.a (if you built one) with the libc.a from vsta. Then you can do all your compiles as "i386-aout-gcc -Tvsta.ld" and it all works. - rob - --------------------------------------------------------------- STARTUP(crt0-vsta.o) ENTRY(start) OUTPUT_FORMAT(a.out-i386) OUTPUT_ARCH(i386) SEARCH_DIR(.) __DYNAMIC = 0; MEMORY { textram : ORIGIN = 0x1020, LENGTH = 2M dataram : ORIGIN = 0x400000, LENGTH = 2M } /* * stick everything in ram (of course) */ SECTIONS { .text : { CREATE_OBJECT_SYMBOLS *(.text) etext = .; __CTOR_LIST__ = .; LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) __CTOR_END__ = .; __DTOR_LIST__ = .; LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) __DTOR_END__ = .; *(.lit) *(.shdata) } > textram .shbss SIZEOF(.text) + ADDR(.text) : { *(.shbss) } .talias : { } > textram .data : { *(.data) CONSTRUCTORS _edata = .; } > dataram .bss SIZEOF(.data) + ADDR(.data) : { __bss_start = ALIGN(0x8); *(.bss) *(COMMON) end = ALIGN(0x8); _end = ALIGN(0x8); } .stab . (NOLOAD) : { [ .stab ] } .stabstr . (NOLOAD) : { [ .stabstr ] } } From nick@nsis.cl.nec.co.jp Mon Dec 27 15:08:43 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07874; Mon, 27 Dec 93 15:08:42 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23017; Mon, 27 Dec 93 15:09:57 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26664(netkeeper.sj.nec.com ); Mon, 27 Dec 93 15:10:54 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04894(archimedes.inoc.sj.nec.com ); Mon, 27 Dec 93 15:10:52 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00081; Mon, 27 Dec 1993 15:39:05 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA14237 (8.6.4/IDA-1.5 for ); Sun, 26 Dec 1993 15:28:54 -0800 Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA17743; Mon, 27 Dec 1993 08:28:51 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA03559; Mon, 27 Dec 1993 08:28:50 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-931217.1) id AA27085; Mon, 27 Dec 1993 08:28:48 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00170; Mon, 27 Dec 93 08:28:33 +0900 Date: Mon, 27 Dec 93 08:28:33 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9312262328.AA00170@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Well knwon ports Status: OR Over the weekend I was thinking about well known ports. It seems to me that CONS and KBD are no longer needed (yes, I am familiar with the startup race condition in VSTa). Does anyone have any comments about these? If there is agreement, I'd like to ask that CONS be registered as /dev/console and KBD registered as /dev/keyboard, and that startup of user programs would include opening these files. (I know this will conplicate things a little, and that it'll require some parts of libc to be rewritten, but for orthagonality, and for MADO, it would make things simpler). From vandys@cisco.com Mon Dec 27 15:26:54 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07908; Mon, 27 Dec 93 15:26:48 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23065; Mon, 27 Dec 93 15:27:50 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26809(netkeeper.sj.nec.com ); Mon, 27 Dec 93 15:28:46 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04929(archimedes.inoc.sj.nec.com ); Mon, 27 Dec 93 15:28:44 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00116; Mon, 27 Dec 1993 15:59:25 -0800 Received: from localhost by glare.cisco.com with SMTP id AA14538 (5.67a/IDA-1.5 for ); Mon, 27 Dec 1993 15:22:05 -0800 Message-Id: <199312272322.AA14538@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Well knwon ports In-Reply-To: Your message of "Mon, 27 Dec 1993 08:28:33 +0900." <9312262328.AA00170@europa.nsis.cl.nec.co.jp> Date: Mon, 27 Dec 1993 15:22:05 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Over the weekend I was thinking about well known ports. It seems to me >that CONS and KBD are no longer needed (yes, I am familiar with the >startup race condition in VSTa). cons and kbd are only well-known for purposes of providing a defined place to complain into during bootup. We could get rid of them, but it isn't really at the heart of what you're after, I think. >Does anyone have any comments about these? If there is agreement, I'd >like to ask that CONS be registered as /dev/console and KBD registered >as /dev/keyboard, and that startup of user programs would include >opening these files. (I know this will conplicate things a little, and >that it'll require some parts of libc to be rewritten, but for >orthagonality, and for MADO, it would make things simpler). User programs inherit their stdin/stdout/stderr from their invoking program--usually, login. In 1.2, because I wrote the RS-232 driver, I enhanced login to take an optional argument which is the device to open for input and output (actually, if one arg, it is both input and output, if two, then the first is input and the second output). No user program should ever need to manually open paths for his stdin/out/err. If he did, /dev/console and /dev/keyboard would be the Wrong Thing, since you could well be running on a telnet connection or serial port. You'd either get a permission error, or else your program would start talking to some unexpecting person! The right thing for a windowing system would probably be to redirect stdin/out/err into the windowing server, then start the shell. Optionally, you could also insert a /dev/tty entry into the mount table and accept further open()'s of this path. This is "optional", because most programs use their inherited stdin/out/err, or else they close it and open it to, say, a disk file. I'd like to vote that cons/kbd remain well known addresses for now, because they allow simple, dependable debugging of boot servers. When I'm debugging boot server, I *like* things simple and dependable. I would also endorse the plan that these addresses be used for nothing else, ever. In fact, with the exception of their being the default stdin/out/err in login, they are not used outside of boot servers (to the best of my recollection). I'm unclear why MADO would use namer registry? There can be multiple windowing systems; registering one as /dev/console would be visible system-wide, which doesn't appear desirable. In Plan9's 8.5, the windowing system redirects I/O, and mounts objects into the filesystem namespace. This is visible only to the process and its descendents, which is generally what a windowing system desires. Andy From rob@darkstar.cygnus.com Mon Dec 27 15:15:41 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07880; Mon, 27 Dec 93 15:15:40 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23039; Mon, 27 Dec 93 15:16:54 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA26724(netkeeper.sj.nec.com ); Mon, 27 Dec 93 15:17:50 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA04915(archimedes.inoc.sj.nec.com ); Mon, 27 Dec 93 15:17:46 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00113; Mon, 27 Dec 1993 15:46:36 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA16444 (8.6.4/IDA-1.5 for ); Fri, 24 Dec 1993 20:49:21 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA09030; Fri, 24 Dec 93 20:49:19 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA21210; Fri, 24 Dec 93 21:49:17 MST Message-Id: <9312250449.AA21210@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 24 Dec 1993 21:49:17 MST Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: vsta@cisco.com Subject: VSTa patches for binutils-2.3 Status: OR Here's a patch and a few new files that add VSTa support to the GNU binutils. At this current time, it's almost identical to the go32 (DJGPP) linker, but now we can change things... There are two files in this message, one vsta.patch is the patch file, the other vsta.shar is a shar file with the new config files in them. To add: 1. ftp the binutils-2.3.tar.gz from your favorite site. 2. untar binutils-2.3.tar.gz 3. unshar vsta.shar 4. patch < vsta.patch 5. configure --target i386-vsta (just vsta also works) 6. make When you type "make install", you'll get i386-vsta-ld (and the rest of the binutils). Then to link for VSTa, you can cross compile using a standard i386-aout or i386-go32 (DJGPP) tool chain. I've also used just gcc on my Linux box to get the object, then linked with i386-vsta-ld. I imagine that the gcc on NetBSD would work also. You'll still need to list crt0.o and libc.a when you link. I'll add these patches To our sources so they'll make the next binutils release. Next I'll add libc and crt0.o to the GNU C library to get a completely functioning system. Afterwards, gcc. I haven't been able to get the kernel to recompile using a standard i386-aout compiler yet, due to header problems. It's so nice getting away from DOS. :-) - rob - ----------------------- vsta.patch --------------------- Only in binutils-2.3.1/bfd/config: vsta.mh diff -rc binutils-2.3/bfd/config.bfd binutils-2.3.1/bfd/config.bfd *** binutils-2.3/bfd/config.bfd Fri Nov 5 19:15:55 1993 --- binutils-2.3.1/bfd/config.bfd Fri Dec 24 19:11:13 1993 *************** *** 93,98 **** --- 93,99 ---- *-*-netware*) bfd_name=${cpu}-nlm ;; *-*-sysv4*) bfd_name=${cpu}-elf ;; *-*-solaris2*) bfd_name=${cpu}-elf ;; + *-*-vsta*) bfd_name=${cpu}-aout ;; *-*-go32*) bfd_name=${cpu}-aout ;; *-*-sysv*) bfd_name=${cpu}-coff ;; diff -rc binutils-2.3/config.sub binutils-2.3.1/config.sub *** binutils-2.3/config.sub Fri Nov 5 19:15:19 1993 --- binutils-2.3.1/config.sub Fri Dec 24 19:06:30 1993 *************** *** 169,174 **** --- 169,178 ---- basic_machine=`echo $1 | sed -e 's/86.*/86-unknown/'` os=-solaris2 ;; + vsta | i386-vsta) # CYGNUS LOCAL + basic_machine=i386-unknown + os=-vsta + ;; go32 | i386-go32) # CYGNUS LOCAL basic_machine=i386-unknown os=-go32 *************** *** 654,660 **** | -amigados* | -msdos* | -newsos* | -unicos* | -aos* \ | -nindy* | -vxworks* | -ebmon* | -hds* \ | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \ ! | -go32 | -sim | -es1800* | -udi | -hms* | -xray \ | -os68k* | -none* | -v88r* | -aout* | -coff | -elf* | -bosx* \ | -ecoff* | -lynxos* | -netware* ) # The last three lines above are CYGNUS LOCAL --- 658,664 ---- | -amigados* | -msdos* | -newsos* | -unicos* | -aos* \ | -nindy* | -vxworks* | -ebmon* | -hds* \ | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \ ! | -go32 | -vsta | -sim | -es1800* | -udi | -hms* | -xray \ | -os68k* | -none* | -v88r* | -aout* | -coff | -elf* | -bosx* \ | -ecoff* | -lynxos* | -netware* ) # The last three lines above are CYGNUS LOCAL diff -rc binutils-2.3/configure.in binutils-2.3.1/configure.in *** binutils-2.3/configure.in Thu Nov 11 08:37:15 1993 --- binutils-2.3.1/configure.in Fri Dec 24 19:03:18 1993 *************** *** 161,166 **** --- 161,169 ---- noconfigdirs="" case "${host}" in + i[34]86-*-vsta) + noconfigdirs="tcl expect deja-gnu make texinfo bison patch flex byacc send-pr gprof uudecode dejagnu diff" + ;; i[34]86-*-go32) noconfigdirs="tcl expect deja-gnu make texinfo bison patch flex byacc send-pr gprof uudecode dejagnu diff" ;; *************** *** 194,199 **** --- 197,206 ---- fi gasdir=pagas ;; + i[34]86-*-vsta) + # add the vsta support tools to the list + configdirs=`echo vsta ${configdirs}` + ;; i[34]86-*-go32) # add the go32 support tools to the list configdirs=`echo go32 ${configdirs}` *************** *** 222,227 **** --- 229,236 ---- ;; sh-*-*) case "${host}" in + i[34]86-*-vsta) ;; # don't add gprof back in + *) configdirs=`echo gprof ${configdirs}` ;; i[34]86-*-go32) ;; # don't add gprof back in *) configdirs=`echo gprof ${configdirs}` ;; esac diff -rc binutils-2.3/ld/Makefile.in binutils-2.3.1/ld/Makefile.in *** binutils-2.3/ld/Makefile.in Wed Nov 10 20:32:15 1993 --- binutils-2.3.1/ld/Makefile.in Fri Dec 24 19:47:43 1993 *************** *** 165,171 **** BFDLIB = ../bfd/libbfd.a LIBIBERTY = ../libiberty/libiberty.a ! ALL_EMULATIONS=em_lnk960.o em_sun3.o em_i386aout.o em_go32.o \ em_m88kbcs.o em_a29k.o em_news.o em_hp300bsd.o em_hp3hpux.o \ em_h8300.o em_h8300h.o em_ebmon29k.o em_sun4.o em_gld960.o \ em_m68kcoff.o em_st2000.o em_sa29200.o em_i386mach.o \ --- 165,171 ---- BFDLIB = ../bfd/libbfd.a LIBIBERTY = ../libiberty/libiberty.a ! ALL_EMULATIONS=em_lnk960.o em_sun3.o em_i386aout.o em_go32.o em_vsta.o \ em_m88kbcs.o em_a29k.o em_news.o em_hp300bsd.o em_hp3hpux.o \ em_h8300.o em_h8300h.o em_ebmon29k.o em_sun4.o em_gld960.o \ em_m68kcoff.o em_st2000.o em_sa29200.o em_i386mach.o \ *************** *** 189,195 **** MANSOURCES=ld.tex LDCSOURCES=ldlang.c lexsup.c ldctor.c mri.c ldindr.c ldmain.c ldwrite.c ldwarn.c ldlnk960.c \ ! em_gld.c em_sun3.c em_go32.c em_m88k.c em_ebmon29k.c em_hppaosf.c \ ldgld960.c ldemul.c ldver.c ldmisc.c ldexp.c ldsym.c ldfile.c \ relax.c lderror.c --- 189,195 ---- MANSOURCES=ld.tex LDCSOURCES=ldlang.c lexsup.c ldctor.c mri.c ldindr.c ldmain.c ldwrite.c ldwarn.c ldlnk960.c \ ! em_gld.c em_sun3.c em_vsta.c em_go32.c em_m88k.c em_ebmon29k.c em_hppaosf.c \ ldgld960.c ldemul.c ldver.c ldmisc.c ldexp.c ldsym.c ldfile.c \ relax.c lderror.c *************** *** 260,265 **** --- 260,268 ---- em_sun3.c: $(srcdir)/emulparams/sun3.sh \ $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS} ${GENSCRIPTS} sun3 + em_vsta.c: $(srcdir)/emulparams/vsta.sh \ + $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS} + ${GENSCRIPTS} vsta em_go32.c: $(srcdir)/emulparams/go32.sh \ $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS} ${GENSCRIPTS} go32 Only in binutils-2.3.1/ld/config: vsta.mt diff -rc binutils-2.3/ld/configure.in binutils-2.3.1/ld/configure.in *** binutils-2.3/ld/configure.in Fri Nov 5 19:21:25 1993 --- binutils-2.3.1/ld/configure.in Fri Dec 24 18:48:49 1993 *************** *** 57,62 **** --- 57,63 ---- m680[01234]0-ericsson-ose) ld_target=ose68 ;; m683?2-ericsson-ose) ld_target=ose68 ;; *-tandem-none) ld_target=st2000 ;; # FIXME needs better name + i[34]86-*-vsta) ld_target=vsta ;; i[34]86-*-go32) ld_target=go32 ;; i[34]86-*-aix*) ld_target=i386-coff ;; i[34]86-*-sco*) ld_target=i386-coff ;; Only in binutils-2.3.1/ld/emulparams: vsta.sh ----------------------- vsta.shar -------------------------------- : To unbundle, sh this file echo binutils-2.3/bfd/config/vsta.mh cat >binutils-2.3/bfd/config/vsta.mh <<'@@@ Fin de binutils-2.3/bfd/config/vsta.mh' CC=gcc @@@ Fin de binutils-2.3/bfd/config/vsta.mh echo binutils-2.3/ld/config/vsta.mt cat >binutils-2.3/ld/config/vsta.mt <<'@@@ Fin de binutils-2.3/ld/config/vsta.mt' EMUL=vsta @@@ Fin de binutils-2.3/ld/config/vsta.mt echo binutils-2.3/ld/emulparams/vsta.sh cat >binutils-2.3/ld/emulparams/vsta.sh <<'@@@ Fin de binutils-2.3/ld/emulparams/vsta.sh' SCRIPT_NAME=aout OUTPUT_FORMAT="a.out-i386" TEXT_START_ADDR=0x1020 PAGE_SIZE=0x1000 SEGMENT_SIZE=0x400000 NONPAGED_TEXT_START_ADDR=0x0 ARCH=i386 @@@ Fin de binutils-2.3/ld/emulparams/vsta.sh exit 0 From vandys@cisco.com Wed Dec 29 14:56:43 1993 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA24269; Wed, 29 Dec 93 14:56:42 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02061; Wed, 29 Dec 93 14:57:56 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10743(netkeeper.sj.nec.com ); Wed, 29 Dec 93 14:59:03 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA08450(archimedes.inoc.sj.nec.com ); Wed, 29 Dec 93 14:59:00 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id PAA00077; Wed, 29 Dec 1993 15:25:56 -0800 Received: from localhost by glare.cisco.com with SMTP id AA22721 (5.67a/IDA-1.5 for ); Wed, 29 Dec 1993 14:48:46 -0800 Message-Id: <199312292248.AA22721@glare.cisco.com> To: David Eagle USG Cc: vsta@cisco.com In-Reply-To: Your message of "Wed, 29 Dec 1993 16:58:17 EST." <9312292158.AA06372@wasted.zk3.dec.com> Date: Wed, 29 Dec 1993 14:48:45 -0800 From: Andrew Valencia Status: OR [David Eagle USG writes:] >"Would we be able to write the kernel of VSTa into FLASH BIOS, >and thus boot amazingly fast?" "Should I make it a priority >to have FLASH BIOS as a component of the new system I am buying?" Well, I can get DOS to boot in about 6 seconds from a warm boot and about 12 from cold (RAM test disabled, no config.sys and empty autoexec.bat of course). VSTa takes about 10 seconds after that. I guess if you're stuck with a BIOS which is really poky it might pay off. >Also, I would appreciate comments on whether I could be hurt by >opting to save $150 by going with the Cyrix 486DLC/40 instead of >the Intel 486SX25. I have personally run VSTa on a 386, 486SX, and 486DX2 66 Mhz. I've never heard of anybody running on a Cyrix. From all accounts, it's supposed to be quite compatible--take a standalone boot floppy down to the store and give it a spin! If the standalone boot can come up, ID keyboard/screen/disk, then I'd expect that it's fine. Even if it didn't boot right off, source is available and I'd be interested in merging back any changes which fixed running with a Cyrix part (without breaking an Intel part, preferably... :->). Andy Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA20297 (8.6.4/IDA-1.5 for ); Sat, 1 Jan 1994 16:21:44 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15403; 2 Jan 94 0:20 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pGGW0-000J05C; Sun, 2 Jan 94 00:17 GMT Message-Id: From: Dave Hudson Subject: Re: Linux based build etc. To: vsta@cisco.com Date: Sun, 2 Jan 1994 00:17:51 +0000 (GMT) In-Reply-To: <9312202344.AA00460@europa.nsis.cl.nec.co.jp> from "Gavin Thomas Nicol" at Dec 21, 93 08:44:18 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: 1702 Gavin Thomas Nicol wrote (about the 20th December 1993): > > It's very good to see people with a working build under Linux. One > other thing that might be worth looking at is creating a VSTa image > that could be written to floppy. I did do some work on it, and > basically all you have to do is follow what boot.exe does, but instead > of writing to memory, write to disk. This will build up a memory > image. > > Of course, a boot block, and initialization code need to be tacked > onto the front of the image, but they're generally trivial. > Well I've just got the code to do exactly this working. It requires the Linux as86/ld86 pair to build the bootsector and setup code and currently uses a couple of utilities under Linux to make a loadable image. The code I have is as follows: combine: reads a "boot.lst" type file and creates a file containing the VSTa kernel and boot tasks bootsect: a floppy diskette bootstrap loader (uses PC BIOS int 0x13 calls). setup: initialises descriptor/page tables, switches to protected mode and starts VSTa proper. (This is independent of the bootsector code so it can be used when I get an HDD loader working as well) build: combines the output of all of the above into an image that can be "dd"'d to a diskette. Sometime I'd like to write a more generalised boot loader that would allow multiple boot configs to be selected, and that would hopefully let MS-DOS be booted as well. I suspect that Werner Almesberger's LILO for Linux would be a good starting place, but I'd like to get some work done on bitblt and port Werner's dosfsck and my mkdosfs code first :-) If you're interested I can mail the code to you. Happy New Year, Dave From vandys@cisco.com Fri Jan 7 10:00:32 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16946; Fri, 7 Jan 94 10:00:32 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09047; Fri, 7 Jan 94 10:01:40 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA11386(netkeeper.sj.nec.com ); Fri, 7 Jan 94 10:03:41 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14272(archimedes.inoc.sj.nec.com ); Fri, 7 Jan 94 10:03:38 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00098; Fri, 7 Jan 1994 10:22:05 -0800 Received: from localhost by glare.cisco.com with SMTP id AA23881 (5.67a/IDA-1.5 for ); Fri, 7 Jan 1994 09:46:48 -0800 Message-Id: <199401071746.AA23881@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Mapping user names In-Reply-To: Your message of "Thu, 06 Jan 1994 15:32:51 +0900." <9401060632.AA01988@europa.nsis.cl.nec.co.jp> Date: Fri, 07 Jan 1994 09:46:48 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >Can user names be mapped from msg.sender? MADO will need some way to >find out who connected to it, so it can load the user's font mappings. Hmmm, does MADO keep a central database? How would he know what the user's filesystem view would look like? Or does MADO register requested font names, but keep all the actual font storage under his own control? Anyway, the "perm_uid" field of a "struct perm" was added so that for each ability a server is told a client possesses, it can know *why* it has that ability. Roughly, "uid" is the login name--if the user is local. In a clustered configuration, I don't know yet how I'll map UIDs. I may just map all remote UIDs to a single UID like "net" by default. Andy From rob@darkstar.cygnus.com Fri Jan 7 10:33:51 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17086; Fri, 7 Jan 94 10:33:50 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09167; Fri, 7 Jan 94 10:34:58 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19580(netkeeper.sj.nec.com ); Fri, 7 Jan 94 10:36:57 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14428(archimedes.inoc.sj.nec.com ); Fri, 7 Jan 94 10:36:53 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00102; Fri, 7 Jan 1994 11:01:13 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA08535 (8.6.4/IDA-1.5 for ); Fri, 7 Jan 1994 10:25:55 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA11309; Fri, 7 Jan 94 10:25:53 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA00443; Fri, 7 Jan 94 11:25:52 MST Message-Id: <9401071825.AA00443@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 7 Jan 1994 11:25:52 MST In-Reply-To: Andrew Valencia "Bounced E-mail" (Jan 7, 9:23am) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , vsta@cisco.com Subject: Re: Bounced E-mail Status: OR > > Well I've just got the code to do exactly this working. It requires the > > Linux as86/ld86 pair to build the bootsector and setup code and currently > > uses a couple of utilities under Linux to make a loadable image. The code I > > have is as follows: The LD patch I made is all you need to develop VSTa hosted applications under Linux, I just use the native cc (gcc really) to produce an object, then linking it with i386-vsta-ld sets everything right. > > If you're interested I can mail the code to you. I'll try to incorporate any of these changes back into the mainstream GNU sources. As of now, I've got a full VSTa specific cross tool chain built. (gcc, gas, ld, all binutils). I'm working on libc now. - rob - From eagle@zk3.dec.com Fri Jan 7 11:04:09 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17279; Fri, 7 Jan 94 11:04:08 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09396; Fri, 7 Jan 94 11:05:15 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19960(netkeeper.sj.nec.com ); Fri, 7 Jan 94 11:07:17 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA14575(archimedes.inoc.sj.nec.com ); Fri, 7 Jan 94 11:07:10 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00106; Fri, 7 Jan 1994 11:33:48 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by hubbub.cisco.com with SMTP id AA10472 (8.6.4/IDA-1.5 for ); Fri, 7 Jan 1994 10:58:30 -0800 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA03284; Fri, 7 Jan 1994 13:58:28 -0500 Received: by wasted.zk3.dec.com; id AA26828; Fri, 7 Jan 1994 13:51:54 -0500 Date: Fri, 7 Jan 1994 13:51:54 -0500 From: David Eagle USG Message-Id: <9401071851.AA26828@wasted.zk3.dec.com> Apparently-To: vsta@cisco.com Status: OR Roughly, "uid" is the login name--if the user is local. In a clustered configuration, I don't know yet how I'll map UIDs. I may just map all remote UIDs to a single UID like "net" by default. Andy ... Please don't do this. I have strong feelings about individuals owning their own personal computers, including all the information such as uids on their local system. I have a more detailed writeup of an alternate userID mapping strategy at home that will take me a few days to get to you (I have to go home. I have to find it on my home PC. I have to log onto a local BBS with network connections. I have to mail the paper to myself at work. I have to go to work. I have to send it to you.) But at least the approach you describe is not as bad as trying to map remote user IDs to the SAME local user ID, which introduces all kinds of contradictions, and also assumes that the local password files are subordinate to the 'global' password/userID file. Which of course leads to such security holes as "broadcasting the master password file to all attached nodes" each night to keep everyone in sync. Yuck! From dave@humbug.demon.co.uk Sat Jan 8 05:52:00 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA06235; Sat, 8 Jan 94 05:51:59 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12691; Sat, 8 Jan 94 05:53:06 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00246(netkeeper.sj.nec.com ); Sat, 8 Jan 94 05:55:12 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16335(archimedes.inoc.sj.nec.com ); Sat, 8 Jan 94 05:55:08 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id GAA00317; Sat, 8 Jan 1994 06:02:14 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA14437 (8.6.4/IDA-1.5 for ); Sat, 8 Jan 1994 05:27:00 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa07401; 8 Jan 94 13:22 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pIdZN-000G5vC; Sat, 8 Jan 94 13:19 GMT Message-Id: From: Dave Hudson Subject: Booting VSTa To: vsta@cisco.com Date: Sat, 8 Jan 1994 13:19:09 +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: 2060 Status: OR Hi all, I've been doing some more thinking about how to improve the booting of VSTa. Currently I can use DOS or my floppy based loader. I'd like to see what the general response to some more developments are. First a couple of comments: The DOS load is neat as it allows all of the boot time server's parameters to be specified in "boot.lst", and the location of the servers can physically change on the disk (although not the name/directory unless boot.lst is changed). My current loader requires a build process where the boot time servers are merged into a large file and then placed at a known location before it can be booted. I'd like to extend the boot loading to handle hard drives, and provide some of the features found on boot loaders like LILO under Linux. In particular I want to still be able to boot DOS and OS/2 as well as VSTa (Linux would be nice as well!). The biggest problem is that in order to be able to build the boot loader I need to write in assembly language (or at least this is by far the neatest way to go), and I'm currently trying to keep the code/data at < 32 kbytes. The problems with writing the code are: 1. If I don't build any filesystem knowledge into the boot loader, I need to maintain a list of all of the sectors that need to be loaded to boot a kernel/boot servers. 2. If I build simple support for a filesystem into the boot loader it would need to be for a simple fs, and I have a natural aversion to DOS fs because of the filename length and permissions restrictions. This solution would avoid needing to pre-build a file with the kernel/boot servers in it, as boot.lst could be scanned and read at boot time. So, what does everyone think - go with the first solution (where I need to find a way of determining which sectors are in a pre-built boot file), or go with the second solution (where we need a special boot partition)? I can see arguments for and against both, so before I start to think about any more code here I'd like some comments. Maybe I've missed another way? Regards, Dave From pat@wesson.it.com.au Sat Jan 8 08:29:04 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09392; Sat, 8 Jan 94 08:29:03 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13011; Sat, 8 Jan 94 08:30:10 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01010(netkeeper.sj.nec.com ); Sat, 8 Jan 94 08:32:17 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16407(archimedes.inoc.sj.nec.com ); Sat, 8 Jan 94 08:32:10 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00326; Sat, 8 Jan 1994 08:58:49 -0800 Received: from joyce.cs.su.OZ.AU by hubbub.cisco.com with SMTP id AA15599 (8.6.4/IDA-1.5 for ); Sat, 8 Jan 1994 08:23:37 -0800 Received: from wesson.it.com.au by joyce.cs.su.OZ.AU (mail from pat for vsta@cisco.com) with MHSnet (insertion MHSnet site: garion.it.com.au); Sun, 09 Jan 1994 03:23:35 +1100 Received: from wesson by garion.it.com.au with smtp (Smail3.1.28.1 #3) id m0pIgSR-0000ZZ5; Sun, 9 Jan 94 00:24 WST Message-Id: From: pat@wesson.it.com.au (Pat Mackinlay) Subject: Re: Booting VSTa To: dave@humbug.demon.co.uk (Dave Hudson) Date: Sun, 9 Jan 1994 00:17:08 +0800 (WST) Cc: vsta@cisco.com (VSTa Mailing List) In-Reply-To: from "Dave Hudson" at Jan 8, 94 01:19:09 pm X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 792 Status: OR > So, what does everyone think - go with the first solution (where I need to > find a way of determining which sectors are in a pre-built boot file), or go > with the second solution (where we need a special boot partition)? I'm a Linux user also, and I love LILO. It's a very neat and powerful way to handle the booting process, and I've never had any problems at all with it. I've never really been a fan of the restricted filing system approach as it places some silly restrictions on the system setup, and also turns the boot loader into a fairly complex piece of software. If I were doing this, I'd be aiming at borrowing a lot of code from LILO, and extending it to allow arbitrary servers to be loaded at bootup. That's my opinion, anyhow. -- pat -- empty space is wasted space. From vandys@cisco.com Sat Jan 8 09:14:58 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA09408; Sat, 8 Jan 94 09:14:57 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13109; Sat, 8 Jan 94 09:16:04 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA01285(netkeeper.sj.nec.com ); Sat, 8 Jan 94 09:18:11 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA16437(archimedes.inoc.sj.nec.com ); Sat, 8 Jan 94 09:18:08 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00330; Sat, 8 Jan 1994 09:45:02 -0800 Received: from localhost by glare.cisco.com with SMTP id AA18593 (5.67a/IDA-1.5 for ); Sat, 8 Jan 1994 09:09:51 -0800 Message-Id: <199401081709.AA18593@glare.cisco.com> To: Dave Hudson Cc: vsta@cisco.com Subject: Re: Booting VSTa In-Reply-To: Your message of "Sat, 08 Jan 1994 13:19:09 GMT." Date: Sat, 08 Jan 1994 09:09:50 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >So, what does everyone think - go with the first solution (where I need to >find a way of determining which sectors are in a pre-built boot file), or go >with the second solution (where we need a special boot partition)? Well, I naturally like the most general solution, but I can imagine how hairy such a boot loader could become. DOS is actually a pretty simple boot filesystem; name length doesn't matter much, and you can ignore permissions entirely. The FAT table is simple, and the biggest complication is that the root directory and subdirectories are allocated differently. If you don't do block buffering most of this can be ignored. >I can see arguments for and against both, so before I start to think about >any more code here I'd like some comments. Maybe I've missed another way? It's hard for me to comment, since I think we need to spell out a couple implicit assumptions: 1. We want to choose operating systems from a boot prompt 2. Once we choose one, we want to enter that OS with no intermediate steps. 3. We don't mind requiring a DOS partition (or do we?). 4. If all the self-hosted compiles are under a vstafs partition, we don't mind copying them to a DOS partition (I would mind, or rather, I would add a "make install" build step). 5. We don't mind if our boots fail in mysterious ways because a server got re-built (but the sector map wasn't updated). 6. We want to be able to boot on machines with no DOS. For some mix of these, there are other cheap-o options. For instance, have your autoexec.bat run boot.exe. This satisfies 1, 2, 3, 5. It fails miserably on 6, and leaves 4 as a problem. A LILO-like loader which understands DOS filesystems satisfies 1, 2, 3, 5. It fails on 6. But if we teach it vstafs, it could cover 6, and even 4. Is the loader becoming a monster, though? What if we all decide we hate vstafs, and go with minixfs instead? Should we imbed a small interpreted language in it so it's easy to extend for future filesystems? Then you could compile in whichever filesystems you currently need, which would cap the bloat of the executable image, even if you added lots of different filesystems to it. My philosophy when I wrote VSTa was that DOS made a dandy bootstrap loader. Thus, I never considered booting DOS first to be a problem, any more than I mind the boot ROM step of a Sun workstation bootup. For true standalone, something like your floppy booter is exactly what I had in mind. For the middle ground you're now exploring, VSTa's flexible perspective on filesystems is making it hard to find "the" solution. "I don't have a solution, but I certainly admire the problem." Regards, Andy From nick@nsis.cl.nec.co.jp Sun Jan 9 16:06:32 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16999; Sun, 9 Jan 94 16:06:31 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18091; Sun, 9 Jan 94 16:07:38 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA02271(netkeeper.sj.nec.com ); Sun, 9 Jan 94 16:09:52 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17551(archimedes.inoc.sj.nec.com ); Sun, 9 Jan 94 16:09:49 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00486; Sun, 9 Jan 1994 16:35:41 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA21591 (8.6.4/IDA-1.5 for ); Sun, 9 Jan 1994 16:00:34 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.4/6.4J.6-TYO_gate) id JAA15014; Mon, 10 Jan 1994 09:00:29 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA03887; Mon, 10 Jan 1994 09:00:28 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940107.1) id AA12180; Mon, 10 Jan 1994 09:00:26 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00470; Mon, 10 Jan 94 09:00:04 +0900 Date: Mon, 10 Jan 94 09:00:04 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9401100000.AA00470@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Mapping user names Status: OR >>Can user names be mapped from msg.sender? MADO will need some way to >>find out who connected to it, so it can load the user's font mappings. > >Hmmm, does MADO keep a central database? How would he know what the >user's filesystem view would look like? Or does MADO register requested >font names, but keep all the actual font storage under his own control? Well, font handling is pretty much taken care of in bitblt (ie. font loading etc.), but I've always planned on MADO/bitblt to support UTF. To do this, I decided to use a segmented font architecture similar to 8.5. In this scheme, you have a character range to font mapping table like: #character range font 0-31 ascii-control 32-127 time-roman One ability I was hoping to give to MADO was the ability for user-defined font mappings, which requires some way of finding a user's HOME and then reading in a MADO configuration file. From vandys@cisco.com Sun Jan 9 20:23:40 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17028; Sun, 9 Jan 94 20:23:39 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18599; Sun, 9 Jan 94 20:24:45 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04415(netkeeper.sj.nec.com ); Sun, 9 Jan 94 20:27:01 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA17729(archimedes.inoc.sj.nec.com ); Sun, 9 Jan 94 20:26:59 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00498; Sun, 9 Jan 1994 20:51:42 -0800 Received: from localhost by glare.cisco.com with SMTP id AA16890 (5.67a/IDA-1.5 for ); Sun, 9 Jan 1994 20:16:39 -0800 Message-Id: <199401100416.AA16890@glare.cisco.com> To: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Cc: vsta@cisco.com Subject: Re: Mapping user names In-Reply-To: Your message of "Mon, 10 Jan 1994 09:00:04 +0900." <9401100000.AA00470@europa.nsis.cl.nec.co.jp> Date: Sun, 09 Jan 1994 20:16:38 -0800 From: Andrew Valencia Status: OR [nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:] >One ability I was hoping to give to MADO was the ability for >user-defined font mappings, which requires some way of finding a >user's HOME and then reading in a MADO configuration file. But bitblt probably doesn't have permissions to access their $HOME. There is no setuid (and this was intentional). Even if it happened to have their abilities, there's no reason to assume the user wants to store their own fonts in $HOME, in a filesystem under $HOME, or even on a fileserver which bitblt could ever find. Imagine keeping the font files on a pkzipfs, and wanting to load one. You start up a pkzipfs on your .zip file containing all your personal fonts, mount it into your name space, and... bitblt can't understand the path. Would it be possible for the program/library which adds a font to write() the font information to the bitblt server? I don't remember if bitblt provides a directory hierarchy when you mount him, but if it did, you could just create a file in the fonts/ subdir under the server. If you already see the filename there, you don't have to bother. This would guarantee that the program which wants to add the font has the ability to access the font file to be added. I'm not sure there's a downside, unless there's a fundamental difficulty with bitblt accepting fonts over connections? Andy From dave@humbug.demon.co.uk Mon Jan 10 05:11:29 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17337; Mon, 10 Jan 94 05:11:28 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19861; Mon, 10 Jan 94 05:12:34 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08808(netkeeper.sj.nec.com ); Mon, 10 Jan 94 05:14:52 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18109(archimedes.inoc.sj.nec.com ); Mon, 10 Jan 94 05:14:49 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id FAA00605; Mon, 10 Jan 1994 05:41:01 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA09720 (8.6.4/IDA-1.5 for ); Mon, 10 Jan 1994 05:05:58 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa29744; 10 Jan 94 13:00 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pJMB3-000G16C; Mon, 10 Jan 94 12:57 GMT Message-Id: From: Dave Hudson Subject: More ideas on booting VSTa To: vsta@cisco.com Date: Mon, 10 Jan 1994 12:57:00 +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: 2310 Status: OR Ok, I've had a bit more time to think about the boot problem and I have a new idea I'd like to bounce around. There's one prerequisite to all of this thinking - I believe that I'm right in thinking that it should be possible to create a filesystem within a file of another filesystem (a bit like stacker does under DOS). If I've got this wrong stop me now :-) I still like the idea of keeping the flexibility in having a "boot.lst" file, but I don't want to force boot filesystems onto people who have no need for them (or in the case of floppy booting people who really can't have 2 partitions). What I was thinking is this: 1. Invent a new boot file system type - very simple, with limited if any subdirectory handling. 2. Create utilities to make and repair the boot file system, where the fs can be made on a raw disk partition or a largish file of an existing fs. 3. Write a boot filesystem server. 4. Write a LILO like boot manager, but instead of reading command parameters and writing them into a data area or bootsector (as under Linux), write them into the area reserved for command line parameters of the boot time servers. 5. Ensure that any shutdown utility checks that if our boot fs is really a file of another fs, that some defined action can be taken in the event that the boot fs file has been moved. So far I can't see any obvious problems. As I see it: A. The new fs behaves like any other fs, eg mount it as "/boot" and we have something like: /boot/vsta /boot/dos /boot/rs232 /boot/rs232.new.100193 B. We can have different versions/implementations of the same server (eg the 2 rs232 drivers in the example above) without having to have 2 complete boot time images. C. The only thing we need to be able to do is determine where all of the sectors of the boot fs are, irrespective of whether it's a partition in its own right or whether it's a file in another fs. So, (quickly dons a flame proof suit) are there any glaringly obvious points I've missed here? I'd like to hear any comments. If there's support for this way forward, how many files would such a boot fs need to support (as a default - the mkfs facility should allow fewer/more to be selected). Also how many characters should the filenames be (max). I was thinking about 24-30ish. Regards, Dave From tthorn@daimi.aau.dk Mon Jan 10 09:49:18 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA17726; Mon, 10 Jan 94 09:49:17 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20695; Mon, 10 Jan 94 09:50:22 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA23072(netkeeper.sj.nec.com ); Mon, 10 Jan 94 09:52:40 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18671(archimedes.inoc.sj.nec.com ); Mon, 10 Jan 94 09:52:33 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00621; Mon, 10 Jan 1994 10:08:02 -0800 Received: from avignon.daimi.aau.dk by hubbub.cisco.com with SMTP id AA17306 (8.6.4/IDA-1.5 for ); Mon, 10 Jan 1994 09:33:01 -0800 Received: by avignon.daimi.aau.dk id AA09627 (5.65c8/IDA-1.4.4 for vsta@cisco.com); Mon, 10 Jan 1994 18:32:59 +0100 Date: Mon, 10 Jan 1994 18:32:59 +0100 From: Tommy Thorn Message-Id: <199401101732.AA09627@avignon.daimi.aau.dk> To: vsta@cisco.com Subject: Re: Booting VSTa In-Reply-To: <199401081709.AA18593@glare.cisco.com> References: <199401081709.AA18593@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Status: OR Andrew Valencia writes: .. > It's hard for me to comment, since I think we need to spell out a couple > implicit assumptions: > > 1. We want to choose operating systems from a boot prompt > 2. Once we choose one, we want to enter that OS with no intermediate > steps. > 3. We don't mind requiring a DOS partition (or do we?). > 4. If all the self-hosted compiles are under a vstafs partition, we > don't mind copying them to a DOS partition (I would mind, or > rather, I would add a "make install" build step). > 5. We don't mind if our boots fail in mysterious ways because a server > got re-built (but the sector map wasn't updated). > 6. We want to be able to boot on machines with no DOS. .. > A LILO-like loader which understands DOS filesystems satisfies 1, 2, > 3, 5. It fails on 6. But if we teach it vstafs, it could cover 6, False. LILO gets the physical sectors from the OS when you install a new image. The boot-part of LILO has no filesystem knowledge. This is one of the (good) design decisions, as LILO will work no matter which kind of filesystem the future might bring. (As long as files remain in place, unlike Log Structured Filessystems.) I'd suggest either porting LILO to VSTa (fairly easy?) or using a similar scheme. Dave Hudson writes: > Ok, I've had a bit more time to think about the boot problem and I have a > new idea I'd like to bounce around. > > There's one prerequisite to all of this thinking - I believe that I'm right > in thinking that it should be possible to create a filesystem within a file > of another filesystem (a bit like stacker does under DOS). If I've got this > wrong stop me now :-) > > I still like the idea of keeping the flexibility in having a "boot.lst" > file, but I don't want to force boot filesystems onto people who have no > need for them (or in the case of floppy booting people who really can't have > 2 partitions). What I was thinking is this: > > > 1. Invent a new boot file system type - very simple, with limited if any > subdirectory handling. I could suggest "tar". > 2. Create utilities to make and repair the boot file system, where the fs > can be made on a raw disk partition or a largish file of an existing fs. > > 3. Write a boot filesystem server. > > 4. Write a LILO like boot manager, but instead of reading command parameters > and writing them into a data area or bootsector (as under Linux), write them > into the area reserved for command line parameters of the boot time servers. > > 5. Ensure that any shutdown utility checks that if our boot fs is really a > file of another fs, that some defined action can be taken in the event that > the boot fs file has been moved. > > > So far I can't see any obvious problems. As I see it: > > A. The new fs behaves like any other fs, eg mount it as "/boot" and we have > something like: > > /boot/vsta > /boot/dos > /boot/rs232 > /boot/rs232.new.100193 > > B. We can have different versions/implementations of the same server (eg the > 2 rs232 drivers in the example above) without having to have 2 complete boot > time images. > > C. The only thing we need to be able to do is determine where all of the > sectors of the boot fs are, irrespective of whether it's a partition in its > own right or whether it's a file in another fs. > > > So, (quickly dons a flame proof suit) are there any glaringly obvious points > I've missed here? I'd like to hear any comments. If there's support for > this way forward, how many files would such a boot fs need to support (as a > default - the mkfs facility should allow fewer/more to be selected). Also > how many characters should the filenames be (max). I was thinking about > 24-30ish. Please explain to me why this would be much better, than just running something lilo-like when you would otherwise had reorganized the files in your bootfs? /Tommy From vandys@cisco.com Mon Jan 10 10:38:52 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18196; Mon, 10 Jan 94 10:38:50 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20995; Mon, 10 Jan 94 10:39:55 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA06542(netkeeper.sj.nec.com ); Mon, 10 Jan 94 10:42:13 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA18912(archimedes.inoc.sj.nec.com ); Mon, 10 Jan 94 10:42:09 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00626; Mon, 10 Jan 1994 11:06:57 -0800 Received: from localhost by glare.cisco.com with SMTP id AA13458 (5.67a/IDA-1.5 for ); Mon, 10 Jan 1994 10:31:57 -0800 Message-Id: <199401101831.AA13458@glare.cisco.com> To: Dave Hudson Cc: vsta@cisco.com Subject: Re: More ideas on booting VSTa In-Reply-To: Your message of "Mon, 10 Jan 1994 12:57:00 GMT." Date: Mon, 10 Jan 1994 10:31:56 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >There's one prerequisite to all of this thinking - I believe that I'm right >in thinking that it should be possible to create a filesystem within a file >of another filesystem (a bit like stacker does under DOS). If I've got this >wrong stop me now :-) No, you have it right. Both bfs and vstafs have run on top of another file. The big "gotcha" is that you have to make sure the server closes before the underlying filesystem closes, otherwise the file data may not be updated (and thus, your filesystem will be corrupt, since the underlying server's "file data" is your filesystem structures!). >1. Invent a new boot file system type - very simple, with limited if any >subdirectory handling. bfs. :-) >2. Create utilities to make and repair the boot file system, where the fs >can be made on a raw disk partition or a largish file of an existing fs. bfs/cmd (mkfs, fsck is missing) >3. Write a boot filesystem server. bfs. Written. :-) A tarfs would be neat to have too, but if you're more interested in the boot process than in writing a new filesystem, bfs is already there. >... >5. Ensure that any shutdown utility checks that if our boot fs is really a >file of another fs, that some defined action can be taken in the event that >the boot fs file has been moved. Um, not pretty. I've purposely set up all filesystems so that once your system falls idle you can just power off. Dependencies on shutdown processes make operating systems very fragile. This is not a fatal objection, more below. >C. The only thing we need to be able to do is determine where all of the >sectors of the boot fs are, irrespective of whether it's a partition in its >own right or whether it's a file in another fs. This would be good to generalize, so that a single program could do the job for any filesystem which cared to be supported. I'd use rstat(), but its job is supposed to be done witha relatively modest amount of returned data--a sector list could be enormous. A distinct filesystem operation would do. What we do for the sync()'ing problem is add fsync() to our filesystems. Then we have the filesystems fsync() their underlying "device" when they want to make sure data is out to physical media. If it's running on another filesystem, the filesystem writes out its blocks. If it's just a disk, the fsync() is ignored (because the driver has already done the requested I/O). This is desirable in general; I was planning on doing it before your boot loader questions ever came up. The logistics of placing the images into the boot filesystem are non-trivial. If you're doing self-hosted builds, copying the files to /boot is easy enough. If you're cross-compiling, you would need something like mtools, but for bfs instead of DOS. If you're cross-compiling but booting the images on another box, you'll have to deal with the two steps of copying over the image, and adding it to the boot filesystem. Editing boot.lst is easy for self-hosted builds (emacs /boot/boot.lst), harder with mtools (emacs boot.lst ; bcp boot.lst /x/y/z/boot.lst), and impossible if you don't have mtools. At worst, your scheme still allows the current DOS-oriented boot process to be used. The great advantage of your scheme, of course, is that the filesystem blocks are much less likely to move around (and thus invalidate the precalculated sectors the LILO-like loader keeps) than if you had to do it for each server image. Or, if you did indeed assemble everything into a single boot image, it still makes it far easier to deal with multiple versions of various servers. Building under VSTa, the boot build is very convenient indeed. All you do is edit and copy files as appropriate, with no follow-on programs to recalculate sector locations. Andy From dave@humbug.demon.co.uk Tue Jan 11 01:50:04 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23791; Tue, 11 Jan 94 01:50:03 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23714; Tue, 11 Jan 94 01:51:08 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16374(netkeeper.sj.nec.com ); Tue, 11 Jan 94 01:53:31 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21426(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 01:53:28 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id CAA00886; Tue, 11 Jan 1994 02:18:35 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA19563 (8.6.4/IDA-1.5 for ); Tue, 11 Jan 1994 01:43:37 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10577; 11 Jan 94 9:35 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pJfKX-000G1KC; Tue, 11 Jan 94 09:24 GMT Message-Id: From: Dave Hudson Subject: Re: Booting VSTa To: Tommy.Thorn@daimi.aau.dk Date: Tue, 11 Jan 1994 09:24:05 +0000 (GMT) Cc: vsta@cisco.com In-Reply-To: <199401101732.AA09627@avignon.daimi.aau.dk> from "Tommy Thorn" at Jan 10, 94 06:32:59 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2503 Status: OR Tommy Thorn wrote: > > I'd suggest either porting LILO to VSTa (fairly easy?) or using > a similar scheme. This is certainly an option - in fact it's what I was almost certainly going to do until a couple of days ago - it may still be a good way to do things. > > > 1. Invent a new boot file system type - very simple, with limited if any > > subdirectory handling. > > I could suggest "tar". I'd like a tarfs too! > > [...earlier ideas deleted...] > > Please explain to me why this would be much better, than just running > something lilo-like when you would otherwise had reorganized the files > in your bootfs? > > /Tommy > Hmm: For a LILO image I need something like the bootable image I use for floppy booting. This has very little overhead (spacewise) when there's only the one boot image (about 300k currently for all of my boot servers and the microkernel itself). For each new image however we start adding a further 300k. This probably isn't too much of a problem on a hard drive, but I also like to have a general system maintenance floppy and I don't think I would want 2 or more images on a floppy. Under Linux with all of the device support in one 400k compressed kernel I only need one kernel image, but I soon run out of space doing this with VSTa since the kernel and boot servers are loaded below 640k. My floppy loader can just squeeze 572 kbytes into this space so I'm only going to be able to add 6 more boot servers before I have a real problem (the problem gets worse if the library code linked to each server gets much bigger - until we have shared libs). Additionally, every time a server is modified we need to remerge a bootable image and rerun the "LILO" installer (although if everyone's prepared to accept this it could be done as part of the server's makefile). A boot fs of the type I described before only requires only one copy of each different server binary on the entire system (so it saves space), and thinking about it, it should be possible to make it automatically update the boot loader's sector map if it physically moves on the disk (gets rid of the shutdown util objection I hope) I suspect I want to run VSTa in a somewhat atypical way since I run lots of differently configured systems. I'm still a little concerned that I don't want to create something that's completely [345]86 PC specific, and I'd hope that a boot fs concept would be portable to other architectures (maybe I'm showing my ignorance here though). Regards, Dave From vandys@cisco.com Tue Jan 11 09:16:10 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00289; Tue, 11 Jan 94 09:16:09 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00519; Tue, 11 Jan 94 09:17:15 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA20090(netkeeper.sj.nec.com ); Tue, 11 Jan 94 09:19:39 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA22256(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 09:19:37 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00904; Tue, 11 Jan 1994 09:43:19 -0800 Received: from localhost by glare.cisco.com with SMTP id AA12495 (5.67a/IDA-1.5 for ); Tue, 11 Jan 1994 09:08:25 -0800 Message-Id: <199401111708.AA12495@glare.cisco.com> To: Dave Hudson Cc: Tommy.Thorn@daimi.aau.dk, vsta@cisco.com Subject: Re: Booting VSTa In-Reply-To: Your message of "Tue, 11 Jan 1994 09:24:05 GMT." Date: Tue, 11 Jan 1994 09:08:24 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >want 2 or more images on a floppy. Under Linux with all of the device >support in one 400k compressed kernel I only need one kernel image, but I >soon run out of space doing this with VSTa since the kernel and boot servers >are loaded below 640k. Please remember that your boot servers should *only* be a disk driver, and a filesystem. You can run all other drivers off the filesystem, as well as any other filesystems. This is why I didn't add > 1M support for my boot loader--if you're loading that much on boot, you're not taking advantage of a microkernel's abilities. You can demand-page executables off *any* filesystem--including bfs. >I suspect I want to run VSTa in a somewhat atypical way since I run lots of >differently configured systems. I'm still a little concerned that I don't >want to create something that's completely [345]86 PC specific, and I'd hope >that a boot fs concept would be portable to other architectures (maybe I'm >showing my ignorance here though). You can also kill off servers (even device drivers) which you no longer need. The real point of a microkernel is that you can be bringing up and shutting down various device support configurations, without having to boot your box. Andy From jont@hsa.com.au Tue Jan 11 16:28:17 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13254; Tue, 11 Jan 94 16:28:15 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02320; Tue, 11 Jan 94 16:29:20 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19504(netkeeper.sj.nec.com ); Tue, 11 Jan 94 16:31:47 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23798(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 16:31:38 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA01008; Tue, 11 Jan 1994 16:57:10 -0800 Received: from warrane.connect.com.au by hubbub.cisco.com with SMTP id AA21109 (8.6.4/IDA-1.5 for ); Tue, 11 Jan 1994 16:22:10 -0800 Received: by warrane.connect.com.au with UUCP id AA21333 (5.67b8/IDA-1.5 for vsta@cisco.com); Wed, 12 Jan 1994 11:22:01 +1100 Received: from saangreal.hsa.com.au (saangreal) by hsa.hsa.com.au with SMTP id AA24443 (5.65c/IDA-1.5 for ); Wed, 12 Jan 1994 10:58:43 +1100 From: Jonathon Tidswell Message-Id: <199401112358.AA24443@hsa.hsa.com.au> Subject: Re: Booting VSTa To: vsta@cisco.com Date: Wed, 12 Jan 1994 10:55:40 +1100 (EST) Reply-To: jont@hsa.com.au Organization: Hydrographic Sciences Australia P/L Organisation: Disorganised. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1938 Status: OR > From: Andrew Valencia > > [Dave Hudson writes:] > > >want 2 or more images on a floppy. Under Linux with all of the device > >support in one 400k compressed kernel I only need one kernel image, but I > >soon run out of space doing this with VSTa since the kernel and boot servers > >are loaded below 640k. > > Please remember that your boot servers should *only* be a disk driver, and > a filesystem. You can run all other drivers off the filesystem, as well as > any other filesystems. This is why I didn't add > 1M support for my boot > loader--if you're loading that much on boot, you're not taking advantage > of a microkernel's abilities. There are two related issues: - a simple boot disk/procedure for normal use, and - a standalone boot method for handling systems where problems have occured [ ie a corrupted FS ] It would be nice if the boot procedure could be the same for both uses. And the second case potentially needs many more boot time servers, since it is not guaranteed that they will be loadable from the normal medium. I have some preference for a separate BFS partition - we want a special list of sectors to load, lets not duplicate the work that partitions already do in isolating and identifying sectors. Since a great deal of flexibility exists in what is placed on the BFS (from almost nothing to almost everything ;) and the space is not necessarily wasted I like the added security of having boot code in a guaranteed stable/clean partition. FWIW SVR4 uses/requires a BFS. - JonT -- Jonathon Earnshaw Tidswell | Telephone: +61 2 957 3549 Hydrographic Sciences Australia P/L | Facsimile: +61 2 959 3594 PO Box 85 Cammeray NSW Australia 2062 | E-mail: jont@hsa.com.au Disclaimer: I think my thoughts are my own, and I believe my writings are too. "These are my opinions, others may have similar ones, but these are MINE." From vandys@cisco.com Tue Jan 11 16:46:42 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13289; Tue, 11 Jan 94 16:46:41 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02406; Tue, 11 Jan 94 16:47:45 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19692(netkeeper.sj.nec.com ); Tue, 11 Jan 94 16:50:12 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23874(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 16:50:08 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA01011; Tue, 11 Jan 1994 17:13:58 -0800 Received: from localhost by glare.cisco.com with SMTP id AA17592 (5.67a/IDA-1.5 for ); Tue, 11 Jan 1994 16:39:06 -0800 Message-Id: <199401120039.AA17592@glare.cisco.com> To: David Eagle USG Cc: vsta@cisco.com In-Reply-To: Your message of "Tue, 11 Jan 1994 11:03:04 EST." <9401111603.AA04899@wasted.zk3.dec.com> Date: Tue, 11 Jan 1994 16:39:05 -0800 From: Andrew Valencia Status: OR [David Eagle USG writes:] >This message is in response to the brief discussion earlier >about user IDs and what to do about remote users. >... Remember, UIDs are not used to determine what you can or can not read. So two distinct users can both possess, say, 1.3, but because the "struct perm" in has a UID field, you can tell that one user got 1.3 because he's "joe", but another user got it because of being "frank". It is more of an accounting thing. I expect that each node is configured to know what kind of mapping/trust to apply to its fellow nodes. In my paper, I wrote about a mapping like: Node His_perm My_perm pc0 * * pc1 1.* 9.* pc1 2.3 5.7 pc1 * 2.2 pc2 * 2.2 The first entry says that if somebody comes across from pc0, we trust that PC and we have coordinated permissions. So anything you have on pc0, you get on my machine as well. The second entry says that we trust pc1 well enough that if you have a 1.* permission on pc1, we'll convert to 9.* on our side, and give you that permission. This is for semi-trusted machines, where you want to map part of one machine's users but don't want to bother keeping lock- step permission values. The third entry is similar, except that we're mapping a single permission value. The fourth says that we'll let other permissions through, but they all get mapped to 2.2. This assumes you don't store anything precious with access allowed for 2.2 (in fact, the default distribution file etc/ids maps this to bad.bad), but such a permission can still be used to read public files and such. The final entry would be appropriate for a PC which we don't trust at all, but we will allow them untrusted access. Such an entry might be used if you had some games which somebody else wanted to run or copy. There, all that about permission. What about UIDs? Well, if a UID is used to tell *why* somebody got a permission, then it's easy for the local case--they got them because they logged in, and we use the UID for their account. For networks, I see two possibilities. Either everybody gets a UID for "net", which means they came across the net. Or, you could enhance the mapping table: Node His_perm My_perm UID pc0 * * 123 pc1 1.* 9.* 379 ... So that you get a UID which tells you which entry in the table was responsible for the permission granted. I don't think a table like: Node His_perm My_perm His_UID My_UID pc0 * * 123 456 ... is great, because I want to make permissions easy to share, and this would make you add table entries for every single remote user for every single permission. Andy From vandys@cisco.com Tue Jan 11 16:57:34 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA13370; Tue, 11 Jan 94 16:57:34 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02518; Tue, 11 Jan 94 16:58:39 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA19881(netkeeper.sj.nec.com ); Tue, 11 Jan 94 17:01:05 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23979(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 17:01:02 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id RAA01015; Tue, 11 Jan 1994 17:28:06 -0800 Received: from localhost by glare.cisco.com with SMTP id AA18661 (5.67a/IDA-1.5 for ); Tue, 11 Jan 1994 16:53:13 -0800 Message-Id: <199401120053.AA18661@glare.cisco.com> To: jont@hsa.com.au Cc: vsta@cisco.com Subject: Re: Booting VSTa In-Reply-To: Your message of "Wed, 12 Jan 1994 10:55:40 +1100." <199401112358.AA24443@hsa.hsa.com.au> Date: Tue, 11 Jan 1994 16:53:13 -0800 From: Andrew Valencia Status: OR [Jonathon Tidswell writes:] >I have some preference for a separate BFS partition > - we want a special list of sectors to load, lets not duplicate the work that > partitions already do in isolating and identifying sectors. I agree entirely, with one downside we shouldn't ignore: people *hate* messing around with disk partitions! I'd guess that less than half of the folks running VSTa would be doing so if it weren't capable of running on just about any IDE (and soon, SCSI) DOS system. Since neither DOS files nor disk partitions move (unless explicitly moved), I think a scheme which allowed the boot filesystem's sectors to be recorded should handle both handily. You can record the location of your BFS partition (very safe), or the location of your BFS filesystem-in-a-file (very easy, but relatively vulnerable). Andy From dave@humbug.demon.co.uk Wed Jan 12 07:50:01 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA21093; Wed, 12 Jan 94 07:50:00 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA05784; Wed, 12 Jan 94 07:51:04 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA27267(netkeeper.sj.nec.com ); Wed, 12 Jan 94 07:53:34 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA25480(archimedes.inoc.sj.nec.com ); Wed, 12 Jan 94 07:53:30 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA01167; Wed, 12 Jan 1994 08:18:04 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA20254 (8.6.4/IDA-1.5 for ); Wed, 12 Jan 1994 07:43:14 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa03843; 12 Jan 94 15:42 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pK7eF-000G1xC; Wed, 12 Jan 94 15:38 GMT Message-Id: From: Dave Hudson Subject: Joystick device server To: vsta@cisco.com Date: Wed, 12 Jan 1994 15:38:19 +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: 346 Status: OR I've just been working on an Alpha release joystick (PC games port) device server, but I need to check that it works on systems other than my VSTa target machine. Does anyone fancy trying it and letting me know what happens? I wrote it because I'll need it in a couple of months and it seemed an easy device to start with :-) Regards, Dave From eagle@zk3.dec.com Tue Jan 11 14:52:15 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12443; Tue, 11 Jan 94 14:52:14 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01971; Tue, 11 Jan 94 14:53:14 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18428(netkeeper.sj.nec.com ); Tue, 11 Jan 94 14:55:38 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA23509(archimedes.inoc.sj.nec.com ); Tue, 11 Jan 94 14:55:30 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id PAA01001; Tue, 11 Jan 1994 15:21:28 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by hubbub.cisco.com with SMTP id AA03893 (8.6.4/IDA-1.5 for ); Tue, 11 Jan 1994 09:29:52 -0800 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA05123; Tue, 11 Jan 1994 11:03:45 -0500 Received: by wasted.zk3.dec.com; id AA04899; Tue, 11 Jan 1994 11:03:04 -0500 Date: Tue, 11 Jan 1994 11:03:04 -0500 From: David Eagle USG Message-Id: <9401111603.AA04899@wasted.zk3.dec.com> Apparently-To: vsta@cisco.com Status: OR This message is in response to the brief discussion earlier about user IDs and what to do about remote users. I mentioned that I was opposed to the local system doing any sort of mapping of user IDs whatsoever. Andy's current thinking is that he would temporarily map them all to a default 'net' user ID. Here is some of my reasoning for being against this approach. There are at least three (3) different schemes for "networking" many computers together. I. Introduce a new set of commands: rlogin, telnet, rcp, ftp, rsh, rexec, etc. to allow users to log onto other systems, transfer data to/from other systems, and execute commands on other systems. II. Introduce a central administrator (usually a master system) or a globally agreed to administration procedure so that: all the files/resources on every system appear as though they are in a single (local) file system. This generally also means either global user IDs and/or replicated root directories. III. Introduce an enhancement to the pathname format to include "system" in the path. I prefer option III. (I also implemented it many years ago at a large computer company.) Option I does not give the user enough power, replicates commands the user is already familiar with (cp,sh) and introduces new commands which before were transparent and associated with physical devices (rlogin, telnet). Option II requires too much to be defined globally, does not give each system autonomy, and all too often it is incredibly difficult, if not impossible to move a computer from one network to another (pathname conflicts!!). Option III may be implemented by a simple modification to the "open" system call and thereafter passing system calls to a server task. This, in and of itself, can be a lot of overhead and a little slow. However: 1) Good support of intertask communication can solve this at the application level. Applications can send messages to other tasks which contain much higher level operations than "read,write,rewind". 2) ALL of the standard security and accounting automatically work. 3) In efficient implementations the interposition of an extra server task at each end is very small compared to the network and actual I/O overhead. If done right, Option III can also maintain the integrity of the local system's password file. The only user IDs that the local OS knows about are local user IDs. Anyone on a remote machine accessing my local files will have to present a valid local ID. This allows me to continue using my normal security and accounting procedures. Notice that when we turn this around it means that in order to access someone else's system we need to map our local user ID to a valid ID on the remote system. I envision this mapping being done by a special kernel task which maintains a special user ID mapping database. Users may add/modify/delete (my_local_userID,remote_system,remote_user_ID) entries at any time. I am strongly opposed to any compromises to local autonomy. For instance I feel it is a horrible security hole to recognize certain users on certain remote systems as privileged on my system. In fact, I think it is a big mistake to recognize the system from which a request originates at all. This is too easily falsified in a broadcast environment. The best security would entail having the initiator of a communications session 'prove' his identity by responding to an encrypted question. Public key encryption is a good tool for this. I also think it is a mistake to allow certain files to be 'exported to' or 'mounted by' only certain remote systems. Security must be based on user ID (and maybe other filters as well, such as restricting the access rights of an executable program when it is installed on the system. These restrictions would be in addition to any restrictions placed on the user executing the task.) When a remote request for access comes in, it must not matter from which remote system or network that request originates; instead, it only matters what local user ID is presented. This user ID must not be verified by passing the password across the net (too easily intercepted) but by an encrypted session initiation. After the user ID is verified a session key is exchanged that will be used for the encryption of all data sent during this communication session. (That key may be null if the user wishes. This could be the case if the communcation line is known to be secure or if the data being accessed is public.) Also, I don't want to forget accounting. It is important that remote users pay for their access to my system. This is handled by charging all their activity to the local user ID the remote user presents. My system is not a public asset. I must be able to control and charge for access, or else I do not really 'own' my own computer. From vandys@glare.cisco.com Fri Jan 14 09:18:18 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA18511; Fri, 14 Jan 94 09:18:17 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA14958; Fri, 14 Jan 94 09:19:20 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16340(netkeeper.sj.nec.com ); Fri, 14 Jan 94 09:22:03 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA02747(archimedes.inoc.sj.nec.com ); Fri, 14 Jan 94 09:21:54 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00437; Fri, 14 Jan 1994 09:37:56 -0800 Received: from localhost by glare.cisco.com with SMTP id AA29928 (5.67a/IDA-1.5 for ); Fri, 14 Jan 1994 09:03:47 -0800 Message-Id: <199401141703.AA29928@glare.cisco.com> To: Dave Hudson Cc: vsta@cisco.com Subject: Re: A couple of questions and some patches In-Reply-To: Your message of "Thu, 13 Jan 1994 11:41:30 GMT." Date: Fri, 14 Jan 1994 09:03:47 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >Am I right in thinking that the messages "FS_STAT" and "FS_WSTAT" replace >the UNIX "ioctl" function - I'm a bit short of information to go on here,... Yes, this is exactly what they replace. FS_STAT is used to retrieve the current information, and FS_WSTAT is used to modify one or more values. The stat code is written so it's easy to share the common chores, and add device-specific functions. The messages are structured as "name=value" sequences, separated by newlines. >Last question - is there any sort of spec for namer registration, ie what a >server registers itself as? (Or is it a bit of a free for all?). It's a bit of a free-for-all, unfortunately. Mouse is in srv/mouse, so perhaps srv/joystick would the ticket. Filesystems (as in, file storage on a non-volatile block-oriented device) are in fs/, and the block devices themselves go in disk/. The null block server could well be misplaced, since it's in the root of the nameserver hierarchy. >OK, now for the patches - whilst I was wandering around the code I spotted >what I guess are some typos (I'd guess that the changes are related to where >the code used to be). The changes are all one liners and I've tagged them >on below. >... Thanks! I'll apply them soon. Andy From vandys@glare.cisco.com Sat Jan 15 14:15:49 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00627; Sat, 15 Jan 94 14:15:47 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19599; Sat, 15 Jan 94 14:16:49 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18932(netkeeper.sj.nec.com ); Sat, 15 Jan 94 14:19:38 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05748(archimedes.inoc.sj.nec.com ); Sat, 15 Jan 94 14:19:32 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id OAA00099; Sat, 15 Jan 1994 14:42:54 -0800 Received: from localhost by glare.cisco.com with SMTP id AA02145 (5.67a/IDA-1.5 for ); Sat, 15 Jan 1994 14:09:07 -0800 Message-Id: <199401152209.AA02145@glare.cisco.com> To: vsta@cisco.com Subject: VSTa v1.2 available Date: Sat, 15 Jan 1994 14:09:06 -0800 From: Andrew Valencia Status: OR Version 1.2 of VSTa is available at ftp.cisco.com:vandys/vsta. This version includes the addition of an Adaptec 1542b/c SCSI disk driver, a COM1/2 serial port driver (plus enhancements to login so you can log in as another user over it), process debugging (kernel support, plus the simple debugger "adb"), and (as always) bug fixes. The DJGPP C compiler environment has changed again. The latest version has apparently switched to COFF executable format, which is completely incompatible with a.out. Thus, cross-compilation options are either to use an older DJGPP (shall I put my copy up on FTP?) or to cross compile from Linux or FreeBSD using the patches from rob@cygnus.com. I used DJGPP because at the time it was stable and it appeared that it would save me time. It has now become a liability, so I think it's time to move on. I will be shooting for the next release to support self-hosted compiles as the preferred method of building from source. Such a change requires a port of RCS to VSTa, some tedious file crunching to get rid of those stupid DOS line endings (\r\n), and probably some bug fixes to make it work well. For now, let's limp along for one more release. Please let me know if a copy of DJGPP would help. Regards, Andy vandys@cisco.com From vandys@glare.cisco.com Sat Jan 15 21:13:54 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA11076; Sat, 15 Jan 94 21:13:53 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20462; Sat, 15 Jan 94 21:14:55 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA21179(netkeeper.sj.nec.com ); Sat, 15 Jan 94 21:17:46 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05918(archimedes.inoc.sj.nec.com ); Sat, 15 Jan 94 21:17:40 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id VAA00131; Sat, 15 Jan 1994 21:38:19 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA06165 (8.6.4/IDA-1.5 for ); Sat, 15 Jan 1994 21:04:28 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA06529; Sat, 15 Jan 94 21:04:25 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA18083; Sat, 15 Jan 94 22:04:24 MST Message-Id: <9401160504.AA18083@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Sat, 15 Jan 1994 22:04:24 MST In-Reply-To: Andrew Valencia "VSTa v1.2 available" (Jan 15, 2:09pm) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , vsta@cisco.com Subject: Re: VSTa v1.2 available Status: OR From: Andrew Valencia Subject: VSTa v1.2 available > Version 1.2 of VSTa is available at ftp.cisco.com:vandys/vsta. This version Yippie! :-) > apparently switched to COFF executable format, which is completely > incompatible with a.out. Thus, cross-compilation options are either to use an Actually, there are good reasons for using COFF, the best one being that source level debugging of C++ programs works... > older DJGPP (shall I put my copy up on FTP?) or to cross compile from Linux or > FreeBSD using the patches from rob@cygnus.com. I'll try to squeeze out a source release shortly. GCC's source directory structure is being rearranged for a few days to support multi front ends in a cleaner manner. As soon as it all stablizes again, I'll do a release. I can do a release of all the binutils and ld first. Over the holiday, I added support for VSTa to the entire GNU tool chain... Libc still needs some work. > on. I will be shooting for the next release to support self-hosted compiles > as the preferred method of building from source. Such a change requires a This is my goal too. Adding support for VSTa to the GNU tools isn't as useful for cross development as it is for self-hosting. The main problem I see is it'd be best to use GCC's header files rather than VSTa's. The VSTa specific stuff would get it's own header files. There is support in the C library for platform specific header files. I will get any patches required back into the mainstream GNU sources. - rob - From vandys@glare.cisco.com Sat Jan 15 14:15:49 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00627; Sat, 15 Jan 94 14:15:47 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19599; Sat, 15 Jan 94 14:16:49 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18932(netkeeper.sj.nec.com ); Sat, 15 Jan 94 14:19:38 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05748(archimedes.inoc.sj.nec.com ); Sat, 15 Jan 94 14:19:32 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id OAA00099; Sat, 15 Jan 1994 14:42:54 -0800 Received: from localhost by glare.cisco.com with SMTP id AA02145 (5.67a/IDA-1.5 for ); Sat, 15 Jan 1994 14:09:07 -0800 Message-Id: <199401152209.AA02145@glare.cisco.com> To: vsta@cisco.com Subject: VSTa v1.2 available Date: Sat, 15 Jan 1994 14:09:06 -0800 From: Andrew Valencia Status: OR Version 1.2 of VSTa is available at ftp.cisco.com:vandys/vsta. This version includes the addition of an Adaptec 1542b/c SCSI disk driver, a COM1/2 serial port driver (plus enhancements to login so you can log in as another user over it), process debugging (kernel support, plus the simple debugger "adb"), and (as always) bug fixes. The DJGPP C compiler environment has changed again. The latest version has apparently switched to COFF executable format, which is completely incompatible with a.out. Thus, cross-compilation options are either to use an older DJGPP (shall I put my copy up on FTP?) or to cross compile from Linux or FreeBSD using the patches from rob@cygnus.com. I used DJGPP because at the time it was stable and it appeared that it would save me time. It has now become a liability, so I think it's time to move on. I will be shooting for the next release to support self-hosted compiles as the preferred method of building from source. Such a change requires a port of RCS to VSTa, some tedious file crunching to get rid of those stupid DOS line endings (\r\n), and probably some bug fixes to make it work well. For now, let's limp along for one more release. Please let me know if a copy of DJGPP would help. Regards, Andy vandys@cisco.com From vandys@glare.cisco.com Tue Jan 18 07:51:57 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08685; Tue, 18 Jan 94 07:51:56 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00992; Tue, 18 Jan 94 07:52:57 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA07752(netkeeper.sj.nec.com ); Tue, 18 Jan 94 07:56:03 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11020(archimedes.inoc.sj.nec.com ); Tue, 18 Jan 94 07:55:57 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00712; Tue, 18 Jan 1994 08:06:07 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA04294 (8.6.4/IDA-1.5 for ); Tue, 18 Jan 1994 07:32:30 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA26525; Tue, 18 Jan 1994 10:32:26 -0500 Date: Tue, 18 Jan 1994 10:32:26 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199401181532.AA26525@world.std.com> To: vsta@cisco.com Subject: SCSI server path Status: OR Hi, The VSTa 1.2 SCSI readme file has some information that is out of date :-(. Here's an update: 5. VSTa 1.2 /boot/boot.lst changes: Add the following before the 'DOS filesystem' section: # The SCSI/CAM driver ../srv/mach/scsi/cam Mike Larson From vandys@glare.cisco.com Tue Jan 18 09:03:24 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA25602; Tue, 18 Jan 94 09:03:23 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01184; Tue, 18 Jan 94 09:04:23 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA08400(netkeeper.sj.nec.com ); Tue, 18 Jan 94 09:07:29 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA11206(archimedes.inoc.sj.nec.com ); Tue, 18 Jan 94 09:07:27 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00720; Tue, 18 Jan 1994 09:24:11 -0800 Received: from cton.computone.com by hubbub.cisco.com with SMTP id AA07021 (8.6.4/IDA-1.5 for ); Tue, 18 Jan 1994 08:50:38 -0800 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0pMJdj-0006TQC; Tue, 18 Jan 94 11:50 EST Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Tue, 18 Jan 94 11:50 EST Message-Id: From: dave@computone.com (David Johnson) Subject: Ethernet driver status and network manager question To: vsta@cisco.com Date: Tue, 18 Jan 1994 11:50:33 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 602 Status: OR I have a basically working NE2000 driver for VSTa and I'm starting to map out the network manager to run on top of it. I want to get a upper-level design somewhat done before releasing the Ethernet driver so that I can stablize the interface. I noticed a number of references to uid mapping and such when dealing with a network connection. Obviously, these issues will have to be addressed once the network manager and name mapper are done. However, I would like to solicit comments on the network manager architecture and interface. Any suggestions or comments will be greatly appreciated. dave From vandys@glare.cisco.com Tue Jan 18 20:57:00 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA07799; Tue, 18 Jan 94 20:56:59 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03360; Tue, 18 Jan 94 20:57:59 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA10704(netkeeper.sj.nec.com ); Tue, 18 Jan 94 21:01:08 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13451(archimedes.inoc.sj.nec.com ); Tue, 18 Jan 94 21:01:06 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id VAA00776; Tue, 18 Jan 1994 21:07:32 -0800 Received: from localhost by glare.cisco.com with SMTP id AA14787 (5.67a/IDA-1.5 for ); Tue, 18 Jan 1994 20:33:59 -0800 Message-Id: <199401190433.AA14787@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: SCSI server path In-Reply-To: Your message of "Tue, 18 Jan 1994 10:32:26 EST." <199401181532.AA26525@world.std.com> Date: Tue, 18 Jan 1994 20:33:58 -0800 From: Andrew Valencia Status: OR [larz@world.std.com (Mike A Larson) writes:] > Add the following before the 'DOS filesystem' section: > # The SCSI/CAM driver > ../srv/mach/scsi/cam Of course, do this only if you have an Adaptec 1542b/c SCSI adaptor connecting your root disk! Andy From vandys@glare.cisco.com Fri Jan 21 01:18:48 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23397; Fri, 21 Jan 94 01:18:30 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA15370; Fri, 21 Jan 94 01:19:29 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00464(netkeeper.sj.nec.com ); Fri, 21 Jan 94 01:22:52 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA20854(archimedes.inoc.sj.nec.com ); Fri, 21 Jan 94 01:22:50 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id BAA01023; Fri, 21 Jan 1994 01:27:47 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA28603 (8.6.4/IDA-1.5 for ); Fri, 21 Jan 1994 00:54:52 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15199; 21 Jan 94 8:50 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pN8Cc-000DPUC; Thu, 20 Jan 94 22:50 GMT Message-Id: From: Dave Hudson Subject: Optimisation To: VSTa mailing list Date: Thu, 20 Jan 1994 22:50:13 +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: 416 Status: OR Has anyone looked into code optimisation for VSTa? I'm thinking of compiling the code with something like "-m486 -O2" optimisation. I'd be interested in any comments on what the results were if it's been tried. I would hope that when we get a self hosted build process that maybe this could be available as some global makefile parameter that could be overridden in individual blocks of code. Regards, Dave From vandys@glare.cisco.com Fri Jan 21 07:59:56 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA23387; Fri, 21 Jan 94 07:59:54 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16577; Fri, 21 Jan 94 08:00:53 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05155(netkeeper.sj.nec.com ); Fri, 21 Jan 94 08:04:18 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21349(archimedes.inoc.sj.nec.com ); Fri, 21 Jan 94 08:04:12 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA01125; Fri, 21 Jan 1994 08:01:09 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA12042 (8.6.4/IDA-1.5 for ); Fri, 21 Jan 1994 07:28:18 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA07290; Fri, 21 Jan 94 07:28:14 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA01370; Fri, 21 Jan 94 08:28:13 MST Message-Id: <9401211528.AA01370@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 21 Jan 1994 08:28:12 MST In-Reply-To: Dave Hudson "Optimisation" (Jan 20, 10:50pm) Reply-To: rob@cygnus.com X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Dave Hudson , VSTa mailing list Subject: Re: Optimisation Status: OR From: Dave Hudson Subject: Optimisation > Has anyone looked into code optimisation for VSTa? I'm thinking of > compiling the code with something like "-m486 -O2" optimisation. I'd be > interested in any comments on what the results were if it's been tried. I see no reason why it wouldn't work. If it doesn't, let me know. - rob - From vandys@glare.cisco.com Fri Jan 21 08:42:09 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03397; Fri, 21 Jan 94 08:42:07 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16709; Fri, 21 Jan 94 08:43:04 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05910(netkeeper.sj.nec.com ); Fri, 21 Jan 94 08:46:29 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA21517(archimedes.inoc.sj.nec.com ); Fri, 21 Jan 94 08:46:26 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id IAA01130; Fri, 21 Jan 1994 08:42:38 -0800 Received: from localhost by glare.cisco.com with SMTP id AA08030 (5.67a/IDA-1.5 for ); Fri, 21 Jan 1994 08:09:42 -0800 Message-Id: <199401211609.AA08030@glare.cisco.com> To: rob@cygnus.com Cc: Dave Hudson , VSTa mailing list Subject: Re: Optimisation In-Reply-To: Your message of "Fri, 21 Jan 1994 08:28:12 MST." <9401211528.AA01370@darkstar.cygnus.com> Date: Fri, 21 Jan 1994 08:09:41 -0800 From: Andrew Valencia Status: OR [rob@darkstar.cygnus.com (Rob Savoye) writes:] >> Has anyone looked into code optimisation for VSTa? I'm thinking of >> compiling the code with something like "-m486 -O2" optimisation. I'd be >> interested in any comments on what the results were if it's been tried. > I see no reason why it wouldn't work. If it doesn't, let me know. Although the VSTa kernel isn't written with any "volatile" declarations, I was pretty careful in positioning procedure calls to keep the compiler aware of the volatility of globals. The best example of this is the nop() call while idling. I have yet to hit a bug due to the optimizer. This includes GCC 1.X and 2.X with and without the optimizer. As Rob said, if you find one, let us know. Andy From vandys@glare.cisco.com Wed Jan 26 06:46:51 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA26498; Wed, 26 Jan 94 06:46:49 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10397; Wed, 26 Jan 94 06:47:44 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA06324(netkeeper.sj.nec.com ); Wed, 26 Jan 94 06:51:39 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA05649(archimedes.inoc.sj.nec.com ); Wed, 26 Jan 94 06:51:33 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id HAA00603; Wed, 26 Jan 1994 07:07:51 -0800 Received: from world.std.com by hubbub.cisco.com with SMTP id AA16331 (8.6.4/IDA-1.5 for ); Wed, 26 Jan 1994 06:35:37 -0800 Received: by world.std.com (5.65c/Spike-2.0) id AA09820; Wed, 26 Jan 1994 09:35:33 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199401261435.AA09820@world.std.com> Subject: timer notification To: vsta@cisco.com Date: Wed, 26 Jan 1994 09:35:32 -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: 384 Status: OR Hi, I'm about to implement request timeouts in the SCSI driver and I would get ideas on the best way to notify a process that a timer has expired. Notification could be either via a message or a signal. However, I don't see SIGALRM in . Is there a way, short of writing a timer server, of requesting the delivery periodic time based messages? Thanks. Mike Larson From vandys@glare.cisco.com Fri Jan 28 04:40:32 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20897; Fri, 28 Jan 94 04:40:32 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA20256; Fri, 28 Jan 94 04:41:26 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA25347(netkeeper.sj.nec.com ); Fri, 28 Jan 94 04:45:31 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA13310(archimedes.inoc.sj.nec.com ); Fri, 28 Jan 94 04:45:28 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA00874; Fri, 28 Jan 1994 04:47:25 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA29241 (8.6.4/IDA-1.5 for ); Fri, 28 Jan 1994 04:15:22 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa13778; 28 Jan 94 12:08 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pPs01-000G8QC; Fri, 28 Jan 94 12:08 GMT Message-Id: From: Dave Hudson Subject: Rewind missing? To: VSTa mailing list Date: Fri, 28 Jan 1994 12:08:32 +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: 429 Status: OR I'm doing some work with bfs at the moment. While I was modifying the makefiles for "cmd/mkfs.c" I found that there's an unreferenced symbol kicking around - there doesn't appear to be a "rewind" function in the 1.2 release. Was there one before and It's just not got through into 1.2 or am I missing some code? For the moment I guess I'll just replace the code with something like fseek(fd, 0, SEEK_SET); Regards, Dave From vandys@glare.cisco.com Wed Feb 2 01:50:50 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10861; Wed, 2 Feb 94 01:50:49 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA10813; Wed, 2 Feb 94 01:51:40 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA16286(netkeeper.sj.nec.com ); Wed, 2 Feb 94 01:56:09 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA26669(archimedes.inoc.sj.nec.com ); Wed, 2 Feb 94 01:56:05 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id BAA00170; Wed, 2 Feb 1994 01:54:39 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA24069 (8.6.4/IDA-1.5 for ); Wed, 2 Feb 1994 01:23:56 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15612; 2 Feb 94 9:22 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pRdm5-000F2BC; Wed, 2 Feb 94 09:21 GMT Message-Id: From: Dave Hudson Subject: Re: Rewind missing? To: Andrew Valencia Date: Wed, 2 Feb 1994 09:21:29 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199402012104.AA25478@glare.cisco.com> from "Andrew Valencia" at Feb 1, 94 01:04:53 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1250 Status: OR Andrew Valencia wrote: > > [Dave Hudson writes:] > > >I'm doing some work with bfs at the moment. While I was modifying the > >makefiles for "cmd/mkfs.c" I found that there's an unreferenced symbol > >kicking around - there doesn't appear to be a "rewind" function in the 1.2 > >release. > >For the moment I guess I'll just replace the code with something like > >fseek(fd, 0, SEEK_SET); > > In fact, maybe I should just add a #define of rewind to fseek(...). > But I'm curious how BFS compiled in the past? Maybe one of our massive > libc cleanups made it go away. Ah, making the bfs server didn't force the bfs cmd code to be built, and that's where the problem was. FWIW, I found a far more serious problem in the bfs block allocation code which makes me suspect that it's had some changes done to it without much testing - the problem caused every other write request to fail, so any file < 16 kbytes is fine, but anything bigger got messed up. I fixed this, but rather than send patches I'm waiting til I finish the changes I'm doing to support using the fs as a real boot filesystem (I'm trying to make the block management code track all free space, not just the space at the end of the filesystem). Dave From vandys@glare.cisco.com Wed Feb 2 11:38:42 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA19185; Wed, 2 Feb 94 11:38:41 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA12948; Wed, 2 Feb 94 11:39:31 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA18226(netkeeper.sj.nec.com ); Wed, 2 Feb 94 11:44:08 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA28067(archimedes.inoc.sj.nec.com ); Wed, 2 Feb 94 11:44:06 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00307; Wed, 2 Feb 1994 11:59:01 -0800 Received: from localhost by glare.cisco.com with SMTP id AA20677 (5.67a/IDA-1.5); Wed, 2 Feb 1994 11:05:12 -0800 Message-Id: <199402021905.AA20677@glare.cisco.com> To: Dave Hudson Cc: VSTa mailing list Subject: Re: Rewind missing? In-Reply-To: Your message of "Wed, 02 Feb 1994 09:21:29 GMT." Date: Wed, 02 Feb 1994 11:05:11 -0800 From: Andrew Valencia Status: OR [Dave Hudson writes:] >Ah, making the bfs server didn't force the bfs cmd code to be built, and >that's where the problem was. Actually, now it comes back. BFS has never really been run--I wrote it to test my concepts. The last time he ran was under a simulated VSTa messaging environment, running under DOS. mkfs was a djgpp program which built a BFS filesystem so I could have something to run my "filesystem" against while exercising VSTa messages manually. >FWIW, I found a far more serious problem in the bfs block allocation code >which makes me suspect that it's had some changes done to it without much >testing - the problem caused every other write request to fail, so any file >< 16 kbytes is fine, but anything bigger got messed up. Well, for a filesystem that has never really run, this doesn't surprise me. I'm surprised it even works to 16K! :-) On the other hand, much of it has been cannabalized for the other servers, and I have tried to move bug fixes back into BFS as I found them elsewhere. Andy From vandys@glare.cisco.com Tue Feb 1 13:04:57 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA02522; Tue, 1 Feb 94 13:04:56 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA08665; Tue, 1 Feb 94 13:05:44 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA05776(netkeeper.sj.nec.com ); Tue, 1 Feb 94 13:10:14 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA24280(archimedes.inoc.sj.nec.com ); Tue, 1 Feb 94 13:10:12 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id NAA01510; Tue, 1 Feb 1994 13:26:21 -0800 Received: from localhost by glare.cisco.com with SMTP id AA24981 (5.67a/IDA-1.5 for ); Tue, 1 Feb 1994 12:54:48 -0800 Message-Id: <199402012054.AA24981@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: timer notification In-Reply-To: Your message of "Wed, 26 Jan 1994 09:35:32 EST." <199401261435.AA09820@world.std.com> Date: Tue, 01 Feb 1994 12:54:47 -0800 From: Andrew Valencia Status: OR [larz@world.std.com (Mike A Larson) writes:] >I'm about to implement request timeouts in the SCSI driver and I would >get ideas on the best way to notify a process that a timer has expired. >Notification could be either via a message or a signal. However, I don't >see SIGALRM in . Is there a way, short of writing a timer >server, of requesting the delivery periodic time based messages? >Thanks. Yes, you fire up a thread and have him sleep() and then pop off a message to your main server port. The floppy driver does this, although he kills off the thread each time he wants to cancel the timeout interval. It would be much more efficient to just leave the thread around, and accept the periodic time messages. Andy From vandys@glare.cisco.com Thu Feb 3 06:46:17 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA00364; Thu, 3 Feb 94 06:46:16 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA16430; Thu, 3 Feb 94 06:47:06 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA03169(netkeeper.sj.nec.com ); Thu, 3 Feb 94 06:51:48 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00581(archimedes.inoc.sj.nec.com ); Thu, 3 Feb 94 06:51:45 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id HAA00497; Thu, 3 Feb 1994 07:10:45 -0800 Received: from amdahl.com by hubbub.cisco.com with SMTP id AA25175 (8.6.4/IDA-1.5 for ); Thu, 3 Feb 1994 06:40:17 -0800 Received: by amdahl.com (/\==/\ Smail #25.33) id ; Thu, 3 Feb 94 06:24 PST Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.16) id ; Thu, 3 Feb 94 06:22 PST Message-Id: From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: VSTa standalone boot loader status? To: vsta@cisco.com Date: Thu, 3 Feb 1994 06:22:41 -0800 (PST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 396 Status: OR I've got the GNU binutils for VSTa built under NetBSD-current, and I'd like to be able to boot VSTa without having to go through the DOS mire, if at all possible. So can anyone tell me what the status of the standalone boot loader is? Thanks, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From vandys@glare.cisco.com Thu Feb 3 11:37:37 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03110; Thu, 3 Feb 94 11:37:36 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01296; Thu, 3 Feb 94 11:38:26 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA04386(netkeeper.sj.nec.com ); Thu, 3 Feb 94 08:26:56 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA00747(archimedes.inoc.sj.nec.com ); Thu, 3 Feb 94 08:26:53 -0800 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00524; Thu, 3 Feb 1994 08:42:55 -0800 Received: from localhost by glare.cisco.com with SMTP id AA15405 (5.67a/IDA-1.5 for ); Thu, 3 Feb 1994 08:12:27 -0800 Message-Id: <199402031612.AA15405@glare.cisco.com> To: vsta@cisco.com Subject: VSTa mailing list archive Date: Thu, 03 Feb 1994 07:56:53 -0800 From: Andrew Valencia Status: OR Hello, As of January 14th, the VSTa mailing list is being automatically archived. Yes, hard to believe I hadn't done this before, but I guess I was too busy doing crazy VSTa stuff! :-) If any of you have an archive of stuff before this time (the more complete, the better) could you please send me a private note so I can see about putting together a complete and official archive of the list? I will put the final product out on FTP, as I'm sure it will be handy for new and old members alike. Thanks, Andy vandys@cisco.com From vandys@glare.cisco.com Thu Feb 3 11:36:59 1994 Return-Path: Received: from nec16.dcsd.sj.nec.com by buggy.dcsd.sj.nec.com (4.1/SMI-4.1) id AA03042; Thu, 3 Feb 94 11:36:58 PST Received: from netkeeper.sj.nec.com ([131.241.31.2]) by nec16.dcsd.sj.nec.com (4.1/SMI-4.1) id AA01243; Thu, 3 Feb 94 11:37:47 PST Received: by sj.nec.com (5.65/YDL1.7-930120.13) id AA00968(netkeeper.sj.nec.com ); Thu, 3 Feb 94 10:48:57 -0800 Received: by inoc.sj.nec.com (5.65/YDL1.7-930126.17) id AA01270(archimedes.inoc.sj.nec.com ); Thu, 3 Feb 94 10:48:55 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00534; Thu, 3 Feb 1994 11:03:33 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA08750 (8.6.4/IDA-1.5 for ); Thu, 3 Feb 1994 10:33:00 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa01744; 3 Feb 94 16:19 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pS6k1-000Ey2C; Thu, 3 Feb 94 16:17 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa standalone boot loader status? To: "Alistair G. Crooks" Date: Thu, 3 Feb 1994 16:17:16 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: from "Alistair G. Crooks" at Feb 3, 94 06:22:41 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: 1464 Status: OR > I've got the GNU binutils for VSTa built under NetBSD-current, and I'd > like to be able to boot VSTa without having to go through the DOS > mire, if at all possible. So can anyone tell me what the status of > the standalone boot loader is? I've written a boot loader that will allow you to boot from a floppy - this was done under Linux, but I'd guess it should be pretty easy to get it running under NetBSD. The loader reads a boot.lst file and builds a memory image. It then writes a boot sector, setup routine and the image to a floppy (just using dd - so nothing implementation specific). The only problem you may have is with the real mode assembler code - but only if you want to build it yourself. I currently use the as86/ld86 pair under Linux, and I don't know how bootstrap code is build under NetBSD or whether the assembler (or whatever) is compatible. You could just use the pre-assembled versions however, as they don't need to be rebuilt to change the boot servers, etc. Can you let me know how the real mode bootstrap works under NetBSD as I'd like to port some sort of tool to VSTa itself to do true self hosted building. I'm currently working on a new boot loader, using a modified bfs filesystem, but I wouldn't expect this to be finished for about a month yet. When it's finished it should be possible to boot fixed disks into either DOS or VSTa and hopefully Linux as well - I'll look at others as they arise. Regards, Dave