From vandys@glare.cisco.com Thu Oct 27 16:53:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00884; Thu, 27 Oct 1994 16:53:30 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id SAA24553 for ; Thu, 27 Oct 1994 18:12:15 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa18704; 27 Oct 94 23:46 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r0dm9-0003MNC; Thu, 27 Oct 94 22:58 GMT Message-Id: From: Dave Hudson Subject: Modified floppy server To: VSTa mailing list Date: Thu, 27 Oct 1994 22:58:29 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1049 Hi All, I've just finished some modifications to the floppy server to make it do look-ahead sector caching on reads (writes still go direct to keep things safe). If anyone's using the current code and wouldn't mind running the new stuff for a while please let me know. Running the following command form: dd if=/dev/fd/fd0 bs=xxxx > /dev/null and timing the results showed the following (on a 1.44 MByte floppy): old (dx-33) new (dx-33) linux-1.1.58 (dx/2-66) bs=512 610 seconds 71 seconds 51 seconds bs=18432 56 seconds 56 seconds 51 seconds I put in the results for my Linux system doing the same test for comparison (my Linux box is a dx/2-66 with 256k cache though whereas my VSTa system is a dx-33 with no L2 cache). Running a boot floppy with the new code seems to have everything running about 200-300% faster under a dos fs. FWIW I believe that the difference between the 71 second and the 56 second results is down to the overhead of an extra 35 requests per track (2880 requests as opposed to just 80). Regards, Dave From vandys@glare.cisco.com Fri Oct 28 17:56:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00134; Fri, 28 Oct 1994 17:56:07 -0700 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA19176 for ; Fri, 28 Oct 1994 19:15:27 -0700 Received: from humbug.demon.co.uk by post.demon.co.uk id aa22970; 28 Oct 94 20:13 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r0xeR-0003MvC; Fri, 28 Oct 94 20:11 GMT Message-Id: From: Dave Hudson Subject: Re: Modified floppy server To: Dave Mason Date: Fri, 28 Oct 1994 20:11:51 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2538 Hi, I've cc'd this to the list in case anyone with more experience of floppies can spot any gaping wholes in my reasoning about performance. Dave Mason wrote: > > > Running a boot floppy with the new code seems to have everything running > > about 200-300% faster under a dos fs. > > Usable! Well it allows me to bring up VSTa and all of my servers in just under 1 minute from a boot floppy :-) (It was about 5 minutes before the new code) > > FWIW I believe that the difference between the 71 second and the 56 second > > results is down to the overhead of an extra 35 requests per track (2880 > > requests as opposed to just 80). Actually I fixed a bug earlier today and the timings are now 76 and 46 respectively. I think some work on the messaging code and context switching will improve this quite a bit. It also suggests that some of the copying from the read-ahead buffer may be quite a bit more expensive than I'd originally realised. > Why not buffer a full track? It's only 18K. You could issue the > first 512 bytes, then 3.5K, then 14K (postponing the 14K read allows > waiting to see if the 3.5 was useful (i.e. did the client ask for more > before the 3.5 was read) to optimize most access patterns). I thought about this (although it would be a more significant rewrite) - in fact I made a comment about track caching in the readme for the 1.3.2 version of fd. The performance issue with floppies is that of missing the next sector - waiting 200 ms for the disk to spin round again is really bad news. If we used segmented buffering of a track (ie 512, 3.5k and then 14k) we'd be in great danger of missing the next sector after each segment and thus waiting 200 ms for the next blocks. One thing I did try and found wasn't useful was reading ahead for whole cylinders (both sides of the media), but the extra code didn't actually give me any benefits in performance (so I took it out - I like to keep things as simple as possible). There are a couple of nice side-effects of the way the read-ahead works. The first is that we're unlikely to want to read data from lower numbered sectors if we make our first request somewhere in the middle of the track so we don't bother to buffer (and thus wait for) data we aren't likely to need. The second is that whatever the client requests gets DMA'd directly into their buffer not DMA'd into a track buffer and then copied - quite a saving on a lot of I/O. > I'm not running vsta yet, but fairly soon, I think. The more the merrier :-) Regards, Dave From vandys@glare.cisco.com Fri Oct 28 23:14:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA00160; Fri, 28 Oct 1994 23:14:54 -0700 Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA25232 for ; Sat, 29 Oct 1994 00:34:17 -0700 Received: from crl5.crl.com by mail.crl.com with SMTP id AA03683 (5.65c/IDA-1.5 for ); Sat, 29 Oct 1994 00:34:01 -0700 Received: by crl5.crl.com id AA27614 (5.65c/IDA-1.5 for vsta@cisco.com); Sat, 29 Oct 1994 00:33:10 -0700 Date: Sat, 29 Oct 1994 00:33:10 -0700 From: Antony Halim Message-Id: <199410290733.AA27614@crl5.crl.com> To: vsta@cisco.com Subject: subscription Please add "Antony Halim" to the vsta mailing list. Thanks From vandys@glare.cisco.com Sun Oct 30 05:40:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00331; Sun, 30 Oct 1994 05:40:30 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA27919 for ; Sun, 30 Oct 1994 06:59:56 -0800 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); Mon, 31 Oct 1994 01:59:50 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA18692; Mon, 31 Oct 94 02:04:04 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA15038; Mon, 31 Oct 1994 02:01:08 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199410301501.AA15038@sour.sw.oz.au> Subject: Hypertext index of vsta mailing list To: vsta@cisco.com Date: Mon, 31 Oct 1994 01:01:08 +1000 (EST) X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au Precedence: special-delivery X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1021 I've made a hypertext index of the VSTa mailing list, available via the WWW at: http://ftoomsh.socs.uts.EDU.AU/mlists/vsta It's mostly built from the VSTa list mail archives at ftp.cisco.com, but I had to collate the last month or so by hand from my and Jeremy's mail archives so there my be a few messages missing from early November (if anything, it's nothing major -- if you do spot something missing, please let me know). It should get updated everytime a new messages arrives. When I get some time I'll build a searchable full text database. Also, if anyone is really keen and wants to do text for a VSTa WWW page I'll happily put it up. PS: would an idex of the shlib mailing list be useful? PPS: Is anyone else working on a R3000 port? I remember some people mentioning it earlier this year. I could really use a VSTa aware boot loader and a keyboard driver ... -- Christopher Fraser ``First time surrealists are often confused by the chrisf@sw.oz.au similarities between fish and telephones.'' From vandys@glare.cisco.com Sun Oct 30 10:23:19 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00359; Sun, 30 Oct 1994 10:23:18 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA09867; Sun, 30 Oct 1994 11:35:20 -0800 Message-Id: <199410301935.LAA09867@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: Query about M_READ In-Reply-To: Your message of "Sun, 30 Oct 1994 04:50:48 -0000." Date: Sun, 30 Oct 1994 11:35:20 -0800 From: Andrew Valencia [Dave Hudson writes:] >Perhaps it's just a bit late in the morning for me, but why do we need >M_READ? Is it a security issue? (I can see that a server would be able to >read data from a client's buffer as well as write it) If M_READ is set, the segments are not sent across to the server. The server has to send back segments, whose contents are copied out to the buffers from the client's msg_send() request. Being a DMA server process merely determines whether, *if* a message does not have M_READ set, whether the segments sent across are attached to the server process read-only or read-write. An optimization for filesystems TBD is to have them realize that they're talking to a DMA-capable block server, and never set M_READ. This avoids the extra copy from server segment to filesystem buffer cache. Better yet, since we have allowed our file descriptor layer to handle unaligned I/O, we could have the file descriptor layer detect this and implement it transparently to users of read()/write(). Andy From vandys@glare.cisco.com Mon Oct 31 06:19:31 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00521; Mon, 31 Oct 1994 06:19:29 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id HAA04279; Mon, 31 Oct 1994 07:38:59 -0800 Message-Id: <199410311538.HAA04279@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Cc: vsta@amri.cisco.com Subject: Re: Physical mappings in VSTa In-Reply-To: Your message of "Mon, 31 Oct 1994 16:16:47 +1100." <199410310516.AA10547@sour.sw.oz.au> Date: Mon, 31 Oct 1994 07:38:59 -0800 From: Andrew Valencia [jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) writes:] >I've managed to get mappings working from BIOS32 ROMs, so I can detect >the bios, call the BIOS32 functions to find the PCI bios, and call that >to find the NCR53c810 chip. I hope to get some real functionality >going in the next few days. Good job! PCI support would be nice, and doing it all from a user-level server is the microkernel way to do it. >I modified the kernel mmap() to allow a user process to do fixed mappings >of physical memory. There seems to be a problem however. For normal >mmaps, the first arg (address) is the address to be mapped to (in the >case of MAP_FIXED or ignored otherwise), and the offset arg is the place >in the object being mapped where the mapping is coming from. Ugh. Poor thinking on my part. >In the case of MAP_PHYS, the address arg is the physical address. >As a quick hack I used offset as the virtual address, but it really >should be the other way around. I could only find a couple of uses >for MAP_PHYS mappings in the console driver, so it wouldn't be hard to >fix at this stage. Also, libc could be modified to pass the address >in both the vaddr and the offset unless in the case of MAP_PHYS, unless >MAP_FIXED is set, on the assumption that MAP_FIXED|MAP_PHYS users >know about the modified kernel. Let's just move the parameter where it belongs and fix the places which use physical mapping. For the base distribution that's the console. I think a couple folks have written code like this, too. This message is your warning! :-) Andy From vandys@glare.cisco.com Tue Nov 1 08:14:16 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00783; Tue, 1 Nov 1994 08:14:14 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA25613 for ; Tue, 1 Nov 1994 09:32:59 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA15591; Tue, 1 Nov 1994 18:31:52 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA23780; Tue, 1 Nov 1994 18:31:46 +0100 Date: Tue, 1 Nov 1994 18:31:46 +0100 From: jw@ibch01.inf.tu-dresden.de (Wittenberger) Message-Id: <9411011731.AA23780@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: no sucess on boot Hello, I can't boot the system. After starting go.bat I get a message that the servers are loaded. Then Launch at .... imidiately after I get boot process 10 died [kernel debugger] pr gives that 10 is testsh (or even init depends on boot.lst). tf calls it a page fault. Because I don't know any help I did a quit. Then I get success messages from the wd server wich found the 2 disks. (1st linux second dos) After that the dos server info's me that the filesystem is established (should be on the 1st partition of the second disk wd1_dos0 as I gave it in boot.lst). Now only cons is constantly ONPROC, seems to be in msg_wait. Any help? /Joerg From vandys@glare.cisco.com Tue Nov 1 09:39:31 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00797; Tue, 1 Nov 1994 09:39:29 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA10231; Tue, 1 Nov 1994 10:59:12 -0800 Message-Id: <199411011859.KAA10231@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jw@ibch01.inf.tu-dresden.de (Wittenberger) Cc: vsta@cisco.com Subject: Re: no sucess on boot In-Reply-To: Your message of "Tue, 01 Nov 1994 18:31:46 +0100." <9411011731.AA23780@ibch01.inf.tu-dresden.de> Date: Tue, 01 Nov 1994 10:59:12 -0800 From: Andrew Valencia [jw@ibch01.inf.tu-dresden.de (Wittenberger) writes:] >boot process 10 died [kernel debugger] >pr gives that 10 is testsh (or even init depends on boot.lst). >tf calls it a page fault. What version of OS are you using? What was the program counter? >Then I get success messages from the wd server wich found the 2 disks. >(1st linux second dos) >After that the dos server info's me that the filesystem is established >(should be on the 1st partition of the second disk wd1_dos0 as I gave >it in boot.lst). Sounds like I/O is healthy... >Now only cons is constantly ONPROC, seems to be in msg_wait. When you type ^Z, cons runs and drops into the kernel debugger. So he's not running all the time, but he's running every time you drop to the debugger. Something pretty fundamental is wrong here. testsh doesn't even require a filesystem. Put init back in and let me know what the PC is; from that I can make a guess. Andy From vandys@glare.cisco.com Tue Nov 1 20:01:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA00867; Tue, 1 Nov 1994 20:01:33 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA23230 for ; Tue, 1 Nov 1994 21:21:15 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Wed, 02 Nov 1994 16:21:10 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA01803; Wed, 2 Nov 94 16:26:41 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA15477; Wed, 2 Nov 1994 16:22:28 +1100 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199411020522.AA15477@sour.sw.oz.au> Subject: Random comments To: vsta@cisco.com (VSTa list) Date: Wed, 2 Nov 1994 16:22:26 +1100 (EST) Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE; Wed, 2 Nov 1994 01:47:58 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10806; 2 Nov 94 9:30 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r2bxN-0003PtC; Wed, 2 Nov 94 09:26 GMT Message-Id: From: Dave Hudson Subject: Re: Random comments To: Jeremy Fitzhardinge Date: Wed, 2 Nov 1994 09:26:13 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1849 Hi, Jeremy Fitzhardinge wrote: > > In the course of doing that, I thnk I found a kernel bug with > executable caching, or perhaps a filesystem bug. For a while I > was being confused because none of my changes were taking place - > I even put a 'printf("FOO!");' at the start of main. Even if I > rm'd the binary and all the .o's, remade and typed "./ls", I got > the old version. A file called "ls~" appeared which I couldn't > delete ("cannot unlink: busy", but if I "mv ls~ .." I could make > a new one which worked. Once I'd finished and copied it into > /vsta/bin, the same thing happened. This was on a dos filesystem. >From discussions I've had with Andy this could be a kernel problem - executables don't get uncached correctly. There's also was a problem with the FID code a couple of months back that I seem to remember was related. I didn't try to create a fix as at the time it triggered a kernel trap and I was more interested in fixing the kernel (Andy did this with his mmap() changes). If memory serves, the problem is that if we change a file's contents we don't change it's FID so the kernel doesn't realise there's any difference. FWIW the "xxx~" files are created by strip, and using cp to copy the new version of the file over the old one still leaves the file with the same FID. > I changed the idle loop to use the "hlt" instruction rather than just > busy-waiting. This keeps CPUs much cooler on fast machines and saves > batteries on my notebook. This is true for most CPUs, but it breaks other systems (they lock up). Linux now defaults to using hlt, but has to provide a boot-time switch to disable it for some systems. I just took a quick look at the Linux kernel and it would appear that the kernel will hang with the message "Checking 'hlt' instruction... " if this doesn't work. Regards, Dave From vandys@glare.cisco.com Wed Nov 2 06:53:56 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00951; Wed, 2 Nov 1994 06:53:54 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA03426; Wed, 2 Nov 1994 08:13:43 -0800 Message-Id: <199411021613.IAA03426@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: VSTa mailing list Subject: Re: Random comments In-Reply-To: Your message of "Wed, 02 Nov 1994 09:26:13 GMT." Date: Wed, 02 Nov 1994 08:13:43 -0800 From: Andrew Valencia [Dave Hudson writes:] >FWIW the "xxx~" files are created by strip, and using cp to copy the new >version of the file over the old one still leaves the file with the same >FID. Dave and I talked about the changes needed to allow uncaching when a file is truncated. It's only tedious, not hard. See the treatment for removal if you want to see what's involved. >This is true for most CPUs, but it breaks other systems (they lock up). >Linux now defaults to using hlt, but has to provide a boot-time switch to >disable it for some systems. I just took a quick look at the Linux kernel >and it would appear that the kernel will hang with the message "Checking >'hlt' instruction... " if this doesn't work. We could leave the default the conservative one, and allow switches to be passed to specify the other. This requires boot.exe hackery, but since we want to increase the buffer size I have to break out Borland C again anyway, so I may as well enhance it to allow some flags to be passed. I think we also want a flag to indicate MGA text for the on-screen kernel debugger. Andy From vandys@glare.cisco.com Thu Nov 3 03:14:45 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA01330; Thu, 3 Nov 1994 03:14:43 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA08538 for ; Thu, 3 Nov 1994 04:34:33 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 03 Nov 1994 23:34:29 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA11633; Thu, 3 Nov 94 23:40:38 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA11140; Thu, 3 Nov 1994 23:35:49 +1100 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199411031235.AA11140@sour.sw.oz.au> Subject: ls patches To: vsta@cisco.com (VSTa list) Date: Thu, 3 Nov 1994 23:35:48 +1100 (EST) Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE #include #include +#include +#include #include static int ndir; /* # dirs being displayed */ @@ -16,6 +18,13 @@ static int lflag = 0; /* -l flag */ +static int sort(const void *v1, const void *v2) +{ + const char *s1 = *(const char **)v1; + const char *s2 = *(const char **)v2; + return strcmp(s1, s2); +} + /* * prcols() * Print array of strings in columnar fashion @@ -36,6 +45,7 @@ } } + qsort((void *)v, nelem, sizeof(char *), sort); /* * Calculate how many columns that makes, and how many * entries will end up in each column. @@ -269,12 +279,33 @@ struct dirent *de; char **v = 0; int nelem; + struct stat st; - /* - * Prefix with name of dir if multiples - */ - if (ndir > 1) { - printf("%s:\n", path); + if (stat(path, &st)) { + perror("stat failed"); + return; + } + if (!S_ISDIR(st.st_mode)) { + if (lflag) { + struct dirent de; + + de.d_namlen = strlen(path); + strcpy(de.d_name, path); + ls_l(&de); + } else { + char *v[2]; + v[0] = path; + v[1] = 0; + prcols(v); + } + return; + } else { + /* + * Prefix with name of dir if multiples + */ + if (ndir > 1) { + printf("%s:\n", path); + } } /* From vandys@glare.cisco.com Sat Nov 5 01:46:02 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA00356; Sat, 5 Nov 1994 01:45:58 -0800 Received: from math.tau.ac.il (taurus.math.tau.ac.il [132.67.64.4]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA21415 for ; Sat, 5 Nov 1994 02:06:28 -0800 From: yogo@math.tau.ac.il Received: from libra.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-930921) id AA01408; Sat, 5 Nov 94 12:06:21 +0200 Received: by libra.math.tau.ac.il (4.1/math.sub-st921020) id AA14362; Sat, 5 Nov 94 12:06:19+020 Message-Id: <9411051006.AA14362@libra.math.tau.ac.il> Subject: VSTa boot To: vsta@cisco.com Date: Sat, 5 Nov 1994 12:06:19 +0200 (GMT+0200) X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 965 I got VSTa up and running on its own 10Mb DOS partition; I really don't like it this way, booting into dos in order to get VSTa. Also, I can't boot directly from its own fs. I saw somewhere in the digest files someone is working on an ext2fs (linux) server, and on booting code which doesn't need dos. I wonder what is the status of these. Booting up seems quite simple, assuming vstafs leaves the first sector available as a boot sector. Current boot.exe jobs should be divided: one tool for parsing boot.lst, checking what files are to be loaded, and creating list of physical disk blocks for each file. This list is patched on top of a boot sector loader, which simply reads blocks of data using BIOS services. It is also possible to save pointers to physical pos of each file, and have the files stored in 1 block, but this might be incompatible with some filesystems. If nobody else is on to this, I'll start with it. -- yossi (yogo@math.tau.ac.il) From vandys@glare.cisco.com Sat Nov 5 08:50:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00455; Sat, 5 Nov 1994 08:50:13 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA02873 for ; Sat, 5 Nov 1994 09:10:49 -0800 Received: from schirf.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA11001; Sat, 5 Nov 94 10:10:47 -0700 Received: from localhost by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id KAA04603; Sat, 5 Nov 1994 10:10:45 -0700 Message-Id: <199411051710.KAA04603@schirf.cs.utah.edu> To: yogo@math.tau.ac.il Cc: vsta@cisco.com Subject: Re: VSTa boot In-Reply-To: Your message of "Sat, 05 Nov 94 12:06:19 +0200." <9411051006.AA14362@libra.math.tau.ac.il> Date: Sat, 05 Nov 94 10:10:44 MST From: Bryan Ford >I got VSTa up and running on its own 10Mb DOS partition; I really don't like >it this way, booting into dos in order to get VSTa. Also, I can't boot >directly from its own fs. > >I saw somewhere in the digest files someone is working on an ext2fs (linux) >server, and on booting code which doesn't need dos. I wonder what is the >status of these. > >Booting up seems quite simple, assuming vstafs leaves the first sector >available as a boot sector. Current boot.exe jobs should be divided: one >tool for parsing boot.lst, checking what files are to be loaded, and >creating list of physical disk blocks for each file. This list is patched >on top of a boot sector loader, which simply reads blocks of data using BIOS >services. It is also possible to save pointers to physical pos of each file, >and have the files stored in 1 block, but this might be incompatible with >some filesystems. > >If nobody else is on to this, I'll start with it. If you'd be willing to take a little extra time to examine a few other issues as well before starting in on a new boot mechanism, you could make life much more enjoyable for a lot of other people as well. :-) VSTa isn't the only free OS that has serious bootstrap troubles. The Linux boot loaders have a stupid 512K limit on boot image size, which is OK if you're loading _just_ a relatively small kernel and a few device drivers, but sometimes would be nice to load a lot more from the start - for example, a whole suite of device drivers, plus an entire root disk image that you can work from in the absence of a functional hard disk. The BSD and Mach boot loaders don't have this 512K limitation, but are otherwise very brain-dead and rely on interpreting the file system at boot time, which means they are very file system specific. None of the BSD, Linux, or Mach boot loaders have any notion of loading multiple boot modules at once during bootstrap like VSTa does; yet both Linux and Mach are now seriously starting to need this feature. It sounds like what you're planning to do at this point is essentially rewrite LILO to support multiple boot modules and to run under VSTa. With a little planning, I think you could fairly easily create a boot loader that supports VSTa, Linux, Mach, and BSD at the same time in basically the same way, and could easily become "the definitive free OS boot loader". :-) There's also a lot of already-written free boot loader code I could point you to that might make your job easier. So, are you interested? Bryan From vandys@glare.cisco.com Sat Nov 5 16:11:52 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00478; Sat, 5 Nov 1994 16:11:45 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id QAA09027 for ; Sat, 5 Nov 1994 16:32:14 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa29112; 6 Nov 94 0:32 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r3vUY-0003l9C; Sun, 6 Nov 94 00:29 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa boot To: Bryan Ford Date: Sun, 6 Nov 1994 00:29:53 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199411051710.KAA04603@schirf.cs.utah.edu> from "Bryan Ford" at Nov 5, 94 10:10:44 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: 3844 Hi, > It sounds like what you're planning to do at this point is essentially > rewrite LILO to support multiple boot modules and to run under VSTa. > With a little planning, I think you could fairly easily create a boot loader > that supports VSTa, Linux, Mach, and BSD at the same time in basically the > same way, and could easily become "the definitive free OS boot loader". :-) > There's also a lot of already-written free boot loader code I could point > you to that might make your job easier. I've done quite a lot of work on this sort of code over the last year (including the rework of bfs and some code that's not hit the standard distribution as it's waiting for some extensions to libc to be included) and I've got a couple of comments and ideas: As well as the free OS code we'd also need to support booting DOS, OS/2 and NT (it's not going away for a while I suspect). Several people I've mentioned OS's like Linux and VSTa to all say the same thing - how easy is it to get this to work with my existing system/OS? A major reason for being able to use VSTa for code at work is because I can install it to boot from DOS via the DOS 6.22 config manager. That said, I like the multi-boot idea but after some experience of this now and having worked with a couple of fs's here are a couple of problems I think we'd need to overcome (and some possible solutions): 1) FS independence This is a difficult one - adding the ability to read all fs's we need is one possibility (simpler than a general case though as there's no need to check permissions, handle writes, handle concurrency, etc). Another solution is to provide tools for, or facilities within, each fs to be able to create a map of physical media blocks for any particular file. This whole issue can be complicated by the fact that I can layer one fs on top of another (eg to provide VSTa permissions and long filenames on top of a DOS FAT fs). BTW I seem to remember something about BSD partitions not being the same as DOS partitions. If this is true (and I'm not sure) then this also complicates matters. FWIW I believe these are the fs's we'd have to support to cover most of the free OS set (there are more): minix, ext2fs, bffs, vstafs, dos fat, and umsdos. 2) Pre-boot I/O In order to support a loader that can read multiple modules we need to provide a way to interact with the loader. There are two ways to do this - through the BIOS or via our own device drivers. If we say we'll write our own cut-down drivers (we don't need writes to disks say) then it means coding a driver for all of our possible BIOS supported boot devices, our keyboard, screens, RS-232 and I'd guess ethernet, etc. I believe this is how BSD does things but I really don't like it - I can envisage a boot loader that's bigger than our OS :-( The alternative is to use BIOS calls and thus real mode which is where we get our 512k limits from (we'll use 128k for vector tables, data areas and loader code). I've always planned to use the BIOS facilities for this (like Linux) which is why I ported bin86. What we could do to get round the 512k limit is write a mini BIOS-extender (same idea as a DOS-extender) that provides us with a mechanism to bounce data into extended memory as well as base memory. This will take a bit of coding, but as performance isn't the issue we can just switch between real and protected mode (avoiding V86 mode) - the DOS Oberon system used to do this (I don't know if it still does). At least with a BIOS-extender we can write some of our code with GCC :-) (although not using our standard libc) I think we can get to a stage where we can boot VSTa without DOS easily and perhaps we can show the way on how to tackle the problem to other OS's, but I think we'll find it difficult to create a *definitive* boot loader. Regards, Dave From vandys@glare.cisco.com Sat Nov 5 17:02:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00483; Sat, 5 Nov 1994 17:01:53 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA09545 for ; Sat, 5 Nov 1994 17:22:27 -0800 Received: from schirf.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA21654; Sat, 5 Nov 94 18:22:25 -0700 Received: from localhost by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id SAA05202; Sat, 5 Nov 1994 18:22:24 -0700 Message-Id: <199411060122.SAA05202@schirf.cs.utah.edu> To: Dave Hudson Cc: VSTa mailing list Subject: Re: VSTa boot In-Reply-To: Your message of "Sun, 06 Nov 94 00:29:53 GMT." Date: Sat, 05 Nov 94 18:22:22 MST From: Bryan Ford >I've done quite a lot of work on this sort of code over the last year >(including the rework of bfs and some code that's not hit the standard >distribution as it's waiting for some extensions to libc to be included) and >I've got a couple of comments and ideas: > >As well as the free OS code we'd also need to support booting DOS, OS/2 and >NT (it's not going away for a while I suspect). Several people I've >mentioned OS's like Linux and VSTa to all say the same thing - how easy is >it to get this to work with my existing system/OS? A major reason for being >able to use VSTa for code at work is because I can install it to boot from >DOS via the DOS 6.22 config manager. I agree that booting DOS, OS/2, NT, and other OS's will definitely be needed, but it can probably be handled just like LILO does it: chain to another boot block loaded from a particular partition. >That said, I like the multi-boot idea but after some experience of this now >and having worked with a couple of fs's here are a couple of problems I >think we'd need to overcome (and some possible solutions): > >1) FS independence > >This is a difficult one - adding the ability to read all fs's we need is one >possibility (simpler than a general case though as there's no need to check >permissions, handle writes, handle concurrency, etc). Another solution is >to provide tools for, or facilities within, each fs to be able to create a >map of physical media blocks for any particular file. This whole issue can >be complicated by the fact that I can layer one fs on top of another (eg to >provide VSTa permissions and long filenames on top of a DOS FAT fs). Both the FS-interpretation approach and the FS-independent block list approach have their advantages and disadvantages, and for a boot loader to be useable on all three major free OS's (Linux, BSD, VSTa) it would probably have to support both methods. For one thing, I'm pretty sure it takes special system calls (or in the case of VSTa and Mach, special FS server RPCs) to calculate block lists for embedding in the boot loader, and It's likely that BSD doesn't have such calls since they've always had just one "main" type of file system and have always gone with the FS interpretation approach. So if you're installing the boot loader under BSD, you probably can't calculate block lists at all. (Somebody tell me if I'm wrong.) On the other hand, block lists are the _only_ way to support arbitrary file systems that the boot loader doesn't directly know about. However, supporting both approaches may not be as big of a problem as it may seem at first. The Mach server bootstrap program (the program that loads servers once the "microkernel" has already been started) in the new mach4 distribution already has a rudimentary VFS-like layer and supports MINIX, ext2fs, and BFFS file systems at the same time (it automatically determines filesystem type and uses the appropriate interpretation code). You could take this code and add a fourth "file system type", which would really be more like a pseudo-filesystem that reads data based on precalculated LILO-style block lists. That way you'd get the benefits of both approaches: the boot loader would support certain common filesystems directly, and any other filesystem indirectly with the block list approach. >BTW I seem to remember something about BSD partitions not being the same as >DOS partitions. If this is true (and I'm not sure) then this also >complicates matters. That's true, and it is indeed a problem, but not a really big one. Basically the boot loader just needs to be able to detect and interpret more than one partitioning format, and nested partitions, in addition to multiple file system formats. (BSD systems are typically set up with a disk partitioned into DOS partitioned, with one of those DOS partitions sub-partitioned BSD-style. Ugly, but that's the way it is...) Someone's already working on bashing the Mach partition-interpretation code into something semi-encapsulated and environment-independent; if you want I can put you in contact with him and you two can work out how to set things up so both Mach and your boot loader (and potentially other clients) can use the same partition interpretation code. Maybe even create a "generic partition-interpretation library" or somesuch... :-) >FWIW I believe these are the fs's we'd have to support to cover most of the >free OS set (there are more): minix, ext2fs, bffs, vstafs, dos fat, and >umsdos. This looks like a good list, although umsdos is not absolutely necessary since files written through umsdos can be accessed by the same names through a traditional msdos filesystem as long as they're not too long or have funny characters or anything. And as I said before, the first three are already covered. :-) >2) Pre-boot I/O > >In order to support a loader that can read multiple modules we need to >provide a way to interact with the loader. There are two ways to do this - >through the BIOS or via our own device drivers. If we say we'll write our >own cut-down drivers (we don't need writes to disks say) then it means >coding a driver for all of our possible BIOS supported boot devices, our >keyboard, screens, RS-232 and I'd guess ethernet, etc. I think this would be a really bad idea... >I believe this is >how BSD does things but I really don't like it - I can envisage a boot >loader that's bigger than our OS :-( No, the BSD/Mach boot loaders use the normal BIOS calls. They load large boot images into >1MB memory by switching in and out of protected mode, just like DOS extenders do. In fact, unlike LILO, much of the BSD/Mach boot loader code is written in normal 32-bit C, compiled with GCC. (LILO is written all in 16-bit assembly language - hardly an ideal situation. :-) ) You could basically just pick up the BSD boot loader, which already handles the basic mode switching and disk loading, and start adding in the additional functionality to handle multiple boot modules, different file systems, etc. >The alternative is to use BIOS calls >and thus real mode which is where we get our 512k limits from (we'll use >128k for vector tables, data areas and loader code). I've always planned to >use the BIOS facilities for this (like Linux) which is why I ported bin86. >What we could do to get round the 512k limit is write a mini BIOS-extender >(same idea as a DOS-extender) that provides us with a mechanism to bounce >data into extended memory as well as base memory. This will take a bit of >coding, but as performance isn't the issue we can just switch between real >and protected mode (avoiding V86 mode) - the DOS Oberon system used to do >this (I don't know if it still does). At least with a BIOS-extender we can >write some of our code with GCC :-) (although not using our standard libc) Oops, I see you already had the basic idea - so I guess my news is that it's already done, and the code is available. :-) Good luck! Bryan From vandys@glare.cisco.com Sun Nov 6 05:43:44 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA00565; Sun, 6 Nov 1994 05:43:38 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA26106 for ; Sun, 6 Nov 1994 06:04:11 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa25386; 6 Nov 94 14:03 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r48DY-0003F2C; Sun, 6 Nov 94 14:05 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa boot To: Bryan Ford Date: Sun, 6 Nov 1994 14:05:12 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199411060122.SAA05202@schirf.cs.utah.edu> from "Bryan Ford" at Nov 5, 94 06:22: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: 2857 Hi, Bryan Ford wrote: > > However, supporting both approaches may not be as big of a problem as it > may seem at first. The Mach server bootstrap program (the program that > loads servers once the "microkernel" has already been started) in the new > mach4 distribution already has a rudimentary VFS-like layer and supports > MINIX, ext2fs, and BFFS file systems at the same time Why does mach need the microkernel loaded and running first? Certainly we'd have a problem under VSTa as we can't switch back to real mode at the moment (and I'm not too sure I'd like to be able to). I know that mach used to have it's device drivers running in kernel space - is this still true (and thus why we need the microkernel running)? > >BTW I seem to remember something about BSD partitions not being the same as > >DOS partitions. If this is true (and I'm not sure) then this also > >complicates matters. > > Maybe even create a "generic > partition-interpretation library" or somesuch... :-) Well we already have code for VSTa to handle dos partitions via a library and I guess supporting BSD partitioning wouldn't be a bad idea as well (someone's bound to suggest porting BFFS to VSTa sometime). > >FWIW I believe these are the fs's we'd have to support to cover most of the > >free OS set (there are more): minix, ext2fs, bffs, vstafs, dos fat, and > >umsdos. > > This looks like a good list, although umsdos is not absolutely necessary > since files written through umsdos can be accessed by the same names > through a traditional msdos filesystem as long as they're not too long or > have funny characters or anything. And as I said before, the first three > are already covered. :-) It's the long filenames I was thinking of really. It's not too bad though as we can get most of the format from the dos code. > No, the BSD/Mach boot loaders use the normal BIOS calls. They load > large boot images into >1MB memory by switching in and out of protected > mode, just like DOS extenders do. In fact, unlike LILO, much of the > BSD/Mach boot loader code is written in normal 32-bit C, compiled with GCC. Does NetBSD do this differently then? I have some of what I believe is the standard NetBSD boot code and it talks to the hardware directly. Can you point me at BIOS supporting code - thanks :-) > Oops, I see you already had the basic idea - so I guess my news is that > it's already done, and the code is available. :-) I'd like to see what's been done before, but I'm beginning to suspect that we need something new (just borrowing functions from elsewhere). I'd like to see the BIOS extender code, but I have some I wrote a couple of years ago that would do as well (just needs porting from TASM format to bin86 format, but that's pretty easy). Now if I can just find that magic 8th and 9th day next week ... :-) Regards, Dave From vandys@glare.cisco.com Sun Nov 6 06:30:50 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00570; Sun, 6 Nov 1994 06:30:47 -0800 Received: from math.tau.ac.il (taurus.math.tau.ac.il [132.67.64.4]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA26855 for ; Sun, 6 Nov 1994 06:51:22 -0800 From: yogo@math.tau.ac.il Received: from libra.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-930921) id AA11875; Sun, 6 Nov 94 16:51:08 +0200 Received: by libra.math.tau.ac.il (4.1/math.sub-st921020) id AA06872; Sun, 6 Nov 94 16:51:07+020 Message-Id: <9411061451.AA06872@libra.math.tau.ac.il> Subject: Re: VSTa boot To: vsta@cisco.com Date: Sun, 6 Nov 1994 16:51:06 +0200 (GMT+0200) In-Reply-To: from "Dave Hudson" at Nov 5, 94 11:08:37 am X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 497 > > The problem with getting the boot code to work without dos is that we'll > need a way to get a list of disk blocks used for a particular file in order > to load it. There are quite a few ways to make this easy for a particular > fs, but we really want a mechanism that's not tied to one specific fs. I haven't looked at the servers very much yet, was mainly peeking around the OS stuff; I guess the filesystems should offer standard interface for this. -- yossi (yogo@math.tau.ac.il) From vandys@glare.cisco.com Sun Nov 6 08:00:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00586; Sun, 6 Nov 1994 08:00:33 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA27644 for ; Sun, 6 Nov 1994 08:21:15 -0800 Received: from schirf.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA05496; Sun, 6 Nov 94 09:21:14 -0700 Received: from localhost by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id JAA09142; Sun, 6 Nov 1994 09:21:12 -0700 Message-Id: <199411061621.JAA09142@schirf.cs.utah.edu> To: Dave Hudson Cc: VSTa mailing list Subject: Re: VSTa boot In-Reply-To: Your message of "Sun, 06 Nov 94 14:05:12 GMT." Date: Sun, 06 Nov 94 09:21:11 MST From: Bryan Ford Dave Hudson wrote: >Bryan Ford wrote: >> >> However, supporting both approaches may not be as big of a problem as it >> may seem at first. The Mach server bootstrap program (the program that >> loads servers once the "microkernel" has already been started) in the new >> mach4 distribution already has a rudimentary VFS-like layer and supports >> MINIX, ext2fs, and BFFS file systems at the same time > >Why does mach need the microkernel loaded and running first? Certainly we'd >have a problem under VSTa as we can't switch back to real mode at the moment >(and I'm not too sure I'd like to be able to). I know that mach used to >have it's device drivers running in kernel space - is this still true (and >thus why we need the microkernel running)? Basically, it's a brain-damaged side effect of the way Mach developed. :-) We're working on changing Mach to do things more the way VSTa does - loading the microkernel and some initial servers all at once right on bootup; once that transition is completed (and we have a boot loader that fully supports this method :-) ), we'll get rid of the server bootstrap program. >> >BTW I seem to remember something about BSD partitions not being the same as >> >DOS partitions. If this is true (and I'm not sure) then this also >> >complicates matters. >> >> Maybe even create a "generic >> partition-interpretation library" or somesuch... :-) > >Well we already have code for VSTa to handle dos partitions via a library >and I guess supporting BSD partitioning wouldn't be a bad idea as well >(someone's bound to suggest porting BFFS to VSTa sometime). That sounds good. However, you should still contact the guy who's working on partition interpretation in Mach (again, another "feature" of the kernel that really doesn't belong in the kernel :-) ) and coordinate with him. A generic partition-interpretation library that would work under multiple OSes and in different environments would be great. Contact Stephen Williams . >> No, the BSD/Mach boot loaders use the normal BIOS calls. They load >> large boot images into >1MB memory by switching in and out of protected >> mode, just like DOS extenders do. In fact, unlike LILO, much of the >> BSD/Mach boot loader code is written in normal 32-bit C, compiled with GCC. > >Does NetBSD do this differently then? I have some of what I believe is the >standard NetBSD boot code and it talks to the hardware directly. Hmmm... I've never seen the NetBSD boot code, so you may be right; I just assumed it worked essentially like the Mach boot code. I know the Mach boot code uses the "BIOS extender" approach. >Can you >point me at BIOS supporting code - thanks :-) You can get it from kahlua.cs.utah.edu:/pub/mach/mach4-i386-UK02p6.tar.gz, in the directory mach4-i386/kernel/i386at/boot in the tar file. (Or if you'd prefer not to download the whole 300K source tree just to get the boot code, tell me and I'll create a smaller archive.) BTW, the Mach boot code uses a sort of kludgy way of coaxing 16-bit assembly language code out of gas, rather than using some other assembler such as as86. This has the advantage that it can be easily cross-compiled, but of course the 16-bit code is rather ugly. It seems like it should be almost trivial to change gas to support 16-bit code - basically just a matter of adding a directive that inverts the decision of whether or not to add a size prefix to each instruction, right? It might be worth looking into this before writing lots of new 16-bit code with either of the less-than-adequate existing methods. >> Oops, I see you already had the basic idea - so I guess my news is that >> it's already done, and the code is available. :-) > >I'd like to see what's been done before, but I'm beginning to suspect that >we need something new (just borrowing functions from elsewhere). I agree - it's no simple addition to one of the existing boot loaders - it's more a matter of gluing together a bunch of scattered existing routines into an entirely new boot loader. Thanks, and good luck! :-) Bryan From vandys@glare.cisco.com Sun Nov 6 08:03:31 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00589; Sun, 6 Nov 1994 08:03:26 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id IAA27671 for ; Sun, 6 Nov 1994 08:24:08 -0800 Received: from schirf.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA05524; Sun, 6 Nov 94 09:24:06 -0700 Received: from localhost by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id JAA09166; Sun, 6 Nov 1994 09:24:05 -0700 Resent-Message-Id: <199411061624.JAA09166@schirf.cs.utah.edu> Received: from math.tau.ac.il by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id HAA08958; Sun, 6 Nov 1994 07:46:16 -0700 From: yogo@math.tau.ac.il Received: from libra.math.tau.ac.il by math.tau.ac.il (5.67/math.tau-930921) id AA11791; Sun, 6 Nov 94 16:46:01 +0200 Received: by libra.math.tau.ac.il (4.1/math.sub-st921020) id AA06626; Sun, 6 Nov 94 16:45:59+020 Message-Id: <9411061445.AA06626@libra.math.tau.ac.il> Subject: Re: VSTa boot To: baford@schirf.cs.utah.edu (Bryan Ford) Date: Sun, 6 Nov 1994 16:45:59 +0200 (GMT+0200) In-Reply-To: <199411051710.KAA04603@schirf.cs.utah.edu> from "Bryan Ford" at Nov 5, 94 10:10:44 am X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1484 Resent-To: vsta@cisco.com Resent-Date: Sun, 06 Nov 94 09:24:04 MST Resent-From: Bryan Ford > The Linux boot loaders have a stupid 512K limit on boot image size, > which is OK if you're loading _just_ a relatively small kernel and Keep in mind PCs boot up in real mode, so >1Mb is impossible to load. That's in theory, in practice >640K is a problem as well, as this is where a lot of external memory (EPROMS, VGA ram etc) are located. > It sounds like what you're planning to do at this point is essentially > rewrite LILO to support multiple boot modules and to run under VSTa. In fact what I had in mind is writing a simple loader for VSTa, one which is small enough to live in a boot sector. It is then very generic, as ANYTHING which knows how to boot DOS will be able to boot it up (default mbr, LILO, OS/2 boot manager, and others). > With a little planning, I think you could fairly easily create a boot loader > that supports VSTa, Linux, Mach, and BSD at the same time in basically the > same way, and could easily become "the definitive free OS boot loader". :-) > There's also a lot of already-written free boot loader code I could point > you to that might make your job easier. > > So, are you interested? The question is - do I (or anybody else) need it? I have all of the above up and running here, except for Mach; This is all managed by LILO, which seems to handle this very good: It handles the linux-specific bootup, and it knows how to load DOS (+VSTa) or BSD boot sector and let their own loaders do their job. -- yossi (yogo@math.tau.ac.il) From vandys@glare.cisco.com Sun Nov 6 13:52:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00632; Sun, 6 Nov 1994 13:52:36 -0800 Received: from algol.cs.umbc.edu (wrath@algol.cs.umbc.edu [130.85.100.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA01726 for ; Sun, 6 Nov 1994 14:13:19 -0800 Received: (from wrath@localhost) by algol.cs.umbc.edu (8.6.9/8.6.9) id RAA29838 for vsta@cisco.com; Sun, 6 Nov 1994 17:13:16 -0500 From: Vijay Gill Message-Id: <199411062213.RAA29838@algol.cs.umbc.edu> Subject: status of the sparc port To: vsta@cisco.com Date: Sun, 6 Nov 1994 17:13:16 -0500 (EST) Reply-To: vijay@umbc.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 43 Anyone working on the sparc port? thanks From vandys@glare.cisco.com Sun Nov 6 14:27:44 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00636; Sun, 6 Nov 1994 14:27:40 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA02231 for ; Sun, 6 Nov 1994 14:48:07 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id PAA19008 for ; Sun, 6 Nov 1994 15:47:24 -0700 Message-Id: <199411062247.PAA19008@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: swap; sanity checking; list addres change Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19000.784162042.1@xmission.xmission.com> Date: Sun, 06 Nov 1994 15:47:23 -0700 From: Gary Shea First, I would appreciate it if I could get my list address changed to shea@xmission.com... my Novell address is a bit unstable. Second, has anyone got swap to work under any conditions? I am having real trouble getting vsta built, since it apparently needs more than 4 Megs in various places. It blows up about 15 times in the course of the build. I have tried swap with DOS partitions but it crashes the system. I'm making a good faith effort here -- I went out and bought 2 more Meg of memory and a 520 Meg disk! Finally, the hard question. I need to map a word into kernel space and change it. The user passes the system call the address of the word. I need to make sure the user isn't passing me something that should not be changed. My guess is I should scan through the pview's for that user's process, looking for one that applies to the word's address (can there be more than one?). If p_prot == 0 I won't be compromising security. Then I need to actually change the word. I'm not clear on how to do that... I can't find any examples to steal! I'm guessing that I need to somehow map the user's page into kernel space, do the change, then destroy the mapping. Can anyone point me to some code? Thanks Gary From vandys@glare.cisco.com Sun Nov 6 17:07:14 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00665; Sun, 6 Nov 1994 17:07:09 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA03855; Sun, 6 Nov 1994 17:27:53 -0800 Message-Id: <199411070127.RAA03855@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: swap; sanity checking; list addres change In-Reply-To: Your message of "Sun, 06 Nov 1994 15:47:23 MST." <199411062247.PAA19008@xmission.xmission.com> Date: Sun, 06 Nov 1994 17:27:53 -0800 From: Andrew Valencia [Gary Shea writes:] >First, I would appreciate it if I could get my list address >changed to shea@xmission.com... my Novell address is a bit >unstable. Done. >Second, has anyone got swap to work under any conditions? >I am having real trouble getting vsta built, since it >apparently needs more than 4 Megs in various places. It >blows up about 15 times in the course of the build. I have >tried swap with DOS partitions but it crashes the >system. I'm making a good faith effort here -- I went out >and bought 2 more Meg of memory and a 520 Meg disk! I have a palmtop 486 coming in about a week. I plan on partitioning 10 megs for swap, at which point I can start trying this for myself. Dave did some hacking, and we flushed out a couple bugs and a design flaw. I think the design flaw is in my court. >Finally, the hard question. I need to map a word into kernel >space and change it. The user passes the system call >the address of the word. I need to make sure the user isn't >passing me something that should not be changed. My guess is >I should scan through the pview's for that user's process, looking >for one that applies to the word's address (can there be more >than one?). If p_prot == 0 I won't be compromising security. >Then I need to actually change the word. I'm not clear on how >to do that... I can't find any examples to steal! I'm guessing >that I need to somehow map the user's page into kernel space, >do the change, then destroy the mapping. Can anyone point me to >some code? Do you really need it *mapped*? If not, copyin/copyout are the way to go. They do all the sanity checking and catch invalid references. Andy From vandys@glare.cisco.com Mon Nov 7 03:21:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA00834; Mon, 7 Nov 1994 03:20:54 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA21785 for ; Mon, 7 Nov 1994 03:41:38 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 07 Nov 94 12:41:18+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 07 Nov 94 12:40:01-0100 Date: 07 Nov 94 12:40:01-0100 From: Basile STARYNKEVITCH Message-Id: <9411071140.AA01068@rosser.serma.cea.fr> To: vsta@cisco.com Subject: vesta newcomer... and a few questions Content-Length: 5410 Hello all, I've been watching this mailing list for a couple of months. Finally i've got VSTa 1.3.2 (fetched from ftp.ibp.fr, a VSTa mirror ftp in France) running on my home PC (a 486DX2/66 with 16Mb RAM, Farenheight 1280 S3 graphic, 800Mb disks on IDE and SCSI). It is mostly a Linux box (at home, and i'm emailing from work). Thanks to all for a runnable VSTa. Actually, i'm mostly cross compiling: using Linux as a development environment (with Emacs -yes I like the full GNU emacs with all its features and whistles). The good news: 1) I successfully build a cross assembler and cross linker with GNU binutils-2.5.1 (which has a vsta target already) using linux as host and vsta as target. (binutils 2.5.2 is out now, i didn't try it yet). I hacked a little to add a vsta directory in linux /usr/lib/gcc-lib and can crosscompile using gcc -b vsta. I didn't recompile gcc (i'm using a 2.6.0p1 on linux). 2) my PC has a French keyboard (ie AZERTY instead of QWERTY). I half succeeded to patch vsta/srv/mach/con2/isr.c (making a new cons boot server). [[this is the main reason for cross-developpment: I really hate to have a keyboard mapping which is not what my keys engraving (ie the symbol painted on the real world plastic keys!) are. And very useful characters such as |<>[]{} have different mapping on French keyboards.]] I'm desperately lacking of documentations!! My very partial understanding is from reading some source files (and the very few vsta man pages). I did read a year ago some Plan9 introductory papers and the vsta readme file but i lack a clear picture of the whole thing. So, here are the bad news and the questions: 0) i can't afford having a PC devoted to VSTa. My PC is mostly a Linux box, and will remain mostly Linux. Most of my disk partitions are for Linux. I reserved 50Mb for VSTa (and have space for 90Mb more). Since i like the Linux environment i use it to cross-develop (source is Linux, target is Vsta). I might buy another disk in a few months if needed. 1) I didn't succeed to patch vsta/srv/mach/con2/isr.c using the AltGr key - its keycode is 100 (according to Linux kbd-0.89 sources and keymaps files). AltGr is needed on french keyboard because the tilde ~ is AltrGR+eacute, where eacute is the unshifted 2 key (digits are shifted). Many useful chars such as # { | \ are obtained by AltGr-ing a key (ie press AltGr, press another key, release this Key, release AltGr). I guess that AltGr key send an e0 extend keycode but i'm not sure. If someone patched the cons2 server for nonamerican keyboards i would be pleased to know about it. 2) printf and syslog(LOG_INFO, ..) didn't work. I suppose that my cons is the first server, and can't printf or syslog since no server can recieve it (i guess that both of them send messages to a server, probably cons). How can i debug the cons server? How can i display IsoLatin1 chars? (ie eacute, etc). 3) How can i use the dbg debugger? 4) It is really annoying that VSTa needs DOS to boot. (i didn't have DOS on my PC before but had to install DOS for VSTA -what a pity!). I suppose that the bfs (boot file system) is intended to abolish this major inconvenience. However, according to bfs.h comments it seems that bfs moves its files sometimes. But i expect a loader to load files from a fixed place. How would VSTa boot without DOS under bfs? I suppose that etc/inittab and etc/fstab would also go into BFs (with the boot/ subdir of course). Since BFS has no directories, what are the name conventions? I really wish a VSTA boot disk (ie a 1.44Mb floppy image). Please, don't assume all people have DOS!! 5) i didn't succeed in creating a user for me -i'm logging in as vandys. How do i create a user basile having nearly superuser power? 6) i think somebody wrote a VSTA fileserver for the Linux ext2 filesystem? Is this thing out? 7) what exactly is a mount under VSTa? (and what is the /env filesystem?). 8) what is a file under vsta, and a directory? Can a file be both an ordinary file (a la Posix, ie a stream of bytes) and a directory? I might write a filesystem whose files have forks (a la Macintosh). Basically, each file (or inode) would be a dictionnary (ie like a directory): keys would be IsoLatin1 strings, and values would be either byte blocks or pointer to another inode. Is this doable? 9) how do I add swap space to VSTa? Preferably, i would either swap to a partition (thus sharing a swap partition with Linux) or to a file (eg in a DOS or Bfs or VestaFS filesystem). How can i find out the remaining free (or used) memory (either physical or virtual) ? 10) what are the VestaFS specifics. How do i find the remaining available place on a VestaFS filesystem (i succeeded in creating one, and mounting it thru etc/fstab). How do i run the vestafs fsck? Thanks for reading (and sorry for my english). -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses VSTA-ling and Linux-ing at home only! From vandys@glare.cisco.com Mon Nov 7 08:13:52 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00855; Mon, 7 Nov 1994 08:13:47 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA18242; Mon, 7 Nov 1994 08:34:02 -0800 Message-Id: <199411071634.IAA18242@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Gary Shea Cc: vsta@amri.cisco.com Subject: Re: swap; sanity checking; list addres change In-Reply-To: Your message of "Mon, 07 Nov 1994 08:27:59 MST." <199411071528.IAA02418@xmission.xmission.com> Date: Mon, 07 Nov 1994 08:34:02 -0800 From: Andrew Valencia [Gary Shea writes:] >Yeah, I really need it mapped. This is the user-level synchronization >stuff we were talking about, a system call that takes a spinlock as an >argument, puts the process to sleep, and releases the lock. To >release the lock, it has to change the word holding the test-and-set >bit. Ah yes. >My questions are: 1) Is the above the right way to test whether >it's ok to write? and 2) How do I map the word into kernel space >so I can change it? Can I figure it all out just looking at copyin/ >copyout? I looked at them and didn't see what I was looking for; >I'll look again. (1) is probably NOT ok. The problem is that another thread could come along and unmap the memory. It would be a race condition. (2) you can touch the memory by or'ing in 0x80000000 to the address, but you have to use the probe support (see copyin/out) to protect against bogus addresses (and even addresses which become bogus as you run). Ring 0 code can generate references to ring 3 addresses because the kernel occupies the low half of the 32-bit address space and user code occupies the top half. User code *thinks* it starts at 0 because I put a 0x80000000 offset on all user segments. But kernel code sees user addresses at their true linear address. This is how copyin/out work. I don't think it's worth it for you to add a mapping just to have a kernel address for the user word. It's within your address space so doing it with probes is probably more efficient. Andy From vandys@glare.cisco.com Mon Nov 7 08:07:43 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00852; Mon, 7 Nov 1994 08:07:33 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA18063; Mon, 7 Nov 1994 08:28:20 -0800 Message-Id: <199411071628.IAA18063@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Basile STARYNKEVITCH Cc: vsta@cisco.com Subject: Re: vesta newcomer... and a few questions In-Reply-To: Your message of "07 Nov 1994 12:40:01 -0100." <9411071140.AA01068@rosser.serma.cea.fr> Date: Mon, 07 Nov 1994 08:28:20 -0800 From: Andrew Valencia [Basile STARYNKEVITCH writes:] >0) i can't afford having a PC devoted to VSTa. My PC is mostly a Linux >box, and will remain mostly Linux. Most of my disk partitions are for >Linux. I reserved 50Mb for VSTa (and have space for 90Mb more). Since >i like the Linux environment i use it to cross-develop (source is >Linux, target is Vsta). I might buy another disk in a few months if needed. 50 megs is fine for developing. I still have a 386sx laptop with 32 megs of disk and 4 megs of RAM. >2) printf and syslog(LOG_INFO, ..) didn't work. I suppose that my cons >is the first server, and can't printf or syslog since no server can >recieve it (i guess that both of them send messages to a server, >probably cons). How can i debug the cons server? How can i display >IsoLatin1 chars? (ie eacute, etc). Right, the console *is* the destination of syslog messages; sending to yourself is circular and won't give you much joy. But since you're within the console server why not just call write_string() directly? >3) How can i use the dbg debugger? Kernel or process debugger? >5) i didn't succeed in creating a user for me -i'm logging in as >vandys. How do i create a user basile having nearly superuser power? Could you include your entry and explain how it "didn't succeed"? >6) i think somebody wrote a VSTA fileserver for the Linux ext2 >filesystem? Is this thing out? I've never received a copy. >7) what exactly is a mount under VSTa? (and what is the /env filesystem?). The "mount table" from UNIX is simply a data structure within the C library under VSTa. So when you call open() he simply refers to his array of mounts, figures out which server he wants, and asks that server to open a certain path. The kernel knows nothing of pathnames or mount points. /env is the server for environment variables. Your environment path is specified in /vsta/etc/passwd. For purposes of an example, assume it's /users/programmers/basile. When you getenv("FOO") the file: /users/programmers/basile/FOO is open()'ed. The /env filesystem will try the whole path. If it doesn't find it, it then tries /users/programmers/FOO, then /users/FOO, then /FOO. So you can create a global value for the environment variable FOO, or a groupwide one, or a per-user one. Actually, you can create a per-process one, too, but perhaps you didn't want this much detail. I think I described it on the list before, anyway. >8) what is a file under vsta, and a directory? Can a file be both an >ordinary file (a la Posix, ie a stream of bytes) and a directory? I >might write a filesystem whose files have forks (a la >Macintosh). Basically, each file (or inode) would be a dictionnary (ie >like a directory): keys would be IsoLatin1 strings, and values would >be either byte blocks or pointer to another inode. Is this doable? A file is a convention shared between a client (usually via the C library) and a server. Usually files do not permit the FS_OPEN operation. Usually, FS_READ operations on directories return the directory entries within the directory. A server could deviate from this easily. >9) how do I add swap space to VSTa? Preferably, i would either swap to >a partition (thus sharing a swap partition with Linux) or to a file >(eg in a DOS or Bfs or VestaFS filesystem). How can i find out the remaining >free (or used) memory (either physical or virtual) ? I wouldn't mess around with swap just yet. We've found some bugs and are working on them. >10) what are the VestaFS specifics. How do i find the remaining >available place on a VestaFS filesystem (i succeeded in creating one, >and mounting it thru etc/fstab). How do i run the vestafs fsck? I'm not sure what you mean by "specifics"? I guess I need to add max and current space to stat.c; it's only announced during filesystem startup now. You run fsck on the device holding the filesystem. If you had it on, say, a VSTa BFS-type partition, you might have to mount it into your namespace first: mount disk/wd /dev/wd fsck /dev/wd/wd0_bfs0 Andy From vandys@glare.cisco.com Mon Nov 7 09:16:07 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00866; Mon, 7 Nov 1994 09:16:01 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA21383; Mon, 7 Nov 1994 09:36:48 -0800 Message-Id: <199411071736.JAA21383@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Antony Halim Cc: vsta@cisco.com Subject: Re: newbie question In-Reply-To: Your message of "Mon, 07 Nov 1994 09:28:51 PST." Date: Mon, 07 Nov 1994 09:36:47 -0800 From: Andrew Valencia [Antony Halim writes:] >I am new to vsta, and wonder if there's some documentations that explains >the structure of the OS. There's a the (very aged) paper on the FTP site. The mail archives hold discussions on many parts of the system. The "man" command documents the messaging primitives (which probably are too low level to help somebody get started). My guess is the mail archives are the closest to what you want. I should write "The Design and Implementation of the VSTa Operating System" and cut a cool deal with a publisher. In my spare time. :-) Regards, Andy From vandys@glare.cisco.com Mon Nov 7 09:08:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA00863; Mon, 7 Nov 1994 09:08:09 -0800 Received: from chaph.usc.edu (chaph.usc.edu [128.125.253.133]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA03560 for ; Mon, 7 Nov 1994 09:28:57 -0800 Received: from girtab.usc.edu (antony@girtab.usc.edu [128.125.253.145]) by chaph.usc.edu (8.6.8.1/8.6.4) with ESMTP id JAA12003 for ; Mon, 7 Nov 1994 09:28:55 -0800 Received: (antony@localhost) by girtab.usc.edu (8.6.8.1/8.6.7+ucs) id JAA13143; Mon, 7 Nov 1994 09:28:51 -0800 Date: Mon, 7 Nov 1994 09:28:51 -0800 (PST) From: Antony Halim Subject: newbie question To: vsta@cisco.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am new to vsta, and wonder if there's some documentations that explains the structure of the OS. Thanks /antony From vandys@glare.cisco.com Mon Nov 7 12:20:44 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA00887; Mon, 7 Nov 1994 12:20:40 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA13074 for ; Mon, 7 Nov 1994 12:41:29 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA18785; Mon, 7 Nov 1994 10:38:28 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411072038.AA18785@zang.kcc.hawaii.edu> Subject: Re: vesta newcomer... and a few questions To: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) Date: Mon, 7 Nov 1994 10:38:26 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <9411071140.AA01068@rosser.serma.cea.fr> from "Basile STARYNKEVITCH" at Nov 7, 94 12:40:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1273 > 2) printf and syslog(LOG_INFO, ..) didn't work. I suppose that my cons > is the first server, and can't printf or syslog since no server can > recieve it (i guess that both of them send messages to a server, > probably cons). How can i debug the cons server? How can i display > IsoLatin1 chars? (ie eacute, etc). What I did when I was getting my console up was to add another system call that printed a string on the system console. This allowed me to print strings before the console was initialized. If you are debugging past the point where the console is initialized you can just call the console output string routine. > 3) How can i use the dbg debugger? The list of commands available from dbg is found in the file vsta/os/dbg/dbgmain.c. I added an extra command "?"/"help" which prints out this list as a quick reference. Its really meant for debugging the kernel. Using it to debug user-level processes is possible but you dont want to do this :) All the mappings are in the kernels space and you have to constantly translate (and worse if you have it printing kernel symbolic names which have no meaning to you). > Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique > email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 From vandys@glare.cisco.com Mon Nov 7 16:29:04 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00906; Mon, 7 Nov 1994 16:29:00 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id QAA24246 for ; Mon, 7 Nov 1994 16:49:49 -0800 Received: from mancos.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA19779; Mon, 7 Nov 94 17:49:41 -0700 Received: from localhost by mancos.cs.utah.edu (8.6.9/utah-2.15-leaf) id RAA21055; Mon, 7 Nov 1994 17:49:37 -0700 Message-Id: <199411080049.RAA21055@mancos.cs.utah.edu> From: Jay Lepreau To: vsta@cisco.com Cc: dbo@cs.utah.edu Subject: Server-based shared libraries Date: Mon, 07 Nov 94 17:49:36 MST Bryan Ford pointed me to your html-ized mail archives (pretty cool, and cool stuff you're doing in VSTa). I noticed all the discussion in August about shared libraries, including references to Spring's server, and discussion about loss of rebinding flexibility and start up slowness. At Utah we also developed a server-based shared library system, based on our OMOS server (Object/Meta-object Server), which offers additional flexibility over Sun's. As a matter of fact, it was presented at the same Usenix conference, Summer '93. The paper is available by ftp on mancos.cs.utah.edu as papers/shlibs.ps.Z (or in URL'ese file://mancos.cs.utah.edu/papers/shlibs.ps.Z). OMOS is currently undergoing a drastic re-write. We plan to have a snapshot available by the end of the year. It probably won't be straightforward to make a production shared library system then, but you might want to consider it in the future. OMOS is also a crucial component of our Mach-related research project into flexible and adaptive operating systems. That project's home page is http://www.cs.utah.edu/projects/flexmach/. (I'm not on the vsta list, nor is Doug Orr (dbo), the author of OMOS, so reply personally if you have questions or comments.) From vandys@glare.cisco.com Tue Nov 8 02:09:07 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA00957; Tue, 8 Nov 1994 02:08:59 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA07848 for ; Tue, 8 Nov 1994 02:29:46 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 08 Nov 94 11:29:19+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 08 Nov 94 11:29:46-0100 Date: 08 Nov 94 11:29:46-0100 From: Basile STARYNKEVITCH Message-Id: <9411081029.AA13475@rosser.serma.cea.fr> To: newsham@zang.kcc.hawaii.edu Cc: vsta@cisco.com In-Reply-To: <9411072038.AA18785@zang.kcc.hawaii.edu> Subject: Re: vesta newcomer... and a few questions Content-Length: 563 Thanks for your reply. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Tue Nov 8 03:37:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA00994; Tue, 8 Nov 1994 03:37:29 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA15680 for ; Tue, 8 Nov 1994 03:55:42 -0800 Received: from ibch50.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA00773; Tue, 8 Nov 1994 12:54:10 +0100 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA21567; Tue, 8 Nov 1994 12:52:20 +0100 Date: Tue, 8 Nov 1994 12:52:20 +0100 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9411081152.AA21567@ibch50.inf.tu-dresden.de> To: antony@chaph.usc.edu Cc: vsta@cisco.com In-Reply-To: message from Andrew Valencia on Mon, 07 Nov 1994 09:36:47 -0800 Subject: Re: newbie question > [Antony Halim writes:] > > >I am new to vsta, and wonder if there's some documentations that explains > >the structure of the OS. > > There's a the (very aged) paper on the FTP site. The mail archives hold > discussions on many parts of the system. The "man" command documents the > messaging primitives (which probably are too low level to help somebody > get started). > > My guess is the mail archives are the closest to what you want. I should > write "The Design and Implementation of the VSTa Operating System" and cut a > cool deal with a publisher. In my spare time. :-) I gave a intro talk about vsta at the university here. The manuscript (including the slides) is avialable: http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/doc.de/Uebersicht.html and http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/doc.de/Uebersicht.ps Unfortunatly it is still in german except for some parts. Please be carefull: it is partially compiled from the mail archives and nobody checked it for errors yet. /Joerg From vandys@glare.cisco.com Tue Nov 8 02:05:36 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA00954; Tue, 8 Nov 1994 02:05:06 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA07772; Tue, 8 Nov 1994 02:25:49 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 08 Nov 94 11:25:34+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 08 Nov 94 11:25:52-0100 Date: 08 Nov 94 11:25:52-0100 From: Basile STARYNKEVITCH Message-Id: <9411081025.AA13467@rosser.serma.cea.fr> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: <199411071724.JAA20421@glare.cisco.com> Subject: VSTa french keyboards, and Linux filesystems Content-Length: 19305 (I'm replying to Andy, but since this might interest other VSTa users, i'm CC-ing the VSTa mailing list). in an replying email to me, >>>>> "Andrew" == Andrew Valencia writes: >> Do you want my patches to vsta/srv/mach/cons2/isr.c for a >> French keyboard? (even if they are only half working?). (sorry Andy for citing the 2 following lines without permission - I suppose it is not a secret!) Andrew> I wouldn't be able to work on them for myself (lacking a Andrew> French keyboard) so I'd rather wait. **** French keyboards **** I still send it to you.. the actual differences are really tiny. Having a bad keyboard mapping is a nightmare. So, if some french people want to use VSTa, they will be very pleased to have a working cons2 server. Also, other people having non american keyboards might look at it to implement their own mapping. Of course, a good cons should be able to load its keymaps from a file (and this don't do it). The french keyboard is enabled by a -DFRENCH_KBD compilation flag. Some keyboard logging (by write_string messages describing the keycodes and chars) is enabled at compilation time by a -DLOG_KBD compilation flag; it is then toggled during execution by Alt-F10 (leaving only 9 virtual consoles instead of 10) -initially logging is of course disabled. ***** Linux filesystems **** Since i really want to use Linux, i want some filesystem server for at least reading some kind of Linux fs (other than MessyLoss of course - i hate being limited to 8+3 chars in filenames). Do some other people are working on it now? (it seems that some guy started working on ext2 but never got it done) I looked at several Linux fs sources (in Linux v1.1.60): ext2, xia, minix: 1. ext2 is (probably) the most used and the most efficient Linux filesystem. It is the most complex of the 3 fs. It is probably the most efficient, perhaps the less buggy (since it has been tested at thousands of Linux sites). It has cylinder groups, some kind of ACLs (partly implemented), some kind of interesting file flags (compressed, immutable) most of which are not implemented today (in Extfs 0.5a). Perhaps a possible advantage of ext2fs is that it has already been ported (according to source comments) to mach and/or hurd, masix which are supposed to be microkernels. 2. minix and xia are very similar filesystems. Minix don't have file atime (only mtime). It is limited to 32Mb filesystems which is too small. It is probably less robust than ext2 (no cylinder groups). Xia is essentially a minix fs with some added features: bigger fs, longer names, separate atime & mtime, etc. I think i don't want to reuse code from Linux fs. I will only use the data definitions (ie the include files describing the disk layout). Linux fs code is full of linux specific kernel routines. At the moment, i only want to read Linux fs. I don't want to spend to much time (ie only a dozen of evenings). I might give up if it is to complex. Currently, i think i will pick the xia and minix filesystems, since their structure is simpler than ext2 (but they have less features, are less robust). Another possibility will be to interface to linux some filesystem in VSTa. This could be made simpler by using the userfs Linux filesystem (userfs is a filesystem which translate kernel calls to a protocol into a user space Linux server process -something like NFS protocol but probably simpler). The linux vstafs would be a userlevel server process. Of course, the issue is efficiency. Linux is not a microkernel and userfs is not efficient. Any comments or ideas? I'm VSTa-ling and linux-ing only at home (on my home PC) on my spare time and don't have much time for it. ****** hack to cons2 for optional french kbd support **** Here is the uuencoded cons2/isr.c file. I uuencode it because it contains some Iso-Latin-1 chars (which are not displayed correctly now, but this is another story). These are needed because some keys give aacute or eacute without modifiers, and @ or ~ with the AltGr modifier. Since the file is small, i didn't compress or Gnu zip it. I do hope you will add it to next VSTa distributions -even as an unsupported contrib. Please understand that booting a wrong keyboard is simply a nightmare - and french keyboards have tricky stuff for useful chars for Posix or Vsta such as | { } [ ] ` \. begin 644 isr.c M+RH*("H@:7-R+F,@("T@)$ED.B!I2!H86-K960@8GD@ M0F%S:6QE(%-405)93DM%5DE40T@*(" @*&)A6)O87)D('-U<'!O0H@ M(" Y(&]U="!O9B Q,"!V:7)T=6%L(&-O;G-O;&5S(&%R92!S=7!P;W)T960@ M:6X@=&AA="!C87-E*2X@5VAE;@H@("!E;F%B;&5D+"!A;&P@:V5Y8V]D97,@ M86YD(&-H87)S(&%R92!W7,@*B\*"6-A<'-T;V=G M;&4@/2 P+ DO*B!&;W(@=&]G9VQI;F<@969F96-T(&]F($-!4%,@*B\*"6YU M;71O9V=L92 ](# L"2\J(" N+BY.54T@;&]C:R J+PH):7-%," ](# ["2\J M(%!R969I>"!F;W(@97AT96YD960@:V5Y2)RPG)"#@P+#!X.# L,'@X,"PP>#@P+#!X.# L,'@X M,"PP>#@P+#!X.# L"B\J-C@M-S@J+R @,'@X,"PP>#@P+#!X.# L,'@X,"PP M>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L"B\J-SDM M.#8J+R @,'@X,"PP>#@P+#!X.# L)S G+# Q-SPHO*C M,34J+R @ M,"PP,S,L)S$G+" G,BG)RP@,'@X,"P*+RHU-2TV-BHO M("#@P+#!X.# L,'@X,"PP>#@P M+#!X.# L,'@X,"PP>#@P+ HO*C8X+3#@P+#!X.# L,'@X M,"PG-R#@P+"#@P+" P>#@P+" G M/B<*?3L*"B\J(&%D9&5D('-C86X@8V]D97,@9F]R($%L=$=R+65D("HO"G-T M871I8R!C:&%R(&%L=&=R961;,3(X72 ]('L*(# L(# S,RP@)R8G+" G?BB2#@P+" G*B#@P+" P>#@P+ H@,'@X,"P@,'@X,"P@,'@X,"P@ M,'@X,"P@,'@X,"P@,'@X,"P@,'@X,"P@,'@X,"P@,'@X,"P@,'@X,"P@"B P M>#@P+" G-R#@P M+ HG,2#@P+"<@)RPP>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L,'@X,"PP M>#@P+#!X.# L,'@X,"P*,'@X,"PP>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L M,'@X,"PP>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L"C!X.# L,'@X,"PP>#@P M+")RPG)BR#@P+ HG02#@P+ HG?"#@P+"<@)RPP>#@P+#!X.# L,'@X,"PP>#@P+#!X.# L,'@X,"PP>#@P M+#!X.# L,'@X,"P*,'@X,"PP>#@P+#!X.# L,'@X,"PG-R#@P+"5]E=F5N="@I"B J"5!R;V-E7,N("!/;B!TPH)=6-H87(@8V@[ M"B-I9F1E9B!,3T=?2T)$"B @(" @(" @PH@"0D)8V@@/2!S:&EF=" _(&YO7,@96YT97)S"@D@*B!D871A(&9OPH)"6MB9%]E;G%U975E*',L(&,I.PH)?0I]"@HO*@H@ M*B!C=7)S;W)?:V5Y*"D*("H)4')O8V5S2AS=')U8W0@PH)"65N<75E M=65?2@I"B J"5!R;V-EPH)8VAAPH)"65N<75E=65?2!C:&%N9V5S"B J"B J(%)E='5R;G,@,2!I9B!I=" J=V%S*B!A('-H:69T M+71Y<&4@:V5Y+" P(&]T:&5R=VES92X*("HO"G-T871I8R!I;G0*PH)8V%S92 P>#,V.@D)+RH@ M4VAI9G0@:V5Y(&1O=VX@*B\*"6-A#%D.@D)+RH@0V]N=')O;"!K97D@9&]W;B J+PH)"6-T;" ] M(#$["@D)8G)E86L["@EC87-E(#!X.60Z"0DO*B!#;VYT2!U<" J M+PH)"6-T;" ](# ["@D)8G)E86L["@EC87-E(#!X,S@Z"0DO*B!!;'0@:V5Y M(&1O=VX@*B\*(VEF9&5F($9214Y#2%]+0D0*"0DO*B!A;'1G'1E;F1E9"!P&(X.@D)+RH@06QT(&ME>2!U<" J+PH)"6%L=" ](# [ M"B-I9F1E9B!&4D5.0TA?2T)$"B @(" @(" @(" @(" @(" O*B!!;'1''1E;F1E9"!P#8T.B @(" @(" @ M(" @(" @+RH@06QT9W(@:V5Y(&1O=VX@*B\*(" @(" @(" @(" @(" @('-Y M#-A.@D)+RH@26=N;W)E M(&-A<"]N=6T@9&]W;CL@=&AE>2!M:6=H="!R97!E870@*B\*"6-A2!P96YD:6YG M(')E861S+@H@*B\*=F]I9 IK8F1?:7-R*'-T$A<;B(L(&1A=&$L(&1A=&$I.PH@(" @(" @(" @ M=W)I=&5?7,M M+4%,5"U&,2!A;F0@PH@(" @(" @(" @;&]G:V)D M(#T@(6QO9VMB9#L*(" @(" @(" @('-P6)O M87)D(&QO9V=I;F<@)7,@7&XB+ H@(" @(" @(" @(" @(" @("!L;V=K8F0_ M(F5N86)L960B.B)D:7-A8FQE9"(I.PH@(" @(" @(" @=W)I=&5?$4P*2!["B )"6ES13 @/2 P.PH@( E]"GT* end -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 VSTa-ling and Linux-ing at home only. N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Tue Nov 8 07:38:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01011; Tue, 8 Nov 1994 07:38:02 -0800 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA23176 for ; Tue, 8 Nov 1994 07:58:55 -0800 Received: from schirf.cs.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA09242; Tue, 8 Nov 94 08:58:53 -0700 Received: from localhost by schirf.cs.utah.edu (8.6.9/utah-2.15-leaf) id IAA19852; Tue, 8 Nov 1994 08:58:47 -0700 Message-Id: <199411081558.IAA19852@schirf.cs.utah.edu> To: Basile STARYNKEVITCH Cc: vsta@cisco.com Subject: Re: VSTa french keyboards, and Linux filesystems In-Reply-To: Your message of "08 Nov 94 11:25:52 -0100." <9411081025.AA13467@rosser.serma.cea.fr> Date: Tue, 08 Nov 94 08:58:46 MST From: Bryan Ford >Since i really want to use Linux, i want some filesystem server for at >least reading some kind of Linux fs (other than MessyLoss of course - >i hate being limited to 8+3 chars in filenames). Do some other people >are working on it now? (it seems that some guy started working on ext2 >but never got it done) I looked at several Linux fs sources (in Linux >v1.1.60): ext2, xia, minix: > > 1. ext2 is (probably) the most used and the most efficient Linux > filesystem. It is the most complex of the 3 fs. It is probably the > most efficient, perhaps the less buggy (since it has been tested at > thousands of Linux sites). It has cylinder groups, some kind of ACLs > (partly implemented), some kind of interesting file flags (compressed, > immutable) most of which are not implemented today (in Extfs 0.5a). > Perhaps a possible advantage of ext2fs is that it has already been > ported (according to source comments) to mach and/or hurd, masix > which are supposed to be microkernels. It's been ported to the Hurd (which runs on the Mach "microkernel"), and is currently being ported to Lites (which also runs on Mach). Both ports are by the same guy - ldd@step.polymtl.ca (Louis-D. Dubeau). You might want to contact him - he probably has some good hints and possibly some ext2fs code that's much more portable than the original Linux code, which you could get going fairly easily on VSTa. >I think i don't want to reuse code from Linux fs. I will only use the >data definitions (ie the include files describing the disk >layout). Linux fs code is full of linux specific kernel routines. Reinventing the wheel will almost certainly take more time, especially considering that ext2fs has already been ported to non-Linux environments. >At >the moment, i only want to read Linux fs. I don't want to spend to >much time (ie only a dozen of evenings). You can simply not implement the glue code to call the ext2fs write routines, if you're in a hurry. It'll still almost certainly be way faster than rolling your own from scratch. Another approach you could take, if you're really not interested in writing to filesystems even in the longer term, is to use the FS interpretation code in the Mach server bootstrap program. It's fairly well encapsulated and should be easy to rip out, and already supports ext2fs, Minix, and BFFS, so you'd get "three for the price of one". :-) But it's definitiely never going to support writing. If you try this approach, you should coordinate with whomever is planning to work on the new boot loader (Dave Hudson and/or Yossi Gottlieb, both of whom are on this list), since it may use it too. You might be able to use the same source code, or a common library. Bryan From vandys@glare.cisco.com Tue Nov 8 23:04:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA01081; Tue, 8 Nov 1994 23:04:47 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA04190 for ; Tue, 8 Nov 1994 23:25:41 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 09 Nov 94 08:25:36+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 09 Nov 94 08:26:04-0100 Date: 09 Nov 94 08:26:04-0100 From: Basile STARYNKEVITCH Message-Id: <9411090726.AA00425@rosser.serma.cea.fr> To: vsta@cisco.com Cc: baford@schirf.cs.utah.edu, rideau@clipper.ens.fr, Remy.Card@masi.ibp.fr In-Reply-To: <199411081558.IAA19852@schirf.cs.utah.edu> Subject: VSTa & Linux ext2fs filesystem Content-Length: 1334 After emails from Bryan Ford , Francois-Rene Rideau , Remy.Card@masi.ibp.fr, and another kind person (T.T.?) whose email i've lost, i decided to look into e2fsprogs-0.5b-WIP.tar.gz. Among other things this contains a libext2fs which interfaces an Ext2fs filesystem thru a parametrable IO "manager". I believe this could be easily translated to a VSTa message routines. This libext2 seem rather modular. So, contrary to what i've said before, i will just take this libext2 and interface it to VSTa. I don't care about efficiency. If i succeed (this means i don't want to spend too much time on it) I will email patches to the VSTa mailing list and to Remy.Card. All this is done at home on my spare time. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 VSTa-ling and Linuxing at home only N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Nov 9 00:32:04 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA01096; Wed, 9 Nov 1994 00:31:26 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA07411 for ; Wed, 9 Nov 1994 00:52:08 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 09 Nov 94 09:52:04+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 09 Nov 94 09:52:29-0100 Date: 09 Nov 94 09:52:29-0100 From: Basile STARYNKEVITCH Message-Id: <9411090852.AA01197@rosser.serma.cea.fr> To: vsta@cisco.com Subject: patches for GCC 2.6.1 under VSTa. Content-Length: 25072 I'm linuxing and VSTa-ling at home only as a hobby (ie for fun, not serious). I tried to install GNU gcc-2.6.1 for VSTa (technically i patched it for a cross compiler build on i486-linux for i486-vsta.). I first installed GNU binutils-2.5.2.tar.gz (which does have alread a support for VSTa) - i took config.sub from there. I left home before gcc-2.6.1 for VSta compilation finished - but half of it was done. (i did have problems for makeing the vsta specific config files, but they always occured in less than 10 minutes; and this compilation already ran >40min). The resulting patches (to apply to GNU 2.6.1 distribution) follows. Please, test them and improve them. Once they are ok, I hope Andy could post them to GNU, to be added for the 2.6.2 GNU distribution (which might come out soon, so we better test this in less than a week). diff -P -r -C 3 /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/vsta.h gcc-2.6.1-vsta/config/i386/vsta.h *** /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/vsta.h Thu Jan 1 01:00:00 1970 --- gcc-2.6.1-vsta/config/i386/vsta.h Tue Nov 8 23:29:44 1994 *************** *** 0 **** --- 1,109 ---- + /* Definitions for Intel 386 running VSTa + Copyright (C) 1992, 1994 Free Software Foundation, Inc. + + (inspired from Linux config.) + + This file is part of GNU CC. + + GNU CC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GNU CC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU CC; see the file COPYING. If not, write to + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ + + /* base Intel 386 defs */ + #include "i386/i386.h" + /* Unix specific i386 */ + #include "i386/unix.h" + /* some stuff from Bsd */ + #include "i386/bsd.h" + /* Get perform_* macros to build libgcc.a. */ + #include "i386/perform.h" + + /* Don't assume anything about the header files. */ + #define NO_IMPLICIT_EXTERN_C + + /* This is tested by i386/gas.h. */ + #define YES_UNDERSCORES + + /* Specify predefined symbols in preprocessor. */ + + #undef CPP_PREDEFINES + #define CPP_PREDEFINES "-Dposix -Di386 -Dvsta -D__vsta__ -Asystem(vsta) -Asystem(posix) -Acpu(i386) -Amachine(i386)" + + #undef CPP_SPEC + #if TARGET_CPU_DEFAULT == 2 + #define CPP_SPEC "%{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE}" + #else + #define CPP_SPEC "%{m486:-D__i486__} %{posix:-D_POSIX_SOURCE}" + #endif + + #undef SIZE_TYPE + #define SIZE_TYPE "unsigned int" + + #undef PTRDIFF_TYPE + #define PTRDIFF_TYPE "int" + + #undef WCHAR_TYPE + #define WCHAR_TYPE "long int" + + #undef WCHAR_TYPE_SIZE + #define WCHAR_TYPE_SIZE BITS_PER_WORD + + #undef HAVE_ATEXIT + + + /* Linux uses ctype from glibc.a. I am not sure how complete it is. + For now, we play safe. It may change later. */ + + #if 0 + #undef MULTIBYTE_CHARS + #define MULTIBYTE_CHARS 1 + #endif + + #undef LIB_SPEC + /*we dont have any profiling or other so just use -lc*/ + #define LIB_SPEC \ + "-lc" + + #undef STARTFILE_SPEC + #define STARTFILE_SPEC "{server:crt0srv.o%s} %{!server:crt0.o%s}" + + + + /* There are conflicting reports about whether this system uses + a different assembler syntax. wilson@cygnus.com says # is right. */ + #undef COMMENT_BEGIN + #define COMMENT_BEGIN "#" + + #undef ASM_APP_ON + #define ASM_APP_ON "#APP\n" + + #undef ASM_APP_OFF + #define ASM_APP_OFF "#NO_APP\n" + + /* Don't default to pcc-struct-return, because gcc is the only compiler, and + we want to retain compatibility with older gcc versions. */ + #define DEFAULT_PCC_STRUCT_RETURN 0 + + + /* We need that too. */ + #define HANDLE_SYSV_PRAGMA + + #undef LINK_SPEC + + /* We want to pass -v to linker */ + #if TARGET_CPU_DEFAULT == 2 + #define LINK_SPEC "%{v:-v} %{!m386:-m486}" + #else + #define LINK_SPEC "%{v:-v} %{m486:-m486}" + #endif + diff -P -r -C 3 /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/x-vsta gcc-2.6.1-vsta/config/i386/x-vsta *** /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/x-vsta Thu Jan 1 01:00:00 1970 --- gcc-2.6.1-vsta/config/i386/x-vsta Tue Nov 8 20:14:08 1994 *************** *** 0 **** --- 1,14 ---- + # (inspired from Linux config.) + X_CFLAGS = -DPOSIX + + # The following is needed when compiling stages 2 and 3 because gcc's + # limits.h must be picked up before /usr/include/limits.h. This is because + # each does an #include_next of the other if the other hasn't been included. + # /usr/include/limits.h loses if it gets found first because /usr/include is + # at the end of the search order. When a new version of gcc is released, + # gcc's limits.h hasn't been installed yet and hence isn't found. + + BOOT_CFLAGS = -O $(CFLAGS) -Iinclude + + # Don't run fixproto + STMP_FIXPROTO = diff -P -r -C 3 /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/xm-vsta.h gcc-2.6.1-vsta/config/i386/xm-vsta.h *** /home/rosser/basile/mimas.tmp/gcc-2.6.1/config/i386/xm-vsta.h Thu Jan 1 01:00:00 1970 --- gcc-2.6.1-vsta/config/i386/xm-vsta.h Tue Nov 8 20:13:56 1994 *************** *** 0 **** --- 1,32 ---- + /* Configuration for GCC for Intel i386 running VSTa + Copyright (C) 1993, 1994 Free Software Foundation, Inc. + + (inspired from Linux config.) + + This file is part of GNU CC. + + GNU CC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GNU CC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU CC; see the file COPYING. If not, write to + the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ + + #include "i386/xm-i386.h" + + #undef BSTRING + #define BSTRING + #undef bcmp + #undef bcopy + #undef bzero + #undef index + #undef rindex + + #define HAVE_VPRINTF diff -P -r -C 3 /home/rosser/basile/mimas.tmp/gcc-2.6.1/config.sub gcc-2.6.1-vsta/config.sub *** /home/rosser/basile/mimas.tmp/gcc-2.6.1/config.sub Wed Oct 26 19:23:05 1994 --- gcc-2.6.1-vsta/config.sub Tue Nov 8 20:47:21 1994 *************** *** 4,28 **** # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software # can handle that machine. It does not imply ALL GNU software can. ! # ! # This file is free software; you can redistribute it and/or modify ! # it under the terms of the GNU General Public License as published by ! # the Free Software Foundation; either version 2 of the License, or ! # (at your option) any later version. ! # ! # This program is distributed in the hope that it will be useful, ! # but WITHOUT ANY WARRANTY; without even the implied warranty of ! # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ! # GNU General Public License for more details. ! # ! # You should have received a copy of the GNU General Public License ! # along with this program; if not, write to the Free Software ! # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ! ! # As a special exception to the GNU General Public License, if you ! # distribute this file as part of a program that contains a ! # configuration script generated by Autoconf, you may include it under ! # the same distribution terms that you use for the rest of that program. # Configuration subroutine to validate and canonicalize a configuration type. # Supply the specified configuration type as an argument. --- 4,24 ---- # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software # can handle that machine. It does not imply ALL GNU software can. ! ! #This file is free software; you can redistribute it and/or modify ! #it under the terms of the GNU General Public License as published by ! #the Free Software Foundation; either version 2 of the License, or ! #(at your option) any later version. ! ! #This program is distributed in the hope that it will be useful, ! #but WITHOUT ANY WARRANTY; without even the implied warranty of ! #MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ! #GNU General Public License for more details. ! ! #You should have received a copy of the GNU General Public License ! #along with this program; if not, write to the Free Software ! #Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ! # Configuration subroutine to validate and canonicalize a configuration type. # Supply the specified configuration type as an argument. *************** *** 42,47 **** --- 38,52 ---- # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # It is wrong to echo any other type of specification. + if [ x$1 = x ] # CYGNUS LOCAL + then + echo Configuration name missing. 1>&2 + echo "Usage: $0 CPU-MFR-OPSYS" 1>&2 + echo "or $0 ALIAS" 1>&2 + echo where ALIAS is a recognized configuration type. 1>&2 + exit 1 + fi + # First pass through any local machine types. case $1 in *local*) *************** *** 71,80 **** -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \ -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\ -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \ ! -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp ) os= basic_machine=$1 ;; -hiux*) os=-hiuxwe2 ;; --- 76,96 ---- -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \ -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\ -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \ ! -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \ ! -sim | -cisco | -oki | -wec | -winbond ) # CYGNUS LOCAL os= basic_machine=$1 ;; + -scout) # CYGNUS LOCAL + ;; + -wrs) # CYGNUS LOCAL + os=vxworks + basic_machine=$1 + ;; + -unixware) # CYGNUS LOCAL + os=-sysv4 + basic_machine=`echo $1 | sed -e 's/86-.*/86-unknown/'` + ;; -hiux*) os=-hiuxwe2 ;; *************** *** 104,118 **** -isc*) basic_machine=`echo $1 | sed -e 's/86-.*/86-unknown/'` ;; ! -lynx) os=-lynxos ;; -ptx*) basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'` ;; - -windowsnt*) - os=`echo $os | sed -e 's/windowsnt/winnt/'` - ;; esac # Decode aliases for certain CPU-COMPANY combinations. --- 120,131 ---- -isc*) basic_machine=`echo $1 | sed -e 's/86-.*/86-unknown/'` ;; ! -lynx*) # CYGNUS LOCAL: lynx os=-lynxos ;; -ptx*) basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'` ;; esac # Decode aliases for certain CPU-COMPANY combinations. *************** *** 123,129 **** | tron | a29k | 580 | i960 | h8300 | hppa1.0 | hppa1.1 \ | alpha | we32k | ns16k | clipper | sparclite | i370 | sh \ | powerpc | sparc64 | 1750a | dsp16xx | mips64 | mipsel \ ! | pdp11 | mips64el | mips64orion | mips64orionel ) basic_machine=$basic_machine-unknown ;; # Object if more than one company name word. --- 136,144 ---- | tron | a29k | 580 | i960 | h8300 | hppa1.0 | hppa1.1 \ | alpha | we32k | ns16k | clipper | sparclite | i370 | sh \ | powerpc | sparc64 | 1750a | dsp16xx | mips64 | mipsel \ ! | mips64el | mips64orion | mips64orionel \ ! | m88110 | sparc | m680[01234]0 | m683?2 | z8k | v70 \ ! | h8500) # CYGNUS LOCAL basic_machine=$basic_machine-unknown ;; # Object if more than one company name word. *************** *** 138,154 **** | none-* | 580-* | cray2-* | h8300-* | i960-* | xmp-* | ymp-* \ | hppa1.0-* | hppa1.1-* | alpha-* | we32k-* | cydra-* | ns16k-* \ | pn-* | np1-* | xps100-* | clipper-* | orion-* | sparclite-* \ ! | pdp11-* | sh-* | powerpc-* | sparc64-* | mips64-* | mipsel-* \ ! | mips64el-* | mips64orion-* | mips64orionel-* ) ;; # Recognize the various machine names and aliases which stand # for a CPU type and a company and sometimes even an OS. 3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc) basic_machine=m68000-att ;; 3b*) basic_machine=we32k-att ;; alliant | fx80) basic_machine=fx80-alliant ;; --- 153,183 ---- | none-* | 580-* | cray2-* | h8300-* | i960-* | xmp-* | ymp-* \ | hppa1.0-* | hppa1.1-* | alpha-* | we32k-* | cydra-* | ns16k-* \ | pn-* | np1-* | xps100-* | clipper-* | orion-* | sparclite-* \ ! | sh-* | powerpc-* | sparc64-* | mips64-* | mipsel-* \ ! | mips64el-* | mips64orion-* | mips64orionel-* \ ! | m88110-* | m680[01234]0-* | m683?2-* | z8k-* \ ! | h8500-* ) # CYGNUS LOCAL ;; # Recognize the various machine names and aliases which stand # for a CPU type and a company and sometimes even an OS. + 386bsd) # CYGNUS LOCAL + basic_machine=i386-unknown + os=-bsd + ;; 3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc) basic_machine=m68000-att ;; 3b*) basic_machine=we32k-att ;; + a29khif) # CYGNUS LOCAL + basic_machine=a29k-amd + os=-udi + ;; + adobe68k) # CYGNUS LOCAL + basic_machine=m68010-adobe + os=-scout + ;; alliant | fx80) basic_machine=fx80-alliant ;; *************** *** 178,183 **** --- 207,216 ---- basic_machine=m68k-apollo os=-sysv ;; + apollo68bsd) # CYGNUS LOCAL + basic_machine=m68k-apollo + os=-bsd + ;; balance) basic_machine=ns32k-sequent os=-dynix *************** *** 246,251 **** --- 279,288 ---- encore | umax | mmax) basic_machine=ns32k-encore ;; + es1800 | OSE68k | ose68k | ose | OSE) # CYGNUS LOCAL + basic_machine=m68k-ericsson + os=-ose + ;; fx2800) basic_machine=i860-alliant ;; *************** *** 260,267 **** basic_machine=hppa1.1-hitachi os=-hiuxwe2 ;; ! h8300hms) basic_machine=h8300-hitachi os=-hms ;; harris) --- 297,316 ---- basic_machine=hppa1.1-hitachi os=-hiuxwe2 ;; ! h8300hds) basic_machine=h8300-hitachi + os=-hds + ;; + h8300hms) # CYGNUS LOCAL + basic_machine=h8300-hitachi + os=-hms + ;; + h8300xray) # CYGNUS LOCAL + basic_machine=h8300-hitachi + os=-xray + ;; + h8500hms) # CYGNUS LOCAL + basic_machine=h8500-hitachi os=-hms ;; harris) *************** *** 279,284 **** --- 328,349 ---- basic_machine=m68k-hp os=-hpux ;; + w89k-*) # CYGNUS LOCAL + basic_machine=hppa1.1-winbond + os=-proelf + ;; + op50n-*) # CYGNUS LOCAL + basic_machine=hppa1.1-oki + os=-proelf + ;; + op60c-*) # CYGNUS LOCAL + basic_machine=hppa1.1-oki + os=-proelf + ;; + hppro) # CYGNUS LOCAL + basic_machine=hppa1.1-hp + os=-proelf + ;; hp9k2[0-9][0-9] | hp9k31[0-9]) basic_machine=m68000-hp ;; *************** *** 291,296 **** --- 356,365 ---- hp9k8[0-9][0-9] | hp8[0-9][0-9]) basic_machine=hppa1.0-hp ;; + hppaosf) + basic_machine=hppa1.1-hp + os=-osf + ;; i370-ibm* | ibm*) basic_machine=i370-ibm os=-mvs *************** *** 312,318 **** basic_machine=`echo $1 | sed -e 's/86.*/86-unknown/'` os=-solaris2 ;; ! iris | iris4d) basic_machine=mips-sgi case $os in -irix*) --- 381,412 ---- basic_machine=`echo $1 | sed -e 's/86.*/86-unknown/'` os=-solaris2 ;; ! i386mach) # CYGNUS LOCAL ! basic_machine=i386-mach ! os=-mach ! ;; ! i386-vsta | vsta) # CYGNUS LOCAL ! basic_machine=i386-unknown ! os=-vsta ! ;; ! i386-go32 | go32) # CYGNUS LOCAL ! basic_machine=i386-unknown ! os=-go32 ! ;; ! i386-linux* | linux) # CYGNUS LOCAL ! basic_machine=i386-unknown ! os=-linux ! ;; ! i386-linux*coff | linuxcoff) # CYGNUS LOCAL ! basic_machine=i386-unknown ! os=-linuxcoff ! ;; ! i386-linux*elf | linuxelf) # CYGNUS LOCAL ! basic_machine=i386-unknown ! os=-linuxelf ! ;; ! iris | iris4d | \ ! iris3 | iris4) # CYGNUS LOCAL basic_machine=mips-sgi case $os in -irix*) *************** *** 346,355 **** --- 440,461 ---- mips3*) basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown ;; + monitor) # CYGNUS LOCAL + basic_machine=m68k-rom68k + os=-coff + ;; + msdos) # CYGNUS LOCAL + basic_machine=i386-unknown + os=-msdos + ;; ncr3000) basic_machine=i486-ncr os=-sysv4 ;; + netbsd386) + basic_machine=i386-unknown # CYGNUS LOCAL + os=-netbsd + ;; news | news700 | news800 | news900) basic_machine=m68k-sony os=-newsos *************** *** 362,367 **** --- 468,477 ---- basic_machine=mips-sony os=-newsos ;; + necv70) # CYGNUS LOCAL + basic_machine=v70-nec + os=-sysv + ;; next | m*-next ) basic_machine=m68k-next case $os in *************** *** 390,395 **** --- 500,513 ---- np1) basic_machine=np1-gould ;; + OSE68000 | ose68000) # CYGNUS LOCAL + basic_machine=m68000-ericsson + os=-ose + ;; + os68k) # CYGNUS LOCAL + basic_machine=m68k-none + os=-os68k + ;; pa-hitachi) basic_machine=hppa1.1-hitachi os=-hiuxwe2 *************** *** 418,426 **** --- 536,552 ---- ps2) basic_machine=i386-ibm ;; + rom68k) # CYGNUS LOCAL + basic_machine=m68k-rom68k + os=-coff + ;; rtpc | rtpc-*) basic_machine=romp-ibm ;; + sa29200) # CYGNUS LOCAL + basic_machine=a29k-amd + os=-udi + ;; sequent) basic_machine=i386-sequent ;; *************** *** 428,433 **** --- 554,577 ---- basic_machine=sh-hitachi os=-hms ;; + sparclite-wrs) # CYGNUS LOCAL + basic_machine=sparclite-wrs + os=-vxworks + ;; + sparcfrw) # CYGNUS LOCAL + basic_machine=sparcfrw-sun + os=-sunos4 + ;; + sparcfrwcompat) # CYGNUS LOCAL + basic_machine=sparcfrwcompat-sun + os=-sunos4 + ;; + sparclitefrw) # CYGNUS LOCAL + basic_machine=sparclitefrw-fujitsu + ;; + sparclitefrwcompat) # CYGNUS LOCAL + basic_machine=sparclitefrwcompat-fujitsu + ;; sps7) basic_machine=m68k-bull os=-sysv2 *************** *** 435,440 **** --- 579,591 ---- spur) basic_machine=spur-unknown ;; + st2000) # CYGNUS LOCAL + basic_machine=m68k-tandem + ;; + stratus) # CYGNUS LOCAL + basic_machine=i860-stratus + os=-sysv4 + ;; sun2) basic_machine=m68000-sun ;; *************** *** 462,467 **** --- 613,622 ---- basic_machine=sparc-sun os=-sunos4 ;; + sun4sol2) # CYGNUS LOCAL + basic_machine=sparc-sun + os=-solaris2 + ;; sun3 | sun3-*) basic_machine=m68k-sun ;; *************** *** 478,487 **** --- 633,654 ---- tower | tower-32) basic_machine=m68k-ncr ;; + udi29k) # CYGNUS LOCAL + basic_machine=a29k-amd + os=-udi + ;; ultra3) basic_machine=a29k-nyu os=-sym1 ;; + unixware) # CYGNUS LOCAL + os=-sysv4 + basic_machine=i386-unknown + ;; + v810 | necv810) + basic_machine=v810-nec + os=-none + ;; vaxv) basic_machine=vax-dec os=-sysv *************** *** 505,510 **** --- 672,681 ---- xps | xps100) basic_machine=xps100-honeywell ;; + z8ksim) # CYGNUS LOCAL + basic_machine=z8k-unknown + os=-sim + ;; none) basic_machine=none-none os=-none *************** *** 512,517 **** --- 683,697 ---- # Here we handle the default manufacturer of certain CPU types. It is in # some cases the only manufacturer, in others, it is the most popular. + w89k) # CYGNUS LOCAL + basic_machine=hppa1.1-winbond + ;; + op50n) # CYGNUS LOCAL + basic_machine=hppa1.1-oki + ;; + op60c) # CYGNUS LOCAL + basic_machine=hppa1.1-oki + ;; mips) basic_machine=mips-mips ;; *************** *** 524,532 **** vax) basic_machine=vax-dec ;; - pdp11) - basic_machine=pdp11-dec - ;; we32k) basic_machine=we32k-att ;; --- 704,709 ---- *************** *** 572,580 **** -solaris) os=-solaris2 ;; - -gnu/linux*) - os=`echo $os | sed -e 's|gnu/linux|linux|'` - ;; # First accept the basic system types. # The portable systems comes first. # Each alternative must end in a *, to match a version number. --- 749,754 ---- *************** *** 587,593 **** | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \ | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix* \ | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* \ ! | -ptx* | -coff* | -winnt*) ;; -sunos5*) os=`echo $os | sed -e 's|sunos5|solaris2|'` --- 761,771 ---- | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \ | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix* \ | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* \ ! | -ptx* \ ! | -go32 | -vsta | -sim | -es1800* | -udi | -hms* | -xray | -hds* \ ! | -os68k* | -none* | -v88r* | -coff \ ! | -abug | -ecoff* | -netware* | -proelf | -os9* ) ! # The last three lines above are CYGNUS LOCAL ;; -sunos5*) os=`echo $os | sed -e 's|sunos5|solaris2|'` *************** *** 610,615 **** --- 788,796 ---- -acis*) os=-aos ;; + -386bsd) # CYGNUS LOCAL + os=-bsd + ;; -ctix* | -uts*) os=-sysv ;; *************** *** 622,627 **** --- 803,811 ---- -svr4) os=-sysv4 ;; + -unixware) # CYGNUS LOCAL + os=-sysv4 + ;; -svr3) os=-sysv3 ;; *************** *** 631,636 **** --- 815,826 ---- # This must come after -sysvr4. -sysv*) ;; + -ose*) # CYGNUS LOCAL + os=-ose + ;; + -es1800*) # CYGNUS LOCAL + os=-ose + ;; -xenix) os=-xenix ;; *************** *** 659,667 **** *-acorn) os=-riscix1.2 ;; - pdp11-*) - os=-none - ;; *-dec | vax-*) os=-ultrix4.2 ;; --- 849,854 ---- *************** *** 674,679 **** --- 861,872 ---- # default. # os=-sunos4 ;; + m68*-cisco) + os=-aout + ;; + mips*-cisco) + os=-elf + ;; *-tti) # must be before sparc entry or we get the wrong os. os=-sysv3 ;; *************** *** 683,688 **** --- 876,890 ---- *-ibm) os=-aix ;; + *-wec) # CYGNUS LOCAL + os=-proelf + ;; + *-winbond) # CYGNUS LOCAL + os=-proelf + ;; + *-oki) # CYGNUS LOCAL + os=-proelf + ;; *-hp) os=-hpux ;; *************** *** 737,742 **** --- 939,950 ---- *-masscomp) os=-rtu ;; + *-rom68k) # CYGNUS LOCAL + os=-coff + ;; + *-*bug) # CYGNUS LOCAL + os=-coff + ;; *) os=-none ;; *************** *** 755,760 **** --- 963,971 ---- -sunos*) vendor=sun ;; + -bosx*) # CYGNUS LOCAL + vendor=bull + ;; -lynxos*) vendor=lynx ;; *************** *** 784,789 **** --- 995,1006 ---- ;; -ptx*) vendor=sequent + ;; + -vxworks*) + vendor=wrs # CYGNUS LOCAL + ;; + -hms*) # CYGNUS LOCAL + vendor=hitachi ;; esac basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"` diff -P -r -C 3 /home/rosser/basile/mimas.tmp/gcc-2.6.1/configure gcc-2.6.1-vsta/configure *** /home/rosser/basile/mimas.tmp/gcc-2.6.1/configure Thu Oct 27 18:15:04 1994 --- gcc-2.6.1-vsta/configure Tue Nov 8 21:37:41 1994 *************** *** 803,808 **** --- 803,816 ---- fixincludes=Makefile.in #On Linux, the headers are ok already. broken_install=yes ;; + i[345]86-*-vsta*) # Intel 80386's running VSTa microkernel + cpu_type=i386 + xm_file=i386/xm-vsta.h + xmake_file=i386/x-vsta + tm_file=i386/vsta.h + fixincludes=Makefile.in + broken_install=yes + ;; i[345]86-*-lynxos*) cpu_type=i386 if [ x$gas = xyes ] -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Nov 9 04:08:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA01151; Wed, 9 Nov 1994 04:08:04 -0800 Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu [128.223.4.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA18698 for ; Wed, 9 Nov 1994 04:29:03 -0800 From: cogswell@sisters.cs.uoregon.edu Received: from sisters.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA13913 (5.65/IDA-1.4.2 for vsta@cisco.com); Wed, 9 Nov 94 04:29:01 -0800 Received: by sisters.cs.uoregon.edu (5.61/UofO CS 27-Mar-91) id AA29818; Wed, 9 Nov 94 04:28:59 -0800 Date: Wed, 9 Nov 94 04:28:59 -0800 Message-Id: <9411091228.AA29818@sisters.cs.uoregon.edu> To: vsta@cisco.com Subject: notify problem? Cc: cogswell@skinner.cs.uoregon.edu I just installed VSTa yesterday in the hopes of using it for a research project for my thesis. In the hopes of getting a feel for the performance of the system I wrote the program attached below. The program just starts up a pair of processes, and the processes take turns sleeping, then being woken by a notify from the other process. I'm basically trying to measure context switch speed. The problem is I get a stack-overflow error, which dumps me into the kernel debugger, virtually every time I try to run the program. Except for some occasional hangs during booting, the system seems really stable, so I'm at a bit of a loss as to why I'm having trouble here. Couple other questions: How many people are currently using VSTa? When will the mailing list digest next be updated on ftp.cisco.com? -- Bryce #include #include #include #include #include #include extern int notify( pid_t pid, pid_t tid, char * ev ); void event_handler( char * msg ) { } void go( int cnt, int id, pid_t him ) { if ( id ) sleep( 1 ); while ( --cnt >= 0 ) { notify( him, 0, "go" ); sleep( 1 ); } } int main( int argc, char * argv[] ) { int cnt = argc == 2 ? atoi( argv[1] ) : 0; struct time start, finish; int delta; int pid; if ( cnt < 1 ) { fprintf( stderr, "usage: %s \n", argv[0] ); return 1; } notify_handler( event_handler ); pid = fork(); time_get( &start ); if ( pid ) go( cnt, 0, pid ); /* parent */ else go( cnt, 1, getppid() ); /* child */ time_get( &finish ); delta = 1000000*(finish.t_sec - start.t_sec) + (finish.t_usec - start.t_usec); printf( "time = %d usec = %d usec/switch\n", delta, delta/cnt ); return 0; } From vandys@glare.cisco.com Wed Nov 9 07:57:06 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01176; Wed, 9 Nov 1994 07:56:58 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA16251 for ; Wed, 9 Nov 1994 08:17:56 -0800 Message-Id: <199411091617.IAA16251@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol Date: Wed, 09 Nov 1994 08:17:53 -0800 From: Andrew Valencia Subject: FAQ alpha Apparently-To: ------- Blind-Carbon-Copy To: vandys Subject: FAQ alpha Date: Wed, 09 Nov 1994 08:17:53 -0800 From: Andrew Valencia Here's the alpha version of the VSTa FAQ. Feel free to mail me suggestions on where it can be improved. Regards, Andy v0.2 FAQ for VSTa: Frequently Asked Questions About VSTa 1. What is VSTa? VSTa is a copylefted operating system created by Andy Valencia (vandys@cisco.com) and later enhanced by numerous others. It uses a microkernel organization, in which the "kernel" code is very small (~40k) and all filesystems and drivers reside in "user" mode processes. At user level it looks substantially like a POSIX-type system. 2. What does "VSTa" stand for The "Valencia Simple Tasker". Actually, the 40K in the kernel suports kernel preemption, shared memory MIMD multiprocessors, and virtual memory. It really isn't all that simple! 3. What does VSTa run on? VSTa was originally written for the i386 PC. It has since run on 2 meg 386sx processors and 16 meg Pentium processors. The DMA system currently does not correctly support > 16 meg ISA bus access. Most of the code is there (bounce buffers and such) but it is not completely implemented. VSTa has driver support for ST-506, IDE, and Adaptec 1542[bc] disk interfaces. It supports floppy drives, MGA and CGA monitors, RS-232 interfaces, parallel interfaces, NE2000 LAN cards, and bus or serial mice. Under SCSI, it also supports CDROM. VSTa has a port to the Amiga with 68030 in progress. At last status report the kernel would boot and run simple tasks, and interrupt handling was being brought up next. VSTa has people looking at ports to R3000's and SPARC's. No bootable code has been reported yet. 4. How do I get VSTa? Cygnus has kindly made some space available at their FTP site: ftp.cygnus.com:pub/embedded/vsta Cisco also has it available, although their FTP daemon makes it more of a chore: ftp.cisco.com:vandys/vsta Other mirror sites exist and will be added here as verified. 5. How do I boot it? See the file vsta_*.readme on the FTP site. This will point you to the files "license" and "readme" in the vsta.tz compressed archive. These provide information on the terms and conditions for use of VSTa. Then it points you to doc/roadmap.txt in the same archive, which tells you how to boot up the system. 6. Ok, I booted it, but how do I find out more about its design? The FTP sites hold an aging introduction paper. The mailing list archives at the FTP sites contain several messages which describe the design of various parts (booting, VM, scheduling, ...) of the system. If you are searching for a particular topic, a hypertext index: http://ftoomsh.socs.uts.EDU.AU/mlists/vsta provides a powerful interface for searching all message list traffic. The doc/ subdirectory holds a skeletal amount of documentation on the basic kernel interfaces. More will be added (time permitting :->). Finally, the code itself has relatively consistent and numerous comments. 6. I created a root user, but nothing works for me! The protection system uses your ID for the default protection on object creation. You should specify a non-zero length ID, and add a root ID as one of the "extra" ones. See the file /vsta/etc/group. 7. I boot up, and see the disk blink, but my screen doesn't show anything The default in boot/boot.lst is for a CGA system. MGA cards place text at a different address; add the -mga flag to the "cons" server. The kernel debugger also needs to be flagged this way; you need to edit the file os/mach/dbg_ibm.c and then rebuild your kernel. 8. Does it network? An initial port of KA9Q has been done. It uses the ne2000 driver and can be used to telnet and FTP. Some code has been written to provide a /tcp server so that, for instance, a telnetd can be run to allow logins via the net. 9. What's being developed for VSTa? Ports are in various states of progress for the m68k, R3000, and SPARC. People are working on a windowing system, a Linux filesystem, a BSD filesystem, a /proc filesystem, more networking. For SCSI, tape support is in progress. A list, maintained by Gavin Nicol (gtn@ebt.com) is posted to the mailing list periodically. 10. What list is that? We run a VSTa mailing list. Send a subscription request to: vsta-request@cisco.com There's no list server, so feel free to use English. Once you're on the list, send to: vsta@cisco.com and the message will be distributed to all members. A digest format is available; specify this in your subscription request if you prefer it. Our digest algorithm is to wait up to three days to collect three messages. ------- End of Blind-Carbon-Copy From vandys@glare.cisco.com Wed Nov 9 09:15:06 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01194; Wed, 9 Nov 1994 09:15:03 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA19519; Wed, 9 Nov 1994 09:36:01 -0800 Message-Id: <199411091736.JAA19519@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: cogswell@sisters.cs.uoregon.edu Cc: vsta@cisco.com, cogswell@skinner.cs.uoregon.edu Subject: Re: notify problem? In-Reply-To: Your message of "Wed, 09 Nov 1994 04:28:59 PST." <9411091228.AA29818@sisters.cs.uoregon.edu> Date: Wed, 09 Nov 1994 09:36:01 -0800 From: Andrew Valencia [cogswell@sisters.cs.uoregon.edu writes:] >... >void go( int cnt, int id, pid_t him ) >{ > if ( id ) > sleep( 1 ); You should try: if (id) { for (;;) { sleep(10000); } } I believe the sleep is being interrupted after the first signal and then he's dropping down into the other side of the code. I just tried something like this and the stack does appear to be reset correctly on completion of each event handler. Regards, Andy From vandys@glare.cisco.com Wed Nov 9 10:57:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01217; Wed, 9 Nov 1994 10:57:51 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA06979 for ; Wed, 9 Nov 1994 11:18:52 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id MAA04146 for ; Wed, 9 Nov 1994 12:18:04 -0700 Message-Id: <199411091918.MAA04146@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: www archive? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <4132.784408681.1@xmission.xmission.com> Date: Wed, 09 Nov 1994 12:18:02 -0700 From: Gary Shea Someone said something about a www archive of the mailing list? Is that so? Where is it? I've never heard about a readily-usable archive, but it would save me lots of disk space :) Gary From vandys@glare.cisco.com Wed Nov 9 11:22:29 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01220; Wed, 9 Nov 1994 11:22:25 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA08435 for ; Wed, 9 Nov 1994 11:43:25 -0800 Received: from rtl.cygnus.com (rtl.cygnus.com [140.174.1.2]) by cygnus.com (8.6.9/8.6.9) with ESMTP id LAA05563; Wed, 9 Nov 1994 11:43:19 -0800 Received: (rob@localhost) by rtl.cygnus.com (8.6.9/8.6.4) id LAA18785; Wed, 9 Nov 1994 11:43:18 -0800 Message-Id: <199411091943.LAA18785@rtl.cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Wed, 9 Nov 1994 11:43:18 PST In-Reply-To: Basile STARYNKEVITCH ' <9411090852.AA01197@rosser.serma.cea.fr> patches for GCC 2.6.1 under VSTa. Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Basile STARYNKEVITCH , vsta@cisco.com Subject: Re: patches for GCC 2.6.1 under VSTa. From: Basile STARYNKEVITCH Subject: patches for GCC 2.6.1 under VSTa. > The resulting patches (to apply to GNU 2.6.1 distribution) follows. > Please, test them and improve them. Once they are ok, I hope Andy > could post them to GNU, to be added for the 2.6.2 GNU distribution I'm a touch confused. This looks like that patch we put out on the crossgcc mailing list. The patch we made for GCC 2.6.1 is at ftp.cygnus.com: pub/embedded and it also adds VSTa support. I'm working right now on getting it into the FSF GCC sources, I already added it to binutils, GAS, and LD. This looks different slightly than mine, was it new or is it bug fixes ? (maybe I need more coffee this morning...) Anyway, I'm looking at it, and it I'll merge the changes that look tight into our source tree. I'm on the road, anybody able to test the patches ? - rob - From vandys@glare.cisco.com Wed Nov 9 19:08:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01259; Wed, 9 Nov 1994 19:08:10 -0800 Received: from skinner.cs.uoregon.edu (skinner.cs.uoregon.edu [128.223.4.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA00896 for ; Wed, 9 Nov 1994 19:29:12 -0800 From: cogswell@sisters.cs.uoregon.edu Received: from sisters.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP id AA24921 (5.65/IDA-1.4.2 for vsta@cisco.com); Wed, 9 Nov 94 19:29:05 -0800 Received: by sisters.cs.uoregon.edu (5.61/UofO CS 27-Mar-91) id AA07276; Wed, 9 Nov 94 19:29:03 -0800 Date: Wed, 9 Nov 94 19:29:03 -0800 Message-Id: <9411100329.AA07276@sisters.cs.uoregon.edu> To: vsta@cisco.com Subject: more notify problems I'm still having trouble with VSTa crashing when I try to use notify(). Its not clear to me whether this is a general problem or specific to my hardware. I find that VSTa crashes about 10% of the time when I boot it, simply hanging at the login prompt. It also tends to mysteriously hang maybe once an hour, even if I'm not running jobs. What is typical behavior for other people? I've attached a sample program using notify() below. Without the write() call it runs okay. With the write() it often triggers the ASSERT_DEBUG(pr->p_port == port, "msg_receive: DISC pr mismatch"); assertion (line 600) in msg.c, or sometimes the ASSERT_DEBUG(port->p_hd, "msg_receive: p_wait/p_hd disagree"); assertion (line 530) in the same function. Is this a common/well-understood problem? -- Bryce #include #include void event_handler( char * msg ) { } int main( void ) { int pid; notify_handler( event_handler ); if ( pid = fork() ) { write( 1, "hello\n", 6 ); waitpid( pid, NULL, 0 ); } else { notify( getppid(), 0, "go" ); } return 0; } From vandys@glare.cisco.com Wed Nov 9 19:57:55 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01270; Wed, 9 Nov 1994 19:57:51 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA25729; Wed, 9 Nov 1994 20:18:53 -0800 Message-Id: <199411100418.UAA25729@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: cogswell@sisters.cs.uoregon.edu Cc: vsta@cisco.com Subject: Re: more notify problems In-Reply-To: Your message of "Wed, 09 Nov 1994 19:29:03 PST." <9411100329.AA07276@sisters.cs.uoregon.edu> Date: Wed, 09 Nov 1994 20:18:52 -0800 From: Andrew Valencia [cogswell@sisters.cs.uoregon.edu writes:] >I find that VSTa crashes about 10% of the time when I boot it, >simply hanging at the login prompt. It also tends to mysteriously >hang maybe once an hour, even if I'm not running jobs. What is >typical behavior for other people? I've seen this, but only on my wife's laptop with some sort of power management scheme. The manufacturer won't tell me what it's doing. What kind of machine is yours? >I've attached a sample program using notify() below. Without the >write() call it runs okay. With the write() it often triggers the > ASSERT_DEBUG(pr->p_port == port, "msg_receive: DISC pr mismatch"); >assertion (line 600) in msg.c, or sometimes the > ASSERT_DEBUG(port->p_hd, "msg_receive: p_wait/p_hd disagree"); >assertion (line 530) in the same function. Wow! Looks like you found a new (yet simple) way to stress the messaging engine. I'll play with this, assuming it causes problems on my own machine. Andy From vandys@glare.cisco.com Thu Nov 10 00:37:05 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA01300; Thu, 10 Nov 1994 00:36:58 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA22845 for ; Thu, 10 Nov 1994 00:57:55 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 10 Nov 94 09:56:22+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 10 Nov 94 09:56:51-0100 Date: 10 Nov 94 09:56:51-0100 From: Basile STARYNKEVITCH Message-Id: <9411100856.AA00680@rosser.serma.cea.fr> To: rob@cygnus.com Cc: vsta@cisco.com In-Reply-To: <199411091943.LAA18785@rtl.cygnus.com> Subject: forget about my patches for GCC 2.6.1 under VSTa. Content-Length: 3335 >>>>> "Rob" == Rob Savoye writes: Rob> From: Basile STARYNKEVITCH Rob> Subject: patches for GCC 2.6.1 Rob> under VSTa. >> The resulting patches (to apply to GNU 2.6.1 distribution) >> follows. Please, test them and improve them. Once they are ok, >> I hope Andy could post them to GNU, to be added for the 2.6.2 >> GNU distribution Rob> I'm a touch confused. This looks like that patch we put out Rob> on the crossgcc mailing list. The patch we made for GCC 2.6.1 Rob> is at ftp.cygnus.com: pub/embedded and it also adds VSTa Rob> support. I'm working right now on getting it into the FSF GCC Rob> sources, I already added it to binutils, GAS, and LD. This Rob> looks different slightly than mine, was it new or is it bug Rob> fixes ? (maybe I need more coffee this morning...) Anyway, Rob> I'm looking at it, and it I'll merge the changes that look Rob> tight into our source tree. I'm on the road, anybody able to Rob> test the patches ? Sorry, i didn't know about the existing patch on ftp.cygnus.com (an ftp server i didn't know about). I'm glad patches of GCC 2.6.1 for VSTa already exist. My patches were nearly untested (I hacked them in one evening, and i don't know much about VSTa or GCC internals), and other patches are porbably better. My FSF sources are from prep.ai.mit.edu:/pub/gnu and its mirrors (eg ftp.ibp.fr in France). I'm suprised that GNU distribution of binutils-2.5.2 mentions (and supports and knows about) VSTa, while GNU distribution of gcc-2.6.1 don't mention VSTa. Why? Shouldn't the GNU distribution of GCC support VSTa? (Or perhaps i was tired last evening to the point that i didn't find an existing VSTa support in gcc 2.6.1, although I think i did try a grep -i vsta **/* [on zsh, where ** is a recursive *] on it). Again, my apologies to every one. I'm just a novice on VSTa and quite enthusiastic about it. Sorry for having wasted bandwidth! My patches are nearly untested, so do take the ftp.cygnus.com:/pub/embedded/crossgcc-2.6.1.patch.gz patch instead). Also, I'm VSTa-ling and Linux-ing at home only, where i don't have any network access. Sadly, my PC is standalone. To summarize, i didn't know about exisiting patches for gcc-2.6.1 for VSTa. The patches i've send are hacked in one evening and not really tested; as I said in their posting, the gcc compilation was unfinished (because i had to shut my home PC down to let a guest sleep in silence in the room containing my PC). And i haven't time to restart it yet. So please look at ftp.cygnus.com:/pub/embedded/crossgcc-2.6.1.patch.gz instead of my patches. (of course, i didn't test them yet but cygnus people knows a lot more than me about GCC and about VSTa). -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Thu Nov 10 06:38:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA01442; Thu, 10 Nov 1994 06:38:38 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id GAA27844 for ; Thu, 10 Nov 1994 06:59:43 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id HAA27195 for ; Thu, 10 Nov 1994 07:59:01 -0700 Message-Id: <199411101459.HAA27195@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: Re: more notify problems In-Reply-To: Your message of "Wed, 09 Nov 1994 19:29:03 PST." <9411100329.AA07276@sisters.cs.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <27189.784479539.1@xmission.xmission.com> Date: Thu, 10 Nov 1994 07:59:00 -0700 From: Gary Shea cogswell@sisters.cs.uoregon.edu writes: >I'm still having trouble with VSTa crashing when I try to use notify(). >Its not clear to me whether this is a general problem or specific to >my hardware. > >I find that VSTa crashes about 10% of the time when I boot it, >simply hanging at the login prompt. It also tends to mysteriously >hang maybe once an hour, even if I'm not running jobs. What is >typical behavior for other people? This is typical for me, also. When I build, the system dies at (seemingly) random times; when I compile it falls into the debugger fairly often, but then exiting the debugger brings me back to a normal state; often the login prompt never shows after a boot. I guess this is part of the fun of a new system :) Gary From vandys@glare.cisco.com Thu Nov 10 07:35:09 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01456; Thu, 10 Nov 1994 07:35:05 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id HAA17148; Thu, 10 Nov 1994 07:56:10 -0800 Message-Id: <199411101556.HAA17148@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: more notify problems In-Reply-To: Your message of "Thu, 10 Nov 1994 07:59:00 MST." <199411101459.HAA27195@xmission.xmission.com> Date: Thu, 10 Nov 1994 07:56:10 -0800 From: Andrew Valencia [Gary Shea writes:] >This is typical for me, also. When I build, the system dies >at (seemingly) random times; when I compile it falls into the >debugger fairly often, but then exiting the debugger brings me >back to a normal state; often the login prompt never shows >after a boot. I guess this is part of the fun of a new system :) Is your machine a laptop? When it drops into the debugger, could you do a "tf" and forward that along to me? None of this happens here, so this is the only way I can hunt it down. How much RAM does your system have? I already posted a warning about building the shared libraries--tmpfs uses a LOT of RAM consuming one 8K block per global C library entry point. Andy From vandys@glare.cisco.com Thu Nov 10 09:33:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01504; Thu, 10 Nov 1994 09:33:56 -0800 Received: from ftp.std.com (ftp.std.com [192.74.137.7]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA06018 for ; Thu, 10 Nov 1994 09:55:03 -0800 Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id MAA26017; Thu, 10 Nov 1994 12:53:30 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA06239; Thu, 10 Nov 1994 12:53:43 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199411101753.AA06239@world.std.com> Subject: SCSI tape stat info To: vsta@cisco.com Date: Thu, 10 Nov 1994 12:53:42 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2871 Hi, Below are some notes on SCSI device names and tape commands. This information will eventually a part of the SCSI document, but for now I'm going to use it as a specification for writing the SCSI tape stat/wstat interface. Please feel free to comment. Mike Larson Device Names ------------ Device names composed of an optional device prefix letter followed by a 2 letter device ID followed by address ID followed by an optional '_' and device specific parameter string. device prefix letter - "n" for no-rewind tapes device ID - "sd" for hard disks and magneto- optical disks, "sr" for CDROM drives, and "st" for tapes. device address - BUS/TARGET/LUN identifier (see below). device specific - optinal string that encodes parameters specific to a device or a mode that the device supports (see below). The device ID has the following structure: BBTT[L], where B = BUS, T = TARGET, L = optional LUN designator (a = LUN 0, b = LUN 1, etc.), leading 0's are stripped. For example, st4 is the tape unit at BUS 0, TARGET 4, LUN 0 and st104b is the tape unit at BUS 1, TARGET 4, LUN 1. The device specific string is used as follows: for "sd" devices, the device specific string is a partition type name (eg., "dos") followed by a partition index (0 to number of partitions minus 1). For "st" devices, device specific string is an optional mode selector (tape modes are described later). Currently, this is a number that ranges from 0 - 3. For example, sd2_dos2 is the third disk partition on the disk at BUS 0, TARGET 2, LUN 0 and st104b_1 the tape unit at BUS 1, TARGET 4, LUN 1 with parameters described by mode 1. Tape Device FS_STAT Message Fields ---------------------------------- size - an attempt at determining the number of bytes on a tape medium. type - "s" (for special file, I think) owner - "1/1" (sys/sys) dev - CAM device number id - vendor + product + revision ID fields Tape Device FS_WSTAT Message Fields ----------------------------------- Syntax: : COMMAND | COMMAND '=' PRMNAME | COMMAND '=' PRMNAME prmval | COMMAND '=' prmval ; where COMMAND and PRMNAME are identifiers and prmval is a literal (eg., 1, 3.14) or an identifier. Command PrmName PrmVal ------- ------- ------ MTIOCTOP mt_op (*1) count MTSETMODE mode (*2) value *1) mt_op = MTWEOF | MTFSF | MTBSF ... Note that the SCSI/CAM tape driver is currently using the FreeBSD mtio.h. *2) mode = MTBLKSIZ[0-N] | MTDENSITY[0-N] (where N is currently 3). Note that the MT*0 names contain default values determined by the driver. Modes are persistent - they do not go away when a tape device is closed. Here are the possible values for the MTSETMODE modes parameters: MTBLKSIZ - for fixed-block devices, the block size in bytes. MTDENSITY - SCSI density code. From vandys@glare.cisco.com Thu Nov 10 10:16:15 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01508; Thu, 10 Nov 1994 10:16:14 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA08385 for ; Thu, 10 Nov 1994 10:37:21 -0800 Received: from rtl.cygnus.com (rtl.cygnus.com [140.174.1.2]) by cygnus.com (8.6.9/8.6.9) with ESMTP id KAA19086; Thu, 10 Nov 1994 10:37:19 -0800 Received: (rob@localhost) by rtl.cygnus.com (8.6.9/8.6.4) id KAA05141; Thu, 10 Nov 1994 10:37:19 -0800 Message-Id: <199411101837.KAA05141@rtl.cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Thu, 10 Nov 1994 10:37:18 PST In-Reply-To: Basile STARYNKEVITCH ' <9411100856.AA00680@rosser.serma.cea.fr> forget about my patches for GCC 2.6.1 under VSTa. Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Basile STARYNKEVITCH Subject: Re: forget about my patches for GCC 2.6.1 under VSTa. Cc: vsta@cisco.com From: Basile STARYNKEVITCH Subject: forget about my patches for GCC 2.6.1 under VSTa. > Sorry, i didn't know about the existing patch on ftp.cygnus.com (an > ftp server i didn't know about). I'm glad patches of GCC 2.6.1 for > VSTa already exist. My patches were nearly untested (I hacked them in > one evening, and i don't know much about VSTa or GCC internals), and > other patches are porbably better. Not a problem! I'm glad you dove right in! The patch hasn't been out that long, so it's not suprising most folks hadn't seen the patch. I'd welcome your help in improving the current patch. > I'm suprised that GNU distribution of binutils-2.5.2 mentions (and > supports and knows about) VSTa, while GNU distribution of gcc-2.6.1 > don't mention VSTa. Why? Shouldn't the GNU distribution of GCC support Cygnus is the maintainer of the binutils, while Richard Kenner is the GCC maintainer. This makes it harder to get patches in the FSF sources, but this patch looks like it'll be accepted. The VSTa patches has been in our sources for almost a year. The critical spot was LD, cause with a LD for VSTa cross, you can use the native compiler on *BSD or Linux and then just link with the VSTa cross compiler and you're there. One of these days I'll merge in the libc changes and get a complete tool chain. Still thinking about GDB.... - rob - From vandys@glare.cisco.com Thu Nov 10 10:52:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01515; Thu, 10 Nov 1994 10:52:09 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA10513 for ; Thu, 10 Nov 1994 11:13:15 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 10 Nov 94 20:12:59+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 10 Nov 94 20:13:29-0100 Date: 10 Nov 94 20:13:29-0100 From: Basile STARYNKEVITCH Message-Id: <9411101913.AA09502@rosser.serma.cea.fr> To: rob@cygnus.com Cc: vsta@cisco.com In-Reply-To: <199411101837.KAA05141@rtl.cygnus.com> Subject: Re: forget about my patches for GCC 2.6.1 under VSTa. Content-Length: 4216 Again, i didn't really test my patches. However, i fetched your patches and failed to cross-link with VSTa 1.3.2 native crt0.o. I'm cross-compiling with gcc2.6.1 (on host SunOS5.3, with native gcc2.6.1) First, all of libobjc fails, because of repeated size_t conflicts # GCC was configured as follows: ../gcc-2.6.1/configure --verbose --host=sparc-solaris2 --target=i386-vsta --with-gcc --prefix=/netdisk/rigel.2/basile/xvsta --program-prefix=vsta_ echo host=sparc-unknown-solaris2 target=i386-unknown-vsta build=sparc-unknown-solaris2 # i copied include directories (and lib also) of vsta.tz appropriately # example of size_t error /netdisk/mimas.2/basile.tmp/Xvsta-Gcc/xgcc -B/netdisk/mimas.2/basile.tmp/Xvsta-Gcc/ -O -fgnu-runtime \ -c -DCROSS_COMPILE -DIN_GCC -DSVR4 -O2 -I./include -I. -I.. -I/netdisk/mimas.2/basile.tmp/gcc-2.6.1 -I/netdisk/mimas.2/basile.tmp/gcc-2.6.1/config /netdisk/mimas.2/basile.tmp/gcc-2.6.1/objc/Object.m In file included from /netdisk/rigel.2/basile/xvsta/i386-vsta/include/stdio.h:7, from /netdisk/mimas.2/basile.tmp/gcc-2.6.1/objc/typedstream.h:31, from /netdisk/mimas.2/basile.tmp/gcc-2.6.1/objc/Object.h:30, from /netdisk/mimas.2/basile.tmp/gcc-2.6.1/objc/Object.m:27: /netdisk/rigel.2/basile/xvsta/i386-vsta/include/sys/types.h:20: redefinition of `size_t' /netdisk/mimas.2/basile.tmp/Xvsta-Gcc/include/stddef.h:136: `size_t' previously declared here # failure of crt0.o from VSTa rosser ~/mimas.tmp/Xvsta-Gcc !46 20:08 % make -k cross-test LANGUAGES=c # ./xgcc -B./ -DCROSS_COMPILE -DIN_GCC -DSVR4 -O2 -I./include -c ../gcc-2.6.1/cross-test.c ## to make things clearer i've make -k cross-test LANGUAGES=c 'GCC_FOR_TARGET = ./xgcc -B./ -v' ## to just add the -v flag ./xgcc -B./ -v -DCROSS_COMPILE -DIN_GCC -DSVR4 -O2 -I./include -c ../gcc-2.6.1/cross-test.c Reading specs from ./specs gcc version 2.6.1 ./cpp -lang-c -v -I./include -isystem ./include -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dunix -Di386 -DVSTA -D__unix__ -D__i386__ -D__VSTA__ -D__unix -D__i386 -D__VSTA -Asystem(unix) -Asystem(vsta) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -DCROSS_COMPILE -DIN_GCC -DSVR4 ../gcc-2.6.1/cross-test.c /tmp/cca002KK.i GNU CPP version 2.6.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: ./include ./include /netdisk/rigel.2/basile/xvsta/lib/gcc-lib/i386-vsta/2.6.1/include /netdisk/rigel.2/basile/xvsta/lib/gcc-lib/i386-vsta/2.6.1/sys-include /netdisk/rigel.2/basile/xvsta/i386-vsta/include End of search list. ./cc1 /tmp/cca002KK.i -quiet -dumpbase cross-test.c -O2 -version -o /tmp/cca002KK.s GNU C version 2.6.1 (80386, BSD syntax) compiled by GNU C version 2.6.1. /netdisk/rigel.2/basile/xvsta/i386-vsta/bin/as -o cross-test.o /tmp/cca002KK.s ./xgcc -B./ -v -DCROSS_COMPILE -DIN_GCC -DSVR4 -O2 -I./include cross-test.o -o cross-test Reading specs from ./specs gcc version 2.6.1 /netdisk/rigel.2/basile/xvsta/i386-vsta/bin/ld -o cross-test /netdisk/rigel.2/basile/xvsta/i386-vsta/lib/crt0.o -L. -L/netdisk/rigel.2/basile/xvsta/i386-vsta/lib cross-test.o -lgcc -lc -lgcc __main.o(.text+0x74): multiple definition of `__main' /netdisk/rigel.2/basile/xvsta/i386-vsta/lib/crt0.o(.text+0x49): first defined here _exit.o(.text+0xd): undefined reference to `_cleanup' make: *** [cross-test] Error 1 The /netdisk/rigel.2/basile/xvsta/i386-vsta/lib/crt0.o is a copy of vsta-1.3.2's file. I suppose i have to patch VSTa crt0.s & crt0srv.s for GCC 2 (actually for g++ support of destructors and constructors). -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Thu Nov 10 12:16:53 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01532; Thu, 10 Nov 1994 12:16:46 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA14932 for ; Thu, 10 Nov 1994 12:37:54 -0800 Received: from rtl.cygnus.com (rtl.cygnus.com [140.174.1.2]) by cygnus.com (8.6.9/8.6.9) with ESMTP id MAA25167; Thu, 10 Nov 1994 12:37:53 -0800 Received: (rob@localhost) by rtl.cygnus.com (8.6.9/8.6.4) id MAA08730; Thu, 10 Nov 1994 12:37:52 -0800 Message-Id: <199411102037.MAA08730@rtl.cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Thu, 10 Nov 1994 12:37:52 PST In-Reply-To: Basile STARYNKEVITCH ' <9411101913.AA09502@rosser.serma.cea.fr> Re: forget about my patches for GCC 2.6.1 under VSTa. Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Basile STARYNKEVITCH Subject: Re: forget about my patches for GCC 2.6.1 under VSTa. Cc: vsta@cisco.com From: Basile STARYNKEVITCH Subject: Re: forget about my patches for GCC 2.6.1 under VSTa. > I'm cross-compiling with gcc2.6.1 (on host SunOS5.3, with native > gcc2.6.1) First, all of libobjc fails, because of repeated size_t > conflicts > > # example of size_t error Hum, I haven't tried it with obj, or on Solaris. I did my last set of tests in HP-UX, and it worked fine. I'm getting a Solaris machine within the next few weeks (ug...) but I can try on one of our machines out here. > __main.o(.text+0x74): multiple definition of `__main' > /netdisk/rigel.2/basile/xvsta/i386-vsta/lib/crt0.o(.text+0x49): first defined here > _exit.o(.text+0xd): undefined reference to `_cleanup' > make: *** [cross-test] Error 1 This is a library problem. __main is thrown in by GCC for C++ support. (it comes from libgcc) You cna stub it out "__main(){}" if you don't intend to ever run G++, but it exist mostly to setup constructer/destructer tables. It should have worked, thank for finding it! _cleanup is the same basic problem. It can be stubbed out, but for C++ support it needs to work. I don't know if anyone is doing C++ on VSTa, but it'd be nice if they could if they wanted. - rob - From vandys@glare.cisco.com Thu Nov 10 17:00:56 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA01579; Thu, 10 Nov 1994 17:00:54 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA27370; Thu, 10 Nov 1994 17:22:01 -0800 Message-Id: <199411110122.RAA27370@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@cisco.com Subject: Re: IRQ's in Amiga VSTa In-Reply-To: Your message of "Thu, 10 Nov 1994 14:56:38 -1000." <9411110056.AA00455@zang.kcc.hawaii.edu> Date: Thu, 10 Nov 1994 17:22:00 -0800 From: Andrew Valencia [newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:] >It looks like the current IRQ handling scheme is not well suited >to the amiga archetecture. I think I may have to use an aditional >scheme (keeping the current scheme for where it is useful). To >explain why let me first explain how amiga interupts are handled >(to the best of my understanding). > >The 680x0 cpu family has 3 interupt lines used to signal an >interupt on any of 7 levels. The interupts are prioritized, >0 being non-interupt state, 7 being non-maskable interupts. >When an interupt comes in the cpu sets a mask for all interupts >at that level and lower. Higher priority interupts may occur >but not lower. There are 7 interrupt vectors for these 7 >levels of interupts. > >The amiga has additional hardware which handle interupts before >they ever reach the cpu. All external interupts are connected >to this chip and translated to one of the cpu levels. The custom >chips also have a number of internal interupts they can generate. >There is a mask register for masking individual interupts and >another register that is readable for determining what interupt >lines are active. Here is a list of the interupts as seen >by the custom chips: > >Level1 TBE - serial port transmit buffer empty > DSKBLK - disk block transfer > SOFTINT - software generated interupt >Level2 CIAA - CIA A. This chip has its own interupt register > and mask. > PORTS - external interupts >Level3 BLIT - blitter interupt > COPER - coprocessor graphics interupt > VERTB - vertical blanking interupt for video >Level4 AUD1 - Audio channel interupts > AUD2 > AUD3 > AUD4 >Level5 RBF - serial port receive buffer full > DSKSYNC - disk sync pattern found >Level6 CIAB - CIA B. This chip has its own interupt register/mask. > EXTERN - external interupts >Level7 NMI - non maskable interupts > >The internally generated interupts all fit in well with the >message passing interupt scheme. The kernel can parse out the >interupt type from the custom chips and the CIA chips to determine >what exactly caused the interupt and send an ISR message with >this information. The problem I am having is with the externally >generated interupts. > > - Many devices may share the same interupt types "EXTERN" and > "PORTS". (I suppose "NMI" also but I dont think they are > used). > - These interupt states are generated externally and may > not be turned off by the kernel without the kernel knowing > the hardware in question. > >What is happening to me currently is I get a PORTS interupt from >my SCSI card (for dma). The kernel catches it as PORTS and >queues up a message to the process. The kernel then returns from >the interupt service routine but since the hardware line is >still being driven high the interupt occurs immediately after >returning. This causes the kernel to keep looping in the interupt >service routine. No processes run, just about the only thing >that still runs is the hard clock which is at a higher priority. >The alternatives I have thought of at this point are: > > - Put Device drivers in the kernel. This is highly undesireable. > - Put support for more devices in the kernel. Parse out > the interupt types further. This means each time a new > device driver is written the kernel has to be modified. > - Add a mechanism for loading code into the running kernel. > This is no simple feat and may make the kernel a bit larger. > - Disable the specific interupt type before delivering the > message. This requires that the process itself reenable > the interupt when it is done or notifies the kernel that it > may reenable the interupt. This scheme doesnt allow for > different processes to receive interupts through the same > vector. > - Make a registry of interupt services for the PORTS and EXTERN > interupts. When an interupt occurs, call each of the service > routines in turn until one returns true indicating that the > interupt was intended for it. > >I like the last alternative the best. This is how the amigados >microkernel handles this. The problems I see are: > > - The kernel must find the process, switch to it and do some > sort of jump into its address space. > - The code will be running at a high priority level and maybe > in priveledged mode. > - There seems to be lots of room for something to go wrong > if the handler is faulty. > >I'm not sure how all the details would work out. > >Comments? (many hopefully).... (I usually don't quote whole messages, but I thought the list would be interested in the progress of an Amiga port) This is exactly the problem the HP 300 port was faced with. I was planning on dumping P-code as a part of the interrupt registry. The P-code would be just sufficient to query hardware, check/clear bits, and report a boolean value back. The kernel interrupt handling would recognize a level which had various P-code registries, and would call each registry. When one returned "true", you'd queue up the ISR message for his associated server. This was my theory. I'm still looking for time to try it in practice on a 300. The priority's somewhat lower since your 68k port already does most of the "proof of portability" I was looking for. BTW, I'll want to take you out to dinner when next you pass through the SF Bay Area! Regards, Andy From vandys@glare.cisco.com Thu Nov 10 19:19:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01599; Thu, 10 Nov 1994 19:19:54 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA05796; Thu, 10 Nov 1994 19:41:03 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA00699; Thu, 10 Nov 1994 17:40:04 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411110340.AA00699@zang.kcc.hawaii.edu> Subject: Re: IRQ's in Amiga VSTa To: vandys@cisco.com (Andrew Valencia) Date: Thu, 10 Nov 1994 17:40:03 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <199411110122.RAA27370@glare.cisco.com> from "Andrew Valencia" at Nov 10, 94 05:22:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 737 > This is exactly the problem the HP 300 port was faced with. I was planning > on dumping P-code as a part of the interrupt registry. The P-code would be > just sufficient to query hardware, check/clear bits, and report a boolean > value back. The kernel interrupt handling would recognize a level which had > various P-code registries, and would call each registry. When one returned > "true", you'd queue up the ISR message for his associated server. I'm not sure I know exactly what you mean. What is P-code? How would a device driver put it in the kernel (or does this reside in the processes address space?). I'd like to get this implemented so I can finish debugging the scsi driver. Thanks. > Regards, > Andy From vandys@glare.cisco.com Thu Nov 10 19:27:00 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01603; Thu, 10 Nov 1994 19:26:59 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id TAA02694; Thu, 10 Nov 1994 19:48:08 -0800 Message-Id: <199411110348.TAA02694@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@cisco.com Subject: Re: IRQ's in Amiga VSTa In-Reply-To: Your message of "Thu, 10 Nov 1994 17:40:03 -1000." <9411110340.AA00699@zang.kcc.hawaii.edu> Date: Thu, 10 Nov 1994 19:48:07 -0800 From: Andrew Valencia [newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:] >I'm not sure I know exactly what you mean. What is P-code? How would >a device driver put it in the kernel (or does this reside in the processes >address space?). I'd like to get this implemented so I can finish >debugging the scsi driver. Thanks. I simply mean an interpretive pseudo-assembly code which permits the driver to describe actions which need to be taken within a hardware interrupt handler. In its simplest form you would write the following in your server: tst_mydev: mov.l DEV_REG,d0 btst d0,$3 beq is_interrupting movq $0,d0 ret is_interrupting: mov.l $CLR_INTR,DEV_REG2 movq $1,d0 ret tst_mydev_end: And then pass tst_mydev and (tst_mydev_end-tst_mydev) (i.e., the length) as a part of ISR registration. But allowing the driver to specify just *any* instruction might not be desirable (or it might be, but make sure it's position independent!) so instead you could devise a pseudo-assembly code and pass that instead. The p-code interpreter would be kernel code. Apologies if any of my 68k assembly is wrong; it's been a while. Andy From vandys@glare.cisco.com Fri Nov 11 05:58:00 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01675; Fri, 11 Nov 1994 05:57:59 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id GAA28293 for ; Fri, 11 Nov 1994 06:19:10 -0800 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id JAA09824; Fri, 11 Nov 1994 09:19:08 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA15022; Fri, 11 Nov 1994 09:19:26 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199411111419.AA15022@world.std.com> Subject: Re: IRQ's in Amiga VSTa To: vsta@cisco.com Date: Fri, 11 Nov 1994 09:19:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1162 Hi, [Andrew Valencia writes] > This is exactly the problem the HP 300 port was faced with. I was planning > on dumping P-code as a part of the interrupt registry. The P-code would be > just sufficient to query hardware, check/clear bits, and report a boolean > value back. The kernel interrupt handling would recognize a level which had > various P-code registries, and would call each registry. When one returned This is an interesting idea. It certainly avoids a number of messy issues (some of which Tim mentioned). I remember that the Alliant real-time user mode interrupt handling code was fairly complicated in this regard. As an aside, the comment just before the kernel jumped to the user's interrupt handler went something like "why does this feel like jumping off a !@#$% bridge". One question: have you considered using a threaded interpreter as opposed to a p-code interpreter? Threaded interpreters claim to run very quickly and to be easy to extend. The extensiblity factor would come in to play if, in the future, someone needs to do more complicated processing than testing and setting of bits. Mike Larson From vandys@glare.cisco.com Fri Nov 11 08:47:55 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01689; Fri, 11 Nov 1994 08:47:53 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA26389; Fri, 11 Nov 1994 09:08:41 -0800 Message-Id: <199411111708.JAA26389@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@amri.cisco.com Subject: Re: IRQ's in Amiga VSTa Date: Fri, 11 Nov 1994 09:08:40 -0800 From: Andrew Valencia Hi, Did I make the P-code idea clear? I think a threaded interpreter would be overkill, and also most of the fast TIL (Threaded Interpretive Language) interpreters I've worked with would be difficult to make position independent. Here's some off-the-cuff code ideas. Imagine that the device at address DEV_ADDR has bit DEV_INTR and clears the interrupt when the register is written. So the P-code has to have a "bit test word" operation, and a "store word" operation. Let's say BTST skips an instruction when the bit IS set. #define PCODE_BTST 1 /* Test a bit in a word */ #define PCODE_STZERO 2 /* Store 0 -> word */ #define PCODE_RET_TRUE 3 /* Return boolean true */ #define PCODE_RET_FALSE 4 /* ...false */ #define PCODE_MAX 4 /* Highest legal opcode */ ulong test_device_pcode[] = { PCODE_BTST, DEV_ADDR, DEV_INTR, PCODE_RET_FALSE, PCODE_STZERO, DEV_ADDR, PCODE_RET_TRUE }; Now you register it with: enable_isr(port, irq, test_device_pcode, sizeof(test_device_pcode)); The kernel copies in the code, stores it somewhere, and so forth. The interpreter would look something like: /* * Size of each instruction */ static int interp_size[] = { 3, /* BTST */ 2, /* STZERO */ 1, /* RET_TRUE */ 1 /* RET_FALSE */ }; interp_pcode(ulong *pc) { ulong instr, *addr; uint bit; for (;;) { instr = *pc++; switch (instr) { case PCODE_BTST: addr = (ulong *)*pc++; bit = *pc++; if (*addr & (1 << bit)) { ASSERT_DEBUG(*pc <= PCODE_MAX, "interp_pcode: bad skip"); pc += interp_size[*pc]; } break; case PCODE_RET_FALSE: return(0); case PCODE_RET_TRUE: return(1); case PCODE_STZERO: addr = (ulong *)*pc++; *addr = 0; break; default: ASSERT(0, "interp_pcode: bad instruction"); } } } Regards, Andy From vandys@glare.cisco.com Fri Nov 11 10:10:41 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01715; Fri, 11 Nov 1994 10:10:40 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA04376; Fri, 11 Nov 1994 10:31:50 -0800 Message-Id: <199411111831.KAA04376@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: larz@world.std.com (Mike A Larson) Cc: vsta@cisco.com Subject: Re: IRQ's in Amiga VSTa In-Reply-To: Your message of "Fri, 11 Nov 1994 13:28:30 EST." <199411111828.AA23086@world.std.com> Date: Fri, 11 Nov 1994 10:31:49 -0800 From: Andrew Valencia [larz@world.std.com (Mike A Larson) writes:] >If you passed the tcode "source" to enable_isr(), I don't see why >you need position independence. This means, of course, that the >kernel needs to translate the tcode "source" to something that >can be interpreted, but TIL's tend to have very simple syntax's. A parser in the kernel. I'm getting the shivers! :-) >Thanks for the example. A couple of questions - how you handle the case >where there are multiple interrupt bits (eg,. complete interrupt, error >interrupt, etc.)? Also, do you plan to add logical operations (eg., >read the contents of a register, bitwise OR in a flag, and write the >value back to the register)? Well, the point is that you create a P-code which is exactly sufficient for the target architecture. So until you NEED such an operation, the operation does not exist. Minimalism at its finest! Andy From vandys@glare.cisco.com Fri Nov 11 10:07:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA01712; Fri, 11 Nov 1994 10:07:05 -0800 Received: from europe.std.com (root@europe.std.com [192.74.137.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id KAA09393; Fri, 11 Nov 1994 10:28:14 -0800 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id NAA08274; Fri, 11 Nov 1994 13:28:12 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA23086; Fri, 11 Nov 1994 13:28:30 -0500 From: larz@world.std.com (Mike A Larson) Message-Id: <199411111828.AA23086@world.std.com> Subject: Re: IRQ's in Amiga VSTa To: vandys@cisco.com (Andrew Valencia) Date: Fri, 11 Nov 1994 13:28:30 -0500 (EST) Cc: vsta@cisco.com In-Reply-To: <199411111708.JAA26389@glare.cisco.com> from "Andrew Valencia" at Nov 11, 94 09:08: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: 1139 Hi, [Andrew Valencia writes:] > Did I make the P-code idea clear? Yes. > I think a threaded interpreter would be overkill, ... This was what I was interested in finding out. For the original problem, I agree with you (and Tim needs a solution right now). But, a TIL might give you flexibility to do oddball things in the future. > ... and also most of the fast TIL (Threaded Interpretive Language) > interpreters I've worked with would be difficult to make position > independent. If you passed the tcode "source" to enable_isr(), I don't see why you need position independence. This means, of course, that the kernel needs to translate the tcode "source" to something that can be interpreted, but TIL's tend to have very simple syntax's. > Here's some off-the-cuff code ideas. Thanks for the example. A couple of questions - how you handle the case where there are multiple interrupt bits (eg,. complete interrupt, error interrupt, etc.)? Also, do you plan to add logical operations (eg., read the contents of a register, bitwise OR in a flag, and write the value back to the register)? Mike Larson From vandys@glare.cisco.com Fri Nov 11 11:03:59 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01737; Fri, 11 Nov 1994 11:03:54 -0800 Received: from cayman.Cayman.COM (cayman.Cayman.COM [143.137.137.1]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA00290 for ; Fri, 11 Nov 1994 11:25:07 -0800 Received: from foxharp.UUCP (nuucp@localhost) by cayman.Cayman.COM (8.6.8.1/ECB-MAIN-1.16) with UUCP id OAA17906 for vsta@cisco.com; Fri, 11 Nov 1994 14:23:17 -0500 Received: by foxharp: id m0r61X5-0002e3C; Fri, 11 Nov 94 14:21 EST Message-Id: To: vsta@cisco.com Subject: Re: IRQ's in Amiga VSTa In-Reply-To: vandys's message of Fri, 11 Nov 1994 09:08:40 -0800. <199411111708.JAA26389@glare.cisco.com> Reply-To: pgf@foxharp.boston.ma.us Date: Fri, 11 Nov 1994 14:21:11 -0500 From: Paul Fox > > Did I make the P-code idea clear? I think a threaded interpreter would be > overkill, and also most of the fast TIL (Threaded Interpretive Language) > interpreters I've worked with would be difficult to make position > independent. > > Here's some off-the-cuff code ideas. > maybe i'm missing the point of all this, but a couple of things come to mind... it seems to me that for performance, you'd want to "compile" the code at driver registration time, rather than do the interpretation at interrupt time. but i'd think for flexibility, since you can't _really_ predict what a specific driver will need to do in terms of masking and checking and restoring state etc, you should let the driver-writer simply provide a block of assembly code. this is more dangerous from a security point of view, but then, installing a driver at all is somewhat dangerous from _that_ point of view, and shouldn't be possible unless you're "trusted" to some extent, right? the kernel coulld in principle do some address and opcode checking of the passed-in assembly code to be sure they're not doing anything dumb, like jumping to or overwriting location zero, or not doing the proper returns, or whatever. (i'd think you'd want to do that sort of sanity check in the p-code interpreter you proposed, in any case, to catch the same kinds of problems.) paul --------------------- paul fox, pgf@foxharp.boston.ma.us (arlington, ma) From vandys@glare.cisco.com Fri Nov 11 13:25:16 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA01757; Fri, 11 Nov 1994 13:25:15 -0800 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA16207; Fri, 11 Nov 1994 13:46:24 -0800 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA29845 ; Fri, 11 Nov 1994 22:46:03 +0100 Received: from aviso.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05) id AA02393; Fri, 11 Nov 94 22:45:53 +0100 From: rideau@clipper.ens.fr (Francois-Rene Rideau) Message-Id: <9411112145.AA02393@clipper.ens.fr> Subject: Re: IRQ's in Amiga VSTa To: vandys@cisco.com (Andrew Valencia) Date: Fri, 11 Nov 94 22:45:55 MET Cc: vsta@cisco.com In-Reply-To: <199411111831.KAA04376@glare.cisco.com>; from "Andrew Valencia" at Nov 11, 94 10:31 am X-Mailer: ELM [version 2.3 PL11] > A parser in the kernel. I'm getting the shivers! :-) Why not use a FORTH inside the kernel ? Or even use the OpenBoot bytecode FORTH thing. That would be great ! FORTH is small, a complete FORTH system, including parser, is < 16 KB. From vandys@glare.cisco.com Fri Nov 11 22:45:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA01842; Fri, 11 Nov 1994 22:45:48 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA07444 for ; Fri, 11 Nov 1994 23:07:00 -0800 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, 12 Nov 1994 18:06:54 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA02292; Sat, 12 Nov 94 18:17:30 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA25784; Sat, 12 Nov 1994 18:08:25 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199411120708.AA25784@sour.sw.oz.au> Subject: Re: IRQ's in Amiga VSTa To: vsta@cisco.com Date: Sat, 12 Nov 1994 18:08:24 +1100 (EST) In-Reply-To: <9411112145.AA02393@clipper.ens.fr> from "Francois-Rene Rideau" at Nov 11, 94 10:45:55 pm X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au Precedence: special-delivery X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 904 But I thought Francois-Rene Rideau said: > > > A parser in the kernel. I'm getting the shivers! :-) > Why not use a FORTH inside the kernel ? > Or even use the OpenBoot bytecode FORTH thing. > That would be great ! > FORTH is small, a complete FORTH system, including parser, is < 16 KB. 16 KB isn't especially cheap for a 40 KB microkernel, and then there's the question of whether FORTH can access all the machine instructions it needs to solve the original problem. For the weight of a FORTH interpreter I'd rather see a way of dynamically linking new object code into the kernel. You could then specify a dynamically (or staticly) linked kernel kernel function as the hander routine for a given interrupt. This would be a reasonably general mechanism for kernel extensibility, but still kind of expensive for a small microkernel. P-code seems the way to go for the moment. Cheers, Christopher. From vandys@glare.cisco.com Sat Nov 12 09:36:00 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01974; Sat, 12 Nov 1994 09:35:53 -0800 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA26289 for ; Sat, 12 Nov 1994 09:57:09 -0800 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA24315 ; Sat, 12 Nov 1994 18:56:57 +0100 Received: from aviso.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05) id AA10929; Sat, 12 Nov 94 18:56:52 +0100 From: rideau@clipper.ens.fr (Francois-Rene Rideau) Message-Id: <9411121756.AA10929@clipper.ens.fr> Subject: Bytecode interpreter To: fire-l@artopro.mlnet.com (Fire-l) Date: Sat, 12 Nov 94 18:56:55 MET Cc: vsta@cisco.com In-Reply-To: <941111203131288@artopro.mlnet.com>; from "Fire-l" at Nov 11, 94 10:39 am X-Mailer: ELM [version 2.3 PL11] For those interested in a good bytecode interpreter, I'd suggest looking at the one from the CAML-light run-time system. It runs at quite honorable speed, is compact, etc. On traditional C compilers, it uses a switch() statement, but if GCC is detected is uses a jump table. CAML-light can be found at ftp.inria.fr:/pub/lang/caml-light It's a functional language of the ML family, with side effects and strict evaluation (not a pure lazy functional language). It runs on Unix machines, and under MS-DOS (16 and 32 bit versions available), and on MacIntoshes. From vandys@glare.cisco.com Sat Nov 12 09:46:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01978; Sat, 12 Nov 1994 09:46:31 -0800 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA26459 for ; Sat, 12 Nov 1994 10:07:48 -0800 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA24550 ; Sat, 12 Nov 1994 19:07:34 +0100 Received: from aviso.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05) id AA11208; Sat, 12 Nov 94 19:07:30 +0100 From: rideau@clipper.ens.fr (Francois-Rene Rideau) Message-Id: <9411121807.AA11208@clipper.ens.fr> Subject: Re: P-Code vs TIL To: chrisf@sour.sw.oz.au (Christopher Fraser) Date: Sat, 12 Nov 94 19:07:33 MET Cc: vsta@cisco.com In-Reply-To: <199411120708.AA25784@sour.sw.oz.au>; from "Christopher Fraser" at Nov 12, 94 6:08 pm X-Mailer: ELM [version 2.3 PL11] > For the weight of a FORTH interpreter I'd rather see a way of > dynamically linking new object code into the kernel. You could then > specify a dynamically (or staticly) linked kernel kernel function > as the hander routine for a given interrupt. This would be a > reasonably general mechanism for kernel extensibility, but still > kind of expensive for a small microkernel. P-code seems the > way to go for the moment. Indeed, what we need here is a dynamic loader for kernel code. But the problem of having P-code, threaded code, or assembly is orthogonal to it, and orthogonal to having C, FORTH, or anything else as a source language. The compiler is outside the kernel. And once the compiler worked, it's easiest to use assembly or threaded code than P-code. The p-code interpreter for CAML-light itself is more than 10 KB ! From vandys@glare.cisco.com Sun Nov 13 12:16:19 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02071; Sun, 13 Nov 1994 12:16:18 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA25720 for ; Sun, 13 Nov 1994 12:37:43 -0800 Message-Id: <199411132037.MAA25720@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Bug in messaging engine Date: Sun, 13 Nov 1994 12:37:43 -0800 From: Andrew Valencia Hi, folks. I've hunted down the bug which ends up with the "DISC pr mismatch". It appears that the p_iowait semaphore gets v'ed an extra time. This is usually harmless, since the semaphore value is zeroed each time a new msg_send() is initiated. However, msg_disconnect() does not zero it, and thus walks straight through his p_sema_v_lock and frees the message while it's still on the server's message queue. All the extra zeroing is a waste of code space and CPU cycles. I'm going to dig up the bogus v'ing and get rid of all excess resets of the semaphore count. Andy From vandys@glare.cisco.com Sun Nov 13 12:45:33 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA02075; Sun, 13 Nov 1994 12:45:32 -0800 Received: from post.demon.co.uk ([158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA01990 for ; Sun, 13 Nov 1994 13:06:47 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa25052; 13 Nov 94 21:06 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r6iLF-0003DWC; Sun, 13 Nov 94 17:03 GMT Message-Id: From: Dave Hudson Subject: Re: P-Code vs TIL To: Francois-Rene Rideau Date: Sun, 13 Nov 1994 17:03:49 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9411121807.AA11208@clipper.ens.fr> from "Francois-Rene Rideau" at Nov 12, 94 07:07:33 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: 2642 Hi All, I think this discussion seems to be going off at a tangent from the original problem :-) > > For the weight of a FORTH interpreter I'd rather see a way of > > dynamically linking new object code into the kernel. You could then > > specify a dynamically (or staticly) linked kernel kernel function > > as the hander routine for a given interrupt. This would be a > > reasonably general mechanism for kernel extensibility, but still > > kind of expensive for a small microkernel. P-code seems the > > way to go for the moment. Unless I misunderstood the problem we weren't looking for kernel extensibility (I just hack in a few more syscalls if I want to do that :-)), simply a way of turning off an interrupt flag so that the kernel can get on and pass a message to the appropriate server. I guess there's a possible objection that we might want to do something quickly, but the current rs232 server actually stands up quite well and it's dealing with an awful lot of M_ISRs. One of the bits of kernel code I've done over the last month or so gets the RT and BG priority queues running so we can just stick speed critical threads into the RT queue instead though and thus get the M_ISRs delivered more quickly. > Indeed, what we need here is a dynamic loader for kernel code. > But the problem of having P-code, threaded code, or assembly is orthogonal > to it, and orthogonal to having C, FORTH, or anything else as a source > language. The compiler is outside the kernel. And once the compiler worked, > it's easiest to use assembly or threaded code than P-code. > The p-code interpreter for CAML-light itself is more than 10 KB ! At a guess the sort of P-code interpretter Andy described would be somewhat nearer to a few hundred bytes. The idea of having to either have a linker in the kernel or having to do mode switches in and out of kernel space to call a user-registered function (that may or may-not find an interrupt is really for it) doesn't particularly appeal to me. This discussion about P-code has brought me to something I've been pondering for a few months now though - writing something like a P-code server. Once the 68k port is running I'd quite like to play with some ideas on CPU independent code. VSTa's servers would allow large chunks of native code to be handled efficiently, just leaving perhaps application logic in a highly transportable format. I'd envisage that messaging would be handled as a "low-level" operation in such a development. Anyway it's just an idea and I don't know how much of it's been tried before (anyone know if this has been done on Mach at all?) Regards, Dave From vandys@glare.cisco.com Sun Nov 13 14:19:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02089; Sun, 13 Nov 1994 14:19:08 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA03791 for ; Sun, 13 Nov 1994 14:40:33 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id PAA21298 for ; Sun, 13 Nov 1994 15:40:31 -0700 Message-Id: <199411132240.PAA21298@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: "no child" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21293.784766430.1@xmission.xmission.com> Date: Sun, 13 Nov 1994 15:40:30 -0700 From: Gary Shea I've got the system calls which will support the kernel side of user-level thread synchronization (twait(lock_t*) and tsignal(pid_t)) working, although they're definitely not done. User-level spinlocks are also implemented. Now I just need to do some more checking in the system calls and implement the pid queue for libc. The scary part is not really understanding why p_sema sets the flags it does (since that's where I stole the code...). I left out the flag-sets I don't understand :) Small comfort to future users! I tested the syscalls with a program that tforks and then starts counting to 10, sleeping between counts. The child does pretty much the same thing. They both print out what number they're on. On its 3 the parent calls twait(); on the child's 8 it calls tsignal(). The child exits on 10. The parent is only at 6 or so, and it dies, the message "no child" appearing. There's no signal involved (I think I'm catching them all!). I see that ECHILD is defined in libc/errno.c but it doesn't seem to be used anywhere in the kernel (cd /vsta/os; grep ECHILD */*.c). Somebody please explain what's happening? Gary From vandys@glare.cisco.com Sun Nov 13 14:56:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02094; Sun, 13 Nov 1994 14:56:54 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA04393 for ; Sun, 13 Nov 1994 15:18:10 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa16056; 13 Nov 94 23:17 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r6nol-0003DWC; Sun, 13 Nov 94 22:54 GMT Message-Id: From: Dave Hudson Subject: Kernel work/fixes To: VSTa mailing list Date: Sun, 13 Nov 1994 22:54:38 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1555 Hi All, I just thought I'd mention some work I've recently done on the kernel (in case anyone else was thinking of working on the same code): Added a mechanism to move threads into the real-time and background scheduling priorities and to query the priority that a particular thread has. Fixed the ID handling in libc to allow a ID to be held as a group ID. Also patched libusr to get the permissions granted by a particular ID correct (not really kernel fixes I know :-)) Modified the kernel ID manipulation code to keep the process permission/protection bits in sync with the ID of the owner. Modified the pstat() mechanism to allow additional information to be available (eg free memory, load averages, etc) Fixed an internal bug in the msg_accept() code to remove an unwanted v_sema(&p->p_sema). This meant that almost all attempts to grab the process semaphore (on any server that had ever had a client) suceeded instead of blocking if another update to per-process information was being handled. Fixed a bug in free_proc() that caused system reboots if the pid_sema was being held when a process was being removed from the process list. The process vas was being freed up before the attempt to grab the semaphore; if we fell asleep on the semaphore we ended up reloading 0 into CR3 during the resume(). This last one could be demonstrated by trying: while true; do ps; done on one VC, whilst running: while true; do ls; done on another. I found this would reboot my systems within a couple of seconds. Regards, Dave From vandys@glare.cisco.com Mon Nov 14 07:42:31 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02273; Mon, 14 Nov 1994 07:42:30 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA12060; Mon, 14 Nov 1994 08:03:18 -0800 Message-Id: <199411141603.IAA12060@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Gary Shea Cc: vsta@amri.cisco.com Subject: Notify problems and what-not In-Reply-To: Your message of "Mon, 14 Nov 1994 08:55:30 MST." <199411141555.IAA02670@xmission.xmission.com> Date: Mon, 14 Nov 1994 08:03:17 -0800 From: Andrew Valencia [Gary Shea writes:] >Could you give me a clue on how you figured out what it is? >Maybe I could make use of that info someday :) The exception type (from "tf") is 255, which is the interrupt vector used for system calls. So then you look at the "bt" and see which system call was invoked. If it's just do_exit() then you know he asked to exit. If it's by way of sendev() then he's dying on a signal. If his current signal is "abort", you can figure he failed an assertion. BTW... I found the bug in p_iowait semaphore counting last night. The problem is in the interrupted I/O code pathof msg_send(). If the p_sema_v_lock with PRICATCH is interrupted, the semaphore count is incremented to "back out" the sleeper. However, the portref's p_state continues to indicate that there's an I/O waiter for the semaphore. If the server runs during this window (after the sleeper has been interrupted, but before he can run) he will move the state to "I/O done" and v_sema the semaphore even though there's no sleeper. This leaves a semaphore at count 1, which will allow the next guy to fall straight through. If he did another message operation it wouldn't matter; msg_send() currently resets the semaphore count before using the semaphore. But msg_disconnect() doesn't, which is why this bug has hit so rarely. Andy From vandys@glare.cisco.com Tue Nov 15 08:33:35 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA00066; Tue, 15 Nov 1994 08:33:33 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA28080; Tue, 15 Nov 1994 08:03:41 -0800 Message-Id: <199411151603.IAA28080@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: Process lists In-Reply-To: Your message of "Tue, 15 Nov 1994 15:59:34 GMT." Date: Tue, 15 Nov 1994 08:03:40 -0800 From: Andrew Valencia [Dave Hudson writes:] >What I was thinking was to have a single directory of "process files". What >I'm not sure about is the format these should take. Some elements, eg the >protection IDs can just be handled through the FS_STAT mechanism. The >problem comes with things like the count of threads, process name, elapsed >times, etc, and how we represent them. The format can be fiddled back and forth forever. I'm not sure it's all that critical. The important part is that it be available from a server for net mounting. The other strange part is that I'm pretty sure this needs to be a pretty fancy server. If we have him redirect signals and ptrace handling, then we allow cluster-wide debugging and process management. So the server would have to have a root ID, and then switch his abilities on the fly as he acts on behalf of his various clients. >I guess the choice is fairly simple - use libpio and pull info out in >binary, or put the info out in text format make things human readable. I vote for text. Makes it easier to share resources across different processor types. >I've looked at the the plan 9 docs and they seem to have also used a >hierarchy of per-process files, but again they don't provide me with any >definitive answers. The plan 9 approach does have some quite interesting >ideas though, like being able to send events to a process via the proc fs. >I'm not really sure if this gives us much useful, but I'd guess that this >sort of thing might be interesting in a distributed system. It allows you to manage a remote process as if he was local using only remote mounting of filesystems. I imagine remote filesystem mounting to be the "engine" of all clustering. >I'd like to be clear on what if anything I may want to add to the pstat() >syscall to implement the proc fs well before I submit my large kernel diff >collection. So long as the call lines up in a basic way, the sizeof(struct) trick allows us to add incremental fields without too much worry. >... the remote access is the thing I'm really >interested in looking into next year. Me, too. With debugging and networking (plus or minus bugs), we just need /tcp and a little black magic to start mounting remote servers. It's taken longer than I hoped, but that's what day jobs do to you.... :-{} Andy From vandys@glare.cisco.com Tue Nov 15 13:26:01 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA00134; Tue, 15 Nov 1994 13:25:59 -0800 Received: from tomahawk.convex.com (tomahawk.convex.com [130.168.61.15]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id NAA06862; Tue, 15 Nov 1994 13:48:37 -0800 Received: (from helgaas@localhost) by tomahawk.convex.com (8.6.9/8.6.9) id PAA05798; Tue, 15 Nov 1994 15:48:15 -0600 Date: Tue, 15 Nov 1994 15:48:15 -0600 From: Bjorn Helgaas Message-Id: <199411152148.PAA05798@tomahawk.convex.com> To: dave@humbug.demon.co.uk, vandys@cisco.com Subject: Re: Process lists Cc: helgaas@convex.com, vsta@cisco.com [Andrew Valencia writes:] >[Dave Hudson writes:] >>What I was thinking was to have a single directory of "process files". What >>I'm not sure about is the format these should take. ... I've made a little progress on a /proc filesystem server, experimenting with very basic things. The current state is that "cat /proc/*/cmd" looks very similar to the output of "ps". >>The problem comes with things like the count of threads, process name, >>elapsed times, etc, and how we represent them. >I vote for text. Makes it easier to share resources across different >processor types. I vote for text as well. One complication with the VSTa implementation of threads is that a single process (i.e., /proc/n directory) may correspond to several threads. I think Plan 9 "threads" are actually separate processes that happen to share an address space. This makes "echo stop > /proc/n/ctl" unambiguous; in VSTa, we will need something like "echo 'stop x' > /proc/n/ctl" to specify the thread within the process. >>I'd like to be clear on what if anything I may want to add to the pstat() >>syscall to implement the proc fs well before I submit my large kernel diff >>collection. Currently there is no way to specify the pid of interest, so I have to scan them all. It would be nice to be able to just get the one I want. Bjorn From vandys@glare.cisco.com Tue Nov 15 19:55:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00201; Tue, 15 Nov 1994 19:55:25 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id UAA23752 for ; Tue, 15 Nov 1994 20:18:07 -0800 Received: from deathwish.video.net (deathwish.video.net [141.211.246.170]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id XAA02891 for ; Tue, 15 Nov 1994 23:18:06 -0500 Received: (kia@localhost) by deathwish.video.net (8.6.9/video.net-0.9) id XAA01792 for vsta@cisco.com; Tue, 15 Nov 1994 23:18:05 -0500 Date: Tue, 15 Nov 1994 23:18:05 -0500 From: Karl Asha Message-Id: <199411160418.XAA01792@deathwish.video.net> To: vsta@cisco.com Subject: boot disk Does a static boot disk actually exist..and in addition..has anyone managed to get themselves up on the net w/ vsta? Karl From vandys@glare.cisco.com Thu Nov 17 06:20:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00594; Thu, 17 Nov 1994 06:20:26 -0800 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA28487 for ; Thu, 17 Nov 1994 06:40:53 -0800 Received: from ibch50.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA24840; Thu, 17 Nov 1994 15:34:18 +0100 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA17887; Thu, 17 Nov 1994 15:32:41 +0100 Date: Thu, 17 Nov 1994 15:32:41 +0100 From: jw@ibch50.inf.tu-dresden.de (Wittenberger) Message-Id: <9411171432.AA17887@ibch50.inf.tu-dresden.de> To: vsta@cisco.com Subject: intro paper On my last mail about the manuscript of a my intro talk avialable I got a couple of request to translate it into english. Done now for the parts of public interest. (There are a couple of comments made also, which are probably only of internal interest here.) I'm not to experienced in VSTa, so it may contain errors. (It's just what I understood.) I'd appreciate if someone (Andy?) could have a look at it and correct me where I'm wrong. Here is the URL: HTML: http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/doc.en/overview.html PostScript: http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/doc.en/overview.ps /joerg From vandys@glare.cisco.com Sat Nov 19 13:49:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA01050; Sat, 19 Nov 1994 13:49:08 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA10899 for ; Sat, 19 Nov 1994 14:12:11 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA19572; Sat, 19 Nov 1994 12:11:25 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411192211.AA19572@zang.kcc.hawaii.edu> Subject: scsi and filesystems To: vsta@cisco.com Date: Sat, 19 Nov 1994 12:11:23 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 583 I finally got the scsi driver working (at least the parts I've been dealing with seem to work). The driver is capable of reading in the partition tables and lets me read arbitrary blocks from the various partitions with the testsh (sector command). My next task is getting a filesystem up. My target is dos because so far this is the only filesystem that is supported by both amigados and vsta. Unfortunately the driver has been written with little endian machines in mind. Things just dont seem to be getting any easier for me :) Tim N. From vandys@glare.cisco.com Sun Nov 20 13:56:29 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA01159; Sun, 20 Nov 1994 13:56:27 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA03757; Sun, 20 Nov 1994 14:19:33 -0800 Message-Id: <199411202219.OAA03757@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@cisco.com Subject: Re: scsi and filesystems In-Reply-To: Your message of "Sat, 19 Nov 1994 12:11:23 -1000." <9411192211.AA19572@zang.kcc.hawaii.edu> Date: Sun, 20 Nov 1994 14:19:32 -0800 From: Andrew Valencia [newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:] >My next task is getting a filesystem up. My target is dos because >so far this is the only filesystem that is supported by both amigados >and vsta. Unfortunately the driver has been written with little >endian machines in mind. Things just dont seem to be getting any easier >for me :) Yes, quite a lack of vision on my part. It's just that I had no idea that VSTa would be ported to a 68k AND would still want to use a little endian DOS filesystem! You can probably steal the needed macros from the mtools package. Sorry, Andy From vandys@glare.cisco.com Mon Nov 21 02:31:03 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA01280; Mon, 21 Nov 1994 02:31:01 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA01056 for ; Mon, 21 Nov 1994 02:54:11 -0800 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); Mon, 21 Nov 1994 21:54:10 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA15156; Mon, 21 Nov 94 22:09:17 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA20749; Mon, 21 Nov 1994 21:55:45 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199411211055.AA20749@sour.sw.oz.au> Subject: R3000 paper To: vsta@cisco.com Date: Mon, 21 Nov 1994 21:55:44 +1100 (EST) X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au Precedence: special-delivery X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 889 Would anyone be interested in reading over a paper on the R3000 port of VSTa I've been working on? It's going to be submitted as as undergrad project sometime soon ... so any comments or suggestions would be greatly appreciated. Just send me a note if you're interested (it's OK if you don't know anything about the R3000 -- it's supposed to explain everything you need to know). On the subject of the R3000 port -- well, it's getting there slowly. I've basicly (hopefully!) finished all of the memory management and exception code. Some of the thread manipulation code still needs doing, and I/O hasn't been touched at all. If anyone is really keen to play around with the code as well, if I get a week or so of solid debugging in I could probably make a pre-pre-Alpha release. PS: If anyone happens to have an R3000 ICE they could lend me, just let me know :-) Cheers, Christopher. From vandys@glare.cisco.com Mon Nov 21 09:22:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA01323; Mon, 21 Nov 1994 09:22:40 -0800 Received: from chaph.usc.edu (chaph.usc.edu [128.125.253.133]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA20730 for ; Mon, 21 Nov 1994 09:45:49 -0800 Received: from aludra.usc.edu (antony@aludra.usc.edu [128.125.253.134]) by chaph.usc.edu (8.6.8.1/8.6.4) with ESMTP id JAA12880; Mon, 21 Nov 1994 09:45:47 -0800 Received: (antony@localhost) by aludra.usc.edu (8.6.8.1/8.6.7+ucs) id JAA28749; Mon, 21 Nov 1994 09:45:42 -0800 Date: Mon, 21 Nov 1994 09:45:40 -0800 (PST) From: Antony Halim Subject: Re: R3000 paper To: Christopher Fraser Cc: vsta@cisco.com In-Reply-To: <199411211055.AA20749@sour.sw.oz.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Nov 1994, Christopher Fraser wrote: > > Would anyone be interested in reading over a paper on the R3000 > port of VSTa I've been working on? It's going to be submitted as > as undergrad project sometime soon ... so any comments or suggestions > would be greatly appreciated. Just send me a note if you're interested > (it's OK if you don't know anything about the R3000 -- it's supposed to > explain everything you need to know). > > On the subject of the R3000 port -- well, it's getting there slowly. > I've basicly (hopefully!) finished all of the memory management > and exception code. Some of the thread manipulation code still > needs doing, and I/O hasn't been touched at all. If anyone is really > keen to play around with the code as well, if I get a week or so > of solid debugging in I could probably make a pre-pre-Alpha release. > > PS: If anyone happens to have an R3000 ICE they could lend me, > just let me know :-) > > Cheers, > > Christopher. > > Yes, I am interested in vsta and the R3000 architecture lately. So your paper will be perfect for me! But no, I don't have any R3000 h/w to lend you. All I have is just the SPIM (MIPS simulator) ;-) /antony From vandys@glare.cisco.com Mon Nov 21 13:45:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA01360; Mon, 21 Nov 1994 13:45:33 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA06667 for ; Mon, 21 Nov 1994 14:08:47 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA23582; Mon, 21 Nov 1994 12:07:57 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411212207.AA23582@zang.kcc.hawaii.edu> Subject: per page reference count. To: vsta@cisco.com Date: Mon, 21 Nov 1994 12:07:55 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 983 I'm getting a strange problem I cant figure out. When some processes die I get an assertion failure in free_pset(). The cause is a per-page structure that has a non-zero reference count. In this particular case it was the testsh process. I looked at the page sets before quitting the shell and I noticed that the highest block in the stack memory region (0x7fff0000 and up) had a reference count of two. Later on when the pages are dereferenced, the count drops to one and when the free_pset routine is called it catches this. I checked the other processes running at the same time and none of the others seemed to have stack pages with more than one reference. Why would the reference count on a stack page by 2? I dont think this error is due to me since this stuff is all handled in os/kern/* files which I have not modified. Is this a known problem? Has it since been fixed? (I'm using the old sources I got in september). Tim N. From vandys@glare.cisco.com Mon Nov 21 14:21:38 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01370; Mon, 21 Nov 1994 14:21:37 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA06604; Mon, 21 Nov 1994 14:44:50 -0800 Message-Id: <199411212244.OAA06604@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@cisco.com Subject: Re: per page reference count. In-Reply-To: Your message of "Mon, 21 Nov 1994 12:07:55 -1000." <9411212207.AA23582@zang.kcc.hawaii.edu> Date: Mon, 21 Nov 1994 14:44:48 -0800 From: Andrew Valencia [newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:] >Why would the reference count on a stack page by 2? I seem to recall a bug ages ago in which you could fault twice on an address and end up with two references even though there was only one atl. This was fixed in 4/19/94. >I dont think this error is due to me since this stuff is all >handled in os/kern/* files which I have not modified. Is this >a known problem? Has it since been fixed? (I'm using the old >sources I got in september). Another possibility is that your fault handling code is not getting read, write, and copy-on-write exactly right. Not as likely for ZFOD areas like the stack. Andy From vandys@glare.cisco.com Tue Nov 22 03:08:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA01451; Tue, 22 Nov 1994 03:08:08 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA14791 for ; Tue, 22 Nov 1994 03:31:23 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 22 Nov 94 12:31:22+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 22 Nov 94 12:31:55-0100 Date: 22 Nov 94 12:31:55-0100 From: Basile STARYNKEVITCH Message-Id: <9411221131.AA00777@rosser.serma.cea.fr> To: vsta@cisco.com Subject: about VSTa coding (name clash with Posix) and ext2fs Content-Length: 2759 Hello all, At home, i'm trying to port Linux ext2 filesystem to VSTa (by writing an ext2fs filesystem server). I'm using the e2fsprogs-0.5b and coding above its libext2. I'm actually developping under linux and cross-compiling (with gcc2.5.2 and binutils 2.5.2 targeted for VSTa) to VSta. A: I do have some remarks about VSTa coding: -------------------------------------------- 1. the errno EINTR EIO E* etc stuff is nearly a nightmare. In errors are strings -this is a good idea. But EINTR is defined as a string in and as a Posixly number in . I believe that this is annoying. I suggest that EINTR in should be ERRINTR (or even VSTA_ERRINTR) and defined as a string, living EINTR only in libc for Posixy camouflage. Also, for easier internationalization it should still be an indentifier like string (ie "ERR:INTERRUPT" instead of "got an interrupt") -i don't have at work the exact values but you see what i mean -someday we should be able to give the user an error message in his native language -eg "Interrompu" in French instead of "Interrupted". 2. Also the S_ISDIR macro (and similars) and S_IFDIR value should in my humble opinion only appear in since they are only for Libc. 3. ino_t should be typedef-ed in . B. my ext2fs file server. ------------------------- Also, i might once have my ext2fs in alpha state (i don't promise anything; i might also give up); currently i did handle correctly some FS_STAT requests. Is there somebody interrested in alpha testing? If yes, please email me. I do lack some tiny documentation about the filesystem protocols. I figured out some of them. I don't really understand what the FS_FID request is for. I don't have a really clear picture of what a client connection to a file server is exactly. Basically, i copied the dos_main routine of the dos fs and hacked it. If no one have any documentation about the filesystem protocol, i might end writing one but i need someone to proofread and correct me. All VSTa-ling and Linux-ing is done at home only so some names, ids, etc might be wrong. Also, i didn't recieve anything of the VSTa mailing list since more than a week. Is it normal? -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Tue Nov 22 05:39:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01464; Tue, 22 Nov 1994 05:39:03 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA18973 for ; Tue, 22 Nov 1994 06:02:18 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa12863; 22 Nov 94 14:02 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0r9vpJ-0003EOC; Tue, 22 Nov 94 14:04 GMT Message-Id: From: Dave Hudson Subject: Re: about VSTa coding (name clash with Posix) and ext2fs To: Basile STARYNKEVITCH Date: Tue, 22 Nov 1994 14:04:09 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9411221131.AA00777@rosser.serma.cea.fr> from "Basile STARYNKEVITCH" at Nov 22, 94 12:31:55 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: 2487 Hi Basile, Basile STARYNKEVITCH wrote: > > 1. the errno EINTR EIO E* etc stuff is nearly a nightmare. In > errors are strings -this is a good idea. But EINTR is > defined as a string in and as a Posixly number in > . I believe that this is annoying. I suggest that EINTR in > should be ERRINTR (or even VSTA_ERRINTR) and defined as a > string, living EINTR only in libc for Posixy camouflage. I think you'll find all of the EXXXX names clash somewhere - when I rewrote the POSIX emulation library code Andy and I discussed this. The eventual conclustion was that the POSIX emulation was exactly that - just an emulation, and that it's cleaner for servers to just use . What you might try though is separating code which wants to use the existing e2fs values and the server specific code that wants to use the VSTa strings. The POSIX emulation stuff should make it easy to translate the internal numerical representation into the VSTa string format. > 2. Also the S_ISDIR macro (and similars) and S_IFDIR value should in > my humble opinion only appear in since they are only for > Libc. > > 3. ino_t should be typedef-ed in . Well I was going to start POSIXising the headers a few months back when I did a lot of libc additions - I originally held off until 1.3.2 was out and haven't had too much time since. I'd like to get all of this straight by the time we reach 1.4. > B. my ext2fs file server. > ------------------------- > > Also, i might once have my ext2fs in alpha state (i don't promise > anything; i might also give up); currently i did handle correctly > some FS_STAT requests. Is there somebody interrested in alpha testing? > If yes, please email me. Yes I'd be interested :-) > I do lack some tiny documentation about the filesystem protocols. I > figured out some of them. I don't really understand what the FS_FID > request is for. I don't have a really clear picture of what a client > connection to a file server is exactly. Basically, i copied the > dos_main routine of the dos fs and hacked it. FIDs are used in the kernel (os/kern/mmap.c) to handle the caching of certain files, eg executables. Basically they just need to be unique IDs per server to allow the kernel to decide if it already has a mapping of a file. > Also, i didn't recieve anything of the VSTa mailing list since more > than a week. Is it normal? Seems to go quiet occasionally. Regards, Dave From vandys@glare.cisco.com Tue Nov 22 07:25:36 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01476; Tue, 22 Nov 1994 07:25:35 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id HAA13483; Tue, 22 Nov 1994 07:48:54 -0800 Message-Id: <199411221548.HAA13483@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Basile STARYNKEVITCH Cc: vsta@cisco.com Subject: Re: about VSTa coding (name clash with Posix) and ext2fs In-Reply-To: Your message of "22 Nov 1994 12:31:55 -0100." <9411221131.AA00777@rosser.serma.cea.fr> Date: Tue, 22 Nov 1994 07:48:53 -0800 From: Andrew Valencia [Basile STARYNKEVITCH writes:] >1. the errno EINTR EIO E* etc stuff is nearly a nightmare. In > errors are strings -this is a good idea. But EINTR is >defined as a string in and as a Posixly number in >. is a VSTa internal file. is POSIX. We expect that you code for one or the other. is not a proposed extension to POSIX, it was designed as a replacement for these POSIX functions. We've looked at making them coexist, but with the exception of the errno emulation code (which maps VSTa to POSIX and back) we inevitably find that the code is improved by using only one or the other. In your case my guess is that your main.c should use and everything else would use . Your main.c can use the existing errno mapping facilities (see libc/errno.c) when needed to turn the Linux code's return values back into VSTa strings. Regards, Andy From vandys@glare.cisco.com Tue Nov 22 12:29:24 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01503; Tue, 22 Nov 1994 12:29:19 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA12819 for ; Tue, 22 Nov 1994 12:50:59 -0800 Received: from ibch50.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA10677; Tue, 22 Nov 1994 18:19:33 +0100 Received: by ibch50.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03) id AA12003; Tue, 22 Nov 1994 18:17:02 +0100 Date: Tue, 22 Nov 1994 18:17:02 +0100 Message-Id: <9411221717.AA12003@ibch50.inf.tu-dresden.de> To: vsta@cisco.com Subject: what is the file hashed by a server From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch50.inf.tu-dresden.de Organisation: Technical Universtiy Dresden Hello, the answer of my question is probably simple. I don't understand how a server (dos for instance) keeps track in the actions. As far as I can see for a client which connects to a server a struct file is set up which is hashed under the handle of the sender (in fact this handle is the reference through which the client accessed the port). All access with this handle as sender modifies this struct file. So the server keeps track with file actions. But what happens on the second open? Sure, I can access 2 files at once from one thread. But I can't see where the server allocate a second struct file. Where I want to look? Thanx ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Tue Nov 22 14:48:34 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01515; Tue, 22 Nov 1994 14:48:31 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA06162; Tue, 22 Nov 1994 15:11:46 -0800 Message-Id: <199411222311.PAA06162@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com Subject: Re: what is the file hashed by a server In-Reply-To: Your message of "Tue, 22 Nov 1994 18:17:02 +0100." <9411221717.AA12003@ibch50.inf.tu-dresden.de> Date: Tue, 22 Nov 1994 15:11:45 -0800 From: Andrew Valencia [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] >As far as I can see for a client which connects to a server a struct >file is set up which is hashed under the handle of the sender (in fact >this handle is the reference through which the client accessed the >port). A new struct file is created when (1) a client connects to the server, or (2) when the open file is cloned. Cloning involves the kernel-generated message M_DUP, which calls dup_client(). Cloning happens during a fork(), as well as during an open() of a new file. An open() clones the client connection held in his mount table, and then walks it down the hierarchy to the desired path using FS_OPEN messages on the cloned file. >All access with this handle as sender modifies this struct file. So >the server keeps track with file actions. But what happens on the >second open? Sure, I can access 2 files at once from one thread. But I >can't see where the server allocate a second struct file. >Where I want to look? Threads share the same open file table. They also look like the same client from the perspective of the server. Only one thread at a time can have an I/O active through a particular open file. See the places in srv/dos/main.c where a "struct file" is malloc()'ed. This will be new_client() and dup_client(). Andy From vandys@glare.cisco.com Tue Nov 22 22:06:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA01542; Tue, 22 Nov 1994 22:06:40 -0800 Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id WAA06347 for ; Tue, 22 Nov 1994 22:30:03 -0800 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rABCK-000vIoC; Wed, 23 Nov 94 00:28 CST Received: from gocart.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rABCH-000uHrC; Wed, 23 Nov 94 00:28 CST Received: by gocart.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0rABCG-00036tC; Wed, 23 Nov 94 00:28 CST Message-Id: From: edm@gocart.eng.hou.compaq.com (Eddie McCreary) Subject: virtual flat frame buffer To: vsta@cisco.com Date: Wed, 23 Nov 94 0:28:52 CST X-Mailer: ELM [version 2.4dev PL11] Howdy folks, I've been playing around with *very* primitive graphics under Vsta and I'd like to share as much code as I can between the operations that work on memory bitmaps and the those that work on the screen. One thing that would go along way to simplifying things would be to setup a virtual flat frame buffer. The idea is that you memory map the amount of memory you have on your video card and when you try to read or write to a portion that isn't mapped in by the page registers, a page fault is generated and the code to handle video paging is invoked. Has anyone done this already? If so, would you mind sharing your code? If not, I'd appreciate anyone's suggestions on implementation details. I'll probably start looking at it in a day or so. thanks in advance, eddier -- .__o Ed McCreary "The Information Superhighway, sanitized _-\ <,- Compaq Computers for your protection." (*)/ (*) edm@twisto.compaq.com From vandys@glare.cisco.com Wed Nov 23 03:19:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA01591; Wed, 23 Nov 1994 03:19:52 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA22929 for ; Wed, 23 Nov 1994 03:43:13 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa08036; 23 Nov 94 11:43 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rAG5d-0003EwC; Wed, 23 Nov 94 11:42 GMT Message-Id: From: Dave Hudson Subject: Re: virtual flat frame buffer To: VSTa mailing list Date: Wed, 23 Nov 1994 11:42:21 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1719 Hi Eddie, Eddie McCreary wrote: > > I've been playing around with *very* primitive graphics under Vsta > and I'd like to share as much code as I can between the operations > that work on memory bitmaps and the those that work on the screen. > One thing that would go along way to simplifying things would be > to setup a virtual flat frame buffer. The idea is that you memory > map the amount of memory you have on your video card and when you > try to read or write to a portion that isn't mapped in by the > page registers, a page fault is generated and the code to handle > video paging is invoked. This was one of the ideas Gavin Nichol and I thought about earlier on this year - we actually thought it was a good way to go although it sacrifices a fair amount of performance. When I actually came to start work on the bitblt code though I found that as we only blitted data onto the screen and did all of the raster ops in system RAM it wasn't too much of a problem to just do the bank switching as we transfered the blt buffers to the video RAM. FWIW I think that using a flat space would be a neater solution as most new devices allow a flat linear mapping anyway :-) > Has anyone done this already? If so, would you mind sharing your > code? If not, I'd appreciate anyone's suggestions on implementation > details. I'll probably start looking at it in a day or so. I wouldn't have thought anyone else will have implemented this as it requires the intervention of the kernel page handler. I just took a quick look at the code and I'm pretty sure there's no mechanism there for a user-installed page fault handler (eg no way to tell the faulting process where we faulted, etc). Regards, Dave From vandys@glare.cisco.com Wed Nov 23 04:58:52 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA01609; Wed, 23 Nov 1994 04:58:51 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA25015 for ; Wed, 23 Nov 1994 05:22:14 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 23 Nov 94 14:22:06+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 23 Nov 94 14:22:42-0100 Date: 23 Nov 94 14:22:42-0100 From: Basile STARYNKEVITCH Message-Id: <9411231322.AA00760@rosser.serma.cea.fr> To: VSTa mailing list Subject: memory managment in servers? Content-Length: 2252 Hello all, I'm the guy who is trying to port the Linux ext2 filesystem to VSTa (currently 1.3.2). Assuming i will not give it up (i only work on it at home on my spare time) i have a question regarding memory managment in VSTa? 0. How does the swapping actually work. I believe i begin to understand the filesystem protocol designed for that (ie FS_ABSREAD FS_ABSWRITE and FS_FID) but i don't know how it is used? 1. Who is deciding the swapping (ie paging) policy? In other words, who decide of the paging strategy (FIFO, best fit, etc)? Is it the kernel or a dedicated swap server? (I think that Andys recommended me to not use it currently since there are some bugs in the swap code). 2. Assuming a filesystem server is booted (perhaps some day a foolish guy would even install my ext2fs as a boot server ie in /boot/boot.lst) i believe it can't swap, so it works (hence malloc) in physical memory, not in virtual memory. Can somebody confirm or explain if i'm wrong. 3. I wish and am prepared to have some kind of memory-low message. Does such a beast exists? I mean that my ext2fs allocate dynamically (block and inode) cache and free them on a age basis (ie it free the oldest unused block and inode in server memory -not on disk). So it is very easy to me to handle a PLEASE_GIVE_BACK(N Kbytes) message asking to free at least N kilobytes - i could also handle a simpler MEMORY_LOW message asking to free as much memory as i can. 4. What exactly are VSTa events and notifies? I guess they generalize posix signals in a message like fashion but i don't grap an exact picture of them (eg can they be blocked, delayed, are they reliable, sendable by anyone). Linuxing and VSTaling at home only. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Nov 23 05:23:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA01612; Wed, 23 Nov 1994 05:23:34 -0800 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA25675 for ; Wed, 23 Nov 1994 05:46:58 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id IAA04454; Wed, 23 Nov 1994 08:48:24 -0500 Date: Wed, 23 Nov 1994 08:48:24 -0500 From: Gavin Nicol Message-Id: <199411231348.IAA04454@ebt-inc.ebt.com> To: edm@gocart.eng.hou.compaq.com Cc: vsta@cisco.com In-Reply-To: (edm@gocart.eng.hou.compaq.com) Subject: Re: virtual flat frame buffer Dave and I have been working on bitblt, which provides a device independent API to clients that allows drawing, rotating, resising etc etc. This server will be what MADO uses to actually hold images of windows. I should have had this all done weeks ago, but work pressures just keep pushing me further behind... and I have been involved in making a fundamental change to the WWW as well... From vandys@glare.cisco.com Wed Nov 23 06:40:36 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA01628; Wed, 23 Nov 1994 06:40:33 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA28793 for ; Wed, 23 Nov 1994 07:03:53 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa18487; 23 Nov 94 15:03 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rAJEv-0003EwC; Wed, 23 Nov 94 15:04 GMT Message-Id: From: Dave Hudson Subject: Re: memory managment in servers? To: Basile STARYNKEVITCH Date: Wed, 23 Nov 1994 15:04:08 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9411231322.AA00760@rosser.serma.cea.fr> from "Basile STARYNKEVITCH" at Nov 23, 94 02:22:42 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: 3732 Hi, Basile STARYNKEVITCH wrote: > > 0. How does the swapping actually work. I believe i begin to > understand the filesystem protocol designed for that (ie FS_ABSREAD > FS_ABSWRITE and FS_FID) but i don't know how it is used? Erm, well at the moment the swapper doesn't work properly :-( (the principal's right though). The FS_ABSXXXX messages are used simply to acheive the same effect as FS_SEEK followed by either FS_READ or FS_WRITE. In fact none of the filesystem servers can be used as a swap device as swap devices must work as DMA servers - so far only wd, fd and cam can do this. FS_FID is used for handling file mapping and isn't used for swapping. FWIW FS_ABSXXXXX aren't just used by the swapper code, as they're also used by the libc code that handles misaligned I/O read()/write() requests (see libc/fdl.c) > 1. Who is deciding the swapping (ie paging) policy? In other words, > who decide of the paging strategy (FIFO, best fit, etc)? Is it the > kernel or a dedicated swap server? (I think that Andys recommended me > to not use it currently since there are some bugs in the swap code). The kernel makes the decisions, swapd just provides the mechanism for moving the pages. > 2. Assuming a filesystem server is booted (perhaps some day a foolish > guy would even install my ext2fs as a boot server ie in > /boot/boot.lst) i believe it can't swap, so it works (hence malloc) in > physical memory, not in virtual memory. Can somebody confirm or > explain if i'm wrong. Well it still uses VM, it's just that all of it's memory is always present :-) Essentially though (as I understand it) any server loaded at the initial boot (not through init) will never swap. > 3. I wish and am prepared to have some kind of memory-low > message. Does such a beast exists? I mean that my ext2fs allocate > dynamically (block and inode) cache and free them on a age basis (ie > it free the oldest unused block and inode in server memory -not on > disk). So it is very easy to me to handle a PLEASE_GIVE_BACK(N Kbytes) > message asking to free at least N kilobytes - i could also handle a > simpler MEMORY_LOW message asking to free as much memory as i can. This sounds a good idea. I'd been thinking about how to do this a while back and this seems much saner than my original thoughts :-) I assume that you're proposing this be a message, eg FS_MEMORY, so that we can ask any server that want's too listen for some more memory. I guess the question must be when and how such a message would be sent? I also wonder about how we'd decide which server to ask for memory - I don't know what the answer is though. > 4. What exactly are VSTa events and notifies? I guess they generalize > posix signals in a message like fashion but i don't grap an exact > picture of them (eg can they be blocked, delayed, are they reliable, > sendable by anyone). Basically events are like POSIX signals - hence the libc emulation code. "kill" is a special one however whose behaviour is hard coded in the kernel. Basically only a process with an ID that dominates the default ID on the process being sent the event should be able to send. This doesn't work properly on standard 1.3.2, but there again the namer permissions bug stops any non group sys.sys user from loging in and so this isn't obvious. One of the sets of patches I recently sent into Andy fix the ID handling and thus this bit of code should work properly on the next release. If I'm correct, we only check for events in a couple of places as we leave kernel code, and we only look for (and therefore process) events for the current process (we may have only just become the current process of course if we switched whilst in the kernel). Regards, Dave From vandys@glare.cisco.com Wed Nov 23 07:10:57 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01636; Wed, 23 Nov 1994 07:10:56 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA00124 for ; Wed, 23 Nov 1994 07:34:16 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 23 Nov 94 16:34:03+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 23 Nov 94 16:34:29-0100 Date: 23 Nov 94 16:34:29-0100 From: Basile STARYNKEVITCH Message-Id: <9411231534.AA00838@rosser.serma.cea.fr> To: dave@humbug.demon.co.uk Cc: vsta@cisco.com In-Reply-To: Subject: Re: memory managment in servers? Content-Length: 3214 Replying to my questions, >>>>> "Dave" == Dave Hudson writes: Dave> Hi, Basile STARYNKEVITCH wrote: >> 0. How does the swapping actually work. I believe i begin to >> understand the filesystem protocol designed for that (ie >> FS_ABSREAD FS_ABSWRITE and FS_FID) but i don't know how it is >> used? Dave> Erm, well at the moment the swapper doesn't work properly Dave> :-( (the principal's right though). The FS_ABSXXXX messages Dave> are used simply to acheive the same effect as FS_SEEK Dave> followed by either FS_READ or FS_WRITE. In fact none of the Dave> filesystem servers can be used as a swap device as swap Dave> devices must work as DMA servers - so far only wd, fd and Dave> cam can do this. FS_FID is used for handling file mapping Dave> and isn't used for swapping. Thanks for your explanation. I don't know what DMA servers are (i know what is DMA) but i can leave this question unanswered. >> 3. I wish and am prepared to have some kind of memory-low >> message. Does such a beast exists? I mean that my ext2fs >> allocate dynamically (block and inode) cache and free them on a >> age basis (ie it free the oldest unused block and inode in >> server memory -not on disk). So it is very easy to me to handle >> a PLEASE_GIVE_BACK(N Kbytes) message asking to free at least N >> kilobytes - i could also handle a simpler MEMORY_LOW message >> asking to free as much memory as i can. Dave> This sounds a good idea. I'd been thinking about how to do Dave> this a while back and this seems much saner than my original Dave> thoughts :-) I assume that you're proposing this be a Dave> message, eg FS_MEMORY, so that we can ask any server that Dave> want's too listen for some more memory. I guess the Dave> question must be when and how such a message would be sent? Dave> I also wonder about how we'd decide which server to ask for Dave> memory - I don't know what the answer is though. Yes. Of course, i meant a server able to give memory back (not wanting more memory -this is just malloc- but capable of free-ing some unimportant memory like buffer caches). I believe a FIFO discipline is enough -the kernel would send some FS_MEMORY messages until it has enough memory (or perhaps it could be a memory server?? which also implements malloc?? -or an mmap or sbrk primitive for allocating virtual|real memory- i'm not clear on that point). FS_MEMORY would be sent in turn to all servers until there is enough memory. I don't know how this FS_MEMORY (that i called MEMORY_LOW before) would be implemented. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Nov 23 07:36:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA01642; Wed, 23 Nov 1994 07:36:31 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA01236 for ; Wed, 23 Nov 1994 07:59:50 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa00561; 23 Nov 94 15:59 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rAK2I-0003ExC; Wed, 23 Nov 94 15:55 GMT Message-Id: From: Dave Hudson Subject: Re: memory managment in servers? To: VSTa mailing list Date: Wed, 23 Nov 1994 15:55:09 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1145 Hi, Basile STARYNKEVITCH wrote: > > Yes. Of course, i meant a server able to give memory back (not wanting > more memory -this is just malloc- but capable of free-ing some > unimportant memory like buffer caches). I believe a FIFO discipline is > enough -the kernel would send some FS_MEMORY messages until it has > enough memory (or perhaps it could be a memory server?? which also > implements malloc?? -or an mmap or sbrk primitive for allocating > virtual|real memory- i'm not clear on that point). FS_MEMORY would be > sent in turn to all servers until there is enough memory. I don't know > how this FS_MEMORY (that i called MEMORY_LOW before) would be > implemented. The message implementation is pretty simple, the biggest problem is how the kernel will decide that any particular process is a server and thus capable of responding to a FS_MEMORY message. I guess the easiest thing would be to check to see which processes have created a port and then go and try them. I have a feeling that this isn't quite so straightforward because the kernel isn't a normal client, but I guess this could be worked around. Regards, Dave From vandys@glare.cisco.com Wed Nov 23 08:44:35 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA01671; Wed, 23 Nov 1994 08:44:34 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA13016; Wed, 23 Nov 1994 09:07:58 -0800 Message-Id: <199411231707.JAA13016@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: VSTa mailing list Subject: Re: memory managment in servers? In-Reply-To: Your message of "Wed, 23 Nov 1994 15:55:09 GMT." Date: Wed, 23 Nov 1994 09:07:58 -0800 From: Andrew Valencia [Dave Hudson writes:] >The message implementation is pretty simple, the biggest problem is how the >kernel will decide that any particular process is a server and thus capable >of responding to a FS_MEMORY message. A bigger potential objection is that the VM page stealing system (when it works, admittedly! :->) does this anyway, and doesn't have to add another mechanism. Andy From vandys@glare.cisco.com Wed Nov 23 11:45:55 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01714; Wed, 23 Nov 1994 11:45:49 -0800 Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA16365 for ; Wed, 23 Nov 1994 12:09:15 -0800 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rANhE-000vOiC; Wed, 23 Nov 94 13:49 CST Received: from gocart.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rAKtA-000uIrC; Wed, 23 Nov 94 10:49 CST Received: by gocart.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0rAKtA-00036qC; Wed, 23 Nov 94 10:49 CST Message-Id: From: edm@gocart.eng.hou.compaq.com (Eddie McCreary) Subject: Re: virtual flat frame buffer To: gtn@ebt.com (Gavin Nicol) Date: Wed, 23 Nov 94 10:49:47 CST Cc: vsta@cisco.com In-Reply-To: <199411231348.IAA04454@ebt-inc.ebt.com>; from "Gavin Nicol" at Nov 23, 94 08:48:24 am X-Mailer: ELM [version 2.4dev PL11] > Dave and I have been working on bitblt, which provides a device > independent API to clients that allows drawing, rotating, resising > etc etc. This server will be what MADO uses to actually hold images > of windows. Yep, I've talked briefly to Dave about it. I'm anxious to take a look at it when it's ready. I should be able to port it for Compaq's QVision and AVGA cards. > I should have had this all done weeks ago, but work pressures just > keep pushing me further behind... and I have been involved in > making a fundamental change to the WWW as well... Unfortunately, I know far too well how you feel. regards, eddie -- .__o Ed McCreary "The Information Superhighway, sanitized _-\ <,- Compaq Computers for your protection." (*)/ (*) edm@twisto.compaq.com From vandys@glare.cisco.com Wed Nov 23 11:47:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01717; Wed, 23 Nov 1994 11:47:23 -0800 Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA16509 for ; Wed, 23 Nov 1994 12:10:48 -0800 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rANhy-000vNbC; Wed, 23 Nov 94 13:50 CST Received: from gocart.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rAL9b-000uJMC; Wed, 23 Nov 94 11:06 CST Received: by gocart.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0rAL9a-00036qC; Wed, 23 Nov 94 11:06 CST Message-Id: From: edm@gocart.eng.hou.compaq.com (Eddie McCreary) Subject: Re: virtual flat frame buffer To: dave@humbug.demon.co.uk (Dave Hudson) Date: Wed, 23 Nov 94 11:06:46 CST Cc: vsta@cisco.com In-Reply-To: ; from "Dave Hudson" at Nov 23, 94 11:42:21 am X-Mailer: ELM [version 2.4dev PL11] Hi Dave, > This was one of the ideas Gavin Nichol and I thought about earlier on this > year - we actually thought it was a good way to go although it sacrifices a > fair amount of performance. When I actually came to start work on the > bitblt code though I found that as we only blitted data onto the screen and > did all of the raster ops in system RAM it wasn't too much of a problem to > just do the bank switching as we transfered the blt buffers to the video RAM. > FWIW I think that using a flat space would be a neater solution as most new > devices allow a flat linear mapping anyway :-) Our video cards which are QVision compatible can do this. You can map the frame buffer to between 1Meg and 4Gig on 1Meg boundaries. I may actually look at doing this. What I'm playing with is for my own amusement and isn't intended to be distributed, so I don't mind introducing hardware dependencies at the lowest level. A question though. Enabling the hardware is a piece of cake. A few bits get toggled and everything is set. Can I then just mmap the address that I mapped the frame buffer to or do I also need to notify the memory manager of the range I'm using? Or is this a stupid question and mmap does that for me? My problem is that I have a mainly DOS background where I can do whatever the hell I want. > I wouldn't have thought anyone else will have implemented this as it > requires the intervention of the kernel page handler. I just took a quick > look at the code and I'm pretty sure there's no mechanism there for a > user-installed page fault handler (eg no way to tell the faulting process > where we faulted, etc). That's what I was worried about. thanks, eddie -- .__o Ed McCreary "The Information Superhighway, sanitized _-\ <,- Compaq Computers for your protection." (*)/ (*) edm@twisto.compaq.com From vandys@glare.cisco.com Wed Nov 23 14:20:07 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01746; Wed, 23 Nov 1994 14:20:06 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA09527; Wed, 23 Nov 1994 14:43:31 -0800 Message-Id: <199411232243.OAA09527@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: VSTa mailing list Subject: Re: memory managment in servers? In-Reply-To: Your message of "Wed, 23 Nov 1994 22:32:20 GMT." Date: Wed, 23 Nov 1994 14:43:31 -0800 From: Andrew Valencia [Dave Hudson writes:] >I didn't think we could reclaim memory from any of the boot servers this way >though? At the moment between my dos server seems to be the one server I'd >want to take some memory off when I get low (and conversely the one I'd like >to give more memory to when I'm running with lots of RAM to spare). A boot server gets a wired-down address space by default. However, I can't think of any reason why DOS couldn't relinquish that once the system's up. Andy From vandys@glare.cisco.com Wed Nov 23 14:12:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA01743; Wed, 23 Nov 1994 14:12:34 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id OAA23582; Wed, 23 Nov 1994 14:35:55 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa21361; 23 Nov 94 22:35 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rAQEe-0003lWC; Wed, 23 Nov 94 22:32 GMT Message-Id: From: Dave Hudson Subject: Re: memory managment in servers? To: Andrew Valencia Date: Wed, 23 Nov 1994 22:32:20 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199411231707.JAA13016@glare.cisco.com> from "Andrew Valencia" at Nov 23, 94 09:07:58 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: 851 Hi Andy, Andrew Valencia wrote: > > [Dave Hudson writes:] > > >The message implementation is pretty simple, the biggest problem is how the > >kernel will decide that any particular process is a server and thus capable > >of responding to a FS_MEMORY message. > > A bigger potential objection is that the VM page stealing system (when it > works, admittedly! :->) does this anyway, and doesn't have to add another > mechanism. I didn't think we could reclaim memory from any of the boot servers this way though? At the moment between my dos server seems to be the one server I'd want to take some memory off when I get low (and conversely the one I'd like to give more memory to when I'm running with lots of RAM to spare). I guess this is a whole new can of worms though (fs caching that is :-)) Regards, Dave From vandys@glare.cisco.com Thu Nov 24 06:07:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA01924; Thu, 24 Nov 1994 06:07:53 -0800 Received: from zephyr.cs.vu.nl (mmdf@zephyr.cs.vu.nl [130.37.16.3]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA27717 for ; Thu, 24 Nov 1994 06:31:22 -0800 Received: from brik.cs.vu.nl by zephyr.cs.vu.nl id aa16543; 24 Nov 94 15:31 MET Received: from jol29.cs.vu.nl by brik.cs.vu.nl id aa14141; 24 Nov 94 15:31 MET Date: Thu, 24 Nov 94 15:30:46 MET From: Ronald Oussoren To: vsta@cisco.com Subject: Stopping file servers Message-Id: <9411241530.aa06305@jol29.cs.vu.nl> Is there a way to cleanly stop a file server (that is stop the file server, and remove its name from the namer)? Ronald From vandys@glare.cisco.com Thu Nov 24 19:25:33 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA01964; Thu, 24 Nov 1994 19:25:32 -0800 Received: from blackdown.tiac.net (root@blackdown.tiac.net [199.3.134.114]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA12833 for ; Thu, 24 Nov 1994 19:49:04 -0800 Received: (from root@localhost) by blackdown.tiac.net (8.6.9/8.6.9) id WAA06629; Thu, 24 Nov 1994 22:49:32 -0500 Date: Thu, 24 Nov 1994 22:49:32 -0500 From: Super user Message-Id: <199411250349.WAA06629@blackdown.tiac.net> To: edm@gocart.eng.hou.compaq.com, vsta@cisco.com Subject: Re: virtual flat frame buffer ok...that's good to hear....I tried my account and it works... I show up now as kia.xensei.com....my domain is being registered though, right (blackdown.org)...apart from that everything looks great.. Cheers, Karl From vandys@glare.cisco.com Fri Nov 25 08:00:18 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA02020; Fri, 25 Nov 1994 08:00:17 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA27520; Fri, 25 Nov 1994 08:23:53 -0800 Message-Id: <199411251623.IAA27520@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: Stopping file servers In-Reply-To: Your message of "Thu, 24 Nov 1994 15:30:46 +0700." <9411241530.aa06305@jol29.cs.vu.nl> Date: Fri, 25 Nov 1994 08:23:52 -0800 From: Andrew Valencia [Ronald Oussoren writes:] >Is there a way to cleanly stop a file server (that is stop the file server, >and remove its name from the namer)? Namer currently does not track server deaths. All VSTa servers to this point are written so you can just kill them; I'd like to keep this semantic as UNIX's shutdown/fsck/lost+found tedium has caused a lot of grief over the years. I've looked at making namer track registered server deaths; so far I haven't been able to convince myself that a kernel mechanism is called for. As it stands now you try to mount the server name and you get a failure. With server death tracking you still get a failure. The only difference is that an "ls" of the namer will show the entry. Is it worth more ring 0 code just to cover a relatively minor exception condition? Andy FromFrom vandys@glare.cisco.com Sat Nov 26 07:40:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02164; Sat, vandys@glare.cisco.com Sat Nov 26 07:48:10 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02167; Sat, 26 Nov 1994 07:48:09 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA17764; Sat, 26 Nov 1994 08:11:51 -0800 Message-Id: <199411261611.IAA17764@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Robert Mayer - S 26 Nov 1994 07:40:16 -0800 Received: from dolly.par.univie.ac.at (dolly.par.univie.ac.at [131.130.70.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA08113 for ; Sat, 26 Nov 1994 08:03:56 -0800 Received: from doris.par.univie.ac.at (doris [131.130.70.22]) by dolly.par.univie.ac.at (8.6.9/8.6.9) with ESMTP id RAA05733 for ; Sat, 26 Nov 1994 17:03:51 +0100 From: Robert Mayer - Student Received: (robert@localhost) by doris.par.univie.ac.at (8.6.9/8.6.9) tudent Cc: vsta@cisco.com Subject: Re: Stopping file servers In-Reply-To: Your message of "Sat, 26 Nov 1994 17:03:47 +0100." <199411261603.RAA01327@doris.par.univie.ac.at> Date: Sat, 26 Nov 1994 08:11:51 -0800 From: Andrew Valencia [Robert Mayer - Student writes:] >> ... All VSTa servers to this >> point are written so you can just kill them; I'd like to keep this semantic >> as UNIX's shutdown/fsck/lost+found tedium has caused a lot of grief id RAA01327 for vsta@cisco.com; Sat, 26 Nov 1994 17:03:47 +0100 Date: Sat, 26 Nov 1994 17:03:47 +0100 Message-Id: <199411261603.RAA01327@doris.par.univie.ac.at> To: vsta@cisco.com Subject: Re: Stopping file servers [Andrew Valencia writes:] > Namer currently does not track server deaths. All VSTa servers to this > point are written so you can just kill them; I'd like to keep this semantic > as UNIX's shutdown/fsck/lost+found tedium has caused a lot of grief over the > years. Does this mean that all seover the >> years. >Does this mean that all servers should be synchronous or am I misunderstanding >this ? There are several ways to deal with this. Write ordering, synchronous operation, and database-style journalling all work. Actually, even sync-on- last-close is sufficient; I'm not looking for Tandem-style guarantees here! Andy rvers should be synchronous or am I misunderstanding this ? Regards, Robert. From vandys@glare.cisco.com Sun Nov 27 17:24:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA02315; Sun, 27 Nov 1994 17:24:48 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id RAA16895 for ; Sun, 27 Nov 1994 17:48:37 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id SAA05755 for vsta@cisco.com; Sun, 27 Nov 1994 18:48:32 -0700 Date: Sun, 27 Nov 1994 18:48:32 -0700 From: Gary Shea Message-Id: <199411280148.SAA05755@xmission.xmission.com> To: vsta@cisco.com Subject: user-level semaphores! I just got semaphores working at the user level! They are FIFO, and for now if the resource is not available, the requesting thread simply drops into the kernel (as opposed to spinning). I think that's the right thing to do for uniprocessors, but the code will soon have a per-semaphore spin count which will default to zero, but which the intrepid hacker may modify by function call. To the user a semaphore is just an integer returned by a call to tsema_new(). The functions tsema_wait() and tsema_signal() and tsema_free() all take that integer as argument. Threads are blocked until the requested resource is available. It should even work in out-of- memory situations, if one pays close attention to the return values! The semaphores are a bit of library code plus two system calls, recently renamed to tsleep(lock_t*) and twake(pid_t). If the lock_t pointer to tsleep is passed in null then it's a generic routine to put a thread to sleep. twake() will wake up any thread which is in the same address space as the calling thread. There's also a user-level spinlock, using the lock_t type, and I need some advice there. Ideally the assembly code that calls the test-and-set operation should simply return the result of that test, but I don't know how to pass a return value back so that C knows what I'm doing. Anyone want to enlighten me? Right now the assembly code spins until it gets the lock, but I want to put in a counter, and it seems silly to code it in assembly... easy enough, but silly. The last bit of work is the tricky stuff; I need to get the interrupt and event handling right in the tsleep(lock_t*) system call (which is a ripoff of p_sema). I'll probably be doing that in personal e-mail, unless folks really want to hear about this... Gary From vandys@glare.cisco.com Mon Nov 28 01:12:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA02373; Mon, 28 Nov 1994 01:12:09 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA27249 for ; Mon, 28 Nov 1994 01:35:58 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 28 Nov 94 10:35:56+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 28 Nov 94 10:36:35-0100 Date: 28 Nov 94 10:36:35-0100 From: Basile STARYNKEVITCH Message-Id: <9411280936.AA00952@rosser.serma.cea.fr> To: VSTa mailing list Cc: Dave Hudson , Markus Friedl Subject: the first ALPHA release of ext2fs VSTa 0.1 -for testers only Content-Length: 11360 Hello all, I'm annoucing the first alpha release of an ext2fs file server for VSTa. This is available by ftp to ftp://131.188.190.131/ with kind ftp hospitality from Markus Friedl (CIP 92) . I can also email gnu zipped uuencoded diff files to the e2fsprogs-0.5b-WIP.tar.gz distribution. ***************************************************************************** Announcing Extfs-VSTa 0.1 ALPHA (for testers only) -------------------------------------------------- This is the first announce of my first alpha release of extfs-VSTa, a port of Linux ext2fs file system to VSTa. This is *NOT* a public release, but only a release for ALPHA testers only. It is based upon (and contains) e2fsprogs-0.5b-WIP.tar.gz available on several Linux ftp sites. This is a derivative work of, since it is based upon, e2fs and libext2fs by Theodore Y. Ts'o and Remy Card (contained in this e2fsprogs-0.5b-WIP.tar.gz gnu zipped tar file). This is distributed as e2fs_0_1.tgz, a 341327 GNU zipped tar file containing the full modified e2fsprogs-0.5b-WIP.tar.gz file tree with my vsta extensions. or as e2fs.diff and e2fsvsta.diff as patches to be applied to the original e2fsprogs-0.5b-WIP.tar.gz. e2fs.diff (40070 bytes) contains the patches to e2fsprogs files (mostly adding #include ). e2fsvsta.diff ( 76449 bytes) is a patch file for creating the vsta specific source code files; it should be applied after the e2fs.diff patch file. I'm putting the files on ftp://131.188.190.131/incoming with kind permission of Markus Friedl (CIP 92)" . Following is the README file. ## file vstasrv/README -*-text-*- ## rcsid: $Id: README,v 0.1 1994/11/27 21:11:36 basile Exp $ EXT2FS-VSTA 0.1 first alpha release - an fileserver for the VSTa microkernel compatible with Linux Ext2Fs filesystems. *** THIS IS A FIRST ALPHA RELEASE *** about my port of ext2fs on Linux from Remy Card to VSTa. -------------------------------------------------------- Copyright 1994 (for the vstasrv/ subdirectory) by Basile STARYNKEVITCH (at home) 8, rue de la Faiencerie 92340 BOURG LA REINE France homephone: (33) [1] 4665-4553 (till 10pm) (south suburb of Paris, in France) 27th november 1994 work email: << basile@soleil.serma.cea.fr >> sometimes in 1995 this will change to << basile.starynkevitch@cea.fr >> but i don't know when this will happen. This is done for fun only at my spare time at home on my own i486/PC running Linux (the latest version, ie 1.1.66 today). the vstasrv/ subdirectory is my own code (released under GNU Public License, any version). This has no connection with my work (but i only have email at work, not yet at home). I don't have much time for this ext2fs server ported to VSTa. I don't promise anything (no warranty as usual), not even to enhance and/or maintain this code. This was cross-developped under Linux (edited with GNU emacs 19.28, cross-compiled with GNU gcc 2.6.2 targeted for VSTa with additionnal patches on ftp.cygnus.com: pub/embedded/, cross-linked with GNU binutils 2.5.2, using GNU make 3.72.1). My PC is home-assembled: i486DX2/66 on Orchid motherboard with 16Mb RAM, IDE and Scsi drives(total is 800Mb) and QIC-150 Scsi tape streamer. (And my wife and our 3 kids want to use the PC too!!) This was tested by booting VSTa 1.3.2 distribution. The only difference from the ftp-able VSTa 1.3.2 was a patched cons2 server for french keyboard support (ie AZERTYUIOP). I debugged mostly with DBPRINTF output (to stdout). ******************************************* goals and design ------------------------------------------- *** THIS IS A FIRST ALPHA RELEASE *** After emails from Bryan Ford , Francois-Rene Rideau , Remy.Card@masi.ibp.fr, and another kind person (T.T.?) whose email i've lost, i decided to look into e2fsprogs-0.5b-WIP.tar.gz. This is a derivative work of these, since it is based upon e2fs and libext2fs by Theodore Y. Ts'o and Remy Card. Having fun in coding is a goal. Simplicity of code is a design goal. Efficiency is not a goal. Robustness is not a goal neither (but i still hope this to be robust one day). Understanding what filesystems and microkernels are is also a goal. Don't expect this to be ever as good as ext2 native on Linux is! I'm writing it for fun, and to be able to read Linux data (and perhaps to write it someday, but currently this is for readonly filesystems). I looked (and somehow copied) into Linux ext2 code, obviously the libext2 code, and also the VSTa dos and vstafs fileservers code. Features include: cached inode and file blocks access (with a FIFO discipline) and a variable number of cached inodes and blocks (thru an hash table for cached inodes, an hash table for cached blocks, an hash table for clientconnection). Tentative mapping of Linux uid/gid and access mode into VSTa. Only regular files, directories and symlinks are handled. Other files (ie fifos, char&block devices) are ignored. Newlines can't figure in filenames. Source files are -with output from the wc word counter (lines, words, chars) The common include for server view (ie cached) of clientstate, inode, block: 300 1080 9050 ext2vsta.h The caching machinery -which does the physical IO of blocks and inodes (and also their cleaning): 408 1432 12470 cache.c The main routines. Contains filesystem and server initialization, and the main message dispatching routine, and many small message handling (ie FS_OPEN, FS_STAT, all client related stuff etc). 701 2411 18477 main.c The read and write routines. Currently, only reading routines are coded. This handles the FS_READ message (for regular files and symlinks): 256 1025 7858 rw.c The VSTa port IO manager for libext2 -interfacing to VSTa ports. 329 1618 11122 vsta_io.c Total is almost two thousand lines. I expect that another thousand is needed (ie for writing). 1994 7566 58977 total This does not include any of e2fs existing code, ie about seven thousand lines (including a patched include file). The caching (of blocks and inodes) is done as follow. We maintain an hash table of cached blocks and another hash table of cached inodes. Each has a reference count (it is a pity that C isn't garbage collected). To be removed from the cache, a block or inode should have a 0 refcount. At some times, aged blocks or inodes which hasn't been accessed are removed. Any access to a block or inode increment the refcount and update the age. Ages are simply measured by a counter, incremented every 16 messages recieved by the server. Caches are cleaned after message handling (ie at bottom of message handling look) so no block or inode is removed during message processing (which can hence use 0-refcounted blocks or inodes, eg temporary blocks in double indrect access). This could also handle an hypothetical FS_MEMORY message sent when memory is low to clean up server memory (such a message would be handled by flushing the cache). I didn't code the writing of files, etc. I suppose that written blocks or inodes should be written immediately. I'll be glad to hear suggestions about this. Also, filesystem checking is not done. ******************************************* running the ext2fs vsta server ------------------------------------------- *** THIS IS A FIRST ALPHA RELEASE *** Only READONLY ext2 filesystems are currently supported. This code can't write a single valid byte on an ext2 filesystem. However, it is buggy and could destroy your data. DON'T USE THIS CODE WITHOUT BACKUPS. IT COULD BREAK YOUR DATA (and perhaps your hardware!). Actually DON'T RUN THIS CODE except for testing (it gives tons of debugging outputs, at least when compiled with -DDEBUG). And please, read the code before running it! The running script is: (in a file /vsta/bin/testext2) #! /vsta/bin/ash -x /vsta/bin/ext2fs -r -i -p disk/wd:wd0_lxnat0 fs/ext2fs > /ext2out.tmp ## eof testext2 ## parameters and options are: -r : readonly filesystem -i : ignore all permission test -p disk/wd:wd0_lxnat0 : diskport is disk/wd:wd0_lxnat0 meaning the IDE first IDE disk (wd0) first linux native partiton (lxnat0). fs/ext2fs : the name given to the filesystem served by this server > /ext2out.tmp: tons of debugging output goes here (stdout) The mounted Linux partition is a Slackware root partition (contains / /lib /etc /bin but not /usr /var /tmp /home* which I have on separate partitions). The testing client script is: (in a file /vsta/bin/e2client) #! /vsta/bin/ash -x sleep 2 mount fs/ext2fs /m date fstab date >> /ext2out.tmp echo before stat and ls of /m >> /ext2out.tmp stat /m ls /m echo before stat and ls of /m/etc >> /ext2out.tmp stat /m/etc ls /m/etc echo before ls and cat of /m/etc/motd >> /ext2out.tmp ls /m/etc/motd cat /m/etc/motd echo testing a big copy of /m/bin/cp into /cplinux.tmp >> /ext2out.tmp cp /m/bin/cp /cplinux.tmp ## eof e2client ******************************************* testing the ext2fs vsta server ------------------------------------------- *** THIS IS A FIRST ALPHA RELEASE *** This code is NOT for general use. DON'T USE IT unless you read it and understood it. I don't know if there are some memory leaks. I don't know how to get the size of an active or sleeping process under VSTa. I didn't understand fully the VSTa filesystem protocol. I understood parts of it gradually, and i probably misunderstood some of it. I don't understand exactly how files are created, deleted, moved, etc in filesystem protocols terms. I didn't understand really what are VSTa permissions and capabilities. I didn't understand what are Ext2fs Access Control Lists (i believe these are not yet implemented). I tried to map unix uid/gid to VSTa ids and unix user,group,others modes to VSTa permissions, but my coding is a crude and untested guess. The -i server option bypasses all tests. If someone could explain me (or better yet, debug and/or recode my routines) how to map Posix UID/GID access modes to VSTa I will be grateful. I expect brave alpha testers to read the code, run it, and preferably send me patches or at least bug reports. They should expect or at least be prepared to lose their data. This didn't happen to me yet, or i didn't notice it (because this is currently a readonly filesystem server). Futures enhancements could be writing routines, less buggy permission routines, etc.. I don't promise anything. (I might give up or just might not have time to code). VSTaling and Linuxing at home only -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Mon Nov 28 05:55:46 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA02507; Mon, 28 Nov 1994 05:55:45 -0800 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id GAA11047 for ; Mon, 28 Nov 1994 06:19:38 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id JAA05126; Mon, 28 Nov 1994 09:20:24 -0500 Date: Mon, 28 Nov 1994 09:20:24 -0500 From: Gavin Nicol Message-Id: <199411281420.JAA05126@ebt-inc.ebt.com> To: shea@xmission.com Cc: vsta@cisco.com In-Reply-To: <199411280148.SAA05755@xmission.xmission.com> (message from Gary Shea on Sun, 27 Nov 1994 18:48:32 -0700) Subject: Re: user-level semaphores! This is what I used for semaphores in user space for MADO so far: static inline unsigned int set_semaphore(volatile unsigned int * p, unsigned int newval) { unsigned int semval = newval; __asm__ __volatile__ ("xchgl %2, %0\n" : /* outputs: semval */ "=r" (semval) : /* inputs: newval, p */ "0" (semval), "m" (*p) ); /* p is a var, containing an address */ return semval; } #define LOCK_SEMAPHORE(x) \ { \ while((x)) \ ; \ set_semaphore(&(x),1); \ } #define FREE_SEMAPHORE(x) set_semaphore(&(x),0); From vandys@glare.cisco.com Mon Nov 28 06:20:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA02511; Mon, 28 Nov 1994 06:20:30 -0800 Received: from cton.computone.com (cton.computone.com [160.77.1.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA11899; Mon, 28 Nov 1994 06:44:16 -0800 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0rC7J7-000ATNC; Mon, 28 Nov 94 09:43 EST Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Mon, 28 Nov 94 09:42 EST Date: Mon, 28 Nov 1994 09:42:46 -0500 (EST) From: David Johnson To: Andrew Valencia Cc: Ronald Oussoren , vsta@cisco.com Subject: Re: Stopping file servers In-Reply-To: <199411251623.IAA27520@glare.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Nov 1994, Andrew Valencia wrote: > [Ronald Oussoren writes:] > > >Is there a way to cleanly stop a file server (that is stop the file server, > >and remove its name from the namer)? > > Namer currently does not track server deaths. All VSTa servers to this > point are written so you can just kill them; I'd like to keep this semantic > as UNIX's shutdown/fsck/lost+found tedium has caused a lot of grief over the > years. > > I've looked at making namer track registered server deaths; so far I haven't > been able to convince myself that a kernel mechanism is called for. As it > stands now you try to mount the server name and you get a failure. With > server death tracking you still get a failure. The only difference is that > an "ls" of the namer will show the entry. Is it worth more ring 0 code just > to cover a relatively minor exception condition? > Seems that namer will need to handle deaths at least of servers which are across the network. Maybe this is indeed useful for local servers also to maintain consistency. It is also frustrating to find a failure which is not obvious. Since a remote user could kill a server (with appropriate permission) a local user would not know why an access is failing. If I am lost out in the weeds, let me know :) dave From vandys@glare.cisco.com Mon Nov 28 11:07:48 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA02556; Mon, 28 Nov 1994 11:07:46 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA14658; Mon, 28 Nov 1994 11:31:39 -0800 Message-Id: <199411281931.LAA14658@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: David Johnson Cc: Ronald Oussoren , vsta@cisco.com Subject: Re: Stopping file servers In-Reply-To: Your message of "Mon, 28 Nov 1994 09:42:46 EST." Date: Mon, 28 Nov 1994 11:31:38 -0800 From: Andrew Valencia [David Johnson writes:] >Seems that namer will need to handle deaths at least of servers which are >across the network. Maybe this is indeed useful for local servers also >to maintain consistency. It is also frustrating to find a failure which >is not obvious. Since a remote user could kill a server (with >appropriate permission) a local user would not know why an access is >failing. You appear to be confusing the issue of when namer is used. Once a connection is set up, the namer is out of the loop, so his knowledge or lack WRT server condition does not help a user who happens to have a service mounted and is trying to use it. The user will see I/O errors on his requests until he closes files, unmounts the mount point, and so forth. As a distinct issue, namer would continue to hold an entry for the server's port_name. When you tried to mount it, you'd get an error indicating that the port wasn't valid. What I *thought* we were talking about was whether it was very important to make the entry go away. Andy From vandys@glare.cisco.com Mon Nov 28 14:20:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA02582; Mon, 28 Nov 1994 14:20:08 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA10290 for ; Mon, 28 Nov 1994 14:44:03 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id QAA26783; Mon, 28 Nov 1994 16:43:59 -0600 Received: by mort (5.0/1.34) id AA00995; Mon, 28 Nov 1994 16:43:56 -0600 Date: Mon, 28 Nov 1994 16:43:56 -0600 Message-Id: <9411282243.AA00995@mort> To: vsta@cisco.com Subject: vsta mount tutorial Content-Length: 1586 Can someone give a short tutorial of how mounting works in vsta. I either don't understand it correctly, or I've got some misconceptions. First, I was under the impression that it was possible to mount a filesystem on top of a directory and still be able to see the existing directory (stackable or translucent filesystems). I haven't been able to figure out how to do this. Second, I've created a large file in the / directory on a dos filesystem with the mkfs_vfs program, and then run a vstafs server using it as the datastore. This works fine and I can mount it and use it (way cool!). I mounted it as /v and copied /vsta to /v. Then I tried mounting the vstafs filesystem on /vsta. That worked. So then I removed everything from the /vsta directory on the dos partition that wasn't needed for booting, and changed the inittab and fstab files to automatically start the vstafs and mount it on /vsta. After rebooting, things seemed okay, except that some things quit working properly. ps started giving weird results in the USR/SYS column, and vi and less started complaining about the terminal type not being found. Basically, it appered that for certain operations, the /vsta directory on the dos filesystem was being searched, and not the /vsta filesystem being served by the vstafs server. Any help in clearing up my understanding of this would be greatly appreciated. Thanks. Brett McCoy, UNIX Systems Administrator Computing and Network Services Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu From vandys@glare.cisco.com Mon Nov 28 15:35:24 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA02604; Mon, 28 Nov 1994 15:35:23 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA01060; Mon, 28 Nov 1994 15:59:13 -0800 Message-Id: <199411282359.PAA01060@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: brtmac@ksu.ksu.edu Cc: vsta@cisco.com Subject: Re: vsta mount tutorial In-Reply-To: Your message of "Mon, 28 Nov 1994 16:43:56 CST." <9411282243.AA00995@mort> Date: Mon, 28 Nov 1994 15:59:11 -0800 From: Andrew Valencia [brtmac@ksu.ksu.edu writes:] >First, I was under the impression that it was possible to mount a >filesystem on top of a directory and still be able to see the existing >directory (stackable or translucent filesystems). I haven't been able >to figure out how to do this. Yes, although this code has been exercised little. >Second, I've created a large file in the / directory on a dos >filesystem with the mkfs_vfs program, and then run a vstafs server >using it as the datastore. This works fine and I can mount it and >use it (way cool!). I mounted it as /v and copied /vsta to /v. >Then I tried mounting the vstafs filesystem on /vsta. That worked. >So then I removed everything from the /vsta directory on the dos >partition that wasn't needed for booting, and changed the inittab >and fstab files to automatically start the vstafs and mount it on >/vsta. Ballsy. I just started playing with vstafs again after a LONG time. I have some pretty good optimizations for I/O, but also hope to shake out some of the remaining problems. You used the "-p" flag when you made the filesystem, right? >After rebooting, things seemed okay, except that some things quit >working properly. ps started giving weird results in the USR/SYS >column, and vi and less started complaining about the terminal type >not being found. Basically, it appered that for certain operations, >the /vsta directory on the dos filesystem was being searched, and not >the /vsta filesystem being served by the vstafs server. ps giving weird results is puzzling--you're going to have to do some debug on *that* one. It sounds like this filesystem was not mounted when you thought it was. Without seeing the actual boot.lst, inittab, and fstab files I can't say for sure. >Any help in clearing up my understanding of this would be greatly >appreciated. vstafs is little used, and has definitely not been tried out as the /vsta fileserver when running from a DOS file. There are certainly going to be problems with I/O flushing, as so far as DOS can tell the vstafs server is just holding some file open indefinitely--so he won't be doing I/O on it the way vstafs thinks his "disk" would. A fun configuration to get going, but be prepared to do some debugging along the way. Also, vstafs is a lightly used server so far as I can tell. I just got a dedicated partition for it onto my central development machine, so expect more activity on it in the near future. Andy From vandys@glare.cisco.com Mon Nov 28 16:37:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA02611; Mon, 28 Nov 1994 16:37:06 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA17582 for ; Mon, 28 Nov 1994 17:00:57 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA02670; Mon, 28 Nov 1994 14:06:58 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411290006.AA02670@zang.kcc.hawaii.edu> Subject: a.out formats, exec and amiga. To: vsta@cisco.com Date: Mon, 28 Nov 1994 14:06:57 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1878 Ok. I finally figured out what is going wrong with exec() on my system and need some advice. Up till now I have been using NMAGIC format a.out files. The reason is that I have example code that uses NMAGIC (loadbsd for amiga) so I stuck with it. The format of my files are: a.out header (32 bytes) text section, starting at address 0x1000 data section, starting at address 0x40000 more stuff I dont use This differs in the format the i386 port uses in that the a.out header isnt part of the text section. (The boot process expects that the a.out header is included in the text segment, so for the crt0srv.o I included 32 null bytes which get copied over by the boot program). My problem is this: exec() gets passed a list of regions to map into the address space. These areas are characterized by starting address, port used to reference file and the offset of that segment into the file (in pages). There is no way I can get offset 32bytes into the file mapped to page 1. (Even worse, the data section of the file is not a multiple of pages in length). Basically I have to switch to another file format. I noticed that execv() expects a ZMAGIC file. I assume this is what everyone is using. When I compiled a file with ZMAGIC format I got the first 32 bytes as the a.out header, followed by padding to a page, and then text starting at 1024. Is this the format file that is being used? If so I suppose I'll be switching over to this format. (Btw. I noticed that the libraries handle all the details of file format and the kernel knows only about sending messages to ports to get pages of data. This is very nice in that it allows the system to be adapted to run other format files, but it doesn't seem the kernel itself is flexible enough to support other file formats if it cant handle byte-offsets.) Tim N. From vandys@glare.cisco.com Mon Nov 28 16:53:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA02617; Mon, 28 Nov 1994 16:53:37 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id RAA18400 for ; Mon, 28 Nov 1994 17:17:25 -0800 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id RAA21073; Mon, 28 Nov 1994 17:17:23 -0800 Message-Id: <199411290117.RAA21073@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Mon, 28 Nov 1994 17:17:23 PST In-Reply-To: newsham@zang.kcc.hawaii.edu (Tim Newsham)' <9411290006.AA02670@zang.kcc.hawaii.edu> a.out formats, exec and amiga. Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: newsham@zang.kcc.hawaii.edu (Tim Newsham), vsta@cisco.com Subject: Re: a.out formats, exec and amiga. From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Subject: a.out formats, exec and amiga. > then text starting at 1024. Is this the format file that is being > used? If so I suppose I'll be switching over to this format. This might not help, but if you compile and link with "-N" I believe a.out wil use zero based addressing. Another good reason to switch to COFF or ELF... The Linux loader can load a.out, coff, or elf. - rob - From vandys@glare.cisco.com Mon Nov 28 17:14:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA02624; Mon, 28 Nov 1994 17:14:14 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA19208; Mon, 28 Nov 1994 17:38:00 -0800 Received: by zang.kcc.hawaii.edu (5.0/V1.0) id AA03213; Mon, 28 Nov 1994 15:37:15 -1000 From: newsham@zang.kcc.hawaii.edu (Tim Newsham) Message-Id: <9411290137.AA03213@zang.kcc.hawaii.edu> Subject: Re: a.out formats, exec and amiga. To: vandys@cisco.com (Andrew Valencia) Date: Mon, 28 Nov 1994 15:37:14 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <199411290125.RAA07628@glare.cisco.com> from "Andrew Valencia" at Nov 28, 94 05:25:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2217 > VSTa is designed assuming that the a.out format can be executed after simply > memory mapping its pages. It sounds like your format uses text relocated > for 0x1000 but offset 0x20 bytes in the file image. A simple but shameless > way to deal with this is to hack your DOS server so that files which start > with the magic a.out number are fiddled within dos_read() so that the file > layout appears to be page aligned. Dont want to hack each possible file server. I was thinking that if it was decided that a certain non-aligned format was definitely needed, an extra layer (stackable filesystem) could be added which does this translation. Only the exec*() routines need know about this system. > Less desirable is to teach the VSTa VM system how to do unaligned I/O for > mapped files. You'll have to think hard concerning the page cache part. I was thinking it might be possible for the VM system to add a byte offset to all requests it sends to a filesystem server (just like it adds a page-offset when requesting pages right now). > The best strategy is probably to use the appropriate ld flags and generate > something with page aligned file organization. Yes. This is what I think too. You mentioned earlier that the linker being used is special (to match the linker that was originally used from dos when the system was being brought up). That the a.out header was part of the text segment. I've been trying to think of how this could be done with just ld flags but I cant think of a way to do it. Maybe I should get a copy of the vsta linker. What exactly are the differences between this loader and the normal (bsd) loader? Alternatively I could just use the ZMAGIC format my loader supports which seems to put the a.out header at virtual address 0 and the first text page at virtual address one with the file image being identical to the memory image (at least for the first segment). Then exec*() would just set the page offset to 1 and starting address as 0x1000. The drawback of the second approach is that most of a page (0x1000 - 0x20) bytes are wasted. This hits worst for the boot servers since thats an extra page, in memory, locked down, that is being used. > Andy From vandys@glare.cisco.com Mon Nov 28 17:01:35 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA02621; Mon, 28 Nov 1994 17:01:30 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA07628; Mon, 28 Nov 1994 17:25:17 -0800 Message-Id: <199411290125.RAA07628@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Cc: vsta@cisco.com Subject: Re: a.out formats, exec and amiga. In-Reply-To: Your message of "Mon, 28 Nov 1994 14:06:57 -1000." <9411290006.AA02670@zang.kcc.hawaii.edu> Date: Mon, 28 Nov 1994 17:25:16 -0800 From: Andrew Valencia [newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:] >Up till now I have been using NMAGIC format a.out files. The reason >is that I have example code that uses NMAGIC (loadbsd for amiga) so >I stuck with it. The format of my files are: VSTa is designed assuming that the a.out format can be executed after simply memory mapping its pages. It sounds like your format uses text relocated for 0x1000 but offset 0x20 bytes in the file image. A simple but shameless way to deal with this is to hack your DOS server so that files which start with the magic a.out number are fiddled within dos_read() so that the file layout appears to be page aligned. Less desirable is to teach the VSTa VM system how to do unaligned I/O for mapped files. You'll have to think hard concerning the page cache part. The best strategy is probably to use the appropriate ld flags and generate something with page aligned file organization. Andy From vandys@glare.cisco.com Tue Nov 29 03:30:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA02730; Tue, 29 Nov 1994 03:30:37 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA12457 for ; Tue, 29 Nov 1994 03:54:33 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa18934; 29 Nov 94 11:54 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rCR5l-00038lC; Tue, 29 Nov 94 11:51 GMT Message-Id: From: Dave Hudson Subject: Re: a.out formats, exec and amiga. To: Tim Newsham Date: Tue, 29 Nov 1994 11:51:29 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9411290006.AA02670@zang.kcc.hawaii.edu> from "Tim Newsham" at Nov 28, 94 02:06:57 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: 948 Hi Tim, > > Basically I have to switch to another file format. I noticed that > execv() expects a ZMAGIC file. I assume this is what everyone is > using. When I compiled a file with ZMAGIC format I got the first > 32 bytes as the a.out header, followed by padding to a page, and > then text starting at 1024. Is this the format file that is being > used? If so I suppose I'll be switching over to this format. We don't really use ZMAGIC - we're actually using QMAGIC, although this may not be entirely evident from the ld.c sources. I know Andy's done a bit of additional work on ld.c since I did some patches just before and after the 1.3.2 release so I'll let him comment on those (although I don't think they affect this case). The standard 1.3.2 version of ld has a bug which didn't get the QMAGIC text page alignment right if we were within 32 bytes of the end of a page (the problem with 1.3.2's rs232 server). Regards, Dave From vandys@glare.cisco.com Tue Nov 29 19:55:02 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.3.78]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA02793; Tue, 29 Nov 1994 19:55:00 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA09341; Tue, 29 Nov 1994 20:17:50 -0800 Message-Id: <199411300417.UAA09341@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: Tim Newsham , vsta@amri.cisco.com Subject: Re: a.out formats, exec and amiga. In-Reply-To: Your message of "Tue, 29 Nov 1994 11:51:29 GMT." Date: Tue, 29 Nov 1994 20:17:50 -0800 From: Andrew Valencia [Dave Hudson writes:] >... The standard 1.3.2 version of ld has a bug which didn't >get the QMAGIC text page alignment right if we were within 32 bytes of the >end of a page (the problem with 1.3.2's rs232 server). Go ahead and port the standard 1.3.2 version--my patches are minimal and won't be needed to get things running. Hacking pview's so they have a byte offset is pretty ugly. The problem is that the VM page cache would no longer match the contents of the file. It would really be a lot nicer if your port could honor a demand-page format of a.out. Let me know if using VSTa's ld looks too nasty. I have a 68k cross tool set for both i386/FreeBSD and Sparc/SunOS, so I could build some stuff for you if it's a simple matter of bootstrapping. Oh yes, you were wondering about the linker. It's not special; it's a pretty simple port of the GNU binutils. It's a common trick that the first 4K of an a.out is mapped to 0x1000, the a.out header is thus the first 0x20 bytes, and the start address is 0x1020. This catches NULL pointer dereferences, leaves pages from the a.out mapped on even page addresses, and doesn't blow extra filespace for the a.out header. Data starts at the first 4 meg boundary above the end of text. This allows an old trick where the 2nd level PTE's for text can be shared among all programs running the same a.out. VSTa uses this organization but doesn't (currently) implement the optimization. Regards, Andy From vandys@glare.cisco.com Wed Nov 30 04:31:04 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA02854; Wed, 30 Nov 1994 04:31:02 -0800 Received: from pamir.inria.fr (pamir.inria.fr [192.93.2.24]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA18535 for ; Wed, 30 Nov 1994 04:55:05 -0800 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 30 Nov 94 13:55:03+0100 X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; Relayed; 30 Nov 94 13:53:49-0100 Date: 30 Nov 94 13:53:49-0100 From: Basile STARYNKEVITCH Message-Id: <9411301253.AA00730@rosser.serma.cea.fr> To: VSTa mailing list Subject: ext2fs VSTa 0.1 - ALPHA ftp site Reply-To: basile.starynkevitch@cea.fr Content-Length: 1424 Thanks to the courtesy of Markus Friedl (CIP 92) , my first alpha release of Ext2Fs VSTa 0.1 is available in ftp://131.188.190.131/pub/VSTa/e2fs Annoucment -rw-r--r-- 1 root ftp 10322 Nov 28 10:16 e2fs.ann Diff to e2fsprogs-0.5b-WIP for includes -rw-r--r-- 1 root ftp 40070 Nov 28 10:16 e2fs.dif Diff to e2fsprogs-0.5b-WIP for the VSTa server -rw-r--r-- 1 root ftp 76449 Nov 28 10:16 e2fsvsta.dif full tar gnu zipped file -rw-r--r-- 1 root ftp 341327 Nov 28 10:16 e2fs_0_1.tgz So if you want to test this early alpha release either get e2fsprogs-0.5b-WIP.tar.gz from a good Linux ftp site and then apply patches e2fs.dif followed by e2fsvsta.dif, or just get and extract the e2fs_0_1.tgz. this is an alpha release for testers only -- VSTa-ling and Linux-ing at home only Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile.starynkevitch@cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From vandys@glare.cisco.com Wed Nov 30 22:54:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA02944; Wed, 30 Nov 1994 22:54:03 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id XAA10939 for ; Wed, 30 Nov 1994 23:18:13 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id VAA12229 for vsta@cisco.com; Wed, 30 Nov 1994 21:17:27 -1000 From: Tim Newsham Message-Id: <199412010717.VAA12229@zang.kcc.hawaii.edu> Subject: fork() problems. To: vsta@cisco.com Date: Wed, 30 Nov 1994 21:17:26 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3517 I'm having problems again. I know, I know, its hard to believe. "Tim is actually having problems?" Well its true :) It seems I can fork()/wait()/exit() ok (most of the time) as done by the "fork" command in the testsh. The second time I issue the command, however, the system just dies. It dies so hard that the hardclock() stops running (I have it print dots to the screen so I know when something goes bad). The fork() command is behaving properly the first time. I know this for sure because I am able to fork off a child and exec a file (finally got that working after switching to the VSTa ld). My guess is that something is going bad in the exit routines. I did check the process table after the fork()/exit() and the table seemed to still be in tact. In reviewing things in machproc.c I've run across some questions: in dup_stack(): /* * New entity returns with 0 value; ESP is one lower so that * the resume() path has a place to write its return address. * This simulates the normal context switch mechanism of * setjmp/longjmp. */ new->t_kregs->eip = (ulong)retuser; new->t_kregs->ebp = (ulong)(new->t_uregs); new->t_kregs->esp = (new->t_kregs->ebp) - sizeof(ulong); new->t_uregs->eax = 0; I'm unclear on why the stack pointer is decremented by a word. This buffer is later used by retuser() to warp to the new context (restore registers from t_kregs). When the longjmp occurs the instruction pointer gets set to "retuser" which causes the program to enter the retuser() function (again). How does a process continue execution if it keeps warping back to retuser()? What is the function of ebp? I don't believe the 68k has an analagous register (a dedicated one at least). The 68k uses the link command at the entry of a function which acts similarly to ebp (correct?). If the longjmp warps to a function that does this then the link register doesnt have to be set does it? At any rate here is the code I am working with right now: /* * New entity returns with 0 value; SP is one lower so that * the resume() path has a place to write its return address. * This simulates the normal context switch mechanism of * setjmp/longjmp. */ new->t_kregs->pc = (ulong)retuser; new->t_kregs->sp = ((ulong)(new->t_uregs)) - sizeof(ulong); new->t_uregs->f_regs[REG_D0] = 0; you'll notice this is basically just a blind copy of the above. in resume(): /* * Make kernel stack come in on our own stack now. This * isn't used until we switch out to user mode, at which * time our stack will always be empty. * XXX esp is overkill; only esp0 should ever be used. */ tss->esp0 = tss->esp = (ulong) ((char *)(t->t_kstack) + KSTACK_SIZE); This one has me really confused. I'm not to clear on what the tss does. In my port I have this stuff commented out. I have a feeling this has something to do with my problems and the 1 word space left on the stack after the longjmp. What amazes me is that even for my limited understanding of this that my port is actually working. Tasks are switching in and out fine and I have one process which does a tfork() successfully and I can do one fork()/exec() pair fine (although not two in a row). My brain is hurting right now, I hope that most of this post has some coherence. Tim N. From vandys@glare.cisco.com Thu Dec 1 00:45:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA02954; Thu, 1 Dec 1994 00:45:25 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA14865 for ; Thu, 1 Dec 1994 01:09:32 -0800 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); Thu, 01 Dec 1994 20:09:29 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA13822; Thu, 1 Dec 94 20:29:31 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA28404; Thu, 1 Dec 1994 20:11:07 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199412010911.AA28404@sour.sw.oz.au> Subject: Re: fork() problems. To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Date: Thu, 1 Dec 1994 20:11:07 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: <199412010717.VAA12229@zang.kcc.hawaii.edu> from "Tim Newsham" at Nov 30, 94 09:17:26 pm X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au Precedence: special-delivery X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 6146 I am by no means a i386 guru ... any or all of this could be wrong! Hopefully I can help clear up some of the user/kernel state confusion ... But I thought Tim Newsham said: > > > I'm having problems again. I know, I know, its hard to believe. > "Tim is actually having problems?" Well its true :) Haven't you finished it *yet*? Sheesh! :-) > It seems I can fork()/wait()/exit() ok (most of the time) as done > by the "fork" command in the testsh. The second time I issue the > command, however, the system just dies. It dies so hard that the > hardclock() stops running (I have it print dots to the screen so > I know when something goes bad). The fork() command is behaving > properly the first time. I know this for sure because I am able > to fork off a child and exec a file (finally got that working after > switching to the VSTa ld). My guess is that something is going > bad in the exit routines. I did check the process table after the > fork()/exit() and the table seemed to still be in tact. In reviewing > things in machproc.c I've run across some questions: > > in dup_stack(): > /* > * New entity returns with 0 value; ESP is one lower so that > * the resume() path has a place to write its return address. > * This simulates the normal context switch mechanism of > * setjmp/longjmp. > */ > new->t_kregs->eip = (ulong)retuser; > new->t_kregs->ebp = (ulong)(new->t_uregs); > new->t_kregs->esp = (new->t_kregs->ebp) - sizeof(ulong); > new->t_uregs->eax = 0; > > I'm unclear on why the stack pointer is decremented by a word. (I not 100% certain, but I'm fairly sure this is right) When setjmp() is called to save the kernel state of a thread, esp points to the return address in the calling function. This is standard i386 calling convention. This is the value of esp saved in the jmpbuf (in this case the jmpbuf is t_uregs). longjmp() loads the esp value from the trapframe and saves the return address at where esp points to (note that it's doesn't push, it overwrites). The last thing it does is execute a ret instruction which pops this return address off the stack. > This buffer is later used by retuser() to warp to the new context > (restore registers from t_kregs). Not really. t_kregs is the *kernel* state of the thread as saved by setjmp (or set up by dup_stack). resume() is used to load this. The user state is stored in a trapframe and loaded by retuser(). > When the longjmp occurs the > instruction pointer gets set to "retuser" which causes the program > to enter the retuser() function (again). How does a process > continue execution if it keeps warping back to retuser()? The above should help clarify this ... basicly it's because there is a distinction between the kernel and user state of a thread. When a thread enters the kernel (via and exception, interrupt, system call or whatever) its user state is saved on the kernel stack in the form of a trapframe. If the kernel decides it needs to jump to a different thread it (essentially) saves the *kernel* state of the thread in t_kregs and loads new state out of a different threads' t_kregs. This new thread returns to user via retuser(). > What is the function of ebp? I don't believe the 68k has an > analagous register (a dedicated one at least). The 68k uses > the link command at the entry of a function which acts similarly > to ebp (correct?). If the longjmp warps to a function that > does this then the link register doesnt have to be set does it? ebp is the frame pointer -- I don't _think_ it has to be used at all, but it can be useful for debugging. But I'm not really sure, my 386 book doesn't talk about it much other than the enter instruction fiddling it as per the standard i386 calling conventions. I'm not sure what's done on the 68k with the frame pointer either. (Incidentally, the R3000 does away with frame pointers all together. Well behaved functions decrement all they need from the stack in one go at the beginning. This value is stored as part of the debugging info ... so if a debugger wants to walk up the stack it just has to look up the frame size for the current function.) > At any rate here is the code I am working with right now: > > /* > * New entity returns with 0 value; SP is one lower so that > * the resume() path has a place to write its return address. > * This simulates the normal context switch mechanism of > * setjmp/longjmp. > */ > new->t_kregs->pc = (ulong)retuser; > new->t_kregs->sp = ((ulong)(new->t_uregs)) - sizeof(ulong); > new->t_uregs->f_regs[REG_D0] = 0; > > you'll notice this is basically just a blind copy of the above. What does your setjmp/longjmp do? > in resume(): > /* > * Make kernel stack come in on our own stack now. This > * isn't used until we switch out to user mode, at which > * time our stack will always be empty. > * XXX esp is overkill; only esp0 should ever be used. > */ > tss->esp0 = tss->esp = (ulong) > ((char *)(t->t_kstack) + KSTACK_SIZE); > > This one has me really confused. I'm not to clear on what the tss > does. In my port I have this stuff commented out. I have a feeling > this has something to do with my problems and the 1 word space left > on the stack after the longjmp. I think this is the kernel stack which the i386 switches to on receipt of an interrupt/exception/whatever. I believe the 68k has a supervisor stack of some description to do this. If you're current doing it on the user stack you shoudln't, because you can't trust it to be right. > What amazes me is that even for my limited understanding of this > that my port is actually working. Tasks are switching in and out > fine and I have one process which does a tfork() successfully and > I can do one fork()/exec() pair fine (although not two in a row). I'm quite impressed! My R3000 port has never successfully made it into user mode yet let alone done fork()/exec() ... Cheers, Christopher. From vandys@glare.cisco.com Thu Dec 1 01:47:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA02962; Thu, 1 Dec 1994 01:47:24 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id CAA16337 for ; Thu, 1 Dec 1994 02:11:34 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id AAA12620; Thu, 1 Dec 1994 00:10:37 -1000 From: Tim Newsham Message-Id: <199412011010.AAA12620@zang.kcc.hawaii.edu> Subject: Re: fork() problems. To: chrisf@sour.sw.oz.au (Christopher Fraser) Date: Thu, 1 Dec 1994 00:10:36 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <199412010911.AA28404@sour.sw.oz.au> from "Christopher Fraser" at Dec 1, 94 08:11:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5288 > (I not 100% certain, but I'm fairly sure this is right) > > When setjmp() is called to save the kernel state of a thread, esp > points to the return address in the calling function. This is > standard i386 calling convention. This is the value of esp saved > in the jmpbuf (in this case the jmpbuf is t_uregs). longjmp() loads > the esp value from the trapframe and saves the return address at > where esp points to (note that it's doesn't push, it overwrites). > The last thing it does is execute a ret instruction which pops this > return address off the stack. yes I understand the distinction between the threads kernel and user saved state. > > This buffer is later used by retuser() to warp to the new context > > (restore registers from t_kregs). > > Not really. t_kregs is the *kernel* state of the thread as saved > by setjmp (or set up by dup_stack). resume() is used to load this. > The user state is stored in a trapframe and loaded by retuser(). > > > When the longjmp occurs the > > instruction pointer gets set to "retuser" which causes the program > > to enter the retuser() function (again). How does a process > > continue execution if it keeps warping back to retuser()? argh! somehow I confused retuser (locore.s) and resume() (machproc.c). Resume() does the warp out to another context, retuser does the return to user-land, and this all makes sense (of course it does :). Ok. That clears up a few things. > > At any rate here is the code I am working with right now: > > > > /* > > * New entity returns with 0 value; SP is one lower so that > > * the resume() path has a place to write its return address. > > * This simulates the normal context switch mechanism of > > * setjmp/longjmp. > > */ > > new->t_kregs->pc = (ulong)retuser; > > new->t_kregs->sp = ((ulong)(new->t_uregs)) - sizeof(ulong); > > new->t_uregs->f_regs[REG_D0] = 0; > > > > you'll notice this is basically just a blind copy of the above. > > What does your setjmp/longjmp do? my setjmp: .globl _setjmp _setjmp: movl sp@(4), a0 | get pointer moveml #0xfefe, a0@ | save a1-a7/d1-d7 movl sp@, a0@(56) | store return address movel #0, d0 | return value rts Basically saves all registers except d0 and a0. This is because d0 just changes again at the end of longjmp (return value) and a0 is used as scratch anyway (so I use it as scratch). It also saves the return value. My longjmp is also pretty simple: .globl _longjmp _longjmp: movl sp@(8), d0 | get return value movl sp@(4), a0 | get pointer moveml a0@, #0xfefe | restore a1-a7/d1-d7 movl a0@(56), sp@ | restore return address rts > > in resume(): > > /* > > * Make kernel stack come in on our own stack now. This > > * isn't used until we switch out to user mode, at which > > * time our stack will always be empty. > > * XXX esp is overkill; only esp0 should ever be used. > > */ > > tss->esp0 = tss->esp = (ulong) > > ((char *)(t->t_kstack) + KSTACK_SIZE); > > > > This one has me really confused. I'm not to clear on what the tss > > does. In my port I have this stuff commented out. I have a feeling > > this has something to do with my problems and the 1 word space left > > on the stack after the longjmp. > > I think this is the kernel stack which the i386 switches to on > receipt of an interrupt/exception/whatever. I believe the 68k has > a supervisor stack of some description to do this. If you're current > doing it on the user stack you shoudln't, because you can't trust it > to be right. The 680x0 has two stack pointers. Both are refered to by "a7" or "sp". When the supervisor bit is set this refers to the SSP (supervisor stack pointer) otherwise it refers to USP (user stack pointer). There is also an instruction (priveledged) to read the USP. (some chips have more than 1 supervisor stack I believe). In my trap/interupt handlers USP is overwritten onto the a7 position of the trap frame after all registers are pushed, and read back from the a7 position before popping the other registers (a7 is never really popped from the stack). If the above code is just to set the user stack pointer then I guess I already covered this. > Cheers, > > Christopher. Thanks for your response. I'm still a bit confused with respect to the extra decrement on the new stack created by dup_stack(). I wouldn't be suprised if this had something to do with my problems. As far as I can tell the stack pointer should point to the bottom most value of the trap frame when a thread enters the kernel, this is the same condition that should exist when the thread returns to userland through retuser(). What I don't understand though is - if this was the case then why would any processes run at all? If the stack pointer was at the wrong position after new processes were created the registers would be read all wrong and the hardware trapframe read by the return-from- exception would be all wrong. This leads me to believe that it is currently correct. Tim N. From vandys@glare.cisco.com Thu Dec 1 06:02:23 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA03150; Thu, 1 Dec 1994 06:02:22 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA00183 for ; Thu, 1 Dec 1994 06:26:28 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa29155; 1 Dec 94 13:54 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rDAmm-0003A8C; Thu, 1 Dec 94 12:38 GMT Message-Id: From: Dave Hudson Subject: Re: fork() problems. To: VSTa mailing list Date: Thu, 1 Dec 1994 12:38:56 +0000 (GMT) In-Reply-To: <199412010911.AA28404@sour.sw.oz.au> from "Christopher Fraser" at Dec 1, 94 08:11:07 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2824 Hi, Christopher Fraser wrote: > > > What is the function of ebp? I don't believe the 68k has an > > analagous register (a dedicated one at least). The 68k uses > > the link command at the entry of a function which acts similarly > > to ebp (correct?). If the longjmp warps to a function that > > does this then the link register doesnt have to be set does it? > > ebp is the frame pointer -- I don't _think_ it has to be used at > all, but it can be useful for debugging. But I'm not really sure, > my 386 book doesn't talk about it much other than the enter > instruction fiddling it as per the standard i386 calling conventions. > I'm not sure what's done on the 68k with the frame pointer either. It's not particularly special - it's usually just used to reference the position of esp (less 4 for the save of the original value of ebp) on entry to a function. The x86 instruction set does have a few tricks it can do by combining ebp and ebx to speed things up. I've used it as just a general purpose reg in assembly code many times before though. > > At any rate here is the code I am working with right now: > > > > /* > > * New entity returns with 0 value; SP is one lower so that > > * the resume() path has a place to write its return address. > > * This simulates the normal context switch mechanism of > > * setjmp/longjmp. > > */ > > new->t_kregs->pc = (ulong)retuser; > > new->t_kregs->sp = ((ulong)(new->t_uregs)) - sizeof(ulong); > > new->t_uregs->f_regs[REG_D0] = 0; > > The sizeof(ulong) just allows enough space for the return address (eip) to be written before the stack end (in longjmp()) > > in resume(): > > /* > > * Make kernel stack come in on our own stack now. This > > * isn't used until we switch out to user mode, at which > > * time our stack will always be empty. > > * XXX esp is overkill; only esp0 should ever be used. > > */ > > tss->esp0 = tss->esp = (ulong) > > ((char *)(t->t_kstack) + KSTACK_SIZE); > > > > This one has me really confused. I'm not to clear on what the tss > > does. VSTa doesn't use TSS's the way some of the Unix clones do (eg Linux). Basically whenever we want to move from ring 0 to ring 3 code though (interrupts, traps, or calls through call gates, etc) the x86 uses the TSS to keep track of what's going on. It'd be a really neat trick for general ptocess handling if it wasn't for the fact that FPU states aren't stored and it takes an enourmous amount of time to save the state in the TSS. A quick flick through the Pentium book shows about 80ish clocks and that's *much* faster than a 386 or 486. Pushing/poping registers as we do at the moment is much quicker Regards, Dave From vandys@glare.cisco.com Thu Dec 1 13:32:59 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA03178; Thu, 1 Dec 1994 13:32:58 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id NAA26466 for ; Thu, 1 Dec 1994 13:57:10 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id LAA15932 for vsta@cisco.com; Thu, 1 Dec 1994 11:55:55 -1000 From: Tim Newsham Message-Id: <199412012155.LAA15932@zang.kcc.hawaii.edu> Subject: dup_stack() To: vsta@cisco.com Date: Thu, 1 Dec 1994 11:55:54 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 138 I convinced myself that the extra space on the stack is necessary. Thanks for the replies. Tim N. From vandys@glare.cisco.com Sat Dec 3 22:19:44 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA03523; Sat, 3 Dec 1994 22:19:43 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id WAA24761 for ; Sat, 3 Dec 1994 22:44:10 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id XAA17860 for ; Sat, 3 Dec 1994 23:44:07 -0700 Message-Id: <199412040644.XAA17860@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: tsleep()/twake() Date: Sat, 03 Dec 1994 23:44:07 -0700 From: Gary Shea These are system calls that will suspend the calling thread and allow another thread to wake it again. I'm distributing an alpha version to anyone that would like to try it. If you grab it, please let me know, so I have some idea of how many people are using it (and who to send fixes to!). You can ftp the file tsleep.tz from xmission.com, the directory is /pub/users/shea. If there's a problem, please let me know! Gary From vandys@glare.cisco.com Sun Dec 4 09:39:54 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03594; Sun, 4 Dec 1994 09:39:53 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA10980; Sun, 4 Dec 1994 10:04:12 -0800 Message-Id: <199412041804.KAA10980@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: vsta@amri.cisco.com Subject: Re: Thoughts about proc permission handling In-Reply-To: Your message of "Sun, 04 Dec 1994 15:51:03 GMT." Date: Sun, 04 Dec 1994 10:04:12 -0800 From: Andrew Valencia [Dave Hudson writes:] >I've just been having some thoughts about permission handling within the >proc server. What's just occurred to me is that my idea of simply having >proc change its own IDs to match those of its current client won't work - >the client can have as many IDs as the server. Nah, that's an edge case. Just skip the last one if necessary--this fails in a conservative fashion. Far better to reuse the actual kernel mechanism than to try and duplicate it. >BTW Andy, I'm thinking of reverting back to my original rework of the proc >fs where we can just get a process list back rather than having to step >through the linked list. I'm rethinking the pstat() system call itself. It's starting to feel like too much code, too intrusive. Perhaps it should just mmap() physical pages and try to snapshot system state on the fly. This would make the /proc server much more important, and much more intimate with the kernel innards. That should probably be OK, so long as it's all in one place. It leaves the /proc server exposed to race conditions. I used to think this was a big enough issue that a kernel mechanism was needed. Now that we've written it and played with it some, I'm not convinced. There are some things (like networking) which, once you let them into the kernel, become a serious case of the tail wagging the dog. Statistical/status inquiries might actually fall into this category. >... This isn't insignificant as at the moment the proc ps code >can yield over 300 pstat() calls when we have 20ish processes (as measured >with the code I wrote yesterday). But it's not a part of the system where performance is important. I'd run it in Smalltalk on a virtual machine if it would leave kernel messaging and scheduling cleaner and more efficient. If /proc is real-time and we leave the nrun calculation in the kernel code, /proc could even do the load average calculations, couldn't he? He'd just have to be sure to subtract out his own nrun-ness (or factor in a fraction of it to reflect his run state outside of the load average calculation). This would also allow him to inhibit (or reduce the granularity of) the calculation when there are no clients--a nice side effect of being a server. Andy From vandys@glare.cisco.com Mon Dec 5 07:16:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03783; Mon, 5 Dec 1994 07:16:10 -0800 Received: from plg.uwaterloo.ca (plg.uwaterloo.ca [129.97.140.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA24847 for ; Mon, 5 Dec 1994 07:40:44 -0800 Received: by plg.uwaterloo.ca id <103744>; Mon, 5 Dec 1994 10:40:30 -0500 From: Dave Mason To: VSTa mailing list Subject: Re: fork() problems. In-Reply-To: References: <199412010911.AA28404@sour.sw.oz.au> X-Url: X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Mon, 5 Dec 1994 10:40:17 -0500 Dave Hudson writes (re: ebp): > It's not particularly special - it's usually just used to reference the > position of esp (less 4 for the save of the original value of ebp) on entry > to a function. The x86 instruction set does have a few tricks it can do by > combining ebp and ebx to speed things up. I've used it as just a general > purpose reg in assembly code many times before though. You probably know this, but I thought I'd mention it for completeness: ebp and esp are the only registers that use the stack segment rather than the data segment, so if ss!=ds (not that anybody would) you may have problems treating ebp just like ebx or one of the others. ../Dave From vandys@glare.cisco.com Mon Dec 5 07:42:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA03787; Mon, 5 Dec 1994 07:42:13 -0800 Received: from dolly.par.univie.ac.at (dolly.par.univie.ac.at [131.130.70.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id IAA26135 for ; Mon, 5 Dec 1994 08:06:38 -0800 Received: from lea.par.univie.ac.at (lea [131.130.70.25]) by dolly.par.univie.ac.at (8.6.9/8.6.9) with ESMTP id RAA09409 for ; Mon, 5 Dec 1994 17:06:33 +0100 From: Robert Mayer - Student Received: (robert@localhost) by lea.par.univie.ac.at (8.6.9/8.6.9) id RAA10138 for vsta@cisco.com; Mon, 5 Dec 1994 17:06:33 +0100 Date: Mon, 5 Dec 1994 17:06:33 +0100 Message-Id: <199412051606.RAA10138@lea.par.univie.ac.at> To: vsta@cisco.com Subject: Re: Thoughts about proc permission handling [Andrew Valencia writes:] (stuff deleted...) > I'm rethinking the pstat() system call itself. It's starting to feel like > too much code, too intrusive. Perhaps it should just mmap() physical pages > and try to snapshot system state on the fly. This would make the /proc > server much more important, and much more intimate with the kernel innards. > That should probably be OK, so long as it's all in one place. > > It leaves the /proc server exposed to race conditions. I used to think this > was a big enough issue that a kernel mechanism was needed. Now that we've > written it and played with it some, I'm not convinced. There are some > things (like networking) which, once you let them into the kernel, become a > serious case of the tail wagging the dog. Statistical/status inquiries > might actually fall into this category. If race conditions are acceptable, why not keep pstat() a system call but make it retrieve the information without doing any locking ? Regards, Robert. From vandys@glare.cisco.com Mon Dec 5 10:32:12 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA03805; Mon, 5 Dec 1994 10:32:10 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id KAA26987 for ; Mon, 5 Dec 1994 10:56:43 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa10709; 5 Dec 94 17:05 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rEgzt-0003JbC; Mon, 5 Dec 94 17:14 GMT Message-Id: From: Dave Hudson Subject: Re: Thoughts about proc permission handling To: Robert Mayer - Student Date: Mon, 5 Dec 1994 17:14:45 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 374 Robert Mayer - Student wrote: > > If race conditions are acceptable, why not keep pstat() a system call > but make it retrieve the information without doing any locking ? It rather depends who we race with - the danger is that our underlying process structures can dissappear from under us if we don't make sure we're the only one playing with them. Regards, Dave From vandys@glare.cisco.com Mon Dec 5 10:37:31 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA03808; Mon, 5 Dec 1994 10:37:30 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA17611; Mon, 5 Dec 1994 11:02:04 -0800 Message-Id: <199412051902.LAA17611@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Dave Hudson Cc: Robert Mayer - Student , VSTa mailing list Subject: Re: Thoughts about proc permission handling In-Reply-To: Your message of "Mon, 05 Dec 1994 17:14:45 GMT." Date: Mon, 05 Dec 1994 11:02:04 -0800 From: Andrew Valencia [Dave Hudson writes:] >Robert Mayer - Student wrote: >> If race conditions are acceptable, why not keep pstat() a system call >> but make it retrieve the information without doing any locking ? >It rather depends who we race with - the danger is that our underlying >process structures can disappear from under us if we don't make sure we're >the only one playing with them. Think even further out. If a user program gets befuddled, he might take a segv and die. The system quite likely goes on. If the kernel gets befuddled.... Also, put on your microkernel hat. If it doesn't need to go in the kernel, don't put it there. Keep your ring 0 code small, allow as much code as possible to run in an environment where faults can be contained. Also, saddle the exceptional case with the cost. The cost of making queries about process state should be skewed heavily to the process making the query. Andy From vandys@glare.cisco.com Tue Dec 6 08:32:29 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA03948; Tue, 6 Dec 1994 08:32:28 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA08511 for ; Tue, 6 Dec 1994 08:57:10 -0800 Message-Id: <199412061657.IAA08511@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: pstat Date: Tue, 06 Dec 1994 08:57:09 -0800 From: Andrew Valencia Hi, folks. Well, I got far enough along on the mmap()/symtab approach of pstat() to realize that the cure would be worse than the symptom. The biggest pain was that most of what the /proc server would examine could become unmapped asynchronously. So as the poor server is trying to make forward progress bits and pieces can be going away. The /proc server thus has to catch events and structure his scan so that the event handler can longjmp() out to a point where the server can realize that a structure went away while he was looking at it. If it sounds bad on paper, just imagine the code I was writing.... So, let's just stick with pstat() and make it as short and sweet (on the kernel side) as possible. I'll apply Dave's patches as soon as he makes a final judgement on the walk-the-list versus list-of-pids approach. Andy From vandys@glare.cisco.com Tue Dec 6 09:16:34 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA03958; Tue, 6 Dec 1994 09:16:33 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id JAA09305 for ; Tue, 6 Dec 1994 09:41:14 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id KAA16104 for vsta@cisco.com; Tue, 6 Dec 1994 10:40:59 -0700 Date: Tue, 6 Dec 1994 10:40:59 -0700 From: Gary Shea Message-Id: <199412061740.KAA16104@xmission.xmission.com> To: vsta@cisco.com Subject: rcs in next release? I would like to formally get down on my knees and BEG that rcs be in the next release... I have heard rumours of it being ported by Andy. I don't enjoy coding without it :) If there's anything I can do to help, let me know. Gary From vandys@glare.cisco.com Tue Dec 6 12:03:28 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03973; Tue, 6 Dec 1994 12:03:27 -0800 Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA19093 for ; Tue, 6 Dec 1994 12:28:08 -0800 Received: from frmap711.mathp7.jussieu.fr (frmap711.mathp7.jussieu.fr [134.157.13.100]) by shiva.jussieu.fr (8.6.9/jtpda-5.0) with SMTP id VAA00406 for ; Tue, 6 Dec 1994 21:28:06 +0100 Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403) at Tue, 6 Dec 94 21:28:05 +0100 From: rideau@mathp7.jussieu.fr (Francois Rideau) Message-Id: <9412062028.AA23567@frmap711.mathp7.jussieu.fr> Subject: change subscribe address To: vsta@cisco.com Date: Tue, 6 Dec 94 21:28:04 MET X-Mailer: ELM [version 2.3 PL11] Dear Andy and VSTa-ers, I'm currently subscribed using my father's address, "rideau@frmap711.mathp7.jussieu.fr" Could I be just subscribed as "rideau@clipper.ens.fr" (that is myself) ? Thanks. I'm not a very active member of VSTa; actually, I'm just looking at VSTa progress. I like VSTa, but I think it's not far enough in the right direction: toward a decentralized system. Currently, VSTa still uses centralized message-passing with an arbitrary convention; actually, this can't be done better using "C". What I'm looking for is a completely decentralized system, where inter-object communication would be automatically inlined as much as possible when possible (and wishable), at compile-time link-time, load-time or run-time, that is, when wishable (sometime between the moment it is made possible and the moment it is made necessary). I hope VSTa will succeed (I also hope I'll be able to vampirize its device drivers/servers), and I'll still follow it's progress with interest, but I've setup another mailing list (tunes@ens.fr) for my own project. -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From vandys@glare.cisco.com Tue Dec 6 12:16:08 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA03977; Tue, 6 Dec 1994 12:16:07 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA23468; Tue, 6 Dec 1994 12:40:49 -0800 Message-Id: <199412062040.MAA23468@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: rideau@mathp7.jussieu.fr (Francois Rideau) Cc: vsta@cisco.com Subject: Re: change subscribe address In-Reply-To: Your message of "Tue, 06 Dec 1994 21:28:04 +0700." <9412062028.AA23567@frmap711.mathp7.jussieu.fr> Date: Tue, 06 Dec 1994 12:40:49 -0800 From: Andrew Valencia [rideau@mathp7.jussieu.fr (Francois Rideau) writes:] >"rideau@frmap711.mathp7.jussieu.fr" >Could I be just subscribed as "rideau@clipper.ens.fr" (that is myself) ? Sure. >... What I'm looking for is a completely decentralized system, >where inter-object communication would be automatically inlined as much as >possible when possible (and wishable), at compile-time link-time, load-time >or run-time, that is, when wishable (sometime between the moment it is >made possible and the moment it is made necessary). I looked at the deeply object-oriented OS designs. Having to drop C is a bitter pill for a from-scratch OS effort, since it guarantees you have to write a mind-numbing amount of code from scratch. Even if you preserve POSIX interfaces with some other language binding you're paddling upstream. Even more alarming was the track record of such efforts. The pattern always seemed to be early successes followed by efforts increasingly bogged in the contradictory requirements of coherency, scalability, transparency, security, fault tolerance, and so forth. To even further generalize, the systems would tend to grab a great deal of the abstraction, and then let it dribble back piecemeal as deeply difficult problems with a system-wide policy interacted with individual application needs. Not to nay-say your effort. Clearly, I believe that experimentation with operating systems is always a Good Thing. But since you posted to the VSTa list, I felt I should offer an explanation for the relatively nuts-and-bolts type of microkernel I ultimately implemented. Finally, I believed that the VSTa microkernel can provide the basic engine for certain implementations of such distributed operating environments. Thus, I was not ruling out more powerful implementation technologies for the future, although admittedly this is not an active area currently. Regards, Andy Valencia From vandys@glare.cisco.com Tue Dec 6 18:03:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA04056; Tue, 6 Dec 1994 18:03:11 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id SAA08739 for ; Tue, 6 Dec 1994 18:27:54 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id TAA22359 for vsta@cisco.com; Tue, 6 Dec 1994 19:27:51 -0700 Date: Tue, 6 Dec 1994 19:27:51 -0700 From: Gary Shea Message-Id: <199412070227.TAA22359@xmission.xmission.com> To: vsta@cisco.com Subject: user semaphore package available for ftp on xmission.com, login anonymous, file /pub/users/shea/tsync.tz. If you already grabbed the system-call-only version, be warned that I changed the name of the kernel and include/sys files. Other than that, there are no changes except the addition of the libc code. This distribution contains both the kernel and libc code. Enjoy! From vandys@glare.cisco.com Thu Dec 8 22:41:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA04490; Thu, 8 Dec 1994 22:41:33 -0800 Received: from ux4.cso.uiuc.edu (jeske@ux4.cso.uiuc.edu [128.174.5.62]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA23827 for ; Thu, 8 Dec 1994 23:06:29 -0800 Received: by ux4.cso.uiuc.edu id AA29554 (5.67b/IDA-1.5 for vsta@cisco.com); Fri, 9 Dec 1994 01:06:20 -0600 From: David Jeske Message-Id: <199412090706.AA29554@ux4.cso.uiuc.edu> Subject: VSTa - First Impressions To: vsta@cisco.com Date: Fri, 9 Dec 1994 01:06:19 -0600 (CST) Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6680 First, I have to take an initial moment to applaud for all you VSTa coders. I could go on about all the reasons I like what I see, but you already know them, so I'll refrain. I retrieved "vsta.tz" and installed it on my machine. It's a 486 with a Adaptec 1542 and I had VSTa up and running in under 10 mintes. No matter how unpleasant running in a DOS filesystem is, it certainly makes starting up easy. Although I do have a problem. I have not yet had time to look into why it occurs, because I was busy elsewhere (see below). After I log in and move into "/", an "ls" will cause a kernel trap (message similar to "boot 8 exit", but I forget exactly) and doing "q" to return from the kernel debugger renders everything pretty much useless. I'm not very concerned because I may be the victem of ignorance more than a system bug. If this rings any bells though, let me know. After getting VSTa up and running, (ohh and doing a self-hosted compile. I guess I just had to.. it was all too easy) I moved to the mailing list archives. THAT was a project. I think it's fair to say that I have read nearly all the archived mail. I may have missed one here or there, but not many. I'm left with a few questions which either were discussed but not answered in the archives, or were just spurred from archive discussion. ---[ Shared Libraries ]--- First, Shared Libraries. How did they end up getting implemented? Is there an archive of the "shared lib mailing list"? I looked through the libc code for mapping the actual library into the processes address space, however, I'm a little foggy about what happens next and how their implemented. The archives would be great, because if there are reasons that some methods were decided against (shlib server, etc.) I am interested in knowing what they were. ---[ scheduler ]--- Also, what happened to the idea of "moving the scheduler out of the kernel"? It was brought up in the mailing list sometime ago and was never noticed by anyone. Going with the "less in the kernel is more" idea, why wasn't this discussed? I believe QNX uses this approach and allows the scheduler to share the address space of the kernel to help performance. While this dosn't buy you anything in terms of protection, it does buy you something in terms of flexibility. I'm not really advocating one way or the other, I'm merely asking what the opinions of others are. I think that allowing the flexibility to write your own scheduler is on of the more interesting prospects of a microkernel, and being able to do so while retaining compatibility (read, no source or binary changes) with the "microkernel proper" is enticing. However, I'm not really aware of possible performance penalties. ---[ CVS ]--- CVS. I have had some limited experience with CVS and I agree with those who suggested it's use for the management of the project source. Andrew said he was going to do this, did it happen? (this is more a bit of curosity than anything I guess). ---[ Capabilites ]--- Is this an official term? I have seen Andy refer to this as "VSTa protection" and such too. I read one of the Plan9 papers which didn't make any mention of Capabilites (as far as I remember). Is this a Plan9 term? It seems that especially in the VSTa white paper, "Capabilities" seems to be almost a proper term for the VSTa system of security. More importantly, is this term one which should be perpetuated? [end questions] I "took notes" so to speak when I went through the mail archives. There is alot there to learn from, however, some will be more intersted in just learning about what you DID do and not how you got there, and so I'm putting togeather the information that I gleaned from the archives. I hesitate to call it a "manual", more sort of a guide, but we'll see what comes of it. The design of VSTa is proving itself to me as far as managability is concerned. I find it far easier to read the code to learn what is going on than in other kernels/systems I have looked at. Some of this may be due to the "relatively" small size of the VSTa project as well, however, it is undoubetly laid out in a way which was easy for me to quickly find my way around. Don't quote me, but I almost find it pleasurable to read the code. This is possibly also because of the pretty rigid formatting rules which have been used throughout. --[ A bit about me and how I found VSTa ]-- If this is already getting too wordy for you, just go ahead and skip this, it's just provided for the curosity bound. I have been a Linux user since the early 0.95 days. I'm a student at the University of Illinois at Champaign/Urbana. I do most of my "for money" work programming on NEXTSTEP. While Linux provides a rich functional base, I have been in dislike of it's statically defined nature and "recomple the kernel" setup. I don't like it's lack of threads, I could go on. A year ago I began to look for alternatives. First in the Linux[ms]s (linux on mach) project. Then in the Hurd (again mach). After a while I stumpled upon QNX. Which, IMHO, has an extremely elegant design. However, QNX is commercial, and no source is available. Anyhow, the recent postings on c.o.l.d about interest in making a microkernel version of Linux sparked me to start doing some research. I'll admit, that my original goal was to go out and look and see what was out there that could help bring a microkernel alternative to the Linux community. I have now, however, abandoned this approach, as I think Linux is just fine the way it is for some, and it's not going the directions I want. I think getting a MK os built and to the place where Linux is, as a pinnacle of free software, would be a better solution. If nothing else, it'll provide a base of free code for people to really discuss the macro vs. micro design tradeoffs with some more facts, instead of religion (or microkernel bashing). VSTa seems the most "practical" of the microkernel's I found, as well as the one most aligned with my ideals of MK design. I must admit, the idea of having non-POSIX security initially caused some aprehension, but after reading a description of the VSTa capabilities I found in the mail archives, I am converted. (the description of POSIX mapping onto VSTa capabilites along with the Capabilites example in the VSTa white paper provided a fairly clear picture of how they can be utilized, while either by itself just left blanks. At least for me) -- 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 Fri Dec 9 14:25:13 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA04582; Fri, 9 Dec 1994 14:25:12 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA10273; Fri, 9 Dec 1994 14:50:11 -0800 Message-Id: <199412092250.OAA10273@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: VSTa - First Impressions In-Reply-To: Your message of "Fri, 09 Dec 1994 01:06:19 CST." <199412090706.AA29554@ux4.cso.uiuc.edu> Date: Fri, 09 Dec 1994 14:50:10 -0800 From: Andrew Valencia [David Jeske writes:] >First, Shared Libraries. How did they end up getting implemented? Is there >an archive of the "shared lib mailing list"? No, creating the list made it all quiet down. :-) The short version is, you link against a library of stubs, one per entry point. All the stubs call a little bit of code which maps in the shared library loader, and passes the requested library and entry point to it. The current loader maps in the real library, and calls the code. All entries are done via a table, which is at the front of a shared library. Thus, detecting a NULL pointer for the table causes the load; thereafter, the vector is pulled from the table and the routine called directly. >... The archives >would be great, because if there are reasons that some methods were decided >against (shlib server, etc.) I am interested in knowing what they were. Mostly, simplicity. More to the point, I was on the road, had some time, picked a way, and went for it. >Also, what happened to the idea of "moving the scheduler out of the kernel"? That was never seriously considered. > Going with the "less in the kernel is more" idea, why wasn't this >discussed? Well, I used not so much the philosophy "everything possible out of the kernel", but the quite different "put enough in the kernel so hereafter you can stay out". > I think that allowing the flexibility to write your >own scheduler is on of the more interesting prospects of a microkernel, >and being able to do so while retaining compatibility (read, no source or >binary changes) with the "microkernel proper" is enticing. However, I'm >not really aware of possible performance penalties. They can be significant, although several operating systems have devised interfaces efficient enough to be acceptable. Often they involve having the scheduling process identify numberous processes all at once, which are then run in order until the list is empty. These schemes usually pick up a lot of complexity when faced with changing priority situations, for instance. >CVS. I have had some limited experience with CVS and I agree with those who >suggested it's use for the management of the project source. Andrew said he >was going to do this, did it happen? (this is more a bit of curosity than >anything I guess). CVS (remote version) requires rsh access, which is incompatible with firewalls. >Is this an official term? I have seen Andy refer to this as "VSTa protection" >and such too. I read one of the Plan9 papers which didn't make any mention >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that >especially in the VSTa white paper, "Capabilities" seems to be almost a proper >term for the VSTa system of security. Nope, this is unique to VSTa. >More importantly, is this term one which should be perpetuated? I don't think we've settled on an accepted terminology in this area. Since I'm involved with Kerberos these days I find myself using some of their terms, now that I've learned them. Glad you found VSTa, hopefully we can load you down with work! :-) Andy From vandys@glare.cisco.com Fri Dec 9 22:38:35 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA04621; Fri, 9 Dec 1994 22:38:34 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id XAA01166; Fri, 9 Dec 1994 23:03:35 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id VAA07187; Fri, 9 Dec 1994 21:02:45 -1000 From: Tim Newsham Message-Id: <199412100702.VAA07187@zang.kcc.hawaii.edu> Subject: Re: VSTa - First Impressions To: vandys@cisco.com (Andrew Valencia) Date: Fri, 9 Dec 1994 21:02:44 -1000 (HST) Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199412092250.OAA10273@glare.cisco.com> from "Andrew Valencia" at Dec 9, 94 02:50:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2639 > >CVS. I have had some limited experience with CVS and I agree with those who > >suggested it's use for the management of the project source. Andrew said he > >was going to do this, did it happen? (this is more a bit of curosity than > >anything I guess). > > CVS (remote version) requires rsh access, which is incompatible with > firewalls. Even if we cant use the distributed version of CVS, CVS should still be used. It does everything RCS does (it uses RCS, so this is easy :) and then a whole lot more. I imagine it wouldn't be hard to change the rsh interface to a messaging interface. Since VSTa will eventually have a network-proxy for message passing this should be suitable. > >Is this an official term? I have seen Andy refer to this as "VSTa protection" > >and such too. I read one of the Plan9 papers which didn't make any mention > >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that > >especially in the VSTa white paper, "Capabilities" seems to be almost a proper > >term for the VSTa system of security. > > Nope, this is unique to VSTa. If you're refering to the term "capability", this is a common term. I've run across it several times before running across VSTa. In _Operating Systems - Design and Implementation_ A. Tanenbaum talks about a 2-dimensional table where the rows specify domains of execution and columns specify various objects. The entries in the tables are the rights. He first covers ACL's which are column slices of the table. Then: "The other way of slicing up the matrix... is by rows. When this method is used, associated with each process is a list of objects that may be accessed, along with an indication of which operations are permitted on each, in other words, its domain. This list is called a capability list, and the individual items on it are called capabilities." Section 5.5.3, page 293. He also gives some references which are pretty old (1966, 1974). There are other systems which use capabilities including the MACH microkernel (port rights). I have never seen it used in quite the way that VSTa implements them. I think VSTa's approach is quite nice, it easily allows processes to make up their own capability definitions and still use the standard library routines to manipulate them. It also has a convenient mechanism for giving away weaker versions of a capability and an easy mechanism for disabling priveledges that one has. I think this system *could* be used to make VSTa a very secure system. (I emphasize "could" because the primitives are just a tool, putting them to work is still a lot of work). > Andy From vandys@glare.cisco.com Sat Dec 10 03:44:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA04712; Sat, 10 Dec 1994 03:44:11 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA11058 for ; Sat, 10 Dec 1994 04:09:09 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa01730; 10 Dec 94 12:08 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rGQYL-0002jJC; Sat, 10 Dec 94 12:05 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa - First Impressions To: VSTa mailing list Date: Sat, 10 Dec 1994 12:05:29 +0000 (GMT) In-Reply-To: <199412100702.VAA07187@zang.kcc.hawaii.edu> from "Tim Newsham" at Dec 9, 94 09:02:44 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: 1623 Tim Newsham wrote: > > I think VSTa's > approach is quite nice, it easily allows processes to make > up their own capability definitions and still use the standard > library routines to manipulate them. It also has a convenient > mechanism for giving away weaker versions of a capability and > an easy mechanism for disabling priveledges that one has. This is a big advantage as far as I'm concerned - the only POSIX thing we can't really do is handle a user belonging to several different groups. In practice I'm not sure that this is such a big issue anyway, but as our users can currently hold several IDs this should cover most cases. > I think this system *could* be used to make VSTa a very secure > system. (I emphasize "could" because the primitives are just > a tool, putting them to work is still a lot of work). As part of the work I've been doing on pstat I fixed a couple of bugs in the 1.3.2 permission code and it now seems to provide some very neat protection facilities. I just reworked some of Bjorn Helgaas' proc code yesterday and found the ability to be able to derive a permission given a shorter one (or any permission if we have ) and to be able to enable and disable any permission we have offers some really nice tricks. The proc code, for example, can now assume the identity of each of its clients in order to get kernel information without requesting information based on its own permissions. I'm sure there are more subtle uses that could lead to a very secure system - the biggest problem I envisage will be with security of a distributed environment. Regards, Dave From vandys@glare.cisco.com Sat Dec 10 19:36:19 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA04799; Sat, 10 Dec 1994 19:36:18 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA19899 for ; Sat, 10 Dec 1994 20:01:24 -0800 Message-Id: <199412110401.UAA19899@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Mail loop Date: Sat, 10 Dec 1994 20:01:24 -0800 From: Andrew Valencia Because of a mail misconfiguration on the part of one of the VSTa mailing list users, you may have received multiple copies of some recent messages. I've removed the user from the list and cleared the mail queues. I apologize for the inconvenience; please send me a note if you see residual problems. Andy Valencia From vandys@glare.cisco.com Sun Dec 11 18:58:32 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA04883; Sun, 11 Dec 1994 18:58:30 -0800 Received: from ux4.cso.uiuc.edu (jeske@ux4.cso.uiuc.edu [128.174.5.62]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA03824 for ; Sun, 11 Dec 1994 19:23:42 -0800 Received: by ux4.cso.uiuc.edu id AA20045 (5.67b/IDA-1.5 for vsta@cisco.com); Sun, 11 Dec 1994 21:23:39 -0600 From: David Jeske Message-Id: <199412120323.AA20045@ux4.cso.uiuc.edu> Subject: New Console Driver To: vsta@cisco.com Date: Sun, 11 Dec 1994 21:23:38 -0600 (CST) Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2224 I hope this didn't duplicate anyones work. I had some vt100 engine source and I didn't like the lack of real vt100 on the console so changed/rewrote the cons2 driver. For those interested: I arranged it so the new "vt100 engine" isn't coded as global variables, so there is no need to "switch" the current "engine" screen. Now the only switching involved is for the visual screen. The main "VSTa file handling stuff" is the same as it was in cons2, also, the keybaord stuff is the same. I basically removed most/all of cons.c and wrote the necessary parts of main.c to support the new "vt100.c". The new engine also is not so hard coded to have one screen size for the entire engine (each screen could have a different size as far as the engine is concerned). I was asking myself while writing this, should I be abstracting this into two layers? One for the "virtual" part of it, and one for the "text console" part of it. This might make it more uniform to support things like graphical consoles and such. However, I couldn't decide if the added overhead would be worth it. Support to add non-text terminals could just as easily be added to the "virtual" part of an integrated driver like the one we have. I admit, the initial reason I thought of doing a 2 level driver was to make it so I could develop the engine without rebooting. It didn't take me long enough for it to be worth it though. Any opinions? Also, is there any place for "subprojects" to be released? As far as I can tell it looks like people just either wait for Andy's release, or send stuff to eachother. Would it be usefull to have a location for subprojects? (or associated stuff)? I have been thinking of setting up anonymous ftp on my machine. It's connected to the new via ISDN, so it wouldn't be stellar speed, but it would be sufficient for the number of people using VSTa now and the number of things I anticipate being on it. However, if there is already a better solution, I won't bother. -- 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 Dec 11 20:33:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA04893; Sun, 11 Dec 1994 20:33:26 -0800 Received: from ux4.cso.uiuc.edu (jeske@ux4.cso.uiuc.edu [128.174.5.62]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id UAA05757 for ; Sun, 11 Dec 1994 20:58:38 -0800 Received: by ux4.cso.uiuc.edu id AA06955 (5.67b/IDA-1.5 for vsta@cisco.com); Sun, 11 Dec 1994 22:58:35 -0600 From: David Jeske Message-Id: <199412120458.AA06955@ux4.cso.uiuc.edu> Subject: Re: New Console Driver To: vsta@cisco.com Date: Sun, 11 Dec 1994 22:58:34 -0600 (CST) Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 706 "cons3-alpha.tar.gz" is available now from genesis.isdn.uiuc.edu:/pub/VSTa/Servers/i386/cons3-alpha.tar.gz As I mention in the readme, I still need to go through and "format" vt100.c the "VSTa way" and clean it up in general. I also need to add a real readme and comments. I'm just putting this up because I start finals tommorow and if I didn't do it now, it would likely be next weekend before it happened. Feel free to grab it and tell me what you think. -- 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 Mon Dec 12 02:20:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA04997; Mon, 12 Dec 1994 02:20:07 -0800 Received: from ux4.cso.uiuc.edu (jeske@ux4.cso.uiuc.edu [128.174.5.62]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA14202 for ; Mon, 12 Dec 1994 02:45:20 -0800 Received: by ux4.cso.uiuc.edu id AA11711 (5.67b/IDA-1.5 for vsta@cisco.com); Mon, 12 Dec 1994 04:45:19 -0600 From: David Jeske Message-Id: <199412121045.AA11711@ux4.cso.uiuc.edu> Subject: Virtualizing Console Resources To: vsta@cisco.com Date: Mon, 12 Dec 1994 04:45:18 -0600 (CST) Reply-To: jeske@uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2724 I was just thinking over the whole "virtual console" thing and I came up with another idea which I belive may be possible and desirable in VSTa. Please give it a little leway, it's 4:47am, I could not sleep, and I have an exam at 8am in the morning. I had to get this out of my head or bust. A virtual console server could provide a namespace via namer where each "console" directory would contain a directory for each "console driver" available. For example, if you had a "kbd","mouse",and "vt100", the virtual console would provide multiplexed version of these devices as con1/kbd, con1/mouse, con1/vt100 as well as con2/kbd,con2/mouse,con2/vt100 (and so on). In this way, any devices present could be made virtual without changes to the virtual driver. (I'm presuming that there is a way to easily lookup names in the namer, and that the virtual driver could just lookup a specific directory in the namer where console devices would be put and then mimic these devices repeatedly for each "con#" directory. If this is incorrect, please point this out, as I have not investigated it specifically.) A glaring advantage of this situation is that it becomes incredibly easy to merely mount con# into the "union" /dev/ of a person's private namespace. In that way, applications run in a client namespace will have easy access to the traditional /dev/mouse, /dev/console (/dev/vt100 in my above case), /dev/kbd (well, this is normally /dev/console too I suppose, this is more to make a point) unknowing that they are multiplexed. There is no added complication burdened onto the indivual drivers. A glaring disadvantage, it just looks like it would incur lots of overhead. A keyboard stroke would have to go through 2 message passes before it ends up at a user level. Likewise for all strictly message pass resources. Is this an overburden? I'm not sure, I don't know how the performance numbers stack up. It probably would be less of a burden if the kernel has code to make efficient small message passes via copy instead of remap. (Andy talked about this in one of his previous mailing list mesages). Forgive me if this is totally off the wall.. I was trying to think of a way to better the unix system way of fighting over /devs when using virtual console type setups, as well as providing an easy support for virtualized server based graphical services. (i.e. as an example, /dev/bitblit should be able to be virtualized through this type of setup as well) Thoughts? -- 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 Mon Dec 12 04:12:19 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA05030; Mon, 12 Dec 1994 04:12:18 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id EAA20742 for ; Mon, 12 Dec 1994 04:37:29 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa25749; 12 Dec 94 12:21 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rH9hw-0003LNC; Mon, 12 Dec 94 12:18 GMT Message-Id: From: Dave Hudson Subject: Re: Virtualizing Console Resources To: jeske@uiuc.edu Date: Mon, 12 Dec 1994 12:18:24 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199412121045.AA11711@ux4.cso.uiuc.edu> from "David Jeske" at Dec 12, 94 04:45:18 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3071 Hi, David Jeske wrote: > > I was just thinking over the whole "virtual console" thing and I came > up with another idea which I belive may be possible and desirable in > VSTa. Please give it a little leway, it's 4:47am, I could not sleep, > and I have an exam at 8am in the morning. I had to get this out of my > head or bust. I remember that feeling :-) Anyway the best ideas always come after 2AM :-) > For example, if you had a "kbd","mouse",and "vt100", the virtual console > would provide multiplexed version of these devices as con1/kbd, con1/mouse, > con1/vt100 as well as con2/kbd,con2/mouse,con2/vt100 (and so on). In this > way, any devices present could be made virtual without changes to the > virtual driver. (I'm presuming that there is a way to easily lookup names > in the namer, and that the virtual driver could just lookup a specific > directory in the namer where console devices would be put and then mimic > these devices repeatedly for each "con#" directory. If this is incorrect, > please point this out, as I have not investigated it specifically.) A lot of this sounds very similar to the code Gavin Nichol's been working on for MADO - I'd really like to see this done for the text consoles as well though (please someone write a keyboard driver that can take different keymaps - I'm quite used to transposing UK to US but it's a real pain). > A glaring disadvantage, it just looks like it would incur lots of overhead. > A keyboard stroke would have to go through 2 message passes before it > ends up at a user level. Likewise for all strictly message pass resources. > Is this an overburden? I'm not sure, I don't know how the performance > numbers stack up. It probably would be less of a burden if the kernel > has code to make efficient small message passes via copy instead of remap. > (Andy talked about this in one of his previous mailing list mesages). Well Andy and I discussed the performance a little when I rewrote the serial mouse code to use the rs232 server. In practice the benefits of using the specialised rs232 server and the simplification of the mouse code have made this worthwhile. I suspect the same may be true for what you're sugesting. FWIW I did a lot of performance analysis a couple of weeks back, but the perf1 program in the 1.3.2 release should give a fair idea of the impact. On my DX4-100 486 with no L2 cache I get a context switch time of 207 us, so there's room for improvement (handling small messages efficiently would be useful). > Forgive me if this is totally off the wall.. I was trying to think of > a way to better the unix system way of fighting over /devs when using virtual > console type setups, as well as providing an easy support for virtualized > server based graphical services. (i.e. as an example, /dev/bitblit should > be able to be virtualized through this type of setup as well) One of the things Gavin's mentioned before is that by using this sort of technique MADO will virtualise /dev/bitblt and thus run any app built to drive bitblt direct. Regards, Dave From vandys@glare.cisco.com Mon Dec 12 04:21:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA05033; Mon, 12 Dec 1994 04:21:07 -0800 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id EAA20931 for ; Mon, 12 Dec 1994 04:46:16 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id HAA23258; Mon, 12 Dec 1994 07:47:20 -0500 Date: Mon, 12 Dec 1994 07:47:20 -0500 From: Gavin Nicol Message-Id: <199412121247.HAA23258@ebt-inc.ebt.com> To: jeske@uiuc.edu Cc: vsta@cisco.com In-Reply-To: <199412121045.AA11711@ux4.cso.uiuc.edu> (message from David Jeske on Mon, 12 Dec 1994 04:45:18 -0600 (CST)) Subject: Re: Virtualizing Console Resources The situation you outline (where the console driver basically multiplexes the various devices), is precisely the architecture that MADO uses/will use. To open a window in MADO, one would run a small program which would set up the namespace to look exactly like the namespace without MADO. This way, a client opening /dev/bitblt would see a graphics deisplay interface exactly like the real thing, and would work with or without MADO. The same thing applies to /dev/console, dev/kbd, and /dev/mouse etc. The original idea for this is from 8 1/2. It is sometimes necessary to rewrite some messages (expecially ones going to/from bitblt), which can incur some overhead. From vandys@glare.cisco.com Mon Dec 12 04:26:40 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA05036; Mon, 12 Dec 1994 04:26:39 -0800 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id EAA21060 for ; Mon, 12 Dec 1994 04:51:53 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id HAA23369; Mon, 12 Dec 1994 07:53:17 -0500 Date: Mon, 12 Dec 1994 07:53:17 -0500 From: Gavin Nicol Message-Id: <199412121253.HAA23369@ebt-inc.ebt.com> To: dave@humbug.demon.co.uk Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: (message from Dave Hudson on Mon, 12 Dec 1994 12:18:24 +0000 (GMT)) Subject: Re: Virtualizing Console Resources Hopefully, the greatest burden I bear (workwise) will be gone soon, and I can start hacking again. One thing I'd really like to see done soon is some kind of RPC system built on top of PIO. When messing with bitblt, the marshalling code gets quite tiresome. probably overkill From vandys@glare.cisco.com Mon Dec 12 08:40:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA05084; Mon, 12 Dec 1994 08:40:25 -0800 Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA03696 for ; Mon, 12 Dec 1994 09:05:40 -0800 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0rHEBy-000vJFC; Mon, 12 Dec 94 11:05 CST Received: from gocart.eng.hou.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0rHEBu-000uHyC; Mon, 12 Dec 94 11:05 CST Received: by gocart.eng.hou.compaq.com (Smail3.1.26.7/COMPAQ-HESIOD) id m0rHEBt-00036qC; Mon, 12 Dec 94 11:05 CST Message-Id: From: edm@gocart.eng.hou.compaq.com (Eddie McCreary) Subject: problems with gcc? To: vsta@cisco.com Date: Mon, 12 Dec 94 11:05:37 CST X-Mailer: ELM [version 2.4dev PL11] I've got an odd problem. While working on a program, every once in a while a small change and the program will no longer execute. What's odd is that the program doesn't execute any of the code before the change, it just won't load. For example, I had a small program like this... int main() { func1(); func2(); func3(); } and it works fine. But, if I make a small change like this... func1(); func3(); func2(); func3(); the program no longer executes. I could understand it if the first call to func3 caused an error, but func1 is never executed. Has anyone seen this before? eddie -- .__o Ed McCreary "The Information Superhighway, sanitized _-\ <,- Compaq Computers for your protection." (*)/ (*) edm@twisto.compaq.com From vandys@glare.cisco.com Mon Dec 12 08:46:04 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA05087; Mon, 12 Dec 1994 08:46:03 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA27794; Mon, 12 Dec 1994 09:11:18 -0800 Message-Id: <199412121711.JAA27794@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: edm@gocart.eng.hou.compaq.com (Eddie McCreary) Cc: vsta@cisco.com Subject: Re: problems with gcc? In-Reply-To: Your message of "Mon, 12 Dec 1994 11:05:37 CST." Date: Mon, 12 Dec 1994 09:11:17 -0800 From: Andrew Valencia [edm@gocart.eng.hou.compaq.com (Eddie McCreary) writes:] >I've got an odd problem. While working on a program, every once in a while >a small change and the program will no longer execute. What's odd is >that the program doesn't execute any of the code before the change, it >just won't load. You might try rm'ing the file each time before recompiling. My guess is that the old image is still cached and causing you grief. I think we agreed that filesystems need to unhash files which are opened for writing, not just files which are removed. This is harder than it looks, because the kernel holds a connection open for the hashed file, see how dos_remove() handles this. Andy From vandys@glare.cisco.com Mon Dec 12 15:52:38 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05114; Mon, 12 Dec 1994 15:52:35 -0800 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id QAA28460 for ; Mon, 12 Dec 1994 16:17:52 -0800 Received: by netmail2.microsoft.com (5.65/25-eef) id AA19404; Mon, 12 Dec 94 16:18:05 -0800 Message-Id: <9412130018.AA19404@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 12 Dec 94 16:18:05 PST X-Msmail-Message-Id: 17D4F68D X-Msmail-Conversation-Id: 17D4F68D From: Jonathon Tidswell (MS Research Fellow) To: vsta@cisco.com Date: Tue, 13 Dec 94 10:15:25 TZ Subject: capabilities / security (was Re: VSTa - First Impressions) ---------- > From: Tim Newsham Quoting Andy quoting David Jeske: > > >Is this an official term? I have seen Andy refer to this as "VSTa protection" > > >and such too. I read one of the Plan9 papers which didn't make any mention > > >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that > > >especially in the VSTa white paper, "Capabilities" seems to be almost a proper > > >term for the VSTa system of security. > > > > Nope, this is unique to VSTa. > > If you're refering to the term "capability", this is a common term. > I've run across it several times before running across VSTa. > In _Operating Systems - Design and Implementation_ A. Tanenbaum > talks about a 2-dimensional table where the rows specify domains of > execution and columns specify various objects. The entries in the > tables are the rights. He first covers ACL's which are column slices > of the table. Then: > > "The other way of slicing up the matrix... is by rows. When > this method is used, associated with each process is a list of > objects that may be accessed, along with an indication of which > operations are permitted on each, in other words, its domain. > This list is called a capability list, and the individual items > on it are called capabilities." Section 5.5.3, page 293. Quoting "Glossary of Computer Security Terms" (NCSC-TG-004) A protected identifier that both identifies the object and specifies the access rights to be alowed to the accessor who possesses the capability. In a capability-based system, access to protected objects such as files is granted if the would-be accessor posseses a capability for the object. [ Im assuming some (standard) technical solution is used to stop simple forgery and copying of capabiliites. ] Any system based on rows of the matrix can be problematic, there is are two obvious problems: revocation - you dont know who has access so how do you revoke it. scalability - for a large system the number of capabilities that must be maintained for a process is also large In regard to the ideas (Andy, Dave, et al) of making VSTa a "very secure" system. Security is basically risk management, until VSTa is used in a critical area the risk is small and consequently the security is great. :-) However in high risk areas (banking ...) I am not convinced the security system currently in place will suffice for the proper assurance of confidentiality (non-disclosure), integrity and availability. [ The so called C-I-A triangle, because it is normally seen as a 3 way trade-off. ] Some details on problems of risk management (security): The problem of availability is sometimes divided into protection against denial-of-service (DOS :-) attacks and reliability issues. I'll leave reliability aside until VSTa goes commercial :-), but DOS attacks are normally aimed at limited resources - network, memory, disk, CPU, etc. Non-disclosure is normally an issue of simple Trojan horses, covert channels (unintended information channels) and users incorrectly setting their permissions. Integrity is often seen as the 3 fold question of data, program and user integrity. Program integrity relies on assurance that only "good" programs are used to create "good" data. This requires both the validation of programs and the identification of those programs that have met the desired assurance level. [ eg you could have 2 sort programs, 1 that appears to be correct and is really quick, and a second you "know" is correct but is slower. In some cases you only want to allow the second to be used. ] Data integrity is primarily the use of information theory to validate data, and user integrity is largely a managerial problem :-) As justification for my pedantry, I'd like to refer people the effort currently being expended to develop and deploy firewalls and companies and universities all around the world --- standard systems are not secure enough. regards, JonT Disclaimers: I am a postgraduate stduent on a scholarship, not an employee of Microsoft ... From vandys@glare.cisco.com Mon Dec 12 22:29:09 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA05154; Mon, 12 Dec 1994 22:29:08 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id WAA02361 for ; Mon, 12 Dec 1994 22:54:26 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id UAA13905; Mon, 12 Dec 1994 20:48:37 -1000 From: Tim Newsham Message-Id: <199412130648.UAA13905@zang.kcc.hawaii.edu> Subject: Re: capabilities / security (was Re: VSTa - First Impressions) To: t-jont@microsoft.com (Jonathon Tidswell) Date: Mon, 12 Dec 1994 20:48:36 -1000 (HST) Cc: vsta@cisco.com In-Reply-To: <9412130018.AA19404@netmail2.microsoft.com> from "Jonathon Tidswell" at Dec 13, 94 10:15:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1931 > Some details on problems of risk management (security): > > The problem of availability is sometimes divided into protection against > denial-of-service (DOS :-) attacks and reliability issues. > I'll leave reliability aside until VSTa goes commercial :-), but DOS > attacks are > normally aimed at limited resources - network, memory, disk, CPU, etc. the schedulers tree nature can be used to protect cpu resources. Each process and its decendants get only their fare share of the cpu. The network and disk resources need to be protected by their servers not the kernel. > Non-disclosure is normally an issue of simple Trojan horses, covert > channels (unintended information channels) and users incorrectly > setting their permissions. I think systems that block the flow of information from "classified" to "unclassified" can be built on top of the current protection model. I also think that schemes such as "type enforcement" might be implementable on top of the current mode. This takes care of issues such as trojan horses (trojan horse can be run at higher security level but can never communicate information to a lower security level without going through a covert channel). > As justification for my pedantry, I'd like to refer people the effort > currently being > expended to develop and deploy firewalls and companies and universities all > around the world --- standard systems are not secure enough. efforts to build firewalls on unix based systems? The security model provided with unix is not very flexible. This is a well known fact. (Security was an afterthought in unix, not part of the design spec). Recently a company introduced a firewall based on BSDI with additions to do type-enforcement which is a step in the right direction. > regards, > JonT In my opinion the primitives provided by VSTa are sufficient to build a high-security system. Tim N. From vandys@glare.cisco.com Tue Dec 13 10:55:28 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05235; Tue, 13 Dec 1994 10:55:26 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA17308 for ; Tue, 13 Dec 1994 11:20:44 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id NAA11082; Tue, 13 Dec 1994 13:20:34 -0600 Received: by mort (5.0/1.34) id AA08287; Tue, 13 Dec 1994 14:12:14 -0600 Date: Tue, 13 Dec 1994 14:12:14 -0600 Message-Id: <9412132012.AA08287@mort> To: vsta@cisco.com Subject: better ls Content-Length: 1143 A while back someone posted that they had created an ls command that did most of the things that the standard UNIX ls did and was all around much better than the ls command in the vsta distribution. Would it be possible to post the code for that ls, or make it available on an anonymous ftp site somewhere. It would really be nice to have an ls that does what you expect it to do. Also, while I'm here, the ls that comes with the distribution has a few bugs. If you mount one directory over another, ls only shows the files in the directory that was mounted last, even though you can still access the files in the other directory. Also, if I mount a vstafs filesystem on /v, then mount another vstafs filesystem on /v/home and ls in / will show two v's. I'll probably try to track these bugs down as a lesson learning about vsta, but someone more knowlegable than I might know how to fix the problems in a few minutes. Brett McCoy, UNIX Systems Administrator Computing and Network Services, Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu PGP Key available on request From vandys@glare.cisco.com Tue Dec 13 12:04:31 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA05259; Tue, 13 Dec 1994 12:04:25 -0800 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA21555 for ; Tue, 13 Dec 1994 12:27:46 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA19633; Tue, 13 Dec 1994 21:27:19 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA17661; Tue, 13 Dec 1994 21:27:10 +0100 Date: Tue, 13 Dec 1994 21:27:10 +0100 Message-Id: <9412132027.AA17661@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Q: simple error (sure) but I can't ind it From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Inside a server I tried to pass a message which I got from a server below up to a client without touching it. For this I wrote: o = msg_send(port,&om); [ check for succes deleted here ] /* now copy the result back */ m->m_arg = om.m_arg; m->m_arg1 = om.m_arg1; for( n=0; nm_seg[n] = om.m_seg[n]; } m->m_nseg = om.m_nseg; msg_reply(m->m_sender, m); But this hangs inside msg_reply. Why? Thanx /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Tue Dec 13 13:30:21 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id NAA05268; Tue, 13 Dec 1994 13:30:19 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id NAA17226; Tue, 13 Dec 1994 13:55:41 -0800 Message-Id: <199412132155.NAA17226@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com Subject: Re: Q: simple error (sure) but I can't ind it In-Reply-To: Your message of "Tue, 13 Dec 1994 21:27:10 +0100." <9412132027.AA17661@ibch01.inf.tu-dresden.de> Date: Tue, 13 Dec 1994 13:55:41 -0800 From: Andrew Valencia [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] >Inside a server I tried to pass a message which I got from a server >below up to a client without touching it. Nope, a client provides a buffer into which he receives data (if his m_op has the M_READ bit). There are no message segments provided from the server to the client. I don't know how you set up "om" before using it for the msg_send(), so it's hard to say what's happening here. At a guess, you should be setting "om" up pretty much the same way before both the msg_send() (so you describe the buffer into which you will receive data) and also before the msg_reply() (and now you're describing your own buffer, which happens to hold the previously received data). Andy From vandys@glare.cisco.com Tue Dec 13 19:06:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA05317; Tue, 13 Dec 1994 19:06:37 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA14584 for ; Tue, 13 Dec 1994 19:31:53 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rHkOs-00047OC; Wed, 14 Dec 94 03:29 GMT Received: from amri.cisco.com by mail3.netcom.com (8.6.9/Netcom) id TAA00916; Sat, 10 Dec 1994 19:35:17 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA04779; Sat, 10 Dec 1994 19:07:22 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA29664 for ; Sat, 10 Dec 1994 19:32:16 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rGeyZ-00048EC; Sun, 11 Dec 94 03:29 GMT Received: from amri.cisco.com by mail2.netcom.com (8.6.9/Netcom) id TAA12965; Sat, 10 Dec 1994 19:16:15 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA04769; Sat, 10 Dec 1994 18:47:30 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA29442 for ; Sat, 10 Dec 1994 19:12:31 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rGefW-00048EC; Sun, 11 Dec 94 03:09 GMT Received: from amri.cisco.com by mail3.netcom.com (8.6.9/Netcom) id XAA10785; Fri, 9 Dec 1994 23:07:13 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA04621; Fri, 9 Dec 1994 22:38:34 -0800 Received: from zang.kcc.hawaii.edu (zang.kcc.hawaii.edu [128.171.105.6]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id XAA01166; Fri, 9 Dec 1994 23:03:35 -0800 Received: (from newsham@localhost) by zang.kcc.hawaii.edu (8.6.9/zang) id VAA07187; Fri, 9 Dec 1994 21:02:45 -1000 From: Tim Newsham Message-Id: <199412100702.VAA07187@zang.kcc.hawaii.edu> Subject: Re: VSTa - First Impressions Old-To: vandys@cisco.com (Andrew Valencia) Date: Fri, 9 Dec 1994 21:02:44 -1000 (HST) Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199412092250.OAA10273@glare.cisco.com> from "Andrew Valencia" at Dec 9, 94 02:50:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2639 Old-To: ryanh@ryanh.ping.com Status: O Old-To: ryanh@ryanh.ping.com To: ryanh@ryanh.ping.com > >CVS. I have had some limited experience with CVS and I agree with those who > >suggested it's use for the management of the project source. Andrew said he > >was going to do this, did it happen? (this is more a bit of curosity than > >anything I guess). > > CVS (remote version) requires rsh access, which is incompatible with > firewalls. Even if we cant use the distributed version of CVS, CVS should still be used. It does everything RCS does (it uses RCS, so this is easy :) and then a whole lot more. I imagine it wouldn't be hard to change the rsh interface to a messaging interface. Since VSTa will eventually have a network-proxy for message passing this should be suitable. > >Is this an official term? I have seen Andy refer to this as "VSTa protection" > >and such too. I read one of the Plan9 papers which didn't make any mention > >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that > >especially in the VSTa white paper, "Capabilities" seems to be almost a proper > >term for the VSTa system of security. > > Nope, this is unique to VSTa. If you're refering to the term "capability", this is a common term. I've run across it several times before running across VSTa. In _Operating Systems - Design and Implementation_ A. Tanenbaum talks about a 2-dimensional table where the rows specify domains of execution and columns specify various objects. The entries in the tables are the rights. He first covers ACL's which are column slices of the table. Then: "The other way of slicing up the matrix... is by rows. When this method is used, associated with each process is a list of objects that may be accessed, along with an indication of which operations are permitted on each, in other words, its domain. This list is called a capability list, and the individual items on it are called capabilities." Section 5.5.3, page 293. He also gives some references which are pretty old (1966, 1974). There are other systems which use capabilities including the MACH microkernel (port rights). I have never seen it used in quite the way that VSTa implements them. I think VSTa's approach is quite nice, it easily allows processes to make up their own capability definitions and still use the standard library routines to manipulate them. It also has a convenient mechanism for giving away weaker versions of a capability and an easy mechanism for disabling priveledges that one has. I think this system *could* be used to make VSTa a very secure system. (I emphasize "could" because the primitives are just a tool, putting them to work is still a lot of work). > Andy From vandys@glare.cisco.com Tue Dec 13 19:06:37 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA05315; Tue, 13 Dec 1994 19:06:36 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA14580 for ; Tue, 13 Dec 1994 19:31:52 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rHkOx-00048EC; Wed, 14 Dec 94 03:29 GMT Received: from amri.cisco.com by mail2.netcom.com (8.6.9/Netcom) id TAA14062; Sat, 10 Dec 1994 19:35:22 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA04776; Sat, 10 Dec 1994 19:07:15 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA29663 for ; Sat, 10 Dec 1994 19:32:13 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rGeyV-00047OC; Sun, 11 Dec 94 03:29 GMT Received: from amri.cisco.com by mail2.netcom.com (8.6.9/Netcom) id TAA12953; Sat, 10 Dec 1994 19:16:02 -0800 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA04771; Sat, 10 Dec 1994 18:47:32 -0800 Received: from ryanh.ping.com (root@ryanh.ping.com [166.78.18.88]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id TAA29443 for ; Sat, 10 Dec 1994 19:12:32 -0800 Received: by ryanh.ping.com (Linux Smail3.1.28.1 #5) id m0rGefT-00047OC; Sun, 11 Dec 94 03:09 GMT Received: from amri.cisco.com by netcom6.netcom.com (8.6.9/Netcom) id OAA09210; Fri, 9 Dec 1994 14:53:51 -0800 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA04582; Fri, 9 Dec 1994 14:25:12 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA10273; Fri, 9 Dec 1994 14:50:11 -0800 Message-Id: <199412092250.OAA10273@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol Old-To: jeske@uiuc.edu Cc: vsta@cisco.com Subject: Re: VSTa - First Impressions In-Reply-To: Your message of "Fri, 09 Dec 1994 01:06:19 CST." <199412090706.AA29554@ux4.cso.uiuc.edu> Date: Fri, 09 Dec 1994 14:50:10 -0800 From: Andrew Valencia Old-To: ryanh@ryanh.ping.com Status: O Old-To: ryanh@ryanh.ping.com To: ryanh@ryanh.ping.com [David Jeske writes:] >First, Shared Libraries. How did they end up getting implemented? Is there >an archive of the "shared lib mailing list"? No, creating the list made it all quiet down. :-) The short version is, you link against a library of stubs, one per entry point. All the stubs call a little bit of code which maps in the shared library loader, and passes the requested library and entry point to it. The current loader maps in the real library, and calls the code. All entries are done via a table, which is at the front of a shared library. Thus, detecting a NULL pointer for the table causes the load; thereafter, the vector is pulled from the table and the routine called directly. >... The archives >would be great, because if there are reasons that some methods were decided >against (shlib server, etc.) I am interested in knowing what they were. Mostly, simplicity. More to the point, I was on the road, had some time, picked a way, and went for it. >Also, what happened to the idea of "moving the scheduler out of the kernel"? That was never seriously considered. > Going with the "less in the kernel is more" idea, why wasn't this >discussed? Well, I used not so much the philosophy "everything possible out of the kernel", but the quite different "put enough in the kernel so hereafter you can stay out". > I think that allowing the flexibility to write your >own scheduler is on of the more interesting prospects of a microkernel, >and being able to do so while retaining compatibility (read, no source or >binary changes) with the "microkernel proper" is enticing. However, I'm >not really aware of possible performance penalties. They can be significant, although several operating systems have devised interfaces efficient enough to be acceptable. Often they involve having the scheduling process identify numberous processes all at once, which are then run in order until the list is empty. These schemes usually pick up a lot of complexity when faced with changing priority situations, for instance. >CVS. I have had some limited experience with CVS and I agree with those who >suggested it's use for the management of the project source. Andrew said he >was going to do this, did it happen? (this is more a bit of curosity than >anything I guess). CVS (remote version) requires rsh access, which is incompatible with firewalls. >Is this an official term? I have seen Andy refer to this as "VSTa protection" >and such too. I read one of the Plan9 papers which didn't make any mention >of Capabilites (as far as I remember). Is this a Plan9 term? It seems that >especially in the VSTa white paper, "Capabilities" seems to be almost a proper >term for the VSTa system of security. Nope, this is unique to VSTa. >More importantly, is this term one which should be perpetuated? I don't think we've settled on an accepted terminology in this area. Since I'm involved with Kerberos these days I find myself using some of their terms, now that I've learned them. Glad you found VSTa, hopefully we can load you down with work! :-) Andy From vandys@glare.cisco.com Tue Dec 13 23:41:44 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA05351; Tue, 13 Dec 1994 23:41:42 -0800 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA23402 for ; Wed, 14 Dec 1994 00:07:07 -0800 Received: by netmail2.microsoft.com (5.65/25-eef) id AA23830; Wed, 14 Dec 94 00:07:10 -0800 Message-Id: <9412140807.AA23830@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 14 Dec 94 00:07:10 PST X-Msmail-Message-Id: 22780B3C X-Msmail-Conversation-Id: 22780B3C From: Jonathon Tidswell (MS Research Fellow) To: jeske@uiuc.edu, newsham@zang.kcc.hawaii.edu Date: Wed, 14 Dec 94 18:55:44 TZ Subject: Re: capabilities / security (was Re: VSTa - First Impressions) Cc: vsta@cisco.com David and Tim, Thank you for your comments. I still have some doubts, which I'd be happy for someone to dispell. Becase if you can then VSTa is probably in the running to be the the first secure freely available OS. [ Ive probably opened my mouth for Choices, Oberon, Amoeba and others to stick assorted references down :-] Tim Newsham wrote: > Jonathon Tidswell wrote: > > Some details on problems of risk management (security): > > > > The problem of availability is sometimes divided into protection against > > denial-of-service (DOS :-) attacks and reliability issues. > > I'll leave reliability aside until VSTa goes commercial :-), but DOS > > attacks are > > normally aimed at limited resources - network, memory, disk, CPU, etc. > > the schedulers tree nature can be used to protect cpu resources. Each > process and its decedents get only their fare share of the cpu. This looks like an nice solution. > The network and disk resources need to be protected by their servers > not the kernel. All resources need to be protected by their respective servers, a microkernel design does not want to include excess material in the kernel, but shifting the responsibility does not solve the problem it simply increases the number of places it needs to be addressed, and correspondingly the number of places it can be poorly addressed. > > Non-disclosure is normally an issue of simple Trojan horses, covert > > channels (unintended information channels) and users incorrectly > > setting their permissions. > > I think systems that block the flow of information from "classified" > to "unclassified" can be built on top of the current protection model. > I also think that schemes such as "type enforcement" might be > implementable on top of the current mode. This takes care of issues > such as Trojan horses (Trojan horse can be run at higher security level > but can never communicate information to a lower security level without > going through a covert channel). It is possible to build systems that support other models on top of existing models, the degenerate case being to simulate the desired environment in full. However to integrate these requires modifying kernel process structures and file structures to handle the tagging needed for classifying data and processes. Equally tags need to be added for type-enforcement. [ Adding them will likely change my view of the security of the system. ] I would like to describe a Trojan horse that currently seems possible. If I've slipped up please tell me so. I write a useful utility 'po', which in addition to its role as an excellent personal organiser utility with all the bells and whistles starts a server (as you) which provides a file system on some predefined port. This filesystem is an exact replica of the filesystem that 'po' can see, except that the permissions it exports the data with are non-existent --- i.e. someone using it accesses your files as you. Obviously 'po' can only export access to files it gets, but this requires that the access of each and every program be restricted as far as possible. This means that some automatic (users are lazy) and external to 'po' (recall 'po' isn't trustworthy) protection device limiting what 'po' may see, is required. Obviously the above protection device must itself be protected from subversion. > > As justification for my pedantry, I'd like to refer people the effort > > currently being > > expended to develop and deploy firewalls and companies and universities all > > around the world --- standard systems are not secure enough. > > efforts to build firewalls on unix based systems? The security model > provided with unix is not very flexible. This is a well known fact. > (Security was an afterthought in unix, not part of the design spec). > Recently a company introduced a firewall based on BSDI with additions > to do type-enforcement which is a step in the right direction. Agreed on all points. - JonT From vandys@glare.cisco.com Wed Dec 14 00:13:45 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05355; Wed, 14 Dec 1994 00:13:44 -0800 Received: from genesis.isdn.uiuc.edu (genesis.isdn.uiuc.edu [192.17.16.222]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id AAA24085 for ; Wed, 14 Dec 1994 00:39:08 -0800 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id CAA22310; Wed, 14 Dec 1994 02:40:32 -0600 From: David Jeske Message-Id: <199412140840.CAA22310@genesis.isdn.uiuc.edu> Subject: Re: capabilities / security (was Re: VSTa - First Impressions) To: t-jont@microsoft.com (Jonathon Tidswell) Date: Wed, 14 Dec 1994 02:40:32 -0600 (CST) Cc: jeske@uiuc.edu, newsham@zang.kcc.hawaii.edu, vsta@cisco.com In-Reply-To: <9412140807.AA23830@netmail2.microsoft.com> from "Jonathon Tidswell" at Dec 14, 94 06:55:44 pm Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1770 > Tim Newsham wrote: > > Jonathon Tidswell wrote: > > > Some details on problems of risk management (security): > > > > > > The problem of availability is sometimes divided into protection against > > > denial-of-service (DOS :-) attacks and reliability issues. > > > I'll leave reliability aside until VSTa goes commercial :-), but DOS > > > attacks are > > > normally aimed at limited resources - network, memory, disk, CPU, etc. > > > > the schedulers tree nature can be used to protect cpu resources. Each > > process and its decedents get only their fare share of the cpu. > This looks like an nice solution. My question is, does the current VSTa system allow high-level servers to take lots of CPU running the requests of low level clients? If it does, then it certainly does not "fairly" share the CPU. QNX has a system for adjusting the priority of a server to match the priority of the client whose request it's serving. Is something like this worth looking into? > > The network and disk resources need to be protected by their servers > > not the kernel. > All resources need to be protected by their respective servers, a microkernel > design does not want to include excess material in the kernel, but > shifting the responsibility does not solve the problem it simply > increases the number of > places it needs to be addressed, and correspondingly the number of places > it can be poorly addressed. However, to the degree that servers are easier to maintain than kernels, it may be easier to implement the security code at the user level and it may be easier to fix security problems without interfering with other parts of the system as much. Of course it also may not, it may depend largly on the type of security problems which are introduced. From vandys@glare.cisco.com Wed Dec 14 00:23:30 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05358; Wed, 14 Dec 1994 00:23:29 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA24281 for ; Wed, 14 Dec 1994 00:48:52 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa27159; 14 Dec 94 8:48 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rHpHH-00038BC; Wed, 14 Dec 94 08:41 GMT Message-Id: From: Dave Hudson Subject: Re: better ls To: brtmac@ksu.ksu.edu Date: Wed, 14 Dec 1994 08:41:39 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <9412132012.AA08287@mort> from "brtmac@ksu.ksu.edu" at Dec 13, 94 02:12:14 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1097 Hi, brtmac@ksu.ksu.edu wrote: > > A while back someone posted that they had created an ls command that > did most of the things that the standard UNIX ls did and was all > around much better than the ls command in the vsta distribution. > Would it be possible to post the code for that ls, or make it > available on an anonymous ftp site somewhere. It would really be > nice to have an ls that does what you expect it to do. I've been offered a location to put all of my ported code up for ftp later this week (thanks David). The ports rely on some libc stuff I did at 1.3.1, but that probably won't get into the standard release until 1.4. I'll ftp up my 1.3.1 libc though if anyone want's to hack their own libc (but it will break the shared libs at the next release). For those who don't want to do anything quite so drastic I'll try and put up static linked binaries for some of the code. Hopefully the ports of yacc, bison and flex, plus the modified ports of sed and gzip will be in the next release as they just needed fixes to 1.3.2's libc, not any new code. Regards, Dave From vandys@glare.cisco.com Wed Dec 14 00:35:27 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05362; Wed, 14 Dec 1994 00:35:26 -0800 Received: from genesis.isdn.uiuc.edu (genesis.isdn.uiuc.edu [192.17.16.222]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id BAA24549 for ; Wed, 14 Dec 1994 01:00:50 -0800 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id DAA22402 for vsta@cisco.com; Wed, 14 Dec 1994 03:02:26 -0600 From: David Jeske Message-Id: <199412140902.DAA22402@genesis.isdn.uiuc.edu> Subject: VSTa FTP site To: vsta@cisco.com Date: Wed, 14 Dec 1994 03:02:26 -0600 (CST) Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 674 As I have talked to a few people and there seems to be a concensus that VSTa needs a "public"ish ftp site. I'm making my machine available. It is a fast machine with enough RAM and HD space for anything the VSTa crowd is going to throw at it. It's over a 64kbps ISDN connection, but that's not terrible. I don't anticipate it generating enough traffic for the 64k to really be a big pain for anyone. genesis.isdn.uiuc.edu:/pub/VSTa put stuff in /pub/VSTa/incoming I'll be orginizing it perodically, and I'll try and keep things current. I'm in the middle of finals right now, so if anything looks a mess, just email me and expect it to take a few days to fix. From vandys@glare.cisco.com Wed Dec 14 01:33:56 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA05379; Wed, 14 Dec 1994 01:33:55 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA25833 for ; Wed, 14 Dec 1994 01:59:16 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa11278; 14 Dec 94 9:58 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rHqOZ-00038BC; Wed, 14 Dec 94 09:53 GMT Message-Id: From: Dave Hudson Subject: Re: capabilities / security (was Re: VSTa - First Impressions) To: jeske@uiuc.edu Date: Wed, 14 Dec 1994 09:53:15 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199412140840.CAA22310@genesis.isdn.uiuc.edu> from "David Jeske" at Dec 14, 94 02:40:32 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: 1291 Hi, David Jeske wrote: > > > Tim Newsham wrote: > > > Jonathon Tidswell wrote: > > > > Some details on problems of risk management (security): > > > > > > > > The problem of availability is sometimes divided into protection against > > > > denial-of-service (DOS :-) attacks and reliability issues. > > > > I'll leave reliability aside until VSTa goes commercial :-), but DOS > > > > attacks are > > > > normally aimed at limited resources - network, memory, disk, CPU, etc. > > > > > > the schedulers tree nature can be used to protect cpu resources. Each > > > process and its decedents get only their fare share of the cpu. > > This looks like an nice solution. > > My question is, does the current VSTa system allow high-level servers to take > lots of CPU running the requests of low level clients? If it does, then it > certainly does not "fairly" share the CPU. QNX has a system for adjusting > the priority of a server to match the priority of the client whose request > it's serving. Is something like this worth looking into? This sounds like something that would need a large scheduler overhaul. I think going this way we'd also hit issues like whether or not we servers should reorder their queued clients (I think I'll leave that to someone else just now :-)). Dave From vandys@glare.cisco.com Wed Dec 14 03:35:25 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA05425; Wed, 14 Dec 1994 03:35:24 -0800 Received: from genesis.isdn.uiuc.edu (genesis.isdn.uiuc.edu [192.17.16.222]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id EAA04792 for ; Wed, 14 Dec 1994 04:00:49 -0800 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id GAA22665; Wed, 14 Dec 1994 06:02:15 -0600 From: David Jeske Message-Id: <199412141202.GAA22665@genesis.isdn.uiuc.edu> Subject: Re: capabilities / security (was Re: VSTa - First Impressions) To: dave@humbug.demon.co.uk (Dave Hudson) Date: Wed, 14 Dec 1994 06:02:12 -0600 (CST) Cc: jeske@uiuc.edu, vsta@cisco.com In-Reply-To: from "Dave Hudson" at Dec 14, 94 09:53:15 am Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1420 >> My question is, does the current VSTa system allow high-level servers to take >> lots of CPU running the requests of low level clients? If it does, then it >> certainly does not "fairly" share the CPU. QNX has a system for adjusting >> the priority of a server to match the priority of the client whose request >> it's serving. Is something like this worth looking into? > > This sounds like something that would need a large scheduler overhaul. I > think going this way we'd also hit issues like whether or not we servers > should reorder their queued clients (I think I'll leave that to someone else > just now :-)). Yes, I think priority queueing would be something which would need to be added to provide an appropriate mechanism to make this type of system work. However, even without priority queueing. A multithreaded server which adjusted each thread's priority according to the priority of the client which requested the work (one work request per thread) would provide an EXTREMELY "fair" distribution of CPU resources according to priority. However, it does sound like something which can be left until later. Ideas like this is why I original rementioned the idea of integrating external scheduler loading (even if it was into kernel space) because it would provide an easy way to work with this type of expansion. However, either of these are things that I agree would best be left until later. From vandys@glare.cisco.com Wed Dec 14 10:28:50 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05470; Wed, 14 Dec 1994 10:28:48 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA10932; Wed, 14 Dec 1994 10:54:15 -0800 Message-Id: <199412141854.KAA10932@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Jonathon Tidswell (MS Research Fellow) Cc: jeske@uiuc.edu, newsham@zang.kcc.hawaii.edu, vsta@cisco.com Subject: Re: capabilities / security (was Re: VSTa - First Impressions) In-Reply-To: Your message of "Wed, 14 Dec 1994 18:55:44 +0700." <9412140807.AA23830@netmail2.microsoft.com> Date: Wed, 14 Dec 1994 10:54:14 -0800 From: Andrew Valencia [Jonathon Tidswell (MS Research Fellow) writes:] >All resources need to be protected by their respective servers, a microkernel >design does not want to include excess material in the kernel, but >shifting the responsibility does not solve the problem it simply >increases the number of >places it needs to be addressed, and correspondingly the number of places >it can be poorly addressed. True, but much of the code is still shared (courtesy of libraries). It also allows filesystems to omit code which makes no sense--for instance, the DOS server has no per-user security or resource controls because the filesystem itself does not understand the concept of multiple users. >> > Non-disclosure is normally an issue of simple Trojan horses, covert >> > channels (unintended information channels) and users incorrectly >> > setting their permissions. Covert channels are a black hole. There are too many possibilities for modulation, and a useful general-purpose system does not result from blocking them. >> I think systems that block the flow of information from "classified" >> to "unclassified" can be built on top of the current protection model. Mandatory access control can not be built on top of the current system. More kernel mechanism would have to be added to forbid connections between different levels. MAC is only marginally justifiable, IMHO, because if you can trick them into trying to give you the data, you can usually trick them into giving it via covert channels (see above). >I would like to describe a Trojan horse that currently seems possible. >If I've slipped up please tell me so. Nope. Well, maybe. Since any process can enable/disable any of its ID's, it is entirely possible to disable all your "useful" abilities and forge perhaps a very modest subset ID. Your "po" utility thus does NOT have to inherit everything the user possesses. The user-manipulable hierarchy of ID values makes this quite practical. Assume I'm ID 1.2. I save all my mail and such under 1.2.1. Now I'm going to run that "po" program of Jonathon's, so I forget 1.2.2, delete 1.2, and run it. "po" tries to snatch my mail, but since it was saved under 1.2.1 with protection 0.0.7, he can neither read nor write it. Because he holds 1.2.2, he could forget 1.2.2.*, but never 1.2.1.*. Lest I forget, your ID's are scanned at time of connection to a server. When you manipulate your IDs, you must reconnect to your file servers, otherwise your access will not be recalculated. In practice, in a UNIX-ish world, your attack would be practical (assuming you can convince users to run your command). I've pondered a database of paths and a tabulation of "how much" to trust programs under them. This might contribute to a solution, because you could then have your shell automagically reduce abilities as it goes about running the suspect code. Andy From vandys@glare.cisco.com Wed Dec 14 10:32:26 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05474; Wed, 14 Dec 1994 10:32:25 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA11227; Wed, 14 Dec 1994 10:57:52 -0800 Message-Id: <199412141857.KAA11227@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jeske@uiuc.edu Cc: t-jont@microsoft.com (Jonathon Tidswell), newsham@zang.kcc.hawaii.edu, vsta@cisco.com Subject: Re: capabilities / security (was Re: VSTa - First Impressions) In-Reply-To: Your message of "Wed, 14 Dec 1994 02:40:32 CST." <199412140840.CAA22310@genesis.isdn.uiuc.edu> Date: Wed, 14 Dec 1994 10:57:51 -0800 From: Andrew Valencia [David Jeske writes:] >My question is, does the current VSTa system allow high-level servers to take >lots of CPU running the requests of low level clients? If it does, then it >certainly does not "fairly" share the CPU. QNX has a system for adjusting >the priority of a server to match the priority of the client whose request >it's serving. Is something like this worth looking into? This is known as "back end promotion". When we looked at providing it at HP, our ultimate decision was that its benefits were far outweighed by its costs. No system server uses "lots" of CPU (for some definition of "lots"). A low priority client would be hard-pressed to do a CPU attack via a high priority server, because the service itself would run promptly, but the low priority client would be throttled by his need to run again to launch the next request. Note that VSTa was NOT designed as a real-time system. As I tried to draw out in the overview paper, there are mechanisms often found in real-time systems which are very useful in making a microkernel operate as a general- purpose system. This is not to say I oppose using VSTa in RT, but it can help you understand why some elements of a RT system have been much more developed than others. Andy From vandys@glare.cisco.com Wed Dec 14 11:31:58 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA05485; Wed, 14 Dec 1994 11:31:57 -0800 Received: from dolly.par.univie.ac.at (dolly.par.univie.ac.at [131.130.70.42]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA26545 for ; Wed, 14 Dec 1994 11:57:23 -0800 Received: from doris.par.univie.ac.at (doris [131.130.70.22]) by dolly.par.univie.ac.at (8.6.9/8.6.9) with ESMTP id UAA28625; Wed, 14 Dec 1994 20:57:11 +0100 From: Robert Mayer - Student Received: (robert@localhost) by doris.par.univie.ac.at (8.6.9/8.6.9) id UAA01181; Wed, 14 Dec 1994 20:57:07 +0100 Date: Wed, 14 Dec 1994 20:57:07 +0100 Message-Id: <199412141957.UAA01181@doris.par.univie.ac.at> To: vsta@cisco.com Subject: New read()/write() Cc: robert@par.univie.ac.at Hi all, a recent posting to comp.os.linux.devel by Larry McVoy had a very interesting idea in it. He suggested two new library functions new_write(int handle, off_t offset, int cookie); new_read(int handle, off_t offset, int cookie); These functions would be asynchronous and report completion by incrementing the cookie (or by calling a function passed as parameter instead of cookie or whatever). Also since the offset is passed each time, the question whether two threads that share a filedescriptor (or port in VSTa) also share the seek pointer (i.e. the offset that the server associates with the connection) does not arise at all. It seems to me that these functions could be implemented very easily in VSTa: e.g. new_write() would tfork(), send an ABS_WRITE message, set the cookie after msg_send() returns (or call the notifier function, see above) and call texit(). Do you think something like this would be a useful addition to libusr.a or libc.a ? Regards, Robert. From vandys@glare.cisco.com Wed Dec 14 12:00:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA05489; Wed, 14 Dec 1994 12:00:47 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA28130 for ; Wed, 14 Dec 1994 12:26:15 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id NAA29771 for ; Wed, 14 Dec 1994 13:26:06 -0700 Message-Id: <199412142026.NAA29771@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: Re: VSTa, tsync, user level semaphores In-Reply-To: Your message of "Tue, 13 Dec 1994 21:10:44 +0900." <9412131210.AA02311@creta.dbg.bs1.fc.nec.co.jp> Date: Wed, 14 Dec 1994 13:26:05 -0700 From: Gary Shea I'm bringing this in-progress conversation to the list (by request) to see what the experts have to say. Sorry about the length... I'm the >>>'s; the other quotes are Masato Kataoka-san (kataoka@dbg.bs1.fc.nec.co.jp). His first mail to me asked why I was using an infinite-loop spinlock to protect the user-level semaphore structures: >>> Masato Kataoka San writes: >>> >If so, is this package assuming a specific scheduling policy? >>> >I mean the one that lowers priority of a process and preempts it >>> >if it's holding cpu time too long. >>> >Otherwise this slock_wait() spins forever. >>> >>> Interesting question. I must admit I never even thought about >>> it, so I guess the answer is Yes, I am assuming a pre-emptive >>> (at least) scheduling policy. >>> >>> There has been some talk of a yield() system call which would >>> give the current thread's time to another thread in the process; >>> I plan on using that whenever it appears, but I haven't really >>> thought it through. Any comments on this part? Will there be a yield() system call? I think maybe Dave Hudson mentioned that one... In the absence of such a beast, should I be giving the user more control over what the spinlock does? I guess it could simply fail after some number of (user-specified, maybe 0 => forever?) loops and return an error... EACCESS? >Is it possible to use msleep() to give CPU to another thread in the >same process? >I don't know very much about threads scheduling policy in VSTa but >yield() syscall is a good thing to have, though. The referred-to function, msleep(), is apparently available on AIX -- I don't know that VSTa has it, and I don't know anything about what it does on AIX. I suspect that what I'm calling yield() above (I can't remember what Dave called it) is the same thing as msleep(). >BTW, am I correct in saying that user level semaphores are preferable >to kernel level ones in the following reason? > > If resources are not contended so often (i.e. im most cases > taking and freeing a semaphore merely increments and decrements > the semaphore count), switching to kernel is just too expensive. > But since a resource is held in arbitrary period of time, > spin-waiting is suicidal in case of a contension even if > sleeping for a certain fixed time in spin-loop. > >Since you didn't write much on VSTa list about why user level >semaphores are good, I justed wanted to know why. If there're >other pros and cons about user-level semaphores, please enlighten me. If you're saying that using a kernel semphore is too expensive sometimes when it needn't be, and that a spinlock is impractical because it wastes cycles spinning while the resource is held, well, that's exactly what I would have said! I didn't initiate this project, by the way, I just asked Andy what might be a good thing to work on... >>> Do you have a suggestions about what we should be doing instead >>> of the infinite loop? I'm open to suggestions. >But if msleep() can give CPU to another thread in the same process >(even if it MAY give CPU to another process), it might be >favorable to call msleep with a certain fixed period in spin-loop. This seems reasonable, and is pretty much what I plan to do when an msleep()-like routine appears. > >Other things I wish (if I may :-) you could consider: > >1) In order to reduce chances of spin-waiting, is it possible to not > call slock_wait() for "tsq" structure in tsema_wait()? Is it > possible to return the pointer to tsq.ts_l[i] rather than slot number? I have been getting a lock on the root structure that holds the array of semaphore structs while I test to see if the index the user gave me is valid. I think you're right, that lock is pointless; the user can trash the semaphore any time! So we might as well get rid of that particular lock-grab, but still use an index. If I didn't allow the user to delete a semaphore that's in use (i.e., reference count it), then I would need that lock, and the lock sequence to modify the reference count would be tricky. Should I ref count the semaphores? >2) Is it possible to implement kernel level semaphores with the same > interface? Thus a user can specify user-level or kernel-level in > semaphore creation call. I think kernel-level threads are better > for highly contended resources. I think the package _is_ that, right now. If a thread tries to get the resource, but it's taken, then they call tsleep (via the semaphore code) and get blocked on a kernel semaphore (which holds all user-level-semaphore-blocked threads). There _is_ the additional overhead of creating a user-level pid_t queue entry for the thread... >3) SMP case? Ideally, it should be possible to spin for some user-specified amount of time before dropping into the kernel, just in case a thread on a different processor gives up the resources. That code is not yet in place. The current code should work in the SMP case anyway (I think!). >Since I'm not an OS researcher or developer or anything, some or all >of the above comments maybe completely wrong or irrelevant. They seem right on to me... >I hope you open up a discussion on the list and let experts to talk. >(Especially thread scheduling things). >That way I can enjoy reading the discussion :-) >--- >Masato Kataoka >kataoka@dbg.bs1.fc.nec.co.jp You got it :) Gary From vandys@glare.cisco.com Wed Dec 14 20:08:15 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA05560; Wed, 14 Dec 1994 20:08:14 -0800 Received: from cton.computone.com (cton.computone.com [160.77.1.10]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id UAA23028 for ; Wed, 14 Dec 1994 20:33:18 -0800 Received: from mom.computone.com by cton.computone.com with smtp (Smail3.1.28.1 #2) id m0rI7rv-000AVIC; Wed, 14 Dec 94 23:32 EST Received: by mom.computone.com (/\==/\ Smail3.1.25.1 #25.1) id ; Wed, 14 Dec 94 23:32 EST Date: Wed, 14 Dec 1994 23:32:10 -0500 (EST) From: David Johnson To: vsta@cisco.com Subject: Help compiling libraries under VSTa Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have added the user-level semaphores to my library but I have been unable to get the library built with gcc under VSTa. It just hangs my system at: mkshlib ld.db libc.db Library ld.a @ 0x60000000 Library libc.a @ 0x60001000 I am running on a 486 w/8 Mb RAM and I have tried with swap running and without to no avail. I also had problems building some of the servers; same problem, just locks. Any pointers would be greatly appreciated. dave From vandys@glare.cisco.com Wed Dec 14 20:33:11 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA05567; Wed, 14 Dec 1994 20:33:10 -0800 Received: from genesis.isdn.uiuc.edu (genesis.isdn.uiuc.edu [192.17.16.222]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id UAA23683; Wed, 14 Dec 1994 20:58:40 -0800 Received: (from jeske@localhost) by genesis.isdn.uiuc.edu (8.6.9/8.6.9) id XAA27044; Wed, 14 Dec 1994 23:00:09 -0600 From: David Jeske Message-Id: <199412150500.XAA27044@genesis.isdn.uiuc.edu> Subject: Re: CVS To: newsham@zang.kcc.hawaii.edu (Tim Newsham) Date: Wed, 14 Dec 1994 23:00:05 -0600 (CST) Cc: vandys@cisco.com, jeske@uiuc.edu, vsta@cisco.com In-Reply-To: <199412100702.VAA07187@zang.kcc.hawaii.edu> from "Tim Newsham" at Dec 9, 94 09:02:44 pm Reply-To: jeske@uiuc.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 874 > > >CVS. I have had some limited experience with CVS and I agree with those who > > >suggested it's use for the management of the project source. Andrew said he > > >was going to do this, did it happen? (this is more a bit of curosity than > > >anything I guess). > > > > CVS (remote version) requires rsh access, which is incompatible with > > firewalls. > > Even if we cant use the distributed version of CVS, CVS should still > be used. It does everything RCS does (it uses RCS, so this is easy :) > and then a whole lot more. > I imagine it wouldn't be hard to change the rsh interface to a messaging > interface. Since VSTa will eventually have a network-proxy for > message passing this should be suitable. Where can the distributed version of CVS be found? Or is this part of a new CVS beta release? (i.e. the answer is going to be join the CVS mailing list) From vandys@glare.cisco.com Wed Dec 14 20:18:44 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA05563; Wed, 14 Dec 1994 20:18:43 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA16127; Wed, 14 Dec 1994 20:44:12 -0800 Message-Id: <199412150444.UAA16127@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: David Johnson Cc: vsta@cisco.com Subject: Re: Help compiling libraries under VSTa In-Reply-To: Your message of "Wed, 14 Dec 1994 23:32:10 EST." Date: Wed, 14 Dec 1994 20:44:12 -0800 From: Andrew Valencia [David Johnson writes:] >I have added the user-level semaphores to my library but I have been >unable to get the library built with gcc under VSTa. It just hangs my >system at: > mkshlib ld.db libc.db > Library ld.a @ 0x60000000 > Library libc.a @ 0x60001000 Probably tmpfs ate all your RAM. The default blocksize is 8K, one block is used per filesysystem entry, and there is one filesystem entry per C library entry point during mkshlib'ing of libc. Workarounds: unmount /tmp and make a /tmp on your DOS filesystem. Or recompile srv/tmpfs with a smaller blocksize (and install/reboot). >I am running on a 486 w/8 Mb RAM and I have tried with swap running and >without to no avail. I also had problems building some of the servers; >same problem, just locks. ^Z to get the kernel debugger. "dv freemem". If it's zero, you ran out of RAM. Don't mess with swap yet; it has its own collection of grief right now. If you have swap configured and freemem > 0, you probably hit one of the deadlocks we've discovered. Andy From vandys@glare.cisco.com Thu Dec 15 02:54:04 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id CAA05716; Thu, 15 Dec 1994 02:53:59 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA09858 for ; Thu, 15 Dec 1994 03:13:43 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA10269; Thu, 15 Dec 1994 12:10:25 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA33645; Thu, 15 Dec 1994 12:08:44 +0100 Date: Thu, 15 Dec 1994 12:08:44 +0100 Message-Id: <9412151108.AA33645@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: How to pass a message From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Hi all, While writing on a server (which should become a second layer on to of another filesystem) I really need to pass a message down to this server below. While everything else works, I'm not able to do this (while I still belive it shouldn't be too hard). All I need is a function passmgs(struct msg* m, void * f) which takes the message as I got it from the client, passes it down to the layer below me and -- depending on the result from this layer -- answers either with msg_err and the error I got or msg_reply's with the answer I got. But I can't say anything about the message, I have to pass it as it is. Please could a kind person help me? Thanx /joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Thu Dec 15 08:37:20 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA05749; Thu, 15 Dec 1994 08:37:19 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA23239 for ; Thu, 15 Dec 1994 09:02:49 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa09380; 15 Dec 94 16:45 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rIJ9V-0002kGC; Thu, 15 Dec 94 16:35 GMT Message-Id: From: Dave Hudson Subject: Re: VSTa, tsync, user level semaphores To: Gary Shea Date: Thu, 15 Dec 1994 16:35:37 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199412142026.NAA29771@xmission.xmission.com> from "Gary Shea" at Dec 14, 94 01:26:05 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: 732 Hi, Gary Shea wrote: > > Any comments on this part? Will there be a yield() system call? > I think maybe Dave Hudson mentioned that one... Yes, any thread will be able to call sched_yield() - the scheduler gets to decide who has the next go though (in case something more urgent comes along). > The referred-to function, msleep(), is apparently available on > AIX -- I don't know that VSTa has it, and I don't know anything > about what it does on AIX. I suspect that what I'm calling yield() > above (I can't remember what Dave called it) is the same thing as > msleep(). We have __msleep() (I think it has the 2 underscores :-)) We even have __usleep(). They both use the same underlying mechanism. Regards, Dave From vandys@glare.cisco.com Thu Dec 15 10:38:28 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05777; Thu, 15 Dec 1994 10:38:26 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA22783; Thu, 15 Dec 1994 11:03:58 -0800 Message-Id: <199412151903.LAA22783@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: VSTa, tsync, user level semaphores In-Reply-To: Your message of "Wed, 14 Dec 1994 13:26:05 MST." <199412142026.NAA29771@xmission.xmission.com> Date: Thu, 15 Dec 1994 11:03:58 -0800 From: Andrew Valencia [Gary Shea writes:] >His first mail to me asked why I was using an infinite-loop >spinlock to protect the user-level semaphore structures: Because, statistically, it won't be held (since it protects only a few instructions) and it is much, much cheaper than dropping into the kernel. Having yield() available might be a plus. >In the absence of such a beast, should I be giving the user more >control over what the spinlock does? I guess it could simply >fail after some number of (user-specified, maybe 0 => forever?) >loops and return an error... EACCESS? This can be useful for some errors, but not otherwise. After all, this is not the spinlock protecting the ultimate resources, this is the spinlock protecting the semaphore's own state. >If you're saying that using a kernel semphore is too expensive >sometimes when it needn't be, and that a spinlock is impractical >because it wastes cycles spinning while the resource is held, well, >that's exactly what I would have said! If you can do a user-level atomic operation in a single instruction, and a reasonable fraction of the time take an uncontended resource, you are way ahead of a kernel transition. Remember, our friends at Intel have given us a ring 3->0 transition time of 100-200 cycles (depending on what you save) and another 30-100 to come back. This is for a null kernel call. An atomic bit test/set is (from memory) 1? 3? cycles. >>But if msleep() can give CPU to another thread in the same process >>(even if it MAY give CPU to another process), it might be >>favorable to call msleep with a certain fixed period in spin-loop. >This seems reasonable, and is pretty much what I plan to do when >an msleep()-like routine appears. As Dave already noted, we have __msleep() and __usleep() already. yield() is on its way. >>2) Is it possible to implement kernel level semaphores with the same >> interface? Thus a user can specify user-level or kernel-level in >> semaphore creation call. I think kernel-level threads are better >> for highly contended resources. >I think the package _is_ that, right now. If a thread tries to >get the resource, but it's taken, then they call tsleep (via the >semaphore code) and get blocked on a kernel semaphore (which holds >all user-level-semaphore-blocked threads). There _is_ the additional >overhead of creating a user-level pid_t queue entry for the thread... Right. For highly contended resources, you spend most of your time not running, so the 1:100 (or more) cycle ratio is a wash. That is, it isn't worth optimizing. This leaves optimizing the case of uncontended resources. >Ideally, it should be possible to spin for some user-specified >amount of time before dropping into the kernel, just in case a >thread on a different processor gives up the resources. That >code is not yet in place. The current code should work in the >SMP case anyway (I think!). Yes, we already bounced this around. I guess it isn't as important until I get my dual-Pentium motherboard. Please, no floating point jokes. I am seriously out wangling for a dual processor system, at which point I can start playing with SMP again. Regards, Andy From vandys@glare.cisco.com Thu Dec 15 10:46:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05780; Thu, 15 Dec 1994 10:46:08 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA00124 for ; Thu, 15 Dec 1994 11:11:41 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id NAA18996; Thu, 15 Dec 1994 13:11:39 -0600 Received: by mort (5.0/1.34) id AA13618; Thu, 15 Dec 1994 13:11:30 -0600 Date: Thu, 15 Dec 1994 13:11:30 -0600 Message-Id: <9412151911.AA13618@mort> To: vsta@cisco.com Subject: VSTa networking questions Content-Length: 1411 Okay, I finally got my hands on an ne2000 clone card. It works fine with DOS packet drivers. The ne server recognizes it and it appears to be working. I can mount the server on /net and do: cat /net/0 or cat /net/800 and it starts spitting things out, so I'm assuming that it's working at least somewhat. My question is, what to do from here? I've tried running 'net', the ka9q stuff, but can't seem to figure out the magic set of commands to get it to do anything. Can someone tell me how to configure it to talk to the ne server? Second, what is the status of the TCP/IP server? Is it in a working state at all? I wouldn't mind doing some debugging if I can get some source to play with. I don't quite feel like reinventing the wheel though. One final question, which doesn't really have to deal with networking in particular. How does the kernel decide who can access io ports? I was able to run the ne server while logged with with ids: 3.101(101), 1.1(101) I haven't quite got ids and capabilities totally figured out yet, though I've got the basics figured out okay. However, it would seem to me that only should be able to access io ports. Thanks. Brett McCoy, UNIX Systems Administrator Computing and Network Services, Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu PGP Key available on request From vandys@glare.cisco.com Thu Dec 15 10:53:30 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05783; Thu, 15 Dec 1994 10:53:29 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA00478; Thu, 15 Dec 1994 11:19:01 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id NAA19305; Thu, 15 Dec 1994 13:18:59 -0600 Received: by mort (5.0/1.34) id AA13658; Thu, 15 Dec 1994 13:18:55 -0600 Date: Thu, 15 Dec 1994 13:18:55 -0600 Message-Id: <9412151918.AA13658@mort> To: Andrew Valencia Cc: vsta@cisco.com Subject: Re: vsta mount tutorial In-Reply-To: <199411282359.PAA01060@glare.cisco.com> References: <9411282243.AA00995@mort> <199411282359.PAA01060@glare.cisco.com> Content-Length: 1269 Verily did Andrew Valencia say on November 28, 1994: >[brtmac@ksu.ksu.edu writes:] > >>First, I was under the impression that it was possible to mount a >>filesystem on top of a directory and still be able to see the existing >>directory (stackable or translucent filesystems). I haven't been able >>to figure out how to do this. > >Yes, although this code has been exercised little. Hmm, it appears that what was throwing me off was that the ls command is only showing files in the last mount. If I mount my home filesystem over /tmp, ls only shows the directories and files in the /home filesystem, but I can still access the files in /tmp with vi, cat, etc. Anyone know why this is offhand? I sort of gave up on the idea of mounting a vsta filesystem stored in a file on a dos filesystem over the top of the dos root filesystem. It was making things way too hard to figure out considering I didn't quite understand what was going on in the first place. I have a better grasp on how everything works now, so maybe I'll do some more playing. Brett McCoy, UNIX Systems Administrator Computing and Network Services, Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu PGP Key available on request From vandys@glare.cisco.com Thu Dec 15 10:55:24 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA05786; Thu, 15 Dec 1994 10:55:23 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA00550 for ; Thu, 15 Dec 1994 11:20:56 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id NAA19349; Thu, 15 Dec 1994 13:20:12 -0600 Received: by mort (5.0/1.34) id AA13662; Thu, 15 Dec 1994 13:20:10 -0600 Date: Thu, 15 Dec 1994 13:20:10 -0600 Message-Id: <9412151920.AA13662@mort> To: vsta@cisco.com Subject: how to make fd bootable Content-Length: 453 What has to be done to make a server loadable by boot.exe? I was playing with making a bootable VSTa floppy, but boot.exe gave me an error when I tried adding fd to the boot.lst file? It said that it hadn't been linked for booting. Brett McCoy, UNIX Systems Administrator Computing and Network Services, Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu PGP Key available on request From vandys@glare.cisco.com Thu Dec 15 15:37:59 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA05821; Thu, 15 Dec 1994 15:37:58 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA17060; Thu, 15 Dec 1994 16:03:31 -0800 Message-Id: <199412160003.QAA17060@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: brtmac@ksu.ksu.edu Cc: vsta@cisco.com Subject: Re: how to make fd bootable In-Reply-To: Your message of "Thu, 15 Dec 1994 13:20:10 CST." <9412151920.AA13662@mort> Date: Thu, 15 Dec 1994 16:03:30 -0800 From: Andrew Valencia [brtmac@ksu.ksu.edu writes:] >What has to be done to make a server loadable by boot.exe? I was >playing with making a bootable VSTa floppy, but boot.exe gave me >an error when I tried adding fd to the boot.lst file? It said that >it hadn't been linked for booting. You need to use crt0srv.o instead of crt0.o. You also have to link with the static library (-lc_s) instead of the shared library version. Andy From vandys@glare.cisco.com Fri Dec 16 00:26:51 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA05859; Fri, 16 Dec 1994 00:26:49 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA02147 for ; Fri, 16 Dec 1994 00:52:21 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa15953; 16 Dec 94 8:50 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rIYLx-00036pC; Fri, 16 Dec 94 08:49 GMT Message-Id: From: Dave Hudson Subject: Re: how to make fd bootable To: brtmac@ksu.ksu.edu Date: Fri, 16 Dec 1994 08:49:29 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 629 brtmac@ksu.ksu.edu wrote: > > What has to be done to make a server loadable by boot.exe? I was > playing with making a bootable VSTa floppy, but boot.exe gave me > an error when I tried adding fd to the boot.lst file? It said that > it hadn't been linked for booting. As Andy, mentioned, fd needs to be linked statically - you'll find though that the boot process is painful (around 6 minutes I found). I've optimised boot.exe and the fd server code to make it load to a login prompt in about 60 seconds now. Hopefully this will get put onto David Jeske's ftp are sometime in the next couple of days. Regards, Dave From vandys@glare.cisco.com Fri Dec 16 04:48:14 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id EAA05924; Fri, 16 Dec 1994 04:48:12 -0800 Received: from TYO1.gate.nec.co.jp (TYO1.gate.nec.co.jp [202.32.8.9]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id FAA13533 for ; Fri, 16 Dec 1994 05:13:49 -0800 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO1.gate.nec.co.jp (8.6.9+2.4Wb3/3.3Wb-NEC-TYO1) with SMTP id SAA01352 for ; Fri, 16 Dec 1994 18:38:04 +0900 Received: from mailsv.bs1.fc.nec.co.jp (venus.d2.bs1.fc.nec.co.jp) by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA29138; Fri, 16 Dec 1994 18:38:02 +0900 Received: from java.dbg.bs1.fc.nec.co.jp by mailsv.bs1.fc.nec.co.jp (8.6.9/6.4JAIN) id SAA03393; Fri, 16 Dec 1994 18:38:01 +0900 Received: from creta.dbg.bs1.fc.nec.co.jp by java.dbg.bs1.fc.nec.co.jp (8.6.9+2.4W/3.3W) id JAA24805; Fri, 16 Dec 1994 09:38:37 GMT Received: by creta.dbg.bs1.fc.nec.co.jp (4.0/6.4J.6) id AA01739; Fri, 16 Dec 94 18:33:26 JST Message-Id: <9412160933.AA01739@creta.dbg.bs1.fc.nec.co.jp> To: vsta@cisco.com Subject: Re: VSTa, tsync, user level semaphores In-Reply-To: Your message of Thu, 15 Dec 94 11:03:58 -0800. <199412151903.LAA22783@glare.cisco.com> Reply-To: kataoka@dbg.bs1.fc.nec.co.jp Date: Fri, 16 Dec 94 18:33:25 +0900 From: Masato Kataoka Andrew Valencia San writes: >> >His first mail to me asked why I was using an infinite-loop >> >spinlock to protect the user-level semaphore structures: >> >> Because, statistically, it won't be held (since it protects only a few >> instructions) and it is much, much cheaper than dropping into the kernel. >> Having yield() available might be a plus. What I was wondering is that if some thread scheduling policies make it impossible to do spin-waiting. If a higher priority thread preempts a lower priority thread which is manipulating a semphore state, the higher priority thread must somehow give up the CPU. It is a statistically very rare case, yet once that happens, the thread or the scheduler must do something to prevent locking up the whole process. I don't think this won't happen in the current VSTa's scheduler, as the higher priority thread which is spinning eventually will get a lower priority than the thread holding the semaphore's lock and get preempted. Is this right? Since I'm quite unhappy about the performance of unix IPC semaphores (it even checks permissions every time because IPC semaphores are independent of shared memory), the user level semaphores will be a very attractive feature (among others). >> Yes, we already bounced this around. I guess it isn't as important until I >> get my dual-Pentium motherboard. Please, no floating point jokes. I am >> seriously out wangling for a dual processor system, at which point I can >> start playing with SMP again. I'm glad to hear that. A free SMP-capable true mirokernel! Thanks for your comments. --- Masato Kataoka kataoka@dbg.bs1.fc.nec.co.jp From vandys@glare.cisco.com Sat Dec 17 14:11:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA06089; Sat, 17 Dec 1994 14:11:04 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA14426 for ; Sat, 17 Dec 1994 14:36:50 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id PAA05636 for ; Sat, 17 Dec 1994 15:36:06 -0700 Message-Id: <199412172236.PAA05636@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Subject: SLIP/PPP Date: Sat, 17 Dec 1994 15:36:05 -0700 From: Gary Shea From a glance at ka9q, it appears to support SLIP. Has anyone worked on that? I have no access to a wire with my machine which (occasionally) runs VSTa, but I can SLIP onto this machine. I would sure love to run VSTa over SLIP... if only to break the "switch to DOS to tar/upload then back to VSTa to work" cycle. Gary From vandys@glare.cisco.com Sun Dec 18 20:45:42 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA06213; Sun, 18 Dec 1994 20:45:40 -0800 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA20374; Sun, 18 Dec 1994 21:11:33 -0800 Received: by netmail2.microsoft.com (5.65/25-eef) id AA21968; Sun, 18 Dec 94 21:11:48 -0800 Message-Id: <9412190511.AA21968@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 18 Dec 94 21:11:48 PST X-Msmail-Message-Id: D606A478 X-Msmail-Conversation-Id: D606A478 From: Jonathon Tidswell (MS Research Fellow) To: vandys@cisco.com Date: Mon, 19 Dec 94 16:01:31 TZ Subject: Re: capabilities / security Cc: vsta@cisco.com Andrew Valencia wrote: > [Jonathon Tidswell (MS Research Fellow) writes:] [ ...] > >All resources need to be protected by their respective servers, a microkernel > >design does not want to include excess material in the kernel, but > >shifting the responsibility does not solve the problem it simply > >increases the number of > >places it needs to be addressed, and correspondingly the number of places > >it can be poorly addressed. > > True, but much of the code is still shared (courtesy of libraries). It also > allows filesystems to omit code which makes no sense--for instance, the DOS > server has no per-user security or resource controls because the filesystem > itself does not understand the concept of multiple users. In a multiuser "secure" system, I would hope all servers that did not support both mulitple users and security protection would be "provably" hidden behind servers that do. Fortunately personal development machines (based on DOS) are unlikely to either multiuser or secure and the advantages of FAT justify its use. (did I write those words :-) Equally in many cases the overhead of security checking is unnecessary. And in these cases not burdening the kernel with security is a big win. [ However, the way the Internet is going and the way system prices are going, I expect companies will be willing to spend for dual pentiums if that will allow them to have a more secure system. ] [ actually quoting me - JonT ] > >> > Non-disclosure is normally an issue of simple Trojan horses, covert > >> > channels (unintended information channels) and users incorrectly > >> > setting their permissions. > > Covert channels are a black hole. There are too many possibilities for > modulation, and a useful general-purpose system does not result from > blocking them. I agree with the first statement and I'd love any references supporting the second. [ I can see that the second could easily be true, but I'd like to be able to cite something at uni. ] > >I would like to describe a Trojan horse that currently seems possible. > >If I've slipped up please tell me so. > > Nope. Well, maybe. Since any process can enable/disable any of its ID's, it > is entirely possible to disable all your "useful" abilities and forge > perhaps a very modest subset ID. Your "po" utility thus does NOT have to > inherit everything the user possesses. Absolutely. But how do I stop 'po' inheriting them in a way that itself cannot be attacked, but is sufficiently user trivial that users wont skip it ? [ Not rhetorical - beyond the limit of my knowledge of ID manipulation. ] > I've pondered a database of paths and a tabulation of "how much" to trust > programs under them. This might contribute to a solution, because you could > then have your shell automagically reduce abilities as it goes about running > the suspect code. Ahhh, part answer of my above question. There are a number of possibly separate questions on this idea: a) What is to be controlled based on the concept of "how much trust" ? b) How to manage the labelling of progams ? c) Where to manage the controls ? d) How to verify that the above is correct and sufficient ? (is it ?) Obnote: It would be nice if "high security" were an optional feature, but this requires that most code be independent of it. I have no idea how feasible this is. Sidenote: If security is in a library, cant I start a server that provides an alternative library for all programs started from then on, effectively bypassing the security ? - JonT From vandys@glare.cisco.com Mon Dec 19 12:22:22 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA06379; Mon, 19 Dec 1994 12:22:20 -0800 Received: from grunt.ksu.ksu.edu (root@grunt.ksu.ksu.edu [129.130.12.17]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA25502 for ; Mon, 19 Dec 1994 12:48:17 -0800 From: brtmac@ksu.ksu.edu Received: from mort by grunt.ksu.ksu.edu (8.6.8/1.34) id OAA18101; Mon, 19 Dec 1994 14:48:13 -0600 Received: by mort (5.0/1.34) id AA03496; Mon, 19 Dec 1994 14:48:05 -0600 Date: Mon, 19 Dec 1994 14:48:05 -0600 Message-Id: <9412192048.AA03496@mort> To: vsta@cisco.com Subject: boot server executables vs. execable executables Content-Length: 1731 What are the advantages and disadvantages to loading servers via the boot server and executing them after the system has booted (such as via inittab)? I understand that there are certain servers which have to be loaded via boot.lst in order for the system to boot properly. Is it the case that only the absolute necessary servers should be loaded that way? Along these lines it would seem that there should be some sort of naming convention to differentiate a server that is linked against crt0srv.o and one linked against crt0.o. That way it is obvious where something got loaded, and you don't try to put the wrong thing in boot.lst and create an unbootable system. A couple of examples. If you want to create a bootable floppy, you need to put the fd server in boot.lst, but you have to have a fd server executable that's linked against crt0srv.o. The default fd in /vsta/boot is not linked against crt0srv.o, so can't be put in boot.lst. On the other hand, for a boot floppy there is no reason to put wd in boot.lst since it can be started in inittab, or after the system is booted. But, since /vsta/boot/wd is linked against crt0srv.o, I don't believe it can be effectively started after the system has booted. Perhaps everything in /vsta/boot should be linked against crt0srv.o and copies of the servers that are linked against crt0.o should be in /vsta/bin/srv or /vsta/srv/bin or some other location. That would help differentiate between the two types of executables. Just some observations. Brett McCoy, UNIX Systems Administrator Computing and Network Services, Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu PGP Key available on request From vandys@glare.cisco.com Mon Dec 19 17:57:09 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA06404; Mon, 19 Dec 1994 17:57:07 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id SAA11035 for ; Mon, 19 Dec 1994 18:23:02 -0800 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); Tue, 20 Dec 1994 13:22:52 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA26817; Tue, 20 Dec 94 13:27:58 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA07007; Tue, 20 Dec 1994 13:24:36 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199412200224.AA07007@sour.sw.oz.au> Subject: Re: boot server executables vs. execable executables To: brtmac@ksu.ksu.edu Date: Tue, 20 Dec 1994 13:24:36 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: <9412192048.AA03496@mort> from "brtmac@ksu.ksu.edu" at Dec 19, 94 02:48:05 pm X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1829 But I thought brtmac@ksu.ksu.edu said: > What are the advantages and disadvantages to loading servers via the > boot server and executing them after the system has booted (such as > via inittab)? I understand that there are certain servers which have > to be loaded via boot.lst in order for the system to boot properly. > Is it the case that only the absolute necessary servers should be > loaded that way? Sure ... you need basic device drivers and file systems etc to get the system up an running. As far as I can tell the main disadvantages with loading images as boot tasks are they are not demand paged (i.e. always resident in core), can't share images and can't have BBS segments (not really sure why). Other than that they're standard images as far as VSTa is concerned. > Along these lines it would seem that there should be some sort of > naming convention to differentiate a server that is linked against > crt0srv.o and one linked against crt0.o. That way it is obvious where > something got loaded, and you don't try to put the wrong thing in > boot.lst and create an unbootable system. > [ sensible naming ideas omitted ] It's probably better to try and remove the need for a separate crt0srv.o and crt0.o. Having said that I'm sure if I can think of a good way of passing arguments to the boot tasks. (Hmmm, if we were using ELF we could maybe have the boot loader attach a note section or segment to the executable ... not really sure). As an aside, how does the waiting for boot servers to initialise themselves currently work? I remember someone mentioning this on the list a little while ago but can't remember the outcome ... Does it mean boot servers have to coded differently to ordinary servers? I can't find an instances of this in the server code I've looked at so far ... Cheers, Christopher. From vandys@glare.cisco.com Mon Dec 19 18:04:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA06408; Mon, 19 Dec 1994 18:04:16 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id SAA11418 for ; Mon, 19 Dec 1994 18:30:12 -0800 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); Tue, 20 Dec 1994 13:30:10 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA26994; Tue, 20 Dec 94 13:35:31 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA07042; Tue, 20 Dec 1994 13:32:09 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199412200232.AA07042@sour.sw.oz.au> Subject: ELF To: vsta@cisco.com Date: Tue, 20 Dec 1994 13:32:09 +1100 (EST) X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2719 How do people feel about adpoting ELF as the "standard" executable format in VSTa? ELF is file executable and linking format used in SVR4. It's highly portable, very cool and entirely in the spirit of the festive silly season. Seriously though, adopting ELF seems like a Good Thing. If nothing else it would most of the executable format handling code be machine independent, but there are lots of other good reasons (I'd started running into a.out limitations in my MIPS port, like no support for multiple "small" and "big" data segments etc, and adding ELF was much easier and more elegant than ECOFF). Reading over the binutils-2.5.1 documentation makes me think that it's quite stable on intel and sparc platforms (the Linux people seem to be using it quite a lot). I haven't had any problems on the MIPSen yet. I'm not sure about 68k. Adding basic support for ELF format boot tasks to my R3000 port was an afternoons work, most of which is (or could be) quite portable. To support it properly would require some changes to the machine independent code, namely making the boottask structure have a set of mapseg like entries associated with it. libc support would also be pretty easy. The machine dependent bit should be limited to some header checks (architecture, endianess etc). The only manditory change would be extending struct mapfile to allow an arbitrary number of mappings. A possible addition would be modifing mapseg to be something like: struct mapseg { void *m_vaddr; /* Vaddr to map at */ uint m_off; /* Offset into file, in pages */ uint m_memsz; /* memory size */ uint m_filesz; /* file size */ uint m_flags; /* See below */ }; where if m_filesz < m_memsz the rest of the mapping is ZFOD, which is how ELF represents such things. I would be tempted to keep the prsent ZFOD-flag style interface and have the libc code work out which bits of the mapping are ZFOD and which are demand paged and do seperate mapseg entries for them. Anyway, if you're interested there's a copy of the ELF spec at: ftp://ftp.intel.com/pub/tis/elf11g.zip (at least, I think elf11g.zip is file we have here). An earlier version of this also appears in the the SVR4 Programmer's Guide: ANSI C and Programming Support Tools. ELF has its own hooks for dynamic linking, but I'm not really sure how they work. I'd be interested in hearing about anyone else's experiences with ELF. I really only been using it for a week so it's probably a little pemature for me to be calling it th best thing since one-pass linking. None-the-less, it appears to be an extremely well thought-out format and was reasonably trivial to implement. Cheers, Christopher. From vandys@glare.cisco.com Mon Dec 19 19:28:54 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id TAA06416; Mon, 19 Dec 1994 19:28:52 -0800 Received: from wiliki.eng.hawaii.edu (wiliki.eng.hawaii.edu [128.171.60.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA14293 for ; Mon, 19 Dec 1994 19:54:51 -0800 Message-Id: <199412200354.TAA14293@hubbub.cisco.com> Received: by wiliki.eng.hawaii.edu (1.37.109.11/16.2) id AA026815580; Mon, 19 Dec 1994 17:53:00 -1000 From: Timothy Newsham Subject: Re: boot server executables vs. execable executables To: chrisf@sour.sw.oz.au (Christopher Fraser) Date: Mon, 19 Dec 1994 17:53:00 -1000 (HST) Cc: brtmac@ksu.ksu.edu, vsta@cisco.com In-Reply-To: <199412200224.AA07007@sour.sw.oz.au> from "Christopher Fraser" at Dec 20, 94 01:24:36 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2426 > > Along these lines it would seem that there should be some sort of > > naming convention to differentiate a server that is linked against > > crt0srv.o and one linked against crt0.o. That way it is obvious where > > something got loaded, and you don't try to put the wrong thing in > > boot.lst and create an unbootable system. > > > [ sensible naming ideas omitted ] > > It's probably better to try and remove the need for a separate > crt0srv.o and crt0.o. Having said that I'm sure if I can think of > a good way of passing arguments to the boot tasks. (Hmmm, if we > were using ELF we could maybe have the boot loader attach a note > section or segment to the executable ... not really sure). The way information is passed to a child with the exec library calls is hard (if not impossible) to do with the boot process. It maps a shared memory area and copies a bunch of data there. It also needs to pass more than just the argv/argc. There probably is a way that boot programs can be compatible with non-boot programs though. If the arguments to boot programs were stored seperately from the boot images themselves the system initialization could push them on the stack of each boot process. It could then push a magic number on the stack of the process. Regular (non-boot programs) run through exec library calls could have a different magic number pushed on the new processes stack. The _start code could then detect which method was used and read argv/argc from stack or from the shared memory region. It might even be possible to pass the boot args as an address to the memory where the args are stored which is more similar to the way normal processes get their args. In that case the start code would be nearly identical except less information would be grabbed from the memory region, and it wouldnt be munmapped when _start finished. I'm not sure its worth the effort though. > As an aside, how does the waiting for boot servers to initialise > themselves currently work? I remember someone mentioning this on the > list a little while ago but can't remember the outcome ... Does it > mean boot servers have to coded differently to ordinary servers? > I can't find an instances of this in the server code I've looked > at so far ... In my boot servers that want to do i/o to stdio I have special startup code to keep trying to open cons and kbd once a second for about 10 seconds. > Christopher. From vandys@glare.cisco.com Mon Dec 19 22:15:49 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA06445; Mon, 19 Dec 1994 22:15:48 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id WAA18570 for ; Mon, 19 Dec 1994 22:41:44 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Tue, 20 Dec 1994 17:41:42 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA02003; Tue, 20 Dec 94 17:47:11 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA10364; Tue, 20 Dec 1994 17:43:46 +1100 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199412200643.AA10364@sour.sw.oz.au> Subject: lcc 3.1 ported to vsta To: vsta@cisco.com (VSTa list) Date: Tue, 20 Dec 1994 17:43:45 +1100 (EST) Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE; Tue, 20 Dec 1994 00:31:57 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id DAA21897; Tue, 20 Dec 1994 03:33:29 -0500 Date: Tue, 20 Dec 1994 03:33:29 -0500 From: Gavin Nicol Message-Id: <199412200833.DAA21897@ebt-inc.ebt.com> To: jeremy@sour.sw.oz.au Cc: vsta@cisco.com In-Reply-To: <199412200643.AA10364@sour.sw.oz.au> (jeremy@sour.sw.oz.au) Subject: Re: lcc 3.1 ported to vsta Banzaii! I had "lcc" on the list of "things to do", and I think I even mentioned it to Andy. Good to have it! From vandys@glare.cisco.com Tue Dec 20 00:36:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id AAA06465; Tue, 20 Dec 1994 00:36:05 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA23174 for ; Tue, 20 Dec 1994 01:02:02 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa19272; 20 Dec 94 9:01 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rK0PG-00039TC; Tue, 20 Dec 94 08:58 GMT Message-Id: From: Dave Hudson Subject: Re: boot server executables vs. execable executables To: Christopher Fraser Date: Tue, 20 Dec 1994 08:58:54 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1478 Hi, Christopher Fraser wrote: > > Sure ... you need basic device drivers and file systems etc to get > the system up an running. As far as I can tell the main disadvantages > with loading images as boot tasks are they are not demand paged > (i.e. always resident in core), can't share images and can't have BBS > segments (not really sure why). Other than that they're standard images > as far as VSTa is concerned. Err, running size on my statically linked boot servers I have BSS segments. Essentially there's almost no difference between the servers but boot servers must be statically linked. I'm sure it would be reasonably easy to make it possible to share images (it just doesn't happen yet) - this would be very desirable for things like the dos and wd servers. The servers aren't swappable just to ensure that we don't lose the core facilities on which the kernel swapper code relies. > As an aside, how does the waiting for boot servers to initialise > themselves currently work? I remember someone mentioning this on the > list a little while ago but can't remember the outcome ... Does it > mean boot servers have to coded differently to ordinary servers? > I can't find an instances of this in the server code I've looked > at so far ... No, they are essentially the same as any other server, it's just that things like the dos server are coded to attempt connection retries (up to say 10 seconds) to other servers on which they rely. Regards, Dave From vandys@glare.cisco.com Tue Dec 20 05:21:08 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id FAA06531; Tue, 20 Dec 1994 05:20:58 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id FAA08031 for ; Tue, 20 Dec 1994 05:31:46 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA12571; Tue, 20 Dec 1994 14:27:06 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA28919; Tue, 20 Dec 1994 14:27:00 +0100 Date: Tue, 20 Dec 1994 14:27:00 +0100 Message-Id: <9412201327.AA28919@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Cry for HELP From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Hi all, Whats wrong with my code? Since a couple of day's I try to pass a message along to another server. This should be done as much uninterpreted as possible. (What I'm really on is a layered filesystem, but this dosn't matter yet.) But I'm jumping around between all sorts of unrecoverable kernel faults. I understand, that I can't pass a message completly uninterpreted because of the M_READ bit. So I tried to pass a message as follows. This has been applied to FS_STAT messages only (by now). /* return 0 on success otherwise a error string */ static char* passrmsg(struct msg*m, struct file*f) { int n; struct msg om; om = *m; /* make a rough copy */ om.m_op = m->m_op | M_READ; /* regenerate the M_READ */ /* copy all the buffer, not sure wether it is needed or not */ for(n=0; nm_nseg; ++n) { void *b; /* bufmalloc is a garbage collecting malloc. After the reply to "m", all buffers are free'd. It has proven to be stable . For tests one may forget about the "m" parameter use malloc instead and generate some memory leaks of no interest */ b = bufmalloc(m,m->m_seg[n].s_buflen); if( b == NULL ) return ENOMEM; bcopy(m->m_seg[n].s_buf,b,m->m_seg[n].s_buflen); om.m_seg[n].s_buf=b; } n = msg_send(f->port,&om); /* send it to the layer below */ if( n < 0 ) { return strerror(); } else { return 0; } } The fancy result of this is, that it works for the first time and break the kernel on the second invocation. To make things simple I started this server (which handles only M_DUP, M_CONNECT, M_DISCONNECT in a stable way and FS_STAT mainly by the code above). Then I mounted it on /test. Next I did: stat /test. This gave me the expected result. Next step again: stat /test. Now I got a assertion failed line 170 file ../mach/trap.c. This is the point where I can only raise my hands. BTW: I ran into a couple of problems with syslog. When I pass a FS_STAT message in the way above and I do a syslog just after the msg_send the result of the msg_send gets overwriten. There is a second problem, when I do a syslog between the msg_reply and msg_receive the next msg_send will hand. But this apears to be too complex to be answered. First I must work out the error condition exactly. Thanks for any help. /Joerg From vandys@glare.cisco.com Tue Dec 20 15:04:31 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA06580; Tue, 20 Dec 1994 15:04:29 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA29139; Tue, 20 Dec 1994 15:30:31 -0800 Message-Id: <199412202330.PAA29139@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: chrisf@sour.sw.oz.au (Christopher Fraser) Cc: brtmac@ksu.ksu.edu, vsta@cisco.com Subject: Re: boot server executables vs. execable executables In-Reply-To: Your message of "Tue, 20 Dec 1994 13:24:36 +1100." <199412200224.AA07007@sour.sw.oz.au> Date: Tue, 20 Dec 1994 15:30:29 -0800 From: Andrew Valencia [chrisf@sour.sw.oz.au (Christopher Fraser) writes:] >As an aside, how does the waiting for boot servers to initialise >themselves currently work? I remember someone mentioning this on the >list a little while ago but can't remember the outcome ... Does it >mean boot servers have to coded differently to ordinary servers? >I can't find an instances of this in the server code I've looked >at so far ... Some folks have listed various ways it's handled. In addition, a lot of the tedium is hidden by namer_lookup(), who does a sleep/retry loop within that function. Andy From vandys@glare.cisco.com Tue Dec 20 15:17:46 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA06583; Tue, 20 Dec 1994 15:17:44 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA29771; Tue, 20 Dec 1994 15:43:47 -0800 Message-Id: <199412202343.PAA29771@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: chrisf@sour.sw.oz.au (Christopher Fraser) Cc: vsta@cisco.com Subject: Re: ELF In-Reply-To: Your message of "Tue, 20 Dec 1994 13:32:09 +1100." <199412200232.AA07042@sour.sw.oz.au> Date: Tue, 20 Dec 1994 15:43:47 -0800 From: Andrew Valencia [chrisf@sour.sw.oz.au (Christopher Fraser) writes:] >How do people feel about adpoting ELF as the "standard" executable >format in VSTa? ELF is file executable and linking format used in >SVR4. It's highly portable, very cool and entirely in the spirit >of the festive silly season. Bah, humbug. a.out is nice, simple, and limited. It keeps languages people from doing horrible things. Well, it tries. Seriously, there are lots of things which would have to be rewritten, for a return on investment of 0. This includes boot loader, boot arguments, some of the bootup BSS/data sizing, boot process searching, adb, dbsym, as well as the exec support in the C library. >Seriously though, adopting ELF seems like a Good Thing. If nothing >else it would most of the executable format handling code be machine >independent, but there are lots of other good reasons (I'd started >running into a.out limitations in my MIPS port, like no support >for multiple "small" and "big" data segments etc, and adding ELF >was much easier and more elegant than ECOFF). Don't know what "small" and "big" data segments are. I know that R3000/R4000 ports to a.out have been done on various unices, so they can't have posed insuperable problems. >Reading over the binutils-2.5.1 documentation makes me think that >it's quite stable on intel and sparc platforms (the Linux people >seem to be using it quite a lot). I haven't had any problems on >the MIPSen yet. I'm not sure about 68k. Yes, but you'll also find that the 2.X gas is moving into the same size as the 1.X GNU C compiler itself. This "lcc" thing looks promising, IMHO. I want the lean/mean language tools option. >libc support would also be pretty easy. The machine dependent bit >should be limited to some header checks (architecture, endianess >etc). The only manditory change would be extending struct mapfile >to allow an arbitrary number of mappings. Adding it to lib C to support it for user programs would be an amusing exercise. Frankly, at that point libbfd is probably a better approach since it handles all the formats. Good byte, lean/mean. >where if m_filesz < m_memsz the rest of the mapping is ZFOD, which >is how ELF represents such things. I would be tempted to keep the >prsent ZFOD-flag style interface and have the libc code work out >which bits of the mapping are ZFOD and which are demand paged and >do seperate mapseg entries for them. I agree on your ZFOD perspective. As for the servers and such, I think converting executable formats would cost time better spent in other areas. Networking, remote services, and so forth. Need to hear more about this R3000 "big/small data" thing, though. I hope this isn't another one of those MIPS "in the name of performance" atrocities. Next thing you know we'll be looking at page coloring to cover their direct-mapped cache. Hmmm, perhaps I'd better add a disclaimer here that these are only my own personal opinions! :-) Andy From vandys@glare.cisco.com Tue Dec 20 22:36:39 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA06617; Tue, 20 Dec 1994 22:36:38 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id XAA21953 for ; Tue, 20 Dec 1994 23:02:41 -0800 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); Wed, 21 Dec 1994 18:02:40 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA21751; Wed, 21 Dec 94 18:02:01 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA24361; Wed, 21 Dec 1994 18:04:26 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199412210704.AA24361@sour.sw.oz.au> Subject: Re: boot server executables vs. execable executables To: dave@humbug.demon.co.uk (Dave Hudson) Date: Wed, 21 Dec 1994 18:04:26 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: from "Dave Hudson" at Dec 20, 94 08:58:54 am X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 346 But I thought Dave Hudson said: > > Err, running size on my statically linked boot servers I have BSS segments. Umm, yeah, Dave's right -- the boot loader allocates space for BSS and the kernel merges it in with the data segment view. I'd managed to convince myself otherwise while writing my ELF loader. Christopher. [embarrassed and sorry] From vandys@glare.cisco.com Tue Dec 20 23:50:37 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id XAA06625; Tue, 20 Dec 1994 23:50:35 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA26638 for ; Wed, 21 Dec 1994 00:16:37 -0800 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); Wed, 21 Dec 1994 19:16:11 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA23439; Wed, 21 Dec 94 19:07:33 EST (4.1/Unixware) (from chrisf@sour.sw.oz.au for vandys@cisco.com) Received: by sour.sw.oz.au id AA24581; Wed, 21 Dec 1994 19:09:59 +1100 (5.65c/1.34) (from chrisf@sour.sw.oz.au for vsta@cisco.com) From: chrisf@sour.sw.oz.au (Christopher Fraser) Message-Id: <199412210809.AA24581@sour.sw.oz.au> Subject: Re: ELF To: vandys@cisco.com (Andrew Valencia) Date: Wed, 21 Dec 1994 19:09:58 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: <199412202343.PAA29771@glare.cisco.com> from "Andrew Valencia" at Dec 20, 94 03:43:47 pm X-Deleted-Return-Receipt-To: chrisf@suite.sw.oz.au X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2331 But I thought Andrew Valencia said: > > [chrisf@sour.sw.oz.au (Christopher Fraser) writes:] > > >How do people feel about adpoting ELF as the "standard" executable > >format in VSTa? ELF is file executable and linking format used in > >SVR4. It's highly portable, very cool and entirely in the spirit > >of the festive silly season. > > Bah, humbug. a.out is nice, simple, and limited. It keeps languages people > from doing horrible things. Well, it tries. > > Seriously, there are lots of things which would have to be rewritten, for a > return on investment of 0. This includes boot loader, boot arguments, some > of the bootup BSS/data sizing, boot process searching, adb, dbsym, as well > as the exec support in the C library. Oh sure, ELF doesn't really buy much in the short term and sticking with a.out has its advantages (it currently works, why fix it etc). I'm primarily interested in ELF because of its aesthetic qualities (small, elegant, extensible, etc) although its flexibility and portability could be beneficial in the longer term. It should be noted the ease of implementing an ELF loader and my laziness are purely coincidental :-) > Don't know what "small" and "big" data segments are. I know that > R3000/R4000 ports to a.out have been done on various unices, so they can't > have posed insuperable problems. They're "one of those MIPS in the name of performance atrocities" that the MIPS tool-chains use -- clustering of small data items together so small offsets can be used to access them. Merging them together is no particular problem, I think they even appear as merged together data segment if you look at the a.out header bit of the MIPS ECOFF header. There is information which lost like read only / sharable data etc, but again it's no great drama. [ ... ] > Adding it to lib C to support it for user programs would be an amusing > exercise. Frankly, at that point libbfd is probably a better approach since > it handles all the formats. Good byte, lean/mean. Not necessarily. It's only a little more complicated than an a.out loader and would be extremely portable. I guess my comments should been seem from the perspective of wanting to see an much code as possible made portable across the VSTa platforms (vs keeping the shared code as simple as possible). Cheers, Christopher. From vandys@glare.cisco.com Wed Dec 21 09:35:21 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id JAA06694; Wed, 21 Dec 1994 09:35:20 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA11216; Wed, 21 Dec 1994 10:01:26 -0800 Message-Id: <199412211801.KAA11216@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Cc: vsta@cisco.com (VSTa list) Subject: Re: lcc 3.1 ported to vsta In-Reply-To: Your message of "Tue, 20 Dec 1994 17:43:45 +1100." <199412200643.AA10364@sour.sw.oz.au> Date: Wed, 21 Dec 1994 10:01:24 -0800 From: Andrew Valencia [jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) writes:] >I've done rough port of lcc 3.1 to VSTa. This looks really nice. It even seems to know how to do register allocation and block unrolling! I've checked a fix for the "inline" assumption and it'll be in 1.3.3. I'm going to play with it some more myself and see if it should become the primary VSTa C compiler. Regards, Andy From vandys@glare.cisco.com Wed Dec 21 11:47:50 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA06704; Wed, 21 Dec 1994 11:47:49 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA02011 for ; Wed, 21 Dec 1994 12:13:56 -0800 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id HAA28547; Tue, 20 Dec 1994 07:34:24 -0800 Message-Id: <199412201534.HAA28547@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Tue, 20 Dec 1994 07:34:24 PST In-Reply-To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)' <199412200643.AA10364@sour.sw.oz.au> lcc 3.1 ported to vsta Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge), vsta@cisco.com (VSTa list) Subject: Re: lcc 3.1 ported to vsta From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Subject: lcc 3.1 ported to vsta > Is anyone interested in playing with it? I'll put it up in > ftp://genesis.isdn.uiuc.edu/pub/VSTa/incoming (or is there somewhere There is also a copy now on our VSTa mirror site, ftp.cygnus.com:pub/embedded/vsta. I agree, GCC is kinda monolithic, and hard to hack sometimes. - rob - From vandys@glare.cisco.com Wed Dec 21 11:47:53 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA06707; Wed, 21 Dec 1994 11:47:52 -0800 Received: from cygnus.com (cygnus.com [140.174.1.1]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA02013 for ; Wed, 21 Dec 1994 12:13:59 -0800 Received: (from rob@localhost) by cygnus.com (8.6.9/8.6.9) id HAA28421; Tue, 20 Dec 1994 07:31:45 -0800 Message-Id: <199412201531.HAA28421@cygnus.com> From: rob@cygnus.com (Rob Savoye) Date: Tue, 20 Dec 1994 07:31:44 PST In-Reply-To: chrisf@sour.sw.oz.au (Christopher Fraser)' <199412200232.AA07042@sour.sw.oz.au> ELF Reply-To: rob@cygnus.com Phone-Number: (303) 258-0506 MST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: chrisf@sour.sw.oz.au (Christopher Fraser), vsta@cisco.com Subject: Re: ELF From: chrisf@sour.sw.oz.au (Christopher Fraser) Subject: ELF > How do people feel about adpoting ELF as the "standard" executable > format in VSTa? ELF is file executable and linking format used in > > ELF has its own hooks for dynamic linking, but I'm not really sure > how they work. I've suggested this before.... We use ELF heavily on several platforms. Under Solaris we recently added dynamic linking support for ELF as well, and we use ELF for mips, pa, i386, sparc. It's becoming popular with high-end ICE's as well. A.out has too many limitations on sections, that's why DJGPP moved to COFF, but ELF would be even better. - rob - From vandys@glare.cisco.com Wed Dec 21 16:30:17 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA06763; Wed, 21 Dec 1994 16:30:16 -0800 Received: from ebt-inc.ebt.com (ebt-inc.ebt.com [192.111.115.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id QAA10134; Wed, 21 Dec 1994 16:56:21 -0800 Received: (from gtn@localhost) by ebt-inc.ebt.com (8.6.9/8.6.9) id TAA17079; Wed, 21 Dec 1994 19:57:55 -0500 Date: Wed, 21 Dec 1994 19:57:55 -0500 From: Gavin Nicol Message-Id: <199412220057.TAA17079@ebt-inc.ebt.com> To: vandys@cisco.com Cc: jeremy@sour.sw.oz.au, vsta@cisco.com In-Reply-To: <199412211801.KAA11216@glare.cisco.com> (message from Andrew Valencia on Wed, 21 Dec 1994 10:01:24 -0800) Subject: Re: lcc 3.1 ported to vsta >This looks really nice. It even seems to know how to do register allocation >and block unrolling! I'm not sure about the x86 port, but I know that for the sparc, the code generated was comparable to gcc with minimal optimization. The small footprint, and the fact that it was designed for speed in mind, bias me toward making it the main compiler. From vandys@glare.cisco.com Wed Dec 21 16:25:46 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA06759; Wed, 21 Dec 1994 16:25:45 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id QAA09921 for ; Wed, 21 Dec 1994 16:51:53 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 22 Dec 1994 11:51:50 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA15275; Thu, 22 Dec 94 11:51:40 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vandys@cisco.com) Received: by sour.sw.oz.au id AA28528; Thu, 22 Dec 1994 11:54:07 +1100 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199412220054.AA28528@sour.sw.oz.au> Subject: Re: lcc 3.1 ported to vsta To: vandys@cisco.com (Andrew Valencia) Date: Thu, 22 Dec 1994 11:54:07 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: <199412211801.KAA11216@glare.cisco.com> from "Andrew Valencia" at Dec 21, 94 10:01:24 am Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE [jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) writes:] > >I've done rough port of lcc 3.1 to VSTa. > > This looks really nice. It even seems to know how to do register allocation > and block unrolling! It will automatically registerise variables which look busy (but will always try to honour the register keyword first). What do you mean by "block unrolling"? > I've checked a fix for the "inline" assumption and it'll be in 1.3.3. I'm > going to play with it some more myself and see if it should become the > primary VSTa C compiler. I've recompiled a few things, and found that things which behaved oddly with gcc work properly when compiled with lcc. For example, I compiled the rs232 server with gcc and it completely failed to work: ./rs232 wouldn't print a usage message. I recompiled with lcc and it worked well. gcc couldn't really be that broken, but I didn't even need to have to look to work out the problem. lcc is a strict ansi compiler with very few extentions, so there's a few things that gcc will allow that lcc will barf on: - inline - assignment between pointers and integers - assigning from a const to a non-const pointer - pointer arithmatic with void pointers - no doubt some other things which I haven't encountered All except for inline can be fixed in a portable way (no ifdefs). I feel the fatal error from mixing const and non-const pointers is excessive, but it can be got around with some casting. Just after I posted the announcement to the vsta list, I got an announcement on the lcc list of lcc 3.2. It fixes a real bug for the i386 target (a /= b/c generates bad code), so I'll look at upgrading the VSTa port. J From vandys@glare.cisco.com Wed Dec 21 21:24:41 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id VAA06782; Wed, 21 Dec 1994 21:24:37 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id VAA20096 for ; Wed, 21 Dec 1994 21:50:45 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa14334; 22 Dec 94 5:50 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rKg4r-0003lYC; Thu, 22 Dec 94 05:28 GMT Message-Id: From: Dave Hudson Subject: Re: lcc 3.1 ported to vsta To: Jeremy Fitzhardinge Date: Thu, 22 Dec 1994 05:28:37 +0000 (GMT) Cc: VSTa mailing list In-Reply-To: <199412220054.AA28528@sour.sw.oz.au> from "Jeremy Fitzhardinge" at Dec 22, 94 11:54:07 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: 970 Hi, Jeremy Fitzhardinge wrote: > > I've recompiled a few things, and found that things which behaved > oddly with gcc work properly when compiled with lcc. For example, > I compiled the rs232 server with gcc and it completely failed to > work: ./rs232 wouldn't print a usage message. I recompiled with > lcc and it worked well. gcc couldn't really be that broken, but > I didn't even need to have to look to work out the problem. The bug here isn't with gcc it's in ld - there's a problem with binaries that have text blocks between 1 and 32 bytes larger than a page. Andy and I clobbered this a while back so it'll be in 1.3.3 BTW, as I seem to be a little in the dark about lcc is it just a C compiler or will it do C++ as well? Is there an FAQ somewhere around? If we're going to adopt it as our main compiler, perhaps now would be a good time to look at a newer native port of gcc that can be available as an extra if it's wanted :-) Regards, Dave From vandys@glare.cisco.com Wed Dec 21 22:15:52 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id WAA06790; Wed, 21 Dec 1994 22:15:50 -0800 Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id WAA21451 for ; Wed, 21 Dec 1994 22:41:59 -0800 Received: from sour.sw.oz.au by staff.cs.su.OZ.AU (mail from jeremy for vsta@cisco.com) with MHSnet (insertion MHSnet site: swallow.sw.oz.au); Thu, 22 Dec 1994 17:41:58 +1100 Received: from sour.sw.oz.au by swallow.sw.oz.au with SMTP id AA24305; Thu, 22 Dec 94 17:41:16 EST (4.1/Unixware) (from jeremy@sour.sw.oz.au for vsta@cisco.com) Received: by sour.sw.oz.au id AA01746; Thu, 22 Dec 1994 17:43:43 +1100 (5.65c/1.34) (from jeremy@sour.sw.oz.au for vsta@cisco.com) From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge) Message-Id: <199412220643.AA01746@sour.sw.oz.au> Subject: Re: lcc 3.1 ported to vsta To: dave@humbug.demon.co.uk (Dave Hudson) Date: Thu, 22 Dec 1994 17:43:42 +1100 (EST) Cc: vsta@cisco.com In-Reply-To: from "Dave Hudson" at Dec 22, 94 05:28:37 am Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb l[EC}c=;uc%x'}uh3E91p&oE The bug here isn't with gcc it's in ld - there's a problem with binaries > that have text blocks between 1 and 32 bytes larger than a page. Andy and I > clobbered this a while back so it'll be in 1.3.3 Ah, yes, I remember that. I thought that was fixed pre-1.3.2? Maybe not. I suppose it was unfair to jab at gcc just because it generated slightly smaller code to hit the bug :-) > BTW, as I seem to be a little in the dark about lcc is it just a C compiler > or will it do C++ as well? Is there an FAQ somewhere around? If we're > going to adopt it as our main compiler, perhaps now would be a good time to > look at a newer native port of gcc that can be available as an extra if it's > wanted :-) You can look at http://www.cs.Princeton.EDU:80/software/lcc/ or ftp://ftp.cs.princeton/pub/lcc. This is the abstract from the paper talking about it (http://www.cs.princeton.edu:80/TR/PRINCETONCS:TR-303-91?abstract=): Lcc is a new retargetable compiler for ANSI C. Versions for the VAX, Motorola 68020, SPARC, and MIPS are in production use at Princeton University and at AT&T Bell Laboratories. With a few exceptions, little about lcc is unusual -- it integrates several well-engineered, existing techniques -- but it is smaller and faster than most other C compilers, and it generates code of comparable quality. Lcc's target-independent front end performs a few simple, but effective, optimizations that contribute to good code; examples include simulating register declarations and partitioning switch statement cases into dense tables. It also implements target-independent function tracing and expression-level profiling. J From vandys@glare.cisco.com Fri Dec 23 18:32:46 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA07083; Fri, 23 Dec 1994 18:32:44 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id SAA26606 for ; Fri, 23 Dec 1994 18:59:06 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id TAA26818 for vsta@cisco.com; Fri, 23 Dec 1994 19:59:03 -0700 Date: Fri, 23 Dec 1994 19:59:03 -0700 From: Gary Shea Message-Id: <199412240259.TAA26818@xmission.xmission.com> To: vsta@cisco.com Subject: REPOST: vstafs question I received no replies to my question on how to make a vstafs filesystem. I have DOS 6.2, and have made a logical partition in the secondary partition of my C: disk. I mounted a dos filesystem on it no problem (although I couldn't see how to actually _use_ it...), as wd:wd0_p1 (that's from memory). Attempting to do a mkfs_vfs on that same device just gives me the message "no entry". From vandys@glare.cisco.com Sat Dec 24 20:56:20 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id UAA07214; Sat, 24 Dec 1994 20:56:18 -0800 Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id VAA26446; Sat, 24 Dec 1994 21:22:46 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by xmission.xmission.com (8.6.9/8.6.9) with SMTP id WAA11005; Sat, 24 Dec 1994 22:22:45 -0700 Message-Id: <199412250522.WAA11005@xmission.xmission.com> X-Authentication-Warning: xmission.xmission.com: Host xmission.xmission.com didn't use HELO protocol To: vsta@cisco.com Cc: vandys@cisco.com Subject: vsta fs FAQ entry Date: Sat, 24 Dec 1994 22:22:43 -0700 From: Gary Shea I've been trying to get a working vfs fs. I spent much of today reading fs & wd code; on a whim I mounted wd in the root fs and lo and behold, it had entries in it! And they were different than the one in the sample inittab line... that simplified things lots. Here's a possible FAQ entry for the next poor fool who tries this: Q: How do I make a vstafs filesystem? A: For DOS 6.2, there are two possible partitions on a disk: the main one, and a secondary one. It is possible to create logical partitions in the secondary partition to subdivide that partition even further. To see what partitions you have available, add a line of the form: disk/wd /wd to the /vsta/etc/fstab file and reboot, or use the command $ mount disk/wd /wd to accomplish the same effect temporarily. Look in the /wd directory for the names of available partitions. Supposing you wish to use the partition wd0_dos1, use the command $ stat /wd/wd0_dos1 to find the exact size of the partition. Divide that number by 512 to get the number of sectors, then the command $ mkfs_vfs /wd/wd0_dos1 number_of_sectors will initialize a vstafs file system on that partition. Now you can run the filesystem server: $ /vsta/boot/vstafs /wd/wd0_dos1 fs/vfs Finally, you must map the namer pathname fs/vfs into the root heirarchy with a mount command: $ mount fs/vfs /vfs If you want the filesystem mounted at boot time, find the vstafs command in the /vsta/etc/inittab and correct it to your device name (note the different syntax when portnames are used); uncomment or introduce the necessary mount line in the /vsta/etc/fstab file. Gary From vandys@glare.cisco.com Tue Dec 27 17:16:53 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00221; Tue, 27 Dec 1994 17:16:48 -0800 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA11294 for ; Tue, 27 Dec 1994 17:47:00 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA04348; Tue, 27 Dec 1994 19:07:04 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA22573; Tue, 27 Dec 1994 18:51:02 +0100 Date: Tue, 27 Dec 1994 18:51:02 +0100 Message-Id: <9412271751.AA22573@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: support library for servers From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Hi, I started a support library for servers. At the moment it makes it a lot easier to write servers. But it still far from being complete. For testing I converted tmpfs to use this library and wrote a server which only passes the received messages to another server (acts simillar to a simple mount, but it leaves all permission checks out). I don't expect it to be usefull as it is, but is a good template for real servers so I'll append it as a example) I enclose the README and the server.h which holds all the current documentation. If someone is interested mail me for the code or try to get it from http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/v132/srv/lib/ (But I am behind the slowest line you may think of.) ---- The README ---- This is a support library for servers. It implements a abstraction of what a server is. This is independent of the underlying OS. (Actually only implemented for VSTa, should be easy for QNX and L3 -- this is what I know, and almost anything else.) See "server.h" for Details of the provided abstraction. At top of this interface it becomes much more easy to write a server. Beside the system independence you get, some of the edge cases disappear (because you don't see the message interface). Furthermore the name handling becomes uniformed. libc/statsup.c is copied and adapted. (Unfortunately it does some msg_ actions itself.) Side note: This code could benefit from a proposed kernel service msg_send_and_receive. As long as kernel entry is that expensive as on the intel it would save a lot of execution time. TODO: * Think about a VSTa independend "struct msg". * Add support for multithreaded servers. (currently a matter of the server specific code). * Fix the hackery around the unknown value of the M_READ bit. * improve the service selection on a received message. (As long as VSTa needs about 10-20 the time of similar systems for a context switch it doesn't matter.) Contact: joerg.wittenberger@inf.tu-dresden.de ----- server.h ------ #ifndef __SERVER_H #define __SERVER_H /* * server.h * * REASONING * This implements a abstraction of what a server is. * A server build at top of this interface is not VSTa specific in * respect to the interface it serves. (It may be VSTa specific in the * sense of being a client of another server.) * * A server consists of a set of services (functions of the type * service) which are bound to a message. These functions all act * on a received message and a data structure associated with the * client. They return a NULL pointer on success or a pointer to a * error string on failure. On success the message is modified to be * used as the reply message. * * One may think about the mentioned data structure as a object served * and the functions as methods on this object (and the message as * arguments to this method). * * Every server has to provide a function init_server (and no main!) * which does all startup initialization of it's internal data * structures and even so establish connections to servers it uses. * It does NOT establish any namer_registration. (The name to use for * registration is the first argument to the server, but this is a * VSTa specific issue.) * * There should are a special function to generate and initialize a * new data structure (ignoring the provided pointer) which is usually * bound to the M_CONNECT (under VSTa) and acts as the constructor in * the sense of object orientation, a function to copy a object from * another one (usually bound to the M_DUP) which may be seen as the * constructor with a object to copy and also a function which deletes * such a object (usually on M_DISCONNECT), the destructor. A function * which successfully created a new object (file in the sense of VSTa) * should bind it to a client. All functions bound to successive * messages from this client will act on this object. A binding gets * revoked by a call to the bindclient with the same id but a NULL * pointer as object. * */ /* * import "struct msg" */ #include typedef char* (service)(struct msg *, void *); extern service* server_bindfn(int, service*); /* Bind function */ extern service* server_bindfn_dft(service*); /* (Re)bind the default */ extern void* server_bindclient(int, void*); /* bind client */ #ifdef WITH_PASSMSG /* * If WITH_PASSMSG is defined, the server has support for * server_passmsg to pass a message on to another server. This is * conditional compiled because of the questionable design of VSTa, * which hides the M_READ bit while it doesn't provide a abstraction * of it. So we have to do some hackery to find the correct meaning. */ extern char* server_passmsg(port_t, struct msg *); #endif extern int init_server(int argc, char **argv); /* supplied by client */ /* * server_mmalloc * * some servers like to malloc buffers which have to be free'd after * the msg_reply (in VSTa, generally spoken which live as long as the * message is processed), but no service will ever see this point. * Such buffers are malloc'ed by server_mmalloc with the corresponding * struct msg. They are automatic free'd. * * This is a bit dangerous because of possible missuse: Never use this * function with a other "struct msg" except the one in the arg (and * only in servers which are at top of this interface). Also don't use * it for buffers which are kept anywhere else (like the per client * data)! * * It is usefull for all dynamic buffers in a service. Never * free it yourself! Even never try to send back static buffers use * buffers you got from this function! * */ extern void* server_mmalloc(struct msg *,long); #ifdef DEBUG /* * Set this to 1 if you like to get some syslog-info from the * server.c. But only if this is also compiled with DEBUG. */ extern int server_dbg_flag; #endif #endif /* __SERVER_H */ /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Tue Dec 27 18:30:02 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00235; Tue, 27 Dec 1994 18:30:01 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id TAA27958; Tue, 27 Dec 1994 19:00:30 -0800 Message-Id: <199412280300.TAA27958@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com Subject: Re: support library for servers In-Reply-To: Your message of "Tue, 27 Dec 1994 18:51:02 +0100." <9412271751.AA22573@ibch01.inf.tu-dresden.de> Date: Tue, 27 Dec 1994 19:00:29 -0800 From: Andrew Valencia [joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:] >http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/v132/srv/lib/ >(But I am behind the slowest line you may think of.) Apparently so! If anybody else got through, can you mail it to me and I'll put it up on FTP? >* improve the service selection on a received message. (As long as >VSTa needs about 10-20 the time of similar systems for a context >switch it doesn't matter.) I'm not sure what this means. If you're saying that VSTa context switches are 10-20 times slower than other similar systems, what is it we're doing that they don't? Or did you mean something else? Andy From vandys@glare.cisco.com Wed Dec 28 01:45:49 1994 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id BAA00276; Wed, 28 Dec 1994 01:45:46 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id CAA03600 for ; Wed, 28 Dec 1994 02:16:10 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA03930; Tue, 27 Dec 1994 18:39:36 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA22595; Tue, 27 Dec 1994 18:20:24 +0100 Date: Tue, 27 Dec 1994 18:20:24 +0100 Message-Id: <9412271720.AA22595@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: cons2 non-us keymap From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Hi, in-head translation of keyboards are a nightmare. I modified the cons2 server slightly to support non-us keyboards. I don't think the monolith way of file stored mappings is needed for c/s systems. It isn't hard to recompile a small server. For that reason I only modified the makefile to support a LANG variable, changed the state machine in isr.c to recognize the extra shift key (alt graphics), and moved the language dependend mapping tables out of isr.c into LANG-dependend files (mapus.c and mapde.c kinda file stored mappings). I'm not sure whether this approach disturbs US people or not because I don't know about the behavior of the right alt key on these keyboards. Maybe we need a generalized isr.c. I don't have experiences in creating diff files suitable for patch. But I don't feel like learning it yet. The following patch did it's job on the makefile and isr.c for me but not for map??.c so I'll append them. Have fun. ---------- patch for makefile and isr.c------------ diff -c cons2.old/isr.c cons2/isr.c *** cons2.old/isr.c Tue Dec 27 17:19:58 1994 --- cons2/isr.c Tue Dec 27 17:42:03 1994 *************** *** 8,38 **** static int shift = 0, /* Count # shift keys down */ alt = 0, /* ...alt keys */ ctl = 0, /* ...ctl keys */ capstoggle = 0, /* For toggling effect of CAPS */ numtoggle = 0, /* ...NUM lock */ isE0 = 0; /* Prefix for extended keys (FN1, etc.) */ ! /* Map scan codes to ASCII, one table for normal, one for shifted */ ! static char normal[] = { ! 0,033,'1','2','3','4','5','6','7','8','9','0','-','=','\b','\t', ! 'q','w','e','r','t','y','u','i','o','p','[',']',015,0x80, ! 'a','s','d','f','g','h','j','k','l',';',047,0140,0x80, ! 0134,'z','x','c','v','b','n','m',',','.','/',0x80, ! '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, ! 0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, ! 0x80,0x80,0x80,'0',0177 ! }; ! static char shifted[] = { ! 0,033,'!','@','#','$','%','^','&','*','(',')','_','+','\b','\t', ! 'Q','W','E','R','T','Y','U','I','O','P','{','}',015,0x80, ! 'A','S','D','F','G','H','J','K','L',':',042,'~',0x80, ! '|','Z','X','C','V','B','N','M','<','>','?',0x80, ! '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, ! 0x80,0x80,0x80,0x80,'7','8','9',0x80,'4','5','6',0x80, ! '1','2','3','0',177 ! }; /* * key_event() * Process a key event --- 8,22 ---- static int shift = 0, /* Count # shift keys down */ alt = 0, /* ...alt keys */ + altgr = 0, /* ...altgr key */ ctl = 0, /* ...ctl keys */ capstoggle = 0, /* For toggling effect of CAPS */ numtoggle = 0, /* ...NUM lock */ isE0 = 0; /* Prefix for extended keys (FN1, etc.) */ ! extern char normal[],shifted[],altgrmap[]; + static char* keymap=normal; /* * key_event() * Process a key event *************** *** 48,62 **** /* * Look up in right table for current state */ if (capstoggle) { - ch = normal[c]; if ((ch >= 'a') && (ch <= 'z')) { ! ch = shift ? normal[c] : shifted[c]; ! } else { ! ch = shift ? shifted[c] : normal[c]; } - } else { - ch = shift ? shifted[c] : normal[c]; } /* --- 32,44 ---- /* * Look up in right table for current state */ + ch = keymap[c]; if (capstoggle) { if ((ch >= 'a') && (ch <= 'z')) { ! ch -= 'a'-'A'; ! } else if ((ch >= 'A') && (ch <= 'Z')) { ! ch += 'a'-'A'; } } /* *************** *** 227,236 **** --- 209,220 ---- case 0x36: /* Shift key down */ case 0x2a: shift = 1; + keymap = shifted; break; case 0xb6: /* Shift key up */ case 0xaa: shift = 0; + keymap = normal; break; case 0xe0: /* Prefix for "left side" */ isE0 = 1; *************** *** 242,251 **** ctl = 0; break; case 0x38: /* Alt key down */ ! alt = 1; break; case 0xb8: /* Alt key up */ ! alt = 0; break; case 0x3a: /* Ignore cap/num down; they might repeat */ case 0x45: --- 226,245 ---- ctl = 0; break; case 0x38: /* Alt key down */ ! if(!isE0) { ! alt = 1; ! } else { ! altgr = 1; ! keymap = altgrmap; ! } break; case 0xb8: /* Alt key up */ ! if(!isE0) { ! alt = 0; ! } else { ! altgr = 0; ! keymap = shift ? shifted : normal; ! } break; case 0x3a: /* Ignore cap/num down; they might repeat */ case 0x45: diff -c cons2.old/makefile cons2/makefile *** cons2.old/makefile Tue Dec 27 17:19:14 1994 --- cons2/makefile Tue Dec 27 17:39:47 1994 *************** *** 1,9 **** CC= gcc LD= ld INCS= -I../../../include CFLAGS= -Wall -DDEBUG $(INCS) -O LDFLAGS= -L../../../libc ! OBJS= main.o cons.o stat.o isr.o rw.o LIBS= -lusr -lc_s .c.o: --- 1,12 ---- + # Edit LANG as you need. currently supported: us de + LANG=us + # CC= gcc LD= ld INCS= -I../../../include CFLAGS= -Wall -DDEBUG $(INCS) -O LDFLAGS= -L../../../libc ! OBJS= main.o cons.o stat.o isr.o rw.o map$(LANG).o LIBS= -lusr -lc_s .c.o: Only in cons2: mapde.c Only in cons2: mapus.c ------------ mapus.c -------------- /* Map scan codes to ASCII, one table for normal, one for shifted */ char normal[] = { 0,033,'1','2','3','4','5','6','7','8','9','0','-','=','\b','\t', 'q','w','e','r','t','y','u','i','o','p','[',']',015,0x80, 'a','s','d','f','g','h','j','k','l',';',047,0140,0x80, 0134,'z','x','c','v','b','n','m',',','.','/',0x80, '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,'0',0177 }; char shifted[] = { 0,033,'!','@','#','$','%','^','&','*','(',')','_','+','\b','\t', 'Q','W','E','R','T','Y','U','I','O','P','{','}',015,0x80, 'A','S','D','F','G','H','J','K','L',':',042,'~',0x80, '|','Z','X','C','V','B','N','M','<','>','?',0x80, '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,'7','8','9',0x80,'4','5','6',0x80, '1','2','3','0',177 }; char altgrmap[] = { 0,033,'!','@','#','$','%','^','&','*','(',')','_','+','\b','\t', 'Q','W','E','R','T','Y','U','I','O','P','{','}',015,0x80, 'A','S','D','F','G','H','J','K','L',':',042,'~',0x80, '|','Z','X','C','V','B','N','M','<','>','?',0x80, '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,'7','8','9',0x80,'4','5','6',0x80, '1','2','3','0',177 }; ---------------- mapde.c ---------------- /* Map scan codes to ASCII, one table for normal, one for shifted */ char normal[] = { 0, 033,'1','2','3','4','5','6','7','8','9','0','\337',047,'\b','\t', 'q','w','e','r','t','z','u','i','o','p','\374','+',015,0x80, 'a','s','d','f','g','h','j','k','l','\366','\344','^',0x80, '#','y','x','c','v','b','n','m',',','.','-',0x80, '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,0x80,0x80,0x80,'-',0x80,0x80,0x80,'+', 0x80,0x80,0x80,'0',0177,0x80,0x80,'<' }; char shifted[] = { 0, 033, '!', '"', '\247', '$', '%', '&','/','(',')','=', '?',0140,'\b','\t', 'Q','W','E','R','T','Z','U','I','O','P','\334','*',015,0x80, 'A','S','D','F','G','H','J','K','L','\326','\304','>',047, 047,'Y','X','C','V','B','N','M',';',':','_','>', '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,'7','8','9',0x80,'4','5','6',0x80, '1','2','3','0',0177,0x80,0x80,'>' }; char altgrmap[] = { 0,033,'!','\262','\263','$','%','^','{','[',']','}','\134',0x80,'\b','\t', '@','W','E','R','T','Y','U','I','O','P','{','~',015,0x80, 'A','S','D','F','G','H','J','K','L',':',042,'~',0x80, '|','Z','X','C','V','B','N','M','<','>','?',0x80, '*',0x80,' ',0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80, 0x80,0x80,0x80,0x80,'7','8','9',0x80,'4','5','6',0x80, '1','2','3','0',177,0x80,0x80,'|' }; ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Wed Dec 28 03:20:06 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id DAA00321; Wed, 28 Dec 1994 03:20:05 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id DAA00782 for ; Wed, 28 Dec 1994 03:50:35 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa06014; 28 Dec 94 11:50 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rMwtt-0002iLC; Wed, 28 Dec 94 11:50 GMT Message-Id: From: Dave Hudson Subject: Re: cons2 non-us keymap To: joerg.wittenberger@inf.tu-dresden.de Date: Wed, 28 Dec 1994 11:50:41 +0000 (GMT) Cc: VSTa mailing list X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 737 Hi, Joerg Wittenberger wrote: > > in-head translation of keyboards are a nightmare. > I modified the cons2 server slightly to support non-us keyboards. It's strange that after all this time two of us have done similar patches (I did UK mappings last week :-)) I'll add your diffs into the work I'm doing to support the cons3 code that David Jeske did a couple of weeks ago. I seem to remember some French mappings being posted a few months back so I'll add them as well. I'm rewriting a lot of the keyboard code at the moment to allow it to handle things like the LEDs, and ultimately downloadable keymaps - it's just a question of how to handle things like a Japanese keyboard that make it more interesting! Regards, Dave From vandys@glare.cisco.com Wed Dec 28 09:29:05 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id GAA00339; Wed, 28 Dec 1994 06:21:12 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id GAA05438 for ; Wed, 28 Dec 1994 06:51:40 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA18622; Wed, 28 Dec 1994 15:09:24 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA31957; Wed, 28 Dec 1994 15:09:23 +0100 Date: Wed, 28 Dec 1994 15:09:23 +0100 Message-Id: <9412281409.AA31957@ibch01.inf.tu-dresden.de> To: vsta@cisco.com In-Reply-To: "joerg.wittenberger@inf.tu-dresden.de"'s message of Tue, 27 Dec 1994 18:51:02 +0100 Subject: support library for servers (continued) From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw To quote myself: >For testing I converted tmpfs to use this library and wrote a server >which only passes the received messages to another server (acts >simillar to a simple mount, but it leaves all permission checks out). >I don't expect it to be usefull as it is, but is a good template for >real servers so I'll append it as a example) But I forgot to append the "passfs.[hc]" here it is: #ifndef _PASSFS_H #define _PASSFS_H /* * passfs.h * Data structures in pass filesystem * * PASSFS is a filesystem, which simply passes all requests down to a * underlying file system. This is not really a useful server, * because the same effect can be achived be a simple mount (in * VSTa). But it is a generic stub which is simple to extend to a * layered file system */ #include #include #include /* * Structure of an open file in the filesystem */ /* * Our per-open-file data structure */ struct file { port_t port; }; #endif /* _PASSFS_H */ ------------------------------------- /* * passfs.c * Main handling loop and startup */ #include #include "../lib/server.h" #include "passfs.h" #include #include #include #include #include port_t theBasePort; /* where we are mounted on */ static char* passmsg(struct msg *m, struct file *f) { return server_passmsg(f->port,m); } /* * new_client() * Create new per-connect structure */ static char * new_client(struct msg *m, struct file * dummy) { struct file *f; /* * Get data structure */ if ((f = malloc(sizeof(struct file))) == 0) { return strerror(); } /* * Fill in fields */ f->port = clone(theBasePort); if( f->port < 0 ) { free(f); return strerror(); } /* * Hash under the sender's handle */ server_bindclient(m->m_sender, f); /* * Return acceptance */ return 0; } /* * dup_client() * Duplicate current file access onto new session * * This is more of a Plan9 clone operation. The intent is * to not share a struct file, so that when you walk it down * a level or seek it, you don't affect the thing you cloned * off from. * * This is a kernel-generated message; the m_sender is the * current user; m_arg specifies a handle which will be used * if we complete the operation with success. */ static char * dup_client(struct msg *m, struct file *fold) { struct file *f; /* * Get data structure */ if ((f = malloc(sizeof(struct file))) == 0) { return strerror(); } /* * Fill in fields */ *f = *fold; f->port = clone(fold->port); if( f->port < 0 ) { free(f); return strerror(); } /* * Hash under the sender's handle */ server_bindclient( m->m_arg, f); /* * Return acceptance */ m->m_arg = m->m_arg1 = m->m_buflen = m->m_nseg = 0; return 0; } /* * dead_client() * Someone has gone away. Free their info. */ static char * dead_client(struct msg *m, struct file *f) { struct file*old; msg_disconnect(f->port); old=server_bindclient( m->m_sender,0); /* old and f should be the same */ if(old) free(old); return 0; } /* * usage() * Tell how to use the thing */ static void usage(void) { printf("Usage is: passfs \n"); exit(1); } /* * init_fssrv() * Startup of a passfs filesystem * * A PASSFS instance expects to start with a command line: * $ passfs */ init_server(int argc, char *argv[]) { #define BIND(a,b) server_bindfn(a,(service*)b) int fd; #ifdef DEBUG extern int server_dbg_flag; server_dbg_flag=0; #endif /* * Initialize syslog */ openlog("passfs", LOG_PID, LOG_DAEMON); /* * Check arguments */ if (argc != 1) { usage(); return 1; } fd = open(argv[0], O_RDWR); if( fd < 0 ) { syslog(LOG_ERR, "unable to open '%s'", argv[2]); exit(1); } theBasePort = __fd_port(fd); /* * Allocate data structures we'll need */ BIND(M_CONNECT,new_client); BIND(M_DISCONNECT,dead_client); BIND(M_DUP,dup_client); BIND(FS_OPEN,passmsg); BIND(FS_ABSREAD,passmsg); BIND(FS_READ,passmsg); BIND(FS_ABSWRITE,passmsg); BIND(FS_WRITE,passmsg); BIND(FS_SEEK,passmsg); BIND(FS_REMOVE,passmsg); BIND(FS_STAT,passmsg); BIND(FS_WSTAT,passmsg); /* * Start serving requests for the filesystem */ syslog(LOG_INFO, "filesystem established"); return 0; } From vandys@glare.cisco.com Wed Dec 28 10:53:16 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id KAA00088; Wed, 28 Dec 1994 10:53:15 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id LAA14837; Wed, 28 Dec 1994 11:17:31 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA18154; Wed, 28 Dec 1994 14:40:32 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA46906; Wed, 28 Dec 1994 14:40:31 +0100 Date: Wed, 28 Dec 1994 14:40:31 +0100 Message-Id: <9412281340.AA46906@ibch01.inf.tu-dresden.de> To: vandys@cisco.com Cc: vsta@cisco.com In-Reply-To: <199412280300.TAA27958@glare.cisco.com> (message from Andrew Valencia on Tue, 27 Dec 1994 19:00:29 -0800) Subject: Re: support library for servers From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw >>>>> "AV" == Andrew Valencia writes: >> * improve the service selection on a received message. (As long as >> VSTa needs about 10-20 the time of similar systems for a context >> switch it doesn't matter.) AV> I'm not sure what this means. If you're saying that VSTa context AV> switches are 10-20 times slower than other similar systems, what AV> is it we're doing that they don't? Or did you mean something AV> else? I don't mean anything else. But as everything - it depends. I remember some messages about context switch time of VSTa. They claim (as I remember) all not to be exact mensured and are anywhere between 60 us and 200 us on 486/?? and pentium. We are playing here with a (non free) system named L3. It needs 10 us to pass a zero length message from one process to another on a 486/50. Up to 8 byte message are about the same speed. From memory: QNX takes about 5 that time. It depends a bit of what we call similar. Both systems are micro kernel. Both have a couple of servers and (almost) no driver related software in the kernel. (And both make exceptions for speed -- I remember, that rs232 support lead to kernel modifications, or am I wrong? L3 has rs232 support partially in the kernel. But in any case it is not essential.) Where is the difference? (From probably least to more significant.) 1) L3 doesn't impose the "everything is a file" policy by the kernel. (Even if I consider this a good thing at the server level I don't like the kernel burned manner.) This may or may not save overhead - I don't know. 2) L3 has not that many protection policy in the kernel. Only the msg sending process is identified by the kernel. (A VSTa-ish policy would need a extra server. Such at least 2 extra message passings at a "M_CONNECT".) 3) L3 is only implemented for [3|4|5]86. Currently with no multiprocessor support in mind. I think this "wastes" some time. 4) L3 has only synchronous unidirectional message passing. A message is in principle passed to another process in a rendezvous and there is not reply. If you need on you have to receive a message from that process. Because this would cost a lot of kernel entries and one of them is about 100 clock cycles, they have some kernel call introduced to send and receive a reply, send a reply and receive the next message and such. These kernel calls don't do anything special, they only spare some ring3->ring0 switches for often used sequences. There servers know about the optimization and prefer these calls. 5) L3 is optimized for message passing. Up to 8 byte are transfered in the processor registers. Everything else is copied into kernel memory and temporary mapped to the receiver. Also the rest of L3 is widely optimized for speed. Jochen Liedke, who wrote the most of it, didn't fear to write large parts in assembly. And he spend some time in things like page-adjusting of thread control block, spare cache and TLB misses and so on. (But at top of the kernel there is nothing intel specific except what the compiler generates ;-) So far. As you can see it is not much. Mostly optimization (which will ever break the portability (of the kernel not the servers)) and the old remove policy from the kernel. /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Sat Dec 31 14:13:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id OAA00539; Sat, 31 Dec 1994 14:13:11 -0800 Received: from nightfly.rme.com (nightfly.rme.com [198.30.235.9]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id OAA26319 for ; Sat, 31 Dec 1994 14:44:03 -0800 Received: (from matt@localhost) by nightfly.rme.com (8.6.9/8.6.9) id RAA02115 for vsta@cisco.com; Sat, 31 Dec 1994 17:43:55 -0500 From: Matt Emerson Message-Id: <199412312243.RAA02115@nightfly.rme.com> Subject: anyone attending usenix? To: vsta@cisco.com Date: Sat, 31 Dec 1994 17:43:53 -0500 (EST) Content-Type: text Content-Length: 149 are any vsta people going to be attending the usenix conference in new orleans? maybe some of us could meet and chat? -matt -- http://www.rme.com/ From vandys@glare.cisco.com Sat Dec 31 15:38:08 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id PAA00562; Sat, 31 Dec 1994 15:38:07 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA07761 for ; Sat, 31 Dec 1994 16:09:08 -0800 Message-Id: <199501010009.QAA07761@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: vsta@amri.cisco.com Subject: Some bugs Date: Sat, 31 Dec 1994 16:09:07 -0800 From: Andrew Valencia I've stamped on a couple of kernel bugs today. First one: adb main?i :r Will panic with a "still refs" complaint in deref_pset() or thereabouts. Fix is in the treatment of copy-on-write pset's during a fork(). Second, if you adb a file, run it, debug it, and so forth, you will lose a couple bits of memory after everything exit()'s. The proc p_prefs hash list was not being cleaned up on server exit(). If either is giving some of you grief send me a note and I'll assemble a patch. 1.3.3 is imminent, in any case. Andy From vandys@glare.cisco.com Sat Dec 31 16:47:26 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00572; Sat, 31 Dec 1994 16:47:25 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA28943 for ; Sat, 31 Dec 1994 17:18:24 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rOEvy-000a0HC; Sat, 31 Dec 94 15:18 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: amiga problems To: vsta@cisco.com Date: Sat, 31 Dec 1994 15:18:10 -1000 (HST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1773 Hi, Its been a while.. been busy with other things. I did get the fork() and exec() problems I was having fixed in the amiga kernel. I have a rather strange bug that I have been banging my head against and cant seem to figure out. For some reason certain pages are getting referenced (by ref_slot()) way more than they should be. The strange thing is that if I throw a printf in ref_slot() the problem goes away. If I do something like: if(pp->pp_ref > 10) printf("..."); then the page reference will keep growing until it hits 10, then it will stop going out of control. I think that the printf() is taking enough time to allow for another process to get scheduled and maybe the next flushing of the mmu's cache sets things right. I did throw in a flush_atc() to test this out and it seems to at least partially fix the problem. I still get a few pages that are referenced too many times. This causes the system to be unuseable at the next exit() since an assertion fails "still ref". I've tried all sorts of things to track it down. It seems that the only pages that this happens to are those that are mapped by kern_mem when handling message passing. The amiga port differs from the i386 in the handling of kernel page tables. There is a seperate root pointer for the kernel and the user page tables. I'm wondering if maybe problems are arising because views that are attached by hat_addtrans() are not visible by the kernel. Its been a few weeks since I've played with this so I'm probably leaving out some important details. I should also point out that my sources are quite old now. I should merge the current sources in with mine. If you have any ideas on what might be wrong please let me know. Tim N. From vandys@glare.cisco.com Sat Dec 31 16:59:46 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id QAA00576; Sat, 31 Dec 1994 16:59:45 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA08395; Sat, 31 Dec 1994 17:30:45 -0800 Message-Id: <199501010130.RAA08395@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com Subject: Re: amiga problems In-Reply-To: Your message of "Sat, 31 Dec 1994 15:18:10 -1000." Date: Sat, 31 Dec 1994 17:30:45 -0800 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] >... For some reason certain pages are >getting referenced (by ref_slot()) way more than they should be. >The strange thing is that if I throw a printf in ref_slot() the >problem goes away. Usually, problems like this point back to stale TLB, as I see you're guessing, too. >If I do something like: > if(pp->pp_ref > 10) > printf("..."); >then the page reference will keep growing until it hits 10, then >it will stop going out of control. I think that the printf() >is taking enough time to allow for another process to get >scheduled and maybe the next flushing of the mmu's cache sets >things right. Only if you're multiprocessor... the kernel printf is done in a tight loop. More likely it ages something out of the TLB which is hosing you. >I did throw in a flush_atc() to test this out >and it seems to at least partially fix the problem. I still >get a few pages that are referenced too many times. This >causes the system to be unuseable at the next exit() since >an assertion fails "still ref". You need to go back and look at your treatment of the TLB when you set up a kernel translation for the MALLOC()'ed (or malloc(), I think you're using an old version of the code) memory. In particular, you need to look at what you do when deleting an old kernel translation. For the i386, it's a flush_tlb() (but only if DEBUG, hmmm, that doesn't seem right) in kern_deletetrans(). >I've tried all sorts of things to track it down. It seems that >the only pages that this happens to are those that are mapped >by kern_mem when handling message passing. The amiga port differs >from the i386 in the handling of kernel page tables. There >is a seperate root pointer for the kernel and the user page tables. >I'm wondering if maybe problems are arising because views that >are attached by hat_addtrans() are not visible by the kernel. Oh, yes, that is definitely an important difference. However, this sounds like you're having problems with the translation you *think* you're adding as a part of getting dynamic kernel memory. An amusing check is to read/modify/write the location, flush the TLB, then assert that the value you just wrote is, in fact, what is currently in that location. Use volatile pointers (to make sure it doesn't all end up in a register). >Its been a few weeks since I've played with this so I'm >probably leaving out some important details. I should also >point out that my sources are quite old now. I should merge >the current sources in with mine. If you have any ideas on what >might be wrong please let me know. Feels like TLB to me (ATC, in Moto-ese, I think). Oh, for other curious types, TLB == "Translation Lookaside Buffer", and ATC == "Address Translation Cache". I first heard the term TLB from IBM types, I don't know where ATC comes from, although it seems like a clearer name. Andy From vandys@glare.cisco.com Sat Dec 31 17:11:12 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00579; Sat, 31 Dec 1994 17:11:11 -0800 Received: from hookomo (hookomo.aloha.net [204.94.112.33]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id RAA29335; Sat, 31 Dec 1994 17:42:10 -0800 Received: by hookomo (Smail3.1.28.1 #11) id m0rOFIz-000a0HC; Sat, 31 Dec 94 15:41 WET Message-Id: From: newsham@aloha.net (Timothy Newsham) Subject: Re: amiga problems To: vandys@cisco.com (Andrew Valencia) Date: Sat, 31 Dec 1994 15:41:57 -1000 (HST) Cc: newsham@aloha.net, vsta@cisco.com In-Reply-To: <199501010130.RAA08395@glare.cisco.com> from "Andrew Valencia" at Dec 31, 94 05:30:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2052 > Only if you're multiprocessor... the kernel printf is done in a tight loop. > More likely it ages something out of the TLB which is hosing you. I should point out that I have a bitmap display. Printf calls the cons putchar routine. The putchar routine stamps characters onto the bitmap, and if scrolling has to be done the whole bitmap gets moved up. I put a cli()/sti() around the putch to make sure that characters get written out without being disturbed. > You need to go back and look at your treatment of the TLB when you set up a > kernel translation for the MALLOC()'ed (or malloc(), I think you're using an > old version of the code) memory. In particular, you need to look at what > you do when deleting an old kernel translation. For the i386, it's a > flush_tlb() (but only if DEBUG, hmmm, that doesn't seem right) in > kern_deletetrans(). I based my hat.c on the i386 port. I have the following: *pt &= ~PT_PG; if (pv->p_vas == curthread->t_proc->p_vas) { flush_atc(); } So the cache should be flushed if it needs to be. > Oh, yes, that is definitely an important difference. However, this sounds > like you're having problems with the translation you *think* you're adding > as a part of getting dynamic kernel memory. Is there anything I need to do to map memory into the kernel when hat adds a translation? I figured that when the kernel was going to add translations it would use kern_addtrans() in vm.c. I noticed that the hat code supports the use of PROT_KERN (kernel access only) but the mach-independant code never uses it so I havent supported it. > An amusing check is to read/modify/write the location, flush the TLB, then > assert that the value you just wrote is, in fact, what is currently in that > location. Use volatile pointers (to make sure it doesn't all end up in a > register). I'll try this. > Feels like TLB to me (ATC, in Moto-ese, I think). fun. (I was hoping you'd say "Oh, its this simple thing over here that you overlooked" :) > Andy From vandys@glare.cisco.com Sat Dec 31 17:16:00 1994 Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]) by amri.cisco.com (8.3/8.3) with ESMTP id RAA00582; Sat, 31 Dec 1994 17:15:59 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id RAA08506; Sat, 31 Dec 1994 17:47:00 -0800 Message-Id: <199501010147.RAA08506@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: newsham@aloha.net (Timothy Newsham) Cc: vsta@cisco.com Subject: Re: amiga problems In-Reply-To: Your message of "Sat, 31 Dec 1994 15:41:57 -1000." Date: Sat, 31 Dec 1994 17:46:59 -0800 From: Andrew Valencia [newsham@aloha.net (Timothy Newsham) writes:] >> Only if you're multiprocessor... the kernel printf is done in a tight loop. >> More likely it ages something out of the TLB which is hosing you. >I should point out that I have a bitmap display. Printf calls the >cons putchar routine. The putchar routine stamps characters onto >the bitmap, and if scrolling has to be done the whole bitmap gets >moved up. I put a cli()/sti() around the putch to make sure that >characters get written out without being disturbed. Huh? We're talking kernel printf() here, right? How does he call a routine in a server? >I based my hat.c on the i386 port. I have the following: > *pt &= ~PT_PG; > if (pv->p_vas == curthread->t_proc->p_vas) { > flush_atc(); > } No, kern_deletetrans(), in mach/vm.c. >Is there anything I need to do to map memory into the kernel when >hat adds a translation? I figured that when the kernel was going >to add translations it would use kern_addtrans() in vm.c. I noticed >that the hat code supports the use of PROT_KERN (kernel access only) >but the mach-independant code never uses it so I havent supported it. Kernel mappings are handled distinct from user mappings. I'd be curious to hear about your copyin/copyout implementation. >I'll try this. >> Feels like TLB to me (ATC, in Moto-ese, I think). >fun. (I was hoping you'd say "Oh, its this simple thing over here that >you overlooked" :) Oh, it's that simple thing over here called "TLB". :-) Andy From vandys@glare.cisco.com Tue Jan 3 11:59:54 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id LAA01023; Tue, 3 Jan 1995 11:59:53 -0800 Received: from xmission.xmission.com (shea@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id MAA20123 for ; Tue, 3 Jan 1995 12:31:10 -0800 Received: (from shea@localhost) by xmission.xmission.com (8.6.9/8.6.9) id NAA18292 for vsta@cisco.com; Tue, 3 Jan 1995 13:31:06 -0700 Date: Tue, 3 Jan 1995 13:31:06 -0700 From: Gary Shea Message-Id: <199501032031.NAA18292@xmission.xmission.com> To: vsta@cisco.com Subject: vsta user-level semaphores I released code for user-level semaphores a month or so ago, but in the process of actually using it I've found some serious flaws in design, which are being rectified now (I hope). The published interface probably won't change much (a semaphore is a semaphore is as semaphore), but the internals will be completely different (and, unfortunately, a lot more complicated). If you try to use what I've already distributed, be warned -- it's not at all safe, especially around malloc. If anyone _is_ planning/needing to use semaphore stuff, perhaps you will get in touch with me for alpha testing? Also, if anyone has components of a thread-safe wrapper library for libc, I would like to know. Thanks Gary p.s. The system calls supporting semaphores seem to be ok, at least for now. From vandys@glare.cisco.com Tue Jan 3 13:01: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 NAA01037; Tue, 3 Jan 1995 13:01:09 -0800 Received: from pong.pencom.com (pong.pencom.com [198.3.200.2]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA23359 for ; Tue, 3 Jan 1995 13:32:17 -0800 Received: by pong.pencom.com (AIX 3.2/UCB 5.64/4.03) id AA25109; Tue, 3 Jan 1995 15:28:58 -0600 From: venki@pencom.com (Venki S Iyer) Message-Id: <9501032128.AA25109@pong.pencom.com> Subject: Re: vsta user-level semaphores To: shea@xmission.com (Gary Shea) Date: Tue, 3 Jan 1995 15:28:57 -0600 (CST) Cc: vsta@cisco.com In-Reply-To: <199501032031.NAA18292@xmission.xmission.com> from "Gary Shea" at Jan 3, 95 01:31:06 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: 470 Gary Shea writes: > > If anyone _is_ planning/needing to use semaphore stuff, perhaps > you will get in touch with me for alpha testing? Also, if > anyone has components of a thread-safe wrapper library for > libc, I would like to know. > Gary, check out the pthreads distribution on rtfm.mit.edu. It has a set of libc wrappers. > Thanks > > Gary > -venki -- Venki M. S. Iyer venki@pencom.com Me? I'm just a warm body. From vandys@glare.cisco.com Wed Jan 4 09:15: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 JAA01168; Wed, 4 Jan 1995 09:15:18 -0800 Received: from pscgate.progress.com (pscgate.progress.com [192.77.186.1]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA10793 for ; Wed, 4 Jan 1995 09:46:32 -0800 Received: from progress.progress.COM by pscgate.progress.com (4.1/pscgate1.1) id AA08231; Wed, 4 Jan 95 12:46:24 EST Received: from proserv.bedford.progress.COM by progress.progress.COM (4.1/psc2.1) id AA05329; Wed, 4 Jan 95 12:46:21 EST Received: from devserv.bedford.progress.COM (devserv-e4) by proserv.bedford.progress.COM (4.1/psc2.2) id AA00490; Wed, 4 Jan 95 12:46:21 EST Received: from crozet.bedford.progress.COM by devserv.bedford.progress.COM (4.1/psc2.1) id AA20646; Wed, 4 Jan 95 12:46:20 EST Received: by crozet.bedford.progress.COM (4.1/psc2.3) id AA06937; Wed, 4 Jan 95 12:46:19 EST Date: Wed, 4 Jan 95 12:46:19 EST From: koogler@bedford.progress.com (David Koogler) Message-Id: <9501041246.ZM6935@crozet> X-Mailer: Z-Mail (3.2.0 06sep94) To: vsta@cisco.com Subject: VSTa 1.32 Booting Problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have been trying to get VSTa 1.32 to boot on my i486 system, but the system dies with a kernel assertion failure: Assertion failed line 81 file ../kern/msgcon.c deref_port: messages Using 'proc' it looks like the namer is dying (it is the only process marked as ONPROC). I am trying to boot "right out of the box" without making any changes to /etc/fstab or /etc/inittab. The only change I have made was in boot.lst where I explicitly defined the hard disk parameters "wd:977:5:17". The box is a fairly run-of-the-mill PC clone, and I have turned off its shadow RAM. I have been able to run Linux 1.0.9 on the box without any problems. Now what can I do? -- David Koogler (koogler@bedford.progress.com) From vandys@glare.cisco.com Sat Jan 7 13:12: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 NAA01862; Sat, 7 Jan 1995 13:12:10 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA28075 for ; Sat, 7 Jan 1995 13:43:45 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA14678; Sat, 7 Jan 1995 22:44:51 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA28759; Sat, 7 Jan 1995 22:44:45 +0100 Date: Sat, 7 Jan 1995 22:44:45 +0100 Message-Id: <9501072144.AA28759@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Is this a bug or not? From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: Technical University Dresden X-Attribution: jfw Hello, I don't know wether I suffer from a bug or ignorance. Here is a striped dow version of my code which still hit my problem. What do I expect it do do? It shold start a thread as some kind of privat server. But this thread is unable to do a msg_reply to the main thread. As you can easy figure all goes well until I send the message OPCODE. This gets received but the thread will hang in the msg_reply. Why? /* * main.c * Main handling loop and startup */ #include #include #include #include #include #include #include #define OPCODE 500 static port_t theRootport; /* Port we receive contacts through */ static port_name theWorkPort; static long theWorkThread; /* * new_client * try to add a new client as supplied */ static void new_client(struct msg *m) { msg_accept(m->m_sender); } /* * dup_client */ static void dup_client(struct msg *m) { m->m_arg = m->m_arg1 = m->m_buflen = m->m_nseg = 0; msg_reply(m->m_sender, m); } /* * dead_client() * Someone has gone away. Free their info. */ static void dead_client(struct msg *m) { } /* * serve() * Endless loop to receive and serve requests */ static void serve() { int x; struct msg msg; loop: /* * Receive a message, log an error and then keep going */ x = msg_receive(theRootport, &msg); if (x < 0) { syslog(LOG_ERR, "msg_receive"); goto loop; } /* * Categorize by basic message operation */ /* * Catch odd cases */ printf("\nreceived msg %d from %d",msg.m_op,msg.m_sender); switch(msg.m_op) { case M_CONNECT: /* New client accept instead of reply */ new_client(&msg); break; case M_DISCONNECT: /* Client done, don't reply*/ dead_client(&msg); break; case M_DUP: dup_client(&msg); break; case OPCODE: msg.m_arg=msg.m_arg1=msg.m_nseg=0; msg_reply(msg.m_sender,&msg); printf("replied"); break; default: /* regular functions */ msg_err(msg.m_sender, EINVAL ); break; } goto loop; } /* * work_init() * */ int work_init() { /* * Last check is that we can register with the given name. */ theRootport = msg_port((port_name)0, &theWorkPort); theWorkThread=tfork(serve); return 0; } /* * */ int work_op(port_t p) { struct msg m; m.m_op=OPCODE; m.m_arg=m.m_arg1=m.m_nseg=0; m.m_buf=0; return msg_send(p,&m); } port_t work_new() { return msg_connect(theWorkPort, ACC_WRITE ); } void work_die() { notify(0, theWorkThread, EKILL); } main() { struct time t; port_t c1; work_init(); c1=work_new(); printf("\ntry the work"); work_op(c1); printf("\ngot a reply"); sleep(20); work_die(); exit(0); } Thanx for any help /Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Sun Jan 8 12:57:09 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id MAA01961; Sun, 8 Jan 1995 12:57:06 -0800 Received: from irz301.inf.tu-dresden.de ([141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id NAA07076 for ; Sun, 8 Jan 1995 13:28:40 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA06512; Sun, 8 Jan 1995 22:29:41 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA44555; Sun, 8 Jan 1995 22:29:35 +0100 Date: Sun, 8 Jan 1995 22:29:35 +0100 Message-Id: <9501082129.AA44555@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: semaphores From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I needed some semaphores. Cause it was stated that the semaphore development is in a redesign I did a quick implementaion using a server. This is for sure not the best you can do, but at least it seems to work. Here is the uuencoded gziped tar in case anyone is interested: /Joerg begin 644 sema.tz M'XL(`%97$"\``^T::6_;.+9?JU_QZJ*M[#J.[20-D#0=9%)W)M@<1=)V!I@= M&+)$V]K(HD-*3KQ%_ON^QT.B'3?)S&X/+$2DM4B1C^\^2)WU]M\>]QY]U=9I MMU]M;L(C`-C!?`)=Y'%[`)(@8^(,\`YGPJSK$DVG")BS- M@BSF*?`A2#8)IF,NF&QYWF$&R!A:CNR9,0%7XS@#9FBPO4?F9N MQ)E,7V1VMIJET6ARW0:\8\3R(8,"^((A:!Y),LGN`6_B$NC-,+ M_#_(($B2I4WMRG$P8XAGGL:7.?-HAS28(*U3+F4\2/3V7$2(&%(9"J8IIDWJ M$*01!)H<6AGR-$.>>-0/"3`N&,R:P5PISG$`8I#C$8\RM:ATS6"XG440O9R&#"94;RX0)Q MB6`:".S*IN$#HCS'1R0C0J'.-4%,"L4?T]F?"#G+18I;I&R$DIEI?B,F6B/[4SOC MWTQP8J$7))+#,$!Q11;!!8Q:CQU>:XHEQJ3"0P%2AB%Q9%A+>^[V#]A MUAI_W3WN\?^PV>X:_[^QL?4*GSOM3G>[\O_?HCV-AVF$%MGOG_>.]_N_>D^Q M%Z>L'/">QFF8Y.B?7\NY7,_F4W3DXS=>,;.W__/IV0>H!0/T1+5R7*U_#UOM M]N+0)QSJ>%Z,/E-;KD\NK(]QH+Y;CL[<4<\\6W?EXY@[A#[%3,<7,QY'>ICL MJQSWGJ*;C(>PWBB(@\;Z]S&['Z81GY)XT`J_XA[WY7];6]O&_CWR?Y? M;6U4]O\M6F'<-1T):LOV3DF2('M?'![*I;$LNC4IX2/E*,(Q@7IU[[,'(#.18[R=R!%,=K%/OH0UUC\R&)D6QQ%0TQ2Q$3:T[]%PK_&_Y38,Y M)=:@7JHD6.4GV,.]$0FS63FX1YO"9[6M,U6I1A\=>^0[TE5($`3PB[F(M5T/ M,%6IG5\KEV.FZ:1(ICH0;!1CDHDAQ4`$8-=QYG=,]\;3_QSYN;R@?9NP?W#0 M_^WL\$,/ZK?X408-1Z@&6ICPE%F>XKJ5,>4.75@MG)L?+]@09E+,OJ/_[VQL M;;5M_=_>VMX@_[_=?57Y_V_1E.>%0@NP\_@XB%,L@-(HH8(HX7RJJQ;D4Y9/ ME9>^+T04P:2F-+`&O<[0G'>+U42ON[2<>A7$Z,2D M#1"J:K4=K!B9L!UT1U+#U"1@7I;PL#@D03EN-_TFYQAE29MCT.IJ1:=.04A%D\4T<#0NW]N&$B M(LW=+0"8N('OSCC/J+=+@-Y3C$19"A8R`D/'2PB13GL$D>9*1T4B"D(J0+FB MD@NAJ."X,,F#+_;DVANCCG5XL@O,/(+M;>:!6WB89@TV3NXS#E M*I2:,-%\3ET3C%54%*IS0X*ZA2TR:26V5^,X03HX8,:&+.GL.OT. M)6GT3$F<3IH`-'B$KFS\3=OAK!I96UOFY\*^FI4WP!*T4KU2(.@E@[')E0]/ M!)0YU6I*3DZ/>\=.N@0DV`D";4QV;9?D;"D`N,3'YZ4T]"!JJ#H\TR=Z22#I MQ`H=4&A.9.D04JBCLH%S]CED+($DOF`PQ\6HP01*B1O\QF4=+G$G>G!5#7=" M.G-&7LRL:!!*HE"L)768/40=_HK0K0Q7JB-HX5B!OGRYNZ@CM]0#L_J$I:N4 MY0XEN+$18("IL?9GZ"BQCXV&](&E&J?$&<6"&?6:&8B"+(!AR[OE,A;`Q6II M4[UIP%"SR4SC*-,]Y>/Z%'/RJ>^XLB8NLUP:4F&PX$/4HH@E+&,K%RTH-^DP M[54J\7W+204PZ`_IO.IM[^>/OVCS4K'?/SK]I7]X\NZT63/)C$,O/%,'ML^2 MZUI3T3U$>/HTR+-Z]_OOOZ-V!G0.'0PXZC'B]I-50L15(8=1$PN29>0(7DF% M@?4NB)-)526&8^E8"(\R5,LU!PJ\@GYH+%\SR M2@#V&B?.QFB$"07;(A54I]H(?\RG;)@3,0*10LSHS-Y"6#=/CEAZ9V?-FF+I MT.(=IS;GW"G%5%M=V:$@'*/`*K:OIQN3R!`<"A=S.W4Y<&5-(T!&Y-,I=B)K M/'2K15"%/8HERPZQI7I MXP7K!_<<>#3N.`=W)^WU2GZY+UU7%>734BJ+/"E?/2AT:^2U:UU&"EVKQ>BK M.=T(5:#O>-W'YU@Y<&4&$D;T$%P%\Q;`.[J\00N*A2HF;BN#"^GO)"WE08R1 M&?E;!W$W==,R-4%E@,)6F:#A:\$,M&A_.?=I@MC#N9B$/2'UT:_+A$6_ MKANJ"9Q^5S+FMK@&Z+TOR@Q.0W8DHG.=14FLY*?5>1(.QIM#&.7DP<:,CL\* M[Q]8YZ%O=S-]]A@1:$-U.$#`3.&B M;S=QFN6YO&45%LIG]\34+;CER!DI?*5'6^UX%%X]%:C.[)884J0,1AAI51BU M-\>!3I12?0XPXB;*45I4'K(:O'VG(&O"!1)88W`$CJE#?&W@VADJX*PO#C5N.'U[.BE;F M1#M:,L3D9[KR5PF1]]A`XU.THH7$R,$\'`/'"$OQ3Y8X8IH0CGV[W+))!%YL0MN"!6:.Z[!.19^UZ7.T]"9?U!;@+)$.-F+^D!<_II6?G7V] M/>Z]_^]NFON?[G9GLX,CG?;F9G7_\RW:'9U M)FY6O#;7_K);C&A'!LJ9_89%@O)4"`.M/$B*5^M.IGY3$-_]?L1W_POB.W^+ M>%R?8-:]=%6/S#`I@E.;Z0]C:5K"Z?/+3C/K*I)#PR'SM1<.=)<&#'VAWB7K M[&7(C@L?%4T/=(L!S5"-4U?S`"-7/)S[&#%P2^C]X_#H:'F\6XY[)<,NXB2Q ML4Y#W-`GPY:_/ZZOKUK5JE:UJE6M:E6K6M6J5K6J5:UJ5:M:U:I6M:I5K6I5 6JUK5JE:UJE6M:O^?[3\?@/CH`%```%6K ` end From vandys@glare.cisco.com Mon Jan 9 07:05:09 1995 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id HAA02178; Mon, 9 Jan 1995 07:05:07 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id HAA14195 for ; Mon, 9 Jan 1995 07:36:27 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA05771; Mon, 9 Jan 1995 16:37:21 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA39299; Mon, 9 Jan 1995 16:05:53 +0100 Date: Mon, 9 Jan 1995 16:05:53 +0100 Message-Id: <9501091505.AA39299@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: Semaphore server (correction) From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi, I guess I should have spend a night before I posted the server based sema code yesterday. There was a questionable design decision in, which turned out to be a bug not a feature. I happened to thing it would be useful to have a semaphore destroyed when the creating thread disconnects, but this is a really bad idea in multithreaded env's. So I removed it. Instead I added a sema_get which yield the current value. Also I added sema_[pv]n, which takes a positive integer as the second value and plays the role of n p/v's at once. sema_pn? will now allways return the old value of the sema. If it returns zero you failed to get the sema, maybe due to a signal. I'm not sure wether it would be better to add a loop around the msg_send in the semalib.c. As a side note: my weak english lead to a pun in the code. BTW: it shouldn't be too hard to mount the server anywhere (but don't open it at the moment :-() and write a small program which calls the sema functions on the port of a specified file. Then you have sema's ready in shell scripts. Sorry for the inconvenience. Here is the corrected code: begin 644 sema.tz M'XL(`!E-$2\``^T;_4_;R+*_XK]BFKZV3FI"$D*12-,31],>>@4JH+V3[ITB M8V\2/QRO6=L)N8K__5K_TN+79!=C:;G4[G`1]!PJ9N/.&")4W+VD\!I47#468S)F`^";P) MQ(+/`A_[TPE;'B#GT[`^9TGT.C70$CA+,C>$41"J<6G@-4&-F?`L].&,6:[O M,Q\2/DV#*4YA[^/`(#K'?]T4W#!!S"S(8@49\[2B`LK2%\G$&<"%X.A5(XB8$)PH4;\'L_^0,QI)B*< M(F)C7)F9DG<3$#3)/(\E3B`ON&)<*3\]"$`W=QQL#/)'\HRV`ZW39^;'6WWU;^_S':"QT`T.]/M2I0"-C;ZX\]S[+0<^Y(PTC$+/=& MEJ5[\D]-;JW]P][;J\,Z7P)7WRPS[PU^L%_@61*SH ML%X$D1=FF(J]2Q;)1KJ(,6>;O+=R2`GW!;9:K>6N;]C57N[Z-#C%SHYE$1:: MEO*4H;+VGF4%4:JCL$T_]5[1,S,]11=&8MD)21DPCF2G@QU+XY>Z+35.YSDV M]A0=F(J8N68\\%7G2#"64_`",ZM@!!N-7$C0V/@?=4[&N7H/.,<=]M]IM3>U M_7>[6^T6V?_;3K>R_\=HN7'75"2HK=H[U4."['VY>Y2L]*7^-:"0CZ6C\"8H M8Z?U!_3ANYRR=H46M=&P@/XVKMDQ8.U"?5'=^FX!)*G(O!2F MR1BF/7RG3Y?T,&U.ASSN*U]D.EPQ[D>EEW:?'J*$C?LMTWV6C=2+SOL1]3!! M`[<3Y]44K?WJFEM"?R-IT0-R:IWV"OCL7BR4*?_V4)3/;J5\=A/E)==Z)\WH MT\M4_S6"5_RRGIPJ?A4J9'4N2R]\0QU"=*0%([O4B;U0!QH)95"IR$.,1;Y= MTL5Z3\*A.[=SV'?0,N,!8EESVK5B.);`I0I6;UL(-@ZP^A5I36,$8)=!:K?U MZY6E_BNQ[O$HPLHYG]>!W;V]X:_'^Z<#6)6&"4HK*^B%/,*XI*!OB%:WKA]. M[P=)3H%$\-2NJ&I/T$R1]G3QO[W9V6KI^+^Y^;:S3?%_NXK_C]-DY,U+=0]? MU@[<((*)&_EA$(TAY#R66W,DIS2+992^*T7(DXD"<.(FDVLI0\#OSBQ&7I2& M]T\V%$._,CAG+(94N-ZYW*#F&#A":`SR-$!=,L3`-"H<"9#RR:O4Z:]:G MG57:9C;,R]A:YJ(!$GQ(+_92M%%X["3XDW$,1\68N@Y72\AR$2AT^O4>D M1FKJQ\.]W;U?!F"WW];7L/(ZYMEX$BX<>(%!,&!1FDA^-AI_2[LF&=)>FO;` MC4F;Z$#!]=)@1F<3Z!=H[K6&3BL(MI`>_[(-;?ZU2N2*;T=U@O?U;Y3?'>EW-J>#T7R`'* M:N@+Y1^"Q>'"UN,H#63">46O.F.2S`KY3B-!H7 MJ[*9XIPR944JY3-EK2JW!##9I6']?3^'S^52EEUO25+K?0.L^=9OA8P*2BA[*2X$S()\H<_9L>T2"2Q&TJ,;N72NBE M>;.T-/G"E->Q,+EZ[R8]P7HF9-%-6O.#5;U.MBRV[B;\1A)OGDC/HX+*&98L MRD6B[\5W;-0EET_U4T&#ZXF5SKKN\-W4A5'3NN:%EM#)HI8[\DL#1HI,#4;' M;'WI-H<4QK+8+GE'!X=)D:+JCJA@DV[(*+`S&04M60VWWU"M73JX=,\X&@#2]I/17J15$H>!&`O%5>((7\&%QO71#<), M,$<=BN(?1O`ZV)2Z874;\3/N+\!S MZ?`[/_:=LBD7.)*YY_5F,6CY;#VW:'6,C4%K+FWZ+.1SR&)]0H\.HD!@SOV# M=(+6&U+\SA-*>>R*^"<\9J.,F!%(%%)&A[P&PX9^*BW+X/C8J4F1C@S=060R MUYUBF6HW5]RX$"6CB-A\J,"U2:2(CDYO?5^>)L^-:;@HB"R.\<4WQD/7(.AL MG6S/]3P6DP?,SYL#?0A.5!KC;.JA)[AD`2:?Q*O,P[Z=G+K*RDI&9A7$+?N% MI9BF?8-,3_/(H'(V;5GP/,G-XJZ0<%7RC/UV3[U1>IJ_Z""@-G!*3J",4?O) M7"[ECV67Y&=Q(?UEWHM/]W3F1.2;-S<1A;[26?;,(V0I@9"EQ_5%+V.Z!^>WK$`K7_SU=2TX1FZ2:5W@S0.]*$LMPF9+HN MD)4W@1F9)]PR;AW@]^P*,A8TET?F\G0L2:).\9X(X.)N7#C MJG0A4C7UF&M?3\D!P"79CN15(K%+E8X#K_"+5DFP+\L[JRN>'6HE',:%*]>M M_%.)W#T,7F,NL&BD^T-G;H*2T(0#!A4A[VA9)HPD\*-$!&=MEES4:F)P8UJP MHQ:$9/M2U=,R)[#6-#8>._),LL@-$HR$WL0VGXT,9!PX&.X='1X.]DYWUJ@P M/"S%'A5<2A%%ZE,1'4N!(A>T#%&%5>@I/NR?Y+/@)'LZS9.9N\K0)>H<<]D; M$6K%T*W8OW[9,0,+_RW'_6C8[L]'QZ=FH')!2V,DF#K1R=%3X7<'8G624AHQ MN]>(3X/3TAA*RF\?A2KB9F%JX//H6E(F#*_[A]]V,:WMP74$LGS)=WV"2`)G` M.SK"$?3/^YJCZ=3K53I]67(>NY0H4?8K:QSE%#-*BN>,]M1H;RVGK.0IC`]1 M&U9J,VJCF[NV)[U:W.?QZE_>!0A:ZGWWD\4UP;T1O=7MOQ.OJ:5B0HG59A*XW;.DN_4S2YMY`32)T7]2*@ZSWB'HM`(<)K@7;O5>_,F*'+_ M0!V9TTYQN_X.G93T,JT\GL<"\8_LVK^BTY<^AA._YN!D^6=S;Z*3]RB'#-(I M_^H&JKKC*F>\\'?.=O\!\^[]B'L>'6"FL7'Y`8>A4IU1) MJO\'@L!"'HTA;3MI1[+L:0GI^WG8T5GIT/QY:I:TW4]1'. (click here) From vandys@glare.cisco.com Mon Jan 9 08:37:21 1995 Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by amri.cisco.com (8.3/8.3) with ESMTP id IAA02185; Mon, 9 Jan 1995 08:37:20 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by beasley.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id JAA02983 for ; Mon, 9 Jan 1995 09:08:44 -0800 Received: from ibch01.inf.tu-dresden.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA08001; Mon, 9 Jan 1995 17:58:12 +0100 Received: by ibch01.inf.tu-dresden.de (AIX 3.2/UCB 5.64/4.03.1) id AA42736; Mon, 9 Jan 1995 17:58:07 +0100 Date: Mon, 9 Jan 1995 17:58:07 +0100 Message-Id: <9501091658.AA42736@ibch01.inf.tu-dresden.de> To: vsta@cisco.com Subject: exec server idea From: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Sender: jw@ibch01.inf.tu-dresden.de Organisation: University of Technology Dresden X-Attribution: jfw Hi all, I don't like the fact that this list is going to be silent. I guess a lot of work has been done since 1.3.2 is out, when will 1.3.3 come? I'd like to start a discussion about a exec server again. I think a exec server would be reasonable. It could: - help to implement different formats for executables (yeah this can be done in the lib but...) - transparently execute programs on other machines or extention boards - transparently solve the problem of more or less trusted programs without having the shell maintain a database for this (I find this solution very difficult and it will grow and complicate all the shells.) - also serve a proc file system with very few help from the kernel. - remove signal handling primitives from the kernel - handling of shared libs could be simplified (It would even be possible to have a exec server which can "run" a Makefile. This way a directory containing the source would have a transparent view as a executable...) - could eventually "execute" trusted code inside of the kernel (like isr primitives, other schedulers etc.) in a very simple manner. How about the following interface: - A exec server would be mounted over say /bin and knows one or more places where to look for executable files. - to run a program we'll have to tell it which program, the argument line and our current name space. This could be done by open a file (the name of the executable) for write a line of arguments, then write the mount table, eventually write the current content of /env/#. Then write "run". Probably we should separate the parts by keywords like this: arguments: mount table: run! - now the server could fork. Insert the new process in it's proc file system and in the child process set it's id to the one of the user, load the executable, set up the mount table and execute the actual program. - the shell, or whatever "lauched" the programm could know read the process number from the file and later the exit code. - to notify anything just write "signal: " and have the exec server responsible for the rest. (Or write this to the appropriate file in the proc file system.) - a close (or at least a disconnect) on the file would have a meaning of kill for foreground processes and nothing for background. - signal handling could be really simple. It would not even need help from the kernel. Just have a thread in each program (lauched silently before the main is executed) listning on a port and have the exec server dispatch the signals to this port. Only for a unconditional kill of a thread a kernel help would be needed. But this doen't work by now anyway. BTW: (If you don't believe this: take the semasrv, remove the unqueueing of a pending request in the abort, then start semasrv and the sematest, wait 23 seconds and try to kill the hanging sematest.) - the signal serving thread could also take over the responsibility for semaphores (in a way may first attempt of the implementation of the semasrv was made -- this happend not to work but appearantly because of the debugging code I've thrown in) such to spare two context switches on semaphore operations.) - to run code in the kernel, the server would require a page from the kernel, relocate a object in this page (using the map of the kernel) and give the kernel an address to start. This could even mean to chance the complete kernel at run time ;-). - I guess even the permission code could be removed from the kernel. Just have the M_CONNECT identify the responsible "securety server" here the exec server and ask it for id's on a M_CONNECT. The longer I consider the question, the more ideas I get. But I think this should be enough for now. Any thoughts wellcome. Joerg ----------------------------------------------------------------------------- Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de Rietzstr. 32b | 01139 Dresden | Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8 WWW: (click here) From vandys@glare.cisco.com Mon Jan 9 10:56: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 KAA02233; Mon, 9 Jan 1995 10:56:03 -0800 Received: from uruk.org (uruk.org [198.145.95.253]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id LAA29474 for ; Mon, 9 Jan 1995 11:27:48 -0800 Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.6.8/8.6.6) with SMTP id LAA05999; Mon, 9 Jan 1995 11:10:06 -0800 Message-Id: <199501091910.LAA05999@uruk.org> X-Authentication-Warning: uruk.org: Host loopback didn't use HELO protocol To: joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) Cc: vsta@cisco.com, erich@uruk.org Subject: Re: exec server idea In-Reply-To: Your message of "Mon, 09 Jan 1995 17:58:07 +0100." <9501091658.AA42736@ibch01.inf.tu-dresden.de> Date: Mon, 09 Jan 1995 11:10:05 -0800 From: Erich Stefan Boleyn Hi. I've only been a lurker up til this point, but thought I should pipe up on this one. > I'd like to start a discussion about a exec server again. > > I think a exec server would be reasonable. > > It could: ...[discussion of benefits deleted]... I agree with the great potential of an exec server. Other proposals for other systems have been bandied about, and a few have been implemented. What is mostly needed is something that is doable, but won't get in the way of further enhancements. Have you looked at the OMOS project at the University of Utah? I was interested in implementing a similar kind of system for the GNU HURD (both the HURD and OMOS are on top of Mach), and had come up with many of the notions independently. I'm now discussiong pooling ideas, implementation details, and perhaps code with them. It looks to have a lot of promise. Take a look at the URL for OMOS, "http://www.cs.utah.edu/~mecklen/omos/iwooos.html", and maybe also the page on "Flexmach", which is "http://www.cs.utah.edu/projects/flexmach/". For the Mach4 project, the microkernel part, Bryan Ford was interested in getting some interchange between the Mach and VSTa development. Perhaps there is some good ground here to concentrate on. I'll be putting a page together on what I'm implementing for the HURD at some point, it if turns out to be significantly different from their OMOS project, or just for good measure anyway. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): WWW site: "http://www.uruk.org/" \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From vandys@glare.cisco.com Mon Jan 9 11:51: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 LAA02240; Mon, 9 Jan 1995 11:51:22 -0800 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id MAA03731 for ; Mon, 9 Jan 1995 12:23:11 -0800 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA10063 ; Mon, 9 Jan 1995 21:23:09 +0100 Received: from aviso.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05) id AA04250; Mon, 9 Jan 95 21:23:08 +0100 From: rideau@clipper.ens.fr (Francois-Rene Rideau) Message-Id: <9501092023.AA04250@clipper.ens.fr> Subject: mailing list access from WWW -- how ? To: vsta@cisco.com (VSTa mailing list) Date: Mon, 9 Jan 95 21:23:06 MET X-Mailer: ELM [version 2.3 PL11] Hi ! I remember having read that the VSTa list was automatically made accessible in WWW form. I'd like to do the same for the list I'm managing (about a no-kernel OS :) -- tunes@ens.fr. How can I do it ? Thanks for any help. From vandys@glare.cisco.com Tue Jan 10 00:37: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 AAA02324; Tue, 10 Jan 1995 00:37:58 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA05733 for ; Tue, 10 Jan 1995 01:09:50 -0800 Received: from humbug.demon.co.uk by post.demon.co.uk id aa20972; 10 Jan 95 9:09 GMT Received: by humbug.demon.co.uk (Linux Smail3.1.28.1 #1) id m0rRcal-0002bXC; Tue, 10 Jan 95 09:10 GMT Message-Id: From: Dave Hudson Subject: Kernel optimisations To: VSTa mailing list Date: Tue, 10 Jan 1995 09:10:15 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1469 Hi all, Well after the note that the list's been a little quiet I thought I'd mention the code I've been working on for the last week. I decided that the context switch time on a DX/4 system I use (no L2 cache) was way too slow, so I started optimising. This is absolutely critical to the operation of layered servers. I started by assuming that gcc 2.X would produce better code than the 1.42 version we're using now (and allows inline assembly), so I've been cross compiling from Linux. I modified Mike Larson's perf1 test to do 0.5M context switches and timed the results. I also timed a complete kernel rebuild. Both of these were done automatically at boot time for repeatability. Initially I scored 100 seconds for the context switches, and 120 seconds for the kernel build (gives 200 us per context switch) My main target has been the code in locore.s, some of which I've inlined, but I've also switched optimisations to -m486 and -O2. I also modified the build instructions to mutex.c to inline all of the functions (a big win). Whilst doing this, Andy and I have also clobbered a couple of other things which were big performance losses (4 or 5% of the switch time), and one bug that stopped the kernel from running if -DDEBUG was turned off (worth about 20 us) So far I'm close to my eventual aiming point (100 us), now scoring 53 seconds for 0.5M context switches (106 us), and I can now rebuild the kernel in 79 seconds. Regards, Dave