From vandys@glare.cisco.com Wed Apr 5 05:21:35 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA04270; Wed, 5 Apr 1995 05:21:34 -0700 Received: from zephyr.cs.vu.nl (root@zephyr.cs.vu.nl [130.37.16.3]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id GAA14527 for ; Wed, 5 Apr 1995 06:08:17 -0700 Received: from sloep11.cs.vu.nl by zephyr.cs.vu.nl with smtp (Smail3.1.28.1 #15) id m0rwUoT-00000tC; Wed, 5 Apr 95 15:08 +0200 Date: Wed, 5 Apr 95 15:08:00 MET DST From: Ronald Oussoren To: vsta@cisco.com Subject: Signal() emulation Message-ID: <9504051508.aa12470@sloep11.cs.vu.nl> I found an old (?,1988) version of the POSIX standard in the local library, and I'm now trying to implement the signal functions of POSIX for VSTa, by extending the existing code for signal() (which uses events). Most of it seems to be not to hard. Two two more problematic functions seem to be sigsuspend() (and therefore pause(), the ANSI C equivalent), and alarm(). Sigsuspend() is used to wait for a signal. Currently I have implemented this using busy waiting. Is there a system call to wait for the delivery of an event, and if not, is there a reason for not having it? The other problem is alarm(). Alarm() should make provisions for the (async) generation of a SIGALRM signal after a number of seconds. This part is easy: just fork of a thread that sleeps that number of seconds and then sends the event. However, calling alarm() should also cancel the outstanding timer, and return the number of seconds until the canceled timer would cause a signal. How can this be done from user space? While I am asking questions, why doesn't tfork() allow passing a parameter to the new thread? Wouldn't having this ability make it easier to create thread-safe code (no need for a global variable to pass data to the new thread, like in the implementation of rename()). Ronald From vandys@glare.cisco.com Wed Apr 5 07:24:55 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA04298; Wed, 5 Apr 1995 07:24:54 -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 IAA24142; Wed, 5 Apr 1995 08:11:42 -0700 Message-Id: <199504051511.IAA24142@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ronald Oussoren Cc: vsta@cisco.com Subject: Re: Signal() emulation In-Reply-To: Your message of "Wed, 05 Apr 1995 15:08:00 +0700." <9504051508.aa12470@sloep11.cs.vu.nl> Date: Wed, 05 Apr 1995 08:11:42 -0700 From: Andrew Valencia [Ronald Oussoren writes:] >Sigsuspend() is used to wait for a signal. Currently I >have implemented this using busy waiting. Is there a >system call to wait for the delivery of an event, and >if not, is there a reason for not having it? I believe you can do a timed wait for a LONG time, and the system call will be interrupted on receipt of an event. >The other problem is alarm(). Alarm() should make provisions >for the (async) generation of a SIGALRM signal after a number >of seconds. This part is easy: just fork of a thread that >sleeps that number of seconds and then sends the event. >However, calling alarm() should also cancel the outstanding >timer, and return the number of seconds until the canceled >timer would cause a signal. How can this be done from >user space? You'll need to kill off the thread handling the alarm sending. If you keep the time when alarm() was called, you can get the current time and figure out what time remains. >While I am asking questions, why doesn't tfork() allow >passing a parameter to the new thread? Wouldn't having >this ability make it easier to create thread-safe code >(no need for a global variable to pass data to the new >thread, like in the implementation of rename()). Yes, and this actually came by the list one time. I proposed it, but the general response was muted so I never went ahead. I think I'll add it for 1.4. Andy From vandys@glare.cisco.com Thu Apr 6 09:01:28 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA04505; Thu, 6 Apr 1995 09:01:26 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id JAA17854; Thu, 6 Apr 1995 09:48:18 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa05221; 6 Apr 95 17:24 GMT-60:00 Received: from humbug.demon.co.uk by post.demon.co.uk id aa01110; 6 Apr 95 17:24 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0rwuGv-0003YNC; Thu, 6 Apr 95 17:19 BST Message-Id: From: Dave Hudson Subject: Re: Signal() emulation To: Andrew Valencia Date: Thu, 6 Apr 1995 17:19:05 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199504051511.IAA24142@glare.cisco.com> from "Andrew Valencia" at Apr 5, 95 08:11:42 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: 819 Andrew Valencia wrote: > > >While I am asking questions, why doesn't tfork() allow > >passing a parameter to the new thread? Wouldn't having > >this ability make it easier to create thread-safe code > >(no need for a global variable to pass data to the new > >thread, like in the implementation of rename()). > > Yes, and this actually came by the list one time. I proposed it, but the > general response was muted so I never went ahead. I think I'll add it for > 1.4. I would really like to see this added :-) I didn't have an opinion on this when the issue came up on the mailing list (Feb 94 from what I've just seen), but I've since had a couple of instances where I'd have really liked to be able to do this. I guess there's a backwards compatibility issue, but maybe not that bad? Regards, Dave From vandys@glare.cisco.com Thu Apr 6 19:52:05 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA04565; Thu, 6 Apr 1995 19:52:04 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id UAA14067 for ; Thu, 6 Apr 1995 20:39:00 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA02996 (5.67b8/IDA-1.5 for ); Thu, 6 Apr 1995 22:38:40 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id WAA13040 for vsta@cisco.com; Thu, 6 Apr 1995 22:40:32 -0500 From: David Jeske Message-Id: <199504070340.WAA13040@fiction.isdn.uiuc.edu> Subject: VSTa WWW Page To: vsta@cisco.com Date: Thu, 6 Apr 1995 22:40:32 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 861 I put togeather a WWW page for VSTa, it is available at: "http://www.cen.uiuc.edu/~jeske/VSTa" If you would like to have something on the page, just email it to me in whatever form, I'll turn it into HTML if necessary, so no HTML knowledge is necessary. Also, I wasn't sure what to do with the "People" list, if you would like your name listed with or without a link, send the information to me and I'll put it in. Unrelated to that, as some of you may have noticed my Sun is no longer available for ftp (genesis.isdn.uiuc.edu). It wasn't being used for much, and I needed the money for school so I sold it... -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Sun Apr 9 00:16:18 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA04912; Sun, 9 Apr 1995 00:16:16 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA04041; Sun, 9 Apr 1995 01:03:25 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA21312 (5.67b8/IDA-1.5); Sun, 9 Apr 1995 01:07:48 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id BAA20347; Sun, 9 Apr 1995 01:09:40 -0500 From: David Jeske Message-Id: <199504090609.BAA20347@fiction.isdn.uiuc.edu> Subject: Re: Problem with v133 To: vandys@cisco.com (Andrew Valencia) Date: Sun, 9 Apr 1995 01:09:40 -0500 (CDT) Cc: joerg.wittenberger@inf.tu-dresden.de, vsta@cisco.com In-Reply-To: <199502071924.LAA04594@glare.cisco.com> from "Andrew Valencia" at Feb 7, 95 11:24:07 am X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2790 > [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] > > >Now I did an ls, works. cd'd to vsta, ls, works. But whenever I cd > >into a second subdir and do an ls there the dos server dies. > > You need to gather a stack backtrace of the DOS server, along with the > output of "tf". Obviously, I was able to cd down multiple levels of > directories, so it's not a generic problem. I have the same problem, in fact, I can't "ls" in / either. I actually have a few variables going on in my system which may spice it up a bit, I figure one of them is responsible for whatever the VSTa dos server dosn't like. However, everything else thinks the FAT is fine so it probably is actually a VSTa dos server problem. (VSTa dos surely is tempermental) 1) I have OS/2 on my machine and it stores weird "wp root.sf" files for Extended Attributes on FAT. (actually one file in the root directory) 2) I have Win95 on my machine and it has long filename extensions (it's some backward compatible thins.. OS/2 has no problem with it) 3) I untarred vsta from Linux directly onto the msdos partition. Having all these variables probably dosn't help, but then again, it brings out the best bugs :) I used to only have problems doing "ls" in the root directory so I just stayed below "vsta". Since I installed 1.3.3 I can't "ls" in several of the places below /vsta. (when I say "ls" replace that with "do anything usefull in the directory") Anyhow, As soon as I can clean up the FAT enough so VSTa will let me compile (or even get into srv/dos for that matter) I'll try and see what I can do. Here is a "bt" from right after it died: trace(0x0,0xc0de88,0x1ffc1c0,0x1ffc100) called from do_cmd+a5 do_cmd(0xc0de88) called from dbb_main+92 dbg_main(0x2d6b) called from dbg_enter+15 dbg_enter(0xae69,0x8) called from do_exit+104 do_exit(0x10000,0x1ffe734,0xc0df98) called from sendev+62 sendev(0x1ffc100,0xc0df98) called from check_events+104 check_events(0x5b5a,0x7fffff20,0x7ffffe8c,0x12c8) called from trap_2eb trap(0x2b002b,0x7fffff30,0x7fffff20,0x7ffffe8c) called from trap_common+10 and output of "tf" Trap type 255 err 0x0 eip 0x33:0x599a eax 0x00 ebx 0x5b5a ecx 0x5 edx 0x400000 esi 0x7fffff20 edi 0x7fffff30 esp 0x2b:0x7ffffe70 ebp 0x7ffffe8c eflags 0x246 I don't know how helpfull that is, since it's not a "dos" backtrace. At the risk of saying something stupid, why does it trap? Is that an "intentional" trap because the filesystem disappeared? -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Sun Apr 9 01:14:04 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA04917; Sun, 9 Apr 1995 01:14:02 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id CAA05958 for ; Sun, 9 Apr 1995 02:01:11 -0700 Received: from punt.demon.co.uk by disperse.demon.co.uk id aa13596; 9 Apr 95 10:01 GMT-60:00 Received: from humbug.demon.co.uk by punt.demon.co.uk id aa20432; 9 Apr 95 9:57 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0rxsnl-0003nnC; Sun, 9 Apr 95 09:57 BST Message-Id: From: Dave Hudson Subject: Re: Problem with v133 To: jeske@uiuc.edu Date: Sun, 9 Apr 1995 09:57:00 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199504090609.BAA20347@fiction.isdn.uiuc.edu> from "David Jeske" at Apr 9, 95 01:09:40 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: 650 Hi David, David Jeske wrote: > [...problem with dos fs deleted...] I seem to remember you've got Linux on your system - if you can dump some sectors with dd and mail them to me I can probably make a pretty good guess at the problem. This is how I fixed some OS/2 HPFS problems for Linux and some problems with OS/2 swapfiles with mkdosfs. If you can let me know how big your dos partition is and what your disk parameter are I can make a guess at which sectors would be most useful to me. I believe MS published a book with the spec for the new FAT fs used in Windows 95 so maybe that would be a good place to look too. Regards, Dave From vandys@glare.cisco.com Sun Apr 9 15:26:57 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05007; Sun, 9 Apr 1995 15:26:55 -0700 Received: from dam.CharlesView.COM (dam.charlesview.com [199.103.137.242]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id QAA17069 for ; Sun, 9 Apr 1995 16:14:09 -0700 Received: (from smap@localhost) by dam.CharlesView.COM (8.6.11/1.0ckc) id TAA08631 for ; Sun, 9 Apr 1995 19:14:19 -0400 Received: from ray(199.103.137.241) by dam via smap (V1.3) id sma008627; Sun Apr 9 19:13:56 1995 Received: (calvin@localhost) by ray.charlesview.com (8.6.11/8.6.10) id TAA01872; Sun, 9 Apr 1995 19:15:12 -0400 Date: Sun, 9 Apr 1995 19:15:12 -0400 Message-Id: <199504092315.TAA01872@ray.charlesview.com> From: Calvin Clark To: vsta@cisco.com Subject: chdir() in VSTa 1.3.3 libc always returns 0 I was trying to write a simple "find" utility because I didn't have a port handy and I was getting tired of trying to find files by hand. I noticed that chdir() always returns 0, even if you try to go to a directory that doesn't exist. A brief glance at the definition in libc/open.c shows that in fact this is the case. There's also an open_c.vim file in the distribution, which suggests someone was hacking on the file at the time. I'll patch it up in my own sources but I was wondering if there is an "official" fix that has been adopted for this. -Calvin From vandys@glare.cisco.com Sun Apr 9 15:41:29 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05019; Sun, 9 Apr 1995 15:41:28 -0700 Received: from dam.CharlesView.COM (dam.charlesview.com [199.103.137.242]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id QAA17569 for ; Sun, 9 Apr 1995 16:28:42 -0700 Received: (from smap@localhost) by dam.CharlesView.COM (8.6.11/1.0ckc) id TAA08640 for ; Sun, 9 Apr 1995 19:28:52 -0400 Received: from ray(199.103.137.241) by dam via smap (V1.3) id sma008636; Sun Apr 9 19:28:45 1995 Received: (calvin@localhost) by ray.charlesview.com (8.6.11/8.6.10) id TAA01875; Sun, 9 Apr 1995 19:30:01 -0400 Date: Sun, 9 Apr 1995 19:30:01 -0400 Message-Id: <199504092330.TAA01875@ray.charlesview.com> From: Calvin Clark To: vsta@cisco.com Subject: keyboard layouts I've been typing with a dvorak layout for a few years now and qwerty gives me headaches, so I hacked the isr.c files to read dvorak. The keyboard table is duplicated in many places. For right now I just hard-coded the change, but it would be better to have they layout be dynamic so that it can be changed to any arbitrary table with an external program like Linux's "keymap" command. I don't see any pressing reason to have a separate table for the virtual consoles, the kernel debugger and the rs232 code, so it could be just a single internal table. On the other hand, it might be nice to be able to have different layouts on different virtual consoles (something Linux doesn't support) though it might mean a bit more code. Any opinions on the matter? -Calvin From vandys@glare.cisco.com Sun Apr 9 15:41:26 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05016; Sun, 9 Apr 1995 15:41:25 -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 QAA01003; Sun, 9 Apr 1995 16:28:38 -0700 Message-Id: <199504092328.QAA01003@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Calvin Clark Cc: vsta@cisco.com Subject: Re: chdir() in VSTa 1.3.3 libc always returns 0 In-Reply-To: Your message of "Sun, 09 Apr 1995 19:15:12 EDT." <199504092315.TAA01872@ray.charlesview.com> Date: Sun, 09 Apr 1995 16:28:38 -0700 From: Andrew Valencia [Calvin Clark writes:] >I was trying to write a simple "find" utility because I didn't have a >port handy and I was getting tired of trying to find files by hand. >I noticed that chdir() always returns 0, even if you try to go to >a directory that doesn't exist. A brief glance at the definition in >libc/open.c shows that in fact this is the case. There's also an >open_c.vim file in the distribution, which suggests someone was >hacking on the file at the time. FWIW, I have a port of "rh"; it runs much like "find", but uses a C-like syntax. It's in the 1.3.3 distribution. >I'll patch it up in my own sources but I was wondering if there is an >"official" fix that has been adopted for this. The problem is harder than you think. Because the mount table is lexical, you could have something mounted as /usr/local/bin, but nothing specifically mounted as /usr or /usr/local. So if you chdir to /usr, and then local, and then bin, it's "reasonable" from an intuitive sense, although there's no real filesystem with a real directory at the intermediate points. Our Bourne shell (/vsta/bin/sh) does a reasonably good job in its "cd" command behavior. It might make a starting point. Andy From vandys@glare.cisco.com Mon Apr 10 00:24:11 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05172; Mon, 10 Apr 1995 00:24:09 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA14654 for ; Mon, 10 Apr 1995 01:11:24 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id cc16355; 10 Apr 95 9:06 GMT-60:00 Received: from humbug.demon.co.uk by post.demon.co.uk id ab04340; 10 Apr 95 8:47 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0ryE44-0003JzC; Mon, 10 Apr 95 08:39 BST Message-Id: From: Dave Hudson Subject: Re: keyboard layouts To: Calvin Clark Date: Mon, 10 Apr 1995 08:39:15 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199504092330.TAA01875@ray.charlesview.com> from "Calvin Clark" at Apr 9, 95 07:30:01 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: 1474 Hi, Calvin Clark wrote: > > > I've been typing with a dvorak layout for a few years now and qwerty > gives me headaches, so I hacked the isr.c files to read dvorak. The > keyboard table is duplicated in many places. For right now I just > hard-coded the change, but it would be better to have they layout be > dynamic so that it can be changed to any arbitrary table with an > external program like Linux's "keymap" command. I don't see any > pressing reason to have a separate table for the virtual consoles, the > kernel debugger and the rs232 code, so it could be just a single > internal table. On the other hand, it might be nice to be able to > have different layouts on different virtual consoles (something Linux > doesn't support) though it might mean a bit more code. Any opinions > on the matter? I currently have patches to support US, UK, French and German keyboards running with David Jeske's cons3 server. One of the things I'm planning on doing though is to rework the keyboard server and allow cons to understand how to do VT switching. Having the keyboard separate is neater for when I'm working on using bitblt for display. As far as the kernel debugger map's concerned I find it's easier just to live with that being hardwired (and just ifdef'd). As far as different maps on different VTs goes, I'm not sure it buys us much, but it's not too difficult to do (*much* easier than it would be to do under Linux though). Regards, Dave From vandys@glare.cisco.com Mon Apr 10 00:24:15 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05175; Mon, 10 Apr 1995 00:24:14 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA14659 for ; Mon, 10 Apr 1995 01:11:30 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id at16475; 10 Apr 95 9:06 GMT-60:00 Received: from humbug.demon.co.uk by post.demon.co.uk id aa04368; 10 Apr 95 8:47 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0ryE6S-0003K0C; Mon, 10 Apr 95 08:41 BST Message-Id: From: Dave Hudson Subject: Re: chdir() in VSTa 1.3.3 libc always returns 0 To: calvin@charlesview.com Date: Mon, 10 Apr 1995 08:41:43 +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: 896 Hi Calvin, Calvin Clark wrote: > > I was trying to write a simple "find" utility because I didn't have a > port handy and I was getting tired of trying to find files by hand. > I noticed that chdir() always returns 0, even if you try to go to > a directory that doesn't exist. A brief glance at the definition in > libc/open.c shows that in fact this is the case. There's also an > open_c.vim file in the distribution, which suggests someone was > hacking on the file at the time. If you want find I have a port of GNU find - it'll be available under 1.4 along with a number of other GNU tools (it needs some more libc code and GNU make to build it). I can mail you a binary for this if it'll help, but the sources are pretty meaningless as the static binary is against some hacking I did at 1.3.1 and my dynamic linked version is against a pre-1.4 version of libc. Regards, Dave From vandys@glare.cisco.com Mon Apr 10 16:41:18 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA05378; Mon, 10 Apr 1995 16:41:17 -0700 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id FAA00597 for ; Mon, 10 Apr 1995 05:19:35 -0700 Received: from world.std.com by europe.std.com (8.6.11/Spike-8-1.0) id IAA22689; Mon, 10 Apr 1995 08:19:33 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA01278; Mon, 10 Apr 1995 08:19:32 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199504101219.AA01278@world.std.com> Subject: new FAT fs To: vsta@cisco.com Date: Mon, 10 Apr 1995 08:19:31 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 308 Hi, [Dave Hudson wrote] > I believe MS published a book with the spec for the new FAT fs used in > Windows 95 so maybe that would be a good place to look too. You you (or anyone else) has a reference to the new FAT spec, please let me know. I'm interested in getting a copy. Thanks. Mike Larson From vandys@glare.cisco.com Mon Apr 10 21:18:58 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA05409; Mon, 10 Apr 1995 21:18:56 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id WAA21251 for ; Mon, 10 Apr 1995 22:06:17 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA09139 (5.67b8/IDA-1.5 for ); Tue, 11 Apr 1995 00:05:55 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id AAA26655 for vsta@cisco.com; Tue, 11 Apr 1995 00:07:45 -0500 From: David Jeske Message-Id: <199504110507.AAA26655@fiction.isdn.uiuc.edu> Subject: VSTa Questions (fwd) To: vsta@cisco.com Date: Tue, 11 Apr 1995 00:07:45 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1519 I noticed this request for VSTa info on comp.os.research, I suspect several of you already read the group when you have time. However, I wanted to post it here to also request that you bounce any answers you write on to me as well. I gave him some cursory answers explaing the namespace and semaphores stuff I know or have read on the mailing list. Forwarded message: > >Path: vixen.cso.uiuc.edu!howland.reston.ans.net!agate!darkstar.UCSC.EDU!osr > >From: "Scott J. C. MacKillip" > >Newsgroups: comp.os.research > >Subject: Questions about VSTa > >Date: 10 Apr 1995 14:44:42 GMT > >Organization: TASC > >Lines: 18 > >Approved: comp-os-research@ftp.cse.ucsc.edu > >Message-ID: <3mbg8q$5k4@darkstar.UCSC.EDU> > >NNTP-Posting-Host: ftp.cse.ucsc.edu > >Originator: osr@cse.ucsc.edu > > > Hi. > I have a few questions about the VSTa operating system. I was > hoping someone would be able to help me out. > > How is naming handled by VSTa? Is VSTa a distributed OS? > How is fault tolerance achieved for VSTa? > How does VSTa implement synchronization? (For example, are > semaphores implemented? What about other methods of inter > process communication?) > > > I appreciate any imput to these questions!! > > Thanks! > > Scott MacKillip -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Tue Apr 11 01:19:35 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA05423; Tue, 11 Apr 1995 01:19:34 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id CAA08310 for ; Tue, 11 Apr 1995 02:06:56 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA10570 (5.67b8/IDA-1.5 for ); Tue, 11 Apr 1995 04:06:36 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id EAA27053 for vsta@cisco.com; Tue, 11 Apr 1995 04:08:27 -0500 From: David Jeske Message-Id: <199504110908.EAA27053@fiction.isdn.uiuc.edu> Subject: FAQ and Docs To: vsta@cisco.com Date: Tue, 11 Apr 1995 04:08:26 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1309 I have started to assemble pieces of information from all parts of the mailing list archives and any scraps I have lying around. I'm putting them on the home page as I find them and clean them up a little. I have a alpha version of a FAQ for VSTa. It's version 0.2, has anyone written anything FAQ-like since then, or added anything to it? I made "FAQ v0.3 alpha" available on the WWW page. I am putting the FAQ into "current" shape and adding some more information to it. After I get it fleshed out a little, I'll post it to comp.os.research along with the WWW site announcement. If you have any docs or whatnot, send them my way and I'll put them into the assimilation pile. All this information I'm collecting will eventually become part of some orginized documentation. However, for now I just want to get the jump on getting the information out there and all in one place. If you are WWW enabled, then you can see what I've made available so far under: http://www.cen.uiuc.edu/~jeske/VSTa/vsta.faq.html and http://www.cen.uiuc.edu/~jeske/VSTa/Docs/ -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Tue Apr 11 15:24:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05555; Tue, 11 Apr 1995 15:24:44 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id QAA15900 for ; Tue, 11 Apr 1995 16:12:01 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA16188 (5.67b8/IDA-1.5 for ); Tue, 11 Apr 1995 18:11:39 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id SAA29709 for vsta@cisco.com; Tue, 11 Apr 1995 18:13:31 -0500 From: David Jeske Message-Id: <199504112313.SAA29709@fiction.isdn.uiuc.edu> Subject: MADO questions To: vsta@cisco.com Date: Tue, 11 Apr 1995 18:13:31 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 793 Is there anything written down about the design/goals of MADO (other than it is an 8 1/2 like design, although I should probably go re-read that)? Does it intend to provide device independent drawing primitives? I assume the Window Mangement is going to take a more NeWS-like approach than the standard X approach of "a WM is a client". (i.e. this would be good IMHO) Is this true? Or is the "manager layer" which provides dummy /dev/bitblit's for processes and rewrites messages to /dev/bitblit going to talk to some external window manager? -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) From vandys@glare.cisco.com Tue Apr 11 16:32:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA05566; Tue, 11 Apr 1995 16:32:44 -0700 Received: from ebt-inc.ebt.com (kirk.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id RAA21798 for ; Tue, 11 Apr 1995 17:19:37 -0700 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id UAA24254; Tue, 11 Apr 1995 20:21:09 -0400 Date: Tue, 11 Apr 1995 20:21:09 -0400 From: Gavin Nicol Message-Id: <199504120021.UAA24254@ebt-inc.ebt.com> To: jeske@uiuc.edu CC: vsta@cisco.com In-reply-to: <199504112313.SAA29709@fiction.isdn.uiuc.edu> (message from David Jeske on Tue, 11 Apr 1995 18:13:31 -0500 (CDT)) Subject: Re: MADO questions >Does it intend to provide device independent drawing primitives? Yes. One reason for the seperation between MADO and bitblt is to allow that (ie. draw to a printer driver/postscript generator which looks just the same). >I assume the Window Mangement is going to take a more NeWS-like approach >than the standard X approach of "a WM is a client". (i.e. this would >be good IMHO) Is this true? Or is the "manager layer" which provides >dummy /dev/bitblit's for processes and rewrites messages to /dev/bitblit >going to talk to some external window manager? MADO will primary be a multiplexer, but I have plans to also include a certain amount of built-in functionality (menus, labels etc), and to support downloadable code. Given that Java looks so neat, I guess that might be where it will go. All dependent on time of course.... From vandys@glare.cisco.com Wed Apr 12 00:49:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05598; Wed, 12 Apr 1995 00:49:19 -0700 Received: from zephyr.cs.vu.nl (root@zephyr.cs.vu.nl [130.37.16.3]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id BAA17099 for ; Wed, 12 Apr 1995 01:36:44 -0700 Received: from galei.cs.vu.nl by zephyr.cs.vu.nl with smtp (Smail3.1.28.1 #15) id m0ryxua-00000UC; Wed, 12 Apr 95 10:36 +0200 Date: Wed, 12 Apr 95 10:36:07 MET DST From: Ronald Oussoren To: vsta@cisco.com Subject: More signals (event bug?) Message-ID: <9504121036.aa01228@galei.cs.vu.nl> My implementation of posix signals is almost finished, however I have a problem in one of my test programs. The problem can be reproduced by using only events. When a program is waiting for events in a while loop, like this: { notify_handler(handler); while(1); } This program will get a segmentation fault (EFAULT) when an event is sent to it (*) . When the busy waiting is replaced by a sleep(), the event is caught and all is well. As this is the only problem left for getting a working signal implementation, I would like to solve this. Any ideas on how to solve it? Ronald (*) It also receives the event. From vandys@glare.cisco.com Wed Apr 12 05:16:34 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA05657; Wed, 12 Apr 1995 05:16:32 -0700 Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id GAA06524 for ; Wed, 12 Apr 1995 06:03:51 -0700 Received: from amdahl.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #1) id m0rz21r-0000GYC; Wed, 12 Apr 95 06:00 PDT Received: from amdahl.uts.amdahl.com by amdahl.amdahl.com with smtp (Smail3.1.28.1 #49) id m0rz24M-00009hC; Wed, 12 Apr 95 06:02 PDT Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.16) id ; Wed, 12 Apr 95 06:03 PDT Message-Id: From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: MADO questions To: gtn@ebt.com (Gavin Nicol) Date: Wed, 12 Apr 1995 06:03:02 -0700 (PDT) Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199504120021.UAA24254@ebt-inc.ebt.com> from "Gavin Nicol" at Apr 11, 95 08:21:09 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1111 > >I assume the Window Mangement is going to take a more NeWS-like approach > >than the standard X approach of "a WM is a client". (i.e. this would > >be good IMHO) Is this true? Or is the "manager layer" which provides > >dummy /dev/bitblit's for processes and rewrites messages to /dev/bitblit > >going to talk to some external window manager? > > MADO will primary be a multiplexer, but I have plans to also include a > certain amount of built-in functionality (menus, labels etc), and to > support downloadable code. Given that Java looks so neat, I guess that > might be where it will go. > > All dependent on time of course.... I realise that this is not going to make me popular, but this sounds to me to be a trifle ambitious - is there any chance of getting a minimalist MADO into 1.4, without all the bells and whistles, adding support for them later, when time allows? Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 125 234 6377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation] From vandys@glare.cisco.com Wed Apr 12 07:25:28 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA05685; Wed, 12 Apr 1995 07:25:27 -0700 Received: from ebt-inc.ebt.com (kirk.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id IAA14577 for ; Wed, 12 Apr 1995 08:12:56 -0700 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id LAA16278; Wed, 12 Apr 1995 11:14:56 -0400 Date: Wed, 12 Apr 1995 11:14:56 -0400 From: Gavin Nicol Message-Id: <199504121514.LAA16278@ebt-inc.ebt.com> To: agc@uts.amdahl.com CC: jeske@uiuc.edu, vsta@cisco.com In-reply-to: (agc@uts.amdahl.com) Subject: Re: MADO questions >I realise that this is not going to make me popular, but this sounds >to me to be a trifle ambitious - is there any chance of getting a >minimalist MADO into 1.4, without all the bells and whistles, adding >support for them later, when time allows? That is actually the development plan. As I said, the problem is time. I don't even have much time to sleep this month. That;s why I'm awake now... (12:30 in Japan...) From vandys@glare.cisco.com Wed Apr 12 13:29:15 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA05735; Wed, 12 Apr 1995 13:29:11 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id OAA19960 for ; Wed, 12 Apr 1995 14:16:39 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa23480; 12 Apr 95 16:59 GMT-60:00 Received: from humbug.demon.co.uk by post.demon.co.uk id aa03615; 12 Apr 95 16:59 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0rz4oA-0002cTC; Wed, 12 Apr 95 16:58 BST Message-Id: From: Dave Hudson Subject: Re: MADO questions To: Gavin Nicol Date: Wed, 12 Apr 1995 16:58:22 +0100 (BST) Cc: agc@uts.amdahl.com, jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199504121514.LAA16278@ebt-inc.ebt.com> from "Gavin Nicol" at Apr 12, 95 11:14:56 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 863 Hi, Gavin Nicol wrote: > > >I realise that this is not going to make me popular, but this sounds > >to me to be a trifle ambitious - is there any chance of getting a > >minimalist MADO into 1.4, without all the bells and whistles, adding > >support for them later, when time allows? > > That is actually the development plan. As I said, the problem is > time. I don't even have much time to sleep this month. That;s why I'm > awake now... (12:30 in Japan...) I'm aiming for a version of bitblt to be working for 1.4, but I'm pretty strapped for time myself until mid-May now :-( I've actually had some stuff on-screen since 1.3.1, but I wanted to get the performance work done on the kernel first. I think I need to do some work on the source layout now though as I'd like to try to make this easier to get running on the 68k port. Regards, Dave From vandys@glare.cisco.com Fri Apr 14 09:33:57 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA06097; Fri, 14 Apr 1995 09:33:56 -0700 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA02608 for ; Fri, 14 Apr 1995 10:21:38 -0700 Received: from world.std.com by europe.std.com (8.6.11/Spike-8-1.0) id NAA20032; Fri, 14 Apr 1995 13:21:27 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA19273; Fri, 14 Apr 1995 13:21:23 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199504141721.AA19273@world.std.com> Subject: Re: MADO questions To: vsta@cisco.com Date: Fri, 14 Apr 1995 13:21:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 532 Hi, Gavin Nicol wrote (regarding a minimalist MADO): > > That is actually the development plan. As I said, the problem is > time. I don't even have much time to sleep this month. That;s why I'm > awake now... (12:30 in Japan...) Perhaps you could post a list of sub-projects, along with current status, related to the minimalist version of the windowing system. It may be possible that someone reading this mailing list would volunteer to help out if they knew more details about what needs to be done. Mike Larson From vandys@glare.cisco.com Fri Apr 14 11:33:47 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA06134; Fri, 14 Apr 1995 11:33:46 -0700 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id MAA13313 for ; Fri, 14 Apr 1995 12:21:24 -0700 Received: by hookomo (Smail3.1.28.1 #11) id m0rzqvI-000uW2C; Fri, 14 Apr 95 09:20 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: i386 vsta To: vsta@cisco.com (VSTa Mailing List) Date: Fri, 14 Apr 1995 09:20:56 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 845 Hi, At work there are always spare machines coming in and out and I decided I'd install vsta on one of them to play around with a fully working vsta finally. After figuring out how to get the box into real mode (hey, I dont do dos :) I was able to get it up and running fine. I'm just using a dos filesystem currently (least disruptive to the system). Anyway I wasn't able to compile any programs. I remember hearing of this problem before and I thought the answer was something like give yourself permissions 1.1 (sys.sys) but I did that and I still cant compile. I get "perm" when I use cc and it complains about not being able to use the files in /tmp (I cant even ls -l them but I can do an ls on them) after cpp creates them when I do a make in one of the srv directories. Whats the answer? Tim N. From vandys@glare.cisco.com Fri Apr 14 11:32:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA06131; Fri, 14 Apr 1995 11:32:18 -0700 Received: from Sun.COM (Sun.COM [192.9.9.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id MAA13239 for ; Fri, 14 Apr 1995 12:20:00 -0700 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19329; Fri, 14 Apr 95 12:19:28 PDT Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA26219; Fri, 14 Apr 95 15:19:26 EDT Received: from missmarple.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA23008; Fri, 14 Apr 1995 15:19:03 +0500 Received: from canalpark.East.Sun.COM by missmarple.East.Sun.COM (5.x/SMI-SVR4) id AA20763; Fri, 14 Apr 1995 14:32:34 -0400 Received: by canalpark.East.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA12501; Fri, 14 Apr 1995 14:31:52 -0400 Date: Fri, 14 Apr 1995 14:31:52 -0400 From: Evon.Liu@East.Sun.COM (Evon Liu - Sun BOS Software) Message-Id: <199504141831.OAA12501@canalpark.East.Sun.COM> To: vsta@cisco.com Subject: problem with gcc (g++) X-Sun-Charset: US-ASCII Content-Length: 520 Hi, There, I'm trying to cross-compile (gcc-cross was built on host sparc-sun-sunos4.1.4, targeted for i386-vsta), it gives me: -------- xxx.cc: Assembler messages: xxx.cc:3: Error: Unknown pseudo-op: `.section' xxx.cc:3: Error: Unknown pseudo-op: `.section' ------- The problem is that "cc1plus" generates xxx.s file which contains these two lines: .section .dtor .section .ctor the assembler (as-cross) doesn't recognize the opcode ".section".. Does anybody know how to resolve that? Thanks, -Evon From vandys@glare.cisco.com Fri Apr 14 12:39:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA06151; Fri, 14 Apr 1995 12:39:47 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id NAA18351 for ; Fri, 14 Apr 1995 13:27:29 -0700 Received: (from rob@localhost) by cygnus.com (8.6.12/8.6.9) id NAA21786; Fri, 14 Apr 1995 13:27:27 -0700 Message-Id: <199504142027.NAA21786@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Fri, 14 Apr 1995 13:27:27 PDT In-Reply-To: Evon.Liu@East.Sun.COM (Evon Liu - Sun BOS Software)' <199504141831.OAA12501@canalpark.East.Sun.COM> problem with gcc (g++) Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Evon.Liu@East.Sun.COM (Evon Liu - Sun BOS Software), vsta@cisco.com Subject: Re: problem with gcc (g++) From: Evon.Liu@East.Sun.COM (Evon Liu - Sun BOS Software) Subject: problem with gcc (g++) > I'm trying to cross-compile (gcc-cross was built on host > sparc-sun-sunos4.1.4, targeted for i386-vsta), it gives me: > > The problem is that "cc1plus" generates xxx.s file which contains > these two lines: > .section .dtor > .section .ctor > the assembler (as-cross) doesn't recognize the opcode ".section".. > > Does anybody know how to resolve that? Oops, when I did the VSTa support for cross compiling I never tested G++. Down in gcc/config/i386/vsta.h is: #undef EXTRA_SECTIONS #define EXTRA_SECTIONS in_ctor, in_dtor #undef EXTRA_SECTION_FUNCTIONS #define EXTRA_SECTION_FUNCTIONS \ CTOR_SECTION_FUNCTION \ DTOR_SECTION_FUNCTION #define CTOR_SECTION_FUNCTION \ void \ ctor_section () \ { \ if (in_section != in_ctor) \ { \ fprintf (asm_out_file, "\t.section .ctor\n"); \ in_section = in_ctor; \ } \ } #define DTOR_SECTION_FUNCTION \ void \ dtor_section () \ { \ if (in_section != in_dtor) \ { \ fprintf (asm_out_file, "\t.section .dtor\n"); \ in_section = in_dtor; \ } \ } You might want to remove this. VSTa uses a.out, and that object file format (like old sun3's) only support three sections, namely .text, .data and .bss. For a.out I usually stick the ctor and dtor tables in .text. - rob - From vandys@glare.cisco.com Wed Apr 19 06:48:53 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA06199; Fri, 14 Apr 1995 19:17:05 -0700 Received: from plg.uwaterloo.ca (plg.uwaterloo.ca [129.97.140.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id UAA14414 for ; Fri, 14 Apr 1995 20:04:48 -0700 Received: by plg.uwaterloo.ca id <23576>; Fri, 14 Apr 1995 23:04:35 -0400 From: Dave Mason To: vsta@cisco.com Subject: 1.4 when? Message-Id: <95Apr14.230435edt.23576@plg.uwaterloo.ca> Date: Fri, 14 Apr 1995 23:04:30 -0400 Dave Hudson writes: > I'm aiming for a version of bitblt to be working for 1.4, but I'm pretty > strapped for time myself until mid-May now :-( I've actually had some stuff Any news on when 1.4 will be out? Let me make it perfectly clear that I'm not trying to apply pressure! (Given how much time *I* have lately, I wouldn't be any help even if I were working on any parts of vsta -- but I do *wish* I had time to work on it.) Part of my reason for asking is that plan9 is going to be released shortly, and it would be interesting to see how similar they are, performance, etc. It might also make some sense to use real 9P protocol so that we could try having vsta and plan9 machines interoperating! But I haven't had a chance to look and see how much work that would be to change. ../Dave From vandys@glare.cisco.com Wed Apr 19 06:53:52 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00111; Wed, 19 Apr 1995 06:53:51 -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 OAA26145; Mon, 17 Apr 1995 14:39:31 -0700 Message-Id: <199504172139.OAA26145@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Mason Cc: vsta@cisco.com Subject: Re: 1.4 when? In-Reply-To: Your message of "Fri, 14 Apr 1995 23:04:30 EDT." <95Apr14.230435edt.23576@plg.uwaterloo.ca> Date: Mon, 17 Apr 1995 14:39:31 -0700 From: Andrew Valencia [Dave Mason writes:] >Any news on when 1.4 will be out? Let me make it perfectly clear that >I'm not trying to apply pressure! (Given how much time *I* have >lately, I wouldn't be any help even if I were working on any parts of >vsta -- but I do *wish* I had time to work on it.) I'd expect at least a couple of months. Andy From vandys@glare.cisco.com Wed Apr 19 06:56:17 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00134; Wed, 19 Apr 1995 06:56:16 -0700 Received: from zephyr.cs.vu.nl (root@zephyr.cs.vu.nl [130.37.16.3]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id BAA06245 for ; Wed, 19 Apr 1995 01:20:16 -0700 Received: from sloep11.cs.vu.nl by zephyr.cs.vu.nl with smtp (Smail3.1.28.1 #15) id m0s1Uzc-00000bC; Wed, 19 Apr 95 10:20 +0200 Date: Wed, 19 Apr 95 10:20:03 MET DST From: Ronald Oussoren To: vsta@cisco.com Subject: Event bug, fix Message-ID: <9504191020.aa07313@sloep11.cs.vu.nl> Hi, Earlier I sent a message about a bug in the (i386) implementation of the event mechanism. Basically the assembly part of the handler returned to a random address. The following patch fixes that. However it is not perfect: The return address is just outside off the stack (it will be changed when something is pushed on the stack), thus when a second event is send just before the first handler returns, the return address will be invalid. Ronald *** syscalls.s Wed Apr 19 09:52:26 1995 --- ../../new/syscalls.s Wed Apr 19 09:51:24 1995 *************** *** 94,100 **** popf /* Restore state */ popa pop %esp /* Skip event string */ ! ret /* Resume at old IP */ .globl _notify_handler _notify_handler: --- 94,100 ---- popf /* Restore state */ popa pop %esp /* Skip event string */ ! jmp -4(%esp) /* Resume at old IP */ .globl _notify_handler _notify_handler: From vandys@glare.cisco.com Wed Apr 19 06:57:49 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00149; Wed, 19 Apr 1995 06:57:48 -0700 Received: from zephyr.cs.vu.nl (root@zephyr.cs.vu.nl [130.37.16.3]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id BAA12064 for ; Tue, 18 Apr 1995 01:50:18 -0700 Received: from sloep11.cs.vu.nl by zephyr.cs.vu.nl with smtp (Smail3.1.28.1 #15) id m0s18ym-00000oC; Tue, 18 Apr 95 10:49 +0200 Date: Tue, 18 Apr 95 10:49:52 MET DST From: Ronald Oussoren To: vsta@cisco.com Subject: Event delivery bug Message-ID: <9504181049.aa05112@sloep11.cs.vu.nl> Hi, I think the event mechanism for the i386 version of VSTa contains a bug in the assembly part of the library (in mach/syscalls.s). My understanding of the event delivery is as follows: - events are delivered by the kernel using sendev() (mach/trap.c). This function copies an event structure, containing the event string, the old stack pointer and the old IP on the stack. The stack pointer is updated to indicate this, and the IP is changed to the notify-handler of the process. - The handler in the library calls a user defined C function, after setting up a stack frame. - The assembly language handler then restores the old state, and returns to the old IP, letting the program continue at the place it was when the event was delivered (without reentering the kernel). The problem is with the last step, returning to the old IP, from mach/syscalls.s: >asm_handler: > pusha /* Save state */ > pushf > lea 0x28(%esp),%eax /* Point to event string */ > push %eax /* Leave as arg to routine */ > movl c_handler,%eax > call %eax > lea 4(%esp),%esp /* Drop arg */ > popf /* Restore state */ > popa > pop %esp /* Skip event string */ At this point, the stack pointer will be restored to its old location, where it was before the event was delivered (this is due to the layout of the event structure that was pushed). I think that the old IP is now just below the top of the stack (that is, when a value would be pushed on top of the stack, it would erase the old IP). > ret /* Resume at old IP */ The 'ret' instruction returns to the address on top of the stack, I think this is _not_ the old IP! (There really is a problem, I included the source for two small programs, event[.c] and notify[.c]. When an event is send to 'event', it will print the event to standard error and then continue. However, when I sent an event to it using the 'notify' program, 'event' will stop after printing that event, and the 'fault' event (a segmentation fault) -- event.c void handler(char *s) { write(2, s, strlen(s)); write(2, "\n"); } int main(void) { notify_handler(handler); while(1){ /* DO NOTHING */ } } -- notify.c int main(int argc, char **argv) { notify(atoi(argv[1]), 0, argv[2]); } [NOTE: I haven't checked if the included code fragments compile, I rewrote then from memory, the 'orginals' are at my home machine, not here where I have net access.] ) I hope someone can fix this, I don't know enough of assembly to do it. Ronald From vandys@glare.cisco.com Wed Apr 19 07:12:07 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00194; Wed, 19 Apr 1995 07:12:04 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA04849 for ; Sat, 15 Apr 1995 01:51:15 -0700 Received: from punt.demon.co.uk by disperse.demon.co.uk id aa12045; 15 Apr 95 9:51 GMT-60:00 Received: from humbug.demon.co.uk by punt.demon.co.uk id aa17114; 15 Apr 95 9:48 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0s03U2-0002t5C; Sat, 15 Apr 95 09:45 BST Message-Id: From: Dave Hudson Subject: Re: MADO questions To: Mike A Larson Date: Sat, 15 Apr 1995 09:45:37 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199504141721.AA19273@world.std.com> from "Mike A Larson" at Apr 14, 95 01:21:22 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: 2423 Hi, Mike A Larson wrote: > > Gavin Nicol wrote (regarding a minimalist MADO): > > > > That is actually the development plan. As I said, the problem is > > time. I don't even have much time to sleep this month. That;s why I'm > > awake now... (12:30 in Japan...) > > Perhaps you could post a list of sub-projects, along with current status, > related to the minimalist version of the windowing system. It may > be possible that someone reading this mailing list would volunteer > to help out if they knew more details about what needs to be done. Well I'm not sure about MADO, but I've just started to rework the code I did for bitblt last year - I'm splitting things up a little. Previously bitblt was going to be something like the Xfree86 servers and include support for most video chips in one server - this causes a few performance issues, but more importantly makes it very difficult to use any really neat features provided by just one chip. It also causes severe code bloat :-( My new approach is to redefine things somewhat, have a server per-chipset-type with an autoprobe loader that will detect video adaptors and execs the correct bitblt server(s) - this gives the same effect as the fully integrated approach. Alternatively it will be possible to just kick off the server(s) that you know you need. I'm reworking some of my older stuff into libraries to simplify the task of writing the individual servers. There are a couple of extra benefits to this approach - one is that it becomes much simpler to have multiple bitblts running at once (memory usage is better). Another is that it allows for very specialised, highly optimised bitblt servers for particular tasks (I can imagine say a very fast "mode 13" server for 320x200x256 with *lots* of fast assembly routines for games or animation work). Finally, having thrown off the idea of doing everything in one server I can start to code up a server with a bitblt interface for printers (I wrote support for 9 pin, 24 pin and HP laserjet printers in some dos code 5 or 6 years ago so I should be able to rework this). Another advantage to this approach of course is that it makes it *much* easier for other people to code up support for their own video adaptors :-) I'm hoping to get some time over the Easter break to define the interface details and code up a simple VGA and a Hercules server and see how they behave. Regards, Dave From vandys@glare.cisco.com Tue Apr 25 08:43:07 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00181; Tue, 25 Apr 1995 07:09:56 -0700 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id UAA09254 for ; Thu, 20 Apr 1995 20:33:53 -0700 Received: by hookomo (Smail3.1.28.1 #11) id m0s29T9-000ueyC; Thu, 20 Apr 95 17:33 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: vsta and t4600 To: vsta@cisco.com (VSTa Mailing List) Date: Thu, 20 Apr 1995 17:33:22 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 566 Hi, Well they took the box I was checking out vsta on and I grabbed another one. This is a T4600 laptop. I'm told it has a 486/33 and the display is supposed to do vga. The drive is an ide. When I "boot vsta" it says: Boot vsta: 69600+36864+5736 Tasks: cons namer wd dos init Launch at 0x1020 Then nothing else. The first thing that came to mind was that people with monochrome displays had problems. Is it running on a console that I cant see or is it just dead? Has anyone used vsta on a toshiba laptop? Tim N. From vandys@glare.cisco.com Tue Apr 25 08:28:07 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00259; Tue, 25 Apr 1995 07:17:12 -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 IAA28067; Tue, 25 Apr 1995 08:09:59 -0700 Message-Id: <199504251509.IAA28067@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: vsta and t4600 In-Reply-To: Your message of "Thu, 20 Apr 1995 17:33:22 -1000." Date: Tue, 25 Apr 1995 08:09:58 -0700 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] > Boot vsta: 69600+36864+5736 > Tasks: cons namer wd dos init > Launch at 0x1020 >Then nothing else. The first thing that came to mind was >that people with monochrome displays had problems. Is >it running on a console that I can't see or is it just dead? Easy to check. Edit your vsta/boot/boot.lst entry for the "cons" server. I belive it's the -mono flag. Then try to boot again. Andy From vandys@glare.cisco.com Fri Apr 28 07:19:46 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00085; Fri, 28 Apr 1995 07:19:35 -0700 Received: from stargate.promus.com (mmdf@stargate.PROMUS.COM [192.251.123.11]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id GAA24502 for ; Fri, 28 Apr 1995 06:35:03 -0700 Received: from ceres.promus.com by stargate.promus.com id aa19758; 28 Apr 95 8:26 CDT Received: by ceres.promus.com with Microsoft Mail id <2FA0E104@ceres.promus.com>; Fri, 28 Apr 95 07:35:16 CDT From: David Eagle To: "'vstalist'" Subject: boot diskette? Date: Fri, 28 Apr 95 08:36:00 CDT Message-ID: <2FA0E104@ceres.promus.com> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 OK, I am still kinda new to VSTa. How do I create a boot diskette? Is this even possible? If not, when do we expect such a capability to be ready? In particular, I would like to boot off a 1.4M floppy. What would be really cool is if I could boot from a floppy on a floppy-only system with about 8M memory, decompress the entire floppy into memory, and (after allowing 3M for the expanded boot diskette and 1M for system data areas) have about 4M for user program space. Then, if I may continue my fantasy a moment, I would like that 3M of expanded bootdisk to contain ALL the normally used subroutines for GUI support, so that my programs can average about 40K each and still be user friendly. By the way, I do have ulterior motives for wanting a lean, mean OS machine. Will reveal in a followup. From vandys@glare.cisco.com Fri Apr 28 07:40:02 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00188; Fri, 28 Apr 1995 07:39:33 -0700 Received: from trefle.saclay.cea.fr (trefle.saclay.cea.fr [132.166.128.101]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id AAA28933 for ; Wed, 26 Apr 1995 00:01:59 -0700 Received: from oeillet.saclay.cea.fr by trefle.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with ESMTP id JAA21055 for ; Wed, 26 Apr 1995 09:01:10 +0200 Received: from soleil.serma.cea.fr by oeillet.saclay.cea.fr (8.6.10/ CEANET-ROUTER-3.0) with SMTP id JAA25561 for ; Wed, 26 Apr 1995 09:03:30 +0200 Received: from rosser.serma.cea.fr by soleil.serma.cea.fr (5.0/CEANET.2.0.1) id AA12854; Wed, 26 Apr 1995 09:01:52 --100 Received: by rosser.serma.cea.fr (5.x/SMI-SVR4) id AA00569; Wed, 26 Apr 1995 09:02:00 +0200 Date: Wed, 26 Apr 1995 09:02:00 +0200 Message-Id: <9504260702.AA00569@rosser.serma.cea.fr> From: basile.starynkevitch@cea.fr To: vsta@cisco.com Subject: separate read-file and read-dir protocol requests content-length: 2167 Hello All, (I'm the guy who on my spare time is very slowly porting the linux ext2fs to VSTa) I have a question (and suggestion). Since I'm VSTa-ling (and Linuxing) at home only and emailing at work, this is from my memory. Why does reading a file and reading a directory take the same request (FS_READ, if I remember well)? I believe this is wrong (or at least a poor choice) because: 1) currently, reading a dir produce a succession of lines, one per filename. Consequently (as I understand it), a filename can't contain a newline character (which is permitted by Posix). 2) even on many modern Unixes, there are two different syscalls (getdents and read) for reading a directory and a plain file 3) most utilities use readdir (or getdents) for reading directories, so having a separate read-dir request would, in my humble opinion, almost just need recoding readdir. 4) more interestingly, it would be very difficult to implement a filesystem where file have both directory and bytestream structures (like on the MacIntosh OS -forks- or the TRON OS). I believe that such a feature is highly desirable; for instance, it would make adding user-level metadata easier (eg an icon for a file would be just the .ICON direntry, etc). Also, an executable would use such a thing for symbol tables, etc. Actually, section-structured files (like ar,tar,cpio,ELF formats on Unixes) would be easier. Any comments? -- ---------------------------------------------------------------------- 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.85.68; phone: (33) 1- 69.08.40.66; homephone: (33) 1- 46.65.45.53 email: basile.starynkevitch@cea.fr (redirected to basile@soleil.serma.cea.fr); ---------------------------------------------------------------------- N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a **small pertinent part** of my mail in all answers Veuillez citer une **petite partie pertinente** de mon courrier dans vos reponses From vandys@glare.cisco.com Fri Apr 28 07:24:44 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00092; Fri, 28 Apr 1995 07:24:42 -0700 Received: from gatekeeper.dsg.com (gatekeeper.DSG.COM [204.179.88.126]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id IAA01938 for ; Fri, 28 Apr 1995 08:18:01 -0700 Received: (from uucp@localhost) by gatekeeper.dsg.com (8.6.10/8.6.10) id KAA01535 for ; Fri, 28 Apr 1995 10:18:42 -0500 Received: from opus.dsg.com(204.179.89.3) by gatekeeper.dsg.com via smap (V1.3) id sma001533; Fri Apr 28 10:18:29 1995 Received: from stimpy.dsg.com (stimpy.dsg.com [204.179.89.15]) by opus.dsg.com (8.6.10/8.6.10) with ESMTP id KAA03739 for ; Fri, 28 Apr 1995 10:21:22 -0500 Received: from sparky.dsg.com (sparky.dsg.com [204.179.89.9]) by stimpy.dsg.com (8.6.10/8.6.10) with SMTP id KAA15746 for ; Fri, 28 Apr 1995 10:21:21 -0500 Received: by sparky.dsg.com (5.0/SMI-SVR4) id AA08612; Fri, 28 Apr 95 10:21:20 CDT Date: Fri, 28 Apr 95 10:21:20 CDT Message-Id: <9504281521.AA08612@sparky.dsg.com> From: erewhon@dsg.com (Steven Byrnes) To: vsta%cisco.com@dsg.com Subject: Newbie question regarding ports Reply-To: erewhon@dsg.com (Steven Byrnes) X-Zippy: LBJ, LBJ, how many JOKES did you tell today??! Comments: Hyperbole mail buttons accepted, v3.05. content-length: 439 Now that I've all scared you away... :) I've been using VSTa all of one week now. Very nice. I was trying to write a little program that output to some of the I/O ports but didn't have any luck. From browsing the machine-dependent server code, I see that it is possible. Are only servers allowed to do it? What is the minimal incantation necessary to write to (or read from) an I/O port? Am I doing something wrong? Thanks, Steven From vandys@glare.cisco.com Fri Apr 28 08:28:42 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00271; Fri, 28 Apr 1995 08:28: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 JAA23909; Fri, 28 Apr 1995 09:21:57 -0700 Message-Id: <199504281621.JAA23909@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com (VSTa Mailing List) Subject: Re: vsta - compile problems In-Reply-To: Your message of "Tue, 25 Apr 1995 19:34:42 -1000." Date: Fri, 28 Apr 1995 09:21:57 -0700 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] > When I do a tcsetattr() on the >modem line it also seems to affect the console. Yes, the POSIX TTY handling is, well, simple. Remember that the POSIX TTY handling resides entirely in the C library, and it currently makes some simplifying assumptions. >After using a normal fork() it seemed to >work ok. Since TTY state is not tabulated against different file descriptors, this is not surprising. >I did notice a high loss rate at 9600bps. It >didnt work at all at 19200 or 38400. What kind of UART? Also, you're probably running a version without the latest round of performance work, which makes a serious difference. For 1.4, we also get a fully preemptive kernel, which should make a BIG difference. >When I used the >login program on the same serial line it seemed to work >ok (no loss) but it only sends \r's at the end of lines >for some commands. More likely, it only sends \n's. Yes, default mode is (from memory) -onlcr. I don't think onlcr is implemented. > 'gcc: installation problem, cannot exec cpp: no entry' > 'gcc: Program cpp got fatal signal 127.' > 'perm' >I can run cpp manually so I assume its just a path problem >of some sort. That's odd. Did you move any files around? Or change your mount table (use the "fstab" command) in a way which would confuse where things are located? Regards, Andy From vandys@glare.cisco.com Fri Apr 28 07:33:46 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00095; Fri, 28 Apr 1995 07:33:45 -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 IAA22121; Fri, 28 Apr 1995 08:26:35 -0700 Message-Id: <199504281526.IAA22121@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: erewhon@dsg.com (Steven Byrnes) Cc: vsta@amri.cisco.com Subject: Re: Newbie question regarding ports In-Reply-To: Your message of "Fri, 28 Apr 1995 10:21:20 CDT." <9504281521.AA08612@sparky.dsg.com> Date: Fri, 28 Apr 1995 08:26:35 -0700 From: Andrew Valencia [erewhon@dsg.com (Steven Byrnes) writes:] >I was trying to write a little program that output to some of the I/O ports >but didn't have any luck. From browsing the machine-dependent server code, >I see that it is possible. Are only servers allowed to do it? What is the >minimal incantation necessary to write to (or read from) an I/O port? Am I >doing something wrong? main() { enable_io(, ); outportb(, ); } Make sure you're in sys.sys group, otherwise the kernel won't allow the io_enable(). I could've included error checking in the example, but you *did* say minimal! Andy From vandys@glare.cisco.com Fri Apr 28 07:40:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00193; Fri, 28 Apr 1995 07:40:54 -0700 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id WAA23539 for ; Tue, 25 Apr 1995 22:35:30 -0700 Received: by hookomo (Smail3.1.28.1 #11) id m0s3zkJ-000unNC; Tue, 25 Apr 95 19:34 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: vsta - compile problems To: vsta@cisco.com (VSTa Mailing List) Date: Tue, 25 Apr 1995 19:34:42 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1262 Hi, I got VSTa up and running on the laptop. It was the -mono flag that I needed. I am also able to compile now. I was able to write a small program to talk to the serial port. I noticed some weirdness. When I do a tcsetattr() on the modem line it also seems to affect the console. I havent started digging through the code yet. I tried using a tfork() for the two sides of the i/o job but that didnt work so well. After using a normal fork() it seemed to work ok. I did notice a high loss rate at 9600bps. It didnt work at all at 19200 or 38400. When I used the login program on the same serial line it seemed to work ok (no loss) but it only sends \r's at the end of lines for some commands. Anyway on to my main problem. Again I am having trouble with the compiler. I can use 'cc' just fine but 'gcc' does not seem to work. It complains that it cant find cpp: 'gcc: installation problem, cannot exec cpp: no entry' 'gcc: Program cpp got fatal signal 127.' 'perm' I can run cpp manually so I assume its just a path problem of some sort. Its really fun to see VSTa working after reading the source and descriptions from others for so long and working on a non-working version for so long. Tim N. From vandys@glare.cisco.com Fri Apr 28 08:14:50 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00267; Fri, 28 Apr 1995 08:14:49 -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 JAA23388; Fri, 28 Apr 1995 09:08:11 -0700 Message-Id: <199504281608.JAA23388@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: basile.starynkevitch@cea.fr Cc: vsta@cisco.com Subject: Re: separate read-file and read-dir protocol requests In-Reply-To: Your message of "Wed, 26 Apr 1995 09:02:00 +0200." <9504260702.AA00569@rosser.serma.cea.fr> Date: Fri, 28 Apr 1995 09:08:10 -0700 From: Andrew Valencia [basile.starynkevitch@cea.fr writes:] >1) currently, reading a dir produce a succession of lines, one per >filename. Consequently (as I understand it), a filename can't contain >a newline character (which is permitted by Posix). Remember how I said VSTa was "mostly" POSIX conforming? :-) This sounds like an excellent time to tell POSIX to take a leap. >2) even on many modern Unixes, there are two different syscalls >(getdents and read) for reading a directory and a plain file I didn't want to do UNIX again. >3) most utilities use readdir (or getdents) for reading directories, >so having a separate read-dir request would, in my humble opinion, >almost just need recoding readdir. Yes, but why create two mechanisms when one suffices? >4) more interestingly, it would be very difficult to implement a >filesystem where file have both directory and bytestream structures >(like on the MacIntosh OS -forks- or the TRON OS). I believe that such >a feature is highly desirable; for instance, it would make adding >user-level metadata easier (eg an icon for a file would be just the >.ICON direntry, etc). Also, an executable would use such a thing for >symbol tables, etc. Actually, section-structured files (like >ar,tar,cpio,ELF formats on Unixes) would be easier. A VSTa filesystem is free to map the underlying filesystem's namespace. It would be easy to synthesize filename extensions (or modifiers) to handle this. You thus demultiplex the resource forks out into distinct directory entries, and gain compatibility with UNIX-style file management as a bonus. Andy From vandys@glare.cisco.com Fri Apr 28 07:37:30 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00098; Fri, 28 Apr 1995 07:37:29 -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 IAA22270; Fri, 28 Apr 1995 08:30:50 -0700 Message-Id: <199504281530.IAA22270@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: David Eagle Cc: "'vstalist'" Subject: Re: boot diskette? In-Reply-To: Your message of "Fri, 28 Apr 1995 08:36:00 CDT." <2FA0E104@ceres.promus.com> Date: Fri, 28 Apr 1995 08:30:50 -0700 From: Andrew Valencia [David Eagle writes:] > How do I create a boot diskette? Is this even possible? If not, when >do we >expect such a capability to be ready? In particular, I would like to boot >off a 1.4M >floppy. Dave Hudson did this, and made some really elegant performance/caching tweaks to the floppy driver. >What would be really cool is if I could boot from a floppy on a >floppy-only >system with about 8M memory, decompress the entire floppy into memory, and >(after allowing 3M for the expanded boot diskette and 1M for system data >areas) >have about 4M for user program space. Sounds quite reasonable. You might want to enhance srv/tmpfs to permit subdirectories. Or, you could run a filesystem on top of GNU zip on top of the compressed data (but then you have to leave the floppy in the drive). >Then, if I may continue my fantasy a >moment, >I would like that 3M of expanded bootdisk to contain ALL the normally used >subroutines >for GUI support, so that my programs can average about 40K each and still be >user >friendly. Sure. And shared libraries reall help here, you'd just have to make a shlib for your GUI. No problem, although you have to be careful how you treat global data shared between clients and library. >By the way, I do have ulterior motives for wanting a lean, mean OS machine. > Will >reveal in a followup. So far this sounds like a pretty simple exercise. We look forward to hearing about your plans. Regards, Andy From vandys@glare.cisco.com Sat Apr 29 07:46:42 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00112; Sat, 29 Apr 1995 07:46:41 -0700 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id AAA08857 for ; Sat, 29 Apr 1995 00:33:51 -0700 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from chrisf for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Sat, 29 Apr 1995 17:33:48 +1000 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA10378; Sat, 29 Apr 95 17:33:17 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA15333; Sat, 29 Apr 1995 17:32:45 +1000 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199504290732.AA15333@sour.sw.oz.au> Subject: Re: separate read-file and read-dir protocol requests To: vsta@cisco.com Date: Sat, 29 Apr 1995 17:32:44 +1000 (EST) In-Reply-To: <9504260702.AA00569@rosser.serma.cea.fr> from "basile.starynkevitch@cea.fr" at Apr 26, 95 09:02:00 am Return-Receipt-To: chrisf@suite.sw.oz.au X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2081 But I thought basile.starynkevitch@cea.fr said: > > Hello All, > > (I'm the guy who on my spare time is very slowly porting the linux > ext2fs to VSTa) > > I have a question (and suggestion). Since I'm VSTa-ling (and Linuxing) > at home only and emailing at work, this is from my memory. > > Why does reading a file and reading a directory take the same request > (FS_READ, if I remember well)? I believe this is wrong (or at least a > poor choice) because: > > 1) currently, reading a dir produce a succession of lines, one per > filename. Consequently (as I understand it), a filename can't contain > a newline character (which is permitted by Posix). Although it's unlikely to be a problem, it would be nice to get file-system interoperability with other operating systems which use ext2fs. You could probably use some general escaping mechanism for encoding newlines in some manner. You'll probably have to encode carriage-returns as well. [ ... ] > 4) more interestingly, it would be very difficult to implement a > filesystem where file have both directory and bytestream structures > (like on the MacIntosh OS -forks- or the TRON OS). I believe that such > a feature is highly desirable; for instance, it would make adding > user-level metadata easier (eg an icon for a file would be just the > .ICON direntry, etc). Also, an executable would use such a thing for > symbol tables, etc. Actually, section-structured files (like > ar,tar,cpio,ELF formats on Unixes) would be easier. It would be cute. To a certain extent it could be done with user-level file-systems. Another approach I was thinking of playing around with is to be able to associate a (safe) interpretable bit of code with a file system object, which gets run by the libc code of the querying program to generate the object's file structure. Simple bits of code cold do thing like understand tar files and so on, more complex bits of code could do things like read-out records of a database file by various keys. Something like Java would be a reasonable choice for the attachment code. Christopher. From vandys@glare.cisco.com Thu May 4 07:00:01 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00077; Thu, 4 May 1995 06:59:59 -0700 Received: from stargate.promus.com (mmdf@stargate.PROMUS.COM [192.251.123.11]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id JAA28116 for ; Tue, 2 May 1995 09:50:44 -0700 Received: from ceres.promus.com by stargate.promus.com id aa22653; 2 May 95 11:41 CDT Received: by ceres.promus.com with Microsoft Mail id <2FA654EE@ceres.promus.com>; Tue, 02 May 95 10:51:10 CDT From: David Eagle To: "'vstalist'" Subject: Re: boot floppy Date: Tue, 02 May 95 11:51:00 CDT Message-ID: <2FA654EE@ceres.promus.com> Encoding: 114 TEXT X-Mailer: Microsoft Mail V3.0 > [David Eagle writes:] > > > How do I create a boot diskette? Is this even possible? If not, > >when do we expect such a capability to be ready? In particular, I would like to boot > >off a 1.4M floppy. >There are two possibilities at the moment for boot floppy support - one is >to put a dos fs on it and boot normally, but even with my patched code for >boot.exe and fd this took me about a minute to boot (demand paging from >floppy is painful). The other is to create a boot floppy image and load it >all in one go, but this means having things statically linked as boot >servers. So let me see if I understand. There IS a way to create a VSTa boot diskette. But you have to link in a special way. Is there a utility that then creates the boot diskette? Is that utility in the "complete" copy of VSTa that Andy sent me? Is there documentation on how to perform this special link? > I've been looking at some improvements though - one is to improve the >capabilities of the fd server (to implement much better caching strategies), >and the other is implement a variant on the Linux xiafs boot mechanism (if >anyone remembers this :-)). The idea would be to make the boot servers and >kernel load from a single image (pretty easy) and then have one of them load >the remainder of the diskette as a compressed boot fs image (xiafs of course >did this without compression for booting hard-drives so it couldn't move the >fs image about, but we can here). Hmmm... I don't see how improving the fd server could possibly help speed up the boot process. The fd server can't run until the OS is loaded and running! Also, why would the boot server and kernel have to be bound as a single object? In fact, why are we even talking about a "boot server"? Isn't the word "server" meant to refer to an application running under VSTa? Shouldn't we be talking about a "bootstrap loader"? I envisioned a very simple (1 or 2 K) loader that is loaded by my computer's ROM, which then has the job of loading and starting the OS. I envisioned the boot process unfolding thusly: 1. Power on computer. ROM takes over. elapsed time: nanoseconds 2. ROM finds valid boot sector on floppy disk. ROM loads and jumps to boot sector. elapsed time: tenths of seconds (assume CMOS controlled memory/integrity checks are disabled) 3. Our bootstrap loader takes over. He reads and decompresses into memory as much of the OS as we care to bind together. Let's imagine for a moment that this is a minimal kernel. elapsed time: tenths of seconds 4. The minimal kernel takes over. The first thing it does is IMMEDIATELY present a logon interface. Then, as a background process, it continues reading, decompressing, and kicking off servers, device drivers, system integrity checks, etc. etc. etc. elapsed time: maybe a full second passes between flipping the power on and seeing the logon screen. 5. The user can log in as soon as s/he wants. Some operations may be slow if the needed driver/server has not yet finished loading. 6. Once initialization is complete, all the kernel initialization code is kicked out of memory to free up more space for applications. >> >What would be really cool is if I could boot from a floppy on a floppy-only >> >system with about 8M memory, decompress the entire floppy into memory, and >> >(after allowing 3M for the expanded boot diskette and 1M for system data >> >areas) have about 4M for user program space. >> >> Sounds quite reasonable. You might want to enhance srv/tmpfs to permit >> subdirectories. Or, you could run a filesystem on top of GNU zip on top of >> the compressed data (but then you have to leave the floppy in the drive). >Something like tcx might work too. Of course another highly desireable >feature for this would be some sort of execute-in-place facility for >memory-mapped filesystems (I'm not sure if tmpfs does this or not). It's >something I'd like to get working for use with some memory mapped flash >filesystems. Basically just map the code directly, and use the data >copy-on-write. Gosh, I hope I understand this last issue once I get deeper into VSTa. From vandys@glare.cisco.com Thu May 4 07:28:50 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00241; Thu, 4 May 1995 07:28:49 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id CAA25755 for ; Wed, 3 May 1995 02:56:50 -0700 Received: from punt.demon.co.uk by disperse.demon.co.uk id bh11720; 3 May 95 10:47 GMT-60:00 Received: from humbug.demon.co.uk by punt.demon.co.uk id aa11686; 3 May 95 10:45 GMT-60:00 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0s6axW-0003p6C; Wed, 3 May 95 10:43 BST Message-Id: From: Dave Hudson Subject: More serial port speed thoughts To: VSTa mailing list Date: Wed, 3 May 1995 10:43:06 +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: 2205 Hi All, I've had some more thoughts about how to improve servers such as the serial server which generate lots of interrupts. I've discussed this briefly with Andy, and it seems a reasonable approach. Originally when I added the code to allow the user of the real-time scheduler queue the plan was to allow things like the rs232 server to run in this high priority queue and get good response to interrupts. The downside of this of course is that this means user requeusts from the server also get run at this high priority and potentially blocks other more deserving requests going on elsewhere. With the introduction of a kernel arbitrated semaphore mechanism (I've got to do some experiments with Gary's code to work out the details yet) there's now a much cleaner solution. Instead of one port for handling interrupts and requests we split the server into two threads, each of which manages one port. The first thread runs in the realtime queue and manages the port to which interrupt messages are sent. The second thread runs in the time-share queue and manages the publicly visible port (ie registered with the namer) that handles user requeusts. A couple of things drop out of this implementation: We only run at a high priority for the kernel generated M_ISR messages. We only have to do a quick check that the messages delivered to the interrupt handler port are M_ISR's from the kernel instead of having to go through a long list of possible messages. Assuming all goes well when I come to try this, it may be of use in some of the other servers that handle a lot of interrupts, and will hopefully avoid some of the starvation problems that currently exist if we're running things in the realtime queue (eg. one of my performance analysis tools causes me to loose keyboard interrupts). On a more minor performance note, the 1.3.3 implementation of the port I/O code is pretty nasty as it does lots of calling and jumping (major overheads) to do what in essence are single CPU instructions. One of the things I tweaked a few month back as part of my performance overhaul was to use inline assembly code for these functions if the code's compiled under GCC. Regards, Dave From vandys@glare.cisco.com Sun May 7 16:43:13 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00186; Sun, 7 May 1995 16:43:11 -0700 Received: from stargate.promus.com (mmdf@stargate.PROMUS.COM [192.251.123.11]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id IAA29076 for ; Fri, 5 May 1995 08:07:24 -0700 Received: from ceres.promus.com by stargate.promus.com id aa27187; 5 May 95 9:58 CDT Received: by ceres.promus.com with Microsoft Mail id <2FAA30FE@ceres.promus.com>; Fri, 05 May 95 09:06:54 CDT From: David Eagle To: "'vstalist'" Subject: Re: boot floppy Date: Fri, 05 May 95 10:06:00 CDT Message-ID: <2FAA30FE@ceres.promus.com> Encoding: 40 TEXT X-Mailer: Microsoft Mail V3.0 Dave Hudson wrote: > Ah, there's method in my madness :-) If we load a server at boot-time it > gets put into wired memory so it can have its pages stolen from under it. > These pages are also in the base 640k of RAM. What I described was to load > a boot image of say the kernel, fd, namer, env, a modified tmpfs (that > supports directories) and a special init process. The init process would > use fd to read the compressed disk image from the floppy and unpack it into > the tmpfs. Dave, I really like what I hear you saying here. Pardon my ignorance, but don't we also need servers for the video display and keyboard (in order to support the logon screen)? Or is there minimal support for this in the logon process itself? > The biggest problem in running before servers are ready is that their ports > aren't registered - I guess we could find a way round this though for a > special requirement (define a few more "well known" ports that we can wait > to become active), and it shouldn't be too hard to start executing these > servers as they're unpacked into the tmpfs. I really appreciate your "it can be done" attitude. This whole scenario sounds like a great thing to me. I would love to see it accomplished, and am willing to help. Here is one reason this might be useful: It would be great to have a lean, mean bootable floppy which could serve as the media for a serious hardware diagnostics program. David Eagle FromFrom vandys@glare.cisco.com Sun May 21 20:00:35 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisc vandys@glare.cisco.com Sun May 21 19:58:31 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]o.com (8.3/8.3) with ESMTP id UAA00094; Sun, 21 May 1995 20:00:33 -0700 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id VAA06217; Sun, 21 May 1995 21:39:29 -0700 Received: from xmission.xmission.com (shea@localhost [127.0.0.1]) by xmission.xmission.com (8.6.12/8) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00076; Sun, 21 May 1995 19:58:30 -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 VAA21398; Sun, 21 May 1995 21:56:23 -0700 Message-Id: <199505220456.VAA21398@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Gary Shea Cc: vsta@cisco.com Subject: Re: preemption In-Reply-To: Your message of "Sun, 21 May 1995 22:39:07 MDT." <199505220439..6.12) with ESMTP id WAA23285; Sun, 21 May 1995 22:39:18 -0600 Message-Id: <199505220439.WAA23285@xmission.xmission.com> To: Andrew Valencia Cc: vsta@cisco.com Subject: Re: preemption In-reply-to: Your message of "Sat, 29 Apr 1995 10:38:21 PDT." <199504291738.KAA16937@glare.cisco.com> Date: Sun, 21 May 1995 22:39:07 -0600 From: Gary Shea Andrew Valencia writes: >Currently, when running in kernel mode we can take interrupts which set >higher priority processes runnable. The code returning from the inWAA23285@xmission.xmission.com> Date: Sun, 21 May 1995 21:56:23 -0700 From: Andrew Valencia [Gary Shea writes:] >I'm looking at the code for interrupt() in trap.c. >I see the call to check_preempt() inside a test for PRIV_USER, >which as best I can tell means that when we caught the interrupt, >the system was running in user mode. Yes. >In the kernel-preemption version, I get the impression that the >call to check_preempt() would be moved outside of the PRIV_USER test. >We'd only get to that test through check_preempt(terrupt >handler could--but does not currently--cause a context switch. I'm looking at the code for interrupt() in trap.c. I see the call to check_preempt() inside a test for PRIV_USER, which as best I can tell means that when we caught the interrupt, the system was running ) and re-scheduling, >meaning possibly after some other kernel or user process has been >executing, regardless of whether we were running in user or kernel >mode. Is that right? Yup. >In that case, the possibility of race conditions in the kernel >is greatly increased, as I sein user mode. In the kernel-preemption version, I get the impression that the call to check_preempt() would be moved outside of the PRIV_USER test. We'd only get to that test through check_preempt() and re-scheduling, meaning possibly after some other kernel or user process has been executing, regardless of whether we were running in user or kernel mode. Is that right? In that case, the possibility of race conditions in the kernel is greatly increased, as I see it. In fact, I don't see how they can be avoided. Could someone please explain whe it. Absolutely correct. It's not a coincidence that the original UN*X did not have kernel preemption. It's a powerful simplifying assumption (as is uniprocessor, FWIW). >In fact, I don't see how they can >be avoided. Could someone please explain why, say in the middle >of p_sema(), we can't take an interrupt, get re-scheduled into >a user mode process running user code which accesses p_sema() >for the same semaphore again, and deadlocks? Note that check_preempt() won't preempt if the current CPU is holding any locks. Thus, at the beginning of p_sema() (for insty, say in the middle of p_sema(), we can't take an interrupt, get re-scheduled into a user mode process running user code which accesses p_sema() for the same semaphore again, and deadlocks? I thought I understood before kernel preemption, when you were guaranteed, if in kernel mode, to stay in kernel mode until you decide to leave. With kernel preemption I'm ance) where we take the lock on really lost! > Andy Gary the semaphore structure, we protect the data structure from both parallel threads on other CPUs, as well as from preemption on the current CPU. >I thought I understood before kernel preemption, when you were >guaranteed, if in kernel mode, to stay in kernel mode until >you decide to leave. With kernel preemption I'm really lost! Take a look at kern/sched.c, the check_preempt() routine. Kernel preemption still has conditions which will prevent preemption from occurring. You need to be a running thread. You must not be holding any locks. You must not have explicitly flagged inhibition of preemption. Regards, Andy From vandys@glare.cisco.com Wed May 31 06:15:51 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00132; Wed, 31 May 1995 06:15:49 -0700 Received: from comsun.rz.uni-regensburg.de (comsun.rz.uni-regensburg.de [132.199.1.163]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id AAA26396 for ; Tue, 30 May 1995 00:00:58 -0700 Received: from rchsg5.chemie.uni-regensburg.de by comsun.rz.uni-regensburg.de with SMTP id AA00841 (5.65c/IDA-1.4.4 for ); Tue, 30 May 1995 08:59:51 +0200 Received: by rchsg5.chemie.uni-regensburg.de (931110.SGI/URRZ-Sub-1.5-irix) (for vsta@cisco.com) id AA15057; Tue, 30 May 95 09:12:42 +0200 Date: Tue, 30 May 95 09:12:42 +0200 From: c5039@rchsg5.chemie.uni-regensburg.de (Harald Backert) Message-Id: <9505300712.AA15057@rchsg5.chemie.uni-regensburg.de> To: vsta@cisco.com Subject: /dev/mouse? Hi, I successfully installed VSTa 1.3.3 on my laptop (IBM 40LX, 386SX, 387SX, 10 MB RAM, 80 MB HD, PS/2 mouse). Well, it seems to work. However I cannot get /vsta/srv/mach/mouse/test to work, since test want's to open /dev/mouse, but when I try 'cd /dev', I only get an error message: cd: can't cd to /dev. How do I create an /dev/* entry? Next question: How do I change the file attributes? chmod does not exist. Do I have to compile chmod by myself? Currently I use DOS attrib, but that is not the elegant way. Another question: How do I get a swap partition working? I found no informations about this in the docs (but I remember that I saw it somewhere, I just cannot find it anymore...) Bye, Harald From vandys@glare.cisco.com Wed May 31 06:55:02 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00161; Wed, 31 May 1995 06:55:00 -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 IAA28098; Wed, 31 May 1995 08:54:42 -0700 Message-Id: <199505311554.IAA28098@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: c5039@rchsg5.chemie.uni-regensburg.de (Harald Backert) Cc: vsta@cisco.com Subject: Re: /dev/mouse? In-Reply-To: Your message of "Tue, 30 May 1995 09:12:42 +0200." <9505300712.AA15057@rchsg5.chemie.uni-regensburg.de> Date: Wed, 31 May 1995 08:54:42 -0700 From: Andrew Valencia [c5039@rchsg5.chemie.uni-regensburg.de (Harald Backert) writes:] >However I cannot get /vsta/srv/mach/mouse/test to work, since test >want's to open /dev/mouse, but when I try 'cd /dev', I only get an >error message: cd: can't cd to /dev. >How do I create an /dev/* entry? You mount the server into that path. Remember, a server advertises a port number; it is not connected with a particular filesystem path. A client can then choose to attach a server to a portion of its address space. For you case, I would do: $ mount srv/joystick /dev/mouse >Next question: How do I change the file attributes? chmod does not >exist. Do I have to compile chmod by myself? Currently I use >DOS attrib, but that is not the elegant way. The "stat" command will get the file attributes in field=value format. You can then use "stat -w field=newvalue". For DOS, you can rewrite the read-only protection, the modified/created time, and the file type (switching from symlink to regular file, which actually just toggles the hidden bit). >Another question: How do I get a swap partition working? I found no >informations about this in the docs (but I remember that I saw it >somewhere, I just cannot find it anymore...) "swapd -n" will run the swap daemon with no swap partitions. This will just reclaim pure pages. Until the next release, this page stealing will not find many pages which could be reclaimed. "swapd disk/wd:wd0_lxswap0" would start swapping using a Linux swap partition on the first IDE disk. Swapping has become more robust, but still plan on doing kernel debugging if you enable it and use it much. Andy From vandys@glare.cisco.com Thu Jun 1 06:17:11 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00082; Thu, 1 Jun 1995 06:17:09 -0700 Received: from dorka.pcug.org.au (root@ts66.pcug.org.au [203.10.76.66]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id CAA12824 for ; Thu, 1 Jun 1995 02:02:10 -0700 Received: (from root@localhost) by dorka.pcug.org.au (8.6.11/8.6.9) id TAA00346 for vsta@cisco.com; Thu, 1 Jun 1995 19:07:53 +1000 From: root Message-Id: <199506010907.TAA00346@dorka.pcug.org.au> Subject: Non-DOS partitions To: vsta@cisco.com Date: Thu, 1 Jun 1995 19:07:52 +1000 (EST) Reply-To: fbogsany@pcug.org.au X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 815 Hi, I haven't completed reading the mailing list archives yet so I hope this isn't a FAQ :). I haven't installed VSTa yet and I'm currently using my two hard drives for Linux in the following configuration: 100 mb root partition on drive 2 ~750 mb /usr partition striped across the remainder of the 2 drives Both are using ext2 file systems. Is it currently possible to install VSTa on an ext2 partition (ie is the ext2 support still read-only?), or can a VSTa native filesystem be used as the root partition for VSTa? What I really want to know is whether it is possible to install VSTa without using a DOS partition. I'd be perfectly willing to halve my root partition for this purpose but I'd rather not have to install DOS if at all possible. Thanks for any help, Francis Bogsanyi fbogsany@pcug.org.au From vandys@glare.cisco.com Mon Jun 5 06:57:12 1995 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00069; Mon, 5 Jun 1995 06:57:11 -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 IAA27944; Thu, 1 Jun 1995 08:44:10 -0700 Message-Id: <199506011544.IAA27944@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: fbogsany@pcug.org.au Cc: vsta@cisco.com Subject: Re: Non-DOS partitions In-Reply-To: Your message of "Thu, 01 Jun 1995 19:07:52 +1000." <199506010907.TAA00346@dorka.pcug.org.au> Date: Thu, 01 Jun 1995 08:44:10 -0700 From: Andrew Valencia [root writes:] >Is it currently possible to install VSTa on an ext2 partition (ie is the ext2 >support still read-only?), or can a VSTa native filesystem be used as the >root partition for VSTa? I'm told VSTa runs read-only on an ext2 filesystem. VSTa can certainly use a vstafs for its root. >What I really want to know is whether it is possible >to install VSTa without using a DOS partition. I'd be perfectly willing to >halve my root partition for this purpose but I'd rather not have to install >DOS if at all possible. Since the boot loader is a DOS program, I'm not sure how you'd run it without a DOS filesystem for it to access? Dave Hudson got a standalone boot floppy going, but I don't imagine it would be very pleasant for the long run. Both Dave and myself are on a mailing list which is putting together a standard for boot loader technology ("MultiBoot Standard"). If you are interested in chipping in on this front, I'd welcome the help! If your concern is dealing with finding a copy of DOS, be aware that VSTa boots just fine from FreeDOS, too. Regards, Andy From vandys@puli.cisco.com Wed Jun 7 10:08:40 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00174; Wed, 7 Jun 1995 10:08:39 -0700 Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id MAA10032 for ; Wed, 7 Jun 1995 12:09:43 -0700 Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id MAA26176 for ; Wed, 7 Jun 1995 12:10:56 -0700 Received: from unknown(204.30.20.6) by gate.itron-ca.com via smap (V1.3mjr) id sma026173; Wed Jun 7 12:10:06 1995 Received: from jerry.itron-ca.com by sungod.itron-ca.com (4.1/SMI-4.1) id AA00589; Wed, 7 Jun 95 12:10:06 PDT Message-Id: <9506071910.AA00589@sungod.itron-ca.com> X-Sender: jerry@sungod Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jun 1995 12:12:01 -0700 To: vsta@cisco.com From: jerry@itron-ca.com (Jerry O'Keefe) Subject: Adding my name to the vsta mailing list X-Mailer: I've been the studying the VSTA sources the last week or so. It looks very interesting. I have it loaded and running on a Sharp PC-8700 portable. I do have some experience with modifying KA9Q, so if I can help in that regard, please let me know. Any way please add my name to the VSTA mailing list. jerry@itron-ca.com Regards Jerry O'Keefe From vandys@puli.cisco.com Thu Jun 15 06:55:50 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00162; Thu, 15 Jun 1995 06:55:49 -0700 Received: from dorka.pcug.org.au (root@ts73.pcug.org.au [203.10.76.73]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id WAA05524 for ; Tue, 13 Jun 1995 22:06:15 -0700 Received: (from root@localhost) by dorka.pcug.org.au (8.6.11/8.6.9) id PAA00560 for vsta@cisco.com; Wed, 14 Jun 1995 15:12:28 +1000 From: root Message-Id: <199506140512.PAA00560@dorka.pcug.org.au> Subject: VSTafs partitions To: vsta@cisco.com Date: Wed, 14 Jun 1995 15:12:27 +1000 (EST) Reply-To: fbogsany@pcug.org.au X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1728 Hi, Well I have VSTa running now (after a massive repartitioning effort). Now I'd like to create a vstafs partition. Small question: without the /dev entries used under UNIX, how do we refer to physical disk partitions? The dos line in the boot.lst file refers to its partition as wd:wd0_dos1 (sorry, I'm using Linux at the moment and I can't remember if that last digit is 1 or 0). There doesn't seem to be an entry for this in the /namer/disk directory, so when I try to create a vstafs partition by typing mkfs_vfs with either wd:wd0_p3 or wd:wd0_p2 or wd:wd0_dos2 (that could be a 1 :)) and of course the size of the partition, it just bombs out on me with a variety of error messages. I also tried the series of commands suggested by Andy when he first released vstafs, but I couldn't get them to work either with or without the dos, disk and init lines in the boot.lst file (vsta wouldn't boot without them). I suspect that things have progressed considerably beyond those days and this series of commands is simply irrelevant now :). My second hard disk is devoted to linux and my 1st is set up as: partition size fs 1 ~200Mb DOS 2 ~100Mb ext2fs 3 ~90Mb DOS 4 ~16Mb linux swap I want to set up the 3rd partition as vstafs (it is currently empty) and then use this as my root partition for vsta. I presume for the latter operation I simply need to adjust the fstab appropriately, however for the former I need a little assistance. Could someone please indicate the series of commands required to set up the partition and the changes required for the system initialisation files in order to boot from DOS and then use the vstafs partition for the vsta root ? Thanks, __ F. Bogsanyi fbogsany@pcug.org.au From vandys@puli.cisco.com Fri Jun 16 05:57:31 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00127; Fri, 16 Jun 1995 05:57:30 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA06393; Fri, 16 Jun 1995 08:00:16 -0700 Message-Id: <199506161500.IAA06393@puli.cisco.com> To: fbogsany@pcug.org.au Cc: vsta@cisco.com Subject: Re: VSTafs partitions In-Reply-To: Your message of "Wed, 14 Jun 1995 15:12:27 +1000." <199506140512.PAA00560@dorka.pcug.org.au> Date: Fri, 16 Jun 1995 08:00:16 -0700 From: Andrew Valencia [root writes:] > Well I have VSTa running now (after a massive repartitioning effort). >Now I'd like to create a vstafs partition. Small question: without the /dev >entries used under UNIX, how do we refer to physical disk partitions? Mumble. I'm thinking about folding namer paths into the main open() code path. Currently they're distinct, and it's causing most of your confusion. >The dos >line in the boot.lst file refers to its partition as wd:wd0_dos1 (sorry, I'm >using Linux at the moment and I can't remember if that last digit is 1 or 0). >There doesn't seem to be an entry for this in the /namer/disk directory, so >when I try to create a vstafs partition by typing mkfs_vfs with either wd:wd0_ >p3 >or wd:wd0_p2 or wd:wd0_dos2 (that could be a 1 :)) and of course the size of t >he >partition, it just bombs out on me with a variety of error messages. The namer path should disk/wd. This maps a path to a port number. When you mount that port number in your namespace, the server at that port number looks like a directory tree. So disk/wd:wd0_dos0 is shorthand, conceptually, for "mount disk/wd on /FOO, and then open /FOO/wd0_dos0". I say conceptually, because it doesn't really join your filesystem namespace. Things should become clearer if you do: % mount disk/wd /dev/wd % ls /dev/wd You can now use /dev/wd/wd0_dos0 (or whatever) as a regular file, in much the same way as /dev entries in UNIX. When you're finished fiddling with your disk, you can also: % umount /dev/wd You should be able to run vstafs as: % vstafs -p disk/wd:wd0_dos0 fs/vfs & Which starts a filesystem from the wd0_dos0 entry of the server registered (under namer) as disk/wd. It registers this filesystem (under namer) as fs/vfs. Once it's running, you could: % mount fs/vfs /v % ls /v And see your filesystem under /v. Andy From vandys@puli.cisco.com Sun Jun 18 07:22:22 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00095; Sun, 18 Jun 1995 07:22:19 -0700 Received: from uxc.cso.uiuc.edu (uxc.cso.uiuc.edu [128.174.5.50]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id MAA08327 for ; Fri, 16 Jun 1995 12:55:08 -0700 Received: from fiction.isdn.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA05917 (5.67b8/IDA-1.5 for ); Fri, 16 Jun 1995 14:54:48 -0500 Received: (from jeske@localhost) by fiction.isdn.uiuc.edu (8.6.9/8.6.9) id OAA16620 for vsta@cisco.com; Fri, 16 Jun 1995 14:56:43 -0500 From: David Jeske Message-Id: <199506161956.OAA16620@fiction.isdn.uiuc.edu> Subject: Re: VSTa mounting and paths To: vsta@cisco.com Date: Fri, 16 Jun 1995 14:56:43 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2487 > Mumble. I'm thinking about folding namer paths into the main open() code > path. Currently they're distinct, and it's causing most of your confusion. > > The namer path should disk/wd. This maps a path to a port number. When you > mount that port number in your namespace, the server at that port number > looks like a directory tree. So disk/wd:wd0_dos0 is shorthand, > conceptually, for "mount disk/wd on /FOO, and then open /FOO/wd0_dos0". I > say conceptually, because it doesn't really join your filesystem namespace. [Andrew's mounting explanation deleted] That also cleared up some confusion I had about the whole disk/wd:?? bussiness. Into the FAQ it goes :) However, it reinforces the previous thoughts I had. I assume (perhaps incorrectly) that when you said you were thinking of folding namer paths into the main open() code path that "disk/wd" would essentally be part of the man open() code path, thus you could directly mount "disk/wd/wd0_dos0" somewhere? While I think the shorthand and concept behind the disk/wd:wd0_disk0 is slightly confusing (espectially before a proper explanation), I think it would make more sense to keep the namer paths separate, but allow them to work slightly more like normal paths, in that "disk/wd/wd0_dos0 would mean to open "wd0_dos0" from the server available in the namer path "disk/wd". Perhaps these things are nearly mutually exclusive, or perhaps I'm still confused about how namer paths are distinct from the main pathspace. After having said that, I would like to test if I understand the idea behind the current layout. If I were to create a second "namer" which would make itself available in the "real" first namer, and then run wd and have itself registered in the second namer, would it then be logical to use "namer2:disk/wd:wd0_dos0" to refer to the partition? If this concept is correct, then I understand the logic behind things and I really think that just a good expanation is the real solution to the confusion. -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) -- jeske@uiuc.edu + David Jeske(N9LCA) NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008 User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) FromFrom vandys@puli.cisco.com Mon Jun 19 18:31:05 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00139; Mon, 19 Jun 1995 18:31:04 -0700 Received: from w4sun5.ccl.itri.org.tw (w4sun5.ccl.itri.org.tw [140.96.111.5]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id CAA07517 for ; Mon, 19 Jun 199 vandys@puli.cisco.com Mon Jun 19 18:31:12 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00141; Mon, 19 Jun 1995 18:31:06 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA06138 for ; Mon, 19 Jun 1995 01:37:05 -0700 Received: from punt.demon.co.uk by disperse.demon.co.uk id ab12377; 19 Jun 95 9:28 +0100 Received: from humbug.demon.co.uk by punt.de5 02:36:30 -0700 Received: from cclw400.ccl.itri.org.tw by w4sun5.ccl.itri.org.tw (4.1/SMI-4.1) id AA19379; Mon, 19 Jun 95 17:50:29 CST Received: from CCLW400/SpoolDir by cclw400.ccl.itri.org.tw (Mercury 1.13); Mon, 19 Jun 95 17:30:48 gmt+800 Received: from SpoolDir by CCLW400 (Mercury 1.13); Mon, 19 Jun 95 17:30:40 gmt+800 From: "James Lee" Organization: ITRI/CCL/W400 To: vsta@cisco.com Date: Mon, 19 Jun 1995 17:30:37 GMT+800 Subject: vsta info Priority: normal X-Mailer: Pegasus Maimon.co.uk id aa15692; 19 Jun 95 9:28 +0100 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0sNbun-00036rC; Mon, 19 Jun 95 09:10 BST Message-Id: From: Dave Hudson Subject: Re: VSTa mounting and paths To: jeske@uiuc.edu Date: Mon, 19 Jun 1995 09:10:36 +0100 (BST) Cc: VSTa mailing list In-Reply-To: <199506161956.OAA16620@fiction.isdn.uiuc.edu> from "David Jeske" at Jun 16, 95 02:56:43 pm X-Mailer: ELM [version 2.4 PL23] MIME-Versiol/Windows (v1.22) Message-Id: <3A4BFC70BD0@cclw400.ccl.itri.org.tw> Please email me more info about vsta. Thanks. James Lee Computer & Communications Lab Industrial Technology Research Institute phone: 886-35-78-1390x303 fax: 886-35-78-1398 jlee@ccl.itri.org.tw n: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2536 Hi, David Jeske wrote: > > > Mumble. I'm thinking about folding namer paths into the main open() code > > path. Currently they're distinct, and it's causing most of your confusion. > > > > The namer path should disk/wd. This maps a path to a port number. When you > > mount that port number in your namespace, the server at that port number > > looks like a directory tree. So disk/wd:wd0_dos0 is shorthand, > > conceptually, for "mount disk/wd on /FOO, and then open /FOO/wd0_dos0". I > > say conceptually, because it doesn't really join your filesystem namespace. > > However, it reinforces the previous thoughts I had. I assume (perhaps > incorrectly) that when you said you were thinking of folding namer paths > into the main open() code path that "disk/wd" would essentally be part of > the man open() code path, thus you could directly mount "disk/wd/wd0_dos0" > somewhere? While I think the shorthand and concept behind the > disk/wd:wd0_disk0 is slightly confusing (espectially before a proper > explanation), I think it would make more sense to keep the namer paths > separate, but allow them to work slightly more like normal paths, > in that "disk/wd/wd0_dos0 would mean to open "wd0_dos0" from the > server available in the namer path "disk/wd". Perhaps these things are nearly > mutually exclusive, or perhaps I'm still confused about how namer paths > are distinct from the main pathspace. I think the confusion comes because it's difficult to differentiate a server path from a normal path. The obvious solution that springs to mind is to prefix server paths with a magic character. We already have "@" (if I remember correctly) for handling environment path expansions. Plan 9 devices use a prefix hash symbol "#" (I believe this is known as a pound symbol in the US (or at least that's what the Plan 9 docs call it), but that confuses me as a pound symbol is the currency one (looks like a squiggly L) over here :-)). Perhaps the solution is to patch libc to allow something similar, thus we have: #disk/wd:wd0_dos0 as a server/path, and the more conventional /dev/wd/wd0_dos0 for when #disk/wd has been mounted at /dev. This might mean a reasonable amount of extra work to patch some of the utils (actually removing quite a bit of code I suspect), but would give us a pretty consistent view. If nothing else, adopting something like this gives us a consistent way to name files within VSTa (it's implicit whether we have a server reference or a "mounted" pathname). Regards, Dave From vandys@puli.cisco.com Tue Jun 20 15:23:40 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA00073; Tue, 20 Jun 1995 15:23:39 -0700 Received: from pcug.org.au (supreme.pcug.org.au [203.10.76.34]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id GAA00365 for ; Tue, 20 Jun 1995 06:15:11 -0700 Received: from ts67.pcug.org.au (ts67.pcug.org.au [203.10.76.67]) by pcug.org.au (8.6.9/8.6.9) with SMTP id XAA17025 for ; Tue, 20 Jun 1995 23:14:21 +1000 Message-Id: <199506201314.XAA17025@pcug.org.au> X-Sender: fbogsany@pcug.org.au X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Jun 1995 23:21:30 +1100 To: vsta@cisco.com From: fbogsany@pcug.org.au (Francis Bogsanyi) Subject: VSTa Partitions Hi, thaFrom vandys@puli.cisco.com Tue Jun 20 15:22:04 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA00064; Tue, 20 Jun 1995 15:22:03 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA19057; Tue, 20 Jun 1995 15:26:38 -0700 Message-Id: <199506202226.PAA19057@nks for the responses to my questions, now for the second round :-). I now have VSTa booting from a DOS partition and then running a VSTa partition (partition 3 or wd0_dos1, 90Mb) as the root partition. My problems now are: 1. runrc has the location of sh hardcoded into it. I fixed this by hardcoding the new location into it :-). (I don't know anything about rcs so I simply used cat to create a writeable version of the file runrc.c). The question is, how many other programs expect specific locations (in particularpuli.cisco.com> To: Dave Hudson Cc: jeske@uiuc.edu, VSTa mailing list Subject: Re: VSTa mounting and paths In-Reply-To: Your message of "Mon, 19 Jun 1995 09:10:36 BST." Date: Tue, 20 Jun 1995 15:26:37 -0700 From: Andrew Valencia [Dave Hudson writes:] >... Perhaps the solution is to patch libc to allow something >similar, thus we have: > #disk/wd:wd0_dos0 >as a server/path, and the more conventional > /dev/wd/wd0_dos0 >for when #disk/wd has been mounted at /dev. Sounds good. >This might mean a reasonable amount of extra work to patch some of the >utils (actually removing quite a bit of code I suspect), but would give us a >pretty consistent view. If nothing else, adopting something like this gives >us a consistent way to name files within VSTa (it's implicit whether we have >a server reference or a "mounted" pathname). I agree. The dichotomy between what is advertised as a service and how many expect a leading /vsta) ? 2. I altered the rc shell script to setup the path as "/bin:/boot:." however sh then bombs out complaining about the two colons and the "exit 0" at the end of the script. 3. Since the script bombs out, the TERM environment variable is not set but if I leave it that way, or set it using the same command line as the rc script, neither vi nor emacs work. vi responds with a message that nansi is not supported and I should try one of the supported m what is available in your name space should be preserved. The question is how you straddle the two name spaces. Currently, it's done by distinct function calls. I think a convention like Dave proposes is a reasonable improvement. Andy odes (which it lists), yet trying these modes simply responds with an even quicker version of the same message and again it doesn't work. less also comes up with a series of messages indicating that it can't scroll backwards, can't clear the screen etc. these are all the same messages that I get when I set the TERM variable to unknown under Unix. These three problems are fairly major, in particular the last two, and of course without the editors it is impossible to edit anything! I have resorted to simply booting under DOS and running the system from the /vsta directory on the dos partition and mounting my vsta partition under /v, but I'd prefer to be able to just use the VSTa partition (which otherwise works quite nicely). As a small aside, does anyone know where a partition actually starts? When I formatted the VSTa partition I used a size equal to the number of sectors that fdisk (under Linux) said were available for that partition, yet after I copied the entire system across to the new partition and then used dd to capture (again under Linux) the first few K of the partition, I found that the first sector of the partition (struct fs, according to vstafs.h) actually started 31.5 K into the partition. The offsets and contents of the rest of the partition seemed to be correct and the preceding bytes were 0. Is this normal? This was originally a dos partition and is now recognised by linux as an extended dos partition, though it won't mount it (bad magic number) although Windows doesn't seem to mind me accessing it (just gives me "no files found"). I'd appreciate any help with the 2nd and 3rd problems, the first is simply something I'm curious about, as is the start of the partition question. Thanks ______ Francis Bogsanyi fbogsanyi@pcug.org.au From vandys@puli.cisco.com Wed Jun 21 18:55:03 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00064; Wed, 21 Jun 1995 18:55:02 -0700 Received: from apollo.is.co.za (apollo.is.co.za [196.4.160.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id LAA00215 for ; Wed, 21 Jun 1995 11:56:10 -0700 Received: by apollo.is.co.za (8.6.12/SMI-SVR4tmp8) id UAA12489; Wed, 21 Jun 1995 20:57:12 +0200 Date: Wed, 21 Jun 1995 20:57:11 +0200 (GMT) From: Datrix Solutions To: vsta@cisco.com Subject: File permission problem? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is the first problem I have come across after a very smooth install. When editing my own .c files with vi and using gcc to compile them, I get a perm error - gcc won't run - some files were compiling until I edited them. I ran ls -l and could not see the difference in permissions or anything else, between the compile and non-compilable files (I have logged in as different users). Could someone talk a bit about permissions, maybe I am doing something wrong? regards, Wayne From vandys@puli.cisco.com Wed Jun 21 18:58:43 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00105; Wed, 21 Jun 1995 18:58:41 -0700 Received: from apollo.is.co.za (apollo.is.co.za [196.4.160.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA19240 for ; Wed, 21 Jun 1995 10:30:28 -0700 Received: by apollo.is.co.za (8.6.12/SMI-SVR4tmp8) id TAA11082; Wed, 21 Jun 1995 19:31:31 +0200 Date: Wed, 21 Jun 1995 19:31:29 +0200 (GMT) From: Datrix Solutions To: vsta@cisco.com Subject: Java Support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have just discovered VSTa. I installed the distribution on three machines (2 laptops) and it compiled and built fine. I sometimes get the "1980 is before 1990" warning, and permission faults in the untar, not sure what they mean... I immediately wrote a printf process that I ran multiple time in the background, and then fired up 2 x gcc's. I am very impressed with the multitasking and the availability of good interaction during heavy processing. I must say that I am very new to this level of systems programming. I am used to templates, inheritance, etc, ... right I'm a C++ programmer. I can see that it must be a diffucult task to write an operating system in C++. I think a programmer should at stage be able to visualize roughly how the code will look in assembly - so necessary for optimal machine code. I am busy going through the (large) archives. Has anyone been looking at Java? I posted a message to their porting mailing list asking what minimal support is required for Java (heard about VSTa) I had this idea that an operating system could be hard-coded to only handle TCP/IP, Graphics, Http, virtual memory, etc + Java VM. Booting off one floppy disk into an html/Java/ppp type environment, would be kinda nice. Most of the systems code code be uploaded as Java itself. I have already "evangalized" VSTa :-), I am planning to do a lot of experimenting with it, but have a lot to learn first. I have bought a few books on i386/i486 architecture and programming. But the problem is 10 million other things pressing :-( cheers, Wayne From vandys@puli.cisco.com Wed Jun 21 18:58:44 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00110; Wed, 21 Jun 1995 18:58:43 -0700 Received: from npt.nuwc.navy.mil (NPT.NUWC.NAVY.MIL [129.190.70.100]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id IAA10257 for ; Wed, 21 Jun 1995 08:28:49 -0700 Received: from c38fs0.npt.nuwc.navy.mil by npt.nuwc.navy.mil with SMTP ; Wed, 21 Jun 95 11:30:30 EDT Received: from 38ntserv (edr) by c38fs0.npt.nuwc.navy.mil (4.1/SMI-4.1) id AA16336; Wed, 21 Jun 95 11:27:27 EDT Message-Id: <9506211527.AA16336@c38fs0.npt.nuwc.navy.mil> X-Sender: eroberts@c38.npt.nuwc.navy.mil X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jun 1995 11:28:14 -0300 To: vsta@cisco.com From: eroberts@C38FS0.npt.nuwc.navy.mil (Edward Roberts) Subject: Request for information Please send info (maybe a URL?) about VSTa microkernel... ed roberts G. Edward Roberts Code 3822 Naval Undersea Warfare Center 1176 Howell St. Newport, RI 02841-1708 (401)841-3933 FAX (401)841-1710 1-800-NAVY-LAD pick Newport and extention 1237 or 3933 (sec) eroberts@c38.npt.nuwc.navy.mil From vandys@puli.cisco.com Thu Jun 22 05:37:12 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00097; Thu, 22 Jun 1995 05:37:11 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id VAA04013; Wed, 21 Jun 1995 21:36:15 -0700 Message-Id: <199506220436.VAA04013@puli.cisco.com> To: Datrix Solutions Cc: vsta@cisco.com Subject: Re: File permission problem? In-Reply-To: Your message of "Wed, 21 Jun 1995 20:57:11 +0200." Date: Wed, 21 Jun 1995 21:36:15 -0700 From: Andrew Valencia [Datrix Solutions writes:] >When editing my own .c files with vi and using gcc to compile them, I get >a perm error - gcc won't run - some files were compiling until I edited >them. I ran ls -l and could not see the difference in permissions or anything >else, between the compile and non-compilable files (I have logged in as >different users). When this happens, could you try: % umount /tmp and try again? There's a bug where tmpfs won't allow even the owner to rewrite an existing file. If you do "gcc -c *.c", gcc (correctly) just keeps using the same temp files, which we won't let him rewrite. It's one of those little things I never manage to nail. If you're interested feel free to hunt it down (in srv/tmpfs/open.c, probably) and provide a patch. Regards, Andy Valencia From vandys@puli.cisco.com Thu Jun 22 06:34:13 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00155; Thu, 22 Jun 1995 06:34:12 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA21890; Thu, 22 Jun 1995 08:38:07 -0700 Message-Id: <199506221538.IAA21890@puli.cisco.com> To: fbogsany@pcug.org.au (Francis Bogsanyi) Cc: vsta@cisco.com Subject: Re: VSTa Partitions In-Reply-To: Your message of "Tue, 20 Jun 1995 23:21:30 +1100." <199506201314.XAA17025@pcug.org.au> Date: Thu, 22 Jun 1995 08:38:07 -0700 From: Andrew Valencia [fbogsany@pcug.org.au (Francis Bogsanyi) writes:] > 1. runrc has the location of sh hardcoded into it. I fixed this by >hardcoding the new location into it :-). (I don't know anything about rcs so >I simply used cat to create a writeable version of the file runrc.c). The >question is, how many other programs expect specific locations (in >particular how many expect a leading /vsta) ? Lots. :-) > 2. I altered the rc shell script to setup the path as "/bin:/boot:." >however sh then bombs out complaining about the two colons and the "exit 0" >at the end of the script. You might have been bit by inserting DOS-style line termination on the file when you edited it? When I work from DOS I use the "vim" editor with the "-b" flag to avoid this. > 3. Since the script bombs out, the TERM environment variable is not >set but if I leave it that way, or set it using the same command line as the >rc script, neither vi nor emacs work. vi responds with a message that nansi >is not supported and I should try one of the supported modes (which it >lists), yet trying these modes simply responds with an even quicker version >of the same message and again it doesn't work. less also comes up with a >series of messages indicating that it can't scroll backwards, can't clear >the screen etc. these are all the same messages that I get when I set the >TERM variable to unknown under Unix. You might try: echo -n vt100 > /env//TERM and see what happens. Environment variables come from the /env server, and this is a simple way to interact with the server directly. You could eve do: echo -n vt100 > /env/TERM and set a system-wide default. > As a small aside, does anyone know where a partition actually >starts? You can do: % mount disk/wd /wd % ls /wd % stat /wd/wd0_dos0 The "size" and "pextoffs" fields will tell you where VSTa thinks a given partition lives (and how long it is). Regards, Andy Valencia From vandys@puli.cisco.com Sat Jun 24 04:53:16 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00083; Sat, 24 Jun 1995 04:53:15 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id RAA22312 for ; Fri, 23 Jun 1995 17:04:53 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id SAA10817 for vsta@cisco.com; Fri, 23 Jun 1995 18:56:54 -0500 From: David Jeske Message-Id: <199506232356.SAA10817@terra.igcom.net> Subject: DOS server debugging continues To: vsta@cisco.com Date: Fri, 23 Jun 1995 18:56:53 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 654 Actually, after looking through fdl.c from libc and the cam code, I don't understand how "read()" could ever read more than 4096 bytes. Which it clearly does when the DOS server is started as a boot server from the boot.lst. (otherwise it wouldn't be able to read ANY FATs over 4096 bytes) So why is "read()" able to read more than 4096 bytes from the cam server in one call when the DOS server is a boot server, but is only able to read 4096 bytes per "read()" when the same DOS server is launched after boot time? David (who is happy to be running into such relatively simple problems such that I can learn much about VSTa from them) From vandys@puli.cisco.com Sat Jun 24 04:53:15 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00081; Sat, 24 Jun 1995 04:53:13 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id QAA19027 for ; Fri, 23 Jun 1995 16:20:49 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id SAA09173 for vsta@cisco.com; Fri, 23 Jun 1995 18:12:49 -0500 From: David Jeske Message-Id: <199506232312.SAA09173@terra.igcom.net> Subject: MSDOS server debugging problems To: vsta@cisco.com Date: Fri, 23 Jun 1995 18:12:49 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1889 Hello everyone, I've been VSTa-less for FAR too long because of bugs in the DOS server so I'm now taking some steps to do something about it. The problems come from several places, first of which is the fact that the DOS server dosn't like something that Win95 does to the disk structures to achieve it's "totally backward compatible long filenames". There is also trouble when I try and use the DOS server on a large extended DOS partition I have. I'm not sure exactly what the root of that problem is... but I'll find out. Anyhow, since I never was able to get ahold of a bootable VSTa floppy, I recently formatted my MSDOS "c:" partition so it would be nice and clean and the VSTa DOS server would like it. Fortunatly, it does like it. So, to begin the struggle here, I'm trying to get the DOS server to startup for the extended partition which still has some remnants of what Win95 did to it. Ok, so I have a problem. When I start the DOS server with the line: dos -p cam:sd1_dos0 fs/d it immediately bombs. The syslog error says dos (pid 3852) error: read (95744 bytes) of FAT failed I changed the line in fat.c which does the "read()" so that it stores the amount it actually DOES read and it only gets 4096 bytes. According to the information in the Bios Parameter Block for that partition, the FAT should be 187 sectors long, which checks out with the 95744 bytes that the DOS server thinks it should be reading. I did some manual "dumpsect" reads around the 9th sector and none of them had any problems reading the data. So my question is: why would "read()" only read part of what it was asked to read? the DOS server expects it to be read all in one call and it works fine for my other FAT filesystem. Should the DOS server be able to handle a partial read and just continue? Or is there some deeper problem which is causing the partial read? From vandys@puli.cisco.com Thu Jun 29 18:13:36 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00104; Thu, 29 Jun 1995 18:13:35 -0700 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id UAA00232 for ; Wed, 28 Jun 1995 20:15:32 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id XAA00614; Wed, 28 Jun 1995 23:16:43 -0400 Date: Wed, 28 Jun 1995 23:16:43 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: vsta source tree, location? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am not able to get into ftp.netcom.com. Could somebody let me know any other sites where I could get vsta. Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca BEng Computer Sys. From vandys@puli.cisco.com Thu Jun 29 18:10:18 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00099; Thu, 29 Jun 1995 18:10:15 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id RAA00384 for ; Thu, 29 Jun 1995 17:05:21 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id SAA16110 for vsta@cisco.com; Thu, 29 Jun 1995 18:56:45 -0500 From: David Jeske Message-Id: <199506292356.SAA16110@terra.igcom.net> Subject: Help: pdisk/cam problem, even more info To: vsta@cisco.com Date: Thu, 29 Jun 1995 18:56:44 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 4708 **** Here is the short version: **** I'm using a 486dx2/66 with 32meg RAM, an adaptec 1542C, 2 1gb quantums, 1 350meg Maxtor, 1 CDROM and 1 4mm DAT drive, VSTa is on the DOS partition on the 1st Quantum (sd0_dos0) and it works fine. For some reason reads to certain partitions will only read 4096 bytes per "read()" call. Successive calls can read the foFrom vandys@puli.cisco.com Thu Jun 29 18:11:34 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00101; Thu, 29 Jun 1995 18:11:33 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id AAA06354 for ; Wed, 28 Jun 1995 00:21:18 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id CAA28789 for vsta@cisco.com; Wed, 28 Jun 1995 02:12:53 -0500 From: David Jeske Message-Id: <199506280712.CAA28789@terra.igcom.net> Subject: RAMDISK filesystem idea/question To: vsta@cisco.com Date: Wed, 28 Jun 1995 02:12:53 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1810 llow I noticed this in a post about boot floppys a short while back, I'm not sure who wrote what: >> Sounds quite reasonable. You might want to enhance srv/tmpfs to permit >> subdirectories. Or, you could run a filesystem on top of GNU zip on >> top of the compressed data (but then you have to leave the floppy in >> the drive). is there any reason that a static RAMDISK filesystem could not be created by making a server which just allowed file-access to a pre-sized piece of RAM and then running a fileing bytes just fine, but again, it always returns having read only 4096 bytes. (or less if you asked for less) The only pattern I can see is that all of the problems occur reading partitions over the "512mb" mark on the hard drives. Which leads me to believe it's really a pdisk, or a pdisk/cam relationship problem. Since "standard" drive size information imposes a 512MB limit (512bytes/sector * 1024sectors?? I'm not sure if that's where the limit comes from or something else, i'm a bit foggy) I've also observed that when working the the raw "sd0" device, I can not read any data past byte 262144, or in other words, I can't read any sector above 511. So if you have any idea why pdisk or cam would have problems with drives over 512MB or space on drives over the 512MB mark... please read on. **** Here issystem on top of that? Not that it would be the most efficient way to do it, but is there any significant reason NOT to do it? The more I think about this the more stupid and wastefull it sounds, so I guess it's kind of a silly idea, however, it's late and I can have silly ideas. Is the compression algorithm used by GNU zip suitable for random access to the underlying data? I was under the impression that it was VERY stream oriented. (not that another compression could not be used in the middle, I was just wondering about G the long version: **** As I explained in the last two messages, I've been having trouble accessing certain partitions on my SCSI drives. For some reason, some partitions will only read 4096 bytes with each "read()" call. Successive "read()" calls can read the information which follows just fine, so it's not that there is something at a particular location which stopped the read. I've been sludging through cam and pdisk code and I can't find any obvious logical reason that my problem persists. I understand wNU zip) I suppose one advantage of enhancing srv/tmpfs instead is that it would not have to be statically sized. However, this might be a disadvantage in the case of a boot-floppy. >Something like tcx might work too. Of course another highly desireable >feature for this would be some sort of execute-in-place facility for >memory-mapped filesystems (I'm not sure if tmpfs does this or not). It's >something I'd like to get working for use with some memory mapped flash >filesystems. Basically just map the code directly, and usehy the magic number is 4096 bytes though. The cam code cuts up requests into 4096 byte calls to the adaptor. When a read is made to a partition which exhibits the problem, the first read to the adaptec is successfull, while the second one returns having read 0 bytes. I don't understand why it occurs on a partition by partition basis though. Which is why I started looking at the pdisk code. Unfortunatly, I still don't have any leads on what specifically would be causing it so I thought I would throw out some more i the data >copy-on-write. I'm fairly sure that doing execute-in-place of a RAM based program THROUGH another filesystem driver would not be possible. (or at least it would be more difficult than writing a native XIP server) nformation I gained from testing and hope someone else has some ideas. Right now, my best guess is that it has to do with the magic "512mb" size associated with "standard" drive size information. (the 512bytes/sector 1024sector limit) However, I'm still learning how the whole pdisk/cam relationship works to find out how this would factor in. I wrote a small test program which does successive reads starting at 1k and incrementing up by 1k each iteration until it reaches 10k. I ran the program on every partition I have available. There are three partitions which "fail" and can only read 4096 bytes per "read()". All other partitions work fine. The partitions which "fail" do it consistantly, I can reboot and such and they still "fail". The three partitions which fail are: sd0_lxnat0 sd1_lxswap0 sd1_dos0 Here is the partition information for all three drives from Linux fdisk. I marked the partitions which have problems under VSTa. Of course I have no problems under any other operating systems. **** My first hard drive: (1gb, Quantum 1080S, sd0) Disk /dev/sda: 64 heads, 32 sectors, 1029 cylinders Units = cylinders of 2048 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/sda1 1 1 420 430064 a7 Unknown /dev/sda2 * 421 421 421 1024 a OS/2 Boot Manager /dev/sda3 422 422 721 307200 6 DOS 16-bit >=32M /dev/sda4 722 722 1029 315392 83 Linux native <--fail Partition 4 has different physical/logical endings: phys=(1023, 63, 32) logical=(1028, 63, 32) **** My second hard drive: (1gb, Quantum 1080S) Disk /dev/sdb: 64 heads, 32 sectors, 1029 cylinders Units = cylinders of 2048 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/sdb1 1 1 300 307184 7 OS/2 HPFS /dev/sdb2 301 301 821 533504 83 Linux native /dev/sdb3 822 822 842 21504 82 Linux swap <--fail /dev/sdb4 843 843 1029 191488 5 Extended Partition 4 has different physical/logical endings: phys=(1023, 63, 32) logical=(1028, 63, 32) /dev/sdb5 843 843 1029 191472 6 DOS 16-bit >=32M <--fail **** My third hard drive: (350meg, Maxtor) Disk /dev/sdc: 64 heads, 32 sectors, 329 cylinders Units = cylinders of 2048 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/sdc1 1 1 329 336880 a7 Unknown **** From vandys@puli.cisco.com Thu Jun 29 18:45:24 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00170; Thu, 29 Jun 1995 18:45:23 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id LAA10359 for ; Mon, 26 Jun 1995 11:48:10 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id NAA25691; Mon, 26 Jun 1995 13:39:54 -0500 From: David Jeske Message-Id: <199506261839.NAA25691@terra.igcom.net> Subject: Debugging Continues (possible cam problem) To: vsta@cisco.com Date: Mon, 26 Jun 1995 13:39:53 -0500 (CDT) Cc: larz@world.std.com X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1634 After digesting large amounts of code, I have come up with the source of my 4096 byte problem. For some reason, the second read request issued inside the cam code always "fails", it reads 0 bytes (count=0) even though xfer_count=4096. In other words, the first time through "cam_cntuio" (in scsicmds.c) 4096 bytes were read successfully. cam_cntuio then reschedules the second read, and when cam_cntuio is called again, count=0, so it cleans up and signals the read as finished. It only happens on this ONE partition on this ONE drive. The partition happens to be an extended DOS partition. Here is the partition table from the second drive as printed from Linux fdisk: ********************** Command (m for help): p Disk /dev/sdb: 64 heads, 32 sectors, 1029 cylinders Units = cylinders of 2048 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/sdb1 1 1 300 307184 7 OS/2 HPFS /dev/sdb2 301 301 821 533504 83 Linux native /dev/sdb3 822 822 842 21504 82 Linux swap /dev/sdb4 843 843 1029 191488 5 Extended Partition 4 has different physical/logical endings: phys=(1023, 63, 32) logical=(1028, 63, 32) /dev/sdb5 843 843 1029 191472 6 DOS 16-bit >=32M ****************** /dev/sdb5 is the partition which cam has trouble with. I'm going to be looking now into why "count" would end up zero on a read, and in particular why it would happen every time on the SECOND read of a request for this particular partition. If anyone has any idea or pointers, they would be appreciated. From vandys@puli.cisco.com Thu Jun 29 18:49:56 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00185; Thu, 29 Jun 1995 18:49:52 -0700 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id IAA04907 for ; Sun, 25 Jun 1995 08:51:28 -0700 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id LAA28073; Sun, 25 Jun 1995 11:51:26 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA18403; Sun, 25 Jun 1995 11:51:26 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199506251551.AA18403@world.std.com> Subject: Re: DOS server debugging continues To: vsta@cisco.com Date: Sun, 25 Jun 1995 11:51:26 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1245 [David Jeske writes:] > Actually, after looking through fdl.c from libc and the cam code, I don't > understand how "read()" could ever read more than 4096 bytes. Which it > clearly does when the DOS server is started as a boot server from the > boot.lst. (otherwise it wouldn't be able to read ANY FATs over 4096 bytes) Hi David, (Please note that I don't have access to the full VSTa source tree right now - some of this is from memory.) From the cam side of things, pdisk_rwio() (the disk read/write function) passes off to cam_start_rwio() to process read/write requests. cam_start_rwio() checks the transfer size - if its greater than MAXIO, the transfer size is truncated to MAXIO. When the transfer completes, cam_cntuio() is called. cam_cntuio() checks to see if more data needs to be transfered, and if so, starts another transfer for up to MAXIO bytes. The process is repeated until the original request is satisfied (or until there is an error). You may want to put some print statements in the cam server to see what's going on. One thing to try is putting a print statement after the disk driver calls dpart_get_offset() and see if the block count is what you expect. Hope this helps. Mike Larson From vandys@puli.cisco.com Sat Jul 1 05:23:00 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00074; Sat, 1 Jul 1995 05:22:59 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA15468; Fri, 30 Jun 1995 09:16:20 -0700 Message-Id: <199506301616.JAA15468@puli.cisco.com> To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: RAMDISK filesystem idea/question In-Reply-To: Your message of "Wed, 28 Jun 1995 02:12:53 CDT." <199506280712.CAA28789@terra.igcom.net> Date: Fri, 30 Jun 1995 09:16:20 -0700 From: Andrew Valencia [David Jeske writes:] >is there any reason that a static RAMDISK filesystem could not be >created by making a server which just allowed file-access to a pre-sized >piece of RAM and then running a filesystem on top of that? That would be easy enough to do already. Just: mkfs_vfs -p /tmp/fs.img /vsta/boot/vstafs /tmp/fs.img fs/tmpfs (install contents) umount / mount fs/tmpfs / >Is the compression algorithm used by GNU zip suitable for random access >to the underlying data? I was under the impression that it was VERY >stream oriented. (not that another compression could not be used in the >middle, I was just wondering about GNU zip) No, gzip is not compatible with random access. However, common block sizes (4K and above) allow very good gzip performance when applied against these little chunks. So it's quite possible to gzip each block, and then add something so you can locate the beginning of each block (which, being variably sized due to compression, can not be found at a fixed offset). >I suppose one advantage of enhancing srv/tmpfs instead is that it would >not have to be statically sized. However, this might be a disadvantage in >the case of a boot-floppy. Or, as in my example, you can static size a piece of tmpfs space and run another filesystem. Andy From vandys@puli.cisco.com Sat Jul 1 05:28:05 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00085; Sat, 1 Jul 1995 05:28:04 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id AAA21939 for ; Sat, 1 Jul 1995 00:22:36 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id CAA00662 for vsta@cisco.com; Sat, 1 Jul 1995 02:13:53 -0500 From: "D.Jeske" Message-Id: <199507010713.CAA00662@terra.igcom.net> Subject: "DOS" server question To: vsta@cisco.com Date: Sat, 1 Jul 1995 02:13:52 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1050 Thanks to Mike Larson I found the cam >512MB disk access problem. Now I am getting back to the task at hand which is getting the "dos" server to be a bit more stable and not die with win95 long filenames and such. (and hopefully get win95 longfilename support into it, which looks pretty doable after some sector dumping) However, I have a question. Why are there ASSERT_DEBUG statements in the dos server? I understand that they can be indespensable in debugging situations, however, I would think that it would be unacceptable under almost any circumstances to have a filesystem driver dump because of an unexpected value unless it was impossible to continue without it (i.e. no superblock or something). Especially on a filesystem such as MSDOS FAT which can almost never be considered to be in a truly "clean" state. I'm not trying to criticize at all, I just want to find out if there was a reason it was written that way, something I'm missing, who knows. Or if it was just habit/whatever and there really is no reason for it. From vandys@puli.cisco.com Sun Jul 2 07:35:06 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00077; Sun, 2 Jul 1995 07:35:05 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA02935; Sun, 2 Jul 1995 09:40:54 -0700 Message-Id: <199507021640.JAA02935@puli.cisco.com> To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: "DOS" server question In-Reply-To: Your message of "Sat, 01 Jul 1995 02:13:52 CDT." <199507010713.CAA00662@terra.igcom.net> Date: Sun, 02 Jul 1995 09:40:54 -0700 From: Andrew Valencia ["D.Jeske" writes:] >However, I have a question. Why are there ASSERT_DEBUG statements in the >dos server? I understand that they can be indespensable in debugging >situations, however, I would think that it would be unacceptable under >almost any circumstances to have a filesystem driver dump because of an >unexpected value unless it was impossible to continue without it (i.e. no >superblock or something). Especially on a filesystem such as MSDOS FAT >which can almost never be considered to be in a truly "clean" state. In general, when I write code which handles end-user data, I tend to write the code so that everything grinds to a halt if an unexpected value pops up. My reasoning is that if my code doesn't know what to do with the value, it doesn't know how to continue. If it just forges ahead anyway, you are exposing the user to the very real possibility that they will have a massively corrupt filesystem, rather than a filesystem with a single glitch associated with a single file. During my life as a UNIX kernel weenie, I had to trudge through massively corrupt filesystems time and again on behalf of anxious customers. I'll take my downtime up front, any day. If you want to continue on in the face of system inconsistencies, you need a fault tolerant filesystem. You don't write one of these by accident, and there's no such thing as "sort of" or "mostly" fault tolerant. IMHO. I also don't know what you mean by FAT filesystems never being truly "clean". I routinely will switch back to DOS and run scandisk after a large amount of work under VSTa. Excepting the occasional DOS server bug (:->), the filesystems are clean from top to bottom. Andy From vandys@puli.cisco.com Sun Jul 2 07:40:38 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00109; Sun, 2 Jul 1995 07:40:37 -0700 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id JAA22819 for ; Sat, 1 Jul 1995 09:59:59 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id NAA01726; Sat, 1 Jul 1995 13:01:03 -0400 Date: Sat, 1 Jul 1995 13:01:02 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: How I can get things going? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. I got the vsta. Installed on my dos machine, and vsta boots up. I could not do much expect move arround. First, I need to do is, to setup my environment, what is the recommended setup and how do I get this thing done. Second, I tried to compile a simple hello world, (cc -o test test.c) I got some errors, (it is expected) but then console got hungup. Well I can change to second console, but the first one just stays there. Infact this behaviour is reproduceable. I just used (go.bat) to boot vsta with default boot.lst. Any help is appreciated. Once I get used the environment, I want to read the kernel source, and make some notes, in the following manner bootup move to higger mem loads kernel jump to magic address etc kernel startup init mem etc .. etc I am not sure it is useful to anyone but this exersice will give me better understanding of how vsta is implemented. I would appreciate if someone could give me guidance. Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca From vandys@puli.cisco.com Mon Jul 3 06:00:19 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00064; Mon, 3 Jul 1995 06:00:14 -0700 Received: from sam.comms.unsw.EDU.AU (sam.comms.unsw.EDU.AU [149.171.96.20]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id TAA12010; Sun, 2 Jul 1995 19:50:12 -0700 Received: from syscon.ee.unsw.edu.au (syscon.ee.unsw.EDU.AU [149.171.92.10]) by sam.comms.unsw.EDU.AU (8.6.9/8.6.9.kenso-central) with SMTP id MAA02424; Mon, 3 Jul 1995 12:42:14 +1000 Received: by syscon.ee.unsw.edu.au (4.1/SMI-4.1) id AA05397; Mon, 3 Jul 95 12:51:53 EST From: T.Hesketh@unsw.edu.au (Tim Hesketh) Message-Id: <9507030251.AA05397@ syscon.ee.unsw.edu.au> Subject: New VSTA user To: vandys@cisco.com (Andrew Valencia) Date: Mon, 3 Jul 95 12:51:52 EST Cc: vsta@cisco.com In-Reply-To: <199506301616.JAA15468@puli.cisco.com>; from "Andrew Valencia" at Jun 30, 95 9:16 am X-Mailer: ELM [version 2.3 PL11] Got VSTA - it works - like it. I would like to use it to illustrate various points for teaching purposes. If so, I might be in a position to contribute examples of use (so much better than documentation). Answers to some basic questions would get me off to a flying start. 1. Is the summary of functions in syscall.c a reasonable summary of system calls? Are there other places to look as well? 2. What is the status of fpu support? I have seen comments referring to fpu support in the mail archives, and have found some relevant code, but for example, what happens on task/thread switching? Is this user controllable? What floating point support is offered within programs? I'm experimenting. 3. Are there options for control of task scheduling, and if so, how are they invoked? 4. Can I change machine clock-tick rates? 5. Can you point me at some code that would best illustrate interrupt setting-up/handling? I hope you don't mind some basic questions from time to time. Thanks for the welcoming message when I joined the mailing list. Tim Hesketh From vandys@puli.cisco.com Mon Jul 3 06:08:12 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00075; Mon, 3 Jul 1995 06:08:10 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id UAA05145; Sun, 2 Jul 1995 20:22:26 -0700 Message-Id: <199507030322.UAA05145@puli.cisco.com> To: T.Hesketh@unsw.edu.au (Tim Hesketh) Cc: vsta@cisco.com Subject: Re: New VSTA user In-Reply-To: Your message of "Mon, 03 Jul 1995 12:51:52 EST." <9507030251.AA05397@ syscon.ee.unsw.edu.au> Date: Sun, 02 Jul 1995 20:22:26 -0700 From: Andrew Valencia [T.Hesketh@unsw.EDU.AU (Tim Hesketh) writes:] >1. Is the summary of functions in syscall.c a reasonable summary of system > calls? Are there other places to look as well? Aside from the exhaustive list of syscalls, you could also look at doc/man/2 for documentation on the messaging system calls. >2. What is the status of fpu support? I have seen comments referring to > fpu support in the mail archives, and have found some relevant code, > but for example, what happens on task/thread switching? Is this user > controllable? What floating point support is offered within programs? I'm > experimenting. We offer access to the 387 FPU in the kernel. The libraries do not support floating point (i.e., printf()) yet. There are some bootstrap issues; I need to coordinate with Dave Hudson to get everything up and running. The kernel does the usual multiprocessor lazy load/strict save of the FPU context. A task just sees that they can use the FPU instructions. See the use of T_FPU in mach/trap.c and kern/sched.c. >3. Are there options for control of task scheduling, and if so, how are they > invoked? See kern/sched.c, especially sched_op(). There's nothing along the lines of an external scheduler. >4. Can I change machine clock-tick rates? Sure. Just change HZ, and everything should follow (delta the hardware's ability to implement what you request--see . >5. Can you point me at some code that would best illustrate interrupt > setting-up/handling? I guess rs232/isr.c (and rs232/main.c to set up interrupt handling) is as good as anything. Also os/mach/isr.c, to see how it's implemented. The Amiga/68030 port has an interesting variation of interrupt handling. It uses a minimal P-code to do the front-line handling of interrupt state (which must be cleared before you can run other user tasks), with the server registering the P-code as a part of connecting with a device's interrupt level. Regards, Andy Valencia From vandys@puli.cisco.com Mon Jul 3 06:14:40 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00086; Mon, 3 Jul 1995 06:14:39 -0700 Received: from apollo.is.co.za (apollo.is.co.za [196.4.160.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id BAA08802 for ; Mon, 3 Jul 1995 01:50:08 -0700 Received: by apollo.is.co.za (8.6.12/SMI-SVR4tmp8) id KAA17319; Mon, 3 Jul 1995 10:51:03 +0200 Date: Mon, 3 Jul 1995 10:51:02 +0200 (GMT) From: Datrix Solutions To: Vanier Kethireddy cc: vsta@cisco.com Subject: Re: How I can get things going? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have started compiling a list of simple questions I would like answered about VSTa. I will be posting this soon. Maybe we can get some FAQ activity going. I know I could read the source to answer all my questions, but I am not a kernel guru (yet :-) Does anyone object to seemingly trivial questions or should there be another forum for this? cheers, Wayne From vandys@puli.cisco.com Tue Jul 4 07:08:16 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00076; Tue, 4 Jul 1995 07:08:15 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id VAA27169; Mon, 3 Jul 1995 21:54:00 -0700 Message-Id: <199507040454.VAA27169@puli.cisco.com> To: Vanier Kethireddy Cc: vsta@cisco.com Subject: Re: Help Creating a user on vsta. In-Reply-To: Your message of "Mon, 03 Jul 1995 21:22:31 EDT." Date: Mon, 03 Jul 1995 21:54:00 -0700 From: Andrew Valencia [Vanier Kethireddy writes:] > Once I log in I can not create any files. Well, typically >if a user is created, we create a dir and change its ownership, >but I didn't do that since there is no chown command. The DOS filesystem, since there's no place to keep owner/protection information, just assumes all files are owned by sys.sys. So make sure your user ID includes sys.sys (1.1), either by adding this ID to the group you log into, or by making your group "root". Regards, Andy From vandys@puli.cisco.com Tue Jul 4 07:14:15 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00090; Tue, 4 Jul 1995 07:14:14 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA10966; Tue, 4 Jul 1995 09:20:26 -0700 Message-Id: <199507041620.JAA10966@puli.cisco.com> To: Datrix Solutions Cc: vsta@cisco.com Subject: Re: A list of questions. In-Reply-To: Your message of "Mon, 03 Jul 1995 22:07:39 +0200." Date: Tue, 04 Jul 1995 09:20:26 -0700 From: Andrew Valencia [Datrix Solutions writes:] >Q How can I kill a process running in the forground (CTRL-C type metaphor)? We need a TTY monitor. This function was to be part of the terminal emulator for the MADO windowing system, which appears to have coasted to a stop. :-( >Q How are the differences between the nl/cr and nl files handled? When > I use vi, I get a lot of ^M's. Must I dtou all the files, or is there > some way to make vi handle these files? VSTa uses the \n convention. For those library routines which understand text in units of lines (gets(), for instance), the library routine tries to handle both conventions. >Q What is the progress with the Boot disk? I have some preliminary code for the MultiBoot standard. If somebody wants to run with it, I'm trying to focus what cycles I have on the /inet server to provide networking. >Q The graphics and windowing system? See MADO, above. >Q When is the next release planed? It was planned for when I got networking running. I've been stuck with management of 7 people for the foreseeable future, which has slowed me down. I *do* have /inet linking, and am currently grappling with how to provide a multiplexed interface to multiple remote clients from a server running against a particular port. Plan 9 solved this by making you use specific routines (listen()/accept()/ etc.), which I'd like to avoid if at all possible. I might break down and require a wstat() to switch between clients, although my ideal is to let an application using only POSIX file handling to server as either a server or client for a TCP port. Andy From vandys@puli.cisco.com Wed Jul 5 06:29:42 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00078; Wed, 5 Jul 1995 06:29:38 -0700 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id SAA15170 for ; Mon, 3 Jul 1995 18:21:34 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id VAA02757; Mon, 3 Jul 1995 21:22:32 -0400 Date: Mon, 3 Jul 1995 21:22:31 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: Help Creating a user on vsta. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I changed my root entry in the passwd file, and everything seems to work alright. So I created a user because, I have bad habit of deleting everything so I want to login as a user instead of root. Once I log in I can not create any files. Well, typically if a user is created, we create a dir and change its ownership, but I didn't do that since there is no chown command. Could somebody suggest me a way to change owner ship of the file. Here is the passwd, group and id file entries, please check and tell me if there is anything wrong with these entries. passwd file root:root:0:0:root:root:/vsta/home/root:root:/vsta/bin/sh vanier:vanier:100:100:vanier:usr.vanier:/vsta/home/vanier:vanier:/vsta/bin/sh group file root:0:sys.sys users:100 ids file sys:1 sys:1 io:2 dos:3 misc:4 bad:2 bad:2 usr:100 vanier:100 Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca From vandys@puli.cisco.com Wed Jul 5 06:26:01 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00072; Wed, 5 Jul 1995 06:23:23 -0700 Received: from apollo.is.co.za (apollo.is.co.za [196.4.160.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id NAA23808 for ; Mon, 3 Jul 1995 13:06:39 -0700 Received: by apollo.is.co.za (8.6.12/SMI-SVR4tmp8) id WAA28866; Mon, 3 Jul 1995 22:07:44 +0200 Date: Mon, 3 Jul 1995 22:07:39 +0200 (GMT) From: Datrix Solutions To: vsta@cisco.com Subject: A list of questions. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I have recently joined the VSTa mailing list. I am a newcomer to the field of operating system level code, and as such, have some questions (rudimentary I assume) about the use of the system. Maybe others have exerienced the same problems - so this can provide some material for the blossoming FAQ (http://www.cen.uiuc.edu/~jeske/VSTa/) : Q Sometimes one is not able to compile your own files and "perm" is displayed. A This is, according to Andy, a bug (maybe with srv/tmpfc/open.c), the workaround is to "umount /tmp". Q How do I generate floating point code? At the moment printf("%f",fl) produces "f" instead of e.g. 1.322123. A The kernel supports fp, but the libs don't yet. Almost there... Q How can I kill a process running in the forground (CTRL-C type metaphor)? Q How are the differences between the nl/cr and nl files handled? When I use vi, I get a lot of ^M's. Must I dtou all the files, or is there some way to make vi handle these files? Q What is the progress with the Boot disk? Q The graphics and windowing system? Q When is the next release planed? Q How many people on the mailing list? Growth rate? cheers, Wayne From vandys@puli.cisco.com Wed Jul 5 06:30:04 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00094; Wed, 5 Jul 1995 06:30:02 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA14546 for ; Mon, 3 Jul 1995 10:34:04 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id MAA03896; Mon, 3 Jul 1995 12:24:39 -0500 From: "D.Jeske" Message-Id: <199507031724.MAA03896@terra.igcom.net> Subject: Re: How I can get things going? To: datrix@is.co.za (Datrix Solutions) Date: Mon, 3 Jul 1995 12:24:39 -0500 (CDT) Cc: vanier@aurora.carleton.ca, vsta@cisco.com In-Reply-To: from "Datrix Solutions" at Jul 3, 95 10:51:02 am X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1224 > I have started compiling a list of simple questions I would like answered > about VSTa. I will be posting this soon. Maybe we can get some FAQ > activity going. I know I could read the source to answer all my > questions, but I am not a kernel guru (yet :-) Sounds good, make sure you check the existing FAQ (as small as it is) and the WWW available documentation if can and have not seen it already. Both are available via "http://www.cen.uiuc.edu/~jeske/VSTa/". If you can't web-browse, I can email them to you directly. I also suggest reading through the rather expansive email/HyperMail archive available at: http://ftoomsh.socs.uts.EDU.AU/mlists/vsta It contains a huge amount of usefull information. > Does anyone object to seemingly trivial questions or should there be > another forum for this? Many seemingly trivial questions actually spark very interesting discussions. In fact, most of the start of the "Documentation" has come from the mailing list archives in the form of answers to "seemingly trivial questions". However, again, take the time to read through the mailing list archive if you can, it contains information about both VSTa itself, and many of the reasons it is the way it is. From vandys@puli.cisco.com Wed Jul 5 06:30:01 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00091; Wed, 5 Jul 1995 06:29:59 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA13917 for ; Mon, 3 Jul 1995 10:26:53 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id MAA03514 for vsta@cisco.com; Mon, 3 Jul 1995 12:17:51 -0500 From: "D.Jeske" Message-Id: <199507031717.MAA03514@terra.igcom.net> Subject: Re: How I can get things going? To: vanier@aurora.carleton.ca (Vanier Kethireddy) Date: Mon, 3 Jul 1995 02:56:02 -0500 (CDT) In-Reply-To: from "Vanier Kethireddy" at Jul 1, 95 01:01:02 pm X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1828 Sender: jeske@igcom.net > First, I need to do is, to setup my environment, what is the > recommended setup and how do I get this thing done. I just use the "vandys" account. I don't know what other people do, but I don't do much "setup". I just toss it in and go to work. > Second, I tried to compile a simple hello world, (cc -o test test.c) > I got some errors, (it is expected) but then console got hungup. Well > I can change to second console, but the first one just stays there. Infact > this behaviour is reproduceable. I just used (go.bat) to boot vsta with > default boot.lst. Any help is appreciated. I don't know what is with the console hanging, you can try just doing "ps" in the second console and then killing whatever is stuck. However, you'll have better luck compiling stuff if you look at the makefile in /vsta/bin.src/test. For some reason the "compile and link" cc dosn't work exactly correctly. > Once I get used the environment, I want to read the kernel source, > and make some notes, in the following manner > bootup > move to higger mem > loads kernel > jump to magic address etc > kernel startup > init mem etc .. etc > > I am not sure it is useful to anyone but this exersice will > give me better understanding of how vsta is implemented. I would appreciate > if someone could give me guidance. You can find a starting point for this information (and other things) on the VSTa home page that I setup. The boot process description is at: http://www.cen.uiuc.edu/~jeske/VSTa/Docs/BootProcess.html As you might have guessed, the "home" for the VSTa page is: http://www.cen.uiuc.edu/~jeske/VSTa/ Definetly take a look through that stuff if you have not done so. If you produce anything that is NOT in the documentation page, please email it to me and I'll polish/HTMLify and include it. From vandys@puli.cisco.com Sun Jul 9 13:12:03 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00064; Sun, 9 Jul 1995 13:11:57 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id WAA08184 for ; Sat, 8 Jul 1995 22:22:59 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id AAA25576 for vsta@cisco.com; Sun, 9 Jul 1995 00:13:28 -0500 From: "D.Jeske" Message-Id: <199507090513.AAA25576@terra.igcom.net> Subject: "terminal" problem with vi from vstafs root To: vsta@cisco.com Date: Sun, 9 Jul 1995 00:13:28 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 504 I would swear that I read a message from someone else who had this exact same problem before. However, I can't find it. I just got a vstafs root partition up and running. I can login and compile and everything is fine... except that when I run vi, it complains about "nansi" is not a valid terminal type. However, when I change the TERM variable to "ansi" (by changing the global TERM in /env) it then says "ansi" is not a valid terminal type even though it is... What is the deal here? Dave From vandys@puli.cisco.com Sun Jul 9 14:12:23 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00222; Sun, 9 Jul 1995 14:12:22 -0700 Received: from aurora.carleton.ca (vanier@aurora.carleton.ca [134.117.55.74]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id JAA11120 for ; Thu, 6 Jul 1995 09:10:53 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id MAA06785; Thu, 6 Jul 1995 12:11:35 -0400 Date: Thu, 6 Jul 1995 12:11:34 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: Where do I find floppy boot info/package. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I got thing rolling with vsta. Now I would like to try floppy boot. Could somebody direct me to the floppy boot. info/package. Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca From vandys@puli.cisco.com Sun Jul 9 14:13:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00248; Sun, 9 Jul 1995 14:13:47 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA18830 for ; Thu, 6 Jul 1995 05:01:27 -0700 Received: from punt.demon.co.uk by disperse.demon.co.uk id aa14261; 6 Jul 95 13:00 +0100 Received: from humbug.demon.co.uk by punt.demon.co.uk id aa08950; 6 Jul 95 13:00 +0100 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0sTlqV-00038CC; Thu, 6 Jul 95 08:59 BST Message-Id: From: Dave Hudson Subject: Re: A list of questions. To: datrix@is.co.za Date: Thu, 6 Jul 1995 08:59:38 +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: 1611 Hi, Datrix Solutions wrote: > > Q How do I generate floating point code? At the moment printf("%f",fl) > produces "f" instead of e.g. 1.322123. > A The kernel supports fp, but the libs don't yet. Almost there... I started coding a maths lib up when I started writing the fp stuff for the kernel, but it's never got much further than that as I've not had the time in the last few months. There are some patches for 1.4 that I sent to Andy a couple of months back that should give much better support for printf including fp. One issue I hit when I did the original fp support was that the VSTa gcc didn't generate some of the fp code correctly so I had to cross compile a new version under Linux which then did work - I haven't tried this under 1.3.3 so this may not be a problem any more. > Q How are the differences between the nl/cr and nl files handled? When > I use vi, I get a lot of ^M's. Must I dtou all the files, or is there > some way to make vi handle these files? When 1.4's available there'll be a port of GNU find that I did a while back - at least this makes things less painful, eg: find -name "*.c" -print | d2utxt \{\} \; > Q What is the progress with the Boot disk? Again I have support for this, but it uses dd to write the raw disk - this is one of the ports I did. > Q The graphics and windowing system? I'm sad to say I've had no time to work on bitblt recently, which is a shame as I had quite a lot of code done (the low level stuff anyway). I think Gavin, much as myself, has been pretty busy at work and not had time to make much progress. Regards, Dave From vandys@puli.cisco.com Sun Jul 9 14:17:08 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00270; Sun, 9 Jul 1995 14:17:07 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA14111; Sun, 9 Jul 1995 16:24:19 -0700 Message-Id: <199507092324.QAA14111@puli.cisco.com> To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: "terminal" problem with vi from vstafs root In-Reply-To: Your message of "Sun, 09 Jul 1995 00:13:28 CDT." <199507090513.AAA25576@terra.igcom.net> Date: Sun, 09 Jul 1995 16:24:19 -0700 From: Andrew Valencia ["D.Jeske" writes:] >I just got a vstafs root partition up and running. I can login and >compile and everything is fine... except that when I run vi, it complains >about "nansi" is not a valid terminal type. However, when I change the >TERM variable to "ansi" (by changing the global TERM in /env) it then >says "ansi" is not a valid terminal type even though it is... Have you tried: echo -n ansi > /env/jeske/TERM to see what happens? Watch out for ^M's at the end of lines. -ltermcap should probably protect itself against this; right now, it uses read() to get the whole database file, which is not a programming interface which maps ^M^J into ^J (this would make it non-binary-clean, which isn't desirable). Andy From vandys@puli.cisco.com Sun Jul 9 14:52:42 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00319; Sun, 9 Jul 1995 14:52:41 -0700 Received: from terra.igcom.net (jeske@[204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id QAA14324; Sun, 9 Jul 1995 16:59:51 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id SAA03490; Sun, 9 Jul 1995 18:50:26 -0500 From: "D.Jeske" Message-Id: <199507092350.SAA03490@terra.igcom.net> Subject: Re: "terminal" problem with vi from vstafs root To: vandys@cisco.com (Andrew Valencia) Date: Sun, 9 Jul 1995 18:50:25 -0500 (CDT) Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199507092324.QAA14111@puli.cisco.com> from "Andrew Valencia" at Jul 9, 95 04:24:19 pm X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1195 > >I just got a vstafs root partition up and running. I can login and > >compile and everything is fine... except that when I run vi, it complains > >about "nansi" is not a valid terminal type. However, when I change the > >TERM variable to "ansi" (by changing the global TERM in /env) it then > >says "ansi" is not a valid terminal type even though it is... > > Have you tried: > > echo -n ansi > /env/jeske/TERM > > to see what happens? I actually did: echo -n ansi > /env/TERM Before doing that it tells me that "nansi" is not found, and then lists a bunch of others that I should use. After doing that it just says: OOPS OOPSterminal entry not found > Watch out for ^M's at the end of lines. -ltermcap should probably protect > itself against this; right now, it uses read() to get the whole database > file, which is not a programming interface which maps ^M^J into ^J (this > would make it non-binary-clean, which isn't desirable). However, I was previously running the same exact termcap off a msdos filesystem with no problems. I just copied everything over and then booted with testsh and changed a bunch of the access modes to let stuff be readable and such. From list-owner-vsta@cisco.com Sat Jul 15 08:42:26 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA00115; Fri, 14 Jul 1995 04:49:49 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id RAA15614 for ; Sun, 9 Jul 1995 17:17:38 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id TAA03868 for vsta@cisco.com; Sun, 9 Jul 1995 19:08:10 -0500 From: "D.Jeske" Message-Id: <199507100008.TAA03868@terra.igcom.net> Subject: More on termcap/terminal problem To: vsta@cisco.com Date: Sun, 9 Jul 1995 19:08:10 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 572 I am even more confused now. I booed vsta back up under my DOS root setup and even if I remove the termcap file, vi will default to "ansi" and start up. When I have the vstafs root up, it just says it can't read the termcap file and then dies. I just tried to move my termcap file back into the lib directory and vstafs died, curious... I was thinking it had to do with permissions, since that is the major difference between vstafs and the msdos setup. Is anyone actually running a system with a vstafs root where the terminal stuff (termcap and such) works? From vandys@puli.cisco.com Mon Jul 24 11:06:25 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00064; Mon, 24 Jul 1995 11:06:24 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA17685; Sat, 22 Jul 1995 08:53:11 -0700 Message-Id: <199507221553.IAA17685@puli.cisco.com> To: rb2@irz301.inf.tu-dresden.de Cc: vsta@cisco.com Subject: Re: new user problems In-Reply-To: Your message of "Thu, 20 Jul 1995 13:47:14 +0200." <199507201147.AA02015@irz403.inf.tu-dresden.de> Date: Sat, 22 Jul 1995 08:53:11 -0700 From: Andrew Valencia [rb2@irz301.inf.tu-dresden.de writes:] >1. Is there a chance to install VSTa on a 386SX with only 2 MB RAM? All my > experiments ended with a hangup resulting from 'freemem = 0'. Even if I > commented out most of the servers in the boot script the first complex > application like gcc or vi crashed VSTa. Your only chance is to enable paging. I've changed the cache code so quite a bit more memory can be reclaimed in the next release. Plan to do kernel debugging if you page heavily! >2. Is there a way to use the Video-BIOS of the graphics card? It would be fine > if I could use at least the standard VGA modi. I want to do simple graphics > in VSTa, if possible. The man who is working on the (MADO?) window system > could probably answer this easily. I don't know about running a BIOS; somebody was playing with mapping a 32-bit BIOS into his process, and getting some reasonable results. If the BIOS is 16-bit, though, you're out of luck. You'd probably need to implement V86 mode, a non-trivial task. Regards, Andy Valencia From vandys@puli.cisco.com Mon Jul 24 11:41:37 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00289; Mon, 24 Jul 1995 11:41:25 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id EAA19062 for ; Thu, 20 Jul 1995 04:47:54 -0700 Received: from irz403.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA17756; Thu, 20 Jul 1995 13:47:32 +0200 Received: by irz403.inf.tu-dresden.de (5.67b+/DEC-Ultrix/4.3) id AA02015; Thu, 20 Jul 1995 13:47:15 +0200 From: rb2@irz301.inf.tu-dresden.de Message-Id: <199507201147.AA02015@irz403.inf.tu-dresden.de> Subject: new user problems To: vsta@cisco.com Date: Thu, 20 Jul 1995 13:47:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 946 Hello, I am relatively new to VSTa. After some inital problems i got things going, and VSTa runs very stable on my private 586/60, 8MB. Plugged into the PC is a DSP card, which I want to control using a VSTa server. Like every VSTa newbie, I have some questions concerning the system. 1. Is there a chance to install VSTa on a 386SX with only 2 MB RAM? All my experiments ended with a hangup resulting from 'freemem = 0'. Even if I commented out most of the servers in the boot script the first complex application like gcc or vi crashed VSTa. 2. Is there a way to use the Video-BIOS of the graphics card? It would be fine if I could use at least the standard VGA modi. I want to do simple graphics in VSTa, if possible. The man who is working on the (MADO?) window system could probably answer this easily. I would be glad, if someone could help me with this problems. Best regards, Robert ---- rb2@irz.inf.tu-dresden.de From vandys@puli.cisco.com Mon Jul 24 11:43:13 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00300; Mon, 24 Jul 1995 11:43:12 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id NAA13918 for ; Mon, 24 Jul 1995 13:53:16 -0700 Message-Id: <199507242053.NAA13918@puli.cisco.com> To: vsta@amri.cisco.com Subject: vstafs as root filesystem Date: Mon, 24 Jul 1995 13:53:16 -0700 From: Andrew Valencia Well... I'm taking three weeks off from work to catch up on my overflowing vacation tally. So--of course--I finally get to spend some time on various mysteries. Mystery #1: what ails VSTa when trying to use a vstafs filesystem as the root? Answer: two things, both related to a filesystem which has real protection. First, I accidentally created all the system files as myself; the system daemons couldn't access them (they're capable of root, but this capability is disabled until explicitly activated). Myster #2: Even with that, /vsta/lib/termcap doesn't appear to be honored. Answer: The BSD code in libtermcap.a does an open(..., 0). 0 maps into neither ACC_READ nor ACC_WRITE on the server side. vstafs simply was refusing to permit reads when such access was not requested. I patched vstafs to map m_arg == 0 into m_arg = ACC_READ. I also fixed the code in the termcap library, but termcap isn't in libc, so it's not a shared library, and I'd have to go relink all the apps. With that, vstafs is now my root partition, and seems to be working OK. "vi" is still behaving funny, though. More hunting TBD. Andy From vandys@puli.cisco.com Wed Aug 2 13:30:08 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00105; Wed, 2 Aug 1995 13:30:06 -0700 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id NAA25722 for ; Wed, 2 Aug 1995 13:11:25 -0700 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA15975; Wed, 2 Aug 95 22:11:19 +0200 Received: by freebsd.first.gmd.de (WAA15456); Wed, 2 Aug 1995 22:10:31 +0200 From: Gerd Truschinski Message-Id: <199508022010.WAA15456@freebsd.first.gmd.de> Subject: XXXXX To: vsta@cisco.com Date: Wed, 2 Aug 1995 22:10:31 +0159 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 858 This is now the third message to the VSTa mailing list. Is this list (grabbing the dictionary: verstorben=deceased .. yup) Is this list deceased? It semms so. Earth to Earth, Bits to Bits..... Or is there a delay between subscribtion to the list and sending mails to other people on the list? To say it loud: I need information about MADO, CAM and the new fast floppy boot. But now we have the second of August. Are you all gone on vacation. Then I have to say : Sorry! BTW: I just have read the papers about MGR. Why don't we use it? Ok, it's not on the VSTa way. But it is running. People use it. /gT/ P.S. send me a note if you could read my posting. -- Gerd Truschinski | Yes, this is the sort of scenario I gt@freebsd.first.gmd.de | think up to amuse myself in the evenings. emma@cs.tu-berlin.de | -- with confirmation from Larisa From vandys@puli.cisco.com Wed Aug 2 13:36:08 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00116; Wed, 2 Aug 1995 13:36:07 -0700 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id KAA13487 for ; Wed, 2 Aug 1995 10:50:21 -0700 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA15398; Wed, 2 Aug 95 19:50:16 +0200 Received: by freebsd.first.gmd.de (TAA14215); Wed, 2 Aug 1995 19:49:31 +0200 From: Gerd Truschinski Message-Id: <199508021749.TAA14215@freebsd.first.gmd.de> Subject: CAM and SEAgate To: vsta@cisco.com Date: Wed, 2 Aug 1995 19:49:31 +0159 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 777 Hi there, I asked this question 3 days ago, but got no response. Is there anyone out there who has ported another driver to CAM. I.e. I want to go with the FreeBSD-Elischer driver for the SEAgate ST01/02 boards. If there is no one, I will continue my porting efforts. Therefor I also need the fast floppy boot server. The one from Feb.04 is tooo slooow. It took me 5 attempts to recognice that my VSTa machine ( a 16MHz, 386SX ) was still running.... The FTP server mentioned in an older mail is now down. And it seems that that software wasn't included in VSTa1.3.3. /gT/ -- Gerd Truschinski | Yes, this is the sort of scenario I gt@freebsd.first.gmd.de | think up to amuse myself in the evenings. emma@cs.tu-berlin.de | -- with confirmation from Larisa From vandys@puli.cisco.com Wed Aug 2 13:46:43 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00131; Wed, 2 Aug 1995 13:46:42 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA10132; Wed, 2 Aug 1995 15:58:30 -0700 Message-Id: <199508022258.PAA10132@puli.cisco.com> To: Gerd Truschinski Cc: vsta@cisco.com Subject: Re: CAM and SEAgate In-Reply-To: Your message of "Wed, 02 Aug 1995 19:49:31 +0159." <199508021749.TAA14215@freebsd.first.gmd.de> Date: Wed, 02 Aug 1995 15:58:29 -0700 From: Andrew Valencia [Gerd Truschinski writes:] >I asked this question 3 days ago, but got no response. My mail machine's power supply fan died, so I only turn it on once a day. I was out of town the last two days, so.... >Is there anyone out there who has ported another driver >to CAM. I.e. I want to go with the FreeBSD-Elischer driver >for the SEAgate ST01/02 boards. >If there is no one, I will continue my porting efforts. The Amiga port used the driver for that controller. I'm not aware of another port for a PC SCSI controller. >Therefor I also need the fast floppy boot server. The one >from Feb.04 is tooo slooow. It took me 5 attempts to recognice >that my VSTa machine ( a 16MHz, 386SX ) was still running.... I heard from Dave Hudson recently, perhaps he'll respond. >The FTP server mentioned in an older mail is now down. And it seems >that that software wasn't included in VSTa1.3.3. Which one is that? ftp.cisco.com:vandys/vsta should work, and ftp.cygnus.com pub/embedded/vsta appears healthy as well. Andy From vandys@puli.cisco.com Wed Aug 2 13:51:52 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00142; Wed, 2 Aug 1995 13:51:51 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA10350; Wed, 2 Aug 1995 16:03:39 -0700 Message-Id: <199508022303.QAA10350@puli.cisco.com> To: Gerd Truschinski Cc: vsta@cisco.com Subject: Re: XXXXX In-Reply-To: Your message of "Wed, 02 Aug 1995 22:10:31 +0159." <199508022010.WAA15456@freebsd.first.gmd.de> Date: Wed, 02 Aug 1995 16:03:38 -0700 From: Andrew Valencia [Gerd Truschinski writes:] >This is now the third message to the VSTa mailing list. >Is this list (grabbing the dictionary: verstorben=deceased .. yup) >Is this list deceased? It semms so. Earth to Earth, Bits to Bits..... No; I just explained the latency aspect of the list. >BTW: I just have read the papers about MGR. Why don't we use it? >Ok, it's not on the VSTa way. But it is running. People use it. I have been scoping the source. It's unfortunate that it's not organized with a cleanly distinct directory holding OS-specific interfaces; perhaps another for device-specific drivers. Still, a port did not look difficult. FWIW, I've been busy with vstafs, and the /inet server. I'll have a source drop towards the end of my vacation (1.5 weeks). Andy From vandys@puli.cisco.com Thu Aug 3 05:17:10 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00064; Thu, 3 Aug 1995 05:17:08 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id DAA29974 for ; Thu, 3 Aug 1995 03:06:43 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa22961; 3 Aug 95 9:39 +0100 Received: from humbug.demon.co.uk by post.demon.co.uk id aa05940; 3 Aug 95 9:36 +0100 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0sdvNJ-0003EMC; Thu, 3 Aug 95 09:11 BST Date: Thu, 3 Aug 1995 09:11:29 +0100 (BST) From: Dave Hudson To: Gerd Truschinski cc: vsta@cisco.com Subject: Re: XXXXX In-Reply-To: <199508022010.WAA15456@freebsd.first.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, On Wed, 2 Aug 1995, Gerd Truschinski wrote: > To say it loud: I need information about MADO, CAM and the new fast > floppy boot. Floppy boot is possible with a 1.3.3 release - I think David Jeske's got my old code working again. For now I'm still working with an interim pre-1.4 system which probably doesn't even look much like 1.4 will (Andy has a habit of making my patches much cleaner and suitable for public consumption :-)) > But now we have the second of August. Are you all gone on vacation. > Then I have to say : Sorry! Yep - have been for 2 weeks now (and the weather's been far too nice to sit around inside) :-) > BTW: I just have read the papers about MGR. Why don't we use it? > Ok, it's not on the VSTa way. But it is running. People use it. The work I've done so far on bitblt was based on some of the ideas from XFree86 2.1 (although I can handle more than 8bpp, like 3.x can). To be honest though I've been meaning to rewrite much of this to get chipset specific servers (for efficiency). I can't remember whether I mentioned this on the mailing list or just in private email though. Regards, Dave From vandys@puli.cisco.com Thu Aug 3 05:18:36 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00067; Thu, 3 Aug 1995 05:18:34 -0700 Received: from europe.std.com (europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id FAA03286 for ; Thu, 3 Aug 1995 05:23:57 -0700 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id IAA11575; Thu, 3 Aug 1995 08:20:11 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA19479; Thu, 3 Aug 1995 08:23:54 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199508031223.AA19479@world.std.com> Subject: Re: CAM and SEAgate To: vsta@cisco.com Date: Thu, 3 Aug 1995 08:23:54 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1492 Hi, [Gerd Truschinski writes:] > Is there anyone out there who has ported another driver > to CAM. I.e. I want to go with the FreeBSD-Elischer driver > for the SEAgate ST01/02 boards. > If there is no one, I will continue my porting efforts. and [Andrew Valencia writes:] > The Amiga port used the driver for that controller. I'm not aware of > another port for a PC SCSI controller. I am about to port the linux fdomain.c (Future Domain) driver. I would have started sooner, but I decided to do some work on the CDFS server first (see below). As for porting SIM level drivers, you should check out the SCSI driver writers guide first. The URL for it is: "http://www.cen.uiuc.edu/~jeske/VSTa/Docs/vcam.html" (this is part of the VSTa hierarchy ("http://www.cen.uiuc.edu/~jeske/VSTa/") maintained by David Jeske). From an implementation standpoint, it would be nice if, as you port the driver, you could come up with librarys and include files that would be useful to future porters of FreeBSD drivers. For example, I plan to write some interface/translation routines to help convert between CAM style calls and linux SCSI driver entry points. It may also be necessary write some include files that define non-VSTa/CAM data structures. CDFS status: I'm working on adding RRIP (Rock Ridge Interchange Protocol) to the VSTa CDFS server. This will allow cdfs to handle long file names, POSIX-like file attributes, etc. Mike Larson From vandys@puli.cisco.com Thu Aug 3 12:39:17 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00075; Thu, 3 Aug 1995 12:38:30 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id MAA03238 for ; Thu, 3 Aug 1995 12:29:28 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id OAA12058; Thu, 3 Aug 1995 14:22:20 -0500 From: David Jeske Message-Id: <199508031922.OAA12058@terra.igcom.net> Subject: Re: XXXXX To: dave@humbug.demon.co.uk (Dave Hudson) Date: Thu, 3 Aug 1995 14:22:19 -0500 (CDT) Cc: gt@freebsd.first.gmd.de, vsta@cisco.com In-Reply-To: from "Dave Hudson" at Aug 3, 95 09:11:29 am X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 595 > Floppy boot is possible with a 1.3.3 release - I think David Jeske's got > my old code working again. Yes, I have his old code working. I also managed to actually get it to copy a vstafs root off the rest of the floppy and then mount it off the tmpfs, however vstafs has problems running off tmpfs files (the one I have does anyhow) so as of yet I've been unable to do anything usefull with it. > > BTW: I just have read the papers about MGR. Why don't we use it? > > Ok, it's not on the VSTa way. But it is running. People use it. Perhaps I'm living under a rock, but what is MGR? From vandys@puli.cisco.com Thu Aug 3 12:35:37 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00072; Thu, 3 Aug 1995 12:35:36 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id OAA29932; Thu, 3 Aug 1995 14:47:34 -0700 Message-Id: <199508032147.OAA29932@puli.cisco.com> To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: XXXXX In-Reply-To: Your message of "Thu, 03 Aug 1995 14:22:19 CDT." <199508031922.OAA12058@terra.igcom.net> Date: Thu, 03 Aug 1995 14:47:33 -0700 From: Andrew Valencia [David Jeske writes:] >> > BTW: I just have read the papers about MGR. Why don't we use it? >> > Ok, it's not on the VSTa way. But it is running. People use it. >Perhaps I'm living under a rock, but what is MGR? It's a simple windowing system which has been ported to various platforms, including PC's and Sun's. The functions of both the window manager and terminal are built into the basic windowing system. Escape sequences are used to communicate window operations, and the source I have does not support color. Still, it's fairly tidy, and quite small--a good fit for the philosophy of VSTa. Andy From vandys@puli.cisco.com Fri Aug 4 07:07:26 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00080; Fri, 4 Aug 1995 07:07:24 -0700 Received: from red-branch.MIT.EDU (jsmith@RED-BRANCH.MIT.EDU [18.70.0.203]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id HAA16316 for ; Fri, 4 Aug 1995 07:16:30 -0700 From: jsmith@red-branch.MIT.EDU Received: (from jsmith@localhost) by red-branch.MIT.EDU (8.6.12/8.6.12) id KAA19161; Fri, 4 Aug 1995 10:16:52 -0400 Date: Fri, 4 Aug 1995 10:16:52 -0400 (EDT) To: Vsta Mailing List Subject: TCP Suite, and other networking. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have been looking at VSTa for awhile now, and have finally decided to start working on a few projects. The first of these being, utilizing VSTa as an embedded OS for routers. This of course requires a rather full Networking suite. My question is anyone already working on this? Or has just basic TCP stuff been worked on? If there are people working on this I would be more than happy to coordinate things with them so that we do not duplicate any efforts. Stuff that I will be needing to support in the near future are the following: RIP, RIPII, SNMP, SNMPII, SLIP, CSLIP, PPP, HDLC, and a couple of protocols for ISDN work. The second major project would be porting VSTa to some Alpha based computers that I have designed and built. Current OS work on them includes Linux, NetBSD, FreeBSD, and HURD. Some of the machine models are indeed SMP machines. Has someone been working on multiprocessing primitives, or is that still at the stage of just 'holding' places for them in the code? Again I would prefer to coordinate things so that duplicated work is not done. Somewhere down the line when I have the time, I am also interested in experimenting with VSTa as the core kernel for a MPP system. I also want to work with VSTa in a distributed environment. The work cluster that I have in mind for this experimentation is a smallish (prototype) model of an Alpha based MPP system, coupled via ATM to 4-8 Alpha workstations (of various configurations). I am interested to see how VSTa can be made to behave in this sort of an environment. Again, this is something for a bit further down the road. Hopefully some people will be interested in helping out with such a project, and when things are at that stage I can and will definately have the machines available for use via internet. All of this listed hardware is stuff of my own desgin. I have all the documentation that one would need, from design documentation clear up to overview documents on how various sections of the machines work. The MPP system would be started as a 64 PE (Processing elements) machine with two IOPs (Input Output Processors) and one Supervisor element. Storage is connected Via Storage Modules, which are seperate cabinets connected via fiber based HIPPI channels, that support a RAID type array of disks with a log based filesystem, CDROMs, and backup storage. The MPP has access to PCI card cages, and several PCI buses, as well as the option to utilize VME card cages/buses. Storage units can be accessed directly from the PEs or through the IOPs. The interconnection structure of the communications network is flexible (4 links per PE to other PEs, 1 link per PE to the I/O Mesh, 1 link per PE to the Graphics Mesh). I think VSTa could be used, hopefully without a large amount of modification, as something akin to a lightweight kernel on the PEs. Front ends for the MPP will be variously configured Alpha machines. This MPP is a pet project of mine, that I have been assisted with by a few interested individuals, I would love to see an interesting OS running on it that didn't take up 1-2 Megabytes/ Per cpu per PE just to run (Each PE has two cpu's). For those interested in looking at the Alpha machines (not the MPP), please feel free to look at: http://red-branch.mit.edu/~jsmith/alpha/alpha.html Sorry for rambling on so long. Thanks for your time, Jonathan From vandys@puli.cisco.com Fri Aug 4 07:15:17 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00112; Fri, 4 Aug 1995 07:15:16 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA03115; Fri, 4 Aug 1995 09:27:23 -0700 Message-Id: <199508041627.JAA03115@puli.cisco.com> To: jsmith@red-branch.MIT.EDU Cc: Vsta Mailing List Subject: Re: TCP Suite, and other networking. In-Reply-To: Your message of "Fri, 04 Aug 1995 10:16:52 EDT." Date: Fri, 04 Aug 1995 09:27:23 -0700 From: Andrew Valencia [jsmith@red-branch.MIT.EDU writes:] >The first of these being, utilizing VSTa as an embedded OS for routers. >This of course requires a rather full Networking suite. My question is >anyone already working on this? Or has just basic TCP stuff been worked >on? All we have is KA9Q. I have a /inet server mostly married with it, which permits programs to open, say, /inet/tcp/25, and take the SMTP port for the box. >If there are people working on this I would be more than happy to >coordinate things with them so that we do not duplicate any efforts. >Stuff that I will be needing to support in the near future are the >following: RIP, RIPII, SNMP, SNMPII, SLIP, CSLIP, PPP, HDLC, and a couple >of protocols for ISDN work. I don't know if the version of KA9Q I ported is up to the task. In any case, it should provide some shortcuts for the port of some other networking code. >The second major project would be porting VSTa to some Alpha based >computers that I have designed and built. Current OS work on them >includes Linux, NetBSD, FreeBSD, and HURD. Some of the machine models >are indeed SMP machines. Has someone been working on multiprocessing >primitives, or is that still at the stage of just 'holding' places for >them in the code? Again I would prefer to coordinate things so that >duplicated work is not done. I have a dream that my annual bonus (coming out in a couple months) will be big enough that I can "sneak in" the purchase of a dual processor Pentium system. Until then, the only sanity checks which have been applied to the SMP support is kernel preemption, and my experience doing SMP at Sequent. >Somewhere down the line when I have the time, I am also interested in >experimenting with VSTa as the core kernel for a MPP system. I also want >to work with VSTa in a distributed environment. This was the primary motivation behind getting /inet up and running. I wanted to map VSTa messages over a box-to-box protocol, and thus be able to access an arbitrary VSTa server from any other box. This would provide the starting point for clustering. Regards, Andy From vandys@puli.cisco.com Fri Aug 4 07:21:26 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00149; Fri, 4 Aug 1995 07:21:24 -0700 Received: from darya.dev.infomkt.ibm.com (netb80.bah.com [156.80.2.80]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id UAA12609 for ; Thu, 3 Aug 1995 20:30:04 -0700 Received: (from quanstro@localhost) by darya.dev.infomkt.ibm.com (8.6.11/8.6.9) id XAA03668 for vsta@cisco.com; Thu, 3 Aug 1995 23:22:25 -0400 Date: Thu, 3 Aug 1995 23:22:25 -0400 From: goon Message-Id: <199508040322.XAA03668@darya.dev.infomkt.ibm.com> Subject: mgr & escape code-based data Apparently-To: vsta@cisco.com >...Escape sequences are used to communicate window operations hmm... doesn't that result in quoting nightmares, especially when using character sets that aren't ascii. (or when you're trying to enter an escape character of some sort.) (not that i've ever used it; just asking why it uses in-band rather than out-of-band control.) From vandys@puli.cisco.com Sat Aug 5 11:42:48 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00118; Sat, 5 Aug 1995 11:42:46 -0700 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id NAA00256 for ; Sun, 30 Jul 1995 13:16:18 -0700 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA17060; Sun, 30 Jul 95 22:16:15 +0200 Received: by freebsd.first.gmd.de (WAA29430); Sun, 30 Jul 1995 22:15:36 +0200 From: Gerd Truschinski Message-Id: <199507302015.WAA29430@freebsd.first.gmd.de> Subject: Is there a SEAGATE scsi driver To: vsta@cisco.com Date: Sun, 30 Jul 1995 22:15:36 +0159 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 708 Hi there, I have a running VSTa for 6 hours now :-) Some of the network connections to the US seems to be malade. It took about 3 days to get the 3MByte :-( And now the question: Is there a SEAGATE ST02 sim driver for VSTa. If not, is there someone working on a port of the FreeBSD driver? The last mails I read are from march.95. So, is the window server running now? And the last question: Am I able to run VSTa on a 386SX without coprocessor? /gT/ BTW: Thank you Andrew for the fast subscribtion. -- Gerd Truschinski | Yes, this is the sort of scenario I gt@freebsd.first.gmd.de | think up to amuse myself in the evenings. emma@cs.tu-berlin.de | -- with confirmation from Larisa From vandys@puli.cisco.com Sat Aug 5 11:50:25 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA00129; Sat, 5 Aug 1995 11:50:23 -0700 Received: from red-branch.MIT.EDU (jsmith@RED-BRANCH.MIT.EDU [18.70.0.203]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA03811; Fri, 4 Aug 1995 10:49:52 -0700 From: jsmith@red-branch.MIT.EDU Received: (from jsmith@localhost) by red-branch.MIT.EDU (8.6.12/8.6.12) id NAA19968; Fri, 4 Aug 1995 13:50:11 -0400 Date: Fri, 4 Aug 1995 13:50:10 -0400 (EDT) To: Andrew Valencia cc: Vsta Mailing List Subject: Re: TCP Suite, and other networking. In-Reply-To: <199508041627.JAA03115@puli.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Aug 1995, Andrew Valencia wrote: > [jsmith@red-branch.MIT.EDU writes:] > > All we have is KA9Q. I have a /inet server mostly married with it, which > permits programs to open, say, /inet/tcp/25, and take the SMTP port for the > box. > > >If there are people working on this I would be more than happy to > >coordinate things with them so that we do not duplicate any efforts. > >Stuff that I will be needing to support in the near future are the > >following: RIP, RIPII, SNMP, SNMPII, SLIP, CSLIP, PPP, HDLC, and a couple > >of protocols for ISDN work. > > I don't know if the version of KA9Q I ported is up to the task. In any > case, it should provide some shortcuts for the port of some other networking > code. Okay, it looks like I will be building most of it up then. Code examples are always nice however, which is what I suspect most of KA9Q will turn into. As long as I'm not stepping on any toes. Let me take a look at a few things then I'll post a summary of how I think I should organize things for people's comments. > >The second major project would be porting VSTa to some Alpha based > >computers that I have designed and built. Current OS work on them > >includes Linux, NetBSD, FreeBSD, and HURD. Some of the machine models > >are indeed SMP machines. Has someone been working on multiprocessing > >primitives, or is that still at the stage of just 'holding' places for > >them in the code? Again I would prefer to coordinate things so that > >duplicated work is not done. > > I have a dream that my annual bonus (coming out in a couple months) will be > big enough that I can "sneak in" the purchase of a dual processor Pentium > system. Until then, the only sanity checks which have been applied to the > SMP support is kernel preemption, and my experience doing SMP at Sequent. Any of the available low-end motherboards out these days actually any good? Not too far make most of them were pretty 'iffy'. There are some nice chipsets for building SMP server type machines out that I have worked with, perhaps putting together a 2 or 4 cpu pentium system would be something a few people would be interested in? Motherboard construction costs would be the biggest cost factor, if there are only a few people interested, if there are say 10-20 the motherboard fab costs should be about 150-220$ apiece. The chipset I have in mind runs in around 230$ per cpu for everything, that plus cpu costs and memory. The cpu's hook together, with or without a L2 cache, via a high speed systems bus, ~560Megabytes/sec. Put a PCI bus on that and a PCI to ISA bridge chip and you would have a reasonable system, for not too much money or work. > >Somewhere down the line when I have the time, I am also interested in > >experimenting with VSTa as the core kernel for a MPP system. I also want > >to work with VSTa in a distributed environment. > > This was the primary motivation behind getting /inet up and running. I > wanted to map VSTa messages over a box-to-box protocol, and thus be able to > access an arbitrary VSTa server from any other box. This would provide the > starting point for clustering. > > Regards, > Andy > Well hopefully in a few months, I can have the working test-bed of machines that I mentioned earlier up and on the internet for people to look and see, and help work on if they so desire, or even play. At this time it stands at this: 4 Io Station machines (lower end Alpha single cpu models) 2 Europa Station machines (mid end single cpu) 4 Adrastea Stations (high end single cpu) 1 Europa Station (mid-high end dual cpu alpha, server class) 1 Callisto Station (High end 4 cpu alpha, server class) 1 Metis 64 PE MPP system (for starters it will only have 32 PEs) The Io stations will be used as front ends for the Metis system, with the rest of the machines hooked into an ATM network(locally) for a compute cluster. All of these machines can be used for experimenting with VSTa or what not if needed, I have others that are currently being used for Linux, NetBSD, FreeBSD development. The reason for the few months wait is both network connections and for the next run of system boards. At first the internet link will probably only be 128Kbs, I am working on alternatives. I may also be able to work out an arrangement with the Local university to hook my network up to thiers (for the development stuff) in exchange for them using some of the machines for thier own stuff. Hopefully I can get interested people to help out some. I have no problems with partitioning the netowork either, into pieces, some for VSTa, some of other things. Perhaps some for distributed some for regular work. Jonathan From vandys@puli.cisco.com Sun Aug 6 06:11:15 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00093; Sun, 6 Aug 1995 06:11:13 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id TAA19316; Sat, 5 Aug 1995 19:33:47 -0700 Message-Id: <199508060233.TAA19316@puli.cisco.com> To: Gerd Truschinski Cc: vsta@cisco.com Subject: Re: Direction of VSTa In-Reply-To: Your message of "Sun, 06 Aug 1995 04:19:20 +0159." <199508060219.EAA12946@freebsd.first.gmd.de> Date: Sat, 05 Aug 1995 19:33:47 -0700 From: Andrew Valencia [Gerd Truschinski writes:] >what is the further way of VSTa? The one True Way. :-) >Will there be more man pages? Yes (he said hopefully). >Will there be Runes? Um, er, maybe. There's been a lot of discussion on this front. I, personally, am focusing a couple levels down, on base OS technology. Others have various levels of motivation on this front. >Will there be a system in the file system? I.e. source and binary >in different directories? Done. 1.4 will have this (next week). >Will there be support for other CPUs than the Intel family? Done. 68030 Amiga will be in the next source tree. >Will there be the sources for the man system? The man command is in src/bin/cmds/man.c. The source for the man pages themselves is in doc/man/*. The source is in roff format; a nroff subset which processes very quickly. >Ok, I have a MIPS system I want to port VSTa to. Someone has started >it, that seems to be not the problem. But there is NO documentation >that could help me. Am I right? The source is copiously commented. The break-out for the 68030 port should help your effort quite a bit. There is no "port manual", as such. >For now I have a FreeBSD system I edit my sources on. This is because >I need a machine I could see both, the VSTa and the FreeBSD sources on. >Then I boot VSTa on that machine (486 with an Adaptec SCSI board). >Compile my sources to a new server; CAM is his name. And after that I >boot DOS to copy the server to a boot disk for my 386SX VSTA machine. >Then I do some testing. >You see, a lot of OS is needed to do my work. Well, if you really want to go this path, you might hack up a driver for FreeBSD which would function like VSTa's boot.exe for DOS. >So, what I need is a VSTa machine with a graphic front end and enough >driver to support MY hardware. I.e I also have a wd8003 board. Not >a NE2000 clone. I scrape by with the multi-screens. >But I don't even know how to fork a process. There is no description.... Be prepared for a surprise: fork() (:->) In general, you should try the POSIX interface; this is what we followed by default. The man system doesn't document all this because I figured that most folks know the interface already, so I just wrote up man pages for the underlying messaging engine, which is unique to VSTa. >What I like? This 60xxx message while the system is booting. This seems >to tell me something about the memory requirements during the boot >process. FreeBSD systems seems to be some magnitudes bigger. Thanks; the joys of microkernels. >But what about Plan9. Am I right that they have a Berkeley style >copyright? And that they have more documentation? I haven't seen the Plan9 restrictions. I'd be surprised if AT&T was as generous as the Berkeley distribution, but you never know. Regards, Andy Valencia From vandys@puli.cisco.com Sun Aug 6 06:11:45 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00098; Sun, 6 Aug 1995 06:11:44 -0700 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id TAA00286 for ; Sat, 5 Aug 1995 19:19:21 -0700 Received: from freebsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA05300; Sun, 6 Aug 95 04:19:18 +0200 Received: by freebsd.first.gmd.de (EAA12946); Sun, 6 Aug 1995 04:19:20 +0200 From: Gerd Truschinski Message-Id: <199508060219.EAA12946@freebsd.first.gmd.de> Subject: Direction of VSTa To: vsta@cisco.com Date: Sun, 6 Aug 1995 04:19:20 +0159 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1636 Hi there, what is the further way of VSTa? Will there be more man pages? Will there be Runes? Will there be a system in the file system? I.e. source and binary in different directories? Will there be support for other CPUs than the Intel family? Will there be the sources for the man system? Ok, I have a MIPS system I want to port VSTa to. Someone has started it, that seems to be not the problem. But there is NO documentation that could help me. Am I right? For now I have a FreeBSD system I edit my sources on. This is because I need a machine I could see both, the VSTa and the FreeBSD sources on. Then I boot VSTa on that machine (486 with an Adaptec SCSI board). Compile my sources to a new server; CAM is his name. And after that I boot DOS to copy the server to a boot disk for my 386SX VSTA machine. Then I do some testing. You see, a lot of OS is needed to do my work. So, what I need is a VSTa machine with a graphic front end and enough driver to support MY hardware. I.e I also have a wd8003 board. Not a NE2000 clone. But I don't even know how to fork a process. There is no description.... What I like? This 60xxx message while the system is booting. This seems to tell me something about the memory requirements during the boot process. FreeBSD systems seems to be some magnitudes bigger. But what about Plan9. Am I right that they have a Berkeley style copyright? And that they have more documentation? /gT/ -- Gerd Truschinski | Yes, this is the sort of scenario I gt@freebsd.first.gmd.de | think up to amuse myself in the evenings. emma@cs.tu-berlin.de | -- with confirmation from Larisa From vandys@puli.cisco.com Sun Aug 6 06:11:50 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00115; Sun, 6 Aug 1995 06:11:48 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id RAA28221 for ; Sat, 5 Aug 1995 17:10:36 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa04344; 6 Aug 95 1:08 +0100 Received: from humbug.demon.co.uk by post.demon.co.uk id aa17974; 6 Aug 95 1:05 +0100 Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3) id m0sesSL-0003EQC; Sun, 6 Aug 95 00:16 BST Date: Sun, 6 Aug 1995 00:16:37 +0100 (BST) From: Dave Hudson To: Gerd Truschinski cc: vsta@cisco.com Subject: Re: Is there a SEAGATE scsi driver In-Reply-To: <199507302015.WAA29430@freebsd.first.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 30 Jul 1995, Gerd Truschinski wrote: > Hi there, > > I have a running VSTa for 6 hours now :-) > Some of the network connections to the US seems to > be malade. It took about 3 days to get the 3MByte :-( Hmm - I've often found this. I found ftp.ibp.fr is a pretty good European mirror though. > And now the question: > > The last mails I read are from march.95. So, is the window server > running now? No - unfortunately neither Gavin or I have had much time to work on any of the graphics code. The last major chunk of VSTa coding I did were the performance reworks and some libc stuff. > And the last question: Am I able to run VSTa on a 386SX without > coprocessor? Should work fine - the kernel can handle an NPX if one is present, but doesn't worry if one isn't Regards, Dave From vandys@puli.cisco.com Mon Aug 7 07:45:24 1995 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00064; Mon, 7 Aug 1995 07:45:22 -0700 Received: from europe.std.com (europe.std.com [192.74.137.10]) by beasley.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id JAA25516 for ; Mon, 7 Aug 1995 09:14:43 -0700 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id MAA26904; Mon, 7 Aug 1995 12:13:27 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA06289; Mon, 7 Aug 1995 12:13:26 -0400 From: larz@world.std.com (Mike A Larson) Message-Id: <199508071613.AA06289@world.std.com> Subject: Re: Direction of VSTa To: vsta@cisco.com Date: Mon, 7 Aug 1995 12:13:26 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1130 Hi, [Gerd Truschinski writes:] >Ok, I have a MIPS system I want to port VSTa to. Someone has started >it, that seems to be not the problem. But there is NO documentation >that could help me. Am I right? I think that someone is Christopher Fraser. He wrote a nice document called "On Porting VSTa to the R3000". >For now I have a FreeBSD system I edit my sources on. This is because >I need a machine I could see both, the VSTa and the FreeBSD sources on. >Then I boot VSTa on that machine (486 with an Adaptec SCSI board). >Compile my sources to a new server; CAM is his name. And after that I >boot DOS to copy the server to a boot disk for my 386SX VSTA machine. >Then I do some testing. >You see, a lot of OS is needed to do my work. Why not copy the FreeBSD sources that you need to the VSTa partition on your 486. Then do the editing and compiling on VSTa running on the 486. This would save one step, at least. Or, if you have a CDROM drive on the 486 and if you have the FreeBSD sources on CDROM, you could mount the CDROM from VSTa and have access to both that way. Mike Larson From vandys@puli.cisco.com Mon Aug 7 07:52:36 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00075; Mon, 7 Aug 1995 07:52:34 -0700 Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id AAA23107; Mon, 7 Aug 1995 00:59:50 -0700 Received: from amdahl.amdahl.com by orpheus.amdahl.com with smtp (Smail3.1.29.1 #1) id m0sfN68-0001q2C; Mon, 7 Aug 95 00:59 PDT Received: from amdahl.uts.amdahl.com by amdahl.amdahl.com with smtp (Smail3.1.28.1 #49) id m0sfN4l-0000yOC; Mon, 7 Aug 95 00:58 PDT Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.16) id ; Mon, 7 Aug 95 01:00 PDT Message-Id: From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: Direction of VSTa To: vandys@cisco.com (Andrew Valencia) Date: Mon, 7 Aug 1995 01:00:48 -0700 (PDT) Cc: gt@freebsd.first.gmd.de, vsta@cisco.com In-Reply-To: <199508060233.TAA19316@puli.cisco.com> from "Andrew Valencia" at Aug 5, 95 07:33:47 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 891 > >But what about Plan9. Am I right that they have a Berkeley style > >copyright? And that they have more documentation? > > I haven't seen the Plan9 restrictions. I'd be surprised if AT&T was as > generous as the Berkeley distribution, but you never know. Definitely not - the distribution terms for Plan9 are that you can only exchange source with someone who has a valid plan9 license - so you can't even post source diffs to the 9fans mailing list, let alone the promised comp.os.plan9 newsgroup. More info in: http://plan9.att.com/plan9 That, plus the $350 charge for plan9 on CD-ROM, have made me a bit wary. Alistair PS. Nice work on 1.4, Andy. -- Alistair G. Crooks (agc@uts.amdahl.com) +44 125 234 6377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation] From vandys@puli.cisco.com Mon Aug 7 07:53:58 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA00085; Mon, 7 Aug 1995 07:53:57 -0700 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id UAA07744; Sun, 6 Aug 1995 20:50:44 -0700 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id XAA25902; Sun, 6 Aug 1995 23:53:46 -0400 Date: Sun, 6 Aug 1995 23:53:46 -0400 From: Gavin Nicol Message-Id: <199508070353.XAA25902@ebt-inc.ebt.com> To: vandys@cisco.com CC: gt@freebsd.first.gmd.de, vsta@cisco.com In-reply-to: <199508060233.TAA19316@puli.cisco.com> (message from Andrew Valencia on Sat, 05 Aug 1995 19:33:47 -0700) Subject: Re: Direction of VSTa >>Will there be Runes? > >Um, er, maybe. There's been a lot of discussion on this front. I, >personally, am focusing a couple levels down, on base OS technology. >Others have various levels of motivation on this front. There will be Runes at some point. From vandys@puli.cisco.com Mon Aug 7 08:19:53 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00121; Mon, 7 Aug 1995 08:19:52 -0700 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id LAA24141; Sun, 6 Aug 1995 11:23:42 -0700 Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id LAA12454; Sun, 6 Aug 1995 11:22:58 -0700 Received: by tweedledumb.cygnus.com (4.1/4.7) id AA05607; Sun, 6 Aug 95 14:22:56 EDT Received: by perdiem.cygnus.com (5.67/4.7) id AA00295; Sun, 6 Aug 95 14:21:01 -0400 Date: Sun, 6 Aug 95 14:21:01 -0400 From: "Mark W. Eichin" Message-Id: <9508061821.AA00295@perdiem.cygnus.com> To: vandys@cisco.com Cc: gt@freebsd.first.gmd.de, vsta@cisco.com In-Reply-To: <199508060233.TAA19316@puli.cisco.com> (message from Andrew Valencia on Sat, 05 Aug 1995 19:33:47 -0700) Subject: Re: Direction of VSTa Plan 9 is intended to be available to Universities and that's it; they seem to want to get the benefits of what happenned with BSD but none of the drawbacks (what drawbacks? well, AT&T lost "control" of it...) The Plan 9 license is unusual enough that many people have punted on it just to avoid having to ask a lawyer about it - sticking to *real* BSD licensed code or GPL code because at least they know where they stand. To look for yourself, check http://www.att.com/press/0795/950718.bla.html http://plan9.att.com/plan9/index.html and in particular, the shrink-wrap license agreement: http://plan9.att.com/plan9/shrink.html The killer excerpt seems to be "Without executing an applicable sublicense with AT&T, no part of the SOFTWARE may be published, sold, or offered for sale, nor may any part of the SOFTWARE be made available on a computer network external to you or your organization, nor may commercial services utilizing this SOFTWARE be sold or offered for sale." which appears to prevent mirror sites, much less other distributions. There is an exception that lets you transfer modified copies to other LICENSEES of the software for internal research and education purposes. _Mark_ Cygnus Support, East Coast From vandys@puli.cisco.com Mon Aug 7 08:18:24 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00107; Mon, 7 Aug 1995 08:18:18 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA23313 for ; Sun, 6 Aug 1995 10:34:11 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.10) id MAA29675; Sun, 6 Aug 1995 12:28:49 -0500 From: David Jeske Message-Id: <199508061728.MAA29675@terra.igcom.net> Subject: Re: Direction of VSTa To: gt@freebsd.first.gmd.de (Gerd Truschinski) Date: Sun, 6 Aug 1995 12:28:49 -0500 (CDT) Cc: vsta@cisco.com In-Reply-To: <199508060219.EAA12946@freebsd.first.gmd.de> from "Gerd Truschinski" at Aug 6, 95 04:19:20 am X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2481 > what is the further way of VSTa? To boldly go where no OS has gone before :) > Will there be more man pages? > Will there be Runes? > Will there be a system in the file system? I.e. source and binary > in different directories? > Will there be support for other CPUs than the Intel family? > Will there be the sources for the man system? I would assume "conditionally yes" on all counts. It's conditional on someone actually going out and doing it. I've worked on collecting all of the "docs/information" I can, and I've put it on a web page at "http://www.cen.uiuc.edu/~jeske/VSTa/". There is already support for the Amiga (030 I believe) which is at least semi-working. > Ok, I have a MIPS system I want to port VSTa to. Someone has started > it, that seems to be not the problem. But there is NO documentation > that could help me. Am I right? I think the guy who was doing the MIPS port disappeared. The CODE for VSTa is incredibly well documented and orginized. For someone capable enough to do a port to another processor, this should be a great help. > For now I have a FreeBSD system I edit my sources on. This is because > I need a machine I could see both, the VSTa and the FreeBSD sources on. > Then I boot VSTa on that machine (486 with an Adaptec SCSI board). > Compile my sources to a new server; CAM is his name. And after that I > boot DOS to copy the server to a boot disk for my 386SX VSTA machine. > Then I do some testing. > You see, a lot of OS is needed to do my work. > So, what I need is a VSTa machine with a graphic front end and enough > driver to support MY hardware. I.e I also have a wd8003 board. Not > a NE2000 clone. You could just setup a cross compile environment on FreeBSD. I believe this should be possible, I know alot of people cross compile from Linux. > But I don't even know how to fork a process. There is no description.... Look through the libc code or the include files. > But what about Plan9. Am I right that they have a Berkeley style > copyright? And that they have more documentation? Plan9 has a different focus than VSTa, and is commercially produced by AT&T Bell Labs. Plan9 is a complete OS which you can get and run (and they just made some easy educational license or something). VSTa is a OS which is a work in progress. If your looking to get an OS up and running without writing code, go for Plan9, if your looking to do OS work and help by contributing to a free project, work on VSTa. From vandys@puli.cisco.com Mon Aug 7 08:24:14 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00172; Mon, 7 Aug 1995 08:24:13 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id KAA23898 for ; Mon, 7 Aug 1995 10:36:52 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.12) id MAA22584 for vsta@cisco.com; Mon, 7 Aug 1995 12:32:21 -0500 From: David Jeske Message-Id: <199508071732.MAA22584@terra.igcom.net> Subject: Re: Direction of VSTa To: vsta@cisco.com Date: Mon, 7 Aug 1995 12:32:20 -0500 (CDT) In-Reply-To: <199508070353.XAA25902@ebt-inc.ebt.com> from "Gavin Nicol" at Aug 6, 95 11:53:46 pm X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 336 > >Um, er, maybe. There's been a lot of discussion on this front. I, > >personally, am focusing a couple levels down, on base OS technology. > >Others have various levels of motivation on this front. > > There will be Runes at some point. Wow, not another thing that I've never heard of... First MGR, now Runes, what is "Runes"? From vandys@puli.cisco.com Tue Aug 8 05:43:16 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00101; Tue, 8 Aug 1995 05:43:15 -0700 Received: from aurora.carleton.ca (vanier@aurora.aurora.carleton.ca [134.117.69.13]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id XAA15301 for ; Mon, 7 Aug 1995 23:08:56 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id CAA21633; Tue, 8 Aug 1995 02:08:58 -0400 Date: Tue, 8 Aug 1995 02:08:58 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: Can someone explain please. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, What is the reason for defining system calls (other than message passing primitives) at the kernel level, say for example fork or tfork. Why can't a process manager handle this job. I would appriciate if some one can explain to me w.r.t boundry line between microkernel and the process manager i.e what exactly they are defined to do under vsta. At this point I do not see any difference between micorkernel and the process manager. Am I thinking in the proper direction? If not can someone guide me please, I might be overlooking other issues. Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca From vandys@puli.cisco.com Tue Aug 8 05:41:23 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00064; Tue, 8 Aug 1995 05:41:22 -0700 Received: from aurora.carleton.ca (vanier@aurora.aurora.carleton.ca [134.117.69.13]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id WAA13692 for ; Mon, 7 Aug 1995 22:13:41 -0700 Received: (from vanier@localhost) by aurora.carleton.ca (8.6.12/8.6.9) id BAA21434; Tue, 8 Aug 1995 01:13:43 -0400 Date: Tue, 8 Aug 1995 01:13:43 -0400 (EDT) From: Vanier Kethireddy To: vsta@cisco.com Subject: where is ver 1.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I have noticed, that people were refering to vsta 1.4. Could somebody tell me where it is located. Currently I am reading kernel source. It is well documented. Thanks to Andy. Regards Vanier ------------------------------------------------------------------------ Vanier, Kethireddy email: vanier@aurora.carleton.ca From vandys@puli.cisco.com Tue Aug 8 05:46:07 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00104; Tue, 8 Aug 1995 05:46:06 -0700 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id HAA19491 for ; Tue, 8 Aug 1995 07:31:05 -0700 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id KAA25901; Tue, 8 Aug 1995 10:33:36 -0400 Date: Tue, 8 Aug 1995 10:33:36 -0400 From: Gavin Nicol Message-Id: <199508081433.KAA25901@ebt-inc.ebt.com> To: jeske@uiuc.edu CC: vsta@cisco.com In-reply-to: <199508071732.MAA22584@terra.igcom.net> (message from David Jeske on Mon, 7 Aug 1995 12:32:20 -0500 (CDT)) Subject: Re: Direction of VSTa >Wow, not another thing that I've never heard of... First MGR, now Runes, >what is "Runes"? 16 bit characters. In fact runes is a bad name, but I have definite designs of having VSTa support ISO 10646 at some point (or rather Unicode). I don't know if anyone has been following html-wg, but the internationisation of the WWW has been sucking up a lot of my spare time for the last year... Look at BSD 4.4 for an idea, but BSD 4.4 is also flawed... From vandys@puli.cisco.com Tue Aug 8 05:54:43 1995 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00131; Tue, 8 Aug 1995 05:54:42 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA22070; Tue, 8 Aug 1995 08:07:33 -0700 Message-Id: <199508081507.IAA22070@puli.cisco.com> To: Vanier Kethireddy Cc: vsta@cisco.com Subject: Re: Can someone explain please. In-Reply-To: Your message of "Tue, 08 Aug 1995 02:08:58 EDT." Date: Tue, 08 Aug 1995 08:07:33 -0700 From: Andrew Valencia [Vanier Kethireddy writes:] > What is the reason for defining system calls (other than message >passing primitives) at the kernel level, say for example fork or tfork. >Why can't a process manager handle this job. For that matter, why have messaging kernel calls when you can have a message manager? What I found, first in reading the available literature on microkernels, and then in writing one, was that the goal of a microkernel is NOT to see how much you can do outside of the kernel. Rather, the goal is to have the microkernel offer a nucleus of services, such that the vast majority of system enhancements you will make afterwards can be done outside of the kernel. Thus, the activity of defining kernel services was to ask "where does this lead?". Not "is there any possible way I could do this outside the kernel?". For instance, an external process manager *could* be accomplished. However, you need to examine what it bought you (its failure still kills your system, probably), what it cost you (performance issues), and whether in balance it was worth breaking it out from the kernel. > I would appriciate if some one can explain to me w.r.t boundry >line between microkernel and the process manager i.e what exactly they >are defined to do under vsta. At this point I do not see any difference >between micorkernel and the process manager. Right. I put processes, memory, and messaging in the kernel. Other very worthy operating systems (QNX, in particular) have put the process management outside. There are no "right" answers, just a continuum of possible design choices. > Am I thinking in the proper direction? If not can someone guide me >please, I might be overlooking other issues. While reading the process handling code, you might want to consider the aspects of symmetric multiprocessor handling, as well as preemption. How would these work outside the kernel? Pay particular attention to latency and scalability. Regards, Andy From vandys@puli.cisco.com Wed Aug 9 12:23:06 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00109; Wed, 9 Aug 1995 12:23:04 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id OAA03067 for ; Wed, 9 Aug 1995 14:36:07 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.12) id QAA17639 for vsta@cisco.com; Wed, 9 Aug 1995 16:30:45 -0500 From: David Jeske Message-Id: <199508092130.QAA17639@terra.igcom.net> Subject: Ideas Summary Preface To: vsta@cisco.com Date: Wed, 9 Aug 1995 16:30:44 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 696 Dave Hudson and I have been involved in a fairly extensive discussion regarding many different issues in VSTa (and similar OSs). Since we think we've come up with several good ideas, I have summarized these discussions and their major impact as it relates to VSTa. The major Topics are as follows, I have split these up into three separate posints to the mailing list to make it easier to discus and digest them. Email # 1 - Server Startup Syncronization 1 2 - Multiple Data Stream 2 3 - TTY Handling 2 4 - Security IDs 3 5 - Misc Ideas 3 From vandys@puli.cisco.com Wed Aug 9 12:23:20 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00114; Wed, 9 Aug 1995 12:23:18 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id OAA03081 for ; Wed, 9 Aug 1995 14:36:20 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.12) id QAA17676 for vsta@cisco.com; Wed, 9 Aug 1995 16:31:36 -0500 From: David Jeske Message-Id: <199508092131.QAA17676@terra.igcom.net> Subject: Ideas Summary (3/3) To: vsta@cisco.com Date: Wed, 9 Aug 1995 16:31:36 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 4647 This is a summary of ideas from a email discussion between Dave Hudson and myself. (Part 3/3) This contains two major topics: 4 - Security IDs 5 - Misc Ideas [4 - Security IDs] Objective: - We want the fine-grained hierarchial security of VSTa, but we also want good user-definible group capabilities. (i.e. something better than letting users hold 6 ids which are still sysadmin created) Main Ideas: - Make each process have only *ONE* security id (their active ID) - Each process will also have a UID will will be their primary security id (i.e. the one they start with). It will, however, have nothing to do with "security". - Try and make id forging automatic for users (for if it's not automatic, they probably won't use it) - setuid should no longer be necessary, a correct client/server design, with a server started with the correct permission is the more secure way - Allow an id to have a list of "equivilant ids" which should act AS that id. These lists will be dealt with and checked by an ID server. Security ID specifics: - Process specifics - a process has a "UID" and a "security id" - in a "user" oriented example: WHen a user logs in, his UID and security id will be the same. (usr.dave for example). When he forges to "usr.dave.bin", his UID will remain "usr.dave" for identification purposes. Once a process forges lower, there is no way to go back, and since one can't hold more than one ID (even inactive), it truly is a ONE WAY street. - ID Server - after a match of a processes security ID to the resouce ID fails the ID server will be asked to do a check of alias lists. - because the aliasing is strictly a "resource ID->real ID" equivilancy mapping, there is NO need to be able to give OTHER users ids. All the information about which other ids can access a particular id domain is stored INSIDE that id domain. (i.e. easier to make secure) - effectively most of the security code is moved out of kernel-space and into server-space. - "Equiviland id alias lists" - These "equivilant id" alias lists could have a "access mode mask" which says which access modes people in the list are CAPABLE of getting. This mask would be combined with the access mode of the resource they access to determine their access mode for the resource. - if the equivilant id alias list has CHMOD access in the "access mode mask" then users in the list will be capable of administering the id domain in the id server. - The id server will allow appropriate people to administer the name<->id mappings and equivilancy id lists for an id domain. (either by the CHMOD condition above, or the REAL holder of the id) - If a resource has an id "usr.joe.group.1" and a process has id "usr.dave", which is being checked for access, EACH level of "usr.joe.group.1" will be check for an alias list, and each such list will be checked for "usr.dave". The process will be granted the access modes associated with the SHORTEST alias match of "usr.joe.group.1" (if any). [5 - Misc Ideas (Summary)] These two ideas sort of look at the same issue. What to do with common code between servers which one dosn't want "duplicated" and "compiled in" to the servers. (Ex. TTY code, partition code, whatever) - Boot time shared libs - Dave Hudson feels this is not very difficult, and thus a definite option. It would also allow better performance than the relay() option for most (all?) cases. However, there are some drawbacks to having something be a shared lib instead of a server. - relay() style message passing - This entails allowing a server to get the message arguments without the data to check and see if it actually cares about the data before it's mapped into it's space. It should then be able to pass the entire message on, including data, to another server. Many "in-line" servers could be handled this way. Security Related: - It would be nice to have some mechanism for determining if a given message connection is "secure" from end to end. Since "everything" can never be secure, one good way to keep a system as secure as possible is to allow servers/applications to know whether connections are secure or not and act appropriately. After all, if the sysadmin chooses to allow dangerous transactions over a non-secure connection, at least it's his choice. From vandys@puli.cisco.com Wed Aug 9 12:22:59 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00105; Wed, 9 Aug 1995 12:22:58 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id OAA03060 for ; Wed, 9 Aug 1995 14:36:01 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.12) id QAA17647 for vsta@cisco.com; Wed, 9 Aug 1995 16:31:03 -0500 From: David Jeske Message-Id: <199508092131.QAA17647@terra.igcom.net> Subject: Ideas Summary (1/3) To: vsta@cisco.com Date: Wed, 9 Aug 1995 16:31:02 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1861 This is a summary of ideas from a email discussion between Dave Hudson and myself. (Part 1/3) [1 - Server Startup Synchronization] I've been working on a boot/root floppy startup based on Dave Hudson's VSTa floppy boot stuff, and I have an interesting problem. What I am doing is copying a image off the disk onto tmpfs and then starting vstafs on the image which is on the tmpfs. However, vstafs will try to startup it's filesystem on the tmpfs file as soon as the file exists, and it fails, because there is not enough file there. I made a workaround by just making a custom vstafs which just goes to sleep for a long enough time to get the whole image loaded. A better way to synchronize dependent servers like this is really necessary. Dave and I came upon two ideas. I suppose they could be more of "short term" and "long term" ideas instead of conflicting. 1) Put in exclusive file access, this way vstafs would have to wait until the file was ready in order to open it and start the filesystem on it. This still complicates the NEXT stage of the process though, becuase init is going to try and mount "fs/root" right away whether vstafs is ready or not. (and it'll only wait so long, thus it'll require another special case) 2) Create a semaphore server where different servers could wait on resource semaphores. Resources are essentially in one of three categories "non-existant" (and thus not-ready), "existant but not ready", and "ready". The most important case is the "non-existant" case, because you don't know how long, or even if, a resource will become available if it's non-existant. Especially in the boot process, it will be usefull to allow a set of resource semaphores to be "pre-created" so that servers waiting for them will know that they will eventually come online, and will never quit trying until they do. From vandys@puli.cisco.com Wed Aug 9 12:23:07 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00110; Wed, 9 Aug 1995 12:23:04 -0700 Received: from terra.igcom.net (jeske@terra.igcom.net [204.251.176.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id OAA03066 for ; Wed, 9 Aug 1995 14:36:06 -0700 Received: (from jeske@localhost) by terra.igcom.net (8.6.12/8.6.12) id QAA17658 for vsta@cisco.com; Wed, 9 Aug 1995 16:31:21 -0500 From: David Jeske Message-Id: <199508092131.QAA17658@terra.igcom.net> Subject: Ideas Summary (2/3) To: vsta@cisco.com Date: Wed, 9 Aug 1995 16:31:21 -0500 (CDT) X-Url: Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 6040 This is a summary of ideas from a email discussion between Dave Hudson and myself. (Part 2/3) This contains two major topics: 2 - Multiple Data Stream 3 - TTY Handling [2 - Multiple Data Stream] Multiple Data Stream Uses/Goals: - Use it to send signal changes, and other non "main-stream" oriented information through the stream. (i.e. DCD changes or whatnot) - To send application specific information down the server/client chain in the "background". For example, caller id information from a callerid modem which you are receiving a call for. - Instead of the UNIXish use of the tty to just "spit" text data to a user, use another data-stream as a "back channel" to send this "out of band data" down to the user. As a default, the user-level library code would just take the text and spit it to the user, and the effect would be the same as on UNIX. However, given a program which wanted to do something sane, the data is now in a discrete chunk which can be cleanly dealt with. - As a specific example. Talk requests. Instead of a talk request being spit right at the user and then the user having to fix the screen and then shell to respond to the talk request. A background program could look for talk requests and if one happened, it could pop up a dialog asking if you wanted to respond requiring only a "y" or an "n" to either enter the talk converstaion or to dismiss the dialog and return the screen to normal. For those who would find that intrusive, a single character could be placed in the corner of the screen to signal the talk request. The possibilities are limitless, and all of them can be done without having to modify the installed "talkd" which the sysadmin is running. Multiple Data Stream Specifics: - The stream "backchannels" will be hidden from POSIX by the userlevel libraries. [3 - TTY Handling] Main Ideas: - POSIX is way over the top TTY-wise - Use a separate tty-server for performing tty level support, however don't require clients to go through it. For example, SLIP/PPP/mouse drivers would just talk directly to the serial port. This provides both the isolation and flexibility of having the tty code in another server, AND the speed of not having to go through another server when you don't need it. - Integrating virtual terminals into the tty server would be a big plus. TTY Server Specifics: - Base Functionality: - Map control signal changes to VSTa Signals - Selectable input modes (caniocal/raw) - Special Character Processing (i.e. interrupt/kill/suspend) - Usage Specifics: - The best idea we had as far as allowing the tty server to be "configured" to run on specific devices is this: Just allow the tty server to be given namer paths over which it should create a tty service. (for example, "cons", or "serial") The tty server will register itself as "tty". By opening tty and walking down one will be able to see a "miror" of what is in the paths which the TTY server is serving. For example, given namer paths: serial/com/01, serial/com/02, cons/01, cons/02, if the tty server was started up as "ttyserv serial cons", then there would also be "tty:serial/com/01", "tty:serial/com/02", "tty:cons/01", "tty:cons/02". (or perhaps that could be "tty/serial/com/01") However, none of the connections would actually be OPEN. That is to say that the tty server would not open a connection to "serial/com/01" until one opened "tty:serial/com/01". In addition any devices which are added to the serial pathspace in the namer would automatically show up under the serial path in the tty server, because the TTY server just reads the "serial" directory when someone asks for a file list in "tty:serial". - A mechanism for adding namer paths to be mirrored by the tty server would be necessary also. - Another possible idea to replace the above idea is possibly some kind of "filter server" system, where there is a standard way to open a namer path THROUGH an existing filter server. - Telephony Layer - perhaps as part of the TTY server, or perhaps as just a completely separate layer. A Telephony Layer, now becoming common in many OSs, is a good idea. This layer allows a device specific driver deal with the DEVICE attached to a specific port. For example, a "modem/fax/voicemail" modem would be handled by it's own Telephony driver so it could actually accept all kinds of incoming calls properly. - We didn't spend much time talking about this. The only idea mentioned were basically to just "let a server do it" which could be done with now with no work (except to write the server). Perhaps there are better ideas. - Virtual Terminal handling - The logical location for such handling would likely be the TTY server. Since non-tty devices don't have any concept of a terminal to virtualize. - Associate a "virtual screen" with every process which has a controlling terminal. Acts of job control are now reduced to connecting that processes virtual screen with the physical screen of the terminal. (i.e. by sending a message to the VT server) - interactive apps are no longer stuck inside the screen group they were created in. Since the VT code will hold ALL the virtual screens for all processes which have screens, one can get the screen of any process for which he has sufficient security privileges. - Screen resizing can be handled at the "virtual screen layer", allowing resizing of the physical screen "on-the-fly" to be much simpler.