From vandys@glare.cisco.com Mon Feb 28 16:14:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA02746; Mon, 28 Feb 1994 16:14:05 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA18740 (8.6.4/IDA-1.5 for ); Mon, 28 Feb 1994 15:47:09 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id IAA10604; Tue, 1 Mar 1994 08:47:04 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA27517; Tue, 1 Mar 1994 08:47:02 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA27521; Tue, 1 Mar 1994 08:47:01 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00317; Tue, 1 Mar 94 08:46:13 +0900 Date: Tue, 1 Mar 94 08:46:13 +0900 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9402282346.AA00317@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Peter Holzer's message of Mon, 28 Feb 94 11:52:44 GMT-1:00 <9402281252.AA05239@junior.vmars.tuwien.ac.at> Subject: Runes >The only thing I expect from a locale is a way to change collating >sequences. This is important since accented characters are not in a >useful order for most (all?) languages. Lowercase/uppercase-mappings >are probably not locale-dependend. I don't care much for >currency-signs, decimal point/comma and similar things. This is the sticky part. The tables required for handling case conversion and the isascii(), isnumber() etc. macros take up 3-400k. Ideally, for each language, a collating table is also needed, and this will add even more overhead. I am focusing on just the basics for now: I/O, conversion to/from multibyte and runes, and will worry about this later. I think the hardest part is going to be regexp()... though filename globbing will be easy. These kind of changes require a lot of thought, and affect very many parts of the system, so I am not going to try to integrate them too deeply until I have more time. For now, if they help get bitblt and MADO running in a rune-aware way, I'll be happy. Another thing that requires a lot of thought is rune input. Asian language input by itself is easy, but the trick will be to come up with a system that allows any language to be input from the keyboard. I have some ideas now, but I'll not air them just yet. From vandys@glare.cisco.com Mon Feb 28 22:27:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id WAA02793; Mon, 28 Feb 1994 22:27:34 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA03050 (8.6.4/IDA-1.5 for ); Mon, 28 Feb 1994 22:00:31 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id PAA08283; Tue, 1 Mar 1994 15:00:12 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA16404; Tue, 1 Mar 1994 15:00:09 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA18472; Tue, 1 Mar 1994 15:00:07 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA03562; Tue, 1 Mar 94 00:59:18 -0500 Date: Tue, 1 Mar 94 00:59:18 -0500 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9403010559.AA03562@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com Subject: Virtual Consoles Well, Andy has been busy again :-) I think the port mapping functionality you described will be quite useful, but I'm slightly concerned about having the keyboard driver built into part of the console driver. Mightn't it be better to have downloadable keymaps, and use a special escape sequence to toggle betwen virtual screens. (ie. if the user presses ALT+SHIFT+F10, the escape sequence "ESC [ VC 10" might be generated)? This would be more flexible I think. I have been planning to rewrite the keyboard driver to handle downloadable maps for some time, and I have quite a lot of the design work done. Shall I code it up? From vandys@glare.cisco.com Tue Mar 1 03:01:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id DAA02810; Tue, 1 Mar 1994 03:01:33 -0800 Received: from irz301.inf.tu-dresden.de by hubbub.cisco.com with SMTP id AA08493 (8.6.4/IDA-1.5 for ); Tue, 1 Mar 1994 02:13:51 -0800 Received: by irz301.inf.tu-dresden.de (5.65/DEC-Ultrix/4.3) id AA29048; Tue, 1 Mar 1994 11:08:42 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA17508; Tue, 1 Mar 1994 11:07:46 +0100 Date: Tue, 1 Mar 1994 11:07:46 +0100 From: jw@ibch01.inf.tu-dresden.de (Wittenberger) Message-Id: <9403011007.AA17508@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: scheduling, real-time and so on There was a diskussion at the subject in the last days. Let me add my 2 cents. In my diploma I moved the complete scheduling out of the kernel, giving this task to a user-object. The kernel ony provides a very simple scheduler for system-boot and scheduler-exchange. The user-object for scheduling provides a {process, task, thread, whatever called} or a procedure to switch to / call up from the kernel for scheduling. This way gives me the opportuntiy to incorporate all kinds of scheduling into a system realising a very simple interface. (BTW The interface *can* be made very efficient, if the kernel maps the adressspace (o parts of it) of this object into it's own - paying the price of security.) Unfortunatly I did this on a different System and I have (at this time) not the experience in VSTa nor the time to repeat it for VSTa. But, why not to go this way in VSTa in the future? So far the first cent, now the second: Let me strongly agree with Andy to call for 1: keep the kernel micro 2: keep the code well structured and clean! For this goals we may pay at other things. Here (short) my experience : The system used in my diploma (BirliX, sure you don't know) was similar to VSTa in some aspects, it has message-based process-comunication (network transparent, at user-level you only see RPC's), it has multi-thread-support (I still don't know, what it is good for, even in VSTa) and monitors for mutex, it has VM, segments, persistent memory, it is still "real" micro-kernel as all I/O and stuff like that is implemented by user-objects. The system emulates Unix an runs X (therefor some kernel-extensions where needed). It far portable cause most of the code is system-independent and modula-2. I think with some development VSTa would come to this point. But the work in my diploma didn't come over the stage of debugging for some reasons: 1st: the "micro"-kernel-system, providing all the mentioned things compiled at the sun 3/80 gets about 2 Meg. 2nd: even when there was a "strong structured" language used and only a hand full people worked on it, applying some "good" coding-rules, the code couldn't kept clean. (Therefor I appended a simple grep-output from the source-directory to my diploma: grep hack *.m[di] about 3 pages...) 3rd: the system finaly suffered from a lot of side-effects 4th: nobody would ever know all parts of the system. But if there are thousend ways to do the same thing, it will be done in hundred ways. And they *will* assume about each other to go the same way (even if they shouldn't do so). And they won't work together. So I hope even VSTa can become simplyfied. Don't add functionality to the kernel! Add simple clear interfaces, if needed and move funtionality out. It may cost some cpu-ticks, but the cpu's are really fast, software-development is far to slow, because the systems are to complex. ----------------------------------------------------------------------------- Joerg Wittenberger email: jw@ibch50.inf.tu-dresden.de Rietzstr. 32b jw6@mail.inf.tu-dresden.de 01139 Dresden Germany --- PGP PUBLIC KEY avialable on request or by finger --- From vandys@glare.cisco.com Tue Mar 1 04:53:52 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA02819; Tue, 1 Mar 1994 04:53:49 -0800 Received: from idefix.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA17116 (8.6.4/IDA-1.5 for ); Tue, 1 Mar 1994 04:26:48 -0800 Received: by idefix.vmars.tuwien.ac.at id AA01207 (5.64+/IDA-1.3.4 for vsta@cisco.com); Tue, 1 Mar 94 13:26:23 +0100 From: Peter Holzer Message-Id: <9403011226.AA01207@idefix.vmars.tuwien.ac.at> Subject: Re: Runes To: vsta@cisco.com Date: Tue, 1 Mar 94 13:26:21 MET In-Reply-To: <9402282346.AA00317@europa.nsis.cl.nec.co.jp>; from "Gavin Thomas Nicol" at Mar 1, 94 8:46 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Gavin Thomas Nicol) wrote: > > >The only thing I expect from a locale is a way to change collating > >sequences. This is important since accented characters are not in a > >useful order for most (all?) languages. Lowercase/uppercase-mappings > >are probably not locale-dependend. I don't care much for > >currency-signs, decimal point/comma and similar things. > > This is the sticky part. The tables required for handling case > conversion and the isascii(), isnumber() etc. macros take up 3-400k. > Ideally, for each language, a collating table is also needed, and this > will add even more overhead. 4.4 BSD uses files to store information for the is*() macros. Each line describes a block of characters, so these files are usually small. I don't know what they do about collating tables. These are really tricky, since there is often no one-to-one mapping. For example, in German Umlaut-A used to be treated just like A, except if two words were completely identical except for the umlaut, the one with the umlaut came after the one without umlaut (Fortunately they have changed the rule. umlaut-A is now a letter between A and B). > I am focusing on just the basics for now: I/O, conversion to/from > multibyte and runes, and will worry about this later. I think the > hardest part is going to be regexp()... though filename globbing will > be easy. This will probably be enough for now. The trickier parts can be added as needed. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Tue Mar 1 05:08:20 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id FAA02823; Tue, 1 Mar 1994 05:08:18 -0800 Received: from idefix.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA17501 (8.6.4/IDA-1.5 for ); Tue, 1 Mar 1994 04:41:08 -0800 Received: by idefix.vmars.tuwien.ac.at id AA01285 (5.64+/IDA-1.3.4 for vsta@cisco.com); Tue, 1 Mar 94 13:40:44 +0100 From: Peter Holzer Message-Id: <9403011240.AA01285@idefix.vmars.tuwien.ac.at> Subject: Re: Virtual Consoles To: vsta@cisco.com Date: Tue, 1 Mar 94 13:40:41 MET In-Reply-To: <9403010559.AA03562@europa.nsis.cl.nec.co.jp>; from "Gavin Thomas Nicol" at Mar 1, 94 12:59 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Gavin Thomas Nicol) wrote: > > Well, Andy has been busy again :-) > > I think the port mapping functionality you described will be quite > useful, but I'm slightly concerned about having the keyboard driver > built into part of the console driver. Mightn't it be better to have > downloadable keymaps, and use a special escape sequence to toggle > betwen virtual screens. (ie. if the user presses ALT+SHIFT+F10, the > escape sequence "ESC [ VC 10" might be generated)? This would be more > flexible I think. I agree (Although I would like the escape sequence to have the same format as the other sequences, so it would have to be ESC [ 1 0 V (or something like this, V may be already in use)). > > I have been planning to rewrite the keyboard driver to handle > downloadable maps for some time, and I have quite a lot of the design > work done. Shall I code it up? I have recently rewritten the Minix console driver to handle downloadable keymaps. Actually, this is the third time I have done this. The current version allows up to eight modifier keys, strings up to 15 bytes per key and numeric entry of codes in base 10 (like alt+numeric keypad in DOS) and 16. I am not yet quite happy with some internals: The translation table could be smaller and faster to search, and removing keymappings is tricky. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Sun Mar 6 14:16:29 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id OAA08476; Sun, 6 Mar 1994 14:16:24 -0800 Received: from zapranoth.mcs.kent.edu (ogion.mcs.kent.edu) by hubbub.cisco.com with SMTP id AA17950 (8.6.4/IDA-1.5 for ); Sun, 6 Mar 1994 13:50:00 -0800 Received: from localhost.ARPA by zapranoth.mcs.kent.edu (930416.SGI/92.09.25) id AA04420; Sun, 6 Mar 94 16:48:37 -0500 Message-Id: <9403062148.AA04420@zapranoth.mcs.kent.edu> From: sjc@mcs.kent.edu (Steve Chapin) To: vsta list Zevon-Of-The-Day: Lawyers, Guns and Money Subject: VSTa compiled under Linux? Date: Sun, 06 Mar 1994 16:48:37 -0500 Sender: sjc@mcs.kent.edu Well, my PCs finally arrived. I think the university purchasing folks use turtles as couriers. I'm bringing up Linux, with the intent of compiling VSTa for downloading onto a backend machine and testing. Has anyone done anything similar, specifically: 1) compiled VSTa under Linux 2) rigged up downloading over a network for backend machines 3) configured VSTa to treat the serial port as the console (I haven't brought VSTa up yet, so I don't know what it uses for the default)? I've done similar stuff for XINU when I was at Purdue, so I have a pretty good idea how to go about it. However, I'm always happy to save effort, so if someone else has already done something similar, please let me know. sc -- From vandys@glare.cisco.com Mon Mar 7 09:56:12 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00083; Mon, 7 Mar 1994 09:56:10 -0800 Received: from localhost by glare.cisco.com with SMTP id AA15849 (5.67a/IDA-1.5 for ); Mon, 7 Mar 1994 09:31:19 -0800 Message-Id: <199403071731.AA15849@glare.cisco.com> To: dave@humbug.demon.co.uk, larz@world.std.com Cc: vsta@cisco.com Subject: Re: Patches to wd and libdpart In-Reply-To: Your message of "Sun, 06 Mar 1994 22:43:14 GMT." Date: Mon, 07 Mar 1994 09:31:18 -0800 From: Andrew Valencia Ok, I have new BFS, dpart, and wd patches incorporated. I did a fix for the kernel debugger screen swapping this weekend, but mostly I did work on cisco stuff (bleh, REAL work) and tweaks to the CPU scheduler. Found an out-and-out bug which explains why a CPU-bound process doesn't timeslice very nicely, plus did some optimizations which appear to help a little. One more pass and I'll add the "cheated" queue, which will help sporadically run processes by giving them preference to complete their CPU quanta over CPU hogs which are always grinding through all of theirs. I also code-read the "real-time" parts of the scheduler, and will be tearing out the current scheme in favor of a one which co-exists better with the main hierarchical scheduler. I think I can set it up so that not only can you have a full range of real-time priorities in a global system, but you can also have threads and processes schedule among themselves in a real-time fashion while working from a lower node in the scheduling tree. So you can have a group of threads which receives, say, 30% of the CPU from the system, but then run among themselves in a non-degrading, strictly prioritized order. Not sure if this is useful in practice, but it falls out for free so I may as well play with it. Regards, Andy From vandys@glare.cisco.com Wed Mar 9 09:37:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00397; Wed, 9 Mar 1994 09:37:26 -0800 Received: from ds1.gl.umbc.edu by hubbub.cisco.com with SMTP id AA25127 (8.6.4/IDA-1.5 for ); Wed, 9 Mar 1994 09:12:53 -0800 Received: from rpc44.gl.umbc.edu (vijay@rpc44.gl.umbc.edu [130.85.60.64]) by ds1.gl.umbc.edu (8.6.5/8.6.5) with ESMTP id MAA24061 for ; Wed, 9 Mar 1994 12:12:56 -0500 Received: from localhost (vijay@localhost) by rpc44.gl.umbc.edu (8.6.5/8.6.5) id MAA00696; Wed, 9 Mar 1994 12:12:50 -0500 Date: Wed, 9 Mar 1994 12:12:49 -0500 (EST) From: Vijay Gill Subject: Why doesn't vSTA switch to 9p? To: vsta list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the paper, it is mentioned that Andy could not go with 9p because the spec was not available. It is now. Any overwhelming reasons for not switching to 9p? Vijay Gill |The (paying) customer is always right. wrath@cs.umbc.edu | - Piercarlo Grandi vijay@gl.umbc.edu | Eagles may soar, but weasels don't get These are my opinions only. | sucked into jet engines. From vandys@glare.cisco.com Wed Mar 9 11:58:43 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id LAA00671; Wed, 9 Mar 1994 11:58:41 -0800 Received: from localhost by glare.cisco.com with SMTP id AA04533 (5.67a/IDA-1.5 for ); Wed, 9 Mar 1994 11:34:32 -0800 Message-Id: <199403091934.AA04533@glare.cisco.com> To: Vijay Gill Cc: vsta list Subject: Re: Why doesn't VSTa switch to 9p? In-Reply-To: Your message of "Wed, 09 Mar 1994 12:12:49 EST." Date: Wed, 09 Mar 1994 11:34:32 -0800 From: Andrew Valencia [Vijay Gill writes:] >In the paper, it is mentioned that Andy could not go with 9p because the >spec was not available. It is now. Any overwhelming reasons for not >switching to 9p? Well, all that code we now have. Plus some no doubt subtle semantic incompatibilities. Plus, I'm still a little leary about getting into hot water with the AT&T legal machine. Yeah, they published it, but right now VSTa is distinct, technically, from Plan9 top to bottom. I had become familiar with some concepts due to their papers. But switching over to an exact clone of an internal interface leaves me with a distinct feeling of unease. This is just my own opinion. Andy From vandys@glare.cisco.com Wed Mar 9 19:47:29 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id TAA00713; Wed, 9 Mar 1994 19:47:28 -0800 Received: from localhost by glare.cisco.com with SMTP id AA10230 (5.67a/IDA-1.5 for ); Wed, 9 Mar 1994 19:23:21 -0800 Message-Id: <199403100323.AA10230@glare.cisco.com> To: vsta@cisco.com Subject: A filesystem philosophy question Date: Wed, 09 Mar 1994 19:23:20 -0800 From: Andrew Valencia In porting ar(1), I ran into quite a neat little problem. ar(1) uses rename(2) to change the name of a file. How do you do that in VSTa? Recall that there is no global namespace. So simply telling "the" filesystem about the two paths is nowhere near good enough. If, in fact, both files are in the same filesystem, I guess you could trim off everything except the filesystem-relative part and pass that. But this doesn't seem like a very good solution. In fact, what I'm tending towards is a routine where you open (for update, to establish your ability to write it) the existing file, and then create the new file (with whatever policy you need, such as error if it already exists, or truncate, this is all in the C library). Then the tricky part--wstat() a message to the new file, indicating that this file wants to *swap* contents with another file. You either send a secret number (to stymie a 3rd party trying to intercept the file) or get one back, and then you wstat() with this on the original file. On success, the two files have had their contents swapped. On failure, nothing's changed. On success, you finish by removing the (now empty) original file. Of course, the library version of rename() falls back to a bulk data copy if it can't do this. This is compatible with old filesystems (who won't recognize the new wstat() message) and also with cross-filesystem renames. What do you think? On another topic, the next version will be out in a couple weeks. It'll have the new multi-screen support, scheduler optimizations, and a lot of cleanup in drivers as they convert to syslog(). Robert Mayer supplied some patches to make the cursor keys emulate a VTXX, Dave Hudson has cleaned up the handling of disk partitions in WD, moving the common code into a library. Mike Larson's has converted his SCSI disk driver to use this as well. I'd like to finish porting BSD's "ash" Bourne shell clone, but we'll see. I've finally added emulation, though, which should help in your porting efforts in general. Regards, Andy From vandys@glare.cisco.com Wed Mar 9 20:56:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id UAA00763; Wed, 9 Mar 1994 20:56:06 -0800 Received: from TYO.gate.nec.co.jp by hubbub.cisco.com with SMTP id AA00110 (8.6.4/IDA-1.5 for ); Wed, 9 Mar 1994 20:31:52 -0800 Received: from mailsv.nec.co.jp by TYO.gate.nec.co.jp (8.6.5/6.4J.6-TYO_gate) id NAA21001; Thu, 10 Mar 1994 13:31:46 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA21937; Thu, 10 Mar 1994 13:31:12 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA19120; Thu, 10 Mar 1994 13:31:08 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00991; Wed, 9 Mar 94 23:30:11 -0500 Date: Wed, 9 Mar 94 23:30:11 -0500 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9403100430.AA00991@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Andrew Valencia's message of Wed, 09 Mar 1994 19:23:20 -0800 <199403100323.AA10230@glare.cisco.com> Subject: A filesystem philosophy question >In porting ar(1), I ran into quite a neat little problem. ar(1) uses >rename(2) to change the name of a file. How do you do that in VSTa? Hmm. It's a sticky problem, and actually, it's not just the file system we need to think about. Ideally, we want a scheme that can name an object in VSTa, and let that object be renamed, moved, deleted, etc. etc. Things like processes, ports, etc. could be candidates for such operations. I have a feeling that we should define some protocol used for such actions; it would be very useful for other things besides file systems (for example, having named ports etc). Such a change might require quite a lot of work though... depending on how far we want to take the idea of "object". From vandys@glare.cisco.com Thu Mar 10 09:29:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00890; Thu, 10 Mar 1994 09:29:01 -0800 Received: from news.std.com by hubbub.cisco.com with SMTP id AA26496 (8.6.4/IDA-1.5 for ); Thu, 10 Mar 1994 09:04:57 -0800 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA24873; Thu, 10 Mar 1994 12:04:48 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18068; Thu, 10 Mar 1994 12:04:35 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199403101704.AA18068@world.std.com> Subject: Re: A filesystem philosophy question To: vsta@cisco.com Date: Thu, 10 Mar 1994 12:04:34 -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: 915 [Andrew Valencia writes] > In porting ar(1), I ran into quite a neat little problem. ar(1) uses > rename(2) to change the name of a file. How do you do that in VSTa? > > Recall that there is no global namespace. So simply telling "the" > filesystem about the two paths is nowhere near good enough. If, in fact, > both files are in the same filesystem, I guess you could trim off everything > except the filesystem-relative part and pass that. But this doesn't seem > like a very good solution. ... Why isn't this a very good solution for intra-filesystem renames (ie, renames within the same filesystem partition or name space)? As a matter of fact, why isn't this the best solution for the case where both the source and destination files reside in the same directory (eg, mv foo bar) and the rename consists of simply changing the file's directory name entry(s)? Mike Larson From vandys@glare.cisco.com Thu Mar 10 09:51:44 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00894; Thu, 10 Mar 1994 09:51:42 -0800 Received: from localhost by glare.cisco.com with SMTP id AA06491 (5.67a/IDA-1.5 for ); Thu, 10 Mar 1994 09:27:37 -0800 Message-Id: <199403101727.AA06491@glare.cisco.com> To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: A filesystem philosophy question In-Reply-To: Your message of "Thu, 10 Mar 1994 12:04:34 EST." <199403101704.AA18068@world.std.com> Date: Thu, 10 Mar 1994 09:27:36 -0800 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >> If, in fact, >> both files are in the same filesystem, I guess you could trim off everything >> except the filesystem-relative part and pass that. But this doesn't seem >> like a very good solution. ... >Why isn't this a very good solution for intra-filesystem renames (ie, >renames within the same filesystem partition or name space)? As a matter >of fact, why isn't this the best solution for the case where both >the source and destination files reside in the same directory (eg, >mv foo bar) and the rename consists of simply changing the file's >directory name entry(s)? Recall that the path lookup loop is not encoded in the server. Why add an entire new mechanism to servers to solve an edge case? But this *has* brought to mind an issue I hadn't considered. What to do about filesystems where there is a many->one relationship of directory entries to files? You'd either have to record the path in the open file state (talk about new mechanism) or something equally expensive. Hmmm... if we *did* pass two filesystem-relative paths, and I *did* add the code to deal with this, then there's another optimization I've been pondering which fits with this: In the current system, I use the Plan9 technique of walking the pathname one element at a time. But once you walk *into* a VSTa filesystem, you'll never walk back out--so why not pass all that path into the server and save the cost of the context switches needed for each element traversal? The code needed to deal with these paths for a rename() is pretty much the same code needed to implement this optimization. Interesting.... Oh, and since we're rambling around this morning, another optimization. I notice that many filesystems encode some file state in the directory structure. So for directory traversal tools, the needed information may be available to them simply for the cost of walking the directory. However, the UNIX architecture ignores this, with the result that you have to actually stat() the file to hear anything about it. What I've been thinking is that the FS_READ of a directory should perhaps be allowed to pass back extra information which it has available anyway. So currently an FS_READ of a directory gets: entry1 entry2 entry3 and instead a filesystem would be allowed to pass back "freebies": entry1 type=f size=1234 atime=6463537 mtime=6463433 ... Of course, this is useless to POSIX utilities, but I'm thinking that it might still be worth it to optimize the case of ls, and perhaps a couple others. In the common case (ls -CF, for instance) you would never have to do that extra FS_STAT message to pick up the file type. Andy From vandys@glare.cisco.com Thu Mar 10 10:29:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id KAA00904; Thu, 10 Mar 1994 10:29:24 -0800 Received: from quasi.vmars.tuwien.ac.at by hubbub.cisco.com with SMTP id AA29392 (8.6.4/IDA-1.5 for ); Thu, 10 Mar 1994 10:05:12 -0800 Received: by quasi.vmars.tuwien.ac.at id AA12871 (5.64+/IDA-1.3.4 for vsta@cisco.com); Thu, 10 Mar 94 19:04:42 +0100 From: Peter Holzer Message-Id: <9403101804.AA12871@quasi.vmars.tuwien.ac.at> Subject: Re: A filesystem philosophy question To: vsta@cisco.com Date: Thu, 10 Mar 94 19:04:41 MET In-Reply-To: <199403101727.AA06491@glare.cisco.com>; from "Andrew Valencia" at Mar 10, 94 9:27 am Reply-To: hp@vmars.vmars.tuwien.ac.at X-Return-Receipt-To: hp@vmars.tuwien.ac.at X-Mailer: ELM [version 2.3 PL5] You (Andrew Valencia) wrote: > > [larz@world.std.com (Mike A Larson) writes:] > > >> If, in fact, > >> both files are in the same filesystem, I guess you could trim off everything > >> except the filesystem-relative part and pass that. But this doesn't seem > >> like a very good solution. ... > >Why isn't this a very good solution for intra-filesystem renames (ie, > >renames within the same filesystem partition or name space)? As a matter > >of fact, why isn't this the best solution for the case where both > >the source and destination files reside in the same directory (eg, > >mv foo bar) and the rename consists of simply changing the file's > >directory name entry(s)? > > Recall that the path lookup loop is not encoded in the server. Why add > an entire new mechanism to servers to solve an edge case? > > But this *has* brought to mind an issue I hadn't considered. What to > do about filesystems where there is a many->one relationship of directory > entries to files? You'd either have to record the path in the open file > state (talk about new mechanism) or something equally expensive. No. The logical way to implement a rename is in my opinion the following: Open the directory where the file (or whatever) is. Open the directory where it should be. Call the rename function with the two open directories and the old and the new name as parameters. This works on file systems with several links per file as well. hp -- _ | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems |_|_) |------------------------------------------------------------------------ | | | It's not what we don't know that gets us into trouble, it's __/ | what we know that ain't so. -- Will Rogers From vandys@glare.cisco.com Fri Mar 11 21:31:16 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id VAA01716; Fri, 11 Mar 1994 21:31:10 -0800 Received: from venus.net.ncu.edu.tw by hubbub.cisco.com with SMTP id AA25223 (8.6.4/IDA-1.5 for ); Fri, 11 Mar 1994 21:07:10 -0800 Received: from localhost by venus.net.ncu.edu.tw (8.6.3/8.6.4) id NAA00617; Sat, 12 Mar 1994 13:05:47 +0800 Date: Sat, 12 Mar 1994 13:05:47 +0800 From: root@venus.net.ncu.edu.tw (F.M. Hsieh) Message-Id: <199403120505.NAA00617@venus.net.ncu.edu.tw> To: vsta@cisco.com Subject: about vSTA... pls send me some info. about vSTA. From vandys@glare.cisco.com Fri Mar 11 21:39:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id VAA01725; Fri, 11 Mar 1994 21:39:07 -0800 Received: from venus.net.ncu.edu.tw by hubbub.cisco.com with SMTP id AA25396 (8.6.4/IDA-1.5 for ); Fri, 11 Mar 1994 21:15:08 -0800 Received: from localhost by venus.net.ncu.edu.tw (8.6.3/8.6.4) id NAA00614; Sat, 12 Mar 1994 13:03:34 +0800 Date: Sat, 12 Mar 1994 13:03:34 +0800 From: root@venus.net.ncu.edu.tw (F.M. Hsieh) Message-Id: <199403120503.NAA00614@venus.net.ncu.edu.tw> To: vsta@cisco.com Subject: about vSTA... pls send me some info. about vSTA. From vandys@glare.cisco.com Sun Mar 13 13:19:46 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id MAA00126; Sun, 13 Mar 1994 12:45:24 -0800 Received: from email.univie.ac.at by hubbub.cisco.com with SMTP id AA14461 (8.6.4/IDA-1.5 for ); Sun, 13 Mar 1994 12:22:05 -0800 Received: from sophie.par.univie.ac.at by email.univie.ac.at with SMTP (PP) id <05789-0@email.univie.ac.at>; Sun, 13 Mar 1994 21:21:52 +0100 Received: from jessica.univie.ac.at by par.univie.ac.at (4.1/SMI-4.3.12) id AA11577; Sun, 13 Mar 94 21:20:14 +0100 Date: Sun, 13 Mar 94 21:20:14 +0100 From: robert@par.univie.ac.at (Robert Mayer - Student) Message-Id: <9403132020.AA11577@par.univie.ac.at> To: vsta@cisco.com Subject: IRQ handling A few days ago I started to write a printer server for VSTa. I wrote a little test program, but it didn't receive any interrupt messages. After a little bit of kernel reading I found the reason: IRQ 7 is disabled by pointing it's vector to a routine that simply IRETs (in the comment it says that there were problems with stray interrupts). I commented out the line that disables IRQ 7 and now my program gets the interrupt messages. The printer server is far from being finished, but I may have found a bug: In os/mach/trap.c line 597 there is a call to hardclock() without parameters. The function hardclock lives in os/kern/xclock.c and it is implemented like this: void hardclock(uint x) { struct trapframe *f = (struct trapframe *)&x; . . . I think in trap.c it should say: hardclock(f); and in xclock.c it should say: void hardclock(struct trapframe *f) { /* struct trapframe *f = (struct trapframe *)&x; */ . . . I don't know if this really is a bug, because everything works fine, but it sure looks strange to me. Greetings Robert From vandys@glare.cisco.com Sun Mar 13 13:22:32 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00072; Sun, 13 Mar 1994 13:22:31 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.5/8.6.5) with SMTP id MAA17097; Sun, 13 Mar 1994 12:47:30 -0800 Message-Id: <199403132047.MAA17097@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: robert@par.univie.ac.at (Robert Mayer - Student) cc: vsta@cisco.com Subject: Re: IRQ handling In-reply-to: Your message of "Sun, 13 Mar 1994 21:20:14 +0100." <9403132020.AA11577@par.univie.ac.at> Date: Sun, 13 Mar 1994 12:47:30 -0800 From: Andrew Valencia [robert@par.univie.ac.at (Robert Mayer - Student) writes:] >... >After a little bit of kernel reading I found the reason: IRQ 7 is >disabled by pointing it's vector to a routine that simply IRETs (in the >comment it says that there were problems with stray interrupts). Yes, I'm afraid you have headed down the Wrong Path. Not only does IRQ 7 provide interrupts spuriously, it also does not deliver printer interrupts reliably. This is why 386BSD's (and, I believe, Linux's and FreeBSD's) LP drivers usually are the so-called "interruptless" versions. they use timing loops and polling instead. Let me know if you would like a copy to examine. >In os/mach/trap.c line 597 there is a call to hardclock() without parameters. >The function hardclock lives in os/kern/xclock.c and it is implemented like >this: >void hardclock(uint x) >{ > struct trapframe *f = (struct trapframe *)&x; >... >I don't know if this really is a bug, because everything works fine, but it >sure looks strange to me. The 386 places the internal state on the stack, and then starts running at our interrupt handling code. So, at the place where parameter "x" *would* have been, if it had been called from C, is a stack frame with the format described by "struct trapframe". So when you set a pointer to where a parameter *would* have been, you are saying that you *know* the format of the frame at that place, and the format is "struct trapframe". I might have written it as: void hardclock(struct trapframe f) { } But C has a lot of latitude in how it implements call-by-value for passing of structures, and I wanted to avoid this gray area entirely. Regards, Andy From vandys@glare.cisco.com Sun Mar 13 16:25:13 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00064; Sun, 13 Mar 1994 16:25:12 -0800 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA17346 (8.6.4/IDA-1.5 for ); Sun, 13 Mar 1994 15:40:19 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa00497; 13 Mar 94 22:56 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pfytj-00037YC; Sun, 13 Mar 94 22:44 GMT Message-Id: From: Dave Hudson Subject: Re: IRQ handling To: Andrew Valencia Date: Sun, 13 Mar 1994 22:44:39 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199403132047.MAA17097@glare.cisco.com> from "Andrew Valencia" at Mar 13, 94 12:47:30 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: 1994 > >... > >After a little bit of kernel reading I found the reason: IRQ 7 is > >disabled by pointing it's vector to a routine that simply IRETs (in the > >comment it says that there were problems with stray interrupts). > > Yes, I'm afraid you have headed down the Wrong Path. Not only does IRQ 7 > provide interrupts spuriously, it also does not deliver printer interrupts > reliably. This is why 386BSD's (and, I believe, Linux's and FreeBSD's) LP > drivers usually are the so-called "interruptless" versions. they use timing > loops and polling instead. I think this tends to depend on the hardware you have available - a couple of years back I came across this problem and wrote a test program that looked for the spurious interrupts. I found that only one type of machine I had available showed the problem, whereas all of the other types I used never showed anything. The first type of system also became notorious for causing problems with a lot of SoundBlaster type cards which default to using IRQ7 as the spurious interrupts used to upset them! The Linux code (last time I looked) can support an interrupt driven version of the lp code (and is apparently much faster this way), but defaults to using polled mode. There's a util to kick it into interrupt driven mode. When I asked Linus Torvalds about this last year, his response was that autoprobing for IRQs on some AT bus systems resulted in crashes, and that in this sort of case Linux would default to the safest possible behaviour (the serial code which also used to autoprobe now doesn't). It would be nice if there was a way of getting an IRQ based version running as well as a polled version (an ideal case for a "stat" field perhaps?). Thinking about it, I'm pretty sure that IRQ7 (and IRQ5 for lp2) must be pretty reliable on a lot of systems, otherwise there'd be no chance of getting PLIP links to work. I suspect that if Tommy Thorn's reading this he can probably give some more details. Regards, Dave From vandys@glare.cisco.com Sun Mar 13 16:27:51 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00067; Sun, 13 Mar 1994 16:27:50 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.5/8.6.5) with SMTP id QAA18752; Sun, 13 Mar 1994 16:04:38 -0800 Message-Id: <199403140004.QAA18752@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson cc: VSTa mailing list Subject: Re: IRQ handling In-reply-to: Your message of "Sun, 13 Mar 1994 22:44:39 GMT." Date: Sun, 13 Mar 1994 16:04:37 -0800 From: Andrew Valencia [Dave Hudson writes:] >I think this tends to depend on the hardware you have available - a couple >of years back I came across this problem and wrote a test program that >looked for the spurious interrupts. I've been in communication with the FreeBSD and NetBSD folks, and all of us have seen this problem across a wide range of systems. >It would be nice if there was a way of getting an IRQ based version running >as well as a polled version (an ideal case for a "stat" field perhaps?). The nice thing about the iret stub is that I minimize the cost of taking these useless interrupts. Having to save all the state needed to go up into C source code would make this long-lived misfeature cost even more CPU cycles. >Thinking about it, I'm pretty sure that IRQ7 (and IRQ5 for lp2) must be >pretty reliable on a lot of systems, otherwise there'd be no chance of >getting PLIP links to work. I suspect that if Tommy Thorn's reading this he >can probably give some more details. No, it's not reliable on a large number of systems. All the software you see on DOS/Windoze machines for doing stuff over the LP port all handles this problem using timeouts, polls, and spin-loops. Andy From vandys@glare.cisco.com Mon Mar 14 14:23:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id OAA00299; Mon, 14 Mar 1994 14:23:30 -0800 Received: from hacke1.dtek.chalmers.se by hubbub.cisco.com with SMTP id AA05956 (8.6.4/IDA-1.5 for ); Mon, 14 Mar 1994 14:00:21 -0800 Received: from localhost (d0asta@localhost) by hacke1.dtek.chalmers.se (8.6.4/8.6.4) id WAA17602; Mon, 14 Mar 1994 22:57:23 +0100 Date: Mon, 14 Mar 1994 22:57:23 +0100 From: Magnus Homann Message-Id: <199403142157.WAA17602@hacke1.dtek.chalmers.se> To: vsta@cisco.com Subject: New desciple... :-) Hi! I've just discovered VSTa - thanks to Vijay at Plan 9 mailing list - and I'm trying to install it. The docs are a little brief, though... :-) I took a PC and unpacked vsta.tz in the root. Did the same with standalone.tz. Of course gcc, tar, make was also copied. After preceeding with the instructions in stand.README, I got an error when doing 'run ls -l'. I would say that the main problem is that I don't know what to expect! But if you take the best from Plan 9 and QNX, it can't be THAT bad... :-). I have previously tried Plan 9, but it required to many machines (said my sysop, anyway), so I was forced to remove it again. To run VSTa on *one* PC would be heaven. I'll try to subscribe via vsta-request. If that's wrong someone please add me? Thankful for any help! (Done any climbing lately, Rob? :-) Homann -- Magnus Homann Email: d0asta@dtek.chalmers.se URL : http://www.dtek.chalmers.se/DCIG/d0asta.html The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html From vandys@glare.cisco.com Mon Mar 14 14:34:00 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00309; Mon, 14 Mar 1994 14:33:59 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.5/8.6.5) with SMTP id OAA14464; Mon, 14 Mar 1994 14:10:48 -0800 Message-Id: <199403142210.OAA14464@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Magnus Homann cc: vsta@cisco.com Subject: Re: New desciple... :-) In-reply-to: Your message of "Mon, 14 Mar 1994 22:57:23 +0100." <199403142157.WAA17602@hacke1.dtek.chalmers.se> Date: Mon, 14 Mar 1994 14:10:46 -0800 From: Andrew Valencia [Magnus Homann writes:] >I've just discovered VSTa - thanks to Vijay at Plan 9 mailing list - >and I'm trying to install it. The docs are a little brief, >though... :-) I'm starting to write man pages for the kernel interfaces. This'll show up in the next release, which should be out in a couple weeks. It'll be a bit longer before I get around to writing the user guide. >I took a PC and unpacked vsta.tz in the root. Did the same with >standalone.tz. Of course gcc, tar, make was also copied. After >preceeding with the instructions in stand.README, I got an error when >doing 'run ls -l'. Use "cd" and "ls" (not "run ls"). If you don't see files, then the "run" command will not ever succeed. "cd" and "ls" are built into the standalone shell, which is what you run from the standalone configuration. You have to manually mount your DOS filesystem before you can see it--I think that's in the standalone instructions. Tell me more about what you see. Also spell out exactly what commands you used. >I would say that the main problem is that I don't know what to expect! >But if you take the best from Plan 9 and QNX, it can't be THAT bad... >:-). I have previously tried Plan 9, but it required to many machines >(said my sysop, anyway), so I was forced to remove it again. To run >VSTa on *one* PC would be heaven. Well, it's a "diamond in the rough" at this point (I hope!). The standalone environment is basically just there so you can tickle your hardware and look around a bit. The full install might go smoother, since it's been exercised more often. >I'll try to subscribe via vsta-request. If that's wrong someone please >add me? I saw you get added a minute ago. Regards, Andy From vandys@glare.cisco.com Mon Mar 14 16:16:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id QAA00334; Mon, 14 Mar 1994 16:16:08 -0800 Received: from grumpy.usu.edu by hubbub.cisco.com with SMTP id AA11592 (8.6.4/IDA-1.5 for ); Mon, 14 Mar 1994 15:53:02 -0800 Received: from cc.usu.edu by cc.usu.edu (PMDF V4.2-13 #4757) id <01H9YWK8C638B8K6JL@cc.usu.edu>; Mon, 14 Mar 1994 16:52:49 MDT Date: Mon, 14 Mar 1994 16:52:49 -0600 (MDT) From: Roger Ivie Subject: Re: New disciple To: vsta@cisco.com Message-Id: <01H9YWK8C7ZAB8K6JL@cc.usu.edu> X-Vms-To: IN%"vsta@cisco.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT [Sorry, lost the attributions; my fingers got carried away] > >I took a PC and unpacked vsta.tz in the root. Did the same with > >standalone.tz. Of course gcc, tar, make was also copied. After > >preceeding with the instructions in stand.README, I got an error when > >doing 'run ls -l'. > > Use "cd" and "ls" (not "run ls"). If you don't see files, then the "run" > command will not ever succeed. "cd" and "ls" are built into the standalone > shell, which is what you run from the standalone configuration. You have to > manually mount your DOS filesystem before you can see it--I think that's in > the standalone instructions. Tell me more about what you see. Also spell > out exactly what commands you used. I, too, have been having trouble. Hopefully, I've done something wrong. Is there a FAQ for the mailing list? Here's what I'm seeing: - I can only run the supplied DOS MAKE once; after that I get 'packed file is corrupt' and have to reboot before I can run it again. This makes building everything a bit, um, difficult. Is there a better DOS MAKE that folks are using? - After unpacking vista_fs.tz and standalone.tz, I had a number of problems. I copied the root passwd entry and cloned it to a different account name, but it was behaving as if the env server wasn't working; the path didn't seem to be getting passed to children. Running make would give me 'gcc: invalid'. - I then cloned one of the example user accounts and modified it. Now the path works correctly, but the default directory doesn't work write. The compiler can't find header files in the default directory and ld can't create an output file in the default directory. As with the other new disciple, I don't know what to expect. I may not have everything set up correctly. I have used neither Plan 9 nor QNX... Roger Ivie ivie@cc.usu.edu From vandys@glare.cisco.com Mon Mar 14 16:39:47 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00338; Mon, 14 Mar 1994 16:39:45 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.5/8.6.5) with SMTP id QAA22527; Mon, 14 Mar 1994 16:16:37 -0800 Message-Id: <199403150016.QAA22527@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roger Ivie cc: vsta@cisco.com Subject: Re: New disciple In-reply-to: Your message of "Mon, 14 Mar 1994 16:52:49 CST." <01H9YWK8C7ZAB8K6JL@cc.usu.edu> Date: Mon, 14 Mar 1994 16:16:37 -0800 From: Andrew Valencia [Roger Ivie writes:] > - I can only run the supplied DOS MAKE once; after that I get > 'packed file is corrupt' and have to reboot before I can run > it again. This makes building everything a bit, um, difficult. > Is there a better DOS MAKE that folks are using? I've never had problems. My copy is 21315 bytes long. Is this the same make you're using? Also, what version of djgpp? > - After unpacking vista_fs.tz and standalone.tz, I had a number > of problems. I copied the root passwd entry and cloned it to > a different account name, but it was behaving as if the env > server wasn't working; the path didn't seem to be getting passed > to children. Running make would give me 'gcc: invalid'. This would be in a FAQ, if we had a FAQ. The problem is that the "root" ID gives you lots of power, but it doesn't work well when objects are created. It has to do with the fact that servers usually use your 0'th ability when creating the default protection label for an object (file, whatever). The root label, having a zero length, conflicts with this. > - I then cloned one of the example user accounts and modified it. > Now the path works correctly, but the default directory doesn't > work write. The compiler can't find header files in the default > directory and ld can't create an output file in the default > directory. I believe GCC looks for header files in /vsta/vsta/include. Is this directory present? I hope you're not trying to do cc's running the standsh from the standalone environment! The full installation uses init/login, and gives you several amenities, like $HOME, $USER, mounts from /vsta/etc/fstab for your /tmp filesystem, namer, .... Standalone, once it has proven that VSTa will understand your hardware, should be tossed in favor of the full installation. >As with the other new disciple, I don't know what to expect. I may not have >everything set up correctly. I have used neither Plan 9 nor QNX... The root account has bitten before. I've just deleted it from the master file, so it'll be gone for the next release. djgpp's wandering path has made it hard for people to run the "full" configuration, since that currently requires that you rebuild from source under DOS. Perhaps paired with a native build capability, it would be appropriate to offer a fully functional binary installation? If I did it, v1.3 would be installed by: - Copy the source files into your DOS filesystem under /vsta ...Includes server binaries with the source under /vsta ...Includes a pre-built kernel in os/make/vsta - Copy the pre-built commands/files to /bin, /lib, /etc - Go to /vsta/boot and invoke go.bat - Log in as vandys, password test. (I won't have you arrested! :->) - cd to /vsta/vsta - make Of course, you don't have to build the world unless you want to. You can just run, building things in the tree as needed. Would folks like this? I'm nearly there--I have to do that rename() work, and then add makefiles so you can build everything from the top. Should I hold off v1.3 as long as needed to get this? Send me private E-mail unless there's an issue you'd like to air on the list. Regards, Andy vandys@cisco.com p.s. My port of GNU C is a 1.X flavor; the code won't be as optimized until somebody can port 2.X. From vandys@glare.cisco.com Wed Mar 16 05:26:03 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with SMTP id FAA00174; Wed, 16 Mar 1994 05:26:01 -0800 Received: from hof (hof.daimi.aau.dk) by dirt.cisco.com with SMTP id AA16847 (8.6.4/IDA-1.5 for ); Wed, 16 Mar 1994 05:02:24 -0800 Received: by hof (Linux Smail3.1.28.1 #14) id m0pgvIG-000IBcC; Wed, 16 Mar 94 14:05 MET Message-Id: Date: Wed, 16 Mar 94 14:05 MET From: tthorn%hof@hof.daimi.aau.dk (Tommy Thorn) To: Andrew Valencia Cc: Dave Hudson , VSTa mailing list Subject: Re: IRQ handling In-Reply-To: <199403140004.QAA18752@glare.cisco.com> References: <199403140004.QAA18752@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Andrew Valencia writes: > >Thinking about it, I'm pretty sure that IRQ7 (and IRQ5 for lp2) must be > >pretty reliable on a lot of systems, otherwise there'd be no chance of > >getting PLIP links to work. I suspect that if Tommy Thorn's reading this he > >can probably give some more details. > > No, it's not reliable on a large number of systems. All the software you > see on DOS/Windoze machines for doing stuff over the LP port all handles > this problem using timeouts, polls, and spin-loops. > > Andy This is properly true, but how big is this large number? Plip does use timeouts and spin-loops are implicit (the tcp protocol will retry for you). Given that real-world performens is acceptable (~20Kb/s ftp), and it doesn't kill the system when idle, I suspect that printer interrupt works well enough to be a win on most architecture. Even given the {Net,Free}BSD peoples experiences, one should try both. If I get around to it, I'll replace the iret with and increment of an integer, and check how many spurious interrupts I actually get on the machines available to me. > The nice thing about the iret stub is that I minimize the cost of taking > these useless interrupts. Having to save all the state needed to go up > into C source code would make this long-lived misfeature cost even more > CPU cycles. Why not just disable them instead? Why can the user level code decide weather to use the interrupts or not. Someday I intend to do some plip-like networking, and it requires the printer interrupt. (plip works well on notebooks without ethernet cards). /Tommy From vandys@glare.cisco.com Wed Mar 16 08:01:18 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00185; Wed, 16 Mar 1994 08:01:17 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.7/8.6.5) with SMTP id HAA05367; Wed, 16 Mar 1994 07:38:27 -0800 Message-Id: <199403161538.HAA05367@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tommy.Thorn@daimi.aau.dk cc: Dave Hudson , VSTa mailing list Subject: Re: IRQ handling In-reply-to: Your message of "Wed, 16 Mar 1994 14:05:00 +0700." Date: Wed, 16 Mar 1994 07:38:27 -0800 From: Andrew Valencia [tthorn%hof@hof.daimi.aau.dk (Tommy Thorn) writes:] >Why not just disable them [IRQ7] instead? Why can the user level code decide >weather to use the interrupts or not. Because they do not start arriving because IRQ7 is enabled. They start arriving because the PIC2->PIC1 chain IRQ is enabled. Like I said, it's a hardware glitch thing. If you write a parallel-port driver, and you depend on interrupts, be prepared to be fielding endless complaints about "it's sluggish" or "sometimes it stops sending for a couple seconds" and such. As for the fast iret stub for IRQ7, I'll be happy to enhance the ISR registry code so the stub gets removed when a handler gets registered. But it would be a big mistake to base the printer driver on interrupts--the latest 386BSD printer driver was done by me and a German guy, after we found out how many people couldn't use the interrupt-based one. Andy From vandys@glare.cisco.com Wed Mar 16 08:44:36 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00190; Wed, 16 Mar 1994 08:44:34 -0800 Received: from hof (hof.daimi.aau.dk) by dirt.cisco.com with SMTP id AA11125 (8.6.4/IDA-1.5 for ); Wed, 16 Mar 1994 08:20:46 -0800 Received: by hof (Linux Smail3.1.28.1 #14) id m0pgyOU-000IBcC; Wed, 16 Mar 94 17:24 MET Message-Id: Date: Wed, 16 Mar 94 17:24 MET From: tthorn%hof@hof.daimi.aau.dk (Tommy Thorn) To: Andrew Valencia Cc: Dave Hudson , Tommy.Thorn@daimi.aau.dk, VSTa mailing list Subject: Re: IRQ handling In-Reply-To: <199403161538.HAA05367@glare.cisco.com> References: <199403161538.HAA05367@glare.cisco.com> Reply-To: Tommy.Thorn@daimi.aau.dk Andrew Valencia writes: > If you write a parallel-port driver, and you depend on interrupts, be > prepared to be fielding endless complaints about "it's sluggish" or > "sometimes it stops sending for a couple seconds" and such. I believe you, but isn't "a couple seconds" a rather large timeout value? > As for the fast iret stub for IRQ7, I'll be happy to enhance the ISR > registry code so the stub gets removed when a handler gets registered. But > it would be a big mistake to base the printer driver on interrupts--the > latest 386BSD printer driver was done by me and a German guy, after we found > out how many people couldn't use the interrupt-based one. Ok, my interest in this wasn't printers, so I don't care. I just don't see sparse events, as plip frames, implemented though busy looping. I got this from Bill Roman, but I haven't verified it yet. songdog!roman@eskinews.eskimo.com writes: > I believe the problem with IRQ 7 has a solution. > > First, the problem. The data sheet for the interrupt controller chip used > in the original PC (Intel 8259, if I remember the part number correctly) > includes a somewhat obscure description of what happens when there is a > glitch on an interrupt request line. If the request into the 8259 is > negated before the processor has recognized the resulting interrupt request > output from the 8259, the 8259 can simply negate that output and no interrupt > occurs. But what if the processor has recognized the interrupt request and > begins an interrupt acknowledge cycle after the input to the 8259 has gone > away? The 8259 has to supply a vector to the processor to complete the > interrupt acknowledge cycle. It uses vector 7, but *does not set the > corresponding bit in the In Service Register of the 8259*. Note that this > spurious interrupt 7 can occur even if this interrupt is already active > from a real IRQ 7. > > The solution: the interrupt handler for IRQ7 (and IRQ15 on a PC/AT) should > check the bit in the In Service Register of the 8259, and do an immediate > IRET if it is not set (indicating a spurious interrupt from a glitch). It > must also check and set a flag if a valid IRQ7 is processed (do this before > STI to prevent race conditions!); if the flag is already set, it means that > this is a spurious IRQ7 occurring during the processing of a valid one, and > again an immediate IRET is called for. > > This discussion is all theoretical, based on the data sheet, although I > plan to implement this in a project at work soon (unfortunately, not > involving VSTa). > -- > Bill Roman (songdog!roman@eskimo.com / roman@songdog.uucp) running linux Kind regards, /Tommy From vandys@glare.cisco.com Thu Mar 17 03:33:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id DAA01450; Thu, 17 Mar 1994 03:33:57 -0800 Received: from email.univie.ac.at by hubbub.cisco.com with SMTP id AA06132 (8.6.4/IDA-1.5 for ); Thu, 17 Mar 1994 03:10:53 -0800 Received: from sophie.par.univie.ac.at by email.univie.ac.at with SMTP (PP) id <01624-0@email.univie.ac.at>; Thu, 17 Mar 1994 12:09:53 +0100 Received: from r2d2.univie.ac.at by par.univie.ac.at (4.1/SMI-4.3.12) id AA10405; Thu, 17 Mar 94 12:09:51 +0100 Date: Thu, 17 Mar 94 12:09:51 +0100 From: robert@par.univie.ac.at (Robert Mayer - Student) Message-Id: <9403171109.AA10405@par.univie.ac.at> To: vsta@cisco.com Subject: printer server Today I got my printer server to successfully print an 800 kBytes image. It is not finished yet, but I wanted to ask about several issues: The server is implemented in a very simple way: It receives an FS_WRITE message, then it prints the data in a polling loop, and finally returns to the main message loop. That way an abort message makes no sense (the server doesn't receive messages while an I/O is in progress) and is simply ignored. I suppose a user would not use the printer server directly, but instead one would have a spooler server (more about spooler servers below) which feeds the printer server in small chunks, and to abort a print job the spooler server simply stops feeding chunks. Is this good enough ? Any opinions ? The handling of the parallel port at the hardware level is implemented as a C++ class (or rather as a struct, which is really a class without constructor/ destructor). Any reason not to use C++ in VSTa ? Some thoughts about a spooler server: A spooler server could look like several directories, representing different queues. To print a file, you 'cp' it to the appropriate directory, to remove or abort it, you 'rm' it. 'rm' should also be possible if the printing was already in progress. If a file is printed successfully, it simply disappears. Stat fields of these files could show ranking order and stuff like this. The spooled data could be stored in an mmap()'ed file or in (a) regular file(s) in a spooling directory, so print jobs would not be lost due to a system/spooler/printer crash. A spooling server implemented like this would seem very easy to use, what do you think ? Probably the most important question: Is it a good idea to add a sophisticated printing/spooling system at this time ? Since VSTa internals are still subject to changes, it could add a considerable amount of maintenance. Greetings Robert From vandys@glare.cisco.com Thu Mar 17 08:32:15 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01468; Thu, 17 Mar 1994 08:32:14 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.7/8.6.5) with SMTP id IAA26809; Thu, 17 Mar 1994 08:09:28 -0800 Message-Id: <199403171609.IAA26809@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: robert@par.univie.ac.at (Robert Mayer - Student) cc: vsta@cisco.com Subject: Re: printer server In-reply-to: Your message of "Thu, 17 Mar 1994 12:09:51 +0100." <9403171109.AA10405@par.univie.ac.at> Date: Thu, 17 Mar 1994 08:09:28 -0800 From: Andrew Valencia [robert@par.univie.ac.at (Robert Mayer - Student) writes:] >The server is implemented in a very simple way: It receives an FS_WRITE message, >then it prints the data in a polling loop, and finally returns to the main >message loop. That way an abort message makes no sense (the server doesn't >receive messages while an I/O is in progress) and is simply ignored. I suppose >a user would not use the printer server directly, but instead one would have >a spooler server (more about spooler servers below) which feeds the printer >server in small chunks, and to abort a print job the spooler server simply >stops feeding chunks. Is this good enough ? Any opinions ? You are using synchronous I/O, which is good (usually) for things like disks. Its problem is that you can hang a user if your printer stops responding for a while. >The handling of the parallel port at the hardware level is implemented as a >C++ class (or rather as a struct, which is really a class without constructor/ >destructor). Any reason not to use C++ in VSTa ? All of VSTa is written in C currently; each time you add a new language to the base OS source, you make it incrementally harder for other people to build it. It also incrementally steals my time, since each new run-time environment will generate a new set of questions, and a new set of things I have to check from time to time. Thus, I am reluctant to add a new language without a compelling reason. Please, no computer language flame wars here. >Some thoughts about a spooler server: >A spooler server could look like several directories, representing different >queues. To print a file, you 'cp' it to the appropriate directory, to remove >or abort it, you 'rm' it. 'rm' should also be possible if the printing was >already in progress. If a file is printed successfully, it simply disappears. >Stat fields of these files could show ranking order and stuff like this. The >spooled data could be stored in an mmap()'ed file or in (a) regular file(s) >in a spooling directory, so print jobs would not be lost due to a >system/spooler/printer crash. >A spooling server implemented like this would seem very easy to use, what do >you think ? Well, a synchronous server reduces the benefits of this approach a bit, since you can just as easily get hung queueing data as writing it to the printer itself. To make it really friendly/safe, I suspect you'll want a pair of threads, one watching the incoming queue, and another taking successive jobs and feeding them out to the printer. >Probably the most important question: Is it a good idea to add a sophisticated >printing/spooling system at this time ? Since VSTa internals are still >subject to changes, it could add a considerable amount of maintenance. The internals are subject to change, but I think the API has stabilized. I think it would be a great idea! :-) Andy From vandys@glare.cisco.com Thu Mar 17 09:45:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA01476; Thu, 17 Mar 1994 09:45:45 -0800 Received: from email.univie.ac.at by hubbub.cisco.com with SMTP id AA21803 (8.6.4/IDA-1.5 for ); Thu, 17 Mar 1994 09:22:35 -0800 Received: from sophie.par.univie.ac.at by email.univie.ac.at with SMTP (PP) id <07602-0@email.univie.ac.at>; Thu, 17 Mar 1994 18:22:04 +0100 Received: from r2d2.univie.ac.at by par.univie.ac.at (4.1/SMI-4.3.12) id AA11747; Thu, 17 Mar 94 18:21:58 +0100 Date: Thu, 17 Mar 94 18:21:58 +0100 From: robert@par.univie.ac.at (Robert Mayer - Student) Message-Id: <9403171721.AA11747@par.univie.ac.at> To: vsta@cisco.com Subject: Re: printer server [Andrew Valencia writes:] > You are using synchronous I/O, which is good (usually) for things like > disks. Its problem is that you can hang a user if your printer stops > responding for a while. > Error handling is not really implemented yet, but I had the following in mind: If the printer doesn't respond, I would simply log an error (currently printf, later the new syslog() ?), return EIO and discard the data. Discarding the data should not be a problem, since the spooling server keeps the original until successful completion (and a user that 'cp's a file to /dev/printer or whatever should do the same). The (obvious) idea behind this is: keep the hardware dependent printer server as simple as possible, and put the fancy stuff into a hardware independent spooler server. [ reasons why not to use C++ right now deleted ] Okay, I can easily change it into C. > >Some thoughts about a spooler server: > >A spooler server could look like several directories, representing different > >queues. To print a file, you 'cp' it to the appropriate directory, to remove > >or abort it, you 'rm' it. 'rm' should also be possible if the printing was > >already in progress. If a file is printed successfully, it simply disappears. > >Stat fields of these files could show ranking order and stuff like this. The > >spooled data could be stored in an mmap()'ed file or in (a) regular file(s) > >in a spooling directory, so print jobs would not be lost due to a > >system/spooler/printer crash. > >A spooling server implemented like this would seem very easy to use, what do > >you think ? > > Well, a synchronous server reduces the benefits of this approach a bit, > since you can just as easily get hung queueing data as writing it to the > printer itself. To make it really friendly/safe, I suspect you'll want a > pair of threads, one watching the incoming queue, and another taking > successive jobs and feeding them out to the printer. > I agree, a good spooler server should use a separate thread to talk to the printer *server* , which could still be synchronous and thus simple. > >Probably the most important question: Is it a good idea to add a sophisticated > >printing/spooling system at this time ? Since VSTa internals are still > >subject to changes, it could add a considerable amount of maintenance. > > The internals are subject to change, but I think the API has stabilized. I > think it would be a great idea! :-) > > Andy > I can send you, Andy, the printer server once it is finished (and converted to C :-( ), but I didn't even start to code a spooler server. Robert From vandys@glare.cisco.com Wed Mar 23 17:20:41 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00121; Wed, 23 Mar 1994 17:20:40 -0800 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id QAA09137 for ; Wed, 23 Mar 1994 16:59:14 -0800 Message-Id: <199403240059.QAA09137@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: rename() working Date: Wed, 23 Mar 1994 16:59:14 -0800 From: Andrew Valencia Well, using Peter Holzer's suggestion, I have implemented rename() for VSTa. I added an FS_RENAME message, and modified the DOS filesystem server so he can understand the message. I'll do the same to vstafs soon, and then finish my port of ar. Andy From vandys@glare.cisco.com Sun Mar 27 08:59:47 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id IAA00337; Sun, 27 Mar 1994 08:59:31 -0800 Received: from email.univie.ac.at by hubbub.cisco.com with SMTP id AA19232 (8.6.4/IDA-1.5 for ); Sun, 27 Mar 1994 08:38:30 -0800 Received: from sophie.par.univie.ac.at by email.univie.ac.at with SMTP (PP) id <13134-0@email.univie.ac.at>; Sun, 27 Mar 1994 18:38:22 +0200 Received: from r2d2.univie.ac.at by par.univie.ac.at (4.1/SMI-4.3.12) id AA18368; Sun, 27 Mar 94 18:36:55 +0200 Date: Sun, 27 Mar 94 18:36:55 +0200 From: robert@par.univie.ac.at (Robert Mayer - Student) Message-Id: <9403271636.AA18368@par.univie.ac.at> To: vsta@cisco.com Subject: proc server Some time ago there was a task list (things to be done and who does them) which had an entry "/proc server". It seems that nobody started to work on this, and so I would like to volunteer. Actually I have already started coding a little test program, but without much success. It was easy to get the addresses of various kernel variables, but how do I access these variables? As far as I can see, kernel memory is already mapped in a process' adress space (good), but it is mapped at linear adress 0, and the process' data segment's descriptor starts at address 2GB (bad). I can only think of two solutions: 1. get a descriptor starting at address 0 or 2. mmap() kernel memory at an address I can access. I think solution 2 is preferable, but can mmap() do this? It seems to me that mmap() can only map files, physical memory and unused (free) memory, or am I missing something? Any help would be appreciated. Robert P.S.: Actually there is a third solution: inside the kernel one could tfork() a server which makes kernel memory accessible as a file. The port would have to be "well known". Any comments on this? Is tfork() possible inside the kernel? Is a server inside the kernel a good idea? From vandys@glare.cisco.com Sun Mar 27 09:11:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA00340; Sun, 27 Mar 1994 09:11:16 -0800 Received: from cygnus.com by hubbub.cisco.com with SMTP id AA19407 (8.6.4/IDA-1.5 for ); Sun, 27 Mar 1994 08:50:19 -0800 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA02456; Sun, 27 Mar 94 08:50:14 PST Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA19514; Sun, 27 Mar 94 09:50:12 MST Message-Id: <9403271650.AA19514@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Sun, 27 Mar 1994 09:50:12 MST In-Reply-To: robert@par.univie.ac.at (Robert Mayer - Student) "proc server" (Mar 27, 6:36pm) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: robert@par.univie.ac.at (Robert Mayer - Student), vsta@cisco.com Subject: Re: proc server From: robert@par.univie.ac.at (Robert Mayer - Student) Subject: proc server > Some time ago there was a task list (things to be done and who does them) which > had an entry "/proc server". It seems that nobody started to work on this, and > so I would like to volunteer. Actually I have already started coding a little There is a great section in the Linux Kernel hackers guide on /proc and how it works. You can grab a copy from darkstar.cygnus.com:pub/linux/LDP. - rob - From vandys@glare.cisco.com Sun Mar 27 10:28:20 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00352; Sun, 27 Mar 1994 10:28:19 -0800 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id KAA14878; Sun, 27 Mar 1994 10:07:21 -0800 Message-Id: <199403271807.KAA14878@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: robert@par.univie.ac.at (Robert Mayer - Student) cc: vsta@cisco.com Subject: Re: proc server In-reply-to: Your message of "Sun, 27 Mar 1994 18:36:55 +0200." <9403271636.AA18368@par.univie.ac.at> Date: Sun, 27 Mar 1994 10:07:20 -0800 From: Andrew Valencia [robert@par.univie.ac.at (Robert Mayer - Student) writes:] >2. mmap() kernel memory at an address I can access. Yes, mapping physical memory would be a useful, general mechanism worth adding to the kernel. However there's a completely different approach which you might consider. The problem with reading kernel memory is (1) your code can break each time the kernel changes, and (2) you can't really trust the results, as the data structures can change out from beneath you. If you add a kernel interface to query process status (HP-UX called it pstat()--I made it up for them, so I've seen this work before) then you can have it communicate using an interface which insulates the /proc server from changes to the kernel. It can also protect against race conditions, as the kernel side of pstat() can apply the locking necessary to guarantee that the information on a given process/thread was consistent for the instant in time it was taken. Your current approach has the nice characteristic that it doesn't put more stuff into the kernel. Allowing the process read-only access to kernel memory opens some security holes, but the lack of write access limits these, and it probably is tolerable. Anyway, another way to consider. Adding a mmap() of physical memory would be the work of an hour or so, let me know if you'd like me to do it, although you're welcome to have a go at it yourself. Please be wary of multiprocessor issues! Regards, Andy From vandys@glare.cisco.com Mon Mar 28 20:42:39 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA00617; Mon, 28 Mar 1994 20:42:37 -0800 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id UAA18564 for ; Mon, 28 Mar 1994 20:21:49 -0800 Message-Id: <199403290421.UAA18564@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: A Bourne shell for VSTa Date: Mon, 28 Mar 1994 20:21:49 -0800 From: Andrew Valencia Well, the "rc" shell from Plan9 is cool in its own way, but I'm sure we all have uses for a more standard shell. I've just finished a little "art" with a blowtorch and have BSD's clone of "sh" running on VSTa. Seems to spawn processes and run built-ins OK, and the basic "for x in ..." stuff seems to work. Environment handling is a bit of a crock, I'll see if I can tidy it up. But this'll be in v1.3! Speaking of v1.3... I'll take contributions through the end of this week. I hope to send out an announcement next week. Regards, Andy From vandys@glare.cisco.com Sat Apr 2 14:11:28 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00231; Sat, 2 Apr 1994 14:11:26 -0800 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id NAA27001 for ; Sat, 2 Apr 1994 13:51:50 -0800 Message-Id: <199404022151.NAA27001@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Opinions on filesystem mount Date: Sat, 02 Apr 1994 13:51:49 -0800 From: Andrew Valencia When I first made up a "root" filesystem, I mounted it as /vsta, as I figured it would be helpful to have distinct paths for VSTa stuff when co-existing in a DOS filesystem. Of course, in practice, the prefix is only there when running VSTa, so it would seem that all it does is add four bytes to each path being used. Would anybody mind if I mount the "root" filesystem in /, and thus move the standard directories to /lib, /bin, and so forth? /namer, /env, /pipe, /tmp, and so forth would remain where they were. This would impact, mostly, things like standard shell paths, the location of password files and libraries, and binaries. On another topic entirely, if somebody has a logic analyzer hooked to a PC, I would like to talk to you about doing some program counter sampling so I can get a histogram of CPU usage vs. code for some common things like message passing and context switching. Mike Larson gave me a little test program which shows a context switch time of ~155 microseconds on my 486 PC. This isn't great, but it really isn't that bad considering I've never gone back and optimized the context switch paths. If somebody could point me to hot spots it would make the task a lot easier. Oh yes, 155 uSec is actually the time to send a message and receive back a response, so there's some message handling code path in there as well. Still, we use both messaging and context switching a LOT; it can't hurt to tune it. Thanks, Andy From vandys@glare.cisco.com Sun Apr 3 07:03:18 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id HAA00338; Sun, 3 Apr 1994 07:03:17 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA06834 (8.6.4/IDA-1.5 for ); Sun, 3 Apr 1994 06:43:38 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa24958; 3 Apr 94 14:41 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pnSNY-0003JFC; Sun, 3 Apr 94 14:38 BST Message-Id: From: Dave Hudson Subject: Re: Opinions on filesystem mount To: Andrew Valencia Date: Sun, 3 Apr 1994 14:38:20 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199404022151.NAA27001@glare.cisco.com> from "Andrew Valencia" at Apr 2, 94 01:51:49 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: 1792 > > When I first made up a "root" filesystem, I mounted it as /vsta, as I > figured it would be helpful to have distinct paths for VSTa stuff when > co-existing in a DOS filesystem. Of course, in practice, the prefix is only > there when running VSTa, so it would seem that all it does is add four bytes > to each path being used. Would anybody mind if I mount the "root" > filesystem in /, and thus move the standard directories to /lib, /bin, and > so forth? Yes please move it to / - I've been meaning to ask if this was possible :-) > On another topic entirely, if somebody has a logic analyzer hooked to a PC, > I would like to talk to you about doing some program counter sampling so I > can get a histogram of CPU usage vs. code for some common things like > message passing and context switching. Mike Larson gave me a little test > program which shows a context switch time of ~155 microseconds on my 486 PC. > This isn't great, but it really isn't that bad considering I've never gone > back and optimized the context switch paths. If somebody could point me to > hot spots it would make the task a lot easier. I won't get chance to look at this until after my Easter break (Thursday or Friday), but if you don't get any other offers let me know - there are a couple of HP analysers in my lab at work (with 486 disasm modules if that's any help). Wouldn't it be possible to get a pretty good feel for this though by using the interval timer - I'd hope that the couple of extra instructions wouldn't foul the 486's pipelining too much and maybe just running INVD after the initial timer read would set a good initial condition anyway? From past experience of writing CPU benchmarks and speed checks starting with a clean cache always seems a good idea. Regards, Dave From vandys@glare.cisco.com Mon Apr 4 06:52:43 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id GAA00981; Mon, 4 Apr 1994 06:52:42 -0700 Received: from news.std.com by hubbub.cisco.com with SMTP id AA05496 (8.6.4/IDA-1.5 for ); Mon, 4 Apr 1994 06:33:14 -0700 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA22354; Mon, 4 Apr 1994 09:32:48 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA18544; Mon, 4 Apr 1994 09:32:26 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199404041332.AA18544@world.std.com> Subject: Re: Opinions on filesystem mount To: vsta@cisco.com Date: Mon, 4 Apr 1994 09:32:26 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 689 > > When I first made up a "root" filesystem, I mounted it as /vsta, as I > > figured it would be helpful to have distinct paths for VSTa stuff when > > co-existing in a DOS filesystem. Of course, in practice, the prefix is only > > there when running VSTa, so it would seem that all it does is add four bytes > > to each path being used. Would anybody mind if I mount the "root" > > filesystem in /, and thus move the standard directories to /lib, /bin, and > > so forth? > > Yes please move it to / - I've been meaning to ask if this was possible :-) I'd vote yes too (mount the root filesystem in /) - for one thing, this should make writing makefiles easier. Mike Larson From vandys@glare.cisco.com Mon Apr 4 18:15:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id SAA02682; Mon, 4 Apr 1994 18:15:33 -0700 Received: from news.std.com by hubbub.cisco.com with SMTP id AA08740 (8.6.4/IDA-1.5 for ); Mon, 4 Apr 1994 17:56:07 -0700 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA09641; Mon, 4 Apr 1994 20:56:05 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA21206; Mon, 4 Apr 1994 20:47:07 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199404050047.AA21206@world.std.com> Subject: Re: Opinions on filesystem mount To: vsta@cisco.com Date: Mon, 4 Apr 1994 20:47:06 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 419 [Andrew Valencia writes:] >[larz@world.std.com (Mike A Larson) writes:] >>I'd vote yes too (mount the root filesystem in /) - for one thing, this >>should make writing makefiles easier. > >Can you tell me in what way it makes writing makefiles easier? The absolute path names are the same so for both DOS and VSTa. Thus: LDFLAGS = -L/libc -L/lib Works for both DOS and VSTa. Mike Larson From vandys@glare.cisco.com Tue Apr 5 09:02:13 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03188; Tue, 5 Apr 1994 09:02:12 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id IAA22009; Tue, 5 Apr 1994 08:42:50 -0700 Message-Id: <199404051542.IAA22009@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: larz@world.std.com (Mike A Larson) cc: vsta@cisco.com Subject: Re: Opinions on filesystem mount In-reply-to: Your message of "Mon, 04 Apr 1994 20:47:06 EDT." <199404050047.AA21206@world.std.com> Date: Tue, 05 Apr 1994 08:42:50 -0700 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >>Can you tell me in what way it makes writing makefiles easier? >The absolute path names are the same so for both DOS and VSTa. Thus: > LDFLAGS = -L/libc -L/lib >Works for both DOS and VSTa. Couple issues mixed in here. When building from a source tree, you almost always want the source tree to use relative paths, so you can have multiple source trees, or do something weird in a source tree without impacting the "regular" tools. Thus, within the VSTa source I hope always to have things like -L../../libc and never an absolute path. This leaves the question of where to place the "installed" binaries. Using the /lib and /bin paths can easily clash with other DOS C compiler environments. What if I added "make install" targets to the makefiles and placed the results in /vsta/lib and /vsta/bin (and /vsta/etc)? This would keep all the VSTa files (source, binary, and random support text files like the password file) within the single DOS directory /vsta, which seems tidier and less likely to clash with other DOS programs. Andy From vandys@glare.cisco.com Tue Apr 5 10:16:25 1994 Received: from dustbin.cisco.com (dustbin.cisco.com [131.108.1.27]) by amri.cisco.com (8.3/8.3) with SMTP id KAA03201; Tue, 5 Apr 1994 10:16:23 -0700 Received: from cygnus.com by dustbin.cisco.com with SMTP id AA17446 (8.6.4/IDA-1.5 for ); Tue, 5 Apr 1994 09:57:01 -0700 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA05575; Tue, 5 Apr 94 09:55:44 PDT Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA07179; Tue, 5 Apr 94 10:55:42 MDT Message-Id: <9404051655.AA07179@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Tue, 5 Apr 1994 10:55:42 MDT In-Reply-To: Andrew Valencia ' <199404051542.IAA22009@glare.cisco.com> Re: Opinions on filesystem mount Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , larz@world.std.com (Mike A Larson) Subject: Re: Opinions on filesystem mount Cc: vsta@cisco.com From: Andrew Valencia Subject: Re: Opinions on filesystem mount > Couple issues mixed in here. When building from a source tree, you almost > always want the source tree to use relative paths, so you can have multiple VPATH is actually the easiest way to do this. > source trees, or do something weird in a source tree without impacting the > "regular" tools. Thus, within the VSTa source I hope always to have things > like -L../../libc and never an absolute path. Use VPATH, (supported by gmake), and have the value of VPATH be configurable. Ultimately, I was planning to add configuration to VSTa so I can port VSTa to the m68k. (which I'd like to do bad) > This leaves the question of where to place the "installed" binaries. Using > the /lib and /bin paths can easily clash with other DOS C compiler All GNU tools currently default to installing in /usr/local/{bin,lib}. Why not just use that ? We use --prefix to change the installed paths. If all the tools and utilities for VSTa used this --prefix value, then they'd all be in sync and work. DJGPP (if you use binaries) comes pre-configured for a path, but we can always reconfig/build DJGPP. Also, GCC_EXEC_PREFIX can also make DJGPP work when it's installed in a non-standard place. When I finish porting GCC to VSTa (in progress) then we can install the "i386-vsta-gcc" anywhere. > environments. What if I added "make install" targets to the makefiles and > placed the results in /vsta/lib and /vsta/bin (and /vsta/etc)? This would Yes. "make install" can use the value of $prefix (from configuring) and then should install them at that value. I'll gladly discuss GNU configuration and build techniques for hours... :-) - rob - From vandys@glare.cisco.com Tue Apr 5 16:45:56 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA03338; Tue, 5 Apr 1994 16:45:55 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id QAA24339 for ; Tue, 5 Apr 1994 16:26:39 -0700 Message-Id: <199404052326.QAA24339@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: VSTa self-hosted build Date: Tue, 05 Apr 1994 16:26:38 -0700 From: Andrew Valencia Self-hosted VSTa builds proceed nicely. ar(1) is now ported, and today I successfully built libusr.a, the VSTa kernel, dbsym, and booted the kernel built under VSTa. Next I'll convert the mkall.bat to a shell script, and see about building the whole tree self-hosted. Hmmm... speaking of shell scripts. Just about every shell script on earth starts with "#!/bin/sh". If I don't have a VSTa /bin there, it'll be an endless pain. What I think I'll do is use a union directory so / will be bound first to the root of the DOS server, and next to /vsta. That'll give you both full access to your DOS filesystem as well as placing the /bin and /lib in their customary location. Kudos to Plan9 for the very flexible concept of union directories! I don't think I've ever used them, so there's probably a little debugging to be done. Andy From vandys@glare.cisco.com Tue Apr 5 22:24:30 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id WAA03355; Tue, 5 Apr 1994 22:24:28 -0700 Received: from sparkle.usask.ca by hubbub.cisco.com with SMTP id AA20325 (8.6.4/IDA-1.5 for ); Tue, 5 Apr 1994 22:05:04 -0700 Received: by sparkle.USask.ca id AA13587 (5.67b/IDA-1.5); Tue, 5 Apr 1994 23:05:02 -0600 Date: Tue, 5 Apr 1994 23:05:02 -0600 From: Doug Konkin Message-Id: <199404060505.AA13587@sparkle.USask.ca> To: Andrew Valencia Cc: larz@world.std.com (Mike A Larson), vsta@cisco.com Subject: Re: Opinions on filesystem mount In-Reply-To: <199404051542.IAA22009@glare.cisco.com> References: <199404050047.AA21206@world.std.com> <199404051542.IAA22009@glare.cisco.com> Andrew Valencia writes: > [larz@world.std.com (Mike A Larson) writes:] > > >>Can you tell me in what way it makes writing makefiles easier? > >The absolute path names are the same so for both DOS and VSTa. Thus: > > LDFLAGS = -L/libc -L/lib > >Works for both DOS and VSTa. > > Couple issues mixed in here. When building from a source tree, you almost > always want the source tree to use relative paths, so you can have multiple > source trees, or do something weird in a source tree without impacting the > "regular" tools. Thus, within the VSTa source I hope always to have things > like -L../../libc and never an absolute path. > What I would suggest here, based on the work we did in developing big systems with many variants, is to use paths relative to a moveable root, i.e. something that can be represented by an environment variable. If the top of the source tree is VSTAROOT, then the libraries can be at $VSTAROOT/libc, and so on. We found that this gave us the flexibility of relative paths, and the "safety" of absolute paths. > This leaves the question of where to place the "installed" binaries. Using > the /lib and /bin paths can easily clash with other DOS C compiler > environments. What if I added "make install" targets to the makefiles and > placed the results in /vsta/lib and /vsta/bin (and /vsta/etc)? This would > keep all the VSTa files (source, binary, and random support text files like > the password file) within the single DOS directory /vsta, which seems tidier > and less likely to clash with other DOS programs. > > Andy You can do the same thing for binaries, putting them at a standard place under the root of the tree, with "install" targets that will move them from there to the proper place to be found in the running system. doug From vandys@glare.cisco.com Wed Apr 6 09:10:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id JAA03382; Wed, 6 Apr 1994 09:10:38 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA16461 (8.6.4/IDA-1.5 for ); Wed, 6 Apr 1994 08:51:09 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08196; 6 Apr 94 14:41 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0poXoq-0002yOC; Wed, 6 Apr 94 14:39 BST Message-Id: From: Dave Hudson Subject: 3.5" 1.44 MByte FDD support To: VSTa mailing list Date: Wed, 6 Apr 1994 14:38:59 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 440 Hi All, Has anyone been able to get 1.44 MByte 3.5" floppy drives to work correctly under VSTa? I could really do with getting this working in order to get some more work on bootstrap utilities finished :-) fd is reporting that it's found the drive and setting up the namer entry. When I mount this at /dev I get my /dev/fd/fd0 entry, but as soon as I try to access the drive I get dropped into the kernel debugger. Regards, Dave From vandys@glare.cisco.com Wed Apr 6 09:49:45 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03387; Wed, 6 Apr 1994 09:49:44 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id JAA25354; Wed, 6 Apr 1994 09:30:27 -0700 Message-Id: <199404061630.JAA25354@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson cc: VSTa mailing list Subject: Re: 3.5" 1.44 MByte FDD support In-reply-to: Your message of "Wed, 06 Apr 1994 14:38:59 BST." Date: Wed, 06 Apr 1994 09:30:26 -0700 From: Andrew Valencia [Dave Hudson writes:] >fd is reporting that it's found the drive and setting up the namer entry. >When I mount this at /dev I get my /dev/fd/fd0 entry, but as soon as I try >to access the drive I get dropped into the kernel debugger. This is most likely just the timer thread being terminated when the main thread decides to cancel the timeout for the floppy. Take out the dbg_enter() in os/kern/event.c for the case of un-handled events, and it'll run much better. Now that we have adb(1) and debugging support, I think I'll be removing this for v1.3. It used to be very convenient for taking a look at why your user programs were dying, but adb is a better way to look anyway. BTW... I haven't tested the floppy driver in a LONG time. Expect some bit decay. Andy From vandys@glare.cisco.com Wed Apr 6 14:17:20 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id OAA03424; Wed, 6 Apr 1994 14:17:19 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA03306 (8.6.4/IDA-1.5 for ); Wed, 6 Apr 1994 13:57:51 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10741; 6 Apr 94 20:57 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0podYv-0002jfC; Wed, 6 Apr 94 20:46 BST Message-Id: From: Dave Hudson Subject: Re: 3.5" 1.44 MByte FDD support To: Andrew Valencia Date: Wed, 6 Apr 1994 20:46:57 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199404061630.JAA25354@glare.cisco.com> from "Andrew Valencia" at Apr 6, 94 09:30:26 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: 1261 Andrew Valencia wrote: > > [Dave Hudson writes:] > > >fd is reporting that it's found the drive and setting up the namer entry. > >When I mount this at /dev I get my /dev/fd/fd0 entry, but as soon as I try > >to access the drive I get dropped into the kernel debugger. > > This is most likely just the timer thread being terminated when the main > thread decides to cancel the timeout for the floppy. Take out the > dbg_enter() in os/kern/event.c for the case of un-handled events, and it'll > run much better. I couldn't find a dbg_enter() there, but a bit of tracing back allowed me find my main problem in os/mach/trap.c (in function sendev). The floppy seems to work fine except for when I take the diskette out of the drive and then try to do something. If I miss the timeout period I end up in an infinite loop :-( > Now that we have adb(1) and debugging support, I think I'll be removing this > for v1.3. It used to be very convenient for taking a look at why your user > programs were dying, but adb is a better way to look anyway. Do you mean just the kernel dissassembler? At the moment (although I know a proc fs is being worked on) I don't know of another way of checking thread/process IDs Regards, Dave From vandys@glare.cisco.com Wed Apr 6 15:12:04 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA03434; Wed, 6 Apr 1994 15:12:03 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id OAA16952; Wed, 6 Apr 1994 14:52:52 -0700 Message-Id: <199404062152.OAA16952@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson cc: VSTa mailing list Subject: Re: 3.5" 1.44 MByte FDD support In-reply-to: Your message of "Wed, 06 Apr 1994 20:46:57 BST." Date: Wed, 06 Apr 1994 14:52:51 -0700 From: Andrew Valencia [Dave Hudson writes:] >Do you mean just the kernel dissassembler? At the moment (although I know a >proc fs is being worked on) I don't know of another way of checking >thread/process IDs You can: adb :r [ ... ] :c and the program will run under the debugger. When it takes an event, it'll stop under the debugger, and you can "$c" it to see where it is, "$r" to check registers, and ":c" to let it run with the event. If it exits, you'll be notified of that as well. For adoptive debugging, yes, you either have to remember the PID if you launch it from a shell, or ^Z to the kernel debugger, "pr" to get a proc list, and find the PID that way. "q" from the kernel debugger to let the system continue. Then "adb " to attach to the process. You'll be blocked until the process runs, at which time it'll see the debugging master and will stop. $c it, then :c to let it continue running under your debugger. If your debugger croaks, the process continues on without further interruption. If the process dies, you'll hear about it in the debugger. Andy From vandys@glare.cisco.com Wed Apr 6 15:09:15 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA03431; Wed, 6 Apr 1994 15:09:14 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8/8.6.5) with SMTP id OAA16799; Wed, 6 Apr 1994 14:49:15 -0700 Message-Id: <199404062149.OAA16799@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: 3.5" 1.44 MByte FDD support In-reply-to: Your message of "Wed, 06 Apr 1994 20:53:48 BST." Date: Wed, 06 Apr 1994 14:49:13 -0700 From: Andrew Valencia [Dave Hudson writes:] >Since the syslog stuff isn't yet on a public release I thought I'd ask this >off the list - have you added syslog support to the fd server? If not, let >me know and I'll add it in - I'd like to try and fix the infinite loop >problem, and make the server turn off the fdd motor when it starts (typing >ahead under DOS, having just copied a file leaves the motor on). No, I haven't added syslog() to it. Knock yourself out! :-) The motor used to spin down, but I can easily believe it's broken. I have converted to self-hosted compilation of the base OS. Seems to be working. I have also moved things around so /vsta/{etc, lib, bin} are constructed from the "make install" target. The servers and init are copied into the /vsta/boot directory, and boot.lst loads the servers in that directory instead of reaching over into the source tree. So you can really scrozz your source and still be able to boot. Also, I won't clear these directories when building the release, so people can run VSTa without having to hassle over a DOS compilation environment first. The most visible result of these changes is that what used to be in lib/ is now built over in libc/, and bin/ has been renamed bin.src/. mkall.bat and mkclean.bat are history; the shell script "mkall" accepts an optional target and invokes all the appropriate makefiles in the subdirectories. So I do "mkall" to build everything, "mkall install" to place it into the bin/, lib/, boot/ subdirs, and "mkall clean/clobber" to clean up afterwards. By BSD convention, "make clean" clears up object files but not resulting libraries or executables, and "make clobber" cleans up everything but the original source. Andy From vandys@glare.cisco.com Thu Apr 7 04:00:15 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id EAA03595; Thu, 7 Apr 1994 04:00:13 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA05302 (8.6.4/IDA-1.5 for ); Thu, 7 Apr 1994 03:40:46 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21785; 7 Apr 94 10:41 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0popjT-0002c0C; Thu, 7 Apr 94 09:46 BST Message-Id: From: Dave Hudson Subject: Re: 3.5" 1.44 MByte FDD support To: Andrew Valencia Date: Thu, 7 Apr 1994 09:46:39 +0100 (BST) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1004 Andrew Valencia wrote: > > The most visible result of these changes is that what used to be in lib/ is > now built over in libc/, and bin/ has been renamed bin.src/. mkall.bat and > mkclean.bat are history; the shell script "mkall" accepts an optional target > and invokes all the appropriate makefiles in the subdirectories. So I do > "mkall" to build everything, "mkall install" to place it into the bin/, > lib/, boot/ subdirs, and "mkall clean/clobber" to clean up afterwards. By > BSD convention, "make clean" clears up object files but not resulting > libraries or executables, and "make clobber" cleans up everything but the > original source. Sounds great. Is there a particular reason for not having a /vsta/src tree, eg /vsta/src/{bin, lib, boot, os, srv}? I suppose it's not too conventional but /vsta/{bin.src, lib.src, boot.src} seem reasonable as well. I'd really like to have a consistent file system layout for once (unlike many other OS's I can think of) :-) Regards, Dave From vandys@glare.cisco.com Thu Apr 7 03:59:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id DAA03592; Thu, 7 Apr 1994 03:59:54 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA05290 (8.6.4/IDA-1.5 for ); Thu, 7 Apr 1994 03:40:26 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21743; 7 Apr 94 10:41 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0pophU-0002bzC; Thu, 7 Apr 94 09:44 BST Message-Id: From: Dave Hudson Subject: Re: 3.5" 1.44 MByte FDD support To: Andrew Valencia Date: Thu, 7 Apr 1994 09:44:36 +0100 (BST) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1077 Andrew Valencia wrote: > > For adoptive debugging, yes, you either have to remember the PID if you > launch it from a shell, or ^Z to the kernel debugger, "pr" to get a proc > list, and find the PID that way. "q" from the kernel debugger to let the > system continue. Then "adb " to attach to the process. > You'll be blocked until the process runs, at which time it'll see the > debugging master and will stop. $c it, then :c to let it continue running > under your debugger. Ah, it was this that I was concerned about losing (^Z followed by pr that is) :-) I agree that adb is much more user friendly for debugging with - that's what allowed me to track down my "type=c" problem in the joystick server. BTW, has anyone considered if there'll be a way of redirecting the kernel debugger output to a windowed screen when MADO's running. A similar but simpler problem I hit last night was that I had a kernel debugger compiled for a colour vid which didn't display anything on my mono screen (cons -mono worked for everything else. Regards, Dave From vandys@glare.cisco.com Sat Apr 9 18:03:37 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id SAA03904; Sat, 9 Apr 1994 18:03:34 -0700 Received: from post.demon.co.uk by hubbub.cisco.com with SMTP id AA15260 (8.6.4/IDA-1.5 for ); Sat, 9 Apr 1994 17:44:34 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa26144; 10 Apr 94 1:41 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0ppme9-0003nuC; Sun, 10 Apr 94 00:41 BST Message-Id: From: Dave Hudson Subject: Timestamps To: VSTa mailing list Date: Sun, 10 Apr 1994 00:41:05 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1808 Hi All, I've recently added the preliminary code to support timestamping in bfs, but it's left me wondering what's the best way to track time under VSTa. My own leanings would be to timestamp everything in GMT (UTC) and then have some notion of localtime - but maybe I'm a little biased living on GMT 6 months of the year :-) I certainly don't want to have to implement something as comprehensive as NTP but it would be nice to have a reference. Whatever, I guess there needs to be some agreement on how filesystems, etc, will report timestamps. I'd really like to be able to cover the 1980's (I have quite a lot of data files from the late 80's), but at the momemnt VSTa time seems to start on 01JAN1990. >From some quick calculations I think 32 bits gives us 136 years of coverage at 1 second accuracy. I just checked RFC 1305 (NTP version 3) and this seems to be the way it's done there (NTP uses these as the most significant 32 bits out of 64 - the other 32 provide subsecond accuracy to about 200 ps). Is there any reason why the filesystems, etc, shouldn't do something similar and nominally start time at 01JAN1900 - I'm quite sure that by the time 2036 comes around no-one will be too worried about extending 32 bits of timestamp :-) I'd hope that this might make things simpler for a few reasons: - If someone does want to add more accurrate time synchronisation we'd already be pretty close (eg if someone wants to add leap seconds). - In a distributed system it would be very useful (perhaps essential?) to have very accurate timestamping of messages - Having one format means it's possible to use a single set of library functions for all conversions. Can anyone think of reasons or other standards that might suggest a different/better approach? Regards, Dave From vandys@glare.cisco.com Mon Apr 11 10:28:03 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA04123; Mon, 11 Apr 1994 10:28:01 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA03053 for ; Mon, 11 Apr 1994 10:09:19 -0700 Message-Id: <199404111709.KAA03053@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: v1.3 available Date: Mon, 11 Apr 1994 10:09:18 -0700 From: Andrew Valencia Version 1.3 of VSTa is now available on ftp.cisco.com:vandys/vsta. It includes a Bourne-ish shell, binary install, self hosted recompilation of the entire system, multiple virtual consoles, a significantly more compatible errno emulation, plus the usual assortment of bug fixes. Hope you enjoy it! :-) Andy From vandys@glare.cisco.com Mon Apr 11 17:46:46 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id RAA04154; Mon, 11 Apr 1994 17:46:44 -0700 Received: from tyo1.gate.nec.co.jp ([202.32.8.9]) by hubbub.cisco.com with SMTP id AA27481 (8.6.4/IDA-1.5 for ); Mon, 11 Apr 1994 17:27:59 -0700 Received: from mailsv.nec.co.jp ([133.200.254.203]) by tyo1.gate.nec.co.jp (8.6.8+2.4Wb/3.2W5) with SMTP id JAA23039 for ; Tue, 12 Apr 1994 09:27:57 +0900 Received: from nsis.cl.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA13664; Tue, 12 Apr 1994 09:27:56 +0900 Received: from europa.nsis.cl.nec.co.jp by nsis.cl.nec.co.jp (5.65c/6.4JAIN-NSIS-940221.1) id AA22779; Tue, 12 Apr 1994 09:27:54 +0900 Received: by europa.nsis.cl.nec.co.jp (5.64/6.4J.6-nsis-ksp-4.10) id AA00475; Mon, 11 Apr 94 19:26:40 -0500 Date: Mon, 11 Apr 94 19:26:40 -0500 From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) Message-Id: <9404120026.AA00475@europa.nsis.cl.nec.co.jp> To: vsta@cisco.com In-Reply-To: Dave Hudson's message of Thu, 7 Apr 1994 09:44:36 +0100 (BST) Subject: 3.5" 1.44 MByte FDD support >BTW, has anyone considered if there'll be a way of redirecting the kernel >debugger output to a windowed screen when MADO's running. A similar but >simpler problem I hit last night was that I had a kernel debugger compiled >for a colour vid which didn't display anything on my mono screen (cons -mono >worked for everything else. I've been away for a few weeks, and I'm just now catching up on my email. Apologies for the late response. This could be hard, because if we are in the kernel debugger, then something bad has happened, and messages are probably not being sent. No messages, no redirection. However, I have some plans to map kernel/server messages to a window. I've got a nice new Pentium PCI/66 coming soon, so I hope to be able to work on VSTa in the same environment as everyone else (no need to port/write driver for the NEC). I'll be changing jobs at the end of this week, and I'll be in the US for a month from the 20th (Rhode Island), so I may or may not get much done. Once I return, things will progress nicely I hope. BTW. Dave, have you done much with the VGA/SVGA version of bitblt? It looks like you been busy doing other stuff. If anyone has some pointers to programming the various VGA/SVGA boards, I'd appreciate it. I got back from the US yesterday, and am still suffering jet lag.... so don't expect too much intelligence today :-) nick From vandys@glare.cisco.com Tue Apr 12 12:26:38 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with SMTP id MAA04204; Tue, 12 Apr 1994 12:26:31 -0700 From: eagle@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by dirt.cisco.com with SMTP id AA05651 (8.6.4/IDA-1.5 for ); Tue, 12 Apr 1994 12:07:49 -0700 Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA02065; Tue, 12 Apr 1994 15:05:11 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA17230; Tue, 12 Apr 1994 15:05:09 -0400 Message-Id: <9404121905.AA17230@wasted.zk3.dec.com> To: vsta@cisco.com Subject: how do capabilities work? Date: Tue, 12 Apr 94 15:05:09 -0400 X-Mts: smtp I have read vsta_intro, and liked a lot of what I see. But I don't understand the "capabilities" description. I like what it says the consequences are, i.e. - a user can create new user IDs with a subset of his/her own privileges, but I don't understand what all these dot-separated numbers represent. Can anyone explain this? From vandys@glare.cisco.com Tue Apr 12 13:38:26 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA04212; Tue, 12 Apr 1994 13:38:25 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA15737; Tue, 12 Apr 1994 13:19:44 -0700 Message-Id: <199404122019.NAA15737@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: eagle@zk3.dec.com Cc: vsta@cisco.com Subject: Re: how do capabilities work? In-Reply-To: Your message of "Tue, 12 Apr 1994 15:05:09 EDT." <9404121905.AA17230@wasted.zk3.dec.com> Date: Tue, 12 Apr 1994 13:19:44 -0700 From: Andrew Valencia [eagle@zk3.dec.com writes:] >I like what it says the consequences are, i.e. - a user >can create new user IDs with a subset of his/her own >privileges, but I don't understand what all these dot-separated >numbers represent. Can anyone explain this? It's very simple in practice, but difficult to describe. Let me try describing it from a POSIX perspective. Recall that POSIX defines other/group/user, defining your increasingly close relationship to an object. In parallel with this, they also define some bits which describe what you can do to an object based on how close your relationship is to the object. For instance, a mode of 0751 on a file owned by group 9 user ID 11, means that user ID 11 gets all three bits (Read, Write, Execute), group 9 gets Read/Execute, and others get just Execute. Now, let's restate the exact same protection system in a different way. First, the question of "closeness" is simply the question of how far a UID matches a protection ID. So if you are (in POSIX-ese) group 9, user ID 11, then your ID would be: 9.11 And when you look at a file, it has a protection which might look the same: 9.11 Finally, in parallel with this file protection you get a matching set of bits which tells you what to grant: 1.5.7 Which, matching from the least specific to most, says "other" gets 1 (execute), group 9 gets 5 (read+execute), and user ID 11 gets 7 (read/write/execute). Now, if you're still in group 9, but your user ID is 12, then your ID: 9.12 Matches the file's protection ID up to 9, but not through 11 any more. Thus, of the 1.5.7 bits, you get 1 (everybody does), and 5 (because you matched through 9). You don't get 7, because 12 doesn't match 11. Thus, the VSTa protection scheme is a simple generalization of POSIX's 3-level scheme. Instead of only allowing group.user, the dotted numbers can be longer, describing a hierarchical ID space which can be organized as needed. Also, all the nasty special cases of group lists, saved UIDs, effective UIDs, and so forth are mostly subsumed by the generalization that a user (rather, his processes) can have an arbitrary number of IDs. Access to an object is the sum of access gained by each ID held. Andy From vandys@glare.cisco.com Tue Apr 12 15:09:13 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA04221; Tue, 12 Apr 1994 15:09:11 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA21212 for ; Tue, 12 Apr 1994 14:50:32 -0700 Message-Id: <199404122150.OAA21212@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: PATH on VSTa Date: Tue, 12 Apr 1994 14:50:31 -0700 From: Andrew Valencia Hmmm... my port of ash does not pass environment variables downwards correctly. When you log on (or in your sh.pro) you can: echo -n "/vsta/bin:." > /env/PATH Which will set a default path system-wide. Or to /env//PATH to set a per-user default. Andy From vandys@glare.cisco.com Wed Apr 13 00:46:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id AAA04261; Wed, 13 Apr 1994 00:46:53 -0700 Received: from pamir.inria.fr by hubbub.cisco.com with SMTP id AA23803 (8.6.4/IDA-1.5 for ); Wed, 13 Apr 1994 00:28:15 -0700 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 13 Apr 94 09:28:08+0200 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 13 Apr 94 09:28:20-0100 Date: 13 Apr 94 09:28:20-0100 From: Basile STARYNKEVITCH Message-Id: <9404130728.AA00479@rosser.serma.cea.fr> To: vsta@cisco.com Cc: vandys@cisco.com Subject: about VSTa - installing without Dos?? Content-Length: 1565 Hello all, I'm becoming really interested by VSTA now (i'm on the mailing list since a few months). However, i do have a problem: I don't have (and don't want to steal or buy) Messy Loss (ie MS-DOS). My home PC (a 486DX/66 with 16Mb RAM, ET4000 Vlb graphic card, 240IDE disk, adaptec1522 compatible clone controller with a 240Mb scsi disk -i'lll soon buy a 1Gb disk- and a Qic-150 archive viper tape streamer) does not have Messy Loss. I'm an enthousiastic Linux user. I would like to install and play with VSTa (and perhaps even hack it, eg add a Linux Ext2fs filesystem server into it... but i don't promise anything yet), but i don't have and do not wish to have Dos -even just for VSTa installation. (Messy Loss is a virus I don't want to install on my PC). Is it possible to install VSTa on a PC without Dos? Ideally i would like to install it from bootable floppies on an IDE (or Scsi) disk partition. I could hack and use Linux utilities to install it, but i don't want to need DOS! Any ideas, explanations, suggestions, remarks, etc... (feel free to reply to the VSTa mailing list)? Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 Linuxing (and perhaps soon VSTaling) at home only. N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. From vandys@glare.cisco.com Wed Apr 13 02:05:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with SMTP id CAA04269; Wed, 13 Apr 1994 02:05:10 -0700 Received: from hof (hof.daimi.aau.dk) by hubbub.cisco.com with SMTP id AA25706 (8.6.4/IDA-1.5 for ); Wed, 13 Apr 1994 01:46:33 -0700 Received: by hof (Linux Smail3.1.28.1 #1) id m0pr0eW-0002gbC; Wed, 13 Apr 94 10:50 MET DST Message-Id: Date: Wed, 13 Apr 94 10:50 MET DST From: tthorn@daimi.aau.dk (Tommy Thorn) To: vsta@cisco.com Subject: VSTa hangs Sadly, VSTa will hang on me quite easily: Using a vanilla install. Log in as vandys/test $ echo -n "/vsta/bin:." > /env/PATH $ echo -n "vt100" > /env/TERM $ cd / $ echo 'main(){printf("hello world\n");}' > hw.c $ gcc -c hw.c (ok!) $ gcc hw.o (and it hangs) The kernel debugger says ld sleeps, or more precise: >pr 46 46 ld vas 1316c80 threads 136f900 runq 13169a0 sys/usr 5/2 sema 13f104c prefs 0 nopen 10 all 13f1200 handler 0 children 1316960 parent 1316b20 pgrp 0x1415d9a0 ports: open: 1309f00 1309280 1309480 1309680 1309900 1309e80 1309880 1309700 1309c00 1309e00 prot: 0, 1+0, 1+1f ids: 3.1(1) 1.1(1) debug port/name: 0x0/0x0 flags 0x0 47 SLEEP kstack c1f000 uregs c1ffc0 wchan 1309294 / kregs 136f904 proc 13f1000 ustack 7fff0000 runq 1316980 runticks 4 flags: hd 136f900 tl 136f900 next 0 msgwait 136f954 qsav 136f960 probe 0 err invalid usr/sys 2/0 evq 136f9c0 eng 409650 puhh. I hope this means something to someone. ;^) /Tommy From vandys@glare.cisco.com Wed Apr 13 09:50:24 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA04294; Wed, 13 Apr 1994 09:50:23 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA27489; Wed, 13 Apr 1994 09:31:31 -0700 Message-Id: <199404131631.JAA27489@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: tthorn@daimi.aau.dk (Tommy Thorn) Cc: vsta@cisco.com Subject: Re: VSTa hangs In-Reply-To: Your message of "Wed, 13 Apr 1994 10:50:00 +0700." Date: Wed, 13 Apr 1994 09:31:31 -0700 From: Andrew Valencia [tthorn@daimi.aau.dk (Tommy Thorn) writes:] >Sadly, VSTa will hang on me quite easily: Dave indicates that he has seen the DOS server dying. This would do in any process using the filesystem. Could you repeat this, but in /vsta? The DOS root directory is a special case (due to the DOS filesystem's evolution) and is (in hindsight) much less tested than the "usual" DOS subdirectory code. Andy From vandys@glare.cisco.com Thu Apr 14 19:46:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00200; Thu, 14 Apr 1994 19:46:33 -0700 Received: from news.std.com (news.std.com [192.74.137.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA07704 for ; Thu, 14 Apr 1994 19:29:12 -0700 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA10853; Thu, 14 Apr 1994 22:29:10 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA14671; Thu, 14 Apr 1994 22:29:08 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199404150229.AA14671@world.std.com> Subject: CDROM filesystem To: vsta@cisco.com Date: Thu, 14 Apr 1994 22:29:08 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 798 Hi, The latest version of the SCSI/CAM driver has preliminary support for CDROM drives, so its time to start thinking about a CDROM filesystem for VSTa. Here are some issues: 1) The most popular CDFS format seems to be based on the High Sierra/ISO 9660 specification. Is this spec. available electronically, or is it necessary to get hardcopy from someplace like Global Engineering? 2) Does anyone know of a CDFS that can be ported to VSTa? 3) There are some similarities between the High Sierra filesystems and the DOS FAT filesystem. Would it be reasonable to try to modify the DOS server to support High Sierra-like filesystems? It looks like writing/porting a CDFS to VSTa would make an entertaining project. Anyone interested in taking it on? Regards, Mike Larson From vandys@glare.cisco.com Fri Apr 15 06:14:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00227; Fri, 15 Apr 1994 06:14:06 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA27682 for ; Fri, 15 Apr 1994 05:56:44 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa17841; 15 Apr 94 13:48 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0prn5f-0002j8C; Fri, 15 Apr 94 13:33 BST Message-Id: From: Dave Hudson Subject: Re: about VSTa - installing without Dos?? To: VSTa mailing list Date: Fri, 15 Apr 1994 13:33:47 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1708 Hi all, I just tried mailing this direct but forgot to cc the list - anyway the return address bounced so here's my somewhat belated reply :-( > Basile STARYNKEVITCH wrote: > > > > Hello all, > > > > I'm becoming really interested by VSTA now (i'm on the mailing list > > since a few months). > > > > Any ideas, explanations, suggestions, remarks, etc... (feel free to > > reply to the VSTa mailing list)? > > I have some boot code that will allow you to generate a boot floppy under > Linux - basically it builds an image file from the servers listed in a > "boot.lst" file and then dumps the whole lot out to the floppy. It's not a > particularly elegant way of handling things, but it works :-) The biggest > downside is that you can't just edit boot.lst to change the way things load. > As soon as I can complete a port of dd I'll be able to build boot floppies > under VSTa as well as Linux. > > I'm working on a new loader (something like LILO) that will hopefully boot > VSTa, DOS, OS/2 and Linux, but that's probably a few months off (I've got > too many more important bits of code to do yet). The VSTa load will use the > version of bfs I rewrote for 1.3 (plus a few as yet unfinished additions), > as it's simple enough to allow me to write some real mode assembler code to > read the fs and build the boot images. This is easy on a raw bfs partition, > but I need to do some code that will identify all of the sectors in a file > for say a dos partition so that the boot loader will know where to find the > sectors of a bfs if it actually resides on another fs instead of a raw > partition. > > Let me know if you want the code as it stands so far :-) > > > Regards, > Dave > From vandys@glare.cisco.com Sun Apr 17 11:04:09 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00420; Sun, 17 Apr 1994 11:04:07 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA00629; Sun, 17 Apr 1994 10:46:57 -0700 Message-Id: <199404171746.KAA00629@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: MR Cc: vsta@amri.cisco.com Subject: Re: /env In-Reply-To: Your message of "Sun, 17 Apr 1994 18:06:24 EST." Date: Sun, 17 Apr 1994 10:46:56 -0700 From: Andrew Valencia [MR writes:] >But this is not the only reason why I'm writing. Could you please give >an explanation of the subdirectories below /env/, especially /env/# ? /env is the environment server. It is a hierarchical name space like most filesystems, but has the special property that a lookup will keep checking in ".." until it reaches the top. So if you have: File Contents /env/XYZ foo /env/vandys/XYZ bar Then getenv() for me, vandys, will return "bar", but everybody else would see "foo". This is because getenv() starts from /env/USER (actually, /env/USER/#, but I'll get to that in a second) when it tries to find the environment variable XYZ. For vandys it finds /env/vandys/XYZ, but for, say, "joe", it tries /env/joe/XYZ, doesn't find it, tries /env/XYZ, finds it, and returns that value. Note that: echo -n bletch > /env/XYZ would change the environment variable on the fly for everybody except vandys, who would continue to see the value in /env/vandys/XYZ. Now, the wrinkle is how to preserve per-process environment variable semantics for those cases where this is really what you want. The directory "#" is a special directory which conceptually resides in /env/USER/#. Unlike any other directory, entries within it are copy-on-write. If one of my processes setenv()'s XYZ to "one", the entry /env/vandys/#/XYZ is filled in with this value. If my process then fork()'s, the # node is transparently converted so that both parent and child processes see a /env/vandys/#/XYZ. But if either changes it, their change remains private to themselves. Thus, environment variables in /env/user/# behave like old, classic environment variables, while variables elsewhere in the /env hierarchy behave like global system variables in a arbitrarily hierarchical namespace. BTW, /env/# is just a shortcut for /env/USER/#, for the purposes of how the /env/server is used. #'s location is set by mkdir'ing this name at the point below which you want to maintain your process-private names. For VSTa's current login and friends, this is /env/USER/#. Doing it this way spares the /env server having to know about user names and such. After you've done this, # means this location no matter what path you use to access it. Andy From vandys@glare.cisco.com Sun Apr 17 18:05:29 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00442; Sun, 17 Apr 1994 18:05:28 -0700 Received: from news.std.com (news.std.com [192.74.137.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA19487 for ; Sun, 17 Apr 1994 17:48:25 -0700 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA13742; Sun, 17 Apr 1994 20:48:24 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA05845; Sun, 17 Apr 1994 20:48:22 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199404180048.AA05845@world.std.com> Subject: VSTa 1.3 impressions To: vsta@cisco.com Date: Sun, 17 Apr 1994 20:48:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 423 Hi, Well, I've been running VSTa 1.3 for a few days now, and I must say that I like it a lot. The new features that I've used so far are great (I especially like the multiple virtual consoles), new servers are sprouting up, and the system is much more reliable. In general, I'd say that VSTa is getting to be a very good software development environment. Good job to all involved, particularly Andy! Mike Larson From vandys@glare.cisco.com Mon Apr 18 14:05:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00581; Mon, 18 Apr 1994 14:05:40 -0700 Received: from decvax.dec.com (decvax.zk3.dec.com [16.140.0.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA01258 for ; Mon, 18 Apr 1994 13:48:36 -0700 From: eagle@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16308; Mon, 18 Apr 1994 16:48:33 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA21349; Mon, 18 Apr 1994 16:48:32 -0400 Message-Id: <9404182048.AA21349@wasted.zk3.dec.com> To: vsta@cisco.com Subject: problem with ftp of 1.3 Date: Mon, 18 Apr 94 16:48:32 -0400 X-Mts: smtp I ftp'd all of the 1.3 files from ftp.cisco.com and took them home. I could only decompress a few of the archives. The rest were corrupted. I copied them over more than once and they compared so it wasn't a problem with the ftp. I can decompress binutl.tz under DOS, and several others. But I can't decompress several on either DOS or UNIX: ash, bin86, emacs, gas, gcc, less, make, rc, vsta, and vsta_bin. I can also decompress binutl under UNIX. I know other folks have had success getting these archives onto their PCs. But perhaps someone could give a clue regarding my difficulties. Has anyone put VSTa out onto a BBS anywhere? I could download it then directly to my PC, even if it were long distance. From vandys@glare.cisco.com Wed Apr 20 08:56:21 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00675; Wed, 20 Apr 1994 08:56:19 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA08512 for ; Wed, 20 Apr 1994 08:39:32 -0700 Message-Id: <199404201539.IAA08512@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: v1.3 bug fixes Date: Wed, 20 Apr 1994 08:39:31 -0700 From: Andrew Valencia With the help of Dave Hudson, I've fixed a number of small memory leaks in the system, adding a fairly comprehensive set of instrumentation for tracking memory use in the process. I've also found a bug in the DOS server which bit some folks doing "make install" which overwrote an executable which was currently running. Actually, the DOS server would have done the right thing on last close, but since the executable never exit()'ed, it never got written, so the file was bad on next reboot. strip(1) was missing from the distribution, sh(1) didn't do the right thing when you set environment variables through the shell, and there were a couple smaller things I fixed. Look for a v1.3.1 soon--and if you have further contributions, let me know soon. In particular, I believe there's still an unexplained DOS server death to hunt. I haven't seen it here. Andy From vandys@glare.cisco.com Tue Apr 26 20:58:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA00616; Tue, 26 Apr 1994 20:58:38 -0700 Received: from kepler.physics.uq.oz.au (kepler.physics.uq.oz.au [130.102.120.12]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id UAA14596 for ; Tue, 26 Apr 1994 20:43:03 -0700 Received: from wigner.physics.uq.oz.au by kepler.physics.uq.oz.au with SMTP (1.37.109.8/16.2) id AA09717; Wed, 27 Apr 1994 13:43:35 +1000 Received: by wigner.physics.uq.oz.au; id AA02161; Wed, 27 Apr 1994 13:43:00 +1000 Date: Wed, 27 Apr 1994 13:43:00 +1000 From: Michael Werner Message-Id: <9404270343.AA02161@wigner.physics.uq.oz.au> To: vsta@cisco.com Subject: vsta ports Are there any people working on ports to RISC machines. I have a MIPS machine at home I would love to develop vsta system on. I would like to add that VSTa is an interesting system and I would prefer that it didn't bloat and become an all-things-to-all-people kernel. An awful lot can be done and learnt from this existing base. What are the procedures for submitting kernel mods? (small ones of course :-) Mike From vandys@glare.cisco.com Tue Apr 26 21:59:59 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA00624; Tue, 26 Apr 1994 21:59:57 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA11849; Tue, 26 Apr 1994 21:44:37 -0700 Message-Id: <199404270444.VAA11849@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Michael Werner Cc: vsta@cisco.com Subject: Re: vsta ports In-Reply-To: Your message of "Wed, 27 Apr 1994 13:43:00 +1000." <9404270343.AA02161@wigner.physics.uq.oz.au> Date: Tue, 26 Apr 1994 21:44:37 -0700 From: Andrew Valencia [Michael Werner writes:] >Are there any people working on ports to RISC machines. >I have a MIPS machine at home I would love to develop >vsta system on. I would love to have a port to a non-x86 platform, so I can find/fix x86-specific things which have crept into otherwise portable code. >I would like to add that VSTa is an interesting system >and I would prefer that it didn't bloat and become >an all-things-to-all-people kernel. An awful lot can >be done and learnt from this existing base. We've already fought this battle a couple times. I basically want a microkernel operating system. I'd like it to do POSIX ".1", but I'm willing to skip parts if they would otherwise make a mess of the whole system (job control comes to mind). At this point I only consider kernel enhancements if they *really* are required. The last big one was to support process debugging, and it's #ifdef'ed so you can build a smaller embedded kernel once you're done debugging. Support for the 387 FPU will (reluctantly) be added at some point. >What are the procedures for submitting kernel mods? >(small ones of course :-) Send them to me (vandys@cisco.com). If you think there's an interesting issue to them, of course feel free to send them to the list. Regards, Andy From vandys@glare.cisco.com Wed Apr 27 07:55:56 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00654; Wed, 27 Apr 1994 07:55:54 -0700 Received: from (ogion.mcs.kent.edu [131.123.2.53]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA05527 for ; Wed, 27 Apr 1994 07:40:35 -0700 Received: from localhost.ARPA by (930416.SGI/92.09.25) id AA08584; Wed, 27 Apr 94 10:34:16 -0400 Message-Id: <9404271434.AA08584@> From: sjc@mcs.kent.edu (Steve Chapin) To: Michael Werner Cc: vsta@cisco.com Zevon-Of-The-Day: Lawyers, Guns and Money Subject: Re: vsta ports In-Reply-To: Your message of Wed, 27 Apr 1994 13:43:00 EDT. <9404270343.AA02161@wigner.physics.uq.oz.au> Date: Wed, 27 Apr 1994 10:34:16 -0400 Sender: sjc@mcs.kent.edu >> Are there any people working on ports to RISC machines. >> I have a MIPS machine at home I would love to develop >> vsta system on. I've got a grad student working on porting VSTa to a PMAX (DecStation 3100). However, it's not moving very quickly, so I hesitate to say that we're working on it (yet). sc -- From vandys@glare.cisco.com Wed Apr 27 11:09:14 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00676; Wed, 27 Apr 1994 11:09:13 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA04943 for ; Wed, 27 Apr 1994 10:53:56 -0700 Message-Id: <199404271753.KAA04943@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: VSTa v1.3.1 available Date: Wed, 27 Apr 1994 10:53:56 -0700 From: Andrew Valencia With the initial flurry of bugs found in v1.3 slowing, I have assembled v1.3.1. It fixes some kernel memory leaks (blush), a bad debug assertion, a number of very minor details, and a bug in the DOS filesystem server which could cause filesystem corruption when overwriting an active executable. It is in ftp.cisco.com:vandys/vsta, and I'm sure it'll be mirrored to the usual places shortly. Andy From vandys@glare.cisco.com Thu Apr 28 13:36:50 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA01282; Thu, 28 Apr 1994 13:36:49 -0700 Received: from csn.org (root@csn.org [128.138.213.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA15999 for ; Thu, 28 Apr 1994 13:21:38 -0700 Received: by csn.org with UUCP id AA04146 (5.65c/IDA-1.4.4 for vsta@cisco.com); Thu, 28 Apr 1994 14:21:33 -0600 Received: by loon.probita.com (5.57/Probita 2/6/94) id AA10860; Thu, 28 Apr 94 08:03:18 -0600 Date: Thu, 28 Apr 94 08:03:18 -0600 From: blund@probita.com (Bob Lund) Message-Id: <9404281403.AA10860@loon.probita.com> To: vsta@cisco.com Subject: Getting emacs to run Hi, I'm trying to run emacs under vsta 1.3.1 and having no luck. I have set the TERM file to 'pc' and 'ibmpc' in both /env and /env/my_login. When I run emacs is says that either of those are unknown terminal types, even though I can find a valid entry in termcap in /vsta/lib/termcap for both. Any suggestions would be most welcome. Thanks in advance. Bob Lund blund@probita.com From vandys@glare.cisco.com Fri Apr 29 09:21:00 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01336; Fri, 29 Apr 1994 09:20:59 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA22243; Fri, 29 Apr 1994 09:05:52 -0700 Message-Id: <199404291605.JAA22243@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: blund@probita.com (Bob Lund) Cc: vsta@amri.cisco.com Subject: Re: Getting emacs to run In-Reply-To: Your message of "Fri, 29 Apr 1994 07:57:05 MDT." <9404291357.AA20733@loon.probita.com> Date: Fri, 29 Apr 1994 09:05:51 -0700 From: Andrew Valencia [blund@probita.com (Bob Lund) writes:] >Thanks for the suggestion. Does using nansi require using a nansi.sys driver >in DOS? Also, I got ibmpc to work. Turns out that there was a '\n' at the >end of 'ibmpc' in the TERM file. When I got rid that it worked fine. No, once VSTa takes over there's *nothing* left from DOS. I just happen to have used the escape sequences of NANSI. Yes, doing: echo nansi > /env/TERM will stick you with that newline; use echo -n nansi > /env/TERM instead. Glad you got things working! Andy From vandys@glare.cisco.com Fri Apr 29 09:57:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01343; Fri, 29 Apr 1994 09:57:38 -0700 Received: from spock.ebt.com (spock.ebt.com [192.111.115.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA28227 for ; Fri, 29 Apr 1994 09:42:08 -0700 Received: from ebt.com (kirk.ebt.com) by spock.ebt.com (4.1/SMI-4.1-NEARNet-A) id AA02767; Fri, 29 Apr 94 12:41:31 EDT Received: by ebt.com (4.1/SMI-4.1-NEARnet) id AA21167; Fri, 29 Apr 94 12:41:30 EDT Date: Fri, 29 Apr 94 12:41:30 EDT From: gtn@ebt.com (Gavin Nicol) Message-Id: <9404291641.AA21167@ebt.com> To: vsta@cisco.com Subject: PCI Bus Does anyone have any inoformation of VSTa running on PCI bus machines? My guess is that it should work without any major problems... nick From vandys@glare.cisco.com Fri Apr 29 15:30:04 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA01385; Fri, 29 Apr 1994 15:30:02 -0700 Received: from localhost.cisco.com by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA16242; Fri, 29 Apr 1994 15:15:00 -0700 Message-Id: <199404292215.PAA16242@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@uhunix.uhcc.Hawaii.Edu Cc: vsta@amri.cisco.com Subject: Re: VSTa... In-Reply-To: Your message of "Fri, 29 Apr 1994 11:49:43 -1000." <9404292149.AA12079@> Date: Fri, 29 Apr 1994 15:15:00 -0700 From: Andrew Valencia [newsham@uhunix.uhcc.Hawaii.Edu writes:] >Does the 68k port have a mailing list of their own or do they >use the main list? How can I get in touch with the people/person >doing the port? There has been so little activity that the answer is "neither". You should bounce a message off the list to stir up a discussion. As I recollect, the big problem is that there are lots of boards with 68000's or EC (Embedded Controller) parts which lack an MMU. VSTa uses VM in support of messaging, so either it's a rewrite of the messaging part of VSTa (plus rewrite of how exec'ing of files is done, plus no doubt lots of other things) or you have to connect with folks using an '020+PMMU or '030. The '040 uses incompatible data structures (three level PTE tree) which can add to the complexity if you want to support it as well. I believe both the '020 and '030 can do the three level format, so that might be your lowest common denominator. cisco routers are 68K based so a cross compilation is trivial for me. It's just that all our boxes use EC parts, so I can't do a port to them. If I had an Amiga or HP 300 I could cross compile something for them. The VM part of the port is pretty simple as the PMMU and '030 use a structure almost identical to the i386. All that remains is a little assembly language stuff and a base set of servers--console and disk, in particular. Probably not even disk, to get started--use the /tmp file server and exercise context switching and stuff like that first. I'm Cc'ing the list because I guess I've written enough now to wake up anybody with latent desires of a 68030 port of VSTa. :-) Andy From vandys@glare.cisco.com Fri Apr 29 15:44:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA01389; Fri, 29 Apr 1994 15:44:17 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA13493; Fri, 29 Apr 1994 15:29:05 -0700 Received: from darkstar.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA01927; Fri, 29 Apr 94 15:28:56 PDT Received: by darkstar.cygnus.com (4.1/SMI-4.1) id AA11110; Fri, 29 Apr 94 16:28:53 MDT Message-Id: <9404292228.AA11110@darkstar.cygnus.com> From: rob@darkstar.cygnus.com (Rob Savoye) Date: Fri, 29 Apr 1994 16:28:53 MDT In-Reply-To: Andrew Valencia ' <199404292215.PAA16242@glare.cisco.com> Re: VSTa... Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Andrew Valencia , newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: VSTa... Cc: vsta@amri.cisco.com From: Andrew Valencia Subject: Re: VSTa... > >Does the 68k port have a mailing list of their own or do they > >use the main list? How can I get in touch with the people/person > >doing the port? > > I'm Cc'ing the list because I guess I've written enough now to wake up > anybody with latent desires of a 68030 port of VSTa. :-) I've thought about this several times, I have several m68k boards, (030 too) and a complete set of GNU tools for cross development. To be honest, I haven't done more than think about it. I want to get the ports of GNU for the i386-aout (VSTa) get done and on the net. So far the current release of GAS, LD, and the binutils now have this support in them, I'm trying to finish GCC. (then GDB) - rob - From vandys@glare.cisco.com Sat Apr 30 11:48:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01499; Sat, 30 Apr 1994 11:48:31 -0700 Received: from math.tau.ac.il (taurus.math.tau.ac.il [132.67.64.4]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA19056 for ; Sat, 30 Apr 1994 11:33:28 -0700 From: laden@math.tau.ac.il Received: from virgo.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-930921) id AA22715; Sat, 30 Apr 94 21:17:21 +0300 Received: by virgo.math.tau.ac.il (5.67/math.sub-st921020) id AA25071; Sat, 30 Apr 94 21:17:20 +0300 Message-Id: <9404301817.AA25071@virgo.math.tau.ac.il> Subject: newbie question To: vsta@cisco.com Date: Sat, 30 Apr 1994 21:17:20 +0300 (GMT+0300) X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1033 hi, i just got release 1.3.1 up, and i'm trying to create a small vfs filesystem going. the way i went about it: i used mkfs_vfs to create a file to 'contain' the filesystem. i uncommented the fstab entry for vfs (it reads: "fs/vfs /v") i changed the inittab entry to "bg:/vsta/boot/vstafs /testfs fs/vfs" when rebooting, i see syslog messages: 2000 sectors 1 free extents 1997 sectors... and i get a login prompt, but when i try and login, i get '/vsta/bin/rc invalid' and i'm back with the login prompt. what (probably obvious) error am i making? btw: i'd like to be able to mount a filesystem while logged on, but can find any mount command in /bin. do i need to write a simple mount() wrapper? i gathered from the mailing list archives that there used to be one, why was it removed? also, the file mkfs_vfs created is 1536 bytes long, does it grow dynamically (i specified 2000 sectors)? disclaimer: i am very new to vsta, and in fact have no experience with OS's at this low level... thanks, guy From vandys@glare.cisco.com Mon May 2 09:55:35 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01780; Mon, 2 May 1994 09:55:33 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA07101; Mon, 2 May 1994 09:40:44 -0700 Message-Id: <199405021640.JAA07101@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: laden@math.tau.ac.il Cc: vsta@cisco.com Subject: Re: newbie question In-Reply-To: Your message of "Sat, 30 Apr 1994 21:17:20 +0300." <9404301817.AA25071@virgo.math.tau.ac.il> Date: Mon, 02 May 1994 09:40:44 -0700 From: Andrew Valencia [laden@math.tau.ac.il writes:] > i used mkfs_vfs to create a file to 'contain' the filesystem. > i uncommented the fstab entry for vfs (it reads: "fs/vfs /v") > i changed the inittab entry to "bg:/vsta/boot/vstafs /testfs fs/vfs" mkfs_vfs -p ... Should pre-allocate (i.e., write each block with zeroes) data. It doesn't appear to be working. :-( >and i get a login prompt, but when i try and login, >i get '/vsta/bin/rc invalid' and i'm back with the login prompt. And this is a bug in libc/open.c. He's being fooled into thinking that /vsta/... matches the /v... mount entry instead of the /vsta/... file within the root (/...) filesystem. Workaround: mount your filesystem as /x instead. >what (probably obvious) error am i making? No error, except that you're probably the second person in the world to play with the vstafs. :-) >btw: i'd like to be able to mount a filesystem while logged on, >but can find any mount command in /bin. do i need to write a >simple mount() wrapper? Since mount tables are an illusion maintained per-process in the C library, mount must be a built-in of the shell. The testsh and rc shells have the built-in, but one has not yet been added for ash. >also, the file mkfs_vfs created is 1536 bytes long, does it grow >dynamically (i specified 2000 sectors)? No, if you're running on top of a file (instead of a device) you need to use the -p. Now, it would appear, you first have to FIX it! It *would* pre-allocate it, except that it'll first try to read a block up there, and the read will fail, which looks like an I/O error to the filesystem, so he bombs out. Filesystem philosophy digression: no, filesystems should not (IMHO) try to keep going in the face of data corruption. In my experience with 4.2 and S5 filesystems, this just makes things worse. If you want to survive I/O errors, run on top of a mirrored volume. End digression. >disclaimer: i am very new to vsta, and in fact have no experience with >OS's at this low level... Well, finding two bugs in your first pass is pretty good! I think I have a fix for the open() bug, but if you'd like to fix the -p one for mkfs_vfs (which is in srv/vstafs/cmd/mkfs.c) and pass me the patch, I'd be happy to add it. Regards, Andy From vandys@glare.cisco.com Mon May 2 11:18:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01786; Mon, 2 May 1994 11:18:53 -0700 Received: from svcs1.digex.net (svcs1.digex.net [164.109.10.23]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA20829 for ; Mon, 2 May 1994 11:04:05 -0700 Received: from comm-data.com (online.comm-data.com) by svcs1.digex.net with SMTP id AA07484 (5.67b8/IDA-1.5 for ); Mon, 2 May 1994 14:03:26 -0400 Received: from sunburst.comm-data.com by comm-data.com (5.0/SMI-SVR4) id AA13733; Mon, 2 May 1994 14:02:58 +0500 Received: by sunburst.comm-data.com (5.0/SMI-SVR4) id AA00661; Mon, 2 May 1994 14:03:30 +0500 From: rmccask@online.comm-data.com (Randy McCaskill) Message-Id: <9405021803.AA00661@sunburst.comm-data.com> Subject: Booting VSTa To: vsta@cisco.com Date: Mon, 2 May 1994 14:03:28 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 326 I am new to VSTa so please excuse any REALLY dumb things that I ask. Now on with my question... Is there currently any other way to boot VSTa other than from DOS? I currently use Linux and it's boot loader LILO. I think that LILO can probably be modified to boot VSTa. -Randy ------ Randy McCaskill rmccask@comm-data.com From vandys@glare.cisco.com Mon May 2 15:02:38 1994 Received: from glare.cisco.com (glare.cisco.com [131.108.11.56]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA01805; Mon, 2 May 1994 15:02:37 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA05859; Mon, 2 May 1994 14:47:50 -0700 Message-Id: <199405022147.OAA05859@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: rmccask@online.comm-data.com (Randy McCaskill) Cc: vsta@cisco.com Subject: Re: Booting VSTa In-Reply-To: Your message of "Mon, 02 May 1994 14:03:28 EDT." <9405021803.AA00661@sunburst.comm-data.com> Date: Mon, 02 May 1994 14:47:50 -0700 From: Andrew Valencia [rmccask@online.comm-data.com (Randy McCaskill) writes:] >Is there currently any other way to boot VSTa other than from DOS? >I currently use Linux and it's boot loader LILO. I think that LILO >can probably be modified to boot VSTa. For now, no. There is some work being done for this, but nothing you can run yet. Andy From vandys@glare.cisco.com Tue May 3 06:03:28 1994 Received: from dirt.cisco.com (dirt.cisco.com [131.108.13.111]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA01854; Tue, 3 May 1994 06:03:27 -0700 Received: from Trantor.DSO.gov.SG (trantor.dso.gov.sg [192.190.204.1]) by dirt.cisco.com (8.6.8+c/CISCO.SUB_GATE.1.1) with SMTP id FAA24394; Tue, 3 May 1994 05:48:33 -0700 Received: by Trantor.DSO.gov.SG (4.1/25-TRANTOR-eef) id AA02947; Tue, 3 May 94 20:52:38 SST From: Tan Pong Heng Message-Id: <9405031252.AA02947@Trantor.DSO.gov.SG> Subject: Re: Booting VSTa To: vandys@cisco.com (Andrew Valencia) Date: Tue, 3 May 94 20:52:37 WST Cc: vsta@cisco.com In-Reply-To: <199405022147.OAA05859@glare.cisco.com>; from "Andrew Valencia" at May 2, 94 2:47 pm X-Mailer: ELM [version 2.3 PL11] > > [rmccask@online.comm-data.com (Randy McCaskill) writes:] > > >Is there currently any other way to boot VSTa other than from DOS? > >I currently use Linux and it's boot loader LILO. I think that LILO > >can probably be modified to boot VSTa. > > For now, no. There is some work being done for this, but nothing you can > run yet. > > Andy > I don't think it is that hard to get VSTa boot under linux. The problem is actually to implement the linux file system under VSTa so that VSTa can access the same file system that it is booted off. LILO will simply load what ever image specified at specific address and jump into it with some argument setting. We can re-write the boot.exe a bit and concatenate the rest of the processes specified in boot.lst now after it. When LILO past the control to the new boot.exe, it simple move them into place instead of loading them into place, the rest should be the same. In fact this should be a worthwhile exercise as it would permit a lot of the Linux developer to participate in the development effort of VSTa. The only problem is we would need a few file system process - EXT, EXT2, XIA, ... -- Tan Pong Heng Defence Science Organization Project Leader 20 Science Park Drive, S(0511)